Mettre en place un logiciel, et à plus forte raison un ERP, est toujours un projet compliqué et risqué car cela touche au cœur du fonctionnement de l’entreprise. Les annales abondent d’exemples de gros projets ERP ayant échoué (budgets et délais explosés, utilisateurs mécontents, etc.). Pourquoi et comment éviter cela ?

Réussir son projet ERP

L’idéal : adopter le logiciel sans l’adapter

En choisissant un logiciel, on choisit une solution qui amène sa logique, ses modes de fonctionnement. Souvent, cela permet de structurer les processus dans une entreprise qui n’a pas encore fait ce travail. Souvent aussi, si l’entreprise avait déjà défini ses processus et sa façon de fonctionner, le logiciel va obliger à changer. Et la tentation est grande, dans les entreprises qui en ont les moyens, de demander des développements spécifiques pour adapter l’outil plutôt que de gérer ce changement.
Or les développements coûtent cher, sont difficiles à maintenir, et viennent parfois tordre la logique de l’outil à mauvais escient. Ce n’est pas parce qu’on avait une manière de faire que c’était la seule, ou la bonne. Et quand bien même une demande spécifique pourrait amener de la valeur, le rapport coût / bénéfice pour la prendre en compte est rarement positif.

Donc, si on a bien choisi son outil, il vaut mieux l’adopter le plus possible tel quel plutôt que l’adapter.

Le mode projet idéal pour éviter les dérives des projets ERP

Une organisation « lean » d’un projet ERP pourrait ressembler à cela :

  • Un commanditaire chargé d’exprimer le besoin, de porter la vision métier. Il sera toujours tenté de descendre dans la description d’une solution détaillée. C’est le rôle du consultant fonctionnel de le ramener au besoin (Quel résultat vises-tu ? Pourquoi demandes-tu cela ? Dans quelles circonstances ce besoin se fait-il sentir ?)
  • Un (des) consultant(s) fonctionnel(s) qui maîtrise(ent) parfaitement la solution. Il est capable le fondement du besoin exprimé et d’identifier la meilleure façon d’y répondre dans la solution (il y a souvent plusieurs façons de faire). Il est capable de challenger le besoin, d’être force de proposition aussi pour amener de la valeur (d’autres clients font comme cela, pour telle raison, cela pourrait-il avoir du sens dans votre organisation). Il peut configurer lui-même la solution pour répondre au besoin. Il peut aider le commanditaire à préparer la formation des utilisateurs à l’outil
  • Une équipe technique pour réaliser les éventuelles interfaces et faire les quelques développements spécifiques qui pourraient malgré tout être nécessaires

Une approche itérative est recommandée pour se focaliser sur l’essentiel :

  • Un découpage du projet en lots autonomes (correspondant à des modules du logiciel et /ou à des processus complets)
  • Sur un module ou un processus donné, le premier lot est dédié à un produit minimum viable. On se focalise d’abord sur les demandes standards et les besoins courants. Souvent, une fois ce premier lot mis entre les mains d’utilisateurs, les demandes plus exotiques tombent d’elles-mêmes avec l’appropriation du nouvel outil, au profit d’améliorations vraiment utiles (et souvent comprises dans le standard)

Pourquoi les gros projets ERP (SAP ou autres) échouent-ils si souvent ?

Dans les grandes organisations, les pratiques sur les projets ERP tendent souvent à aller à l’encontre des principes précédents :

  • Des projets font l’objet d’appels d’offres souvent avec une entreprise choisie pour l’assistance à Maîtrise d’Ouvrage et une autre pour l’intégration. Pour correspondre aux principes d’achats, un cahier des charges est souvent rédigé de manière assez détaillée
  • Cela induit des demandes parfois antinomiques avec le fonctionnement de l’outil sur lesquelles il est difficile de revenir
    Cela induit aussi un mode projet forfaitaire « cycle en V » sur des temps très longs. Or on sait que le taux d’échecs des projets est directement corrélé à leur taille (et leur durée)
  • L’équipe d’AMOA est structurellement sélectionnée pour sa capacité à synthétiser la « lettre au père Noël » des métiers et est rarement en situation d’exercer son devoir de conseil pour que le besoin s’adapte à la solution
  • L’équipe d’intégration est encore moins en position de le faire. Ils paramètrent l’outil mais sans lien direct avec le demandeur, et sans capacité à lui présenter une solution correspondant à son besoin profond plutôt qu’une solution répondant aux spécifications faites par l’assistance Maîtrise d’ouvrage
  • Surtout, quel que soit le logiciel choisi, la connaissance profonde de son fonctionnement est toujours une compétence rare, et, une fois l’appel d’offres gagné l’intégrateur ou l’AMOA doivent staffer avec les ressources disponibles et aux tarifs compatibles avec les grilles d’achats souvent rabotées. En conséquences, 9 fois sur 10, les intervenants ne sont pas en capacité de proposer des solutions. Ils ne peuvent que réaliser ce qu’on leur a demandé en bons exécutants
  • Pire, non seulement il leur est généralement difficile d’exercer leur devoir de conseil, mais ils n’y ont pas spécialement intérêt. C’est compliqué, ça oblige à challenger le métier et à compliquer les interactions établies entre le métier, la DSI et les intervenants, et plus il y de développements spécifiques, plus il y a de travail à vendre au travers d’avenants. Pourquoi s’embêter puisque le maître d’ouvrage est content qu’on exécute ce qu’il demande et qu’on gagne plus d’argent ?
  • Par ailleurs, le logiciel choisi doit souvent s’interfacer avec des solutions existantes multiples avec des problèmes d’intégration parfois compliqués à gérer
  • A la fin, malgré tous les développements spécifiques, le nouvel outil nécessite quand même de faire une conduite du changement. Et elle est quand même toujours difficile parce que personne n’adopte un nouvel outil sans effort, surtout s’il a été dénaturé par des verrues complexifiant le travail
  • Au final, comme on a rencontré des problèmes pour intégrer l’outil dans l’environnement, et d’autres problèmes pour réduire l’écart entre besoin fantasmé, besoin réel, et possibilités de la solution, du retard est pris, les phases de test et de conduite du changement sont souvent compressées, ce qui ne fait qu’aggraver les choses lors de la mise en production

Ca ne se passe pas toujours comme ça, mais c’est souvent comme cela. Pour y remédier : boucles courtes, livraisons par lots, nombre d’intervenants plus réduits, focus sur le savoir-être et la compétence des intervenants (métier et outil) plus que sur leur capacité à respecter des demandes théoriques.

 

Sur le même thème :