ERP diagnostic-d'abord : à quoi ressemble la nouvelle voie en pratique ?
Les trois premiers articles de cette série ont construit un mécanisme : le modèle jour-homme devait vendre le diagnostic bon marché parce qu'il valorisait l'intrant ; et dès lors que l'IA a rendu le travail mécanique bon marché, la qualité de la décision est devenue la seule véritable différence. Reste une question : à quoi ressemble ce mécanisme dans un projet ? Cet article ne pose pas de nouvelle question — il décrit l'ordre. Comment se déroule, étape par étape, un parcours ERP diagnostic-d'abord ?
Les cinq étapes de la nouvelle voie
- Mesurer : Avant de regarder une démo ou de collecter des offres, chiffrez la situation actuelle — quelle part de vos processus est documentée, quelle est la propreté des données de référence, qui est propriétaire de quelle décision. Sans mesure, chaque étape suivante repose sur des suppositions.
- Diagnostiquer : Transformez la mesure en constat. « La précision des stocks est faible » est une observation ; « les écritures de correction après inventaire se concentrent dans cet entrepôt, sur cette famille de produits » est un diagnostic. Le diagnostic vous dit quel problème mérite d'être résolu.
- Écrire le critère : Rédigez la définition du succès avant le démarrage, avec un chiffre et une date. « La mise en production » n'est pas un critère de succès ; « la clôture mensuelle passe de cinq jours ouvrés à deux » en est un. Le critère doit être vérifiable indépendamment de l'éditeur.
- Ordonner les phases par dépendance : Que ce soit la dépendance technique — et non l'appétit des départements — qui détermine l'ordre des phases. Si une phase ne peut pas fonctionner sans le résultat de la précédente, cet ordre n'est pas négociable.
- Lier la recette à la preuve : À la fin de chaque phase, le relevé ne doit pas dire « ça marche » mais « ce scénario, avec ces données, a été exécuté par cette personne et il est passé ». Si la recette n'est pas liée à une preuve, la réunion de transfert tourne à la dispute.
L'ancienne voie face à la voie diagnostic-d'abord
Les deux voies ne font pas le même travail dans un ordre différent ; elles prennent des décisions différentes à des niveaux de connaissance différents. Le tableau rend la différence nette :
| Décision | Ancienne voie | Voie diagnostic-d'abord |
|---|---|---|
| Périmètre | Au moment de l'offre, avec le moins d'information | Après la mesure, sur la base des constats |
| Choix du produit | Première question : quelle marque ? | Dernière question : quelle capacité, selon quel critère ? |
| Ordre des phases | Selon le calendrier de livraison de l'éditeur | Selon la dépendance technique |
| Critère de recette | « Nous sommes passés en production » | Scénario écrit + preuve + approbateur nommé |
| Poids du budget | Sur l'installation et le travail mécanique | Sur le diagnostic et la qualité des décisions |
| Porteur du risque | Entièrement le client | Partagé, lié au critère |
Pas un nom de produit — une catégorie de capacité
La conséquence la plus visible de la voie diagnostic-d'abord est le déplacement du choix du produit dans l'ordre. La décision ne se prend pas avec un nom de marque mais avec trois éléments : quelle capacité, selon quel critère, sous quelle condition préalable. « La gestion des nomenclatures » est une catégorie de capacité ; « peut-on conserver un historique de révisions sur une nomenclature multi-niveaux ? » est le critère de cette catégorie ; « les données de référence produit doivent d'abord être dédoublonnées » en est la condition préalable.
Ce triplet produit aussi les questions à poser à l'éditeur — et ces questions deviennent l'ossature du cahier des charges. La question de la marque ne disparaît pas ; elle passe en dernier. Savoir si un produit est le bon choix ne devient une question à laquelle on peut répondre qu'une fois la capacité et le critère écrits. Dans les projets qui procèdent en sens inverse, le cahier des charges finit par être écrit à rebours, à partir de la liste des fonctionnalités du produit déjà choisi.
L'ordre des phases est fixé par les dépendances
Dans la plupart des projets, le plan de phases est négociable : le module ouvert en premier est décidé par l'appétit des départements ou le calendrier de l'éditeur. Dans la voie diagnostic-d'abord, cet ordre est une contrainte technique. Quelques exemples concrets :
- L'exécution de production ne se met pas en place avant que la nomenclature et le flux d'ordres de fabrication fonctionnent — l'exécution consomme le résultat de la nomenclature.
- Le calcul des coûts ne donne pas de résultat pertinent avant que les mouvements de stock soient correctement enregistrés ; le coût est une dérivée du mouvement.
- Le reporting commercial n'est pas fiable avant le dédoublonnage des données de référence clients et produits — les doublons corrompent le rapport en silence.
Lorsque ces dépendances sont violées, le projet ne s'arrête pas ; c'est pire — une phase construite dans le mauvais ordre semble fonctionner, et le problème n'apparaît qu'une fois les données accumulées. Lier l'ordre des phases aux dépendances prévient d'emblée cette défaillance différée.
La recette est liée à la preuve
Le moment le plus coûteux d'un projet est la réunion de transfert : la dispute entre « c'était dans le périmètre » et « c'est un développement supplémentaire » décide de quel côté part la facture. Le seul moyen de devancer cette dispute est de lier la recette à la preuve dès le départ.
En pratique, cela signifie enregistrer le résultat de chaque scénario de recette non seulement en réussite/échec, mais, en cas d'échec, classé par cause — configuration manquante, données manquantes, demande hors périmètre, ou véritable anomalie ? Ces quatre causes facturent quatre parties différentes. À côté figure le nom de la personne qui a approuvé. Sans classification, tous les « échecs » tombent dans un même tas et, à la réunion de transfert, savoir qui a raison devient une affaire de voix la plus forte plutôt que de trace écrite.
Par où commencer ?
La première des cinq étapes est la mesure — et la mesure a elle aussi un point de départ. Pour voir le profil de risque de votre propre projet, vous pouvez utiliser l'évaluation du score de risque ERP en 10 questions : maturité des processus, sponsoring de la direction, conduite du changement, qualité des données, ressources internes, clarté du périmètre, réalisme du budget, appétit de personnalisation, calendrier et expérience de l'équipe — dix dimensions, notées avec leurs pondérations, qui vous placent dans l'une des quatre bandes de risque. Le résultat est une estimation, pas un diagnostic : il vous dit où regarder, pas quoi faire. Mais la première des cinq étapes est franchie.
Ceci est le quatrième et dernier article d'une série de 4.
1. La fin du
conseil au jour-homme est-elle proche ?
2. Une radiographie des
promesses de l'IA
3. Ce
que l'IA a rendu moins cher dans l'ERP — et ce qu'elle a valorisé
4. ERP diagnostic-d'abord : à quoi ressemble la nouvelle voie en pratique ?
(cet article)
Pour ne pas manquer les nouvelles analyses, abonnez-vous à la newsletter MindDX-Digital Excellence.