Faire adopter un nouvel outil par une équipe qui n'a rien demandé

Le scénario revient souvent. L'outil fonctionne, il a été payé, il a été présenté. Trois mois plus tard, la moitié de l'équipe est revenue à son tableur.

Ce n'est presque jamais un problème technique.

La vraie question : qui gagne quoi

Un outil est souvent commandé par quelqu'un qui en tire un bénéfice direct, de la visibilité, du pilotage, du reporting. Il est utilisé par quelqu'un d'autre, qui saisit l'information.

Si celui qui saisit ne gagne rien, il saisit mal, ou plus du tout. Et tout l'édifice repose sur lui.

La question à se poser avant de développer n'est donc pas « qu'est ce que je veux voir ? » mais « qu'est ce que gagne la personne qui va remplir ça tous les jours ? ». S'il n'y a pas de réponse, il faut en créer une : un gain de temps ailleurs, une tâche supprimée, une information qu'elle cherchait et qu'elle trouve enfin.

Le test de la saisie quotidienne

Prenez la tâche que l'outil demandera le plus souvent. Chronométrez la, sur le vrai poste de travail, avec un vrai dossier.

Si elle prend plus longtemps que la méthode actuelle, même de peu, l'outil sera contourné. Peu importe ce qu'il apporte en aval : la personne qui saisit vit dans l'amont.

C'est le test le plus utile avant une mise en service, et le plus souvent sauté.

Livrer un morceau, pas un ensemble

Une bascule complète demande à chacun de tout changer le même jour. Elle se solde généralement par une période de chaos, puis par un retour partiel aux anciens outils.

Mettre en service un périmètre restreint, complet et réellement utile, permet aux utilisateurs de constater le bénéfice avant d'être exposés au reste. Et les ajustements qui apparaissent sur ce premier lot profitent à tous les suivants.

Le rôle qu'on oublie de nommer

Un outil interne a besoin de quelqu'un qui en est responsable dans l'équipe. Pas un informaticien : quelqu'un qui connaît le métier, à qui on pose les questions, et qui décide des évolutions.

Sans ce rôle, les irritants s'accumulent sans que personne ne les remonte, et l'outil se périme par petites touches. Il n'a pas besoin d'y consacrer beaucoup de temps, il a besoin d'exister et d'être identifié.

Ce qu'il faut accepter de supprimer

Une mise en service réussie supprime quelque chose. Si l'ancien tableur reste ouvert « au cas où », il continuera d'être utilisé, et vous aurez deux sources de vérité, ce qui est pire qu'une seule mauvaise.

Décidez une date, archivez l'ancien support en lecture seule, et tenez la décision. C'est inconfortable pendant deux semaines et sain ensuite.

Le signal qui dit que ça tient

Ce n'est pas le taux d'utilisation la première semaine, qui est toujours bon par curiosité. C'est ce qui se passe quand quelqu'un n'est pas là.

Si l'équipe continue à utiliser l'outil en l'absence de celui qui l'a poussé, l'adoption est faite. Sinon, c'est encore de la discipline, et la discipline s'érode.

Notre article sur pourquoi un outil finit contourné creuse les causes de fond, et la page Optimisation des process décrit notre façon d'aborder ces projets.