Digital Twins in Manufacturing: What It Takes to Move Beyond the Pilot

Synopsis

Manufacturers have adopted digital twins widely, and most of that work is still sitting in pilots. The technology tends not to be the reason. What separates a twin that reaches the factory floor from one that stays in a demonstration is usually the state of the data feeding it and the readiness of the plant to act on what it says. This article looks at why that gap persists and what tends to close it.

Manufacturers have been modeling things before building them for a very long time. Drawings became CAD, CAD became simulation, and by the 1990s an engineer could test how a part would behave under load without cutting any metal.

What changed more recently is that the model stopped being a snapshot. Once sensors became cheap enough to attach to almost anything, a model could be fed what the real machine was doing — temperature, vibration, cycle time, and output quality — and kept current. The design tool became a live one.

That is what a digital twin is. A working model of a physical thing, kept up to date by data from the thing itself.

Manufacturers have taken the idea seriously. In a survey of manufacturing leaders, 86% said a digital twin applied to their organization, and 44% had already implemented one.

Rather, fewer have one working across a whole plant.

Why a pilot works, and production often doesn’t

A pilot succeeds partly because it is a pilot. It usually covers one line or one machine in a corner of the plant where the data happens to be reasonably good, with an engineer nearby who can tell when the model is behaving oddly. Under those conditions, the twin performs, the demonstration goes well, and the business case looks straightforward.

Scaling it means asking the same model to work where none of those conditions hold.

Older equipment on the floor may have no sensors at all or sensors that report in formats nothing else recognizes. Maintenance records may live in one system, production data in another, and quality results in a spreadsheet somebody maintains by hand. The twin that behaved so well on one line now has to be right about a plant where the information arrives incomplete, late, or in disagreement with itself.

This is the barrier the research keeps returning to. McKinsey’s survey of manufacturing executives found that among the obstacles to adoption are fragmented and arcane data landscapes that inhibit high-impact, scalable solutions, alongside a shortage of in-house people able to build and deploy a twin.

What it costs to leave a twin in the pilot stage

The most common outcome is not failure. It is a pilot that quietly becomes permanent.

The model keeps running on its one line, the team that built it moves on, and the investment produces a capability nobody else in the plant can use. Meanwhile, the problems the twin was meant to address – unplanned downtime, scrap, and changeover time – carry on being managed the way they always were.

There is a wider cost as well. A speaker at the Automate conference this summer put it bluntly: the industry’s preference for small, safe, reversible pilots is the single biggest thing holding manufacturing back, leaving it roughly two decades behind the technology sector. The habit that feels prudent at each decision adds up to something considerably less prudent across a decade.

There is a further constraint that tends to surface only at this stage. McKinsey’s assessment of what an organization needs before implementing a twin comes down to digital maturity, meaning a high-quality data infrastructure delivering reliable data from both testing and live environments, and the talent to build and maintain it. A pilot can borrow that readiness from a small, well-instrumented corner of the plant. A production deployment has to actually have it.

What tends to close the gap

None of this argues against starting small. It argues for starting small with the next step already in view. A few things tend to separate the twins that travel from the ones that stay put.

Decide what the twin is for before deciding what it models. A twin built to reduce unplanned stoppages needs different data, at a different frequency, than one built to shorten changeovers. Programs that begin with the modeling question rather than the operational one usually end up with something impressive that nobody uses.

Begin where the data already exists. The line with reasonable sensor coverage and a maintenance history worth trusting is a better starting point than the line with the biggest problem, because it lets the first version prove itself without a retrofit budget attached.

Get the plant and the data teams working together from the start. The people who understand the physical process and the people who manage the data infrastructure tend to sit in different parts of the organization, and a twin needs both to be right. McKinsey’s guidance is blunter than most on this point, describing a successful digital twin program as a change management effort rather than only a technical one.

Keep checking the model against reality. A twin drifts. Equipment wears, materials change, and a model that matched the machine in March may quietly stop matching it by September. The recommended way through this is an iterative approach based on continuous testing, validation, and refinement, which improves accuracy before deployment and is what keeps a twin trusted a year later.

Know who acts on the output and what authority they have. A twin that predicts a bearing failure is only useful if someone is expected to do something about it, with the budget and the scheduling latitude to intervene.

Where we tend to be useful

At Infocusp, we work at both ends of this problem. We build the machine learning and signal processing models that make sense of continuous sensor data, and we build the pipelines, integrations, and cloud infrastructure that get that data into a state a model can rely on.

For manufacturers, the second half is usually where a program either holds or stalls. Getting information off older equipment and into a usable form, reconciling records that disagree with one another, and testing whether a model still behaves once it meets a full production environment rather than a controlled sample.

Building a model that works is the solvable part. What decides whether anyone still trusts it a year later is everything around it – the quality of what feeds it and whether it is still being checked against the machine it claims to represent.

Explore with our experts

Where the advantage moves next

Digital twins are becoming easier to build. Simulation tools have improved, costs have come down, and the modeling work that once required a specialist team is increasingly within reach of a plant engineering group.

That makes the modeling less of a differentiator, not more. As building a twin gets easier, the advantage shifts to organizations that can supply it with trustworthy information and act on what it tells them.

Which is a more useful question for most manufacturers than whether to adopt the technology. The technology is largely settled. What remains is whether the surrounding plant is ready to use what it produces.

If you are working through a digital twin program and would value a conversation about the data and integration work underneath it, our manufacturing team would be glad to talk.

Share your challenge with us