Trois erreurs qui font dériver un projet ERP
Un projet ERP qui dérape le fait rarement pour des raisons techniques. Dans nos diagnostics en PME et ETI, les mêmes causes reviennent, et elles se jouent toutes avant la première ligne de paramétrage.
This article is available in French only.
Nous intervenons régulièrement sur des projets ERP en difficulté : budget dépassé, délais glissants, utilisateurs qui contournent l'outil. Quand nous reconstituons l'historique, le point de bascule se situe presque toujours en amont du déploiement. Trois erreurs expliquent l'essentiel de ces situations.
Croire que l'outil porte l'organisation
C'est l'erreur la plus coûteuse. Une entreprise dont les processus sont flous choisit un ERP en espérant que le logiciel imposera la rigueur qui manque. L'inverse se produit : l'outil révèle le flou et le fige.
Un ERP encode des règles. Si les règles ne sont pas décidées avant, elles seront décidées par défaut, au fil du paramétrage, par la personne qui configure l'écran. Personne n'a arbitré, et pourtant l'organisation est arbitrée.
La complexité n'est jamais dans l'outil, elle est dans les personnes et les processus.
Le travail de cartographie des processus n'est pas une formalité préalable au projet : c'est le projet. Le paramétrage n'en est que la traduction.
Confondre expression de besoin et liste de fonctionnalités
Beaucoup de cahiers des charges que nous relisons sont en réalité des inventaires : une longue liste de fonctions attendues, souvent recopiée d'une documentation éditeur. Ces documents sont difficiles à exploiter, pour une raison simple : ils n'expriment aucune priorité et aucun critère d'acceptation.
Un besoin bien formulé décrit une situation de travail, pas un bouton. « L'acheteur doit pouvoir comparer trois offres fournisseurs sur un même écran avant de valider » est actionnable. « Module achats complet » ne l'est pas.
Conséquence pratique : sans critère d'acceptation, la recette fonctionnelle devient une négociation. Chacun défend sa lecture du document, et le prestataire a généralement la meilleure mémoire des termes exacts.
Sous-estimer la charge côté client
Les devis d'intégrateurs chiffrent les jours du prestataire. Ils ne chiffrent jamais les jours des équipes internes, qui sont pourtant du même ordre de grandeur.
Ce que le projet demande aux équipes en place :
- Fiabiliser et reprendre les données existantes, tâche systématiquement sous-estimée
- Participer aux ateliers de conception, qui mobilisent les personnes les plus occupées de l'entreprise
- Tester, formaliser les anomalies, retester
- Se former, puis former les autres
- Maintenir l'activité courante pendant tout ce temps
Quand cette charge n'est pas planifiée, elle est absorbée en heures supplémentaires jusqu'au point de rupture, puis le projet ralentit sans que personne ne l'ait décidé.
Ce qui change quand le cadrage est fait
Un cadrage sérieux ne garantit pas l'absence de difficulté, mais il déplace la difficulté au bon endroit : avant l'engagement budgétaire, quand les arbitrages coûtent encore peu.
- Les processus cibles sont décidés par l'entreprise, pas par le paramétrage
- Le besoin est exprimé en critères vérifiables, ce qui rend la recette objective
- La charge interne est identifiée et planifiée, donc arbitrable
C'est l'objet de nos missions de cadrage et d'AMOA : produire ces trois éléments avant que le projet ne s'engage, et rester présents pour que ce qui est livré corresponde à ce qui a été demandé.
Un projet ERP en préparation, ou déjà en difficulté ? Nous proposons un diagnostic court pour situer les risques.