PROCESS

Ici, c'est Comment Construire

Conception

L'exemple

Ce volume revient à la même entreprise que tu as rencontrée dans les Règles. Le cas est le même ; seule la lentille a tourné. Là, il t'a montré les règles. Ici, il te montre ce qui se passe quand une règle ne convient pas, et ce qu'un concepteur fait à ce sujet.

Une entreprise vend des logiciels par abonnement, et son travail n'est pas la réparation du logiciel mais la communication autour : comment le problème est trié, traité et raconté, dans l'entreprise et vers le client. Tu sais déjà comment elle trie le problème. Le problème d'un client est un incident, traité comme un cas unique. Le même problème chez de nombreux clients est un incident émergent, quelque chose de plus grand. Et un incident est connu ou inconnu. Un incident connu est un que l'entreprise a déjà vu, avec des instructions prêtes et un modèle pour l'expliquer. L'Exécutant rencontre un incident connu et avance : la règle convient, le modèle est là, le chemin à suivre est écrit. La plupart des cas sont ainsi, et c'est la conception qui fonctionne.

L'exception est l'incident inconnu. C'est le problème que personne n'a encore rencontré, le cas sans modèle, car tu ne peux pas faire de modèle de ce que tu ne comprends pas encore. Ici la règle ne convient pas. L'Exécutant fait face à un client en difficulté et n'a aucun mot écrit à envoyer, aucune instruction à suivre. Il ne peut pas avancer par la règle, car pour ce cas il n'y a pas de règle. C'est le moment dont traite tout le volume : l'Exécutant, bloqué, ayant besoin d'un chemin à suivre que la conception doit déjà lui avoir donné.

Et la conception le lui a donné. Bien avant que ce cas n'arrive, le concepteur a demandé aux Exécutants ce qu'ils craignaient : et si un problème arrive dont nous n'avons pas de modèle ? Ce et si, soulevé avant que le travail n'entre en service, est la première exception, mise au jour non dans une crise mais dans une salle calme, avec assez de temps pour la concevoir et assez de temps pour que les Exécutants apprennent la réponse avant d'en avoir besoin. La réponse conçue pour cela est la voie d'escalade. Quand l'Exécutant rencontre un incident inconnu, il n'invente pas de réponse et ne reste pas silencieux. Il porte le cas par la voie que la conception a construite pour exactement cela : au Propriétaire, qui amène l'Équipe Technique capable de le traiter. Pendant ce temps le client n'est pas laissé dans le silence non plus ; l'Exécutant envoie les mises à jour façonnées que la conception fournit pour un cas qui se déploie, un peu plus certaines à chaque fois, chacune se terminant par l'étape suivante, même quand l'étape suivante est seulement d'attendre. L'Exécutant n'est jamais laissé en plan. La règle ne convenait pas, mais la conception lui a quand même dit quoi faire.

Tous les et si n'ont pas pu trouver réponse d'un coup. Les Exécutants en ont soulevé plus que le concepteur ne pouvait intégrer avant la date de mise en service : le client rare qui demande à ne pas être contacté du tout, le client dont l'administrateur insiste sur un canal à lui, le cas qui touche une promesse que seul le Propriétaire de l'Offre peut modifier. Certains de ceux-ci, le concepteur les a intégrés aussitôt, sous forme d'un petit guide écrit que l'Exécutant suit sans demander à personne, avance ainsi, c'est déjà approuvé. Certains exigeaient une décision vivante et ont été acheminés là où se trouvait l'autorité : une déviation que le propre Leader de l'Exécutant pouvait permettre, et une plus grande que seul le Propriétaire du domaine pouvait sanctionner. Et certains, honnêtement, ont été mis de côté : notés comme exceptions connues à concevoir plus tard, car le concepteur n'avait qu'un temps limité, et il vaut mieux consigner une exception ouverte que de prétendre qu'elle est close. Un chemin à suivre à chaque tournant, écrit là où c'était possible, escaladé là où il le fallait, et jamais simplement absent.

Mais le cœur de ce volume est ce qui se passe après que l'incident inconnu est traité. Il ne reste pas une exception. À mesure que l'Équipe Technique trouve les étapes qui le résolvent, le Propriétaire transforme ces étapes en un guide de résolution que l'Exécutant peut suivre et en modèles que le client recevra. À cet instant l'inconnu devient connu. Le cas qui n'avait pas de règle en a maintenant une. Le prochain Exécutant qui le rencontrera n'escaladera pas ; il prendra le modèle et avancera, car l'exception est devenue un incident connu, repliée dans les règles, et n'est plus une exception. C'est le moteur silencieux que tu as déjà vu dans les Règles, lu maintenant de l'autre côté : le processus ne se contente pas de gérer ses exceptions, il fabrique leurs remplaçantes. Chaque incident émergent résolu laisse derrière lui une pièce permanente de processus, et l'univers des problèmes sans modèle se réduit d'un.

Voilà le cas, à travers la lentille de l'exception. Un Exécutant rencontre un cas que la règle ne convient pas, et n'est pas laissé en plan, car la conception a construit le chemin à suivre d'avance : un guide à suivre, ou une voie par laquelle escalader. Et l'exception ne dure pas, car la conception replie le cas résolu dans les règles, jusqu'à ce que ce qui fut une exception soit simplement la manière normale. Les chapitres qui suivent prennent cela et le tournent, pour que chaque partie de concevoir une exception, la mettre au jour, donner à l'Exécutant le chemin à suivre, et la concevoir pour qu'elle disparaisse, puisse se voir à l'œuvre dans quelque chose de réel.

Les Exceptions se construisent sur les Règles. Là où ce volume montrait comment une règle se fait, celui-ci montre quoi faire quand une règle ne convient pas : comment le cas est mis au jour, comment l'Exécutant reçoit un chemin à suivre, et comment l'exception est repliée dans les règles jusqu'à ne plus en être une. Chaque Discipline se construit sur la précédente, du seul cas bloqué à une conception qui ne laisse presque rien hors de ses règles.

Ce n'est pas un guide théorique. Cela vient d'un travail réel à travers des opérations mondiales, des migrations de systèmes et de la conception de processus. Les idées présentées ici ont été observées, appliquées et affinées dans des environnements complexes impliquant de nombreux pays, de nombreux systèmes et de nombreuses personnes.

Tous les exemples sont anonymisés et abstraits. Ils sont basés sur des situations réelles, mais les noms, les organisations et les détails identifiants ont été retirés à dessein. Le but n'est pas de montrer où l'expérience a été acquise, mais de montrer comment la pensée peut être appliquée dans tout environnement vaste et international.

Ce n'est pas un livre sur ce qui devrait fonctionner. C'est un livre sur ce qui fonctionne, systématiquement, quand les processus sont conçus pour évoluer, les systèmes sont alignés pour les soutenir, et les organisations sont prêtes à se transformer.

NOTE IMPORTANTE :

Les lecteurs sont vivement encouragés à consulter et à partager le contenu original via marvinpro.com. MarvinPro est une œuvre en évolution permanente, dont le contenu est régulièrement mis à jour afin d’intégrer de nouvelles perspectives, des cadres améliorés et des ressources d’apprentissage enrichies. Le contenu copié ou reproduit ailleurs peut ne plus refléter la version la plus récente, tandis que le site en ligne fournira toujours l’expérience d’apprentissage la plus actuelle et la plus complète.

© COPYRIGHT 1990-2026 MarvinPro

Tous droits réservés. Le contenu peut être librement consulté et partagé par lien. Vous êtes autorisé à partager des citations de cette œuvre à condition que l’attribution complète soit reproduite exactement telle qu’elle apparaît dans le texte, y compris la citation, le nom de l’auteur, l’année et marvinpro.com. La copie ou la reproduction d’autres parties, de sections complètes ou de chapitres sans autorisation préalable n’est pas autorisée.

Pensez Simple.