OUI MAIS QUEL ACCOMPAGNEMENT ?

Un accompagnement pour tous les utilisateurs
Nous l’avons indiqué en préambule : un ROI satisfaisant s’appuie sur (1) une solution fonctionnelle qui offre les données, les fonctionnalités et les performances attendues (2) une utilisation massive, et éclairée des applications mises à disposition, par l’ensemble des utilisateurs finaux concernés.

N’oubliez pas le mécanicien !
Se concentrer uniquement sur les utilisateurs finaux de la solution est une erreur répandue. Car enfin, si les réglages de votre voiture de course ne sont pas adaptés à votre style de conduite et au type d’usage que vous souhaitez en faire, vous ne tarderez pas à la laisser au garage et à reprendre votre berline familiale !
Et pour préparer le véhicule de façon adéquate, les mécaniciens doivent connaître au préalable toutes les capacités et leviers d’optimisation de la voiture, le parcours, la nature du revêtement, et le style de conduite du conducteur. CQFD.

Un transfert de compétences approfondi des capacités de l’outil et des caractéristiques métiers aux équipes en charge de conception et de la réalisation du projet est essentiel pour constituer le socle d’une adoption réussie

De la Formation, oui, mais pas que…
Une autre erreur commune consiste à associer Adoption à ‘Formation’ (et même, la plupart du temps, à ‘formation des utilisateurs finaux’, en présentiel bien entendu !)
Nous reviendrons plus tard sur l’importance de la formation. Celle-ci n’est cependant que la partie émergée de l’iceberg. Seule, elle est peu efficace.

Alors, en quoi consisterait cet accompagnement ?
Au risque de décevoir, nous ne livrerons pas ici de solution miracle, facile à mettre en œuvre, rapide, 100% efficace. L’accompagnement est multi-dimensionnel, et la solution adéquate propre à chaque entreprise, chaque projet, chaque typologie d’utilisation, chaque objectif (accélérer l’adoption de la solution ? L’optimiser post-implémentation – en volume, en qualité ?).

Pour autant, nous en connaissons les ingrédients

Informer
Tout simplement parce que tant que l’on ne sait pas ce que l’on ne sait pas, on ne peut pas savoir ce que l’on pourrait/voudrait faire et ce que l’on devrait ou non savoir faire (non, cette phrase n’est pas compliquée).
Avant d’envisager des formations et pour pouvoir les adapter au mieux, il est primordial de mettre à la disposition de tous les acteurs du projet les informations clés relatives :

• aux données à exploiter : qualité, sources, modalité d’intégration, niveau d’agrégation etc.
• à l’outil : capacités, terminologie, caractéristiques propres à l’outil, limitations éventuelles, bonnes pratiques, exemples d’application dans des domaines similaires ou connexes, évolutions attendues…
• à l’utilisation attendue de la solution : personnas, cas d’usages, processus et challenges actuels, souhaits à court, moyen et long terme (périmètre d’analyse, niveau d’analyse, mode d’exploration, degré autonomie, fréquence d’utilisation etc…)
• Au projet : pourquoi il est mis en œuvre ? Quand ? Comment cela va-t-il se passer ? Par qui ? Quels risques ? Quel impact ? Quelle contribution(s) attendue(s) ? A qui s’adresser…

Co-construire la confiance

On pourrait dire aussi : bâtir des ponts, des passerelles, des monte-charges entre tous les acteurs concernés. Ou plus concrètement : impliquer et habiliter des relais métier, planifier des points de rencontre, tester, collecter et traiter les retours, questionner, tester, questionner, tester. Etc.

Teaser (de teasing) ; créer et entretenir l’appétence (et tenir ses promesses)

Il ne s’agit pas nécessairement de communiquer beaucoup, mais bien de communiquer ‘juste’, pour créer un élan d’intérêt, l’entretenir et idéalement intensifier la dynamique jusqu’à ce que la solution soit véritablement adoptée. Communiquer juste, c’est donner, au bon moment, une information pertinente pour l’audience ciblée, de façon percutante, attrayante et engageante. Et surtout ne pas perdre de vue que ce qu’attendent les futurs utilisateurs, c’est essentiellement de pouvoir se représenter ce que la solution va pouvoir leur apporter, et si leurs mots maux ont été entendus, compris et adressés.

Audit technique : vérifier la conformité des développements aux bonnes pratiques pour garantir la performance et l’évolutivité du projet

Le saviez-vous ? 15 secondes, c’est peu… et pourtant considéré rédhibitoire. Un temps de réponse acceptable pour l’affichage d’une requête doit être inférieur à 5 secondes. De la même façon, de mauvais choix de conception, de développement ou d’administration de la plateforme ou du projet peuvent compliquer considérablement, voire limiter l’évolutivité d’un projet, ou, pire encore, générer des erreurs dans les restitutions (ex. : mauvais choix d’agrégation, méconnaissance d’un comportement de jointure…). Ces erreurs ou limitations créent frustration et défiance, et détournent immanquablement les utilisateurs de l’application. Si pertinente soit-elle par ailleurs.

Une parfaite connaissance théorique de l’outil n’est parfois pas suffisante. Qu’il soit résident ou externe, le recours à un spécialiste qui dispose à la fois d’une expertise transverse de l’outil et de l’expérience de la mise en œuvre de projets similaires est fortement recommandé. Il saura identifier, et indiquer le moyen de contourner les risques et / ou corriger les erreurs de développement susceptibles de discréditer la solution.
Economies garanties !

Habiliter

Ne devait-on pas parler de formation ? Oui, c’est bien ce dont il s’agit ici. Mais à ‘formation’, nous préférons le terme d’« empowerment », qui signifie Habiliter, rendre autonome. Former, c’est le moyen. Habiliter, c’est donner l’opportunité d’exploiter tout le potentiel de la solution pour répondre aux besoins ; c’est l’intention.

Qui ? – Tous les acteurs projets : équipes techniques, équipes en charge du support, acteurs projet intermédiaires (Product owners, MOA, chefs de projets), utilisateurs clés (relais, champions, super-users, comme on voudra les appeler), et enfin l’ensemble des utilisateurs finaux.
A Quoi ? – A ce dont ils ont besoin : tout ce dont ils ont besoin. Seulement ce dont ils ont besoin. Au moment où ils en ont besoin et où ils sont prêts à le mettre en pratique. Ça sonne creux ? Pourtant, quand on a dit ça on a (presque) tout dit.
Comment ? – Former, on le verra plus tard, ce n’est pas nécessairement regrouper une dizaine de collaborateurs dans une salle de formation avec un formateur qui leur présente l’outil ‘par le menu’, en une seule fois. Le format, la durée, le contenu et le rythme de formation peuvent prendre autant de formes qu’il n’existe de besoins, de contraintes, et de style d’apprentissages spécifiques différents.

Former enfin, on l’a dit, c’est la partie émergée de l’iceberg. Très visible, elle doit être, d’abord. Et être ‘à la hauteur’ ensuite. Impérativement.
Car au-delà du transfert de compétences, la formation est aussi un acte de communication, et un acte d’engagement envers les utilisateurs. Qui donnera le ton.
Très souvent, c’est sur la base de leur ressenti à l’issue de cette première formation que les utilisateurs finaux qui n’ont pas été directement impliqués jusque-là cèlent un premier jugement sur la qualité du projet, la considération qui leur est apportée etc. Positif, neutre ou négatif, ce ressenti déterminera l’intérêt porté à l’outil et sera peu aisé à infléchir.

Dans 40 % des projets informatique qui ne parviennent pas à atteindre les objectifs préalablement fixés, le défaut d’attention porté à l’exécution de la formation des utilisateurs finaux est l’un des 3 premiers facteurs responsables de l’échec de l’application.”

Gartner.

Lire ou relire les articles précédents / suivants :

Télécharger le dossier complet :