Intégration ERP & Numérisation des Processus

SAP, Dynamics, NetSuite, Odoo et de nombreux ERP régionaux via des connecteurs standards ; tout le reste via API REST ou échange de fichiers.

La couche d’intégration mappe les champs et logiques personnalisés. La personnalisation est normale et ne fait pas obstacle.

MSF complète l’ERP sans le remplacer : vous conservez finance et commerce là où ils sont, et gagnez une couche de production de niveau mondial.

En entrée, généralement les ordres de fabrication, les données articles, les nomenclatures, les gammes et les niveaux de stock. En sortie, les confirmations d’ordre et d’opération, les quantités produites et rebutées, la consommation matière et les résultats qualité. Le débat ne porte jamais sur cette liste, mais sur le système qui fait autorité sur chaque champ et sur ce qui se passe quand les deux sont modifiés. Tranchez cette question champ par champ avant que quiconque écrive un mapping, car cette décision coûte cher à défaire.

Oui, si les confirmations doivent être renvoyées dans l’ERP. Tout ce qui déclenche un mouvement de stock ou clôture une opération est une écriture, et votre équipe ERP voudra la faire passer par des interfaces livrées (BAPI, services OData ou table de staging) plutôt que par un accès direct à la base. Une première phase en lecture seule est raisonnable : récupérer les ordres, les afficher à l’atelier, et continuer à saisir les mouvements à la main tant que les chiffres ne concordent pas.

Quelques semaines lorsqu’un responsable est nommé côté ERP, qu’un système de test est représentatif de la production, que les interfaces sont convenues et que les données de référence sont globalement correctes ; plus longtemps quand ce n’est pas le cas. Le travail de connecteur est rarement le chemin critique : ce sont les fenêtres de changement, les validations de transport et l’attente d’une réponse sur lequel de quatre codes articles est le bon. Si vous ne pouvez pas nommer aujourd’hui le contact ERP, comptez en mois plutôt qu’en semaines.

Par des dépôts CSV ou XML planifiés en SFTP, une table de staging côté ERP, ou une vue base de données construite et maintenue par votre éditeur ERP ou votre propre équipe ERP ; lire vous-même les tables applicatives est généralement refusé et peut casser à la montée de version. Ce que vous perdez, c’est l’immédiateté : la latence est celle de l’intervalle retenu, souvent une fois par équipe ou une fois par nuit. Le flux retour exige un job d’import côté ERP, avec un responsable et une règle pour les enregistrements qu’il rejette.

Ils divergeront, et aucune intégration ne décide qui a raison. Les écarts viennent de saisies faites à des moments différents, du rebut constaté à l’atelier mais pas encore comptabilisé, et des mouvements réalisés en dehors des deux systèmes. Ce que vous gagnez, c’est une piste d’événements : un écart se remonte jusqu’à une équipe et un ordre, et n’apparaît plus en bloc à l’inventaire. Désignez un responsable du rapprochement et une fréquence avant le go-live.

Si l’ERP est injoignable mais que le serveur local et le réseau usine fonctionnent, les ordres déjà lancés restent sur les écrans et les opérateurs continuent de confirmer. Ces confirmations sont écrites dans la base locale, survivent donc à un redémarrage et partent dès que l’ERP répond. La vraie limite, ce sont les ordres jamais transférés : ils ne peuvent pas être démarrés. Demandez si les écritures rejouées peuvent tomber dans une période que votre comptabilité a déjà clôturée.

Non. Le concepteur de flux de processus numérise les formulaires, les validations et le routage du travail entre les personnes : les dérogations papier et les processus de modification technique y basculent bien. Mais il ne change pas la façon dont votre ERP valorise, planifie ou comptabilise, et toute étape qui doit mettre à jour un enregistrement ERP a toujours besoin d’une interface derrière. Une logique qui relève en réalité du calcul, comme les règles de coût de revient, doit rester là où vivent ces données.