Un projet ERP ne devrait pas commencer par le choix d’un ERP.
« Notre ERP arrive en fin de support. Il faut qu’on le change. »
« Notre logiciel vieillit. C’est peut-être le moment de regarder ce qui existe de plus moderne. »
« Les équipes se plaignent. Il faut passer à autre chose. »
Toutes ces raisons peuvent être légitimes.
Mais aucune ne dit encore ce que devrait être le futur ERP de l’entreprise.
Pourtant, c’est souvent à ce moment que commence la consultation du marché : éditeurs, démonstrations, fonctionnalités, tarifs…
Alors que quelques questions devraient probablement être posées avant.
1. Pourquoi voulons-nous changer ?
Un ERP vieillissant n’est pas nécessairement un mauvais ERP.
Il peut parfaitement répondre aux besoins de l’entreprise alors que sa version arrive en fin de support. À l’inverse, un logiciel récent peut générer des ressaisies, mal communiquer avec les autres applications ou limiter certains processus.
Il faut donc commencer par objectiver les limites de l’existant :
- Quels usages ne pouvons-nous pas correctement adresser ?
- Qu’aimerions-nous pouvoir faire demain ?
- Ces limites nous font-elles perdre du temps ou de l’argent ?
- Peut-on l’estimer, même très approximativement ?
La question derrière toutes les autres est finalement simple :
quelle valeur supplémentaire attendons-nous du changement ?
Une solution plus moderne et beaucoup plus chère n’est pas nécessairement une meilleure décision.
2. Qu’est-ce que nous ne voulons surtout pas perdre ?
Lorsqu’une entreprise envisage un nouvel ERP, elle sait généralement très bien expliquer ce qui lui manque.
Beaucoup moins ce qui fonctionne bien aujourd’hui.
Or, après plusieurs années d’utilisation, certains usages et processus sont parfaitement maîtrisés. Un nouvel ERP peut apporter des progrès tout en créant des régressions.
Toutes ne sont d’ailleurs pas forcément inacceptables.
Une fonctionnalité peut être dégradée si la nouvelle solution apporte beaucoup plus de valeur ailleurs.
L’essentiel est de l’identifier et de l’arbitrer avant de la subir.
3. Qu’attendons-nous réellement du futur ERP ?
Un cahier des charges peut rapidement devenir une longue liste de fonctionnalités.
Mais toutes n’ont ni la même importance, ni la même valeur.
Pour les besoins prioritaires, il faut aller plus loin :
À quel processus répondent-ils ? À quel usage ? Quel problème cherchent-ils à résoudre ? Quel gain en attendons-nous ?
Tout n’a pas besoin d’être traduit en ROI précis.
Mais supprimer une double saisie, économiser plusieurs heures chaque semaine ou fiabiliser une donnée essentielle constitue déjà une manière d’objectiver la valeur.
Avant de comparer ce que savent faire les ERP, il faut savoir ce que l’entreprise veut mieux faire grâce à son ERP.
4. Que voulons-nous profiter du projet pour transformer ?
Changer d’ERP impose presque nécessairement certains ajustements de processus : chaque solution embarque une partie de son propre modèle.
Deux écueils apparaissent alors.
Reproduire exactement l’existant dans le nouvel outil, au risque de changer de technologie sans améliorer les pratiques.
Ou, à l’inverse, profiter du projet pour tout transformer, en cumulant changement d’outil, de processus et d’habitudes.
L’enjeu consiste plutôt à identifier les processus qu’il est pertinent d’améliorer à cette occasion et ceux pour lesquels le standard du futur ERP est suffisamment satisfaisant.
C’est cette réflexion qui doit alimenter le cahier des charges — et non l’inverse.
5. Qui pilote réellement le projet ?
L’éditeur connaît son produit.
L’intégrateur connaît son déploiement.
L’IT maîtrise l’écosystème technique.
Les métiers connaissent leurs processus.
Tous sont indispensables. Mais le projet ERP reste d’abord un projet métier.
Il lui faut un pilote disposant d’une légitimité métier suffisante tout en étant capable de dialoguer avec l’IT, l’éditeur et l’intégrateur.
Ce profil peut être accompagné par un intervenant externe si l’entreprise ne dispose pas de cette compétence.
Mais l’entreprise doit rester propriétaire de ses décisions.
L’éditeur ou l’intégrateur peuvent accompagner la transformation. Ils ne doivent pas la piloter à la place de l’entreprise.
6. Comment saurons-nous que le projet a réussi ?
Cette question devrait être posée avant le projet, pas 18 mois après.
Avons-nous supprimé les ressaisies que nous voulions supprimer ?
Gagnons-nous réellement du temps ?
Les données sont-elles plus fiables ?
Pilotons-nous mieux l’activité ?
Les processus ciblés ont-ils progressé ?
Si les raisons du changement ont été clairement posées au départ, il devient beaucoup plus facile d’évaluer ensuite si le projet a tenu ses promesses.
Car la réussite ne se mesure pas seulement au fait que le nouvel ERP soit en production.
Elle se mesure à la valeur qu’il devait produire.
Le logiciel vient ensuite
Il faut évidemment comparer les solutions, rencontrer les éditeurs, assister aux démonstrations et évaluer les coûts.
Mais probablement plus tard qu’on ne l’imagine.
Avant cela, une entreprise devrait savoir :
Pourquoi elle veut changer.
Ce qu’elle veut préserver.
Ce qu’elle veut améliorer.
Ce qu’elle accepte de transformer.
Et comment elle mesurera la valeur obtenue.
La bonne décision pourra alors être de changer d’ERP, de rester chez le même éditeur, de simplement changer de version… ou même de différer le projet.
Un projet ERP ne devrait pas commencer par le choix d’un ERP.
Il devrait commencer par une compréhension claire de ce que l’entreprise veut préserver, améliorer et transformer.
Le logiciel vient ensuite.