Une mauvaise règle dans le fichier d’une équipe reste locale. La même règle dans un ERP touche ventes, inventaire et finance avec beaucoup de discipline. Cette portée est justement la force du système : une commande confirmée peut réserver le stock, déclencher l’expédition et préparer la facture selon un même modèle.

Le risque apparaît lorsque la règle commune est fausse ou qu’une exception légitime n’a aucun chemin. Le monde invente alors un code « divers », une note libre ou un fichier parallèle. L’ERP reste propre en apparence pendant que le vrai processus se déplace.

Concevoir l’exception comme un état

Prenons une commande au-dessus de la limite de crédit :

1. AX calcule exposition actuelle et montant de la commande;
2. la règle place le document bloqué_crédit;
3. aucune libération d’entrepôt n’est permise;
4. une tâche va au rôle Crédit;
5. l’analyste approuve, refuse ou demande une garantie;
6. la décision, la raison et la durée sont auditées;
7. le document reprend ou demeure bloqué.

Permettre à un vendeur de changer directement la limite résout l’écran et détruit le contrôle. Une dérogation explicite garde la règle, son décideur et sa preuve. Elle peut expirer afin de ne pas devenir la nouvelle valeur par défaut.

Le moteur de workflow, les statuts, la sécurité et les écritures doivent rester cohérents. Si le workflow tombe après l’écriture du blocage mais avant la notification, une file surveillée doit reprendre. L’état du document est la source; le courriel n’est qu’un signal.

Corriger une règle sans réécrire l’histoire

Une nouvelle tolérance peut s’appliquer aux commandes futures, mais les documents en cours demandent une décision. Une migration aveugle peut libérer des commandes déjà revues. Je définirais une date d’effet, un ensemble ciblé et un rapport avant/après. Le script est transactionnel et idempotent.

Les rôles doivent séparer vente, crédit, expédition et administration. Les accès directs à SQL contournent validations et audit. Les interfaces externes utilisent les services applicatifs et transmettent un identifiant stable pour éviter les doublons.

La gouvernance de la règle tient dans un registre : propriétaire, objectif, formule, exceptions, métrique et dernière revue. Si 40 % des commandes demandent une dérogation, le processus ou la limite ne représente plus le terrain. L’indicateur déclenche une révision, pas une chasse aux utilisateurs.

Observer le contournement comme un signal de conception

Les exports Excel, codes « autre » et commentaires libres indiquent où le modèle ne couvre pas le travail. Je ne les interdirais pas avant de mesurer leur cause. Un rapport relie fréquence, équipe, étape et délai produit. Si une exception rare protège un client important, on lui construit un chemin contrôlé. Si elle sert chaque semaine, la règle standard doit peut-être changer. Les modifications sont comparées à des indicateurs de crédit, stock et temps de cycle pour éviter d’optimiser seulement la saisie. Cette boucle fait du contournement une donnée de gouvernance plutôt qu’un duel entre utilisateurs supposément indisciplinés et système supposément parfait.

Je testerais une règle avec normal, limite exacte, dépassement, reprise après panne et annulation. Puis je rapprocherais statuts, stock et grand livre. Un ERP apporte de la cohérence lorsqu’il rend les exceptions visibles et décidables; la rigidité devient dangereuse quand elle force le travail à se cacher.