En préambule, Eric Kimberling, président et fondateur de PCS, rappelle que chaque projet est unique et que les deux parties, c'est-à-dire l'éditeur/intégrateur d'un côté, l'entreprise de l'autre, portent des responsabilités dans le succès d'une implémentation d'ERP. Il souligne aussi que si l'exemple qu'il développe ici a concerné la mise en œuvre d'une solution SAP, ce genre d'avatar a malheureusement lieu avec n'importe quel ERP. L'objectif est bien de tirer des leçons de la démarche, indépendamment des technologies mises en œuvre.
Avant d'entrer dans le vif du sujet, il présente d'autres cas d'implémentations d'ERP s'étant soldées par des échecs, comme celui de la faillite de cette importante société de joaillerie pour laquelle, outre l'environnement économique, les dettes importantes et la concurrence féroce, l'échec du projet ERP a été retenu comme facteur aggravant la situation. Les exemples sont nombreux et parfois dramatiques ; le cas qui nous occupe aujourd'hui est celui d'une entreprise générant plusieurs milliards de dollars de chiffre d'affaires qui a poursuivi l'éditeur en justice en 2009 pour fraude et présentation déformée de la réalité. Comme souvent aux États-Unis, l'affaire s'est soldée par un arrangement à l'amiable, PCS étant intervenu en tant qu'expert dans la procédure judiciaire.
Huit points
L'analyse indépendante de PCS a mis en évidence rien moins que huit domaines dans lesquels les choses n'ont pas été faites correctement. L'exposé de ces huit points confine à la caricature, d'où l'intérêt d'en tirer les leçons.
PCS a estimé que le processus de choix et d'évaluation du logiciel avait été léger, que les attentes de l'entreprise par rapport à l'ERP étaient irréalistes, que les besoins métiers n'avaient pas été définis clairement, que la direction générale n'était pas assez impliquée, que le projet avait été mal géré, que l'entreprise avait trop personnalisé son logiciel, que la gestion du changement avait été mal menée et enfin que les risques avaient été mal évalués.
En amont du projet
Malgré une précédente expérience malheureuse avec la mise en œuvre d'un ERP plusieurs années auparavant, l'entreprise n'a, selon PCS, toujours pas défini ses besoins comme il l'aurait fallu. Les processus et les besoins n'avaient pas été correctement définis en amont du choix du logiciel et lorsqu'ils l'ont été, c'est site par site, en commençant par un site pilote. L'approche retenue est passée par un comité de pilotage, ce qui a abouti à de nombreuses demandes de personnalisation, à des incohérences entre les sites et, plus tard, à des erreurs. À noter que le processus de définition des besoins s'est poursuivi tout au long de l'implémentation.
PCS ajoute que la répartition des rôles entre entreprise utilisatrice et éditeur n'avait pas été correctement définie ou comprise et que l'entreprise n'a pas bien fait la différence entre ce qui avait été présenté lors des démonstrations et ce qui a été effectivement acquis contractuellement.
En outre, les attentes étaient irréalistes : l'entreprise espérait une mise en œuvre sur ses multiples sites répartis dans le monde en 18 mois et pensait pouvoir disposer de 100 % des fonctionnalités de son métier en standard, sans aucun développement spécifique. Elle pensait atteindre ces objectifs avec une assistance externe extrêmement réduite.
Le plus préjudiciable au projet aura sans doute été le manque d'implication de la direction générale, qui a adopté une attitude non-interventionniste et rejeté les responsabilités sur les collaborateurs. Il en a découlé une absence de consignes pour le groupe de projet, des décisions lentes pour ne pas dire inexistantes et un manque de cohérence entre les membres de la direction, un problème qui pour PCS va bien au-delà du projet ERP.
Pendant le projet et au-delà
Le pilotage du projet a souffert de ce qui précède et les chefs de projet ont souvent changé au fil du temps. Souvent inexpérimentés, ils se sont également retrouvés à plusieurs, sans vrais objectifs, sans budget et donc sans réelle motivation au succès du projet. Ces personnes venaient essentiellement de l'interne : il n'y a eu que très peu d'apport de compétences externes.
Malgré tous les efforts entrepris pour en limiter l'étendue, plus de 100 développements spécifiques ont été nécessaires pour répondre aux besoins. Ces nombreuses personnalisations ont été assorties d'une procédure défaillante de contrôle et de validation par les utilisateurs. Au final, PCS estime que l'entreprise n'a pas pleinement mis à profit les fonctionnalités du système, qui est rapidement devenu un logiciel spécifique, très éloigné du progiciel standard.
Pour gérer le changement, une équipe dédiée a bien été mise sur pied. Mais les utilisateurs ne se sont que très peu impliqués tout au long du projet et la tâche de l'équipe a été considérablement compliquée par l'évolution permanente des définitions de processus et de la conception du système. En outre, PCS estime que l'équipe centrale de projet n'a pas suffisamment compris les possibilités du système, ce qui a abouti à cette personnalisation massive.
Enfin, les risques n'ont tout simplement pas été gérés du début à la fin du projet, le système n'a pas été correctement testé, que ce soit sur le plan technique, fonctionnel ou des données et les utilisateurs avaient été insuffisamment formés avant le passage en production. PCS précise que l'entreprise a décidé de se lancer malgré un audit interne qui avait averti des risques majeurs d'une mise en production à ce stade.
En conclusion
Dans ce panorama très sombre, il y a néanmoins un certain nombre de choses qui ont bien fonctionné, à commencer par le logiciel. Mais l'entreprise s'est révélée incapable de comprendre comment ce logiciel pourrait répondre à ses besoins métier, ce qui fait dire à Eric Kimberling que "au bout du compte ce n'est pas le logiciel qui détermine le succès ou l'échec d'une implémentation".
Et de donner quelques conseils à suivre aux entreprises candidates à un projet ERP : mettre en place un processus d'évaluation et de choix du logiciel rigoureux, se forger des attentes réalistes et définir clairement son projet. Il insiste sur l'importance de l'implication de la direction générale et sur le profil du chef de projet, qui doit être solide. Enfin, la personnalisation doit être gérée avec parcimonie, le changement parfaitement mené et les risques doivent être mesurés.
Benoît Herr