ERP transfrontalier

Voici un ERP en service pour une entreprise qui vend de l'équipement de part et d'autre de la frontière Canada/États-Unis. Soumissions, commandes, inventaire, achats et CRM alimentent tous un document qui compte plus que les autres : la déclaration en douane, celle qui coûte vraiment cher quand elle est fausse.

Le constructeur de déclaration affecte chaque ligne à une source d'inventaire, scinde une ligne entre plusieurs sources quand un lot ne suffit pas, et agrège le résultat dans un addenda ventilé par pays d'origine, avec poids et valeurs de chaque côté de la frontière. L'affectation automatique PEPS traite le cas courant, et une surcharge manuelle traite celui que l'algorithme rate. Cinq barrières de validation comptent ce qui cloche encore au lieu d'accepter le formulaire : origine manquante, poids manquant, valeur manquante, lignes non affectées, et rupture sur bon de commande, chacune étant un filtre vivant dans lequel on peut entrer.

Ce que nous avons mesuré

Autour se trouve le reste du système. Un outil de marge qui sert aussi de constructeur de soumission : une pièce tirée du catalogue porte son coût moyen réel, donc la marge est calculée plutôt que saisie, en CAD ou en USD au taux du jour. La conversion en un clic d'une soumission enregistrée en commande de vente, la soumission d'origine restant inscrite dessus. Un catalogue de pièces avec cumul des coûts, des nomenclatures, des bons de commande, des fournisseurs, un journal de production et un CRM. Et un journal d'audit dont les entrées peuvent être annulées, parce que les erreurs coûteuses dans un ERP sont celles que personne ne remarque pendant un mois.

À quoi ça tient

Un ERP n'est pas difficile parce que les fonctions sont difficiles. Il est difficile parce que les données sont partagées : une ligne de soumission, une affectation de stock et une ligne de douane sont le même objet vu de trois façons, et s'ils peuvent diverger, ils divergeront. L'essentiel de l'effort de conception est allé là, et non dans les écrans.

Une habitude est sortie de ce code et y est restée. Une classe de défaut y faisait produire silencieusement du CSS invalide à toute la couche de jetons de design, si bien que l'application s'affichait « presque bien » pendant des mois sans une seule erreur dans aucun journal. Mesurer le rendu plutôt que se fier à la réussite d'une compilation est désormais la règle.