Trois usines, trois tableaux de bord. L'usine A affiche un taux de rebut de 2,1 %. L'usine B, qui produit pourtant le même sous-ensemble, annonce 4,7 %. L'usine C ne remonte pas de taux de rebut mais un « taux de non-conformité première présentation » de 3,2 %. Le directeur industriel demande une consolidation ; trois semaines plus tard arrive un fichier de synthèse, assorti d'une page entière de notes de bas de page expliquant pourquoi les chiffres ne sont pas comparables.
Cette scène, tout dirigeant d'un groupe multi-sites l'a vécue. Le réflexe habituel : lancer un projet d'harmonisation des indicateurs, déployer une BI commune, créer un entrepôt de données groupe. C'est traiter le symptôme. Le problème est en amont, dans la donnée produit elle-même : des nomenclatures qui divergent d'un site à l'autre, des référentiels articles incompatibles, des définitions techniques qui n'ont de commun que le nom.
Le symptôme : des KPI qui ne mentent pas, mais qui ne parlent pas de la même chose
Écartons d'emblée une hypothèse rassurante : non, vos usines ne trafiquent pas leurs chiffres. Chaque KPI local est calculé honnêtement, par des équipes compétentes. Le problème est ailleurs : chaque site calcule un indicateur localement vrai sur une base localement définie.
Prenez le taux de rebut. Pour le comparer entre deux usines, il faudrait s'accorder sur trois choses au minimum : ce qu'est une « pièce » (un article fini ? un sous-ensemble ? une opération ?), ce qu'est un « rebut » (une mise au rebut physique ? une retouche ? un déclassement ?), et surtout sur quelle nomenclature l'indicateur est assis. C'est précisément là que tout diverge : l'usine A calcule sur la mBOM de son MES local, l'usine B sur les ordres de fabrication de son ERP dont la nomenclature a été adaptée il y a quatre ans, l'usine C, rachetée il y a deux ans, travaille encore sur son ancien référentiel articles, mappé « au mieux » vers celui du groupe.
12,9 M$ par an et par organisation : le coût moyen de la mauvaise qualité de données, dont l'incohérence entre sources en silos est le problème jugé le plus difficile à traiter (Gartner).
Ce chiffre est une moyenne toutes industries confondues. Dans un groupe multi-sites, où chaque décision d'investissement, d'allocation de capacité ou de make-or-buy repose sur des comparaisons inter-usines, la facture réelle est probablement supérieure et surtout invisible, diluée dans des décisions sous-optimales que personne ne rattache jamais à leur cause.
Ce que la recherche documente
| Constat | Chiffre | Source |
|---|---|---|
| Coût annuel moyen de la mauvaise qualité de données, par organisation | 12,9 M$ | Gartner |
| Problème de qualité de données jugé le plus difficile à traiter | L'incohérence entre sources en silos | Gartner |
| Part du chiffre d'affaires perdue à cause de données défaillantes | 15 à 25 % | MIT Sloan Management Review |
| Gain de productivité attendu d'une intégration bout-en-bout de la donnée | jusqu'à 26 % | McKinsey |
| Industriels bloqués en « pilot purgatory », incapables de passer à l'échelle du réseau d'usines | une large majorité | McKinsey |
| Escalade du coût d'une erreur non corrigée (règle 1-10-100) : saisie → propagée → décision | ×1 → ×10 → ×10 | Dataversity |
La cause racine : la fragmentation de la nomenclature
Pourquoi la BoM est-elle le point de bascule ? Parce qu'elle est la colonne vertébrale de quasiment tous les KPI industriels : taux de rebut, coût de revient, taux de service, TRS ramené à la valeur produite, impact matière d'une modification, tous sont calculés sur une structure produit. Si cette structure diverge entre sites, les indicateurs divergent mécaniquement, même avec des définitions de calcul parfaitement harmonisées.
Cette divergence n'est pas un accident. Elle est structurelle, et elle a trois origines.
C'est ce triptyque qui fait que vos KPI racontent des réalités incompatibles. Le tableau de bord n'est que le dernier maillon d'une chaîne dont chaque maillon amont introduit sa propre distorsion.
Pourquoi les réponses classiques échouent
Trois réponses reviennent systématiquement. Toutes trois ont une utilité réelle ; aucune ne résout le problème de fond.
- +L'harmonisation des ERP. Trois à sept ans, huit chiffres, un périmètre qui se restreint en cours de route. Et même unifié, un ERP ne supprime ni la dérivation eBOM/mBOM ni les spécificités de procédé locales : il déplace le problème.
- +L'entrepôt de données et la BI groupe. La consolidation s'opère par des mappings figés, écrits une fois par des équipes qui ne connaissent pas les subtilités métier de chaque site. Quand la nomenclature évolue, et elle évolue en permanence, les mappings deviennent faux. Le rapport continue de sortir ; il est simplement de moins en moins juste.
- +La gouvernance de données générique. Nommer des data owners, écrire un glossaire, déployer un catalogue : nécessaire, mais insuffisant si la gouvernance reste documentaire. Un glossaire ne réconcilie pas deux mBOM ; il constate leur divergence, au mieux.
McKinsey a documenté le phénomène à grande échelle : une large majorité d'industriels reste bloquée en pilot purgatory : des pilotes prometteurs qui ne passent jamais à l'échelle du réseau d'usines, faute de fondations data suffisantes. Le gisement de valeur, lui, se situe dans l'élimination des pertes d'information aux interfaces : entre fonctions, entre sites, entre entreprises. C'est exactement là que vivent les incohérences de KPI, et aucune des trois approches ne traite le sujet frontalement.
Le digital thread : traiter la continuité, pas les silos un par un
Le digital thread repose sur l'idée d'un fil numérique continu reliant la donnée produit de la conception à la production, au service et au retrait. L'idée n'est pas de remplacer les systèmes existants, ni d'imposer une nomenclature unique à des sites qui ont de bonnes raisons d'avoir des mBOM différentes. L'idée est de maintenir le lien : savoir à tout instant comment la mBOM de l'usine B dérive de l'eBOM de référence, quelles transformations ont été appliquées, et donc ce que recouvre exactement chaque chiffre calculé dessus.
La question change de nature. Au lieu de « pourquoi vos taux de rebut sont-ils différents ? » sans réponse propre, puisque les bases de calcul divergent, on peut demander : « sur le périmètre exactement commun aux deux sites, quel est l'écart de performance réel ? » La première question génère des réunions de justification. La seconde génère des décisions.
Mais le digital thread est un objectif, pas une technologie. La question qui suit immédiatement : avec quoi le construit-on, concrètement, par-dessus un existant PLM/ERP/MES hétérogène qu'il n'est pas question de remplacer ?
Le graphe de connaissance : l'infrastructure qui rend le fil numérique opérant
Un graphe de connaissance modélise explicitement ce que les architectures classiques laissent implicite : cet article de l'ERP de l'usine B est une instance de cette référence eBOM ; cette mBOM dérive de cette version d'eBOM via ces transformations ; ce taux de rebut est calculé sur ce périmètre de nomenclature. Les entités (articles, nomenclatures, sites, indicateurs, versions) et leurs relations (dérive de, remplace, est équivalent à, impacte) deviennent des objets de première classe, interrogeables. Sans déraciner les données de leurs systèmes sources.
- +La comparabilité devient calculable. Au lieu de décréter que deux KPI sont comparables et de le découvrir faux six mois plus tard, le graphe permet de le vérifier : les deux indicateurs reposent-ils sur des structures produit équivalentes ? Sinon, où divergent-elles, et l'écart est-il matériel ? La note de bas de page du contrôleur de gestion devient une requête.
- +L'analyse d'impact devient traversante. Une modification de conception tombe : quel impact réel, site par site ? Avec des nomenclatures silotées, la réponse mobilise des semaines d'analyse manuelle. Avec un graphe reliant eBOM, mBOM locales, stocks et en-cours, la propagation se parcourt en suivant les relations : quels articles, quelles gammes, quels ordres en cours, quels fournisseurs, dans quelles usines.
- +La couche sémantique prépare l'IA. Les projets d'IA générative et agentique en environnement industriel butent sur le même mur : l'absence de contexte fiable. Gartner positionne les couches sémantiques et les graphes comme l'infrastructure qui donne aux systèmes d'IA les définitions, les relations et les garde-fous nécessaires à des réponses fiables et explicables. Le même graphe qui réconcilie vos KPI aujourd'hui est le socle de vos futurs assistants industriels.
Ce que cela change pour votre métier
Reprenons la scène du lundi matin, un an après. La revue de performance ne commence plus par un débat sur les chiffres : les indicateurs consolidés portent chacun leur généalogie : périmètre de nomenclature, version, transformations appliquées. Quand deux sites divergent, la première question n'est plus « qui a raison ? » mais « l'écart est-il un écart de performance ou un écart de périmètre ? ». Et la réponse est disponible en séance, pas trois semaines plus tard.
Par où commencer
- +Choisissez un cas d'usage douloureux et mesurable. L'analyse d'impact d'une modification sur plusieurs sites est souvent le meilleur candidat : la douleur est connue de tous, le temps perdu est chiffrable, le résultat est vérifiable. Évitez de démarrer par « la gouvernance des données groupe » trop abstrait.
- +Ne cherchez pas l'exhaustivité du modèle. Un graphe vit et s'enrichit. Modélisez d'abord les entités et relations strictement nécessaires au cas d'usage choisi ; la tentation de l'ontologie parfaite avant tout déploiement est le meilleur moyen de rejoindre le pilot purgatory.
- +Traitez la réconciliation comme un processus continu, pas comme un projet. Vos nomenclatures divergeront à nouveau demain : c'est la vie normale d'un groupe industriel. La valeur du graphe n'est pas de figer une réconciliation à date, mais de rendre la divergence visible en permanence et son coût explicite.
Les KPI incompatibles ne sont pas un problème de reporting : ils sont le symptôme visible d'une donnée produit fragmentée. La bonne nouvelle, contrairement à ce que suggère le réflexe ERP : résoudre ce problème ne demande pas de tout reconstruire. Il demande de relier ce qui existe.
Sources citées
- Gartner, Data Quality: Why It Matters and How to Achieve It - coût moyen de la mauvaise qualité de données et incohérence inter-sources comme problème n°1.
- McKinsey & Company, Capturing the true value of Industry 4.0 - pertes d'information aux interfaces et « pilot purgatory ».
- Siemens, Steps for effective BOM management in the ETO change process - risques du désalignement eBOM/mBOM.
- Arena Solutions (PTC), BOM Reconciliation - enjeux de la réconciliation des nomenclatures.
- T. Redman, MIT Sloan Management Review - part du chiffre d'affaires perdue à cause de données défaillantes.