L'erreur de traitement avait affecté six cent douze comptes. Le CEO le savait à la fin du premier jour. À la fin du deuxième jour le CEO savait également ce qui suit: que l'erreur provenait d'une mise à jour de routine du système de facturation, que la mise à jour avait été testée selon le protocole convenu, que les tests n'avaient pas détecté l'erreur parce que la combinaison spécifique de types de comptes affectés n'était pas incluse dans les cas de test, et que les cas de test avaient été conçus par le prestataire en utilisant la documentation fournie pendant la phase de transfert de connaissances. Le CEO a demandé à Joël au sujet des cas de test. Joël a sorti le framework de test original que l'entreprise avait utilisé avant la transition et l'a comparé à la version du prestataire. La différence n'était pas dramatique. C'était le genre de différence qui n'est visible qu'à quelqu'un qui sait pourquoi le framework original a été construit de la façon dont il a été construit, c'est-à-dire quelqu'un qui avait été présent pour l'incident spécifique, dix-huit mois avant la transition, qui avait causé que le framework original inclue la combinaison spécifique de types de comptes que la version du prestataire n'incluait pas. "Ce cas de test existe dans notre framework original à cause de quelque chose qui s'est passé avant que tu arrives," a dit Joël. "Une erreur de facturation, plus petite que celle-ci, qui a affecté un sous-ensemble de comptes avec une combinaison spécifique de paramètres hérités. L'incident a été résolu et le framework a été mis à jour pour inclure cette combinaison de type de compte dans tous les futurs tests du système de facturation. La mise à jour était documentée dans le framework de test lui-même. Mais la raison de la mise à jour, l'incident qui l'a produite, n'était pas documentée. C'était de la mémoire institutionnelle." "Et l'équipe du prestataire?" a dit le CEO. "L'équipe du prestataire a examiné la documentation pendant la phase de transfert de connaissances," a dit Joël. "Ils ont vu les cas de test. Ils n'ont pas vu la raison de celui-ci spécifiquement. Quand ils ont construit leur propre framework ils ont fait un jugement raisonnable sur les cas de test à inclure en fonction de la documentation. Celui-ci n'a pas fait it dans leur version parce que sans le contexte il ressemblait à un cas limite plutôt qu'à une leçon apprise." "Est-ce documenté quelque part?" a dit le CEO. "Dans les fichiers de Sandra," a dit Joël. "Elle gardait des registres d'incidents depuis le début. Détaillés. Ils ont été inclus dans les matériaux de transfert de connaissances." "Et l'équipe de Diane?" a dit le CEO. "Les a reçus," a dit Joël. "Les a examinés. N'avait pas Sandra pour les expliquer. Et ne savait pas quoi demander." "Parce qu'elles ne savaient pas ce qu'elles ne savaient pas," a dit le CEO. "Exact," a dit Joël.

C'est la façon spécifique dont la connaissance quitte une organisation. Pas par la sortie dramatique. Pas par la lettre de démission ou la fête de départ à la retraite ou l'annonce de la restructuration. Par l'accumulation silencieuse de contexte non documenté qui n'existe que dans la compréhension des personnes qui étaient présentes quand le contexte a été créé, et qui disparaît, de façon incrémentale et invisible, chaque fois que l'une de ces personnes part sans le transmettre. Les carnets verts avaient été la tentative de Maya de ralentir ce processus. De rendre visible l'invisible. De créer un enregistrement non seulement de ce qu'était la connaissance mais de pourquoi elle existait et ce qui l'avait produite et ce qui se passerait si elle n'était pas appliquée. Maya avait compris, instinctivement, que la connaissance sans contexte est de l'information, et l'information sans contexte est de la donnée, et la donnée sans contexte est du bruit, et que la différence entre une organisation qui apprend de son expérience et une organisation qui continue à répéter les mêmes erreurs est presque entièrement déterminée par combien du contexte survit aux transitions. Les carnets verts avaient survécu à la transition. Ils étaient dans un placard dans le service support. Ce qui n'avait pas survécu c'était Maya. Du côté du prestataire, Gil avait identifié le manque de cas de test trois semaines avant que l'erreur de traitement ne se produise. Il ne l'avait pas identifié spécifiquement comme un manque de cas de test. Il l'avait identifié comme un schéma dans les appels que son équipe recevait, un sous-ensemble de types de comptes qui produisaient des voies de résolution inhabituelles que le script ne couvrait pas complètement et que ses agents géraient par improvisation plutôt que par processus défini. Il l'avait soulevé auprès de son manager. Son manager avait dit que c'était une question pour l'équipe opérationnelle du client. Gil l'a écrit dans ses propres notes. Il écrivait des choses dans un petit carnet marron avec des pages quadrillées qu'il gardait dans le tiroir gauche de son bureau. Le courant était le neuvième. Il a écrit: combinaison de type de compte, interaction de paramètres hérités, voie de résolution peu claire, risque d'erreur potentiel. Il a souligné risque d'erreur potentiel et a dessiné une petite flèche pointant vers la marge gauche, où il a écrit: escalader. Il a escaladé. L'escalade est allée à Jonathan. Jonathan l'a transférée au correspondant de compte du client. Le correspondant de compte l'a enregistrée comme une demande de processus. La demande de processus est restée dans la file d'attente. Trois semaines plus tard, l'erreur de traitement s'est produite. Gil a lu le rapport d'incident et a trouvé la combinaison de type de compte dans le troisième paragraphe. Il avait escaladé. L'escalade avait été correctement traitée et était restée dans la file d'attente. La file d'attente n'avait pas été examinée avant que la mise à jour soit poussée. La mise à jour avait produit l'erreur. Il avait fait tout ce que la structure lui permettait de faire. La structure n'avait pas été construite pour attraper ce qu'il avait vu.

Le CEO a appelé Maya. Pas pour lui demander de revenir. Pas encore. Pour lui poser une question. "L'erreur de traitement," a dit le CEO. "La mise à jour du système de facturation. Les cas de test." "J'ai entendu," a dit Maya. "Dom m'a envoyé un message." "Joël a identifié le manque. Le framework du prestataire manquait un cas de test qui existait dans le nôtre à cause d'un incident d'il y a dix-huit mois. L'incident était dans les fichiers de Sandra. Le contexte non." "Je sais à quel incident tu fais référence," a dit Maya. "Je le pensais," a dit le CEO. "C'était avant ma période ici mais Sandra m'en a parlé quand je construisais la base de connaissances," a dit Maya. "J'ai ajouté une entrée. Je pensais avoir rendu le contexte clair mais il est possible que je l'aie rendu clair pour quelqu'un qui connaissait déjà l'histoire et pas clair pour quelqu'un qui le lisait sans cet antécédent." "Peux-tu regarder l'entrée et me dire ce que tu penses?" a dit le CEO. "Oui. Donne-moi un jour," a dit Maya. Elle a rappelé le matin suivant. "L'entrée décrit l'incident et la leçon," a dit Maya. "Elle ne décrit pas pourquoi la leçon importe. Quelqu'un qui la lit sans contexte comprendrait ce qui s'est passé et ce qui a été changé. Il ne comprendrait pas nécessairement que le même type d'échec se reproduirait si le changement n'était pas maintenu dans les futurs frameworks de test. Je l'ai écrite pour quelqu'un qui comprenait le système. Pas pour quelqu'un qui apprenait le système from scratch." "Est-ce un problème courant avec la documentation?" a dit le CEO. Maya a été silencieuse un moment. "Oui," a dit Maya. "Pas parce que la documentation est mauvaise. Parce que la documentation est toujours écrite par quelqu'un qui comprend déjà la chose documentée, pour quelqu'un qu'il imagine comprendre aussi. Le fossé entre ce lecteur imaginé et le lecteur réel est là où vit le contexte et là où il se perd." "Serais-tu prête à faire ça?" a dit le CEO. "Tu veux dire examiner toute la base de connaissances à la recherche de manques de contexte?" a dit Maya. "Oui," a dit le CEO. "Ça prendrait des mois," a dit Maya. "Je sais," a dit le CEO. "Et l'équipe du prestataire devrait être impliquée," a dit Maya. "Il ne sert à rien d'identifier les manques si les personnes qui ont besoin de les combler ne font pas partie du processus." "Puis-je demander vers quoi cela mène?" a dit Maya. "Je ne suis pas encore prêt à répondre à cette question," a dit le CEO. "Mais j'aimerais savoir que tu serais prête à faire partie de ce vers quoi cela mène." Maya a été silencieuse à nouveau. Plus longtemps cette fois. "Je voudrais en savoir plus avant de m'engager à quoi que ce soit," a dit Maya. "C'est juste," a dit le CEO. "Mais oui," a dit Maya. "En principe. Si cela mène vers quelque chose que je pense valoir la peine." "Merci Maya," a dit le CEO. "Puis-je demander encore une chose?" a dit Maya. "Oui," a dit le CEO. "Tu penses à la base de connaissances spécifiquement ou tu penses à tout?" a dit Maya. "À tout," a dit le CEO. "Bien," a dit Maya. Nora était sous traitement depuis trois mois. Elle continuait à venir. Pas tous les jours. Trois jours par semaine les semaines où le traitement le permettait, deux jours les semaines où il ne le permettait pas, et une fois, dans le deuxième mois, pas du tout pendant une semaine entière quand les effets secondaires avaient produit une fatigue qui était au-delà de ce que le mot fatigue décrit habituellement. L'entreprise s'était ajustée autour d'elle sans qu'on le lui demande. Owen avait été le premier à organiser cela. Pas comme un arrangement formel. Comme une conversation qu'il avait eue avec trois personnes lors de brèves réunions séparées au cours d'un matin de mardi. Il n'avait dit à personne au-dessus de lui qu'il avait fait cela. Il ne lui était pas venu à l'esprit de le rapporter. C'était une chose qui devait être faite et il l'avait faite. Le CEO l'a appris par Nora. "Owen l'a organisé," a dit Nora. "Il n'en a pas fait un projet. Il l'a juste fait arriver." Le CEO y a pensé. Puis est allé voir Owen. "J'ai entendu ce que tu as fait pour Nora," a dit le CEO. Owen a levé les yeux. "C'est juste ce qu'on fait," a dit Owen. Le CEO est resté là un moment. "C'est exactement ce que Priya a dit," a dit le CEO. "Quoi?" a demandé Owen. "Rien," a dit le CEO. "Merci Owen." Le CEO a pensé: combien de fois a-t-il fait ce genre de chose que personne au-dessus de lui ne sait.

La connaissance qui est partie n'était pas seulement dans la documentation. C'était ce que le CEO commençait à comprendre dans les semaines après l'erreur de traitement, en s'asseyant avec le problème de la façon dont le CEO avait appris, tôt dans une carrière qui avait inclus de nombreux problèmes qui semblaient simples et ne l'étaient pas, à s'asseoir avec les problèmes avant de décider quoi en faire. La documentation était la partie visible. Les carnets verts. Les registres d'incidents. Les frameworks de test. Les articles de connaissance du produit. La partie invisible était plus difficile. La partie invisible était la connaissance qui n'avait jamais été dans aucun document. La connaissance de Priya sur quand rester dans un appel et quand un client avait besoin de quelque chose au-delà de ce que le script pouvait offrir. La connaissance de Sandra sur quels agents étaient prêts pour plus de responsabilité. La connaissance de Maya sur pourquoi la base de connaissances était organisée de la façon dont elle l'était. La connaissance d'Owen sur quand une équipe avait besoin d'être organisée avant que le besoin ne soit visible dans aucun rapport. Rien de cela n'avait été dans aucun document. Tout était parti, ou partait, ou était présent et invisible, ce qui était son propre type de perte. Le CEO a pensé à la théorie de Joël sur deux types de distance. La partie dans la documentation que vous pouviez voir, identifier et adresser. La partie qui avait vécu dans Priya et Sandra et Maya vous ne pouviez pas la voir, ne pouviez pas l'identifier complètement et ne pouviez pas l'adresser complètement, pas de là où se trouvait l'entreprise maintenant. Vous ne pouviez que la reconstruire. Et la reconstruire nécessitait les conditions qui l'avaient produite en premier lieu. La salle. La proximité. L'expérience accumulée de personnes qui étaient présentes pour les choses qui produisaient la connaissance et qui restaient assez longtemps pour la transmettre aux personnes qui venaient après elles. Le CEO s'est assis avec cette compréhension pendant plusieurs jours. Ne agissant pas dessus. Pas encore. Après plusieurs jours la compréhension était suffisamment claire. Le CEO a convoqué une réunion avec Joël. Pas une réunion formelle. Une conversation dans la salle de réunion avec le tableau blanc et les quatre chaises. "Je veux parler de ce que revenir en arrière signifierait vraiment," a dit le CEO. "En termes de?" a dit Joël. "En termes de ce que cela nécessiterait," a dit le CEO. "Le conseil. Le contrat. Le calendrier. Les personnes." "Tu as pris la décision," a dit Joël. "Je la prends maintenant," a dit le CEO. "Pendant que nous parlons. Je veux comprendre ce que cela nécessite avant de finir de la prendre." "Ça nécessite de mettre fin au contrat du prestataire," a dit Joël. "Il y aura des pénalités. Je peux regarder les clauses de sortie mais nous devrions supposer que c'est coûteux." "Je sais," a dit le CEO. "Ça nécessite de reconstruire la fonction de support en interne," a dit Joël. "Ça signifie du recrutement. De la formation. Reconstruire la base de connaissances à un état où elle peut réellement soutenir l'équipe. Ça prend du temps. Probablement un an pour arriver à un état fonctionnel. Deux ans pour arriver à là où nous étions avant." "Deux ans," a dit le CEO. "Au minimum," a dit Joël. "Et les personnes?" a dit le CEO. "C'est la question plus difficile," a dit Joël. "Certains d'entre eux reviendront," a dit Joël. "Pas tous. Maya pourrait. Sandra pourrait. Les autres, ceux qui ont pris l'indemnité ou les postes chez le prestataire, certains auront avancé de façons qui sont réelles et qui ne peuvent pas être facilement inversées. Et Priya." "Priya," a dit le CEO. "Priya est dans une petite entreprise en train de faire exactement ce qu'elle est censée faire," a dit Joël. "Je ne sais pas si elle reviendrait." "J'aimerais lui poser la question," a dit le CEO. "Je pensais que tu dirais ça," a dit Joël. "Quoi d'autre?" a dit le CEO. "Le conseil," a dit Joël. "Marcus voudra comprendre le cas financier. Les pénalités pour sortir du contrat du prestataire plus le coût de la reconstruction en interne plus la période de transition où tu fais tourner deux opérations simultanément ou une opération en dessous du standard précédent. C'est un chiffre significatif." "Je sais," a dit le CEO. "Tu vas avoir besoin d'un chiffre différent à mettre contre lui," a dit Joël. "Elena," a dit le CEO. "L'erreur de traitement. La tendance de désabonnement. Les six cent douze comptes. La distance entre trois virgule six et quatre virgule deux sur une échelle de cinq points et ce que cette distance coûte en valeur vie client sur trois ans." "C'est le cas," a dit Joël. "Peux-tu le construire?" a dit le CEO. "Oui," a dit Joël. "Ça prendra deux semaines pour le faire correctement." "Fais-le correctement," a dit le CEO. "Et pendant que je le construis?" a dit Joël. "Je vais appeler quelques personnes," a dit le CEO.

Fin du Chapitre 10

Pensée de l’auteur :

Tu penses à la base de connaissances spécifiquement ou tu penses à tout a dit Maya. Tout a dit le CEO. J'étais content que quelqu'un ait finalement posé la question.

Voici Ce Qui Est Brisé. Le CEO. La Connaissance Qui Est Partie.

MarvinPro | Mars 2026

marvinpro.com

Piensa Simple.