La demande n’est jamais le problème
Quelqu’un demande un état. Ce dont il a besoin, c’est d’arrêter de réconcilier deux systèmes qui ne disent pas la même chose. Quelqu’un demande un champ. Ce dont il a besoin, c’est qu’une seule personne soit propriétaire d’un chiffre qui en a trois aujourd’hui.
Prenez la demande au pied de la lettre et vous la livrerez correctement, dans les délais, sans rien changer. Le système grossit, le symptôme reste, et dans dix-huit mois la même personne demande un deuxième état.
Le premier geste est donc de trouver la question derrière la demande, celle que personne n’a formulée à voix haute. C’est un travail inconfortable, et c’est précisément pour ça qu’on le saute.
Dans un groupe, un mauvais process n’est pas agaçant. Il est multiplié
Dans une société unique, un process maladroit coûte quelques heures par mois et tout le monde le contourne. Sur huit filiales, le même process est répliqué huit fois, diverge localement, et chaque année où il survit rend son démontage plus cher.
C’est pour ça que le même symptôme coûte un ordre de grandeur de plus ici que dans l’étude de cas de l’éditeur, et pourquoi les problèmes ERP de groupe résistent aux correctifs qui marchent très bien à l’échelle d’une société.
C’est aussi pour ça que la cause est bien plus souvent un vide de gouvernance qu’un défaut de conception. Personne n’a décidé que le groupe fonctionnerait d’une certaine façon, chaque entité a donc décidé localement, et l’ERP a fidèlement encodé huit réponses à une seule question.
Des symptômes qui veulent presque toujours dire autre chose
Une clôture à quinze jours est rarement un problème comptable. Ce sont en général des flux intercos jamais mis d’accord, réconciliés à la main à chaque fin de période, parce que les mettre d’accord aurait demandé un arbitrage que personne ne voulait porter.
Une consolidation que le DAF rattrape à la main dans un tableur n’est pas un manque de reporting. C’est un plan comptable harmonisé sur le papier et resté divergent dans les faits.
Cinq filiales qui résolvent le même problème de cinq façons différentes, ce n’est pas un sujet de formation. C’est l’absence de décision, rendue visible. L’ERP n’est pas le problème. Il est le procès-verbal d’une décision que personne n’a prise.
Ce que nous faisons au lieu d’écrire un cahier des charges
Nous remontons du symptôme à la décision qui l’a produit, puis nous faisons la partie que la plupart des consultants évitent : nommer qui est propriétaire de cette décision. Pas une équipe, une personne, au niveau qui a l’autorité de trancher.
Ensuite nous la faisons trancher avant que quoi que ce soit ne soit paramétré. Une décision prise en comité de direction coûte une réunion. La même décision découverte en atelier de paramétrage coûte une phase. La même décision découverte après la bascule coûte un sauvetage.
Parfois la conclusion est qu’il ne faut rien construire du tout. C’est une mission réussie, et nous préférons vous le dire plutôt que de vous vendre un développement.
C’est ça, Clarity Before Code, concrètement
Ce n’est pas une préférence pour moins de code. Nous savons quand il faut construire mille objets et quand il ne faut en construire aucun, et la plupart des consultants se trompent sur les deux dans le même projet.
Ça veut dire que le code que vous obtenez est délibéré et bien dimensionné, parce que la question à laquelle il répond a réellement été posée. Si le besoin n’est pas clair, la solution est forcément mauvaise, aussi bien construite soit-elle.
Le test est simple. Six mois après la bascule, quelqu’un peut-il nommer la règle que chaque personnalisation encode, et cette règle est-elle encore vraie ? Sinon, vous n’avez pas construit un système. Vous avez construit le compte rendu d’une conversation que personne n’a terminée.
