Retour au blog

Réflexions sur la mise en œuvre des logiciels d'entreprise et les méthodologies de gestion de projet.

Tout projet de mise en œuvre d'un ERP, quelle que soit la méthodologie utilisée ou la façon dont les phases sont nommées, est structuré de la même manière typique.

  1. Lancement du projet
  2. Planification
  3. Conception
  4. Développement
  5. Essai
  6. Gestion de la formation et du changement
  7. Préparation au lancement
  8. Passage en direct
  9. Assistance après mise en service
  10. Clôture du projet

Et c'est ainsi depuis au moins 30 ans. Lorsque les entreprises ont commencé à utiliser la méthode « Agile » pour les projets (et je sais que je simplifie ici), cela n'a pas vraiment changé la façon de faire les choses ; cela signifiait souvent simplement que la conception détaillée, le développement et les tests sont devenus des cycles itératifs.

  1. Initiation et planification
  2. Découverte et conception
  3. Développement et tests itératifs
  4. Formation des utilisateurs et gestion du changement
  5. Préparation au lancement
  6. Mise en service et stabilisation
  7. Amélioration continue

De plus, lorsque le concept d’« amélioration continue » a été introduit, peu d’organisations savaient comment l’intégrer à leur fonctionnement, notamment lorsque l’équipe de projet de mise en œuvre est dissoute.

La structure utilisée pour organiser un projet ERP, telle que décrite en introduction, repose sur la compréhension qu'une plateforme applicative logicielle soutient (ou devrait soutenir) une organisation : ses objectifs stratégiques, sa structure organisationnelle, son implantation géographique, ses départements, ses processus métier, ses indicateurs clés de performance (KPI) et les besoins de tous les employés en matière d'efficacité et de productivité. Le projet débute donc par une analyse de l'entreprise : son fonctionnement actuel, son organisation et ses exigences et objectifs (stratégiques). Cette analyse porte sur les besoins métier, les exigences des processus et les objectifs de l'entreprise. Dans une moindre mesure, elle s'intéresse aux exigences informatiques : ce sont les objectifs et les exigences métier qui (devraient) déterminer les exigences informatiques. Font exception les exigences de migration et d'intégration d'applications ; dans ce cas, la demande provient de la technologie elle-même.

En résumé, la méthodologie employée lors des projets ERP consiste à analyser les besoins et à concevoir l'organisation proposée, les processus (modifiés et nouveaux) et les applications, à construire la plateforme applicative à partir de cette conception, puis à former et valider les nouveaux processus et outils. La dernière étape consiste à mettre le système en production, à assurer le support de l'organisation et à résoudre tous les problèmes rencontrés au cours des premiers jours, semaines ou mois suivant la mise en production.

La question est de savoir dans quelle mesure les méthodologies de mise en œuvre fondées sur les principes susmentionnés sont réellement efficaces. De nombreux projets ERP échouent aujourd'hui, ou du moins sont considérés comme peu concluants. Un projet est désormais considéré comme réussi s'il offre au moins les mêmes fonctionnalités que l'ancien système (remplacé), et la mise à jour de la technologie aux normes actuelles est perçue comme un succès.

Et c'est étrange, si le projet est considéré comme une réussite alors que le seul avantage réside réellement dans la nouvelle technologie et que l'organisation, en termes de culture, de processus et de soutien aux buts et objectifs, n'a pratiquement rien gagné. La question est : pourquoi s'obstiner à utiliser cette méthodologie ?

Les défis que représentent les implémentations ERP actuelles peuvent être résumés comme suit :

  1. L'organisation est déçue des résultats.
  2. Le projet prend plus de temps que prévu.
  3. Le projet coûte plus cher que prévu.
  4. Il existe une frustration entre le partenaire de mise en œuvre et le client

Lorsque nous essayons de relier ces frustrations à l'organisation du projet de mise en œuvre ou à la méthodologie utilisée, nous pouvons affirmer que les domaines suivants sont les principales causes des échecs de mise en œuvre des ERP :

  1. Gestion et gouvernance de projet : dérive des objectifs, problèmes d’allocation et de disponibilité des ressources, et bien sûr, l’incapacité du chef de projet à organiser le projet faute de soutien ou parce que la méthodologie n’est pas mise en œuvre dans l’organisation et que l’organisation/la direction ne la comprend pas.
  2. Gestion du changement et formation des utilisateurs : les employés résistent au changement par manque de familiarité avec le système, par crainte de perdre leur emploi ou par manque de formation et de communication adéquates. On sous-estime souvent l’ampleur et la profondeur de la formation nécessaire aux utilisateurs pour bien comprendre le projet. Bien entendu, plus tard, la formation à l’utilisation du nouveau système et des nouveaux processus est insuffisante et inefficace.
  3. Impact culturel et organisationnel : Le manque de vision et d’objectifs communs entre les départements et les parties prenantes est un problème fréquent dans de nombreux projets. De plus, le projet n’est pas aligné sur les objectifs stratégiques de l’entreprise et sa direction refuse d’en reconnaître l’importance (d’où un manque de soutien considérable), ce qui constitue un facteur majeur d’échec et de frustration. Par ailleurs, en matière de gestion du changement, la transformation culturelle nécessaire à l’adaptation aux nouveaux processus et outils est souvent sous-estimée, voire ignorée, ce qui engendre également déception et frustration. Deux autres points importants : la communication et la flexibilité. La direction ne prend conscience que trop tard de la pression exercée par le projet (le changement) sur l’organisation, ce qui provoque un climat de panique et réduit la flexibilité, la créativité et l’ouverture à l’adaptation. On constate également que plus la situation se complique, plus la communication interne diminue et est négligée.
  4. Réingénierie des processus : Comme souligné précédemment, comprendre et documenter en détail les processus actuels avant de concevoir de nouveaux processus ou de migrer vers un nouveau système ERP est beaucoup plus complexe et chronophage que prévu, voire que ce que les organisations sont prêtes à accepter (ou à investir). Aligner les processus métier souhaités avec les processus standard du système ERP sans personnalisation importante peut s'avérer difficile et source de frustration, voire de démotivation, pour l'équipe projet.

Ces raisons sont-elles les seules sources de frustration et de problèmes de projet ? Il est important de noter que la migration des données est souvent mentionnée comme un défi. Bien qu'elle puisse entraîner des retards et des surcoûts dans certains projets, elle est rarement la cause de la déception ou de l'insatisfaction quant à la valeur ajoutée du projet pour l'organisation. De même, les difficultés liées au développement des personnalisations et des intégrations peuvent engendrer, voire entraîner, des surcoûts et des délais supplémentaires. Cependant, elles ne sont jamais la raison pour laquelle, après la mise en production, les utilisateurs ont le sentiment que leurs attentes ou leurs besoins n'ont pas été satisfaits. J'irais même jusqu'à dire que c'est le contraire : la livraison du logiciel est le seul élément réellement mesuré et contrôlé. Les fonctionnalités de l'application, la migration, les personnalisations, les intégrations, les rapports, etc., sont en réalité les aspects les plus faciles à gérer.

Et lorsque les évaluations de projet font apparaître les tests ou le soutien post-implémentation comme des défis, je dirais que cela est davantage lié à une mauvaise gestion de projet et/ou à la motivation de l'organisation à affecter le nombre adéquat de personnes et à reconnaître l'importance et l'impact du projet, comme mentionné précédemment.

Je pense que les raisons évoquées ci-dessus sont celles qui expliquent l'échec du projet et nous obligent à repenser la méthodologie que nous utilisons et à réfléchir aux ressources et aux compétences nécessaires pour gérer et mener à bien un projet ERP.

Il est important de mentionner qu'une méthodologie de déploiement de projet agile ou alternative a plus de chances de réussir que l'approche en cascade, pour des raisons de flexibilité et d'adaptabilité, d'implication des utilisateurs, d'atténuation des risques et de communication améliorée.

Il est également important de souligner que, selon moi, après la difficulté initiale de la mise en œuvre d'un système ERP, les projets d'amélioration continue auront bien plus de chances de succès et les organisations en retireront une valeur ajoutée considérable, à condition bien entendu qu'elles continuent de les encourager et fassent de l'ouverture au changement une valeur fondamentale. À cet égard, il convient de préciser que les systèmes cloud constituent l'outil idéal pour l'amélioration continue.

Je souhaite que ce document serve de base à des discussions et initie un dialogue au sein de p2-i, ainsi qu'avec nos partenaires et clients, afin d'améliorer notre organisation et nos services.

  1. Établir la méthodologie appropriée
  2. Organisons notre réunion du Premier ministre
  3. Embaucher les personnes nécessaires à l'exécution selon la méthodologie
  4. Former et former continuellement nos collaborateurs pour qu'ils réussissent dans notre méthodologie
  5. Former et organiser l'équipe commerciale afin qu'elle puisse vendre nos projets
  6. Réaliser les projets avec succès

J'adore entendre vos commentaires et opinions !

 

Écrit par Amit Kumar

9 décembre 2024