Une exception n'est pas un accident hors du processus, c'est la partie du processus pas encore écrite. Dans cette leçon vous ouvrez le registre : ce que fait le flux quand arrive une entrée que la règle ne couvre pas, quelle panne l'arrête et laquelle le laisse continuer, qui en est informé et comment la décision passe dans le système.
Dans les leçons précédentes un flux a été monté et deux systèmes ont été reliés. Dans les deux, l'exception tenait en une seule ligne : la « voie d'exception » de la fiche de montage, le « comportement en cas de coupure » de la carte d'intégration. Cette leçon ouvre le travail derrière ces deux lignes. Ce que fait le flux quand arrive une entrée que la règle ne couvre pas, qui en est informé et où la décision prise est écrite.
La leçon ne propose pas de supprimer les exceptions. Une exception n'est pas un accident hors du processus, c'est la partie du processus pas encore écrite. Écrite, elle devient règle ; non écrite, elle réclame une décision neuve à chaque fois.
Prérequis : le flux de la cinquième leçon et la carte d'intégration de la sixième. Sans flux il n'y a pas d'exception ; une exception naît au bord d'un flux qui tourne.
Quand les deux se mélangent, la conduite se mélange aussi. Une exception est un cas que la règle ne couvre pas : le système fonctionne correctement mais aucune réponse n'est écrite pour l'entrée rencontrée. Une panne, c'est que le système fonctionne mal malgré ce qui est écrit.
En pratique la distinction se fait avec une question : en regardant la carte, la réponse pour ce cas y est-elle ? Si elle y est et que le système a fait autrement, c'est une panne ; sinon, une exception. Si le même événement arrive deux jours de suite, il cesse d'être une exception et devient une règle manquante.
Une entrée ou un cas que la règle ne couvre pas. Le remède est de décider ; la décision elle-même est consignée, car elle sera reposée.
Le système agit autrement là où une règle est écrite. Le remède est une correction, et le fait qu'elle tienne s'éprouve à part.
Si la discussion « exception ou panne » s'éternise, la carte est floue à cet endroit. La discussion se règle sur la carte, pas dans le système.
Le registre tient sur une page et chaque ligne décrit une exception. Les quatre colonnes répondent aux quatre questions posées quand une exception sort ; quand une colonne reste vide, cette exception ne porte rien vers la fois suivante.
Le vrai gain du registre se voit à la deuxième rencontre. La première fois, décider prend du temps ; la deuxième, ce qui est écrit s'applique et la discussion ne se rouvre pas.
La quatrième colonne est celle qui garde le registre vivant. Restée vide, le registre devient une archive ; remplie, la carte de processus grandit d'elle-même.
La plupart des flux sont montés sur l'idée que l'entrée arrivera dans la forme attendue. L'entrée inattendue est l'endroit où cette idée casse : le formulaire part à moitié rempli, un champ cru obligatoire arrive vide, le système source change en silence le format d'un champ.
Leur point commun est que la plupart ne produisent pas de message d'erreur. Le flux continue et un résultat produit avec des données incomplètes sort. C'est pourquoi la réponse à l'entrée inattendue s'écrit du côté entrée de la carte, pas du côté sortie.
L'enregistrement existe mais une partie des champs est vide. La décision : l'enregistrement est-il retenu, écrit tel quel, ou redemandé à l'envoyeur.
Si un champ tenu pour obligatoire arrive vide, l'obligation n'a pas été vraiment posée. L'écart entre le dictionnaire de champs et le flux sort ici.
Du côté source, le format de date ou de téléphone change. Le flux continue de lire comme avant et la valeur casse en silence.
La sixième leçon a choisi la clé de dédoublonnage ; celle-ci traite les cas où cette clé ne tient pas. La même personne écrit une seconde fois, le même formulaire part deux fois, la même commande entre par deux canaux.
Un doublon est un problème qui grandit en silence : chacun paraît juste tout seul, et au total le rapport gonfle et le client est contacté deux fois. Écrire la décision d'avance revient moins cher que nettoyer après coup.
La règle de dédoublonnage est l'une des premières lignes du registre, car elle revient souvent et sa décision s'oublie facilement.
Arrêter le flux à chaque panne paraît sûr mais arrête le travail ; ne pas arrêter garde le travail en marche mais agrandit le résultat faux. La décision se prend panne par panne et s'écrit sur la carte.
Le critère est celui-ci : quand cette étape fonctionne mal, le résultat peut-il être repris ? S'il le peut, le flux peut continuer et l'enregistrement est marqué. S'il ne le peut pas, le flux s'arrête et la personne qui attend en est informée.
Étapes dont le résultat ne se reprend pas : un message qui part, un paiement, une suppression durable. Dans le doute, l'arrêt est préféré.
Cas qui touchent un seul enregistrement et se reprennent. L'enregistrement est marqué, le flux continue avec les autres, et les enregistrements marqués sont repris en fin de journée.
Le cas le plus dur : une partie de l'étape est passée. Si aucun retour arrière n'est écrit pour cette possibilité, l'enregistrement commence à différer entre les deux systèmes.
Où va l'alerte compte autant que l'alerte elle-même. Une alerte qui tombe dans une boîte partagée n'est souvent le travail de personne ; un canal que tous voient peut devenir un canal dont personne ne répond.
La ligne d'alerte demande un nom de personne. Qui remplace pendant l'absence de cette personne figure sur la même ligne, car les exceptions n'attendent pas les jours de congé.
Le texte de l'alerte fait aussi partie de la décision : s'il dit quel enregistrement, à quelle étape et pour quelle raison cela s'est arrêté, la personne qui regarde peut décider sans entrer dans le système.
L'enregistrement de panne est la seule source qui raconte après coup ce qui s'est passé. Il peut tenir dans le flux, dans le journal de l'outil ou dans une table à part. Ce qui compte n'est pas l'endroit mais qu'il soit cherchable.
Le lire a son propre ordre. Sans cet ordre, ce qu'on regarde est souvent la dernière ligne, et la dernière ligne montre le plus souvent le résultat, pas la cause.
Quel enregistrement, quelle plage de temps. Sans identifiant la recherche part de la date et les enregistrements voisins se voient aussi.
Ce qui s'est passé étape par étape. Lire depuis le premier écart plutôt que depuis la ligne de résultat montre la cause.
La donnée arrivait-elle dans la forme attendue ? Une bonne part des pannes sort ici, et le système lui-même a bien fonctionné.
Tout flux a besoin d'une porte d'intervention manuelle : poursuivre un enregistrement arrêté, reprendre un enregistrement faux, passer la liste d'attente à la main. Sans porte, l'intervention se fait dans les outils et ne laisse pas de trace.
Une intervention est une exception et s'écrit au registre. Sans cela deux problèmes naissent : ce qui a été fait ne se rappelle pas quand le même cas revient, et le résultat produit par le système ne colle plus au travail fait à la main.
Que l'intervention manuelle soit facile n'est pas une faiblesse du flux mais sa tenue dans le temps. Un flux sans porte devient un processus mené à la main dès la première exception.
La panne la plus chère est celle qui ne lève pas de panne. Le flux paraît au vert, des enregistrements se créent, personne n'est alerté ; et le résultat produit est faux. Effleuré d'une phrase dans la sixième leçon, c'est le vrai sujet de la conduite des exceptions.
La source d'une panne silencieuse est le plus souvent du côté entrée : une valeur vide retombe sur la valeur par défaut, un format est mal lu, un appariement s'accroche à un autre enregistrement. Comme le système reste cohérent en lui-même, il ne se signale pas non plus.
Leur point commun : dans tous, le système dit « réussi ». C'est pourquoi une panne silencieuse se prend par la mesure et non par l'alerte.
Le chemin passe par ne pas se fier au rapport du système lui-même. Faites ensemble, trois mesures ramènent à la surface la plupart des pannes silencieuses.
Les trois se posent en habitude hebdomadaire et l'on écrit qui les fait. Une mesure sans propriétaire est lâchée dès la première semaine chargée.
Le nombre d'entrées est comparé au nombre de sorties. L'écart montre les enregistrements qui tombent en silence.
Le même enregistrement dans les deux systèmes est ouvert côte à côte. Regarder les champs clés suffit, plutôt que champ par champ.
Quelques enregistrements au hasard sont suivis de bout en bout. C'est de l'observation plus que de la mesure ; les écarts que le rapport ne montre pas se voient ici.
Le résultat de la mesure s'écrit au registre. Les semaines sans écart s'écrivent aussi, car « regardé et propre » est également une trace.
Toute exception ne passe pas dans le système. Un cas vu une fois est consigné et attend ; un cas qui revient devient règle. Le passer trop tôt embrouille le flux inutilement, trop tard fait reprendre la même décision encore et encore.
Le critère est la fréquence et le prix : si la même exception revient, ou si même une seule fois elle a produit un résultat non repris, une règle s'écrit. Quand la règle s'écrit, la carte de processus et le dictionnaire de champs se mettent à jour aussi, sinon la carte reste en retard sur la réalité.
Quand cette étape se ferme, l'exception ne disparaît pas, elle devient règle. Le registre se change ainsi en journal de mise à jour de la carte de processus.
Le bureau a choisi une tâche pilote, écrit son processus, dressé son dictionnaire de champs, choisi son outil, monté le premier flux et relié deux systèmes. Maintenant le flux tourne et, dans la première semaine, trois cas arrivent coup sur coup.
Aucun des trois n'est écrit sur la carte. La responsable du bureau porte chacun au registre et écrit la décision ; en fin de semaine deux des trois lignes sont devenues des règles.
Première ligne : dans une demande venue du portail, le champ téléphone est vide. Il est décidé que l'enregistrement ne soit pas écrit dans le tableau de suivi et tombe dans une liste d'attente ; la responsable parcourt la liste en fin de journée. Après trois répétitions du même cas, il est transformé en règle et porté sur la carte.
Deuxième ligne : la même personne écrit depuis deux annonces différentes et deux enregistrements s'ouvrent dans le tableau de suivi. La décision : la deuxième demande entre en note sous la même personne. Comme cette décision est la moitié manquante de la règle de clé de la sixième leçon, elle passe directement dans le système.
Troisième ligne : le portail change le format du champ date et les rendez-vous se décalent d'un jour. Il n'y a pas de message de panne et les enregistrements paraissent valables. L'écart n'est pas pris au comptage hebdomadaire mais à l'échantillon : les dates de deux enregistrements tirés au hasard ne collent pas à l'annonce. La conversion de format est corrigée, les enregistrements touchés sont repris à la main et l'intervention est écrite au registre.
En fin de semaine le bureau remarque que les alertes partent vers une boîte partagée et que personne ne la regarde. La ligne d'alerte passe à un nom de personne et une personne remplaçante est écrite aussi.
Deux des trois lignes sont devenues des règles, une est restée en observation. La valeur du registre se voit là : non seulement quelle décision a été prise, mais laquelle est passée dans le système est consignée.
Cette semaine, ouvrez le registre et écrivez ce qui se passe au bord de votre flux en marche. Vous n'avez pas à attendre une exception neuve ; chaque intervention manuelle des deux dernières semaines est déjà une ligne d'exception.
Télécharger le registre des exceptions (xlsx) · un registre d'une page avec les colonnes quelle exception, quand elle est sortie, comment on a décidé et si elle est passée dans le système ; les sections alerte, intervention manuelle et mesure hebdomadaire y sont aussi.
Celles qui suivent ne naissent pas de l'exception elle-même mais du fait que l'exception n'est pas conduite. Leur point commun : aucune ne se voit dans le système comme une panne.
La décision se prend en conversation et n'est pas consignée. Quand le même cas revient, une autre décision est prise et deux enregistrements sont traités différemment.
Un écart touchant un seul enregistrement arrête tout le flux. Au bout d'un moment les alertes sont coupées et la vraie panne bloquante ne se voit plus non plus.
L'alerte va à tout le monde et personne ne la prend. Une alerte non regardée donne le même résultat qu'une alerte non envoyée.
L'enregistrement est corrigé à la main mais qui a fait quoi n'est pas écrit. Quand le même enregistrement casse à nouveau la semaine suivante, la cause ne peut pas être cherchée.
La ligne « tout réussi » ne montre pas la panne silencieuse. Tant que la mesure n'est pas posée, un résultat faux passe pour juste des semaines durant.
Un cas vu une fois est ajouté au flux comme condition. Le flux s'embrouille un peu plus à chaque exception et son entretien devient plus dur.
Si, la première semaine du flux achevée, chaque point de cette liste trouve réponse, la conduite des exceptions compte comme posée.
Termes qui reviennent dans les conversations sur les exceptions. Donner le même sens au même mot garde le registre lisible la deuxième semaine aussi.
Dans cette leçon vous avez écrit le bord du flux : vous avez distingué exception et panne, ouvert le registre, défini les voies d'alerte et d'intervention manuelle et rendu visible la panne silencieuse par la mesure. Les leçons à venir traitent de faire entrer l'équipe dans le processus et de mesurer le résultat.
Si vous souhaitez continuer avec les leçons publiées, vient le module qui resserre une panne dans l'ordre.
Fiche de panne, méthode de coupe en deux et correction durable. Le registre de cette leçon l'alimente.
La carte d'intégration et le comportement en cas de coupure. Une partie de ces exceptions y naît.
La section formation dans son ensemble et les modules ajoutés depuis.
Si vous souhaitez ouvrir le registre des exceptions ensemble, écrivez-nous et nous remplirons les premières lignes.
Demander un Devis sur WhatsApp