Après avoir vu une première vague de projets ERP dont les déploiements ont été défaillants, voici la seconde partie de cette liste d'initiatives déficientes.

7. Collège communautaire de Washington : l’échec des tiers

Dans cette histoire, chaque protagoniste a ses responsabilités. Une partie des frais de scolarité payés chaque année par les étudiants des collèges communautaires de l'État de Washington devait permettre aux écoles de passer à un système ERP de PeopleSoft, avec une date de mise en service fixée à 2012. Mais le projet a du mal à prendre forme. Une part des retards était imputable à l’organisation interne : les processus opérationnels des 34 campus du système étaient très divers et auraient nécessité une normalisation. Mais, c’est seulement bien après le déploiement que ce besoin est devenu évident. Depuis, un autre problème a émergé : Ciber, la société tierce engagée pour déployer le système PeopleSoft, a fait faillite en avril de cette année, et ses actifs ont été récupérés par HTC, une entreprise basée dans le Michigan. De plus, HTC a annulé son contrat avec le système éducatif et a même intenté une action en justice pour réclamer 13 millions de dollars aux collèges, affirmant que l’échec du déploiement est dû à un « dysfonctionnement interne ». Selon l’ancien consultant Greg Crouse, ce genre d’hostilité réciproque n'est pas rare. « On se retrouve dans des cas où le client n'est pas satisfait du travail d’implémentation effectué par l'entreprise et intente des poursuites contre celle-ci. Ou bien, le client n'est pas content et cesse de payer ses factures. Il y a aussi des tierces parties qui adoptent parfois une attitude de fournisseur/revendeur et ils se retrouvent en position de plaignant ou de défendeur, en fonction de celui qui se fâche en premier ». Ce qui est sûr, c’est qu’entre-temps, le déploiement n’avance pas.

8. Woolworth Australie : la disparition de la mémoire institutionnelle

L'avant-poste australien de la vénérable chaîne de grands magasins, affectueusement connu sous le nom de « Woolies », a également été confronté à des problèmes liés aux données quand il est passé d'un système maison, en place depuis 30 ans, à un système SAP. L’un des effets critiques de cette migration, c’est que les directeurs de chaque magasin devaient attendre 18 mois les rapports de profits et pertes, au lieu d’en disposer chaque semaine. Le problème était lié au changement apporté aux procédures de collecte des données. Mais c’est surtout l’incapacité de l'entreprise à comprendre pleinement ses propres processus qu’il fallait mettre en cause. Les procédures métiers quotidiennes n'étaient pas bien documentées, et comme les cadres supérieurs avaient quitté l'entreprise pendant ce trop long processus de transition - six ans - tout le savoir institutionnel a été perdu et n’a pas pu être intégré dans le nouveau déploiement. « Les entreprises omettent souvent d’affecter au déploiement d'un ERP les gens qui connaissent bien les processus métiers », a expliqué M. Crouse. « Soit ils sont affectés à temps partiel, soit l’entreprise embauche de nouvelles personnes pour assister l’intégrateur du nouveau système. Rien de tout cela ne fonctionne. Il est vraiment important d’affecter des personnes qui connaissent bien le processus que vous essayez de mettre en place à temps plein. Et c'est un conseil que l’on peut généraliser : si l’entreprise n’affecte pas les personnes les plus au fait du système, elle peut s’attendre à des problèmes ».

9. Target Canada : un gros ménage à faire dans les données fraîches

La plupart des entreprises qui déploient des systèmes ERP rencontrent des difficultés au moment d'importer des données de systèmes existants dans leur nouvelle infrastructure. Mais en 2013, année du lancement de Target au Canada, l’entreprise pensait bien éviter ce problème puisqu’elle n’avait pas de données à convertir, seulement de nouvelles informations à intégrer dans son système SAP. Cependant, le jour du lancement, sa chaîne d'approvisionnement s'est effondrée, et le problème a été rapidement identifié : ces données supposément fraîches étaient truffées d'erreurs. En effet, les dimensions, les prix, le nom des fabricants, etc. apparaissant sur les étiquettes des articles étaient incorrects. Des milliers d'entrées avaient été saisies manuellement et dans des délais extrêmement courts dans le système par des employés sans expérience qui ne savaient par reconnaître quand les informations fournies par les fabricants étaient erronées. L’enquête a révélé que seulement environ 30 % des données du système étaient exactes.

10. PG&E : une base de « démo » avec de vraies données de production

Certains déploiements tentent de résoudre ce problème de données en testant leur nouveau système avec des données de production, généralement importées de bases de données existantes. Ils peuvent ainsi vérifier que les erreurs sont corrigées avant le déploiement. Mais les données de production sont des données précieuses qui contiennent beaucoup d'informations confidentielles et exclusives, et elles doivent être protégées avec le même soin que dans un contexte de production réelle. En mai 2016, Chris Vickery, analyste des risques chez UpGuard, a découvert une base de données accessible au public, provenant probablement du système de gestion des actifs de Pacific Gas and Electric. La base, qui contenait des détails sur plus de 47 000 ordinateurs, machines virtuelles, serveurs et autres dispositifs de PG&E, était accessible en clair, sans nom d'utilisateur ni mot de passe, à tout un chacun. Dans un premier temps, PG&E a nié qu'il s'agissait de données de production. Mais Chris Vickery affirme que c’était bien sa base de données de production et qu'elle avait été exposée à la suite du déploiement d'un ERP. Le fournisseur tiers avait sans doute reçu les données directement de PG&E pour remplir la base de données de démonstration et la tester en situation de production réelle. Sauf qu’il n’avait pas protégé ces données comme il aurait dû le faire pour une base de production réelle.

11. Sûrement pas une bonne expérience pour Hershey

Est-ce que l’échec d’une implémentation technologique (dans ce cas, le logiciel ERP R/3 de SAP) peut faire chuter une entreprise du Fortune 500 (dans ce cas, Hershey Foods) ? Les problèmes opérationnels rencontrés par Hershey en 1999 pendant la période d'Halloween n'ont certainement pas fait le bonheur des investisseurs de Wall Street. Du fait de défaillances épouvantables dans les applications de la chaîne d'approvisionnement SAP ERP, Siebel CRM et Manugistics utilisées par Hershey, l’entreprise n’a pas pu livrer 100 millions de dollars de Kisses pour Halloween cette année-là, entraînant une chute de son action de 8 %. Selon Greg Crouse, « l’échec d’un projet technologique ne peut pas faire complètement chuter une entreprise du Fortune 500, mais peut certainement l'ébranler un peu ».

12. Un projet beaucoup trop ambitieux chez Nike

Nike, le fabricant de chaussures et d'équipements sportifs mondialement connu, a dépensé 400 millions de dollars pour mettre à niveau sa chaîne d'approvisionnement et ses systèmes ERP. Mais pour quel bénéfice ? D’abord, Nike a perdu 100 millions de dollars en ventes. Ensuite, l’entreprise a vu ses actions chuter de 20 %. Enfin, elle a été confrontée à une série de recours collectifs. C'était en 2000. Ces résultats épouvantables sont la conséquence d’un projet d'ERP, de chaîne d'approvisionnement et de CRM audacieux. Mais au lieu de disposer d’un super système, Nike a dû déchanter. Son histoire résonne à la fois comme un échec malheureux et comme un avertissement.

13. Tempête de problèmes dans l’ERP de HP

L’objectif de HP était de centraliser ses systèmes ERP nord-américains éparpillés sur un seul système SAP. Mais cette histoire épique montre qu’on n'est jamais trop pessimiste quand il s'agit de gestion de projet ERP. En 2004, les chefs de projet de HP étaient au fait de tout ce qui n’allait pas dans le déploiement de leur ERP. Mais ils n'avaient tout simplement pas prévu qu’autant de problèmes surviendraient en même temps. « Finalement, le projet a coûté 160 millions de dollars à HP en commandes en attente et en perte de revenus, soit plus de cinq fois le coût estimé du projet », a déclaré Gilles Bouchard, à l’époque DSI des opérations mondiales de HP. « Nous avons rencontré une série de petits problèmes, tous faciles à régler individuellement. Mais leur accumulation et leur simultanéité ont créé les conditions d’une parfaite tempête ».

14. Un nouveau genre de bizutage d’étudiant de 1e année

À l'automne 2004, la dernière chose dont avaient besoin les étudiants de première année de l'Université du Massachusetts, c’était d’un programme informatique qui pourrisse leur vie et rende leurs premiers pas d’étudiants encore plus incertains. Malheureusement, plus de 27 000 étudiants de l'Université du Massachusetts, mais aussi de Stanford et de l'Université de l'Indiana, ont bataillé des semaines pour se connecter à des portails pleins de bogues et des applications ERP. Au mieux, ils ne pouvaient accéder à leur planning et trouver leurs classes de cours. Au pire, ils ne pouvaient recevoir leurs aides financières. Un ancien étudiant de l’Université du Massachusetts se rappelle qu’à l’époque « les nouveaux étaient complètement perdus, et qu’ils ne savaient pas où aller ». Après quelques jours et quelques semaines un peu tendues, tout le monde a finalement reçu ses chèques et ses emplois du temps.

15. Un projet d’ERP complètement irréaliste chez Waste Management

Le géant de l'élimination des déchets, Waste Management, est toujours impliqué dans une bataille juridique avec SAP. L’entreprise reproche à l’éditeur d’avoir prétendu qu’il pourrait installer son logiciel ERP en 18 mois pour et lui réclame 100 millions de dollars. L'opération initiale a débuté en 2005, mais la saga juridique a commencé en mars 2008, quand Waste Management a intenté une action en justice, accusant les dirigeants de SAP d’avoir survendu leur système, et de l’échec massif qui a suivi. Quelques mois plus tard, SAP a riposté en affirmant que Waste Management avait violé son accord contractuel de différentes façons. En particulier, SAP estime que son client « n’a pas défini ses besoins métiers en temps voulu et avec précision » et qu’il n’a pas affecté à ces tâches « des utilisateurs et des gestionnaires compétents et habilités à prendre des décisions » pour travailler sur le projet. À l'automne 2008, d’autres accusations concernant la documentation, les dépositions et des retards dans la présentation de l'affaire devant un juge se sont ajoutées à la plainte. Au regard de ces problèmes, l’offre de mise en œuvre sur 18 mois paraît aujourd’hui complètement irréaliste.

Survivre au déploiement d'un ERP

Alors, quelles leçons tirer de toutes ces histoires ? D’abord, il ne faut pas se laisser intimider par les régulateurs, s’assurer que vos données sont sécurisées et propres, et bien documenter vos processus avant de changer de plate-forme : ces conseils sont valables pour tout déploiement (et tout autre grand projet IT). Un autre aspect souvent rappelé par Greg Crouse pour la DSI, c'est celui de continuité. « Je travaille actuellement sur une affaire d’implémentation d'ERP dont le calendrier s’étale sur plusieurs années », a-t-il déclaré, « et quatre DSI se sont succédés pendant cette période. Ces changements sont à l’origine d’un tas de problèmes. Il faut un référent stable, quelqu'un qui défend vraiment le projet. Cela devient difficile si les dirigeants et ceux qui connaissent le projet côté client changent continuellement ».