Lorsqu'un processus complexe est automatisé, le désordre ne disparaît pas ; il se modifie simplement en ampleur et en vitesse. Un critère ambigu appliqué par une personne engendre des décisions incohérentes qui finissent par être remarquées ; le même critère ambigu appliqué par un système produit des milliers de décisions systématiquement erronées avant que quiconque ne s'en aperçoive.
Ce changement d'échelle est ce qui fait qu'automatiser un mauvais processus est pire que de le laisser tel quel, et non pas simplement identique.
L'erreur devient indétectable par contraste. Dans un processus manuel, la variabilité interpersonnelle agit comme un système d'alerte : lorsqu'une personne résout un problème différemment, la divergence est discutée et l'approche corrigée. L'automatisation élimine cette variabilité et, par conséquent, le signal d'alerte.
La correction cesse d'être ponctuelle. Découvrir une erreur trois semaines plus tard ne signifie pas simplement corriger le dossier ; cela implique de revoir et de refaire tout le travail effectué durant ces trois semaines. Le coût de la correction de l’erreur augmente proportionnellement au temps écoulé depuis sa détection.
Les exceptions se multiplient au lieu de diminuer. Un processus mal défini génère des cas non conformes. Même automatisés, ces cas continuent d'affluer et nécessitent désormais un traitement manuel en dehors du flux de travail, ce qui engendre souvent une surcharge de travail.
Les responsabilités deviennent floues. Lorsqu'un cas est mal géré, la réponse devient « c'est le système qui a fait ça ». Et ce n'est pas une réponse utile pour un client ou un auditeur, comme l'a clairement montré le cas du chatbot d'Air Canada résolu en 2024 : l'entreprise est responsable de ce que fait son logiciel.
Moment | Ce qui est observé | Que se passe-t-il réellement ? |
|---|---|---|
Semaines 1-2 | Tout fonctionne, l'enthousiasme est palpable. | Les cas simples sont traités |
Semaines 3 à 6 | Des cas « rares » apparaissent» | Des exceptions non prévues émergent |
Mois 2 à 4 | Le travail manuel parallèle est en pleine croissance. | Le processus a bifurqué |
Mois 4 à 6 | Une erreur systématique est détectée. | Les données historiques doivent être réexaminées. |
La séquence est tellement répétitive qu'elle sert d'outil de diagnostic. Si un projet d'automatisation se déroule bien pendant les premières semaines, puis commence à générer du travail parallèle au cours du deuxième mois, le problème ne vient pas de l'implémentation : c'est que le processus n'a pas été défini lors de son automatisation.
Il existe un contrôle préliminaire qui prend un après-midi et qui permet d'éviter la plupart de ces cas : Donnez le même ensemble de vingt cas réels à trois personnes différentes de l'équipe et comparez leurs décisions..
Si les trois critères convergent vers dix-huit ou plus, le processus est suffisamment bien défini pour être automatisé. S'ils convergent vers douze, il n'y a pas de processus : trois critères coexistent et l'automatisation consiste à en choisir un sans en informer personne.
Cet exercice présente également une vertu politique : il transforme une discussion abstraite sur la maturité des processus en un fait que personne ne conteste.
Découvrir qu'un processus n'est pas prêt ne signifie pas qu'il faille tout reporter de six mois. Trois interventions permettent d'obtenir rapidement des résultats concrets :
Définir les critères dans les cas fréquents. Pas toutes : la section 80% de l’ouvrage se concentre généralement sur quatre ou cinq situations. La définition écrite des critères de ces cinq situations permet de lever la plupart des ambiguïtés lors d’une séance de travail.
Automatisez uniquement la préparation. Rassemblez les informations, comparez-les et présentez-les de manière à permettre à chacun de prendre une décision. Cela permet de réaliser d'importantes économies et d'éviter la diffusion de fausses informations.
Instrument avant automatisation. La mesure du processus manuel sur quelques semaines permet d'établir une base de référence et de révéler la variabilité réelle, qui est précisément l'information manquante nécessaire à la prise de décision.
Les trois options sont compatibles avec une évolution future. Aucune ne nécessite une refonte complète avant d'apporter des modifications.
Il est important de quantifier l'effet de renversement, car c'est ce qui peut transformer un projet rentable en un projet ruineux.
Si un système traite deux cents dossiers par jour et qu'une erreur systématique est détectée après six semaines, il reste environ six mille dossiers à examiner. Même si seul le dossier 10% est concerné, cela représente six cents dossiers à corriger, sans compter la communication avec le client, les ajustements comptables et l'impact sur la réputation.
Ce calcul n'apparaît quasiment jamais dans l'analyse de rentabilité, et c'est pourquoi le délai avant défaillance devrait être un indicateur de performance du comité, comme nous l'avons soutenu dans L'automatisation sans observabilité est irresponsable.
Avant d'automatiser un processus, une question guide la décision : Si cela s'avère systématiquement erroné, quand le découvririons-nous et combien coûterait la correction ?
Si la réponse est « en quelques heures et en un clic », le risque d'automatiser un processus imparfait est acceptable et il est judicieux de poursuivre. Si la réponse est « en quelques semaines, et il faudrait analyser les données historiques », le processus doit être défini avant toute automatisation.
Ce n'est pas une question de prudence. C'est une question d'arithmétique.
L'échelle des changements liés au désordre : un critère ambigu appliqué par une personne produit des décisions incohérentes que quelqu'un finit par remarquer, tandis qu'appliqué par un système, il produit des milliers de décisions systématiquement erronées avant que quiconque ne le détecte.
La variabilité individuelle agit comme un système d'alarme : lorsqu'une personne résout un problème différemment, la différence est discutée et l'approche est corrigée. L'automatisation élimine cette variabilité et, par conséquent, le signal qui a permis de détecter le problème.
En soumettant un même ensemble de vingt cas concrets à trois membres de l'équipe et en comparant leurs décisions, on définit le processus. S'ils s'accordent sur au moins dix-huit critères, le processus est défini ; s'ils s'accordent sur douze, plusieurs critères coexistent et l'automatisation consiste à en choisir un sans décision explicite.
Trois choses compatibles pour aller de l'avant : définir les critères pour les quatre ou cinq cas qui concentrent le volume 80%, automatiser uniquement la préparation des informations en laissant la décision à une personne, et mettre en œuvre le processus manuel pendant quelques semaines pour obtenir la base de référence.
Ce nombre augmente avec le temps de détection. Un système traitant deux cents cas par jour et chez qui un défaut est détecté après six semaines implique l'examen d'environ six mille cas ; même si seul le code 10% est concerné, cela représente six cents corrections, incluant la communication avec le client et l'ajustement comptable correspondant.
Si le système présente des erreurs systématiques, quand seraient-elles détectées et quel serait le coût de leur correction ? Si la réponse est en quelques heures et en un seul clic, le risque est acceptable ; si cela prend des semaines et nécessite l’analyse de données historiques, le processus doit être défini avant toute automatisation.
Votre processus est-il prêt à être automatisé ? Nous le testons avec des cas concrets avant même d'écrire une seule ligne de code, et nous vous indiquons quelle partie doit être automatisée et quelle partie doit être définie en premier. Parlons-en →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
