Si l'on demande quel est le taux d'échec des implémentations ERP, la réponse se situe entre 10 % et 84 %, selon la personne à qui l'on s'adresse. Cet écart n'est pas dû à une imprécision des mesures. Il s'agit de douze études ayant utilisé cinq critères d'évaluation incompatibles entre eux, mais qui qualifient toutes le résultat d'« échec ». J’ai passé une journée à consulter toutes les sources auxquelles j’ai pu accéder, y compris les documents déposés auprès de la SEC par les entreprises à l’origine de ces célèbres désastres. Voici ce que chaque chiffre mesure réellement.
Les chiffres et ce qui se cache derrière chacun d’entre eux
| Étude | Taux d’échec ou de dépassement déclaré | Définition du terme « échec » utilisée | Échantillon | Source | Année |
|---|---|---|---|---|---|
| Rapport Standish CHAOS | 16,2 % de réussite, 52,7 % de projets en difficulté, 31,1 % d’annulations. Les projets « problématiques » coûtent 189 % de l’estimation initiale | Succès = respect des délais, du budget et de toutes les fonctionnalités initialement spécifiées. Tout autre cas est considéré comme problématique ou compromis | 365 répondants représentant 8 380 applications, États-Unis | Standish Group, Rapport CHAOS | 1994 |
| Eveleens & Verhoef, reproduction de la méthode Standish | Les définitions de Standish ont été jugées « trompeuses, partiales » et produisant des « chiffres dénués de sens » | Remise en question de la définition elle-même : un projet respectant le budget et offrant plus de fonctionnalités que prévu est considéré comme un échec selon les règles de Standish | 5 457 prévisions portant sur 1 211 projets réels | IEEE Software, Vrije Universiteit Amsterdam | 2010 |
| Rapport ERP de Panorama Consulting, auto-évaluation | 60 % qualifient le projet de succès, 30 % sont neutres ou ne savent pas, 10 % le qualifient d’échec | C’est le répondant qui choisit la qualification. Aucun critère budgétaire ou de calendrier n’est appliqué | 172 personnes interrogées sur le site web de Panorama, de septembre 2012 à janvier 2013 | Panorama Consulting, Rapport ERP 2013 | 2013 |
| Rapport ERP de Panorama Consulting, budget et calendrier | 53 % ont dépassé le budget, 61 % ont pris du retard | Coût ou durée réels supérieurs aux prévisions | Les mêmes 172 répondants | Panorama Consulting, Rapport ERP 2013 | 2013 |
| Rapport ERP de Panorama Consulting | Plus de la moitié ont respecté leur budget prévisionnel ; plus de la moitié ont respecté leur calendrier prévisionnel | Respect déclaré des attentes propres à l’organisation | 131 personnes interrogées, août 2022 à décembre 2023, coût médian de 450 000 $, durée médiane de 15,5 mois | Panorama Consulting, Rapport ERP 2024 | 2024 |
| McKinsey et Université d’Oxford | 45 % de dépassement budgétaire, 7 % de dépassement de délai, 56 % de valeur inférieure aux prévisions | Écart sur trois plans par rapport à l’analyse de rentabilité, limité aux projets dont le coût initial était supérieur à 15 millions de dollars | Plus de 5 400 projets informatiques en juin 2012 ; dépassement de coût total de 66 milliards de dollars | Bloch, Blumberg & Laartz, McKinsey Digital | 2012 |
| Flyvbjerg, Budzier, Lee, Keil, Lunn & Bester, sous-ensemble ERP | Ratio moyen de dépassement de coût : 1,3 ; médiane : 0,9 ; maximum : 79,8 | Coût réel divisé par le coût estimé. Une valeur inférieure à 1,0 signifie que le budget n'a pas été dépassé | 1 612 projets ERP parmi 5 392 projets informatiques achevés entre 2002 et 2014, pour un total de 56,5 milliards de dollars | Journal of Management Information Systems 39(3) | 2022 |
| « 55 à 75 % des projets ERP ne parviennent pas à atteindre leurs objectifs » | 55 à 75 % | Non défini | Non divulgué | Attribué à Gartner sur des dizaines de pages de fournisseurs ; source primaire introuvable | sans date |
| Hershey Foods, perturbation du traitement des commandes au 3e trimestre | Chiffre d’affaires net en baisse de 12 %, passant de 1 217,2 millions de dollars à 1 066,7 millions de dollars en glissement annuel | Impact financier déclaré, et non un taux d’échec | Une entreprise, un trimestre | Formulaire 10-Q déposé auprès de la SEC, le 12 novembre 1999 | 1999 |
| Nike, planification de la demande et de l’offre avec i2 | Révision à la baisse des prévisions pour le 3e trimestre de l’exercice 2001, de 0,50–0,55 $ à 0,34–0,38 $ par action | Impact sur les bénéfices déclaré | Une entreprise, un trimestre | Formulaire 8-K déposé auprès de la SEC, 27 février 2001 | 2001 |
| Revlon, mise en service du système SAP à Oxford, en Caroline du Nord | Baisse du chiffre d’affaires net d’environ 50 millions de dollars au cours des six premiers mois | Impact sur le chiffre d’affaires publié | Une entreprise, un semestre | Formulaire 10-Q déposé auprès de la SEC, 2e trimestre 2018 | 2018 |
| Lidl, programme SAP | 500 millions d’euros dépensés, programme abandonné après sept ans | Annulation avant le déploiement complet | Une entreprise, 10 000 magasins concernés | The Register, 12 décembre 2019 | 2018 |
Cinq études, cinq significations d’un même mot
Selon Standish, 16,2 % des projets ont été couronnés de succès en 1994. Il suffit de lire la définition pour que ce chiffre prenne une autre signification. Une réussite de type 1 signifie : respect des délais, du budget et de toutes les fonctionnalités spécifiées. Si vous livrez un système avec trois semaines de retard, mais que tout le monde finit par l’utiliser avec satisfaction, vous vous retrouvez dans la catégorie « en difficulté », ce qui est rapporté en aval comme un échec. Ainsi, 83,8 % ont échoué à un test de précision des estimations, et non à un test de bon fonctionnement du logiciel.
Eveleens et Verhoef ont vérifié ces chiffres. Ils ont appliqué les définitions de Standish à leurs propres données – 5 457 prévisions portant sur 1 211 projets réels – et ont publié leurs résultats dans IEEE Software en 2010. Leur verdict : trompeur, partial, dénué de sens. Ce sont leurs propres mots. Un projet qui respecte le budget tout en offrant plus de fonctionnalités que promis est considéré comme un échec selon les règles de Standish, car les rapports prévisions/réalités indiquent une tendance erronée. Si vous vous fiez à cela, vous incitez votre PMO à gonfler les estimations.
Panorama pose une question d’un tout autre ordre. En 2013, sur 172 personnes interrogées, 86 % se sont déclarées satisfaites du logiciel, 60 % ont qualifié le projet de succès, 10 % l’ont qualifié d’échec. L’échec signifie ici que quelqu’un a coché la case « échec ». Même rapport, même échantillon : 53 % ont dépassé leur budget, 61 % ont pris du retard. Trois chiffres, un même groupe de personnes, qui se contredisent. En 2024, la même entreprise indique que la plupart de ses 131 répondants ont respecté à la fois le budget et le calendrier. Les deux cohortes ont rempli un formulaire sur le site web d’un cabinet de conseil, ce qui n’est pas négligeable, mais ce n’est pas un recensement.
Puis vint l’article qui a bouleversé ma réflexion. Flyvbjerg et ses collègues, 2022, Journal of Management Information Systems : 5 392 projets informatiques, dont 1 612 projets ERP. Taux moyen de dépassement de budget pour le sous-ensemble des projets ERP : 1,3. Médiane : 0,9. Le projet ERP type, dans le plus grand échantillon constitué, s’est avéré inférieur au budget. La moyenne est tirée vers le haut par une queue atteignant 79,8, un projet qui a coûté quatre-vingts fois son estimation. Les auteurs affirment que la moyenne ne peut pas du tout être calculée, car la queue présente une variance infinie, et que les dépassements et les sous-utilisations sont tout aussi fréquents.
Quant au chiffre de Gartner que tout le monde cite, je suis parti à la recherche de la source originale. La page dédiée à l’ERP sur le site de Gartner présente des affirmations différentes, et toutes les pistes de citation aboutissaient à un blog de fournisseur citant un autre blog de fournisseur. Ce chiffre figure dans le tableau avec la mention « sans source ».
Ce qu’ont déclaré les entreprises dans leurs propres documents financiers
Pour les cas célèbres, j’ai consulté les documents financiers eux-mêmes plutôt que les récits qui en sont tirés. Hershey attribue la baisse de 12 % de son chiffre d’affaires à « des problèmes dans l’exécution des commandes (service client, entreposage et expédition) rencontrés depuis la mise en service, en juillet, d’un nouveau système d’information intégré ». Philip Knight évoque « des complications découlant de l’impact de la mise en œuvre de nos nouveaux systèmes de planification de la demande et de l’offre ». Revlon fait état d’une « baisse du chiffre d’affaires net d’environ 50 millions de dollars ».
Il convient de noter ce qui n’y figure pas. Les chiffres que tout le monde répète à propos de Hershey – 100 millions de dollars de commandes non honorées et un coût de projet de 112 millions de dollars – n’apparaissent nulle part dans le formulaire 10-Q, et je n’ai trouvé aucune source primaire pour l’un ou l’autre. Aucune des trois entreprises ne fait état d’un taux d’échec, car ce n’est pas un indicateur qu’une entreprise mesure pour elle-même.
Un entrepôt en octobre
Un distributeur de taille moyenne avec lequel j’ai travaillé a mis en service un nouvel ERP en mars. Dès le vendredi de la semaine de mise en service : aucun incident bloquant, les commandes circulaient, la paie avait été versée. L’intégrateur a clôturé le projet. Dans toutes les études citées ci-dessus, cela constitue un succès. Selon Standish, peut-être un « Type 1 ».
Je suis retourné sur place en octobre pour une autre raison. L’équipe de réception scannait les palettes entrantes dans le système, puis notait la même ligne sur une feuille fixée au bloc-notes épinglé près de la porte du quai. Le superviseur m’a expliqué que la suggestion de mise en stock les envoyait vers un emplacement souvent déjà plein ; ils notaient donc sur papier l’emplacement réel de la palette et corrigeaient cela plus tard, lorsqu’ils en avaient le temps. Or, ils n’en avaient généralement pas le temps. La précision des stocks dans cette zone s’était dégradée depuis juin et personne en amont n’en savait rien, car le système indiquait que tout était correct.
Autre étage, même entreprise : une acheteuse avait repensé sa logique de réapprovisionnement dans un tableur, car le champ « quantité minimale de commande » de l’ERP ne pouvait pas gérer les remises accordées par un fournisseur. Sa feuille de calcul était plus performante que le système et restait stockée, sans sauvegarde, sur son ordinateur portable.
Aucun de ces deux cas n’apparaît comme un dépassement ou un écart. Le projet a été mené dans les délais et dans les limites du budget.
En quoi je ne partage pas l’interprétation courante
La conclusion habituelle : les projets ERP échouent parce qu’ils sont trop ambitieux ; il faut donc les décomposer en phases, les piloter plus rigoureusement et faire appel à des spécialistes de la gestion du changement.
Je n’y crois pas, et pas par simple esprit de contradiction. Regardez ce que mesure chaque étude. Standish : la précision des estimations. Panorama : un sentiment au moment de l’enquête, ou le respect du budget, selon la page. McKinsey : l’écart par rapport à l’analyse de rentabilité. Flyvbjerg : un ratio de coûts. Les rapports financiers : un quart du chiffre d’affaires. Cinq indicateurs pointant vers cinq aspects différents, mais un point les unit : aucun ne mesure si les utilisateurs exploitent réellement le système.
Toute la valeur d’un ERP réside dans le fait que les données qu’il contient reflètent l’activité de l’entreprise. Un projet livré dans les délais, dans les limites du budget, avec une portée complète, et dont les chiffres d’affaires sont discrètement erronés à partir du quatrième mois, est considéré comme un succès dans toutes les études ci-dessus. Le bloc-notes posé près de la porte du quai leur échappe à tous.
Ce qui signifie que les faibles taux d’échec sont tout aussi suspects que les taux élevés. Un projet en dessous du budget et inutilisé reste un échec.
Si je pouvais remplacer ce tableau par un seul indicateur : six mois après la mise en service, quelle proportion d’utilisateurs ciblés effectue la tâche visée dans le système, sans recourir à un fichier parallèle ? Personne ne publie ce chiffre, sans doute parce qu’il serait catastrophique et parce que cela implique d’effectuer la mesure après le départ des consultants.
FAQ
Quel est le véritable taux d’échec des implémentations ERP ?
Il n’y en a pas un seul, car la notion d’« échec » a une signification différente dans chaque étude. La définition de Standish de 1994 classe 83,8 % des projets comme des échecs. Le chiffre déclaré par Panorama en 2013 est de 10 %. L’échantillon de 1 612 projets ERP analysé par Flyvbjerg en 2022 présente un ratio médian de dépassement de coûts de 0,9, ce qui signifie que le projet type est resté en deçà du budget. Ces trois chiffres sont tous défendables ; ils mesurent des choses différentes.
L'échec du projet ERP de Hershey a-t-il réellement coûté 100 millions de dollars en commandes non honorées ?
Le formulaire 10-Q du troisième trimestre 1999 de Hershey fait état d’une baisse de 12 % du chiffre d’affaires net et l’attribue à des problèmes d’exécution des commandes après la mise en service du nouveau système en juillet. Le chiffre de 100 millions de dollars circule largement, mais je n’ai pas pu le retracer jusqu’à une source primaire.
Existe-t-il des exemples de réussite en matière d’ERP étayés par des chiffres ?
Il est rare que des chiffres soient publiés. Les entreprises publient des informations lorsque le déploiement d'un système affecte leurs résultats, et non lorsque tout se passe bien ; les données publiques sont donc biaisées en faveur des échecs. Ce qui se rapproche le plus d'un ensemble de données positives est le sous-ensemble ERP 2022 de Flyvbjerg, dans lequel environ la moitié des projets ont coûté le montant estimé ou moins.
Sources
- Standish Group, The CHAOS Report, 1994 — https://personal.utdallas.edu/~chung/SYSM6309/chaos_report.pdf
- J. Laurenz Eveleens & Chris Verhoef, The Rise and Fall of the Chaos Report Figures, IEEE Software, 2010 — https://www.cs.vu.nl/~x/chaos/chaos.pdf
- Panorama Consulting Solutions, Rapport ERP 2013 — https://web.archive.org/web/20130228102235if_/http://panorama-consulting.com:80/Documents/2013-ERP-Report.pdf
- Panorama Consulting Group, Rapport ERP 2024 — https://4439340.fs1.hubspotusercontent-na1.net/hubfs/4439340/Reports/ERP%20Report/2024-erp-report-panorama-consulting-group.pdf
- Michael Bloch, Sven Blumberg et Jürgen Laartz, Réaliser des projets informatiques à grande échelle dans le respect des délais, du budget et de la valeur ajoutée, McKinsey et Université d’Oxford, 1er octobre 2012 — http://web.archive.org/web/20251013095742/https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
- Bent Flyvbjerg, Alexander Budzier, Jong Seok Lee, Mark Keil, Daniel Lunn et Dirk W. Bester, La réalité empirique des dépassements de coûts dans les projets informatiques : découverte d'une distribution de loi de puissance, Journal of Management Information Systems 39(3), 2022 — https://arxiv.org/pdf/2210.01573
- Hershey Foods Corporation, formulaire 10-Q pour le trimestre clos le 3 octobre 1999, déposé le 12 novembre 1999 — https://www.sec.gov/Archives/edgar/data/47111/0000047111-99-000081.txt
- NIKE, Inc., formulaire 8-K déposé le 27 février 2001 — https://www.sec.gov/Archives/edgar/data/320187/000032018701000003/0000320187-01-000003.txt
- Revlon, Inc., formulaire 10-Q pour le trimestre clos le 30 juin 2018 — https://www.sec.gov/Archives/edgar/data/887921/000088792118000011/rev2018q210-q.htm
- Lindsay Clark, La zone sinistrée des ERP : Les échecs les plus coûteux de la dernière décennie, The Register, 12 décembre 2019 — https://www.theregister.com/2019/12/12/erp_disaster_zone_the_mostly_costly_failures_of_the_past_decade/
- Gartner, page thématique Progiciels de gestion intégrée (ERP) — https://www.gartner.com/en/information-technology/topics/enterprise-resource-planning (consultée pour connaître l’origine du chiffre de 55 à 75 % largement cité ; la page n’était pas accessible au moment de la rédaction et ce chiffre n’a pu être attribué à aucune publication de Gartner)
Je dirige AdoptionLayer, une entreprise spécialisée dans l’adoption des logiciels au sein des entreprises. Les scènes de terrain décrites dans cet article sont fictives ; les chiffres, en revanche, sont réels et chacun d’entre eux renvoie à sa source ci-dessus.