5 projets ERP qui ont échoué, et pourquoi ils ont mal tourné
Des spécialistes de l’ERP partagent leur analyse et les enseignements que l’on peut tirer d’échecs spectaculaires de déploiements qui se sont mal passés. Avec à la clé, des conseils pour éviter ces écueils.
Il y a de nombreuses façons de faire échouer un projet ERP. « Il faut du temps, une préparation spécifique et une gestion adéquate pour que l’ERP devienne un outil efficace au sein de votre entreprise », prévient Jenny Chua, responsable du développement des activités chez The World Management, une société de conseil en ERP à Singapour.
John Belden, chef de la stratégie et de la recherche chez UpperEdge, un cabinet de conseil en négociations informatiques, confirme. Il voit généralement trois éléments clés qui conduisent à l’échec.
Tout d’abord, les déploiements d’ERP sont souvent deux à dix fois plus importants que les projets qui les ont précédés. Deuxièmement, ils sont transformationnels, ce qui signifie qu’il y a des gagnants et des perdants dans l’organisation en raison de la transformation numérique initiée par le déploiement. Troisièmement, elles sont générationnelles, ce qui signifie qu’une organisation peut n’avoir rien fait de comparable depuis 10 ou 15 ans.
« Un projet aura des problèmes si les entreprises ne sont pas conscientes de ces problèmes et ne tentent pas d’atténuer ces risques », avertit John Belden.
Voici 5 cas célèbres de déploiement d’ERP qui illustrent certaines des principales raisons pour lesquelles ces opérations échouent (et comment éviter de faire pareil).
1. Le projet démesuré de Cover Oregon
Les projets de grande envergure ont tendance à mettre une entreprise dans une position où celle-ci n’est pas préparée au très grand nombre de décisions qu’elle doit prendre. En conséquence, les équipes débordées finissent par enchaîner les mauvaises décisions, les unes après les autres.
Pour John Belden, l’exemple le plus classique est la tentative faite en 2012 par Cover Oregon, le marché en ligne des soins de santé, de mettre en œuvre l’Obamacare et de remplacer simultanément tous ses systèmes transactionnels. L’organisation a finalement dépensé plus de 300 millions de dollars et n’a pas été en mesure de traiter une seule demande d’assurance par l’intermédiaire de sa plateforme.
« Ils ont créé un scénario dans lequel le projet est devenu tellement énorme qu’ils n’ont pas pu respecter les délais ni prendre les décisions qui s’imposaient », constate John Belden.
Les problèmes ont été exacerbés par la nécessité de respecter les délais imposés par l’Obamacare. John Belden estime que le projet aurait pu être mené à bien si Cover Oregon avait réduit sa taille et l’avait limité aux exigences de l’Obamacare.
Ce qu’il faut en retenir : limitez et adaptez la portée du projet ERP au calendrier.
2. La vision trop étroite d’Israel Chemical Limited
Les problèmes « générationnels » surviennent lorsque personne au sein de l’équipe de direction ne comprend où se situent les problèmes.
« Certains peuvent avoir une expérience préalable, mais c’était il y a 10 ou 15 ans et les personnes qui ont tiré les leçons sont ailleurs dans l’organisation ou ont changé de poste », a déclaré John Belden.
Le déploiement raté de SAP par Israel Chemical Limited (ICL) en 2014 en est un bon exemple. Le coût du projet est passé de 120 millions de dollars à plus de 500 millions de dollars. En fin de compte, le PDG d’ICL a démissionné et l’ensemble du déploiement a été annulé.
Le PDG avait confié le projet à une personne relativement nouvelle au sein de la direction financière. Ce chef de projet s’est principalement attaché à s’assurer que les données financières étaient correctement intégrées dans l’ERP, au lieu de prendre en compte les besoins de la chaîne de fabrication et de la chaîne d’approvisionnement de l’entreprise. Les employés de la première usine se sont révoltés après s’être vu imposer le nouveau système.
« Ils se sont davantage concentrés sur l’intégrité financière que sur l’intégrité opérationnelle », explique John Belden.
Ce qu’il faut en retenir : tous les utilisateurs de l’ERP doivent être pris en compte et pas seulement une partie de l’entreprise.
3. L’absence de tests en situation exceptionnelle chez National Grid
Le déploiement de l’ERP de National Grid a été essentiellement balayé par l’ouragan Sandy lorsque le fournisseur d’électricité a tenté de consolider toutes ses opérations américaines sur un système SAP commun en 2012. En fin de compte, il a fallu deux ans pour remettre le projet sur pied, ce qui a coûté 585 millions de dollars.
La société mère avait travaillé avec succès avec la société de conseil Wipro sur une consolidation ERP similaire en Europe. Mais l’équipe chargée du projet ERP s’est heurtée à des différences majeures dans l’environnement réglementaire aux États-Unis.
Wipro a suggéré que l’ERP SAP était prêt à être mis en service sur la base des résultats des tests, mais le système réel n’a pas résisté à l’augmentation de la charge de travail. Des processus opérationnels d’urgence ont été nécessaires pour réparer le réseau électrique après l’ouragan, ce qui a impliqué des procédures spéciales pour faire venir des ouvriers et du matériel d’autres services pour les réparations de grande ampleur.
John Belden estime que l’équipe de déploiement s’était concentrée sur des tests « happy path », c’est-à-dire sur des fonctions testées dans des circonstances idéales, mais qu’elle n’avait pas suffisamment testé le système dans des scénarios d’urgence. National Grid a décidé de mettre le système en service alors que l’ouragan remontait la côte.
Ce qu’il faut en retenir : il est essentiel d’évaluer tous les facteurs susceptibles d’affecter le lancement avant de procéder à un déploiement ERP de grande envergure.
4. Waste Management n’a pas vérifié les affirmations des éditeurs
Waste Management s’est heurtée à des obstacles majeurs lorsqu’il a tenté une installation de grande envergure de SAP en 2005. Après de nombreux problèmes et retards, l’entreprise s’est retrouvée dans un procès à 500 millions de dollars contre SAP, qui a finalement été réglé à l’amiable.
SAP avait suggéré que Waste Management pourrait réaliser des gains annuels de 106 à 220 millions de dollars grâce à un système ERP consolidé, qui pourrait être déployé en 18 mois.
Deepak Lalwani, directeur et consultant en gestion chez Deepak Lalwani & Associates, une société de conseil IT, avance que l’un des principaux problèmes était que Waste Management n’avait pas vérifié les affirmations de SAP avant de prendre la décision de lancer le projet. L’entreprise a rapidement découvert qu’il y avait des écarts importants entre ce qui avait été promis et ce qui avait été apporté par le logiciel.
Ce qu’il faut retenir : vérifiez les affirmations de l’éditeur avec les équipes techniques et les métiers en interne. « La réalisation d’un PoC sur des fonctionnalités critiques peut réduire considérablement les risques », partage Deepak Lalwani.
5. Les objectifs irréalistes de Nike
Nike pensait qu’il pouvait « tout simplement le faire » (« just do it ») lorsqu’il s’est lancé dans une modernisation de son ERP pour un montant de 400 millions de dollars en 2000. Mais le nouveau système a entraîné une perte de 100 millions de dollars de chiffre d’affaires et une chute de 20 % du cours de l’action lorsque la société n’a pas pu honorer les commandes de chaussures Air Jordan.
« Nike était trop optimiste dans ses objectifs et n’a pas vérifié que les processus métiers répondaient bien aux besoins opérationnels avant de déployer le système », explique Alex Sharpe, fondateur de Sharpe Management Consulting.
Ce qu’il faut retenir : il est important de fixer des objectifs réalistes dans le plan du déploiement, notamment en ce qui concerne les fonctionnalités de l’ERP et les calendriers des projets. Alex Sharpe recommande également de définir les exigences opérationnelles et métiers dès le départ et de les garder à l’esprit.
« Veillez à prendre suffisamment de temps pour tester le système, afin de déceler d’éventuels problèmes avant de le mettre en production », ajoute-t-il.
