La plupart des projets ERP n'échouent pas pendant l'implémentation. Ils échouent trois mois après la mise en production.

Il existe un récit confortable de l'échec ERP : le projet s'effondre sous la dérive du périmètre, le budget triple, et tout le monde convient que c'était perdu dès la réunion de lancement. Ce récit existe, mais ce n'est pas le plus courant.

Le plus courant est plus discret. Le système démarre à peu près à l'heure. L'intégrateur anime deux sessions de formation, remet un PDF et facture le dernier jalon. Pendant six semaines, tout semble aller. Puis la responsable réception constate que le flux demande onze clics là où l'ancien tableur en demandait deux : elle recommence à tenir une feuille en parallèle, « juste pour l'instant ». Les achats remarquent que les suggestions de réapprovisionnement sont fausses parce que personne n'a mis à jour les délais, et cessent de les consulter. Au quatrième mois, l'ERP est un endroit coûteux où classer des factures, et l'activité réelle tourne là où elle a toujours tourné.

Personne ne qualifie cela d'échec. Le projet a été livré. Le système est en production. Les chiffres du conseil en sortent même. Mais le gain opérationnel payé n'est jamais arrivé.

Pourquoi la passation est le moment dangereux

Une implémentation ERP se termine exactement au moment où l'organisation commence à comprendre ce dont elle avait réellement besoin. Les besoins recueillis au premier mois étaient une estimation sincère. L'usage réel révèle les manques, et ces manques apparaissent précisément quand les personnes capables de les combler sont passées au client suivant.

La structure d'incitation aggrave la chose. Un intégrateur payé au jalon est payé pour finir. Un intégrateur payé pour faire tourner le système est payé pour le rendre utilisable. Les deux produisent des systèmes différents.

Ce qui l’évite réellement

Trois choses, aucune n’est astucieuse.

Faire tourner l'ancien système en parallèle jusqu'à ce que le nouveau soit démontrablement meilleur. Pas pendant deux semaines décidées à l'avance, mais jusqu'à ce que les utilisateurs cessent d'ouvrir l'ancien. C'est un signal comportemental, plus honnête qu'un formulaire de recette.

Compter les clics sur les cinq tâches les plus fréquentes. Pas celles de la démonstration. Celles que quelqu'un répète quarante fois par jour. Si le nouveau système est plus lent dessus, il perdra, quelle que soit la qualité du reporting.

Nommer une personne, pas une file de tickets. Quelqu'un qui connaît la configuration, répond dans l'heure et sera encore joignable au sixième mois. L'essentiel de ce qui dérape après le démarrage est petit et réparable en une après-midi — à condition qu'il y ait quelqu'un à qui demander.

La partie inconfortable

Cela a une conséquence commerciale. Un intégrateur qui reste pendant la première année d'exploitation ne peut pas porter autant de clients qu'un intégrateur qui livre et s'en va. C'est un modèle moins scalable, et c'est pourquoi il est rare.

Si vous comparez deux propositions, la question à poser aux deux est simple : qui sera réellement dans mon entrepôt la semaine du démarrage, et sera-t-il encore joignable en mars ? Les réponses sont souvent éclairantes.