Il y a une question qui me laisse toujours perplexe : comment peut-on encore rater des projets ERP aujourd’hui ?
Cela fait des décennies que les entreprises déploient des ERP. Les méthodes existent. Les retours d’expérience existent. Les erreurs classiques sont connues. On sait ce qui dérape, ce qui bloque, ce qui coûte trop cher, ce qui démotive les utilisateurs, ce qui finit en contournement Excel trois mois après le go-live.
Et pourtant, ça continue. On lance encore des programmes ERP comme si la réussite dépendait d’abord du choix de l’outil. On compare des solutions, on regarde des fonctionnalités, on organise des comités, on parle reporting, budget, planning, intégrateur, licences. Tout cela est nécessaire, bien sûr. Mais ce n’est presque jamais là que se joue l’essentiel.
La mise en place d’un ERP n’est ni un projet informatique, ni un projet Finance.
En faire un sujet technique, ou pire, un sujet financier est une première erreur. Parce que l’ERP produit des chiffres, parce qu’il alimente le reporting, parce qu’il structure la donnée comptable, on imagine parfois qu’il doit être porté par la finance. C’est une erreur. Un ERP ne sert pas seulement à produire des états financiers. Il touche les ventes, les achats, la production, la logistique, les stocks, la qualité, la maintenance, les approvisionnements, les clients, les fournisseurs, les équipes terrain.
Un projet ERP est donc un vrai projet d’entreprise car il touche la manière dont l’entreprise travaille. Quand un projet ERP est pensé d’abord comme un outil de reporting, il y a de fortes chances que les utilisateurs le vivent comme une contrainte. On leur demande de saisir mieux, plus vite, plus proprement, mais ils ne voient pas toujours ce qu’ils y gagnent. Ils entendent parler de consolidation, de tableaux de bord, de contrôles, de clôtures plus rapides. Très bien. Mais eux, dans leur quotidien, que gagne-t-ils ? Moins de double saisie ? Moins d’erreurs ? Des stocks plus fiables ? Des commandes mieux suivies ? Des arbitrages plus simples ? Des décisions plus rapides ? Si cette réponse n’est pas claire, le projet est déjà mal engagé .
La deuxième erreur est de sous-estimer la conduite du changement. On parle souvent de formation, mais la formation ne suffit pas. Former quelqu’un à cliquer au bon endroit dans un outil ne veut pas dire qu’il a compris pourquoi son métier change. Ce qu’il faut, c’est s’assurer que la description des processus est validée et comprise par tous , c’est l’appropriation de la traduction de ces processus en procédures dans l’outil, de la présence terrain. Des explications simples. Des relais métiers crédibles. Des moments où l’on accepte d’écouter ce qui ne marche pas, ce qui inquiète, ce qui paraît absurde, ce qui va créer du travail en plus si personne ne corrige le processus. Un ERP ne se déploie pas contre les métiers, il se construit avec eux.
La troisième erreur, c’est de croire que l’on va résoudre grâce à l’outil des problèmes que l’organisation n’a jamais voulu traiter. Un ERP ne rend pas magiquement clairs des processus flous. Il ne réconcilie pas tout seul des équipes qui ne se parlent pas. Il ne corrige pas une donnée mal gouvernée. Il ne décide pas à la place de l’entreprise qui est responsable de quoi. Il ne tranche pas les désaccords entre sites, entre pays, entre directions ou entre habitudes locales. Au contraire, il les révèle.
C’est souvent là que le projet devient inconfortable. On découvre que chacun a sa manière de faire. Que les fichiers Excel ne sont pas seulement des outils de confort, mais parfois des systèmes parallèles entiers. Que certaines exceptions sont devenues la règle. Que personne ne sait vraiment qui valide quoi. Que la donnée client, article, fournisseur ou stock n’a pas la même définition selon les équipes.
Et là, il faut du courage managérial : pas seulement un comité projet ou une gouvernance affichée dans un PowerPoint. Une vraie gouvernance. Des décisions prises au bon niveau, des arbitrages assumés, des sponsors qui ne disparaissent pas dès que le projet devient impopulaire. Des directions métiers qui acceptent de remettre en cause leurs pratiques. Une DSI qui ne se contente pas d’intégrer une solution, mais qui aide l’entreprise à poser les bonnes questions.
La difficulté, dans un ERP, n’est généralement pas la technique. La technique compte, évidemment. Il faut choisir une solution adaptée, sécuriser les interfaces, migrer les données, tester, reprendre l’historique, construire les rôles, gérer les habilitations, organiser le support. Mais la technique, on sait faire. On trouve des compétences, des intégrateurs, des experts. Ce qui est beaucoup plus rare, c’est la capacité collective à regarder l’organisation en face.
Un projet ERP réussi commence donc bien avant le paramétrage. Il commence par des questions simples, mais exigeantes :
- Quels problèmes voulons-nous vraiment résoudre ?
- Quels processus sommes-nous prêts à harmoniser ?
- Quelles exceptions acceptons-nous de supprimer ?
- Qui est propriétaire de la donnée ?
- Quels irritants métiers devons-nous traiter en priorité ?
- Qu’est-ce qui fera dire aux utilisateurs : “oui, c’est mieux qu’avant” ?
- Quels arbitrages le comité de direction est-il prêt à assumer ?
Sans ces réponses, on peut avoir le meilleur outil du marché et échouer quand même.
Ce qui m’étonne, ce n’est pas qu’un projet ERP soit difficile. Bien sûr que c’est difficile. Ce qui m’étonne, c’est que certaines erreurs se répètent encore alors qu’elles sont connues depuis longtemps. Comme si l’on recommençait à chaque fois depuis zéro. Comme si l’expérience collective n’avait pas infusé. Comme si l’on continuait à traiter ces programmes comme des projets de déploiement, alors qu’ils sont des projets de transformation.
Un ERP ne se plante pas le jour du go-live, mais trop souvent bien avant : quand le sponsor n’est pas clair, quand les métiers ne sont pas embarqués, quand la donnée est négligée, quand la finance confisque le sujet, quand la DSI est cantonnée à l’exécution, quand on évite les vrais arbitrages, quand on forme trop tard, quand on écoute trop peu, quand on préfère tenir un planning plutôt que traiter une résistance légitime.
Le go-live ne fait que révéler ce que le projet portait déjà. Alors oui, il faut des méthodes. Oui, il faut de la rigueur. Oui, il faut des plannings, des budgets, des tests, des comités, des indicateurs. Mais il faut surtout accepter qu’un ERP est une opération à cœur ouvert sur l’organisation.
Et dans une opération à cœur ouvert, on ne confie pas le sujet à une seule fonction. On ne le réduit pas à un logiciel. On ne se dit pas que l’utilisateur final comprendra plus tard. On ne reporte pas les décisions difficiles à après le démarrage.
On prend les décisions avant. C’est peut-être cela, finalement, la vraie maturité ERP : ne plus croire que l’outil transformera l’entreprise à notre place.
