Dans la plupart des entreprises, un programme ERP démarre avec une promesse simple : standardiser, fiabiliser, gagner en visibilité, mieux piloter. Le cadrage est ambitieux, l’intégrateur est sélectionné, les ateliers s’enchaînent, les macros-plannings s’affichent, et l’on se persuade que le risque principal sera technique : un paramétrage complexe, des interfaces délicates, des reprises de données incertaines. C’est rassurant, parce que cela ressemble à un problème d’experts.
La réalité est moins confortable, et surtout plus fréquente : l’ERP échoue rarement parce qu’on ne sait pas paramétrer. Il déraille parce qu’on ne sait pas trancher. Et ce déficit de décisions n’est pas un accident, c’est une gouvernance floue, molle, non assumée. Le programme devient alors un théâtre de compromis : chacun protège son périmètre, les arbitrages s’empilent, les exceptions gagnent, et l’intégrateur finit par “faire comme il peut”. C’est à ce moment précis que le paramétrage devient un bouc émissaire. On accuse l’outil, alors que c’est l’organisation qui n’a pas tenu le volant.
L’ERP est une machine à décider, pas un projet IT
Un ERP n’est pas un déploiement applicatif. C’est un changement de fonctionnement. Il force l’entreprise à clarifier ses règles, ses responsabilités, ses données, ses rôles, ses contrôles, ses exceptions, et parfois même sa manière de vendre, d’acheter, de produire, de facturer ou de clôturer. Autrement dit, l’ERP est une machine à exposer les désaccords.
Quand la gouvernance est solide, ces désaccords deviennent des décisions, prises vite, documentées, assumées, et traduites dans le modèle. Quand la gouvernance est faible, les désaccords deviennent des ateliers sans fin, des comptes-rendus sans suites, des “on verra plus tard”, puis des escalades tardives qui explosent le planning. Le programme se met à patiner, les métiers s’agacent, l’IT s’épuise, et l’intégrateur avance à l’aveugle.
À partir de là, l’entreprise entre dans un cycle connu : glissements de périmètre, rallonges budgétaires, baisse de qualité, et perte de confiance.
Le flou le plus coûteux : “qui tranche quoi” et “à quel niveau”
Le cœur du problème tient dans une question que beaucoup d’organisations évitent : qui a le droit de décider. Pas “qui participe”, pas “qui donne un avis”, mais qui tranche, avec quel mandat, et selon quelle logique.
Dans un ERP, certaines décisions sont fonctionnelles et doivent être prises par le métier. D’autres sont transverses et doivent être arbitrées à un niveau de direction. D’autres encore sont architecturales, et relèvent de l’IT. Si ces frontières sont confuses, le programme se transforme en marché permanent, où la décision se déplace vers la zone la plus confortable : personne ne tranche, donc tout le monde négocie.
C’est ainsi que naissent les pires dérives : des exceptions validées “par fatigue”, des développements spécifiques “pour rassurer”, des règles de gestion incohérentes “pour contenter”, et des interfaces bricolées “pour ne pas changer le process”. Chaque concession semble petite, mais l’addition est massive : complexité, coûts, fragilité, et dette, dès le jour du go-live.
RACI : utile seulement si le R et le A sont réels
Le RACI est souvent cité, rarement appliqué. On affiche des matrices, on coche des cases, et on croit avoir réglé le sujet. Or le RACI n’a de valeur que s’il est vécu, et s’il est respecté dans la cadence du programme.
Le “Responsible” exécute. Le “Accountable” tranche et porte la décision. Et c’est justement ce “A” qui manque dans les programmes en difficulté. On a des contributeurs, des experts, des key users, des consultants, parfois même des directeurs. Mais on n’a pas d’autorité opérationnelle qui assume les arbitrages, et qui accepte les conséquences.
Quand l’“A” n’est pas réel, la décision remonte trop tard, ou elle se dilue. Le programme devient un empilement de réunions sans énergie. On discute beaucoup, on avance peu. Et pendant ce temps, l’intégrateur continue de paramétrer sur des hypothèses, ce qui prépare un retour de boomerang violent au moment des tests.
Les comités ne servent à rien si la décision n’a pas de canal d’exécution
Un ERP génère des centaines de microdécisions, et une poignée de décisions structurantes. Si le programme ne sait pas distinguer ces deux catégories, tout remonte en comité, tout prend du temps, tout s’alourdit. Et si au contraire rien ne remonte, les équipes terrain prennent des décisions locales qui deviennent ensuite impossibles à harmoniser.
Une gouvernance efficace définit une mécanique lisible : où se prennent les décisions du quotidien, où se prennent les décisions transverses, comment on escalade, sous quel délai, avec quels critères, et surtout comment la décision se traduit immédiatement dans le dispositif de delivery.
Le point le plus sous-estimé, c’est le “canal d’exécution”. Une décision n’existe pas tant qu’elle n’est pas traduite en action : mise à jour du backlog, changement du modèle, adaptation des règles de gestion, modification des jeux de tests, communication aux key users, et mise à jour documentaire. Si le programme ne dispose pas de cette chaîne, il produit des décisions “sur PowerPoint”, puis les rediscute la semaine suivante parce qu’elles n’ont pas été absorbées.
Sponsor : sans sponsor actif, l’ERP devient une guerre de tranchées
Le sponsor n’est pas un nom sur une slide. C’est un rôle actif, qui protège le programme et impose la priorité. Dans beaucoup d’entreprises, le sponsor est trop haut, trop loin, ou trop occupé. Il valide des jalons, mais il ne porte pas les décisions difficiles. L’ERP devient alors un champ de bataille entre directions, et chaque arbitrage est une négociation politique.
Un sponsor efficace fait deux choses. Il impose une direction, et il sécurise la capacité de décider. Il accepte que l’ERP n’est pas la somme des préférences locales, mais un modèle cible, avec des règles communes. Il assume les renoncements nécessaires. Et surtout, il arbitre vite, parce qu’il comprend que le temps perdu en décision coûte plus cher que la décision imparfaite.
Sans sponsor actif, le programme est condamné à être “raisonnable” au lieu d’être “tenu”.
Cadence : le tempo de décision est un KPI invisible
Les programmes ERP sont souvent pilotés par des KPI de delivery : avancement des lots, taux de réalisation, disponibilité des environnements, volume de tickets, progression des tests. C’est nécessaire, mais insuffisant. Le KPI le plus critique est rarement mesuré : le délai moyen de décision.
Quand les décisions prennent trois jours, le programme respire. Quand elles prennent trois semaines, le programme étouffe. Les équipes attendent, les ateliers se répètent, les consultants produisent des variantes, les métiers se contredisent, et l’on paie du temps homme pour ne pas avancer. À la fin, le retard est “rattrapé” en dégradant la qualité : tests écourtés, cutover compressé, conduite du changement sacrifiée. L’échec se prépare là, pas dans le paramétrage.
Une bonne gouvernance installe une cadence de décision, comme une routine industrielle. Un rythme de comités, mais aussi un rythme d’escalade, avec des délais fermes et une capacité à trancher sur la base de critères connus : conformité, risque, valeur, coût, simplicité, impact RUN.
“Qui tranche quoi” : l’arme absolue pour remettre le programme sous contrôle
Remettre un programme ERP sous contrôle consiste rarement à “tout reprendre”. Cela consiste à rendre la décision impossible à éviter. Concrètement, cela passe par une clarification immédiate des niveaux de décision, une simplification des circuits, et une mise sous contrainte des demandes hors standard.
Les demandes de spécifique, par exemple, ne devraient jamais être traitées comme des “détails”. Elles doivent être un sujet de gouvernance : pourquoi on veut déroger, quel problème on évite, quel coût cela crée, quel risque cela ajoute, quel impact sur les mises à jour, la maintenance, la sécurité, l’exploitation. À partir du moment où ces questions sont posées systématiquement, les exceptions diminuent. Le programme redevient cohérent.
La gouvernance sert à protéger le standard, parce que le standard protège la tenue dans la durée.
CTA : DP ERP pour remettre le programme sous contrôle
Un programme ERP n’a pas besoin d’un énième atelier. Il a besoin d’une gouvernance qui tranche, d’un sponsor réellement mobilisé, d’un RACI appliqué, d’une cadence de décision, et d’un dispositif de delivery qui transforme chaque arbitrage en action immédiate. C’est cela qui réduit le risque, stabilise le planning, et évite que l’entreprise découvre au go-live que “tout le monde n’était pas d’accord”.
Je suis DSI / directeur de programme ERP de transition. J’interviens pour remettre un programme sous contrôle, structurer la gouvernance, clarifier “qui tranche quoi”, sécuriser la cadence de décisions, piloter l’intégrateur et les métiers, et ramener le programme à une trajectoire tenable, orientée résultats.
Je suis disponible pour une nouvelle mission : guy@de-lussigny.com / 06 45 90 40 79
En savoir plus sur GDL T&C
Subscribe to get the latest posts sent to your email.