Nous lisons beaucoup d’articles et de points de vue différents sur la pertinence des méthodes de mise en oeuvre pour des projets ERP : adaptatives ou prédictives ? Quelles démarches faut-il adopter pour assurer la réussite des projets ?
Sur la base de nos expériences passées, nous avons identifié plusieurs « invariants » , des paramètres communs à tous nos projets, qui vont aider et permettre l’adaptation de la méthode aux contextes projet.
Invariant 1 : Faire confiance aux équipes opérationnelles pour promouvoir l’agilité dans l’Entreprise.
Le contexte du client est important. Au risque de contrarier des idées reçues, les clients avec un fort historique sur leurs applications et une dette technologique importante ne sont pas les plus réfractaires à un changement de méthode. La mise en oeuvre de méthodes agiles ouvre des perspectives d’évolutions du SI dans des délais jusque-là inconnus des équipes métier. Cela motive et engage pour un projet collectif et renforce les relations entre les équipes métier et IT, parfois distendues au fil des projets passés.
Invariant 2 : Adopter la méthode (agile ou prédictive) en fonction du composant à mettre en oeuvre.
Le produit à mettre en oeuvre est un élément de contexte influant sur la méthode à utiliser. L’urbanisation des SI actuels impose des composants de différentes natures avec des ERPs, des applications dans le cloud, des applications hybrides et d’autres composants liés à la mobilité. Devant cette multitude de produits à mettre en oeuvre, formaliser le besoin de l’utilisateur final, sous forme de « User Stories », comme préconisé par les méthodes agiles, est une bonne approche. Mettre en oeuvre tous les composants du SI avec une méthode agile est plus discutable. Pour sécuriser l’intégration du nouveau produit dans le SI, les méthodes prédictives (Cycle en V) sont plus adaptées. Par exemple, pour la modification d’interfaces, la gestion des releases du SI existant et l’adhérence avec d’autres projets, la planification est essentielle, sur la base d’exigences connues et maîtrisées.
Invariant 3 : La conduite du changement doit adopter une méthode agile.
Le critère le plus important et le plus variable suivant les contextes est celui de l’équipe projet.
La mise en oeuvre d’un ERP dans une organisation va dans un premier temps déstabiliser la structure, puis, avec un phénome de résilience, le projet va apporter les bénéfices attendus. Pour réussir cet objectif, l’équipe projet doit prendre en compte très tôt les éventuelles résistances aux changements. Cette anticipation nécessaire se fait par la détection des signaux faibles et là encore, les méthodes adaptatives offrent un réel avantage pour réduire le risque de rejet du produit.
Ce qui s’applique à l’Entreprise doit également s’appliquer à l’équipe projet, dont chacun des membres est l’ambassadeur du projet. L’agilité permet de partager une vision commune tout au long du projet au travers des différentes « cérémonies » (Daily, Rétrospectives)…
Pas de ROI sans adhésion. Pas d’adhésion sans conduite du changement.
Réussir son projet ERP : Deux constats à l’encontre des idées reçues.
Nous établissons le double constat suivant, afin d’aller également à rebours de certaines idées reçues.
- Constat n°1 : L’agilité, oui, mais sans s’agiter
Au-delà de la méthode, les outils existent et permettent à l’équipe projet de collaborer en transparence. Toutes les parties prenantes (intégrateur, clients, Sponsors) partagent la même source d’information. C’en est fini du fameux « effet tunnel » des méthodes prédictives.
Les rôles changent et le chef de projet des méthodes prédictives devient le facilitateur de projet dans les méthodes adaptatives.
- Constat n°2 : Le prédictif déceptif ?
L’utilisation des méthodes prédictives nous donne l’illusion de la certitude : Certitude sur la date de démarrage et sur le contenu. Cette fausse assurance pousse les entreprises à prendre des engagements forts dès le démarrage du projet. La pression qui en résulte sur l’équipe projet, fournisseur du produit, peut induire une non-qualité préjudiciable aux engagements à venir. Le « contrat » prime sur le résultat.
Conclusion partielle, voire partiale…
Un projet à dominante prédictive permet de mieux répondre à des exigences légales, de type facturation électronique, exigences qui évolueront peu fréquemment avec la réglementation. Un projet à dominante adaptative est plus approprié en vue de répondre à un besoin métier qui changera souvent avec la demande de nouveaux usages.
Même si les projets répondant aux exigences légales réglementaires ont un caractère certain dans leurs mises en application, il peut arriver qu’ils soient décalés, la facturation électronique en est un bon exemple, et la reprise d’un projet en cycle en V nécessite un effort important. Une dose d’agilité permet alors d’identifier un ensemble minimal de fonctionnalités (MVP) qui pourront être complétées lors de la reprise du projet.
À contrario, pour la maintenance de projets menés en agilité, il peut être intéressant d’utiliser certaines pratiques des méthodes prédictives pour :
- Un projet qui nécessite peu d’évolutions ;
- Géré par des équipes de support, habituées à une documentation structurée par objets techniques ;
- L’utilisation de livrables (comme les spécifications par objet technique).
Le bon équilibre réside dans le dosage adéquat des méthodes, au service d’un même but : sécuriser le projet.