Key takeaways
See our roundup of analytics tools, for what to build instead.
The digital twin pitch is appealing. A real-time simulation of the physical plant, updated by sensor streams, queryable for what-if analyses. The vendor demonstrates a rotating 3D model of a packaging line, asset states colour-coded, throughput projecting forward. The plant manager sees the version of the plant they wish they had visibility into.
The reality, 18 months later: the 3D model is in the corner of the office, mostly unopened. The sensor coverage required to keep it accurate turned out to be far more than the original estimate. The engineer who built it has rotated to another project.
Half the model is stale because the plant rearranged Line 3 last quarter and the twin was not updated. The plant got much of what it actually needed, visibility into asset state, downtime causes and PM status, but at a large multiple of the cost of a properly-scoped operational data platform.
This is not an indictment of digital twins as a concept. They work in the right contexts, large continuous-process plants with dedicated reliability engineering teams, capital-intensive industries where modelling pays back through avoided downtime. For mid-market discrete and batch manufacturing, the math rarely works.
A useful twin needs more sensor data than most mid-market plants collect. Vibration, current, temperature, position, per asset, in real time, with calibration that holds. The instrumentation cost is usually the first place projects exceed budget, often by a wide margin.
The twin is a model. Models drift. New equipment arrives, the plant rearranges, processes change. Without a dedicated engineer continually updating the model, accuracy decays to "decorative" within a year. Mid-market plants almost never staff this role and almost never replace the original implementation engineer when they leave.
This is the input most often skipped at scoping. The twin earns its keep when running scenarios on it is meaningfully cheaper than running them in the real plant, what-if changeover sequences, alternative routing, maintenance scheduling experiments. If the plant's actual decision cadence does not need that capability, the simulation is a beautiful answer to a question nobody is asking.
Most of the digital twin's practical value, at a fraction of the cost, comes from an operational data platform. Not a simulation. Just one place where the asset hierarchy, the OEE event stream, the work orders, the preventive schedule and the quality data live together.
This is unromantic. It is also what plants need. The question "where is asset L3-PKG-02 in its PM cycle, and what was its last unplanned event" gets answered in 5 seconds rather than 20 minutes of cross-system lookup.
The question "which assets contributed the most production-minute loss last month" becomes a query instead of a quarterly project. The piece on manufacturing KPIs covers the underlying metrics this kind of platform unlocks.
What the operational platform delivers that the twin pitch promised:
What the platform does not deliver that the twin promised:
For most mid-market plants, the items in the second list are not the binding constraint on improvement. The items in the first list are.
Before any digital twin proposal lands in front of a plant manager, two questions:
Most plants that run this check honestly end up scoping the operational platform first and revisiting the twin in year three or four. By year three, the plant has the data foundation that would make a twin actually useful, and usually finds that the twin's incremental value has shrunk because the platform already covers most of what the team wanted.
The framing above is "most mid-market plants do not need a twin." It is not "no plant should consider a twin." Twins work in:
If the plant fits one of these patterns, the twin can be the right investment. The article on root cause analysis covers the more universal investment, building the data foundation that makes any advanced modelling possible later.
Fabrico is the operational data platform, not the digital twin. It does the asset hierarchy, OEE event stream, work orders, PMs and quality data on one foundation, accessible from the floor and from leadership.
Most plants that come asking about digital twins discover, after a 30-minute conversation, that what they actually need is the platform. The connection to the work order management system and the preventive maintenance schedule matters because those are the workflows that produce most of the daily value.
To see what the platform delivers against your current data fragmentation, book a demo .
No. They are an excellent idea for the small set of plants whose use case justifies them. The point is that the use case has to be specific and demonstrable, not aspirational. Most mid-market plants do not have it.
Run the two scoping questions above and report the results. If the questions produce vague answers, the twin will produce vague value. A defensible "let's build the data foundation first" recommendation usually lands well when accompanied by a roadmap that revisits the twin in year three.
For a mid-market plant, 8-16 weeks for the first three lines and core asset classes. Compare to 12-18 months for a full digital twin with credible model fidelity.
Yes. Once the operational platform has 12+ months of normalised data, statistical pattern recognition (sometimes called "lightweight twins") becomes possible at much lower cost. This is usually the right sequence rather than starting with the heavyweight twin.
Letting the twin's visualisation drive the scoping. The 3D model is what looks impressive in the demo. The data foundation is what produces the value. Plants that commission based on the visualisation end up with the visualisation and not the value.
Login
Blog
