Faire adopter un nouveau système de gestion par les salariés : un plan pratique

Un système de gestion que personne n’utilise n’est pas un projet réussi à moitié : c’est un coût entier, avec en plus un second système à maintenir, parce que l’ancienne méthode continue à tourner en parallèle. Le moment où se décide si cela va arriver n’est pas le jour de la mise en service. Ce sont les semaines précédentes, quand les personnes qui devront l’utiliser sont écoutées ou ne le sont pas.

L’adoption n’est pas une question de bonne volonté des salariés. C’est une question de la mesure dans laquelle le nouveau système aide ou entrave le travail de chacun au moment où il le fait. Celui qui trouve un raccourci plus rapide en dehors du système l’utilisera, et il aura raison.

Qui impliquer, quand il est encore possible de changer d’avis

Impliquer ne signifie pas convoquer une réunion de présentation une fois les décisions prises. Cela signifie amener à la table, pendant la cartographie, les personnes qui connaissent les cas que personne d’autre ne connaît.

• Celui qui exécute l’opération la plus fréquente, celle qui se répète des dizaines de fois par jour : c’est la personne qui paie chaque clic supplémentaire.
• Celui qui gère les exceptions, c’est-à-dire celui à qui tout le monde demande quand le cas est étrange. Ce n’est généralement pas un responsable.
• Celui qui reçoit le travail en aval et subit les erreurs commises en amont.
• Celui qui parle avec les clients, parce qu’il sait quelles informations sont demandées et à quel moment.

Le processus décrit par la direction est celui qui est prévu. Celui qui est réellement exécuté contient des dérogations, des raccourcis et des cas particuliers que quelqu’un résout de mémoire depuis des années. La différence entre les deux est la mesure du risque du projet.

Former sur les tâches, pas sur les fonctions

La formation la plus répandue est une visite guidée des menus : on montre le système écran par écran à tout le monde ensemble. C’est le format qu’on oublie le plus vite, parce qu’aucune des personnes présentes n’apprend son propre travail, mais le travail de tout le monde.

La formation utile part des tâches réelles de chaque rôle et utilise des données réelles, ou au moins réalistes. Elle doit se faire proche du moment où l’on commencera à utiliser le système : si trois semaines passent entre la formation et la mise en service, elle doit être refaite.

Fermer les anciens outils, ne pas les faire coexister

Tant que l’ancienne feuille de calcul reste accessible et pratique, une partie des personnes continuera à l’utiliser. Pas par résistance au changement : parce que ça fonctionne, qu’elles la connaissent et qu’à ce moment-là elles sont pressées.

1. Déclarer une date après laquelle l’ancien outil devient en lecture seule, et la respecter.
2. Importer l’historique qui sert vraiment au travail quotidien, pas toute l’archive : le reste reste consultable ailleurs.
3. Supprimer les raccourcis qui permettent de continuer comme avant, par exemple les formulaires papier encore en circulation.
4. Remplacer, ne pas additionner : si le nouveau système demande une donnée en plus sans en retirer une, l’adoption entre directement en concurrence avec le temps des gens.

La double saisie « par sécurité » doit être décidée explicitement, avec une durée déclarée et une date de fin. Si elle reste indéfinie, elle devient permanente, et à ce moment-là le nouveau système est perçu comme un travail supplémentaire — ce qu’il est effectivement devenu.

Où vont les doutes

Si la réponse à un doute dépend de qui est disponible à ce moment-là, les gens arrêtent de demander et recommencent à improviser. Il faut un parcours unique et connu de tous.

• Un référent par département, choisi parmi ceux qui ont participé à la cartographie, avec du temps effectivement alloué à cette tâche.
• Un seul endroit où l’on écrit les problèmes : pas les couloirs, pas les messages privés au consultant, pas les e-mails à des personnes différentes.
• Une règle déclarée sur ce que l’on fait quand le système ne permet pas une opération urgente : qui on appelle, ce qu’on note, comment on corrige après.
• Un délai de réponse attendu, même large, pourvu qu’il soit connu : savoir que la réponse arrive demain vaut mieux que de ne pas le savoir.

Le registre des problèmes, et qu’en faire

Le registre ne sert que si quelqu’un le lit régulièrement. Les champs utiles sont peu nombreux : qui, quand, ce qu’il faisait, ce qu’il attendait, ce qui s’est passé, comment il a résolu en attendant.

À la lecture hebdomadaire, chaque entrée va dans l’une de trois catégories : anomalie du système, qui se corrige ; connaissance manquante, qui se réexplique, éventuellement à tout le monde si elle se répète ; processus non prévu, qui exige une décision de l’entreprise et non du fournisseur. Confondre la troisième avec la première est le moyen le plus rapide de rendre infinie la liste des modifications.

Mesurer l’adoption : activités menées à terme, pas connexions

Les connexions disent que les gens entrent. Elles ne disent pas que le travail passe par là. Les signaux qui décrivent vraiment l’adoption sont différents.

• Part des opérations de la période enregistrées dans le système par rapport à celles réellement survenues.
• Opérations menées à terme sans correction ultérieure, qui indiquent si les gens savent les faire ou procèdent par tâtonnements.
• Délai entre le fait et son enregistrement : s’il augmente, le système est vécu comme une formalité et non comme un outil.
• Nombre de demandes d’aide sur le même point : indique où le système ou l’explication ne fonctionnent pas.

Ces signaux doivent être observés par département. Une bonne adoption moyenne peut cacher un département à l’arrêt, et c’est ce département d’où viendront les données manquantes qui gâchent les vues de tout le monde.

Quand il vaut mieux reporter ou partir plus petit

Il y a des moments où la même introduction, bien faite, échoue quand même, et il vaut mieux les reconnaître à l’avance.

• Une période de pic saisonnier, ou une échéance qui absorbe l’attention de l’entreprise.
• Aucune personne interne avec du temps alloué pour suivre la mise en service : le fournisseur ne peut pas la remplacer.
• Un processus encore en discussion entre départements : le système rendrait visible un désaccord qu’il faut résoudre avant, et pas avec le logiciel.
• Une fonction essentielle pas encore prête : mieux vaut partir d’un département ou d’un type d’opération et élargir ensuite.

Partir d’un groupe restreint a un avantage qui va au-delà de la prudence : cela produit des personnes internes qui savent utiliser le système et peuvent l’expliquer aux autres avec les mots de l’entreprise, qui fonctionnent mieux que ceux du manuel.

Ce que ce guide ne couvre pas

Ici, il est question de l’adoption organisationnelle : qui impliquer, comment former, comment clore le passé, que mesurer. Les tests techniques à faire avant de mettre le logiciel en usage quotidien — cas limites, données de test, vérifications sur les calculs et les permissions — sont traités dans le guide dédié à la recette. Le choix de ce qui entre dans la première version et de ce qui attend a lui aussi son propre guide.