Epidom : centraliser les opérations d'inventaire multi-sites

L'inventaire multi-sites fait à la main échoue de façon prévisible : chaque site garde sa propre vue, les chiffres dérivent, et les réconcilier consomme un temps qui croît avec chaque nouveau site. Le coût n'est pas un grand échec mais une taxe opérationnelle constante — surcharge, ruptures de stock, et décisions prises sur des données périmées.

Pour Epidom, le goulot était exactement cela : un processus de suivi manuel et multi-sites qui ne pouvait suivre le rythme de l'opération.

Le travail a suivi la méthode standard : cartographier l'opération avant de construire, définir en termes mesurables ce qu'est une vue d'inventaire correcte et à jour, et construire le plus petit système de production qui la délivre — un suivi centralisé qui remplace le processus manuel au lieu de s'y superposer.

Comme pour chaque mission, le système a été construit pour être possédé et exploité par le client, afin que la capacité reste en interne après livraison.

Le processus manuel, site par site, a été remplacé par un système centralisé unique, supprimant la charge de réconciliation et donnant à l'opération une vue exacte de l'inventaire entre les sites. Selon le résumé public du projet, cela a réduit la charge opérationnelle.

Les métriques détaillées avant/après sont en préparation pour publication et apparaîtront ici et sur la page de transparence.

La leçon se généralise à tout opérateur multi-sites : le premier build au ROI le plus élevé est rarement le plus spectaculaire — c'est celui qui supprime la taxe de réconciliation manuelle qui croît avec chaque site. Centralisez d'abord la source de vérité ; tout le reste se compose à partir de là.

Si votre opération gère des chiffres critiques dans des tableurs que chaque site maintient séparément, c'est généralement le goulot à cartographier en premier.

Dans l'agroalimentaire, le problème d'inventaire est structurellement plus difficile que dans la plupart du commerce multi-sites, parce que le stock est périssable, l'unité de mesure se déplace à mesure que les ingrédients passent de la livraison à la préparation puis à l'assiette, et que le gaspillage est une véritable ligne de compte plutôt qu'une erreur d'arrondi. Chaque site développe ses propres conventions — ce qu'est une « caisse », comment on compte un stock entamé, à quel moment a lieu un comptage — et ces conventions restent invisibles jusqu'à ce que quelqu'un tente d'additionner les chiffres. La dérive n'est pas de la négligence ; c'est le résultat prévisible de chaque site qui optimise sa propre journée alors qu'aucune définition partagée n'existe au-dessus d'eux.

Si cela se répète d'un opérateur à l'autre, c'est que l'approche manuelle fonctionne parfaitement à un ou deux sites et échoue silencieusement à cinq ou dix. Un fondateur qui pouvait tenir toute l'opération en tête ne le peut tout simplement plus dès qu'elle s'étend à plusieurs sites, et le tableur qui a porté la première expansion devient ce qui plafonne la suivante. Au moment où la charge se fait sentir comme une taxe, l'opération a généralement déjà fait transiter de l'argent réel — surcommande, dépannages d'urgence, pertes comptabilisées — par l'écart entre ce que chaque site croit avoir et ce qu'il a réellement.

Reconnaître ce schéma compte, parce qu'il indique où doit aller le premier build. L'instinct pousse souvent à courir après un système de prévision ou de prédiction de la demande — le projet visiblement intelligent. Mais une prévision bâtie sur des chiffres qui ne se réconcilient pas est une réponse fausse pleine d'assurance. Le séquencement honnête consiste à rendre la vue actuelle correcte et partagée avant de tenter d'en prédire quoi que ce soit, et c'est exactement pourquoi une source de vérité centralisée, et non un modèle, est le bon premier build pour un opérateur à ce stade.

La façon tentante de centraliser l'inventaire multi-sites est de laisser en place le processus de chaque site et de construire des connecteurs qui font remonter les chiffres de tous les sites dans un tableau de bord. Cela fait une belle démo et ne change presque rien — parce qu'un tableau de bord posé sur des données incohérentes hérite de l'incohérence. Si deux sites comptent différemment le stock entamé, aucune agrégation ne les réconcilie ; le tableau de bord ne fait qu'afficher le désaccord en plus haute résolution. Le travail qui supprime réellement la charge se situe en amont : convenir d'une seule définition d'un article, d'un comptage et d'un site, et faire en sorte que chaque site enregistre selon ce modèle unique plutôt que de le traduire après coup.

C'est pourquoi le Diagnostic d'un build de ce genre consacre son effort au domaine avant qu'aucun écran ne soit conçu. Les questions qui décident du résultat sont sans éclat — quelle est l'unité canonique de chaque ingrédient, quel événement constitue une sortie de stock, comment représenter un transfert entre sites pour qu'il ne soit pas compté deux fois — et il est bien moins coûteux d'y répondre sur le papier que de les découvrir en production. Définir « une vue d'inventaire correcte et à jour » en termes mesurables est ce qui transforme un projet de tableau de bord sans limites en un build borné, doté d'un critère clair pour savoir quand c'est fini.

Le bénéfice d'un modèle bien posé est que la cohérence devient une propriété du système plutôt qu'une discipline que le personnel doit entretenir. Quand chaque site écrit selon les mêmes définitions, la réconciliation cesse d'être une tâche récurrente parce qu'il n'y a plus rien à réconcilier — les chiffres n'ont jamais eu la possibilité de diverger. C'est la différence entre un logiciel qui signale le problème et un logiciel qui le supprime, et c'est la raison pour laquelle le build remplace le processus manuel au lieu de se poser à côté.

La discipline d'une horloge fixe de huit semaines est surtout la discipline de savoir dire non, et un build de ce genre a une liste évidente de choses à refuser. Le réapprovisionnement automatisé, les intégrations fournisseurs, la prévision de la demande et le calcul dynamique du coût des menus sont tous des ambitions raisonnables pour un système d'inventaire mature — et tous se situent en aval d'une vue de stock unique, exacte et partagée, qui n'existait pas encore. Les construire d'abord aurait signifié bâtir de la sophistication sur des chiffres qui dérivaient encore, ce qui est la manière dont les projets d'IA se dotent de fonctionnalités impressionnantes auxquelles personne ne fait assez confiance pour agir.

Le périmètre délibéré était le plus petit système de production qui rend la vue d'inventaire actuelle correcte et partagée entre les sites, avec la télémétrie permettant de savoir qu'elle le reste. Cette retenue n'est pas de la prudence pour la prudence ; c'est ce qui permet à l'opération de prouver que la fondation fonctionne avant d'automatiser la moindre décision par-dessus. Un dirigeant qui peut enfin faire confiance à un seul chiffre sur tous les sites est en bien meilleure position pour cadrer le build suivant — et pour le faire face à un usage réel plutôt qu'à une liste de souhaits écrite avant que la fondation n'existe.

Nommer la frontière est aussi une façon honnête de parler de séquencement plutôt que de capacité. La prévision et le réapprovisionnement automatisé ont une réelle valeur, et un opérateur multi-sites les voudra sans doute — plus tard, comme un second build cadré à partir de la télémétrie du premier. Le point transférable est que l'ordre est tout l'enjeu : la source de vérité centralisée est l'actif qui rend possible tout ce qui vient après, et tenter d'abord la couche intelligente est la manière la plus courante de ne jamais construire la fondation.

Il existe quelques signaux honnêtes qu'une opération a le goulot en forme d'Epidom. Les comptages de stock vivent dans des tableurs par site que quelqu'un consolide à la main. Le même article est décrit différemment selon qui l'a saisi. Une question aussi élémentaire que « combien en avons-nous sur tous les sites en ce moment ? » prend des heures et produit une réponse que les gens, en silence, ne croient pas. Et le temps passé à réconcilier croît chaque fois qu'un site est ajouté, au lieu de rester stable. Si deux de ces signaux ou plus sont vrais, la taxe de réconciliation manuelle est réelle et constitue presque certainement ce qu'il faut cartographier en premier pour le meilleur rendement.

La limite honnête est qu'un système centralisé règle la structure du problème, pas ses entrées. Si les comptages sont saisis sans soin, ou si du stock sort physiquement par la porte de derrière, aucun modèle ne rendra les chiffres vrais — le logiciel impose une seule définition d'un comptage, mais il ne peut imposer que le comptage ait été fait honnêtement. Ce que le système fait, c'est rendre les écarts visibles et attribuables, ce qui suffit souvent à changer les comportements, mais la discipline d'une saisie exacte demeure une responsabilité humaine que le logiciel soutient plutôt qu'il ne la remplace.

Il vaut aussi la peine de dire clairement ce que cette catégorie de build ne livre pas : à elle seule, elle ne réduit pas le gaspillage, ne diminue pas le coût fournisseur et n'améliore pas la marge. Elle supprime la charge de tenir les chiffres au carré et donne à l'opération une base fiable pour prendre ces décisions. L'amélioration de marge est quelque chose que l'opérateur gagne en agissant sur une vue claire — le travail du build est de s'assurer que la vue vaut enfin la peine qu'on agisse dessus.