The digital twin is presented as the holy grail of Industry 4.0. Yet most digital twin projects disappoint, not for lack of technology but for lack of reliable product data. At the heart of the problem: a Bill of Materials fragmented across PLM, ERP, MES and Excel files.
Digital twin: a quick refresher
No need to re-explain the digital twin: a virtual replica of a product, process or system, synchronized with its physical counterpart throughout its life cycle. The concept, formalized in 2002 by Michael Grieves in a PLM context and named by NASA's John Vickers, is now a mass market: about $24.5 billion in 2025, with nearly $385 billion projected by 2034 (Fortune Business Insights).
The promises are well known: predictive maintenance (about 31% of the market), virtual validation, instant access to as-built and as-maintained configurations, a feedback loop from the field to engineering, aftersales support. What deserves attention is less this list of use cases than their common denominator: all of them assume you know with certainty the exact composition of the physical product.
The value of a digital twin lies neither in the simulation engine nor the visualization layer, but in the product structure data that feeds it: the BoM.
The BoM, backbone of the digital twin
The bill of materials is the structured, hierarchical list of every component, sub-assembly and material that makes up a product. It's the informational skeleton onto which all other data attaches: CAD geometry, requirements, manufacturing data, maintenance history, sensor data.
But talking about "the" BoM in the singular is already a misleading simplification. In industrial reality, the same product is described by several nomenclatures, each carried by a different system and function.
A twin worthy of the name needs to navigate between these views and reconcile them: start from a sensor alert on a component in service, trace it back to its reference in the sBOM, identify the corresponding engineering definition in the eBOM, find the manufacturing batch in the mBOM. This is called digital continuity, the digital thread. And it's exactly where things break down.
Product data split across four worlds
Ask any industrial director, PLM manager or methods manager: product data fragmentation is the everyday problem of every industrial company, whatever its size.
Each of these systems was designed for one function, with its own data model, granularity and life cycle. None was designed to offer a unified view of the product.
The symptoms every manufacturer will recognize
The same component exists under three different references depending on the system. The mBOM has drifted from the eBOM through successive changes, without anyone knowing exactly where. The real configuration of a unit delivered five years ago can only be rebuilt by manually cross-referencing the ERP, production reports and the memory of a shop-floor veteran. An impact analysis like "which delivered products contain this faulty component?" ties up three people for two weeks.
Engineers spend around a third of their time on non-value-added tasks, including 20% spent working on outdated information, with all the rework and delays that entails (Tech-Clarity).
The McKinsey Global Institute already estimated back in 2012 that knowledge workers spend nearly 20% of their time, one day a week, searching for and gathering information. This is the diffuse, rarely measured cost that fragmented nomenclatures impose on the whole organization.
Why a digital twin without a reliable BoM is blind
A twin that doesn't reflect reality
Fed by the PLM's eBOM, the twin represents the product as designed, not as manufactured, let alone as it exists today after ten years of maintenance and retrofits. The gap between the virtual model and physical reality is called configuration drift, and it progressively makes the twin unusable. A twin displaying a component no longer fitted to the real machine isn't much better than an outdated drawing.
Predictive maintenance predicting on sand
The algorithm cross-references sensor data with component characteristics: theoretical lifespan, tolerance thresholds, failure history of the reference. If the as-maintained BoM is wrong, because a part substitution during an intervention was never recorded, the algorithm reasons about the wrong component. Predictions become noise at best, dangerous recommendations at worst.
Impossible impact analyses
"If this supplier fails, which products are affected?", "Which delivered serial numbers does this non-conformity concern?", "What's the carbon footprint of this variant?" These questions require crossing the nomenclatures, from the supplier item in the ERP to the units in service. If the links between eBOM, mBOM and sBOM don't exist, or only in hand-maintained spreadsheets, the twin can't answer: it sees each silo, not the connections between them.
A return on investment that evaporates
According to industry analyses, up to 70% of digital twin projects run into major difficulties, with data quality, integration complexity and governance gaps cited as the top obstacles (Informatica). The finding goes beyond the digital twin alone: Gartner predicts that 60% of AI projects not built on "AI-ready" data will be abandoned by 2026.
A digital twin without BoM continuity isn't a twin: it's a portrait, frozen at the moment of design.
Three sector illustrations
Three sectors, one verdict: the value of the digital twin is capped by the quality of the weakest link in the nomenclature chain.
Connecting the BoMs: the knowledge-graph approach
The historical temptation is the grand migration project: centralize everything in a single PLM, or push everything down into the ERP. These sweeping programs fail, because they assume you can impose a single data model on functions whose needs are structurally different. The eBOM and mBOM never diverge "by mistake": they diverge by nature, because they describe different realities.
A more pragmatic approach is gaining ground: connect the nomenclatures where they live, rather than moving them. A knowledge graph represents data as nodes (items, components, serial numbers, documents, requirements, suppliers) and relationships (is composed of, replaces, is manufactured according to, is fitted on). Unlike a classic relational database, it's natively designed to model and traverse hierarchical structures and cross-cutting links, exactly the nature of a BoM.
Coupled with an ontology, the semantic model that formally defines business concepts and their relationships, the graph reconciles heterogeneous repositories without standardizing them: the PLM reference, the ERP item code and the MES designation of the same component become three attributes of a single node, linked to their respective contexts.
- +A unified product view without migration. The graph overlays existing systems and federates them, instead of replacing them.
- +Instant BoM traversals. Tracing a serial number back to its original eBOM, or from a component down to every delivered unit that contains it, becomes a query taking seconds.
- +Auditable digital continuity. Every link between the eBOM, mBOM and sBOM views is explicit, versioned and traceable, a prerequisite in regulated industries.
- +A foundation ready for AI. Graph-RAG approaches let you query product data in natural language with reliable relational context, where an LLM plugged into unstructured documents hallucinates for lack of knowing the product's real structure.
Where to start
No need to aim straight for the complete twin of the whole range. Successful initiatives start from a painful, measurable use case: reconciling eBOM and mBOM on a product line, rebuilding as-built configurations for a fleet, automating supplier impact analyses. The graph is built incrementally, use case after use case, and each step delivers value without waiting for the end of the program.
As long as nomenclatures stay fragmented across PLM, ERP, MES and Excel, the digital twin remains blind: it simulates a product that doesn't quite exist, predicts failures on components no longer fitted, and fails to answer the cross-cutting questions that justified its existence. Before investing in the next twin, ask yourself the only question that matters: is your BoM ready to open its eyes?
Sources
- Grieves, M. (2016), Origins of the Digital Twin Concept, Florida Institute of Technology.
- Fortune Business Insights (2026), Digital Twin Market Size, Share & Growth Report 2026-2034.
- Informatica, Digital Twins Explained: Data Foundation Guide.
- Gartner (2024), survey on AI data readiness.
- Tech-Clarity, Reducing Non-Value Added Work in Engineering.
- McKinsey Global Institute (2012), The Social Economy: Unlocking Value and Productivity Through Social Technologies.