Passer un processus à quelqu'un — Patter

The case

Le problème de la transmission d’un processus, c’est que celui qui le transmet le connaît trop bien. Il sait quelles étapes comptent vraiment et lesquelles n’existent que par tradition. Il connaît l’exception qui survient tous les deux mois. Il sait qu’une dépendance est peu fiable et qu’on procède autrement le vendredi. Rien de tout cela n’est écrit quelque part — pourquoi l’aurait-il été, c’est lui qui s’en occupe.

Alors on transmet ce qui est documenté. L’autre personne acquiesce, la réunion se termine, et deux semaines plus tard arrivent les questions que personne n’aurait pu anticiper — parce qu’elles n’émergent que lorsqu’on exécute réellement le processus.

La solution n’est pas une meilleure documentation. C’est un ordre différent : d’abord reconstruire le processus réel, ensuite le mettre par écrit, ensuite observer quelqu’un d’autre l’exécuter avant de lâcher prise. C’est en observant que les lacunes apparaissent. Elles apparaissent toujours.

Un processus n’a pas été transmis tant que quelqu’un d’autre ne l’a pas exécuté sans vous. Tout ce qui précède n’est que préparation.

Passation de processus

Lister toutes les étapes du processus de mémoire. Sans consulter la documentation pour l'instant. Ce dont vous vous souvenez sans aide correspond à peu près à ce que l'autre personne doit savoir.
Comparer la liste à la documentation existante. Noter les lacunes et les contradictions. La documentation est souvent périmée.
Ajouter les détails non documentés. Cas particuliers, exceptions, ce qu'il faut faire quand l'étape 4 ne fonctionne pas. C'est la partie que vous êtes seul à connaître.
Identifier les dépendances. Outils, accès, identifiants, personnes impliquées. Tout ce que le processus touche.
Vérifier que l'autre personne dispose de tout ce qu'il lui faut. Contrôler les accès avant la réunion, pas pendant.
Rédiger le document de passation. Étapes dans l'ordre, dépendances et exceptions mentionnées. Suffisant pour exécuter le processus sans vous.
Identifier les deux ou trois points les plus susceptibles de poser problème. Ce qui peut bloquer, comment y remédier, qui contacter si ce n'est pas réglable rapidement.
Dérouler le processus en intégralité. Étape par étape, à voix haute. L'autre personne n'exécute pas encore.
Observer l'autre personne exécuter le processus. N'intervenir que si quelque chose est vraiment faux. Noter ce qui est omis.
Revenir sur ce qui manquait. Bref et précis.
En cas de lacunes importantes, recommencer. @9 si nécessaire.
Convenir de ce qui se passe en cas de problème après votre départ. Un nom, un document, un canal. Pas : « envoyez-moi un message. »
Confirmer que la personne est prête à exécuter le processus seule. Son évaluation compte, pas la vôtre.

Adaptez-le

L'étape 3 est celle où la plupart des passations échouent. La version documentée d'un processus est rarement celle qui fonctionne réellement — il y a toujours un contournement pour ce qui n'a jamais été corrigé, un raccourci devenu la norme, une vérification qui existe à cause d'un incident survenu il y a des années. Sauter cette étape, c'est transmettre une image incomplète.

L'étape où l'autre personne exécute le processus pendant que vous observez (étape 9) est incontournable dès que la complexité est réelle. Entendre quelqu'un dire qu'il a compris n'est pas la même chose que le voir faire. Ce qu'il omet ou ce sur quoi il hésite vous apprend plus que n'importe quelle question.

Pour un processus simple, les étapes 6 et 7 peuvent être regroupées dans un document court. Pour tout ce qui comporte des risques sérieux — contact client, finances, opérations — mieux vaut les garder séparées. Le document « que faire en cas de problème » est celui qu'on ouvre vraiment sous pression.

Après plusieurs passations, l'étape 1 devient plus rapide si vous prenez l'habitude de documenter les processus au fur et à mesure plutôt que de les reconstruire après coup. C'est une autre habitude, mais elle accélère considérablement celle-ci.