En fabrication et en distribution, l’adoption de l’IA commence par le savoir derrière le travail

En bref. Avant qu’un agent IA puisse traiter des commandes clients, il lui faut plus qu’un accès à l’ERP. Il lui faut les règles, le contexte et les exceptions que vos gens d’expérience appliquent sans y penser, chacun avec une source, une portée et un responsable. Et il lui faut une ligne claire entre ce qu’il peut faire seul et ce qui revient à une personne. Commencez par un vrai workflow :

1. Choisissez un travail dont la fin est claire.
2. Documentez pourquoi chaque vérification existe.
3. Attribuez séparément le savoir, les décisions et l’exécution.
4. Testez les passages de relais aussi soigneusement que les cas courants.
5. Transformez les corrections en savoir que l’entreprise peut tenir à jour.
6. Élargissez en fonction des manques dans le travail terminé.

Si vous dirigez les opérations ou le service à la clientèle chez un distributeur ou un manufacturier, on vous a sans doute posé cette année une version de la même question : quel est notre plan pour l’IA ?

Vous avez peut-être déjà mené un projet pilote. Il lit les courriels et extrait les lignes de commande. Et les commandes difficiles aboutissent encore chez les trois ou quatre mêmes personnes d’expérience, celles que tout le monde appelle quand la réponse n’est pas claire. L’équipe de gestion des commandes grossit encore une embauche à la fois, et chaque nouvelle recrue doit encore apprendre ce que ces personnes savent.

Ce n’est pas un problème de modèle. L’IA avait accès aux données. Il lui manquait le savoir derrière le travail.

Prenons, à titre d’illustration, une commande chez un distributeur de matériaux de construction. Un client envoie par courriel une liste rédigée avec ses propres descriptions de produits. Un article n’est pas disponible. Un message précédent indique que le chantier ne peut pas recevoir de livraisons partielles. Un équivalent est en inventaire, mais quelqu’un doit confirmer qu’il convient à cette application.

L’ERP, SAP ou autre, fournit les fiches clients, les produits, les prix et l’inventaire. Terminer la commande dépend aussi de consignes dans la correspondance, d’un jugement sur le produit et d’une compréhension de ce que le client a accepté.

Un commis aux commandes d’expérience relie ces éléments presque sans y penser. C’est du savoir tacite : rarement écrit, porté par quelques personnes, et menacé chaque fois que l’une d’elles part. Un agent peut avoir accès à toutes les fiches et manquer quand même de ce qu’il faut pour agir de façon responsable. Il lui faut un moyen de trouver le savoir pertinent, de comprendre où il s’applique et d’agir dans les limites de l’autorité que l’entreprise lui a donnée.

C’est là que l’adoption de l’IA devient un problème de conception opérationnelle. Avant de déléguer le travail, l’entreprise doit comprendre ce dont il dépend.

Séparez le savoir de la façon dont il circule aujourd’hui

Un processus parallèle peut contenir une règle d’affaires importante. Un bout de code sur mesure peut imposer une condition dont la raison d’être est devenue difficile à retrouver. Une relation client peut porter des engagements qui ne sont jamais devenus des consignes formelles.

Les traiter comme un seul problème d’automatisation crée deux risques. Vous pouvez reproduire un processus lourd simplement parce que c’est ainsi que le savoir circule. Ou vous pouvez retirer une étape et perdre la raison pour laquelle elle existait. (Nous y revenons dans notre article sur les processus parallèles.)

Dans l’exemple de la commande, un employé appelle peut-être un chargé de compte chaque fois qu’un article n’est pas disponible. Avant d’automatiser ou de retirer cet appel, demandez-vous ce qu’il accomplit. Le chargé de compte valide-t-il que le produit convient, obtient-il l’autorisation d’expédier en deux, ou protège-t-il une promesse faite au client ? Chaque réponse implique une responsabilité différente.

L’entreprise peut parfois changer la façon dont le travail se fait tout en préservant le jugement ou l’engagement qui le sous-tend.

Chez Frontleap, nous croyons que la connaissance opérationnelle doit devenir un actif durable qui appartient à l’entreprise, accessible aux personnes et aux agents au moment où le travail se fait. Elle doit aider l’entreprise à décider qui peut prendre en charge chaque partie du travail, et à quelles conditions.

Le but n’est pas de maximiser la part du travail faite par l’IA. C’est d’augmenter ce que les opérations peuvent accomplir, et ce que les gens sont libres d’y apporter. Voici une approche concrète pour y arriver, un workflow à la fois. C’est aussi un plan que vous pouvez présenter à votre équipe de direction : il commence petit, il garde votre ERP en place et il protège ce que vos gens savent.

1. Choisissez un travail dont la fin est claire

Commencez par un workflow délimité, comme préparer une commande reçue par courriel pour sa revue et sa saisie dans l’ERP.

Définissez ce que « terminé » veut dire :

• le client et le lieu de livraison sont confirmés ;
• les produits et les quantités sont vérifiés ;
• les consignes de livraison sont prises en compte ;
• les questions non résolues ont un responsable.

Suivez les employés pendant le travail. Notez les moments où ils sortent du système, consultent un collègue ou vérifient une conversation antérieure. Ces moments aident à révéler ce que le workflow doit prendre en charge.

2. Documentez pourquoi chaque vérification existe

Asseyez-vous avec vos gens les plus expérimentés et demandez-leur pourquoi ils se sont arrêtés. Qu’est-ce qui rendait douteuse la correspondance avec le produit ? Pourquoi ont-ils relu un vieux courriel ? Qu’est-ce qui aurait mal tourné s’ils avaient continué ? C’est là que le savoir tacite commence à devenir quelque chose qui appartient à l’entreprise.

Pour chaque consigne ou règle, notez sa source, sa portée et son responsable. Une restriction de livraison peut s’appliquer à une commande, à un chantier ou à toutes les commandes de ce client. Une substitution acceptée une fois ne devient pas automatiquement un équivalent approuvé partout.

Demandez au responsable concerné de distinguer une pratique approuvée d’un processus parallèle temporaire ou d’une habitude individuelle. C’est aussi le moment de remettre en question les règles qui ne servent plus à rien.

3. Attribuez séparément le savoir, les décisions et l’exécution

Connaître une règle, décider comment elle s’applique et exécuter une action sont des responsabilités distinctes. Attribuez chacune délibérément.

Dans notre exemple :

• un agent pourrait repérer la consigne « pas de livraison partielle » et signaler qu’un article non disponible empêche la commande de la respecter ;
• un spécialiste produit qualifié pourrait évaluer si l’équivalent convient à l’application ;
• une personne ayant l’autorité voulue pourrait ensuite obtenir l’accord du client pour un changement.

Là où une règle approuvée détermine entièrement la prochaine action, l’entreprise peut autoriser un agent à l’exécuter. Là où la situation exige du jugement, une négociation ou un engagement qui dépasse cette autorité, acheminez-la vers la bonne personne, avec le contexte pertinent.

Précisez ce qui peut continuer, ce qui doit être mis en pause et ce qui permet au travail de reprendre. La responsabilité doit suivre le savoir et l’autorité qu’exige cette décision précise.

Rien de tout cela ne retire le spécialiste du travail. Son jugement fait partie de ce que l’entreprise vend. L’humain n’est pas le plan de secours ; l’humain fait partie du modèle opérationnel.

4. Testez les passages de relais aussi soigneusement que les cas courants

Testez le workflow avec des commandes passées représentatives, y compris des cas avec des descriptions ambiguës, des consignes contradictoires et des produits non disponibles.

Vérifiez trois choses :

• il reconnaît l’incertitude ;
• il trouve la règle pertinente ;
• il envoie la question non résolue à quelqu’un qui peut y répondre.

Testez ensuite ce qui se passe une fois la réponse revenue.

La personne qui révise doit pouvoir voir la demande d’origine, la consigne appliquée, l’action proposée et ce qui reste incertain. Elle doit comprendre ce que son approbation va déclencher.

Une exception est couverte quand le workflow peut la mener jusqu’à sa résolution. Une alerte qui oblige un employé à reconstituer la situation ailleurs laisse encore du travail à faire.

5. Transformez les corrections en savoir que l’entreprise peut tenir à jour

Quand quelqu’un corrige une commande, demandez-vous ce que la correction enseigne. S’agissait-il :

• d’un accommodement ponctuel pour un client ;
• d’une consigne manquante ;
• d’une règle périmée ;
• ou d’une limite de l’autorité de l’agent ?

Confiez à un responsable le soin de décider quels changements deviennent du savoir partagé. Notez où ils s’appliquent et retirez les consignes qu’ils remplacent.

Une correction sur une commande ne doit pas changer en silence le traitement de toutes les commandes futures. Documenter une réponse sans sa portée ne fait que rendre la mauvaise réponse plus facile à répéter. Une fois validé pour un usage plus large, l’apprentissage doit aider le prochain employé ou le prochain agent devant la même situation.

6. Élargissez en fonction des manques dans le travail terminé

Mesurez si le workflow choisi aide l’équipe à obtenir les bons résultats. Comparez des commandes semblables et suivez le temps de préparation, les corrections, les questions non résolues et les erreurs découvertes après coup.

Notez pourquoi le travail bloque. Un savoir produit manquant appelle une amélioration différente d’une règle d’approbation floue ou d’une consigne client que personne ne trouve.

Servez-vous de ces manques pour choisir quoi ajouter ensuite. Un workflow qui traite les commandes d’une succursale peut avoir besoin d’autres règles ou d’autres responsabilités avant de pouvoir soutenir une autre succursale ou une autre catégorie de produits.

Un exemple complet, du courriel à la commande prête pour SAP

Exemple illustratif : le client, les produits et les quantités sont inventés.

1. Le courriel. Martin Roy écrit à l’équipe de gestion des commandes : 40 deux-par-six « de la longueur habituelle », 12 feuilles de gypse vert 5/8, 6 boîtes de vis à terrasse, « même chantier que la dernière fois ».
2. Le produit ambigu. « La longueur habituelle » n’est pas un code de produit, et le gypse vert 5/8 est en rupture à la succursale qui dessert le lot 14.
3. Le contexte retrouvé. L’agent retrouve les trois dernières commandes de Martin pour le lot 14, toutes en deux-par-six de 16 pieds, et un courriel précédent qui précise que le chantier ne peut pas recevoir de livraison partielle. Il trouve aussi un équivalent en inventaire pour le gypse vert.
4. La décision du représentant. L’agent peut associer les deux-par-six seul : la règle est claire. La substitution, elle, change ce que le client reçoit. Le représentant du service à la clientèle vérifie que l’équivalent convient à l’application et appelle Martin, qui accepte.
5. La commande, prête pour SAP. Client, livraison au lot 14, 40 deux-par-six de 16 pieds, 12 feuilles de l’équivalent approuvé, 6 boîtes de vis à terrasse, livraison complète. La substitution est consignée avec sa raison et sa portée : cette commande, pas toutes les prochaines.

Rendez le savoir réutilisable, puis revoyez qui fait le travail

Un point de départ utile pour l’adoption de l’IA, c’est une vraie commande et un regard attentif sur tout ce qu’il faut pour la terminer.

Repérez le savoir qui se trouve dans les systèmes, les processus parallèles, le code sur mesure, l’expérience des employés et la relation client. Comprenez ce que chaque élément apporte. Décidez ensuite quoi préserver, quoi changer, et quelles responsabilités reviennent à une personne ou à un agent.

Pour votre prochain workflow, posez-vous la question : qu’est-ce qui doit être compris, qui a l’autorité de décider, et qu’est-ce qui peut être délégué une fois ces conditions claires ?

C’est ce que nous construisons chez Frontleap : la gestion des commandes par IA pour les manufacturiers et les distributeurs sur SAP, conçue comme une couche d’exécution qui fonctionne aux côtés de l’ERP. Elle capte la connaissance opérationnelle qui ne se trouve nulle part dans vos systèmes et donne aux personnes et à l’IA un seul endroit pour agir ensemble à partir de celle-ci. Nous commençons par les commandes, parce que c’est là que le lien avec le client est immédiat (découvrir Order Desk). J’explique la conviction qui la sous-tend dans notre manifeste.

Questions fréquentes

Comment réduire la dépendance de l’équipe de gestion des commandes envers quelques personnes d’expérience ?

Recueillez ce que ces personnes savent pendant que le travail se fait, pas dans un manuel. Suivez-les dans un vrai workflow et notez chaque fois qu’elles sortent du système. Documentez chaque règle qu’elles appliquent avec sa source, sa portée et son responsable. Le savoir reste alors dans l’entreprise quand les gens s’en vont, et les nouvelles recrues peuvent s’y appuyer dès le premier jour.

Comment garder à jour le savoir sur les commandes quand les catalogues, les prix et les équipes changent ?

Donnez un responsable à chaque règle. Quand quelqu’un corrige une commande, le responsable décide si la correction devient du savoir partagé, où elle s’applique et quelle ancienne consigne elle retire. Une correction sur une commande ne doit jamais changer en silence toutes les commandes futures.

Qu’est-ce qu’un agent IA devrait traiter seul, et qu’est-ce qui devrait rester entre les mains d’une personne ?

Un agent peut agir là où une règle approuvée détermine entièrement la prochaine étape. Le jugement, la négociation et les engagements qui dépassent son autorité vont à la bonne personne, avec le contexte joint. Mettez par écrit ce qui continue, ce qui est mis en pause et ce qui permet au travail de reprendre, avant de déléguer quoi que ce soit.