Un dirigeant nous a posé cette question il y a quelques semaines, après avoir terminé sa sélection : « J’ai un ERP avec les meilleures fonctionnalités. Mais comment cela s’accorde-t-il avec mon activité, et en quoi cela va-t-il me rendre plus performant ? »
La question est juste. Elle arrive seulement trop tard : à ce stade, l’outil est choisi et le budget est posé. Elle aurait dû ouvrir le projet.
La couverture fonctionnelle mesure la mauvaise chose
Les grilles de sélection comparent des fonctionnalités. Elles produisent un taux de couverture, et ce chiffre décide souvent du choix. Or une fonctionnalité qui existe, une fonctionnalité qui est réellement utilisée et une fonctionnalité qui change un résultat sont trois choses différentes. La grille ne mesure que la première.
C’est pour cela qu’un ERP peut afficher une couverture excellente et laisser tous les indicateurs de l’entreprise exactement où ils étaient. Rien n’a échoué. Simplement, personne n’a demandé au système de produire autre chose que des écrans conformes au cahier des charges.
Le projet a un responsable, le résultat n’en a pas
Un projet ERP est très bien équipé pour réussir en tant que projet. Il a un périmètre, un budget, une date de bascule, un comité de pilotage, un sponsor. Chacun de ces éléments a un propriétaire identifié.
Le résultat attendu, lui, n’en a généralement aucun. Réduire le délai de clôture comptable, diminuer les erreurs de saisie sur les commandes, raccourcir le cycle de devis : ces objectifs figurent parfois dans la note de cadrage, rarement dans la gouvernance du projet. Personne n’en répond au même titre qu’on répond d’un budget.
La conséquence est mécanique. Un projet peut tenir ses délais, respecter son enveloppe, livrer l’intégralité de son périmètre — et ne rien changer de mesurable. Ce n’est la faute de personne. La structure n’a jamais posé la question.
Les processus se décident par défaut quand personne ne les décide
Un ERP porte une manière de travailler. Si l’entreprise ne définit pas ses processus cibles, le standard de l’éditeur les impose.
Ce n’est pas un défaut : adopter le standard est souvent la meilleure décision, et c’est ce que nous recommandons dans la plupart des cas. Mais ce doit être une décision. Quand elle n’est pas prise, on la découvre après la bascule — un contrôle qui existait a disparu, une boucle de validation a été inventée par le paramétrage, une règle de gestion que personne n’avait écrite s’applique désormais à tout le monde.
L’arbitrage entre standard et développement spécifique relève de la même logique, et il se joue au même moment : nous l’avons détaillé dans ERP standard ou spécifique.
Sans mesure avant, aucune preuve après
La plupart des projets ERP sont incapables de répondre à la question « est-ce que cela a servi ? ». Non parce que le résultat serait mauvais, mais parce qu’aucun point de départ n’a été relevé.
La mesure doit être prise avant, sur un petit nombre d’indicateurs que l’entreprise reconnaît déjà. Un indicateur créé pour les besoins du projet ne convainc personne et ne survit pas à la bascule. Un indicateur que le métier suivait déjà, et qui bouge, se passe de commentaire.
Les questions à trancher avant de choisir un outil
Quatre questions, dans cet ordre. Aucune ne porte sur une fonctionnalité.
- Qu’est-ce qui doit être différent dans six mois, et pour qui ? Formulé en termes d’activité, pas de module. « Les commerciaux produisent un devis sans rappeler la production » est un objectif. « Déployer le module CPQ » n’en est pas un.
- Comment le saurons-nous ? Un indicateur existant, relevé avant le démarrage, avec sa valeur actuelle.
- Qui, dans le métier, en répond ? Pas le chef de projet, qui répond du projet. Quelqu’un dont le quotidien change si le résultat n’est pas atteint.
- Quel processus accepte-t-on de faire évoluer, et lequel ne se négocie pas ? La réponse détermine le volume de spécifique, donc le coût de possession sur cinq ans.
Ces questions ne sont pas informatiques. Elles se tranchent avec la direction générale et les responsables métier, et elles conditionnent tout ce qui suit — y compris le choix de l’outil, qui en découle au lieu de le précéder.
Ce qu’un ERP fait réellement
Un ERP ne produit pas de la performance. Il retire des obstacles qui l’empêchaient : une information qu’il fallait ressaisir, un contrôle qui arrivait trop tard, un délai qui venait d’une attente et non d’un traitement.
Encore faut-il avoir nommé ces obstacles. C’est le travail de cadrage, et c’est la partie du projet qui ne s’achète pas avec la licence.
