Le problème de votre transformation n’est peut-être pas le manque de ressources. C’est peut-être l’excès de priorités.

Quand on demande aux mêmes équipes de :

  • maintenir les opérations ;
  • répondre aux urgences ;
  • lancer de nouveaux projets ;
  • adopter de nouveaux outils ;
  • transformer leur manière de travailler.

On ne peut s’étonner que la transformation ralentisse.

Pour un DG ou un DAF confronté au retard d’un ERP, le progiciel qui relie notamment les achats, les stocks et la finance, cette question mérite d’être posée avant d’accepter un nouveau planning. Le retard peut venir d’un défaut technique, d’un périmètre devenu trop large, d’arbitrages en attente ou d’équipes indisponibles. Ces situations n’appellent pas la même réponse.

Ce que le planning ne dit pas

Les discussions que j'entends autour de ces programmes portent souvent sur :

  • les arbitrages ;
  • la gouvernance ;
  • la disponibilité des équipes métiers ;
  • la conduite du changement ;
  • l'évolution des processus.

Car un ERP ne transforme pas uniquement un système d'information. Il impacte les modes de fonctionnement, les responsabilités, les habitudes, et parfois même la culture de l'entreprise. C'est probablement ce qui rend ces projets aussi stratégiques. Et aussi sensibles.

Les projets les plus réussis que j'ai pu observer étaient rarement considérés comme des projets informatiques. Ils étaient portés comme de véritables projets d'entreprise.

Ces observations, formulées dans mon post du 27 août 2026, ne dispensent pas d’examiner les problèmes techniques. Une interface défaillante ou des données incohérentes peuvent suffire à empêcher le démarrage. Elles invitent à regarder aussi qui peut décider du fonctionnement attendu, et qui dispose du temps nécessaire pour le vérifier.

Identifier l’arbitrage qui attend

Pendant longtemps, la gouvernance consistait principalement à prendre les bonnes décisions. Aujourd'hui, elle consiste aussi à les prendre suffisamment vite. La nuance peut sembler mineure. Je la crois au contraire déterminante.

Dans l’épisode WBSRocks consacré aux décisions d’un projet ERP, publié le 20 octobre 2026, Sam Gupta et Shrestha Dash, du cabinet ElevatIQ, insistent sur l’identification du responsable de chaque décision et du recours en cas de désaccord. C’est un éclairage de praticiens du conseil, pas une mesure de la fréquence des échecs.

Leur propos aide à distinguer deux situations : une équipe qui manque d’une expertise pour instruire un choix, et une équipe qui a déjà présenté les options mais attend que quelqu’un tranche. Ajouter des réunions ou des consultants à la seconde ne désigne pas le décideur manquant.

Rendre du temps aux équipes métiers

La question à se poser pourrait être de savoir si votre organisation manque réellement de compétences, ou de temps réellement disponible pour réfléchir, décider et expérimenter.

Libérer de la bande passante n’est donc pas un sujet de confort. C’est une décision stratégique.

L'enjeu pour un dirigeant n'est pas de multiplier les chantiers mais de créer les conditions de leur réussite. La discipline stratégique consiste parfois à renoncer à de bonnes idées pour réussir les meilleures.

Un scénario pour départager les réponses

Une ETI prépare le remplacement de son ERP. Le démarrage a déjà été décalé. L’intégrateur demande une nouvelle date ; le DAF veut pouvoir facturer et clôturer correctement ; les opérations souhaitent conserver un traitement particulier des remises commerciales. La responsable comptable prévue pour les tests assure aussi la clôture mensuelle.

Le comité découvre trois sujets distincts. Le calcul d’une remise reste à arbitrer entre un fonctionnement standard et un développement spécifique. Le rapprochement des soldes repris n’est pas terminé. Enfin, la personne qui doit valider les résultats n’a aucun créneau réservé.

Maintenir la date avec un périmètre réduit n’est une option crédible que si les flux indispensables fonctionnent ensemble. Reporter un état de reporting peut être envisageable ; retirer un contrôle nécessaire à la facturation change la nature du risque. La réduction doit donc être instruite avec les métiers et les responsables techniques, puis testée dans ce périmètre précis.

Décaler la bascule peut permettre de terminer la reprise et les tests. Mais le report doit acheter quelque chose de concret : des journées métiers réservées, un arbitrage sur les remises et une nouvelle répétition du démarrage. Sans ces changements, il déplace le problème. Le DAF doit aussi faire expliciter les coûts encore à engager, la prolongation de l’ancien système et la charge de fonctionnement pendant l’attente.

Renforcer le pilotage peut accompagner une réduction du périmètre ou un report si personne ne peut coordonner ces dépendances ou obtenir les décisions au bon niveau. Si le problème est un défaut technique identifié, l’expertise nécessaire peut être plus ciblée. Si l’arbitrage appartient déjà au DG et attend sa réponse, ajouter un responsable de programme ne lui transfère pas automatiquement cette autorité.

Dans cet exemple, la prochaine réunion peut aboutir à trois engagements vérifiables : le responsable commercial instruit avec la finance le choix sur les remises, que le DG tranche ; le DAF rend disponible la responsable comptable en réaffectant une partie de sa charge ; le responsable du programme présente les dépendances et les preuves nécessaires à une nouvelle décision de démarrage. Les noms, dates et moyens sont à inscrire. Tant que ces preuves manquent, une promesse de livraison ne les remplace pas.

Une fiche pour préparer la prochaine décision

La fiche ci-dessous est un support de discussion, à adapter au projet. Elle ne produit pas automatiquement un feu vert.

Question Élément à rendre visible Décision attendue
Quel fonctionnement est indispensable au démarrage ? Flux métiers prioritaires et dépendances techniques Périmètre qui sera réellement testé
Quel désaccord bloque la suite ? Options, impacts et responsable habilité Arbitrage ou escalade explicite
Qui peut réaliser et valider les tests ? Créneaux réservés et charge opérationnelle réaffectée Disponibilité effectivement financée et organisée
Que reste-t-il à démontrer ? Résultats des tests, écarts de données, anomalies ouvertes Preuves manquantes et conditions d’acceptation
Que coûte chaque option à partir d’aujourd’hui ? Dépenses futures, maintien de l’existant, charge interne Comparaison des options et hypothèses à vérifier
Qui décide du démarrage et avec quel repli ? Critères, décideur final, plan de bascule et limites du retour Accord, report ou changement de périmètre motivé

Sur petit écran, faites défiler le tableau horizontalement.

La checklist de mise en service de Microsoft apporte des critères opérationnels : validation métier, tests utilisateurs avec données migrées et environnement proche de la production, tests de performance représentatifs. Son guide du basculement demande également un décideur final, des critères d’acceptation et un plan de retour. Ces documents concernent Dynamics 365 ; ils constituent des points de vérification à adapter, pas une certification de tout projet ERP.

Un retour arrière doit être préparé et évalué : il n’est pas toujours possible une fois de nouvelles opérations engagées. De même, une anomalie ouverte n’interdit pas nécessairement le démarrage, mais son impact et son traitement doivent être explicitement acceptés par les responsables compétents. Le nombre d’anomalies seul ne permet pas de décider.

Avancer sans confondre vitesse et précipitation

Les organisations lentes ne sont pas toujours celles qui manquent d’informations. Il me semble que ce sont plutôt souvent celles qui veulent être certaines avant de décider.

Face à l’incertitude, les entreprises ajoutent des comités, des validations et des analyses. Chaque précaution semble raisonnable. Mais leur accumulation peut produire un effet inattendu : personne ne décide vraiment, et les décisions arrivent lorsque le contexte a déjà changé.

Les organisations les plus efficaces ne cherchent pas à contrôler chaque variable. Elles distinguent :

  • les décisions difficiles à inverser ;
  • celles qui peuvent être testées rapidement ;
  • celles qui doivent être prises avec les informations disponibles.

Elles ne suppriment pas l’incertitude. Elles construisent une manière de progresser malgré elle.

Pour une bascule ERP, avancer malgré l’incertitude ne dispense donc pas des preuves de fonctionnement ni des conditions de repli.

Lorsque la difficulté concerne la direction du programme, le cadrage d’une mission aide à préciser les résultats attendus, les responsabilités et les moyens à confier. Ce cadrage commence par le problème observé, avant le choix d’un renfort.

La vraie question n’est pas seulement : « Que devons-nous lancer ? » C’est aussi : « Que devons-nous arrêter, simplifier ou reporter pour que les sujets essentiels avancent enfin ? »

Sources et lectures