Comment cartographier les transferts de processus
Comment cartographier les transferts dans un processus : trouvez chaque point où le travail change de mains, enregistrez la façon dont le destinataire est informé et mesurez l'attente. Avec un exemple de départ d'employé en direct.
Cartographier les transferts signifie trouver chaque point où le travail change de mains, enregistrer comment l'équipe de réception apprend qu'elle a du travail et mesurer combien de temps elle attend avant de commencer.
En bref
- Le temps de cycle dans la plupart des processus correspond au temps d'attente entre les équipes, et non au temps de travail en leur sein.
- Chaque transfert comporte un mécanisme de déclenchement, une attente et une condition d'acceptation.
- "Ils vérifient la boîte de réception partagée" est une file d'attente sans propriétaire, ni déclencheur.
- Comptez les croisements : trop de croisements signifie que le travail est mal divisé et non mal dessiné.
- Les transferts où le retard coûte cher devraient être considérés comme des décisions et non comme des étapes.
Le travail ne s'arrête pas en une seule étape
Mesurez n'importe quel processus opérationnel de bout en bout et l'arithmétique est généralement inconfortable : le travail prend des heures et le processus prend des jours. La différence n’est pas l’inefficacité des étapes. Ce sont les écarts entre eux : l'intervalle où une équipe a terminé, la suivante n'a pas commencé, et personne ne considère actuellement l'élément comme le sien. Ces intervalles sont les transferts, et ils ne sont presque jamais documentés car aucune équipe ne les expérimente.
Un transfert n’est pas une flèche. Il s'agit d'un événement avec trois propriétés qui méritent d'être notées : un mécanisme de déclenchement (comment le récepteur le découvre), une attente (combien de temps avant d'agir) et une condition d'acceptation (ce dont il a besoin pour commencer). Un croisement tracé sous forme de ligne simple implique que les trois sont instantanés et complets, ce qui est exactement l'hypothèse qui produit un processus que tout le monde croit bon et un client qui attend toujours.
L'exemple ci-dessous est le départ d'un employé, c'est-à-dire un transfert presque de bout en bout : les RH au manager, le manager à l'informatique, l'informatique aux RH, puis la paie et les installations. Il contient également le transfert qui entraîne le coût le plus élevé en cas de retard dans l'ensemble du domaine RH (révocation d'accès le jour même), c'est pourquoi il est présenté comme une décision plutôt que comme une étape à laquelle quelqu'un parviendra.
Un processus qui consiste principalement en des transferts
Départ des employés au niveau des RH, du manager, de l'informatique, de la paie et des installations. Regardez à quelle fréquence le travail change de mains.
La première traversée règle l'horloge
L'avis arrive aux RH, se répartit entre volontaire et involontaire, et le dernier jour ouvrable est confirmé par le manager. Chaque date limite en aval est suspendue à cette date, donc le transfert qui la communique est celui qui mérite d'être chronométré.
Le transfert sur lequel vous ne pouvez pas être en retard
« Une coupure immédiate de l'accès est-elle nécessaire ? » voies menant à la révocation le jour même. La considérer comme une décision plutôt que comme une étape est délibérée : cela oblige quelqu’un à répondre à la question dès le premier jour au lieu de la laisser dans une liste de contrôle que l’informatique atteindra jeudi.
Des transferts qui rebondissent
La rédaction du transfert, le transfert de projet et les mises à jour du runbook relèvent du responsable, puis d'une décision d'approbation qui peut le renvoyer. Un transfert rejeté est un deuxième passage que personne n’a compté, et c’est là que le débarquement dépasse généralement.
Trois équipes lors de la dernière journée
Entretien de sortie avec les RH, paie finale avec paie, actifs avec installations, puis accès restant avec l'informatique, avec un retour des actifs non restitués dans la paie. Quatre voies agissant en une journée ne fonctionnent que si chacune connaît la date, ce qui vous ramène à la première étape.
Les transferts après le départ de la personne
Paiement final versé, dossiers archivés conformément à la politique de conservation. Les étapes post-sortie sont celles qui manquent le plus souvent dans un processus de départ, car à ce moment-là, personne ne court après et la personne qui l'aurait remarqué est partie.
Comment cela fonctionne
Cartographier le processus avec les voies en premier
Les transferts ne sont visibles qu’une fois le flux divisé par propriétaire. Placez chaque étape dans la voie du rôle qui l'exécute (dans QueryChart, il s'agit de la colonne Voie verticale), et les croisements apparaissent d'eux-mêmes sans que personne n'ait à les chercher.
Marquez chaque ligne qui traverse une voie
Parcourez-les un par un et listez-les. Un processus en quinze étapes traversant huit fois les voies est normal et mérite d’être connu ; le décompte lui-même est souvent le chiffre le plus convaincant de tout l’exercice, car personne ne l’a jamais vu auparavant.
Enregistrez comment le destinataire est informé
Pour chaque traversée, écrivez le mécanisme déclencheur dans le commentaire de l'étape : un changement de statut du système, un ticket attribué, un email, une file d'attente partagée, un stand-up. Là où la réponse honnête est « ils vérifient », vous avez trouvé une file d’attente sans propriétaire et une attente que personne ne mesure.
Enregistrez ce dont le récepteur a besoin pour démarrer
La condition d’acceptation compte autant que le déclencheur. L'informatique ne peut pas effectuer de fourniture sans date confirmée ; la paie ne peut pas être finalisée sans la position de l'actif. Les transferts échouent aussi souvent à cause d’informations incomplètes qu’à cause d’une notification tardive, et les deux ont des correctifs différents.
Chronométrer l'attente, même grossièrement
Demandez à chaque équipe de réception combien de temps un article reste généralement avant de le récupérer. Les chiffres approximatifs suffisent : l'essentiel est la forme, et la forme est presque toujours telle qu'un ou deux croisements occupent la majeure partie du temps écoulé. Mettez les numéros sur les marches.
Réparer le mécanisme avant le processus
La plupart des problèmes de transfert sont résolus en modifiant le déclencheur (une notification au lieu d'une vérification, une file d'attente partagée avec un propriétaire nommé au lieu d'une boîte de réception) plutôt qu'en déplaçant le travail. Repensez le processus uniquement lorsque le passage à niveau ne devrait pas exister du tout.
Erreurs à éviter
Transferts dessinés sous forme de flèches simples
Une traversée non annotée implique un transfert instantané et complet. C’est dans cette hypothèse que vivent les jours manquants.
Compter les pas au lieu des passages
Le nombre de pas vous indique la quantité de travail à effectuer. Le décompte vous indique combien de temps cela prendra. Ils sont souvent sans rapport.
Optimisation à l'intérieur d'une voie
Rendre les pas d'une équipe plus rapides est satisfaisant et ne change généralement rien, car l'objet passe la majeure partie de sa vie entre les voies plutôt que dans celles-ci.
En supposant que le destinataire sache
"Ils le verront dans le système" n'est un déclencheur que si quelqu'un regarde. Demandez-leur quand ils regardent et à quelle fréquence.
Cartographiez vos propres transferts
Ouvrez l'exemple de débarquement en tant que votre propre tableau, renommez les voies et annotez chaque passage avec la façon dont l'équipe suivante est informée.
Guides associés
Questions fréquentes
Qu’est-ce qu’un transfert de processus ?
Le point où la responsabilité d’un travail passe d’une personne, d’une équipe ou d’un système à une autre. Il comporte trois parties qui méritent d'être documentées : comment le destinataire est informé, ce dont il a besoin pour démarrer et combien de temps l'élément attend avant de le faire. Les transferts sont d'une importance disproportionnée car aucune équipe n'en fait l'expérience : l'expéditeur considère le travail effectué et le destinataire n'a pas commencé, donc l'intervalle n'appartient à personne et n'est mesuré par personne.
Comment trouver des transferts dans un processus ?
Dessinez le processus avec une voie par rôle responsable, puis répertoriez chaque connexion qui traverse une limite de voie. C'est l'ensemble complet. En procédant autrement (en demandant aux gens où se situent les retards, en examinant les billets), on trouve les passages à niveau qui suscitent déjà des plaintes et on oublie ceux qui sont simplement lents. Dans QueryChart, l'affectation des voies est une colonne de feuille de calcul, de sorte que les croisements peuvent être énumérés directement à partir des lignes.
Combien de transferts, c'est trop ?
Il n’existe pas de chiffre absolu, mais le ratio est révélateur : si un processus en quinze étapes traverse dix fois les étapes, le travail change de mains presque à chaque étape et la répartition des responsabilités est probablement erronée. Recherchez une voie qui pourrait posséder un bloc contigu au lieu de recevoir et de rendre le même article deux fois. Réduire les passages à niveau est généralement préférable à leur accélération.
Comment puis-je réduire le délai de transfert ?
Modifiez le déclencheur avant de modifier le processus. La plupart des retards viennent du fait que le destinataire ne sait pas qu'il y a du travail (une boîte de réception partagée que personne ne possède, un champ d'état que personne ne surveille), et le remplacement de cela par une véritable notification ou une file d'attente assignée avec un propriétaire nommé corrige l'attente sans toucher à qui fait quoi. Repensez le flux uniquement lorsqu'un passage à niveau ne devrait pas exister et attribuez-lui un propriétaire lorsqu'il le doit.
