Intégration ERP et planification : qui est maître de quelles données ?

Le service commercial pose une question simple : combien reste-t-il à fabriquer sur l'ordre 4711 ? L'ERP répond 320. Le planning du planificateur dit 308. L'atelier dit « terminé ». Trois systèmes, trois réponses, et chacune est juste selon ses propres règles. C'est exactement le problème que l'intégration ERP doit résoudre.

L'intégration ERP pour la planification de la production consiste à relier votre ERP (progiciel de gestion intégré : SAP, Oracle, Microsoft Dynamics 365 ou un autre) à l'outil qui planifie et ordonnance la production, pour que les ordres, les stocks et les déclarations aient le même sens des deux côtés. La difficulté est rarement la liaison technique. Elle consiste à se mettre d'accord sur le système maître de chaque donnée, et sur ce que signifie chaque chiffre.

Trois réponses pour un seul ordre

L'ordre 4711 porte sur 500 pièces bonnes. Jusqu'ici, la machine en a traité 192 : 180 bonnes et 12 rebuts.

• L'ERP retranche les pièces bonnes : 500 − 180 = reste 320.
• L'outil de planification a retranché tout ce qui est passé sur la machine : 500 − 192 = reste 308.
• L'atelier a reçu un ordre de travail pour la série de la semaine, soit 192 pièces. Cette série est finie : pour lui, c'est terminé.

Personne ne s'est trompé de chiffre. Chacun utilise une définition différente du « reste ». L'intégration commence par l'accord sur ces définitions, avant même de mapper le premier champ.

Une déclaration partielle, suivie dans les deux systèmes

Un ordre de fabrication de 100 équerres comporte trois opérations : 10 découpe, 20 soudage, 30 peinture. Le soudeur déclare 60 pièces bonnes à l'opération 20 et rentre chez lui.

• Dans l'outil de planification, il reste 40 pièces à l'opération 20, reportées au lendemain. La peinture peut démarrer sur les 60, si vos règles de transfert autorisent les lots partiels. L'ordre de travail apparaît comme partiellement terminé, toujours rattaché à la commande client.
• Dans l'ERP, l'ordre reçoit une déclaration partielle de 60 à l'opération 20. Aucune entrée en stock de produits finis pour l'instant : elle n'aura lieu qu'après la peinture.

Voyons maintenant deux choses qui dérapent dans la vraie vie.

Le message part deux fois. Une micro-coupure réseau, une nouvelle tentative, et l'ERP affiche 120 pièces soudées sur 100. Chaque déclaration a besoin d'un identifiant unique, pour que le système destinataire repère le doublon et l'ignore.

Le comptage est corrigé. Le lendemain matin, le contrôle trouve 5 soudures défectueuses sur les 60. La déclaration devient 55 bonnes et 5 rebuts : il en faut donc encore 45, et non 40. Quelqu'un doit décider si l'on découpe 5 pièces de plus ou si le client accepte 95 pièces. C'est une décision humaine, pas une décision d'interface.

Date demandée, date calculée, date promise

La plupart des commandes portent trois dates, qui ne doivent pas s'écraser l'une l'autre :

• Demandée : ce que le client a demandé, le 10 mars. Elle ne change que si le client la modifie.
• Calculée : ce que l'outil de planification juge possible, le 14 mars. Elle peut changer à chaque calcul du planning.
• Promise : ce que le commercial a confirmé après avoir vu la date calculée, le 15 mars. Elle ne change que si quelqu'un décide de promettre à nouveau.

L'erreur classique consiste à écrire directement la date calculée dans la date promise. Chaque calcul du planning modifie alors en silence ce qu'on a annoncé au client. Mieux vaut : si la date calculée dépasse la date promise, alerter le commercial, sans rien écraser. La façon dont la promesse est vérifiée au départ est traitée dans de la commande client à la production.

Qui est maître de quelles données dans une intégration ERP

La règle : chaque champ a un seul maître, le seul système autorisé à le modifier. L'autre se contente de le lire. Une répartition typique :

Votre répartition peut être différente. L'essentiel est qu'elle soit écrite.

Pensez à deux cuisiniers qui salent la même soupe. Chacun la goûte, la trouve fade et ajoute du sel. Tous deux ont agi raisonnablement. La soupe est immangeable. Une donnée avec deux maîtres finit de la même façon.

Le mythe : « Une bonne intégration synchronise tout, dans les deux sens, en temps réel »

Envoyer chaque champ dans les deux sens garantit que les deux systèmes s'écrasent mutuellement. Une bonne intégration est sélective : ce dont l'autre côté a besoin, quand il en a besoin, un seul sens par champ. Les déclarations peuvent circuler toutes les quelques minutes, les données articles une fois par jour.

SAP, Oracle, Dynamics : les mêmes questions

Rien de tout cela ne dépend de la marque. Avec SAP, Oracle ou Microsoft Dynamics 365, il faut toujours s'accorder sur ce que signifie « reste », sur quelle date est laquelle et sur le maître de chaque champ. Le mapping des champs varie selon le système et le paramétrage : réglez donc d'abord la question du maître. Pourquoi une couche de planification distincte est nécessaire, c'est ce qu'explique pourquoi votre ERP croit que chaque ordre prend 10 jours.

Comment factory.online vous aide

factory.online s'intègre avec SAP et Microsoft Dynamics 365. Si vous utilisez Oracle ou un autre ERP, demandez-nous ce qu'impliquerait une connexion dans votre configuration. Dans factory.online, le planificateur voit chaque ordre de fabrication avec ses ordres de travail et les déclarations de pièces bonnes et de rebuts par opération : les 60 équerres soudées et les 40 restantes sont visibles, rattachées à la commande client. Les lots produits conservent leur historique pour la traçabilité des lots.

Si votre ERP, votre planificateur et votre atelier donnent trois réponses différentes, réservez une démo et nous suivrons ensemble l'un de ces ordres.