L'adoption : une question multifactorielle

L'adoption, le chainon manquant entre le projet et la valeur ?

L'adoption des systèmes digitaux est un chainons indispensables au succès des transformations digitales. Peut-être le chaînon manquant de notre approche classique. Sans adoption par les utilisateurs, il n'y a pas de gains, pas de dynamique créé par la nouveauté technologique.

Et les systèmes d'information sont répandus dans l'industrie depuis quelques décennies, mais à vraiment grande échelle depuis 20 à 30 ans, ce qui est relativement peu par rapport aux machines, que l'industrie installe depuis 200 ans. Nous avons encore à apprendre de ces deux mondes. Les deux sont des investissements, donc les gains doivent compenser le coût de leur acquisition et de leur mise en place. Les deux font appel à la gestion de projet, même si celle-ci évolue pour prendre en compte les spécificités des projets digitaux. Coté différences, les systèmes d'information sont complexes, et bien plus intrusifs sur le travail de leurs utilisateurs, sur leur manière de faire, que les machines par exemple.

Les objets d'investissements traditionnels changent peu le travail.

Traditionnellement, un projet commence par un cadrage, une étude stratégique, puis une fois la décision prise, on exécute. Jusqu'à ce que l'objet du projet soit en place. Dans le cas d'une machine, elle est installée dans l'atelier, et les équipes sont formées au spécificités de cet équipement. Mais en général, le travail autour de la machine ne change pas fondamentalement. On prévoit un temps d'apprentissage, de montée en production, et ensuite c'est bon, les utilisateurs savent opérer leur équipement. Néanmoins, on a entre dans une phase d'amélioration continue, où les opérateurs et les dépanneurs se rencontrent, et des décisions peuvent être prises pour améliorer l'utilisation de la machine : correction de pannes récurrentes par une modification, ajustement des manière de faire pour mieux profiter de telle ou telle fonctionnalité.

Les systèmes d'information sont beaucoup plus intrusifs sur le travail.

Un nouveau logiciel va transformer, parfois de manière extrêmement importante, la manière dont les personnes travaillent. En effet, mettre en place un système d'information redéfini tous les flux de données. En général, les flux de données manuels ou intuitifs deviennent automatiques et formels. Par ailleurs, de nombreuses tâches sont automatisées, selon une séquence et une logique propre au logiciel. Et donc forcément en écart, au moins minime, avec les manières de faire antérieures à son installation. Il faut donc que les personnes changent leur manière de faire. Et c'est parfois très intrusif.

Prenons pas exemple un logiciel de pilotage de la maintenance. Avant son installation, l'ouvrier dont la machine est en panne appelle son collègue au téléphone, décrit oralement le problème, et le technicien vient discute, traite la question d'un point de vue purement technique, va éventuellement voir le magasinier pour sortir une pièce du stock de pièces de rechange, et une fois la machine réparée, ils vont prendre un café et c'est reparti. L'expérience entre dans la tête du dépanneur, où elle s'accumule avec d'autres pour construire sa compétence spécifique. Et les coûts sont ventilés par une autre personne selon les usages de l'entreprise, en fonction de clé de répartition définies.

Avec la nouvelle GMAO (Gestion de Maintenance Assistée par Ordinateur), l'ouvrier tape un code sur l'écran, le dépanneur arrive (après que le ticket lui ait été attribué), répare la machine, éventuellement réserve une pièce de rechange dans le système avant d'aller la chercher, et tout cela se termine toujours au café. En plus d'avoir acquis de la connaissance, le dépanneur a saisi des données dans le système, qui constitue une base de compétence externe, et tous les coûts ont été attribués automatiquement au bon endroit. Dans cet exemple, on voit qu'une partie du travail fait pour la répartition des coûts revient finalement au dépanneur lui même (qui doit saisir son activité), et que l'accumulation de compétence et donc l'analyse de l'activité est au moins en partie sortie de son périmètre. Ça change bigrement le métier du dépanneur ! Ce changement, illustré ici de manière caricaturale pour un logiciel de maintenance, il se retrouve à chaque mise en place de nouveau système. D'où la nécessité de la conduite du changement.

L'adoption : un autre mot pour la conduite du changement ?

Vu de très loin, adoption et conduite du changement sont proche. Néanmoins, l'adoption s'attache aux systèmes d'information, et nécessite un ensemble de moyens, organisations et structure qui dépassent largement la conduite du changement, même si elle s'en nourrit.

Les points communs entre ces deux notions, conduite du changement et adoption, sont les leviers humains que l'on active. Et en fait c'est tout. C'est déjà pas mal, mais tout le reste diffère.

Là ou la conduite du changement se déploie pendant le projet (entre le moment où le projet est conçu et le "GoLive" d'un système d'info), l'adoption se déploie principalement après ce moment, lorsque les utilisateurs se saisissent du sujet et s'approprie l'outil. Ou pas. Par ailleurs, une adoption réussie nécessite la mise en place de plusieurs leviers, dans plusieurs champs de l'organisation.

• Mettre à disposition le support adéquat. Les utilisateurs ont besoin de pouvoir se référer à une documentation, une aide, quelle qu'en soit la forme, pour pouvoir répondre à leur questions les plus simples. C'est à ce niveau qu'interviennent tous les outils supportant l'adoption (plate-forme d'adoption, outils de mise à disposition de formation, etc.). Ici, on ne créé par d'information, on diffuse une information disponible.

• Mettre en lien les utilisateurs, pour identifier les bonnes pratiques dans le temps, et créer les lieux où les questions trouvent leur réponse, où l'usage s'affine. C'est dans ces réseaux que les utilisateurs acquièrent la compétence d'utiliser les systèmes, et que par extension l'ensemble de l'organisation acquière et capitalise ces compétences, par leur partage. Ici, on créé de l'information et du savoir, du savoir faire, des décisions sur les bonnes manière de faire et d'utiliser les outils.

• Clarifier la gouvernance. C'est à dire qui décide quoi en matière d'évolution des systèmes d'information. Et là ça se complique, car pour que l'adoption soit la meilleure possible, il faut en général résoudre des conflits d'objectifs entre les utilisateurs, et les équipes informatique, entre les besoins opérationnels et les capacités techniques. Pour que cela fonctionne, la gouvernance précise à chaque niveau de problème (du plus immédiat au plus structurant), comment se résolvent ces tensions, inhérentes à toute organisation.

Conclusion : l'adoption est une question multidimensionnelle à prendre dans son ensemble pour le succès de la digitalisation

Dans cette logique, l'adoption devient une problématique multidimensionnelle, qui nécessite d'adresser de nombreux sujet qui peuvent paraître simples dans leur énoncé, mais qui deviennent extrêmement complexe dans leur mise en œuvre, tant ils sont intimement liés à la culture et au métier, au pratiques relationnelles dans l'entreprise. Travailler ce sujet n'est pas un problème technique, mais fondamentalement humain et organisationnel. Il requiert donc une compétence spécifique dans ces domaines, tout en ayant une compréhension approfondie des problématiques techniques, pour permettre de relier l'ensemble des acteurs autour des bons sujets, avec les bonnes routines et pratiques.