Pourquoi un projet ERP échoue, et comment l’éviter

Un ERP mal lancé laisse des traces : un budget dépassé, des équipes qui ressaisissent dans l’ancien outil « au cas où », une direction qui ne croit plus les chiffres. Le logiciel est rarement en cause. Les mêmes six causes reviennent, et chacune se prévient dès le cadrage.

1. Le périmètre qui grossit

Chaque atelier ajoute une demande : un rapport de plus, un cas particulier, un module « tant qu’on y est ». Prises une à une, elles semblent raisonnables. Ensemble, elles doublent la durée. La parade est une liste écrite de ce qui est hors du premier lot, dans le cahier des charges, et un lot suivant où ranger les bonnes idées.

2. Les données importées telles quelles

Clients en double, articles sans unité, fournisseurs avec trois orthographes : importer ces données dans un ERP les rend visibles à tout le monde, et les erreurs se propagent aux factures. Il faut nettoyer avant, et tester l’import sur une copie jusqu’à ce qu’il passe sans retouche. La méthode est dans Reprendre ses données dans un ERP.

3. La personnalisation qui bloque les mises à jour

Recréer dans l’ERP chaque habitude de l’ancien outil mène à des dizaines de développements spécifiques. Chacun doit être repris à chaque nouvelle version. Au bout de deux ans, l’entreprise reste bloquée sur une version ancienne parce que la migration coûte trop cher. Notre règle : d’abord adapter le processus au standard, ensuite paramétrer, et seulement en dernier développer. Voir Personnaliser un ERP sans se piéger.

4. Les tableurs qui survivent

Si l’ancien tableur reste ouvert, il redevient la référence au premier doute. Les équipes ne sont pas de mauvaise volonté : elles ont confiance dans ce qu’elles connaissent. La parade tient en deux gestes, une formation par rôle sur des cas réels, et une date à laquelle l’ancien outil passe en lecture seule. Voir Former les équipes à un ERP.

5. Le pilotage sans décideur

Un ERP touche tous les services, et chaque service a ses priorités. Sans une personne qui tranche, chaque désaccord devient une réunion de plus. Il faut un responsable de projet côté entreprise, avec le pouvoir de décider, et une règle : toute question ouverte reçoit une réponse en une semaine.

6. La bascule d’un bloc

Tout ouvrir le même lundi concentre les risques : si la facturation bloque, tout bloque. Ouvrir par lots (les ventes et la facturation d’abord, puis les achats, puis les stocks) laisse le temps de corriger. Chaque lot se juge sur les scénarios d’acceptation avant d’ouvrir le suivant.

1. 01Lot 1

   Ventes et facturation, sur des données nettoyées.

2. 02Lot 2

   Achats et fournisseurs.

3. 03Lot 3

   Stocks et logistique, après un inventaire.

4. 04Lot 4

   Tableaux de bord et automatisations.

Ce que disent les retours d’expérience

Les études sur les projets informatiques convergent sur ce point : la plupart des dépassements viennent du périmètre et de l’organisation plutôt que de la technique. Le rapport de McKinsey sur les grands projets informatiques en donne une mesure : il porte sur des projets bien plus grands que la plupart des ERP de PME, mais les causes qu’il décrit sont les mêmes.

La parade commune

Ces six causes ont un point commun : elles se préviennent au cadrage, pas en cours de projet. Un périmètre écrit avec son hors périmètre, une reprise des données planifiée, une règle de personnalisation, un plan de formation par rôle, un décideur nommé et une bascule par lots tiennent sur quelques pages. le guide complet de l’ERP les reprend étape par étape. C’est aussi la méthode de notre offre CRM et ERP : un prix fixe sur un périmètre écrit, des lots validés un par un, et des points de suivi à 30 puis à 90 jours pour vérifier que le projet a tenu ce qu’il promettait.

Questions fréquentes

Sources

1. Delivering large-scale IT projects on time, on budget, and on value, McKinsey (nouvel onglet)mckinsey.com