Lors d’un projet ERP auquel j’ai participé, j’ai eu beaucoup de mal à former les utilisateurs au nouveau logiciel pendant la phase de préparation. Il était même difficile de prendre rendez-vous avec les utilisateurs clés , on me répondait toujours “je suis trop occupé”, “peut-être la semaine prochaine”, etc.
Et même quand j’obtenais l’attention d’un utilisateur, il suivait la démonstration quelques minutes puis déclarait : “Mais pourquoi tout changer ? on travaille bien avec le logiciel actuel !”. Certains ont même tenté de me démontrer que le logiciel actuel était meilleur que celui que j’essayais d’implémenter !
Pour ma part, j’étais convaincu du contraire, j’en ai donc parlé à la direction. Et il a été décidé qu’on procéderait au lancement du nouvel ERP à la date prévue, et que s’il restait des utilisateurs qui ne maîtrisaient pas assez le logiciel… et bien, ils n’auraient qu’à s’adapter !
Le lancement a bien entendu été chaotique. Les utilisateurs ne savaient pas comment accomplir leurs tâches quotidiennes, ils ont trouvé que le logiciel était trop compliqué, qu’il ajoutait des étapes de validation inutiles, qu’il lui manquait des fonctionnalités, etc.
Il y a même des besoins métiers qu’on m’a communiqués pour la première fois la semaine suivant le lancement. Tout le monde avait l’impression que le nouvel ERP n’était pas capable de faire le travail, au point que le projet a failli échouer, certains membres de l’équipe demandaient le retour vers l’ancien logiciel.
Mais pourquoi un tel échec ? Les données étaient pourtant bien importées, l’ERP correctement configuré, l’interface était fluide et on pouvait facilement trouver ce que l’on cherchait. Pourquoi les utilisateurs n’ont-ils pas instantanément adopté un ERP que je considérais comme nettement meilleur que leur ancien système ?
Parce qu’un projet ERP n’implique pas de changer uniquement un logiciel
Le besoin d’un nouvel ERP vient le plus souvent d’un besoin organisationnel plutôt que technique. Dans la plupart des entreprises qui décident de changer de logiciel, cette décision vient d’une volonté d’améliorer un processus, de réduire le temps nécessaire à une opération ou de limiter les erreurs. Si le logiciel actuel ne permet pas ces améliorations, l’entreprise envisage naturellement de le remplacer.
Le projet naît donc de la nécessité de transformer des habitudes, des responsabilités ou des circuits de validation. Il est donc primordial de préparer ces changements avant de déployer la solution logicielle censée permettre ce changement.
Si l’entreprise estime qu’il faut ajouter une étape de vérification avant de charger une marchandise, il serait judicieux d’ajouter cette étape avant d’implémenter la validation sur le nouvel ERP. De cette façon, les employés seront habitués à la procédure au déploiement du logiciel ; ils n’auront pas l’impression que l’ERP a compliqué leur journée en ajoutant une étape.
Si vous ajoutez une validation par le caissier au moment des encaissements, demandez à votre caissier d’effectuer la validation, même si son logiciel actuel ne le permet pas. Même un bon en papier pourrait faire l’affaire, quand vous lancerez l’ERP et qu’il permettra la validation, l’amélioration sera nettement visible.
Un ERP peut être techniquement irréprochable et quand même paraître faible, voire inutile si l’on oublie d’intégrer la composante humaine lors de son implémentation.
Parce que les utilisateurs n’ont pas été impliqués dans le projet
Dans pratiquement toute entreprise, l’utilisateur clé connaît des choses que la direction ou le chef de projet ne connaissent pas forcément. Il connait les contournements, les opérations manuelles, les fichiers Excel parallèles, et même les exceptions qui n’apparaissent dans aucune procédure.
Ces utilisateurs sont un grand atout dans un projet ERP, il faut s’approcher d’eux avant même de rédiger la version finale du cahier des charges. Il est essentiel de comprendre leurs difficultés, ce qu’ils font pour combler les manques du logiciel actuel, de leur demander ce qu’ils aimeraient que le logiciel soit capable de faire…
Premièrement, c’est le meilleur moyen de faire remonter les vrais besoins métier, souvent, les besoins exprimés lors des réunions de direction ne sont que la partie visible de l’iceberg. Il existe toujours des besoins qu’un employé n’a jamais exprimés. Parfois, ils ne savent tout simplement pas qu’un logiciel peut le faire !
Ensuite, il est beaucoup plus facile d’introduire une nouveauté auprès des utilisateurs en disant : “Vous vous rappelez quand vous aviez demandé telle fonctionnalité ? eh bien, je vous ai trouvé une solution, essayez ça !” La personne se sentira écoutée, elle n’aura pas l’impression que son avis ou ses efforts ont été négligés, mais plutôt qu’elle a réellement participé au processus. L’employé s’appropriera davantage le projet qu’il a contribué et aidera à le mener à terme dans de bonnes conditions au lieu d’y résister.
C’est nettement plus efficace que d’essayer de convaincre les utilisateurs qu’un nouveau logiciel dont ils n’ont jamais entendu parler est meilleur que ce qu’ils utilisent tous les jours depuis des années.
N’implémentez pas un ERP pour les utilisateurs… Implémentez-le avec eux !
Parce qu’une formation n’est pas de la préparation au changement
Prévoir des séances de formation, collectives ou individuelles aidera certainement vos équipes à savoir comment utiliser le nouveau logiciel. Mais ce qu’on oublie souvent est que les utilisateurs ont d’abord besoin de savoir pourquoi l’entreprise est en train de changer d’ERP.
Un employé habitué depuis des années à un processus y trouve une certaine sécurité. Si le processus est problématique, il se peut qu’il se soit habitué à s’y adapter ou à le contourner. Il se peut même que l’employé soit convaincu que son contournement résout le problème, il est peut-être fier d’avoir inventé la solution.
Il est donc tout à fait normal que quelqu’un se sente menacé par un changement brutal, ça le sort de sa zone de confort, le changement sera perçu comme déséquilibrant. Il essayera alors de vous convaincre que son contournement est meilleur, plus simple ou moins coûteux.
Et il n’aura que partiellement tort. Un employé concentré sur sa tâche n’a pas toujours le recul nécessaire pour avoir une vision d’ensemble. Il peut résoudre un problème à son niveau sans se rendre compte que sa solution en crée un autre dans un service différent.
Quand un employé ne perçoit pas le problème que la direction chercher à résoudre, quand il ne voit pas le bénéfice direct pour son propre travail, il ne peut se concentrer que sur les contraintes immédiates du changement. Si les nouveaux processus impliquent des étapes supplémentaires de validation, il peut même croire qu’on ne lui fait pas confiance. Ce n’est pas forcément de la mauvaise volonté, il s’agit d’une résistance naturelle à un changement qu’on ne comprend pas. Dans beaucoup de cas, l’utilisateur qui résiste est convaincu qu’il rend service à l’entreprise en refusant une mauvaise décision.
C’est pour cette raison que la conduite au changement doit intervenir dès les premières phases du projet ERP. Le fait d’exposer aux équipes les problèmes rencontrés et les changements envisagés les aidera à comprendre le pourquoi du changement et à s’impliquer dans la mise en production de l’ERP.
Apprendre à un utilisateur comment utiliser un logiciel ne l’aidera pas à comprendre pourquoi il doit le faire
Et si la résistance n’était pas le problème ?
Après tout ce qui vient d’être dit, on pourrait conclure qu’un bon projet ERP doit pouvoir faire accepter le changement aux utilisateurs… Mais ce serait aller un peu trop vite. La résistance n’est pas toujours le problème, elle pourrait, dans certains cas, être le symptôme d’un problème avec le projet lui-même !
Dans l’anecdote racontée en introduction, les utilisateurs affirmaient que l’ancien logiciel était meilleur. À l’époque, j’y voyais seulement une résistance au changement. Mais avec le recul, certaines de leurs remarques auraient dû être étudiées plus sérieusement. Le projet aurait gagné à prendre en compte ce que ceux qui utilisent le logiciel à longueur de journée attendent vraiment d’un ERP.
Un utilisateur peut résister à un nouveau logiciel pour l’une ou l’autre des raisons traitées plus haut, il peut aussi résister pour défendre ses habitudes, mais également réagir à un processus mal conçu, à un besoin ignoré ou à une contrainte réelle introduite par le projet.
Il arrive parfois que l’ERP ajoute une complication inutile, ou qu’un besoin mal compris alourdit les processus au lieu d’accélérer leur exécution.
Il ne faut donc pas commettre l’erreur de prendre toute remarque pour de la résistance au changement, il vaut toujours mieux écouter ce que les utilisateurs pensent, puis décider de la nature de la remarque ou de la résistance.
La résistance n’est pas forcément un obstacle qu’il faut faire disparaître à tout prix, elle peut signaler qu’un élément du projet n’a pas suffisamment été pris en compte.
Au début du projet raconté en introduction, nous avons essayé de résoudre les problèmes au moment où nous rencontrions les utilisateurs : leur apprendre le logiciel, répondre à leurs questions, leur montrer que le nouvel ERP était meilleur.
Mais beaucoup de ces problèmes auraient dû être traités beaucoup plus tôt.
Si nous avions mieux communiqué avec l’équipe sur les nouveaux processus, les difficultés rencontrées par les utilisateurs et les raisons de ces changements, nous aurions pu mieux préparer l’entreprise et le logiciel à la mise en production.
Surtout, si nous avions considéré leurs remarques comme des informations plutôt que de simples manifestations de résistance au changement, certaines difficultés auraient pu être détectés avant le jour du lancement.
C’est peut-être l’une des principales différences entre un projet ERP que l’on subit au moment du lancement et un projet ERP que l’on prépare réellement : dans le premier cas, on est obligés de gérer les problèmes au fur et à mesure qu’ils se présentent. Dans le second, on essaie de les découvrir à un moment où il est encore possible de les corriger sans bloquer le fonctionnement de l’entreprise.
Un projet ERP est donc bien plus qu’un projet technique. Le logiciel n’est finalement que l’outil qui permet de mettre en œuvre une transformation qui, elle, est d’abord humaine et organisationnelle.