Pourquoi un bon outil finit contourné, et comment l'éviter

Le scénario est toujours le même. L'outil a été spécifié sérieusement, développé correctement, livré dans les délais. Six mois plus tard, il tourne, les licences sont payées, et les tableurs sont réapparus à côté.

Personne ne l'a saboté. L'outil a simplement perdu, point par point, contre l'habitude qu'il devait remplacer.

Les quatre causes, par ordre de fréquence

Il est plus lent que ce qu'il remplace, sur la tâche la plus fréquente. C'est de loin la première cause. L'outil fait vingt choses de mieux, mais la saisie que la personne répète quarante fois par jour prend deux minutes au lieu de trente secondes. Le bilan global a beau être positif, ce n'est pas lui qui est vécu : c'est la friction, quarante fois par jour.

Il réclame des informations que la personne n'a pas au moment où elle saisit. Un champ obligatoire dont la réponse arrivera demain bloque la saisie aujourd'hui. L'utilisateur invente une valeur pour passer l'écran, et la donnée devient fausse dès le premier jour.

Celui qui saisit n'est pas celui qui en profite. Le terrain remplit, la direction lit. Dans ce schéma, la saisie est une corvée pure, et elle décroche à la première semaine chargée. C'est un problème de conception, pas de discipline.

Il a été livré d'un bloc, longtemps après avoir été spécifié. Entre-temps, le processus a changé, et parfois les personnes qui l'avaient décrit sont parties. On met en service un outil qui répond à une organisation qui n'existe plus.

Ce qui règle ces quatre cas

Chronométrez la tâche la plus fréquente, en secondes. Avant et après. C'est la mesure la plus utile d'un projet d'outil interne, et presque personne ne la prend. Si l'outil est plus lent sur ce geste-là, rien d'autre ne rattrapera.

Rendez optionnel tout ce qui peut l'être. Un enregistrement incomplet mais vrai vaut infiniment mieux qu'un enregistrement complet et inventé. On peut toujours relancer sur un champ vide ; on ne détecte jamais une valeur plausible et fausse.

Rendez quelque chose à celui qui saisit. Un planning qui se remplit tout seul, une relance qu'il n'a plus à écrire, un document généré automatiquement. Dès que la saisie produit un bénéfice visible pour la personne qui la fait, le problème d'adoption disparaît.

Livrez par lots courts. Un processus mis en service, utilisé trois semaines, ajusté, puis le suivant. Chaque lot corrige la trajectoire du suivant, et la question de l'adoption se pose pendant qu'il est encore temps d'y répondre.

Le test des trois semaines

Trois semaines après la mise en service, ne demandez pas aux gens si l'outil leur convient : ils répondront oui. Regardez plutôt ce qui existe à côté. Un tableur partagé, un fil de messages qui sert de pense-bête, une liste sur papier à côté du clavier.

Ce qui est à côté de l'outil décrit exactement ce qu'il ne fait pas. C'est la meilleure liste d'améliorations que vous obtiendrez, et elle est gratuite.

Notre page Optimisation des process décrit comment nous conduisons ces mises en service.