Comment amener le savoir de vos experts jusqu'en production

Chaque PME en croissance a sa Diane. Ça fait quatorze ans qu’elle travaille au service à la clientèle, à l’estimation ou à la gestion des commandes. Quand une commande bizarre entre, on la lui transfère. Elle y jette un œil trente secondes et dit : « C’est un compte de l’Ouest, ils veulent toujours des livraisons fractionnées, et ne cote pas la longueur de 40 pieds, l’aciérie est en rupture depuis le printemps. »

Rien de tout ça n’est écrit. Une partie se trouve dans un onglet de chiffrier nommé « NE PAS SUPPRIMER ». Une autre dort dans un fil de courriels de 2019. Mais l’essentiel, c’est Diane qui le porte.

C’est ça, la vraie matière première d’une IA utile dans une entreprise en exploitation. C’est aussi pour ça que la plupart des projets d’IA dans les entreprises axées sur les processus s’enlisent. Les équipes commencent par le modèle, le fournisseur ou l’entrepôt de données, alors que le savoir qui fait fonctionner le processus se trouve là où aucun des trois ne peut aller le chercher.

Ce billet porte sur la méthode : comment une équipe intégrée sort ce savoir de la tête des gens pour l’amener dans un système qui tourne en production, renvoie les cas difficiles aux humains et peut être audité plus tard. Nous avons expliqué ailleurs comment ces équipes intégrées sont constituées et structurées. Ici, on parle de ce qu’elles font une fois sur place.

Où se trouve vraiment le savoir opérationnel ?

À quatre endroits : les employés seniors, les chiffriers, les fils de courriels et de clavardage, et les vieux systèmes. Chacun demande sa propre technique d’extraction. Avant de capter quoi que ce soit, il faut une carte honnête des quatre.

Les employés seniors. La source la plus précieuse et la moins documentée. Un opérateur d’expérience applique des centaines de petites règles de décision, et il est incapable d’en formuler la plupart si on le lui demande directement. Demandez à Diane comment elle cote une commande urgente et vous aurez deux phrases. Regardez-la en coter vingt et vous trouverez onze règles.

Les chiffriers. C’est souvent ce qui ressemble le plus à un recueil de règles écrit. Un classeur de soumissions entretenu depuis huit ans contient des tables de correspondance, des colonnes de dérogation, des exceptions codées en dur et des formules qui traduisent des politiques d’affaires. Il contient aussi de la logique morte que personne n’utilise et que personne n’ose effacer.

Les fils de courriels et de clavardage. C’est là que les exceptions se négocient. « Peut-on renoncer au minimum pour ce client ? » « Oui, mais seulement sur les articles en stock. » Cette approbation est une règle. Elle ne s’est juste jamais rendue dans un système.

Les vieux systèmes. L’ERP (progiciel de gestion intégré), la vieille base Access, l’outil de commandes maison bâti en 2011. Ils contiennent les données structurées, plus une couche de logique enfouie dans des procédures stockées, des codes de statut et des conventions de champs (« si le numéro de bon de commande commence par X, c’est une commande en consignation »).

La plupart des initiatives d’IA ne regardent que la quatrième source, parce que c’est la plus facile à interroger. Le système qui en sort gère les cas simples et s’écroule sur tout ce que Diane aurait attrapé.

Comment capter un savoir qui n’a jamais été écrit ?

En faisant du terrain. Un atelier d’exigences ou un sondage ne vous mènera pas là. Voici les cinq techniques que nous utilisons, à peu près dans cet ordre.

1. Observer le travail, pas le document de processus

Assoyez-vous avec les gens qui font le travail. Pas le gestionnaire qui décrit le processus, l’opérateur qui l’exécute. Regardez de vraies transactions, en temps réel, avec ses vrais outils ouverts.

Deux règles rendent l’observation payante :

• Demandez « pourquoi » au moment de la décision. « Pourquoi as-tu changé les conditions de transport sur celle-là ? » donne une bien meilleure réponse sur le coup que dans une réunion deux semaines plus tard.
• Notez ce qu’ils consultent avant de décider. Si un estimateur vérifie la fiche de délais d’un fournisseur avant de soumissionner, cette fiche est un intrant de la décision. Elle doit aussi devenir un intrant du système.

Quelques jours d’observation auprès de deux ou trois opérateurs font habituellement ressortir plus de règles que des mois de documentation de processus.

2. Tenir un registre d’exceptions

Les cas normaux sont faciles à comprendre. Le savoir se cache dans les exceptions. Pendant deux à quatre semaines, demandez à l’équipe de consigner chaque transaction qui a exigé un jugement : ce qui est entré, ce qui était inhabituel, ce qu’elle a décidé et pourquoi.

Restez simple. Un formulaire partagé de cinq champs suffit, et le volume compte plus que la finition. Après quelques semaines, vous aurez quelques centaines de vraies exceptions, et elles vont se regrouper. La plupart des entreprises découvrent que ce qui semblait une variété infinie se résume à quinze ou vingt patrons récurrents, plus une longue traîne.

Ces regroupements vous disent ce que le système doit traiter automatiquement, ce qu’il doit signaler et ce à quoi il ne doit jamais toucher.

3. Faire de l’archéologie de chiffriers

Récupérez chaque chiffrier lié au flux de travail et lisez-le comme du code, parce que c’en est. Pour chacun, documentez :

• Quelles colonnes sont des intrants et lesquelles sont calculées
• Quelles formules traduisent une règle d’affaires (une marge plancher, un rabais par catégorie de client, un supplément de transport)
• Quelles cellules sont des dérogations manuelles, et à quelle fréquence on s’en sert
• Quels onglets sont morts

Les dérogations sont la partie intéressante. Une colonne « Ajust. » remplie sur 30 % des lignes vous dit que la formule ne reflète pas la façon dont l’entreprise établit vraiment ses prix. Trouvez qui la remplit et à quoi cette personne pense quand elle le fait.

4. Écrire les règles de décision noir sur blanc

Avec les notes d’observation, le registre d’exceptions et la logique des chiffriers en main, rédigez les règles en langage clair. Pas encore en code. Quelque chose comme :

Si le client est sur la liste de prix de l’Ouest ET que la commande comprend de l’acier coupé sur mesure ET que la date d’expédition demandée est à moins de 5 jours ouvrables, alors appliquer le supplément d’urgence, vérifier l’inventaire de l’aciérie avant de confirmer la longueur et proposer par défaut une livraison fractionnée.

Chaque règle a un responsable (la personne qui la connaît le mieux), une source (observation, registre d’exceptions, chiffrier, courriel) et un niveau de confiance. Certaines règles sont des politiques fermes. D’autres relèvent du « Diane fait habituellement ça ». Cette distinction change la façon dont le système les traite.

5. Valider avec les gens qui font le travail

C’est l’étape qu’on saute le plus souvent, et c’est comme ça qu’on finit avec un système que l’équipe ignore.

Ramenez les règles écrites aux opérateurs et passez-les en revue ligne par ligne. Rejouez ensuite l’historique : « Voici cinquante commandes du dernier trimestre. Voici ce que les règles disent qu’il aurait fallu faire. Voici ce qui s’est réellement passé. » Chaque écart est soit une règle manquante, soit une règle erronée, soit un cas où une personne a tranché autrement pour une raison qui mérite d’être comprise.

C’est aussi là que les opérateurs commencent à faire confiance au projet. Ils voient leur propre jugement reflété fidèlement, et ils peuvent le corriger. Ça fait plus pour l’adoption que n’importe quelle formation donnée plus tard.

Comment garder l’humain dans la boucle une fois les règles automatisées ?

N’automatisez pas toutes les règles sous prétexte que vous les avez captées. Bâtissez un système qui traite le travail routinier de façon fiable et qui envoie les cas qui demandent du jugement à la bonne personne, avec assez de contexte pour décider vite. Trois choix de conception rendent ça possible.

Des seuils de confiance avec un acheminement clair. Chaque décision du système porte un signal de confiance tiré des correspondances de règles, des scores du modèle, ou des deux. Au-dessus du seuil, le système agit. En dessous, le cas s’en va dans une file nommée, attribuée à une personne. Le seuil part prudent et bouge à mesure que l’équipe gagne confiance.

Du contexte à chaque transfert. Quand un cas arrive chez une personne, le système montre ce qu’il a vu, quelles règles se sont appliquées, ce qu’il aurait fait et pourquoi il s’est arrêté. L’opérateur ne devrait pas avoir à refaire l’enquête. Il devrait pouvoir approuver, ajuster ou déroger en moins d’une minute.

Chaque dérogation devient une donnée d’apprentissage. Quand quelqu’un modifie la recommandation du système, la dérogation est consignée avec un code de motif. Chaque semaine, quelqu’un passe les dérogations en revue. Les patrons récurrents deviennent de nouvelles règles. Les cas uniques restent humains. C’est comme ça que le système s’améliore sans qu’on réentraîne un modèle à partir de zéro.

Un système bâti de cette façon produit une piste d’audit par défaut. Pour chaque transaction, vous pouvez dire ce qui est entré, ce que le système a recommandé, quelles règles se sont appliquées, qui a approuvé et quand. La plupart des processus menés à coups de chiffriers ne peuvent répondre à aucune de ces questions aujourd’hui.

À quoi ça ressemble chez un distributeur de taille moyenne ?

Voici un scénario illustratif. C’est un composite, pas un client précis, mais chaque élément est typique : huit semaines entre l’observation terrain et un système encadré qui règle les exceptions de commande routinières et achemine le reste.

Le point de départ

Un distributeur industriel de 220 employés traite environ 400 commandes par jour. À peu près le quart exige une intervention manuelle avant d’être libéré : blocage de crédit, substitution, livraison fractionnée, dérogation de prix, exception de transport.

Une équipe de six personnes à la gestion des commandes s’en occupe. Deux d’entre elles sont là depuis plus de dix ans et prennent les cas les plus difficiles. Les règles se trouvent dans :

• Un classeur Excel de 14 onglets qui sert aux dérogations de prix et aux calculs de transport
• Les codes de blocage de commande de l’ERP, dont environ la moitié ne sont plus utilisés comme documenté
• Une boîte courriel partagée où les représentants demandent des exceptions
• Les deux coordonnatrices seniors

Les commandes qui exigent une intervention attendent en moyenne la majeure partie d’une journée ouvrable. Une des coordonnatrices seniors prévoit prendre sa retraite d’ici dix-huit mois. C’est ce qui rend le projet urgent.

Semaines 1 et 2 : observation et registre d’exceptions

Une cellule intégrée de trois personnes (un responsable de livraison, un ingénieur et un analyste des opérations) passe la première semaine assise avec l’équipe de gestion des commandes. Elle voit traiter environ 300 commandes en exception. En parallèle, l’équipe commence à consigner chaque exception dans un formulaire simple : numéro de commande, type d’exception, décision, motif.

À la fin de la deuxième semaine, le registre compte quelques centaines d’entrées. Elles se regroupent en 17 types d’exceptions récurrents. Cinq d’entre eux représentent l’essentiel du volume : blocages de crédit sur des comptes légèrement au-dessus de leur limite, substitutions pour des codes d’article abandonnés, livraisons fractionnées quand un entrepôt manque de stock, dérogations de transport pour certaines régions et renonciations au minimum de commande.

Semaines 2 et 3 : archéologie de chiffriers et extraction des règles

La cellule passe au peigne fin le classeur de 14 onglets. Six onglets sont morts. Trois contiennent la vraie logique de prix et de transport. Un onglet intitulé « Exceptions » est une liste tenue à la main des clients qui ont droit à un traitement spécial, avec des notes comme « selon Marc, 2021 ».

La cellule fouille aussi la boîte courriel partagée à la recherche de patrons d’approbation. Il en ressort que les renonciations au minimum de commande sont presque toujours accordées aux comptes au-delà d’un certain volume annuel, et presque jamais aux nouveaux comptes. Personne ne l’avait écrit. C’était simplement la façon de faire des deux coordonnatrices seniors.

Le résultat : un recueil d’environ 60 règles de décision, chacune avec une source, un responsable et un niveau de confiance.

Semaines 3 et 4 : validation

La cellule rejoue trois mois d’exceptions historiques contre le recueil de règles. Au premier passage, les règles concordent avec la décision humaine dans un peu moins des trois quarts des cas. Deux séances de travail avec les coordonnatrices permettent de démêler les écarts. La plupart viennent d’une poignée de règles manquantes, comme une règle de transport saisonnière et un groupe de clients à prix contractuels qui n’existaient que dans la mémoire de quelqu’un. Après les mises à jour, le taux de concordance grimpe assez pour que l’équipe soit à l’aise d’automatiser les principaux patrons.

Semaines 5 à 8 : bâtir le système encadré

Le système en production fait quatre choses :

1. Il classe chaque commande bloquée dans un des types d’exceptions connus, à partir des données de l’ERP et des notes de commande.
2. Il applique les règles pour les types à haute confiance et prépare une action recommandée, raisonnement à l’appui.
3. Il libère automatiquement un sous-ensemble défini (par exemple, les livraisons fractionnées quand les deux entrepôts ont du stock et que le client accepte les envois partiels) et consigne chaque libération.
4. Il achemine tout le reste vers la file de la bonne coordonnatrice, avec la recommandation, les règles appliquées et l’historique du client sur un seul écran.

Les dérogations sont consignées avec un code de motif. Chaque action est journalisée avec qui ou quoi a pris la décision. Les règles vivent dans une configuration versionnée que le directeur des opérations peut réviser, pas dans un modèle que personne ne peut examiner.

Les deux coordonnatrices seniors deviennent les premières réviseures du système. Leur rôle passe du traitement de chaque exception à la supervision du système et à la prise en charge des cas qu’il ne peut pas régler.

Qu’est-ce qui change ?

On mesure trois choses : le délai de libération des commandes bloquées, la part des exceptions réglées sans travail manuel et le taux de dérogation par type d’exception. Le résultat plus difficile à mesurer compte tout autant. Quand la coordonnatrice senior part à la retraite, les règles qu’elle portait se trouvent dans un système que l’équipe comprend, possède et peut modifier. Le savoir reste dans l’entreprise.

Qu’est-ce qui dérape le plus souvent ?

Cinq erreurs reviennent sans cesse. La plupart viennent de raccourcis pendant la captation ou d’un système qu’on néglige une fois en production.

Capter le processus officiel plutôt que le vrai. Si votre captation repose surtout sur des entrevues avec des gestionnaires, vous allez coder la façon dont le processus est censé fonctionner. L’observation terrain et le registre d’exceptions sont là pour corriger ce biais.

Automatiser des règles que personne ne voit. Si la logique de décision finit enfouie dans un prompt ou un modèle affiné sans recueil de règles lisible, vous venez de créer une nouvelle Diane, à qui l’équipe ne peut pas poser de questions. Gardez les règles explicites et versionnées partout où c’est possible. Servez-vous des modèles pour la classification et l’extraction, là où des intrants désordonnés exigent du jugement.

Traiter la validation comme une réunion d’approbation. Valider, c’est rejouer de vrais cas historiques contre les règles avec les opérateurs dans la pièce. Une revue de diapositives ne compte pas.

Sauter la revue des dérogations. La revue hebdomadaire des dérogations est ce qui garde le système à jour avec l’entreprise. Sautez-la pendant un trimestre et le système s’éloigne de la réalité, l’équipe cesse de lui faire confiance, et le taux de dérogation grimpe jusqu’à ce que quelqu’un le débranche.

Viser trop large dès le départ. Captez un flux de travail comme il faut avant d’essayer de cartographier toutes les opérations. Pour choisir ce premier flux, voyez comment prouver la valeur de l’IA sur un seul problème. Passer du projet pilote à un système qui tourne a ses propres pièges, que nous abordons dans pourquoi les projets pilotes d’IA s’enlisent.

Qui devrait prendre en charge la captation du savoir ?

Les gens qui captent le savoir devraient aussi bâtir le système. Si une firme interroge votre équipe et qu’une autre écrit le code, chaque règle est traduite deux fois et une partie se perd chaque fois. Une cellule intégrée qui observe vos opérateurs à la première semaine et livre le système en production à la huitième garde le contexte intact.

La propriété à la fin compte tout autant. Le recueil de règles, le code, l’historique des dérogations et le contexte opérationnel devraient vous appartenir. Votre prochain flux de travail devrait partir de ce que le premier a laissé, pas d’une page blanche. Nous creusons le sujet dans ce qu’un mandat d’IA devrait laisser derrière lui, et sur l’importance de garder vos gens au centre du système dans une IA qui rend votre équipe meilleure, pas plus petite.

Foire aux questions

Combien de temps faut-il pour capter le savoir institutionnel d’un flux de travail ?

Pour un seul flux, prévoyez environ quatre semaines de captation et de validation : une à deux semaines d’observation et de registre d’exceptions, une semaine d’analyse des chiffriers et des courriels, puis une semaine à rejouer des cas historiques. La construction du système encadré en production prend habituellement quatre autres semaines.

Les règles captées devraient-elles vivre dans un modèle d’IA ou dans des règles explicites ?

Gardez les règles d’affaires explicites, versionnées et lisibles par l’équipe des opérations. Utilisez des modèles là où les intrants sont désordonnés, par exemple pour classer une commande ou extraire des détails de notes en texte libre. Un recueil de règles enfoui dans un prompt ou un modèle affiné ne peut pas être révisé ni corrigé par les gens responsables du processus.

Que se passe-t-il quand le système se trompe ?

Il ne devrait jamais agir seul sur les cas où il a un doute. Les cas à faible confiance vont dans la file d’une personne nommée, avec tout le contexte, et chaque dérogation est consignée avec un code de motif. Une revue hebdomadaire transforme les dérogations récurrentes en nouvelles règles.

Si vous avez un flux de travail qui dépend de deux ou trois personnes qui portent les règles dans leur tête, nous aimerions en entendre parler. Prenez rendez-vous avec Chrono Innovation et nous verrons ensemble comment nous le capterions, ce que nous automatiserions en premier et ce qui devrait rester entre les mains de votre équipe.