Les programmes technologiques sont couramment jugés terminés à la mise en service, la conduite du changement se réduisant à un calendrier de formation livré dans les dernières semaines. La formation a lieu, la présence est enregistrée, le programme se clôture, et six mois plus tard l'organisation découvre que la moitié est retournée à l'ancien tableur, à l'ancien processus, à l'ancien contournement, parce que personne n'a réellement construit les conditions pour que la nouvelle façon de travailler s'installe durablement.
Ce n'est pas un échec de communication qu'un meilleur support de présentation corrigerait. C'est un échec structurel qui consiste à ne pas traiter l'adoption comme un problème d'ingénierie ayant sa propre conception, ses propres incitations et sa propre mesure, plutôt que comme une réflexion secondaire accrochée à la fin d'un calendrier de livraison.
La présence ne prouve rien
Un taux d'achèvement de formation indique que des personnes se sont assises dans une salle ou ont parcouru un module. Il ne dit rien sur leur capacité à utiliser le système sans accompagnement, sur leur confiance suffisante pour abandonner leur ancien contournement, ni sur le fait que leur manager continue discrètement de demander l'ancien rapport dans l'ancien format, ce qui annule chaque heure de formation dès le premier jour.
Les indicateurs d'adoption qui comptent observent le comportement dans le système en production plusieurs semaines après la mise en service: quelle proportion des transactions passe par le nouveau processus sans contournement, à quelle fréquence l'ancien système ou tableur est encore utilisé, à quelle vitesse les utilisateurs se remettent d'une erreur sans escalade. Ces éléments sont plus difficiles à collecter qu'une feuille de présence, ce qui explique pourquoi la plupart des programmes se contentent de la feuille de présence.
La mise en service n'est pas la ligne d'arrivée. C'est le point où le véritable travail d'adoption commence, et c'est précisément là que la plupart des programmes cessent de prêter attention.
La compétence doit être construite avant la mise en service, pas annoncée à ce moment-là
Une construction de compétences véritable ressemble moins à un calendrier de formation qu'à une montée en puissance délibérée: une exposition précoce au système réel avec des données réelles bien avant la mise en service, un groupe défini d'utilisateurs précurseurs confiants qui deviennent un soutien par les pairs plutôt qu'un ticket de support, et suffisamment de répétition pour que la nouvelle façon de travailler devienne le réflexe par défaut plutôt que l'alternative laborieuse.
Là où cela est bien fait, la date de mise en service cesse d'être le moment où l'adoption commence pour devenir simplement le moment où les roues stabilisatrices sont retirées. Là où cette étape est sautée, la mise en service est le premier moment où la plupart des utilisateurs rencontrent réellement le système, et la confusion qui en résulte est à tort diagnostiquée comme un problème du système plutôt que comme un problème de conception de l'adoption.
Les incitations décident discrètement du résultat
Les gens n'adoptent pas de nouvelles façons de travailler parce qu'on le leur a dit; ils les adoptent parce que la nouvelle méthode est réellement plus facile, ou parce que l'ancienne a été rendue réellement plus difficile, ou parce que quelqu'un dont l'avis compte pour eux utilise visiblement le nouveau système et s'attend à ce qu'ils fassent de même. Les programmes qui ignorent la conception des incitations et misent uniquement sur la communication parient contre le comportement humain le plus élémentaire.
Cela inclut les incitations des managers, pas seulement celles du personnel de première ligne. Si le reporting d'un manager fonctionne encore sur l'ancien système, ou si les entretiens de performance font encore référence aux anciens indicateurs, l'équipe de terrain comprendra correctement que le nouveau système est optionnel et se comportera en conséquence, quel qu'ait été le message du courriel de lancement.
- ·Retirer l'ancien système ou processus à une date fixe plutôt que d'autoriser un fonctionnement parallèle indéfini
- ·Aligner le reporting des managers et les entretiens de performance sur le nouveau système avant la mise en service, pas après
- ·Identifier et équiper des précurseurs visibles capables de modéliser le nouveau comportement de façon crédible auprès de leurs pairs
- ·Mesurer directement l'usage des contournements, pas seulement l'achèvement de la formation, comme signal d'adoption principal
Mesurer le comportement, pas la présence
Un tableau de bord d'adoption sérieux suit l'écart entre le processus conçu et le comportement réel dans le temps: fréquence des contournements, temps de récupération après erreur, proportion d'utilisateurs qui ne se sont pas connectés depuis une période définie, et si cet écart se réduit ou stagne. Rien de tout cela n'exige d'outillage exotique; l'essentiel se trouve déjà dans les journaux système que personne n'a pris la peine d'interroger à cette fin.
Rapporter cela honnêtement, y compris quand l'adoption stagne, est inconfortable pour un programme qui souhaite se déclarer victorieux à la mise en service. Mais c'est le seul moyen de détecter une courbe d'adoption défaillante assez tôt pour intervenir, plutôt que de la découvrir un an plus tard sous la forme d'un retour discret et coûteux à l'ancienne façon de travailler.
Traiter l'adoption comme une discipline d'ingénierie, avec sa propre conception, ses incitations et sa mesure, demande plus de travail que de dérouler un calendrier de formation en espérant le meilleur. C'est aussi la différence entre un investissement technologique qui change réellement le fonctionnement de l'organisation et un investissement qui change simplement le logiciel installé pendant que les anciennes habitudes se poursuivent en dessous.
Le dernier kilomètre est rarement glorieux, et il reçoit rarement le budget ou l'attention accordés à la phase de construction. Mais c'est ce kilomètre qui détermine si tout ce qui précède valait la peine d'être fait.