Gartner publie la même statistique depuis vingt ans : 50 à 70 % des projets ERP « échouent » d’une manière ou d’une autre. Dépassement de budget, retard, périmètre amputé, ou non-adoption. Les chiffres n’ont pas bougé malgré de meilleurs produits, de meilleures méthodologies et des consultants plus expérimentés.
C’est parce que l’industrie continue de traiter les symptômes au lieu des causes. Projet en retard ? Ajoutez des développeurs. Périmètre manquant ? Faites un avenant. Mauvaise adoption ? Faites plus de formation. Rien de tout cela ne résout quoi que ce soit parce que le vrai problème n’est presque jamais là où il semble être.
Cet article présente le framework cause racine que nous utilisons chez Asio Services pour rattraper les projets ERP cassés. C’est le framework que nous aimerions voir utilisé par plus de partenaires, parce que la plupart des échecs ERP ne sont pas des échecs de Business Central. Ce sont des échecs d’analyse.
La distinction symptôme / cause racine
Un symptôme est ce qui fait mal. Une cause racine est pourquoi ça fait mal. En ERP, l’écart entre les deux est souvent profond de trois couches, et les couches sont très différentes les unes des autres.
Exemple classique : « Notre workflow de validation des commandes d’achat est trop lent. » C’est le symptôme. La cause racine n’est presque jamais dans le workflow lui-même. Couche un : le valideur est saturé de notifications et les ignore. Couche deux : la matrice de validation a 7 niveaux au lieu de 3 parce que personne ne fait confiance au système. Couche trois : l’entreprise n’a jamais écrit ce qu’elle veut vraiment contrôler versus ce qu’elle prétend contrôler. La vraie correction est en couche trois. Tout le monde essaie de corriger en couche un.
Les 5 causes racines les plus courantes
Après avoir rattrapé des dizaines de projets BC cassés, on voit les mêmes cinq causes racines revenir.
Cause racine un : processus non définis. Le pattern le plus fréquent. L’entreprise n’a jamais écrit ses propres processus. Elle a demandé au partenaire d’« automatiser ce qu’on fait aujourd’hui », mais « ce qu’on fait aujourd’hui » est différent dans la tête de chacun. Résultat : un système qui ne va à personne.
Cause racine deux : données traitées en dernière minute. La qualité des données de référence a été supposée, pas vérifiée. Doublons, champs manquants, codes obsolètes ont été migrés tels quels. Tous les rapports sont peu fiables et chaque décision analytique est contaminée.
Cause racine trois : personnalisation au lieu de standardisation. Le partenaire a personnalisé BC pour coller à chaque processus existant, quel que soit son âge. Cinq ans et plusieurs mises à jour BC plus tard, le système est ingérable et bloqué sur une vieille release.
Cause racine quatre : partenaire complaisant. Le partenaire n’a jamais dit non à une seule demande. Chaque « ce serait bien » est devenu un développement. Le système est bloaté, lent et coûteux à faire évoluer.
Cause racine cinq : conduite du changement sautée. Le projet technique était parfait sur le papier mais personne côté métier n’était préparé. L’adoption n’a jamais eu lieu. Le système tourne mais le métier tourne sur Excel à côté.
Les 5 pourquoi, version ERP
La méthode classique des « 5 pourquoi » de Toyota fonctionne sur les problèmes ERP si on a la discipline de continuer à demander. Voici un vrai exemple d’un client que nous avons aidé.
Problème : la clôture mensuelle prend 15 jours au lieu des 5 attendus.
Pourquoi 1 : parce que le rapport de consolidation doit être reconstruit à la main chaque mois. Pourquoi 2 : parce que les éliminations intercompany sont saisies dans Excel après la clôture BC. Pourquoi 3 : parce que le module intercompany de BC n’a pas été configuré pour les nouvelles entités ajoutées en 2023. Pourquoi 4 : parce que le partenaire n’a jamais été sollicité pour mettre à jour la configuration après l’acquisition. Pourquoi 5 : parce que l’entreprise n’avait pas de propriétaire interne de la roadmap BC après le go-live.
Le symptôme était une clôture à 15 jours. La correction que le partenaire proposait était « de meilleurs rapports ». La vraie cause racine était la gouvernance : il n’y avait personne côté client qui portait la roadmap BC. C’est ça, la correction.
Pourquoi la plupart des partenaires refusent l’analyse cause racine
Si l’analyse de cause racine est si puissante, pourquoi peu de partenaires l’utilisent ? Trois raisons.
Premièrement, c’est plus lent. Poser cinq pourquoi prend des heures. Traiter les symptômes prend des minutes. Les partenaires aux marges serrées préfèrent la solution rapide.
Deuxièmement, ça déplace la responsabilité. La cause racine pointe souvent vers une décision que le partenaire a prise (ou n’a pas poussé à reconsidérer). Les partenaires évitent les analyses qui risquent la responsabilité.
Troisièmement, ça demande des consultants seniors. On ne fait pas de vraie analyse cause racine avec un junior. La plupart des partenaires placent des juniors sur le quotidien et réservent les seniors pour la vente. La RCA casse ce modèle économique.
Les partenaires qui font de la RCA correctement facturent plus, livrent moins de volume, et ont des clients plus satisfaits. Le choix vous appartient.
Comment repérer un partenaire qui fait du travail cause racine
Trois signaux vous disent qu’un partenaire est sérieux sur l’analyse de cause racine.
Premier signal : il pose souvent « pourquoi » en première réunion. Pas d’une manière socratique agressive, mais avec curiosité. Il veut comprendre la chaîne derrière votre demande avant de proposer une correction.
Deuxième signal : il a une phase de découverte payée. La RCA ne tient pas dans une réunion commerciale gratuite. Un partenaire qui facture sa découverte est un partenaire qui prévoit de faire l’analyse correctement.
Troisième signal : il a des anecdotes de clients qu’il a refusés. Les partenaires qui font de la RCA concluent parfois « Business Central n’est pas la bonne réponse pour vous ». Si un partenaire n’a jamais dit non à un prospect, c’est qu’il n’a jamais fait de vrai diagnostic.
L’approche Asio Services : ERP propre, pas de sparadrap
Nous avons construit Asio Services autour de l’analyse de cause racine. C’est pour ça que nous commençons chaque engagement par une découverte payée, que nous avons des consultants seniors sur chaque projet, et que nous recommandons parfois aux clients de ne pas se lancer.
Nous appelons cette approche « ERP propre » : pas de bricolage, pas de sparadrap, pas de corrections symptômatiques qui reviennent comme des problèmes plus gros au trimestre suivant. Ça coûte plus de temps en amont. Ça économise un ordre de grandeur en coûts et en douleurs en aval.
Si votre Business Central montre des symptômes (clôture lente, rapports peu fiables, faible adoption, tickets récurrents), la réponse n’est pas toujours plus de développement. C’est peut-être une analyse de cause racine.
→ Réservez un appel découverte gratuit avec Asio Services. Nous vous aiderons à séparer les symptômes des causes et vous dirons, en français clair, si la correction est dans Business Central ou ailleurs.
