FDE en pratique (2) : De l'Excel sur le terrain à un modèle commercial exécutable

« Nous avons toujours utilisé Excel. »

C’est l’une des phrases les plus souvent entendues dans les projets de numérisation des entreprises. Cela ne signifie généralement pas que les clients ne veulent pas utiliser de système, mais cela rappelle que l’activité réelle existe déjà, les règles étant simplement dispersées dans des formules de tableau, des messages de groupe et l’expérience des personnes.

Dans le projet de cette usine de fabrication, les planificateurs enregistrent d’abord différents produits dans plusieurs sous-tableaux, puis les résument dans un tableau principal, évaluant manuellement les stocks, les en-cours, les spécifications d’emballage et les dates de péremption, pour finalement fournir à l’achat un « tableau de recommandations d’achat ». Cela ressemble à un tableau, mais en réalité, c’est une coquille d’un modèle commercial.

Ne pas demander « quelle page voulez-vous » lors des entretiens

Nous avons structuré les questions d’entretien en cinq dimensions. En posant ces questions, la discussion passe immédiatement de « à quoi ressemble la page » à « quelles sont les règles » :

1. D’où provient cette donnée, qui est responsable de sa validation ?

2. Quand peut-on passer à l’étape suivante, dans quelles situations doit-on s’arrêter ?

3. Quels champs sont des entrées de calcul, lesquels ne montrent que des résultats ?

4. Comment traiter les différents états, qui a le droit d’approuver ?

5. Qui doit finalement retracer, imprimer ou exporter cet enregistrement ?

Par exemple, « la quantité d’achat » n’est pas un problème que l’on peut résoudre simplement avec une case d’entrée. La planification fournit une quantité recommandée, l’achat ajustera la quantité réelle en fonction du conditionnement minimum, de la date de péremption, des devis des fournisseurs et des fluctuations du marché. Le système devrait conserver à la fois la valeur recommandée et la valeur réelle, plutôt que de remplacer le résultat de la planification par la dernière entrée de l’acheteur.

Remplacer les menus départementaux par des objets et des événements

Lors des réunions, chacun décrit le processus selon son département, ce qui conduit facilement à des menus tels que « module de vente, module d’achat, module d’entrepôt », sans voir les relations entre eux.

Nous avons réorganisé le contenu en objets commerciaux : commandes, produits, formules, matériaux, contrats d’achat, lots de stock, lots de production, enregistrements d’échantillonnage, enregistrements de sortie, relevés. Ensuite, nous avons mappé les verbes de la réunion en événements : confirmation, calcul, achat, entrée, échantillonnage, libération, planification de production, prélèvement, rapport de travail, expédition, encaissement.

Cela permet de découvrir plusieurs relations clés :

• La commande est la source de la demande, mais le contrat d’achat n’appartient pas directement à la commande.

• La formule est la base du calcul des besoins en matériaux, tout en nécessitant la conservation des versions historiques.

• Le lot d’entrée relie le prix d’achat et le coût de prélèvement ultérieur.

• Le lot de production peut correspondre à plusieurs commandes, la comptabilité devant à nouveau répartir lors de la réconciliation et de l’analyse des coûts.

• L’échantillonnage et les résultats de qualité peuvent modifier la disponibilité des stocks.

Cela est plus proche de ce que le système doit réellement exprimer que « faire une page pour chaque département », et facilite également la traçabilité et la réconciliation ultérieures.

Les règles de calcul doivent définir des limites

Ce qui est souvent sous-estimé dans le document de demande, ce sont les calculs. Nous avons décomposé les besoins en matériaux en trois niveaux : la quantité de commande multipliée par l’utilisation unitaire dans la formule, ce qui donne la demande brute ; la demande brute moins le stock disponible, ce qui donne la demande nette ; la demande nette combinée avec l’emballage, la date de péremption, les matériaux de substitution et la stratégie d’achat, formant la quantité d’achat recommandée.

Cette formule n’est pas suffisante, car « le stock disponible » n’est pas égal à la quantité totale dans le tableau des stocks. Les lots en attente, verrouillés et non conformes ne peuvent pas être utilisés directement ; après la planification de la production, le stock doit également être gelé pour éviter que deux commandes n’occupent le même stock.

Ainsi, chaque « généralement », « parfois », « selon les cas » dans les enregistrements d’entretien doit être suivi de questions sur son état correspondant et la personne responsable. Un calcul sans limites ne peut finalement être corrigé que manuellement, et le système ne pourra pas expliquer ses résultats.

Dessiner d’abord un minimum de boucle fermée acceptable

Nous avons défini la première boucle fermée comme suit : une commande de vente, après calcul des besoins en formule et en matériaux, déclenche l’achat et l’entrée, entre en production après libération de qualité, les produits finis sont expédiés par lots, et enfin des données de réconciliation et de coût sont générées. Les parties commerciales peuvent utiliser de vraies commandes, et l’équipe d’ingénierie peut également voir plus rapidement les problèmes inter-modules.

Dans cette chaîne, chaque module ne fait que ce qui est nécessaire pour compléter la boucle fermée. Par exemple, le centre de notification couvre d’abord les matériaux, l’échantillonnage, le prélèvement et les rappels d’approbation ; la formation, les examens, les ordres de maintenance et des rapports plus approfondis sont laissés pour plus tard.

La démonstration est un outil de demande, pas un outil de rapport

Lors de la première démonstration, la discussion est rapidement passée de « à quoi ressemble la page » à « qui initie la sortie de vente », « peut-on imprimer des documents avant que l’inspection ne soit terminée » et « comment réconcilier plusieurs commandes correspondant à un lot de production ». Ces questions n’apparaissent souvent pas dans les demandes écrites, car les utilisateurs ne réalisent que les accords verbaux précédents doivent être enregistrés dans le système lorsqu’ils voient un processus opérationnel.

Nous avons classé chaque retour de démonstration en trois catégories : erreur de règle, c’est-à-dire que l’état ou le calcul ne correspond pas à l’activité, et doit être corrigé ; information manquante, c’est-à-dire que la page, le document exporté ou la notification ne présentent pas les champs clés ; compromis de processus, c’est-à-dire que l’activité souhaite conserver le jugement humain, et le système ne fournit qu’une assistance. Après cette classification, l’équipe ne transformera pas tous les retours en champs, ni ne codera en dur tous les jugements humains.

Cette méthode est applicable à plus d’entreprises

1. D’abord, collecter les matériaux bruts, mais ne pas se précipiter pour écrire les demandes.

2. Ensuite, extraire les objets, événements, états, rôles et règles de calcul.

3. Puis, marquer les conflits et les éléments en suspens, retourner sur le terrain pour confirmation.

4. Ensuite, choisir une boucle fermée minimale qui peut produire des résultats réels.

5. Utiliser la démonstration pour valider les limites, puis décider quelles règles entrer dans le système.

6. Maintenir une distinction claire entre ce qui a été réalisé, ce qui est prévu et ce qui n’est pas traité pour le moment.

« Déplacer Excel dans une page web » n’est qu’un travail de surface. Le véritable travail consiste à transformer les jugements derrière les tableaux en règles visibles par toute l’équipe, tout en laissant de la place pour une confirmation humaine face à l’incertitude.