LE LABORATOIRE DE LA DÉCISION · ENQUÊTE #04
On peut réussir un ERP dans chaque service… et rater complètement l’entreprise.
J’ai été appelé comme DSI de transition après une refonte ERP.
Sur le papier, le projet paraissait plutôt simple.
Il fallait essentiellement refaire ce qui existait déjà.
Chaque métier avait travaillé sur son périmètre.
L’approvisionnement fonctionnait. La logistique fonctionnait. L’assemblage fonctionnait.
Et pourtant, quand on regardait l’entreprise de bout en bout, on obtenait quelque chose comme ça :
Approvisionnement → Excel → Logistique → Excel → Assemblage.
Personne n’avait vraiment raté son morceau.
C’était l’ensemble qui n’avait jamais été réellement conçu.
Le problème n’était pas Excel
La réaction naturelle aurait été de supprimer les fichiers Excel.
C’aurait probablement été une erreur.
Ces fichiers permettaient justement aux équipes de travailler.
Ils transportaient une information que les systèmes ne transportaient pas. Ils géraient une exception qui n’avait pas été prévue. Ils raccordaient deux processus qui avaient été pensés séparément.
Excel n’était donc pas nécessairement le problème.
Il était parfois le symptôme visible de ce qui n’avait jamais été pensé entre deux services.
Et il y avait quelque chose d’encore plus intéressant.
Celui qui maintenait le fichier finissait parfois par devenir, sans que personne ne l’ait décidé, le responsable de l’entre-deux.
L’organisation dépendait de lui. Pas parce qu’on lui avait donné cette responsabilité. Simplement parce qu’il était devenu le seul à comprendre comment raccorder les deux mondes.
On peut avoir raison dans chaque silo et tort au niveau de l’entreprise
C’est probablement l’une des choses que les projets ERP révèlent le mieux.
Chaque service peut parfaitement optimiser son fonctionnement. Chaque décision locale peut être raisonnable. Chaque module peut même fonctionner correctement.
Et pourtant, le système global peut rester mauvais.
Parce qu’une entreprise ne fonctionne pas seulement dans ses services. Elle fonctionne surtout entre eux.
Une commande devient une préparation. Une préparation devient une expédition. Une réception devient un stock. Une vente devient une facture. Une information change de propriétaire. Une responsabilité aussi.
Et c’est précisément à ces endroits que les problèmes apparaissent souvent.
Les organisations savent généralement beaucoup mieux gérer les silos que les raccords.
Un ERP transverse ne rend pas une organisation transverse
C’est là que l’illusion technologique devient intéressante.
On choisit un ERP intégré. On rassemble plusieurs fonctions dans un même système. On harmonise les données. On standardise les processus.
Et on suppose implicitement que l’entreprise devient plus transverse.
Mais l’outil ne décide pas qui est responsable lorsqu’une information passe d’un métier à l’autre, qui arbitre lorsque deux services ont des intérêts différents, quelle règle doit prévaloir lorsqu’un processus traverse plusieurs directions, ou qui doit prendre en charge ce qui n’appartient complètement à personne.
Changer l’outil ne décide pas qui porte l’entre-deux.
Le logiciel peut matérialiser une décision.
Il ne peut pas remplacer celle que l’organisation n’a jamais prise.
Nous n’avons donc pas commencé par modifier l’ERP
Nous avons commencé par quelque chose de beaucoup moins spectaculaire.
Écrire les processus que les gens avaient dans la tête.
Pas uniquement service par service. De bout en bout.
Puis nous les avons raccordés.
Et progressivement, des choses jusque-là invisibles sont apparues : une information que personne ne produisait vraiment, une responsabilité supposée appartenir au service voisin, une règle comprise différemment selon les équipes, une exception gérée depuis des années dans un fichier, des étapes parfaitement logiques localement mais incohérentes lorsqu’on regardait le flux complet.
À ce moment-là seulement, des fonctions transversales comme la direction ou la DAF pouvaient réellement arbitrer.
Le sujet n’était plus : « Que doit faire l’ERP ? »
Mais : « Comment voulons-nous réellement que l’entreprise fonctionne ? »
Le même problème existe avec le standard
C’est aussi pour cela que le débat standard ou spécifique ? me paraît souvent trop pauvre.
Rester proche du standard est généralement une excellente discipline. Le spécifique coûte cher. Il complexifie les évolutions. Et il permet parfois de fossiliser dans le nouvel ERP une habitude dont personne ne connaît plus vraiment la raison.
Mais l’inverse serait tout aussi dangereux.
Certaines spécificités protègent une vraie valeur : une promesse client, une contrainte réglementaire, une efficacité opérationnelle, une particularité du modèle économique.
Une organisation mature maîtrise sur le bout des doigts son spécifique et la valeur qu’il produit.
La bonne question devient alors :
« Si nous demandons à l’ERP de s’adapter à nous plutôt que l’inverse, quelle valeur précise sommes-nous en train de protéger ? »
Si personne ne sait répondre, il y a probablement quelque chose à challenger.
Et c’est là que « refaire comme avant » devient dangereux
J’ai entendu une variante de cette phrase dans énormément de projets :
« Notre cahier des charges ? C’est simple : on veut ce qu’on a déjà. »
Je comprends parfaitement pourquoi.
Changer d’ERP est déjà risqué. On peut légitimement vouloir limiter la transformation simultanée. Une migration très conservatrice peut même être la meilleure décision.
Le problème n’est donc pas de refaire comme avant.
Le problème est de ne plus savoir pourquoi on fait comme avant.
Parce que l’ancien système contient des années de décisions. Certaines sont toujours pertinentes. Certaines sont devenues inutiles. Certaines compensent un problème disparu depuis longtemps. Et pour certaines, personne ne sait plus vraiment.
Tout recopier est dangereux. Tout supprimer l’est aussi.
Vous pouvez décider de peu transformer. Pas de peu comprendre.
C’est probablement la principale conclusion que je tire de ces projets.
Une entreprise peut parfaitement décider : « Pour cette migration, nous voulons limiter les changements. »
C’est une décision stratégique parfaitement défendable.
Mais elle doit être capable de distinguer ce qu’elle préserve parce que c’est nécessaire, ce qu’elle standardise parce que son spécifique n’apporte rien, ce qu’elle supprime parce que la contrainte a disparu, et ce qu’elle transforme parce que cela mérite réellement de changer.
Et pour pouvoir faire ces choix, une étape vient avant toutes les autres : comprendre.
Comprendre pourquoi une règle existe. Comprendre ce qu’un fichier compense. Comprendre ce qui se passe entre deux services. Comprendre où se trouve réellement la valeur. Comprendre qui doit porter la cohérence du flux.
Parce qu’un nouvel ERP peut remplacer l’ancien.
Il ne reconstruira jamais à votre place la compréhension que l’organisation a perdue.
La question que je garderais
Dans votre organisation, qui est réellement responsable de ce qui se passe entre deux services ?
