Quand le WMS et l'ERP divergent : pannes d'interface, écarts de stock et qui est responsable du chiffre

Conclusion d'abord : quand les stocks du WMS et de l'ERP divergent, la cause n'est généralement pas qu'un système a mal calculé. C'est que les deux systèmes définissent la même chose différemment. Une interface cassée n'est que le type de défaillance le plus visible. Le plus souvent, la correspondance de lot, d'unité ou de statut est décalée, de sorte que les livres diffèrent d'une écriture alors que le stock physique n'a jamais bougé. Dans le travail d'intégration WMS-ERP pour entrepôts, le triage suit un ordre strict : vérifier d'abord si l'interface circule, puis vérifier si les correspondances sont justes, et seulement ensuite parler de qui est responsable de l'écart. Inverser cet ordre peut vous faire passer un mois à réparer le mauvais endroit.

J'ai vu cet écueil trois fois. Le cas le plus récent concernait un client de biens de consommation, dans la troisième semaine après le démarrage. La finance disait que l'ERP affichait un manque de plus de deux mille unités sur un produit papier. L'entrepôt disait que le stock physique était entièrement là, et un inventaire tournant leur a donné raison. Chaque camp était sûr que l'autre avait tort, et l'équipe projet a failli reconstruire l'interface de zéro. La vraie cause était presque embarrassante : l'ERP gérait le stock par carton, le WMS le gérait par pièce, et l'interface envoyait des quantités en cartons que le côté récepteur enregistrait comme des pièces. Avec vingt-quatre pièces par carton, une seule commande créait un écart de vingt-trois unités. Rien n'était cassé. Il manquait une ligne dans la table de correspondance des unités.

Pannes d'interface dans l'intégration WMS-ERP : quatre types, dans l'ordre

Quand une interface tombe en panne, ne redémarrez pas le service en premier. Un redémarrage ne corrige qu'une interruption temporaire. Il ne corrige pas une erreur de configuration. Je classe les pannes d'interface en quatre types et je les écarte une par une. D'abord, le message n'est jamais parti : le document sortant reste dans une file d'attente en suspens dans le WMS, souvent parce que son statut est incorrect, par exemple une commande non approuvée que l'interface ne prendra jamais. Ensuite, il est parti mais n'est jamais arrivé : la file du middleware est engorgée, ou un certificat a expiré, et la profondeur de la file plus les journaux d'erreurs rendent cela évident. Troisièmement, il est arrivé mais a été rejeté : un champ manquant, ou un code qui n'existe pas dans les données de référence de l'autre système, fait rebondir le message. Quatrièmement, et c'est le plus dangereux : il est arrivé et a été comptabilisé, mais comptabilisé de travers, par exemple une erreur de conversion d'unité ou une discordance de code d'entrepôt, de sorte que les livres dérivent silencieusement et que le problème explose des jours plus tard.

Sur chaque liste de contrôle de nuit de démarrage, j'insiste sur trois points : une alerte en cas d'arriéré dans la file d'interface, un bouton de nouvelle tentative avec un historique des tentatives pour les documents en échec, et un responsable quotidien du nettoyage des documents rejetés par l'autre partie. Une interface sans ces trois éléments fonctionne à nu. J'ai déjà travaillé avec un client dont l'interface tombait en panne chaque nuit à la même heure, parce que l'envoi programmé entrait en collision avec la fenêtre de maintenance nocturne de l'autre système. Déplacer la fenêtre d'envoi a résolu le problème. Vérifiez les horaires et les journaux avant de soupçonner le code.

Tables de correspondance pour l'intégration WMS-ERP : lot, unité et statut

Une fois que l'interface circule et que les livres divergent encore, vérifiez trois tables de correspondance. La première est la correspondance des unités : carton, palette, pièce, suremballage, quel système détient l'unité de base, où vit la conversion, et si une catégorie de produits fait exception. La deuxième est la correspondance des lots : le numéro de lot de l'ERP est-il la même chose que le numéro de lot du WMS ? Certaines entreprises utilisent la date de production comme lot dans l'ERP tandis que le WMS utilise un numéro de lot de réception, et les deux se ressemblent sans correspondre. La troisième est la correspondance des statuts : en attente d'inspection, en transit, bloqué, endommagé, à quoi correspond chaque statut de stock du WMS dans l'ERP, le stock endommagé compte-t-il comme disponible, le stock bloqué reste-t-il dans les livres ?

La défaillance la plus typique que j'aie vue était un statut « en attente d'inspection » manquant. Des marchandises en attente de contrôle qualité restaient en statut en attente dans le WMS, mais l'ERP les comptait comme stock disponible, de sorte que les ventes prenaient des commandes sur ce chiffre puis ne pouvaient pas expédier. La correction n'était pas compliquée : imprimer la table de correspondance des statuts, la faire signer ligne par ligne par les responsables métier des deux côtés, mettre le stock en attente, bloqué et endommagé chacun dans son propre compartiment, et ne laisser les ventes voir que le statut disponible. Faites signer la table avant le démarrage, ne vous contentez pas d'un accord verbal.

La réconciliation a besoin d'une table d'écarts fixe, et non d'une nouvelle extraction de données chaque fois que quelque chose ne va pas. La table a besoin d'au moins quatre colonnes : produit, quantité WMS, quantité ERP et motif de l'écart. La colonne du motif n'autorise que cinq valeurs : interface non arrivée, conversion d'unité, correspondance de statut, différence de lot ou différence physique. Toute ligne marquée « autre » repart pour une nouvelle investigation. Faites tourner cette table pendant un mois et vous constaterez que les motifs d'écart se concentrent fortement, généralement une ou deux catégories qui se répètent. Cette discipline est ce qui fait tenir la réconciliation de l'intégration WMS-ERP pour entrepôts dans le temps. Corrigez ces un ou deux points et l'écart total chute fortement.

Qui est responsable du chiffre : fixez la règle avant la dispute

Quand les livres divergent, la partie la plus coûteuse est rarement de corriger le chiffre. C'est que les deux camps se rejettent la faute. L'entrepôt dit que le système l'a mal envoyé, l'informatique dit que le métier l'a mal saisi, la finance dit qu'aucun camp n'est fiable. La responsabilité doit donc être fixée avant qu'un problème n'apparaisse, écrite dans les documents de démarrage, et non débattue après coup.

La répartition que nous utilisons est simple. Les problèmes de transmission d'interface relèvent de l'informatique, jugés sur les journaux de transmission : si le journal montre que cela a été envoyé et que l'autre partie ne l'a pas reçu, la couche intermédiaire en est responsable. Les problèmes de règles de correspondance relèvent de l'équipe projet, jugés sur la table de correspondance signée : ce que dit la table, c'est ainsi que cela compte. Les problèmes physiques relèvent de l'entrepôt, jugés sur les résultats de comptage : si le comptage et le WMS divergent, vérifiez d'abord le stock physique. Les problèmes de saisie relèvent de celui qui a saisi le document, jugés sur la valeur d'origine du document, toute modification laissant une trace. Une fois la règle en place, un écart est d'abord classé puis acheminé vers son responsable, sans passer la moitié d'une réunion à décider à qui la faute.

Voici un jugement contre-intuitif : plus l'écart est petit, plus vous devez le prendre au sérieux. Un écart de deux mille unités fait l'objet d'une enquête par tout le monde. Un écart de trois ou cinq unités est balayé d'un ajustement manuel, parce qu'il semble assez proche. Mais les petits écarts sont souvent le signal précoce d'une erreur de correspondance. Trois unités aujourd'hui peuvent devenir trois mille le mois prochain. Notre règle est que chaque écart entre dans la table avec une catégorie de motif, même s'il s'avère être un scan supplémentaire lors d'un comptage. Des petits écarts non enregistrés signifient que, quand un gros arrive, vous ne savez même pas par où commencer à chercher.

Liste de contrôle de démarrage pour l'intégration WMS-ERP en entrepôt

Pour conclure, voici une liste de contrôle que vous pouvez utiliser directement. La nuit du démarrage, cochez chaque point : la table de correspondance des unités couvre-t-elle les catégories d'exception, la table de correspondance des statuts est-elle signée par les responsables des deux côtés, la règle du numéro de lot est-elle la même chose dans les deux systèmes, l'interface dispose-t-elle d'alertes de défaillance et d'un mécanisme de nouvelle tentative, la table des écarts tourne-t-elle automatiquement chaque jour, le motif de l'écart est-il limité à ces cinq catégories, et le document de responsabilité a-t-il été envoyé aux trois parties ? Sept points, tous validés, alors démarrez. S'il en manque ne serait-ce qu'un, le coût de la correction après le démarrage est plusieurs fois supérieur à ce qu'il coûte maintenant.

La vérité brutale est la suivante : des livres WMS et ERP qui divergent ne sont presque jamais un problème de technologie. C'est un problème de définitions que la direction n'a jamais tranché. Écrivez les définitions, faites-les signer et réconciliez chaque jour. Cela fait plus que remplacer un système ne le fera jamais. J'ai vu cet écueil trois fois, et les causes étaient différentes à chaque fois, mais la solution était la même : d'abord le triage, ensuite l'attribution de la responsabilité, et enfin la correction du système.

Par Lin Xiao, Consultant en implémentation WMS

Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.