Un seul chiffre permet de comprendre à quel point le déploiement d'un ERP (Enterprise Resource Planning ou progiciel de gestion intégré) est crucial pour une entreprise : les poursuites qu’elles ont intentées pour défaillance dans la mise en oeuvre de logiciels ERP et de CRM (Customer Relationship Management ou gestion de la relation client) s’expriment désormais en milliards de dollars. Greg Crouse, directeur général de Navigant Consulting, a passé 25 ans à gérer de grands projets en tant que témoin expert pour la justice ou consultant, et l’on peut dire qu’il a vécu tout cela de l'intérieur.

Dans une enquête réalisée en 2015 par Panorama Consulting Solutions, 21% des entreprises interrogées avaient déclaré que leur plus récent déploiement d'ERP avait été un échec. Les défaillances sont donc nombreuses. Mais les enjeux élevés de ces projets et l'augmentation du nombre de litiges ont fait qu'ils sont à la fois plus et moins apparents que jamais. Quand les poursuites judiciaires sont rendues publiques, un beau scandale pointe en perspective. Mais souvent, les nécessités juridiques font que les détails complets du litige ne sont jamais dévoilés. « Vous aurez du mal à trouver quelqu'un pour en parler : soit la procédure va durer un temps infini, reportant aux calendes grecques la divulgation des motifs, soit le litige est réglé à l’amiable et scellé à jamais », a expliqué M. Crouse. Nos confrères de CIO ont rassemblé ici quelques échecs spectaculaires de déploiements d’ERP pour en tirer quelques leçons et un peu de sagesse. (À noter que les commentaires de Greg Crouse relèvent de son expérience générale de ces situations. Il n'a pas travaillé spécifiquement sur les dossiers mentionnés ici.) 

1. MillerCoors : une bataille publique… réglée à l’amiable

En 2014, MillerCoors exploitait sept versions différentes du logiciel ERP de SAP, un héritage des années de consolidation de l'industrie de l'alcool qui a donné naissance à ce géant de l'industrie. Après les nombreuses fusions, l’entreprise a engagé la SSII indienne HCL Technologies pour déployer une mise en oeuvre unifiée de SAP qui servirait l'ensemble de l'entreprise. Mais tout ne s’est pas passé comme prévu : le premier déploiement a été marqué par huit défaillances de gravité « critique », 47 défaillances de gravité « élevée » et de milliers de problèmes supplémentaires qu’il a fallu résoudre en direct et sans répit pendant une période prolongée. En mars 2017, le projet avait tellement dérivé que MillerCoors a poursuivi HCL en justice, lui réclamant 100 millions de dollars. Le géant de l’alcool reprochait notamment à HCL de ne pas avoir mobilisé suffisamment de personnel pour le projet et de ne pas avoir tenu ses promesses. Mais l'entreprise de services IT indienne n’a pas pris l’accusation à la légère. En juin 2017, HCL a répliqué par une plainte, affirmant que MillerCoors reportait ses propres défaillances de gestion sur HCL et qu’elles étaient la cause réelle de cet échec. Des observateurs externes ont pu voir que le libellé des contrats, tel que décrit dans les plaintes, semblait reposer sur un contrat de services généraux préexistant entre les deux entreprises et laissait une grande marge d'erreur. Puis, en décembre 2018, après avoir semble-t-il utilisé les tribunaux comme levier pour faire valoir leurs enjeux, les deux entreprises ont réglé le différend « à l'amiable ». 

2. Revlon : de graves dysfonctionnements énervent les actionnaires

Le géant des cosmétiques Revlon a également eu besoin d’intégrer ses processus dans toutes ses business units après la fusion avec Elizabeth Arden, Inc., acquise en 2016. Par le passé, les deux sociétés avaient connu des expériences de déploiement d’ERP réussies, Elizabeth Arden avec Oracle Fusion Applications et Revlon avec Microsoft Dynamics AX. Mais, en décembre 2016, Revlon a pris la décision fatale d'opter pour une autre solution, SAP HANA. Est-ce qu’à l’époque, le choix de HANA, qui manquait encore de maturité, était voué à l'échec ? C’est possible. Ce qui est sûr, c'est que le déploiement a été suffisamment désastreux pour saboter la propre usine de production de Revlon situé en Caroline du Nord, entraînant des millions de dollars de ventes perdues. En mars 2019, le géant des cosmétiques a mis en cause « des défauts de conception et critiqué le manque de contrôles efficaces dans le cadre de la mise en oeuvre », ajoutant que « les perturbations liées au système ERP avaient entraîné des frais d'expédition supplémentaires et d'autres dépenses imprévues que la société a dû assumer pour remédier aux difficultés rencontrées par le service à la clientèle, une situation qui pourrait se poursuivre jusqu'à la résolution des problèmes du système ERP ». La crise a plombé l'action de Revlon, incitant les actionnaires à intenter des poursuites.

3. Lidl : gros problème pour le géant allemand de la grande distribution

C’était « le » mariage entre deux grandes entreprises allemandes : SAP, la superstar de l'ERP/CRM, et Lidl, une chaîne nationale de supermarchés affichant un chiffre d'affaires annuel de 100 milliards d'euros. Depuis 2011, les deux entreprises travaillaient ensemble pour migrer le système d'inventaire interne de Lidl, à bout de souffle. Mais, en 2018, après avoir dépensé près de 500 millions d'euros, Lidl a abandonné le projet. Alors, que s'est-il passé ? Selon certaines rumeurs, une singularité dans la tenue de registres de Lidl aurait été à l’origine du problème : le géant de la distribution a toujours basé ses systèmes d'inventaire sur le prix payé pour les marchandises, alors que la plupart des entreprises basent leurs systèmes sur le prix de détail auquel ils vendent leurs marchandises. Mais Lidl ne voulait pas changer de méthode, si bien qu’il a fallu personnaliser l'implémentation de SAP, inaugurant le début d’une série de problèmes. Si l'on ajoute à cela un turnover important du personnel dans le département IT de Lidl et des conflits avec le consultant chargé de mener à bien l'implémentation. Tous les ingrédients de l’échec étaient réunis.

4. National Grid : une mise en route en pleine tempête

National Grid, un fournisseur public de gaz et d’électricité opérant dans les États de New York, de Rhode Island et du Massachusetts, s’est retrouvé dans une situation difficile. Bien qu’il ait entamé le déploiement d'une nouvelle implémentation SAP depuis trois ans, il constatait déjà des retards. Or, en cas de dépassement de la date de mise en service, les coûts supplémentaires pour National Grid se chiffraient en dizaines de millions de dollars, et le fournisseur devrait obtenir l'approbation du gouvernement pour augmenter ses tarifs afin de couvrir ce surcoût. A contrario, une mise en route prématurée du nouveau système SAP pouvait compromettre ses propres opérations. De plus, la mise en service était prévue le 5 novembre 2012, moins d'une semaine après le passage dévastateur de l’ouragan Sandy dans la zone de service de National Grid qui avait privé d’électricité des millions de personnes. Dans ce chaos, National Grid a pris la décision fatale de basculer sur le nouveau système SAP, et les résultats ont été encore plus désastreux que ce qu’avaient prédit les personnes les plus pessimistes : des employés ont reçu un salaire trop élevé, tandis que d'autres ont été sous-payés ; 15 000 factures de fournisseurs n'ont pas pu être traitées ; faute de rapports financiers, l'entreprise ne pouvait plus obtenir de prêts à court terme qu’elle contractait habituellement pour disposer des liquidités nécessaires. L’action en justice intentée par National Grid contre l’intégrateur systèmes Wipro, s’est finalement réglée à l'amiable : National Grid a reçu 75 millions de dollars de Wipro, mais cela n'a pas suffi à couvrir les pertes.

5. Worth & Co. : un déploiement interminable qui débouche sur un procès

Worth & Co., une entreprise de fabrication basée en Pennsylvanie, voulait simplement changer de système ERP. En 2014, après avoir assisté à plusieurs présentations, elle a décidé d'engager EDREi Solutions pour implémenter Oracle E-Business Suite. La première date de mise en service avait été fixée à novembre 2015. Mais les choses ont commencé à déraper. La date limite a été repoussée à février 2016 ; Oracle a alors demandé à Worth & Co. de verser 260 000 dollars pour des cours de formation et des contrats de support. Mais l’année 2016 est passée et le déploiement n’était toujours pas achevé. En 2017, Worth & Co. a abandonné EDREi au profit de l’intégrateur Monument Data Solutions. Pendant une année supplémentaire, ce dernier a essayé en vain de personnaliser la suite Oracle pour les besoins de Worth & Co. Finalement, en février 2019, après l'abandon du projet, Worth & Co. a pris une nouvelle décision : ne pas poursuivre en justice le fournisseur IT, mais directement Oracle, auquel l’entreprise a payé 4,5 millions de dollars en licences, services professionnels et formation. Le procès est toujours en cours.

6. Vodafone : le bras armé de la loi

Pour l'opérateur télécom britannique Vodafone, la consolidation de ses systèmes CRM sur une plate-forme Siebel s’est traduite par un tas de problèmes : la migration des comptes de ses clients ne s’est pas bien passée. Et, même si l'entreprise a évité d’ébruiter l’affaire, les utilisateurs ont commencé à remarquer que leurs comptes n'étaient pas correctement crédités pour les paiements effectués. Résultat : le régulateur britannique des télécommunications a infligé une amende de 4,6 millions de livres sterling à l’opérateur. Même si cet incident s'est conclu par le paiement d'une simple amende, Greg Crouse fait remarquer que la surveillance réglementaire pourrait, à l'avenir, de manière un peu surprenante, déboucher sur des litiges privés. « Les gens se rendent compte s’il y a des problèmes avec les implémentations à grande échelle. De plus, il est obligatoire de signaler au régulateur les échecs d’implémentations ». Auparavant, une entreprise pouvait être tentée de garder le silence. Mais, parce que les régulateurs peuvent rendre public les défaillances, elle pourrait estimer désormais qu’elle a plutôt intérêt à porter l’affaire devant la justice et déplacer la responsabilité de la situation sur quelqu’un d’autre.

15 déploiements d'ERP défaillants ou calamiteux (2ème partie)