Executive summary: A digital twin is a live virtual model of your production system, fed by real data, that lets you find constraints and test changes before touching anything physical. Its highest-value use is detecting a constraint that moves with product mix, which conventional analysis cannot see. It is also the most commonly wasted investment in manufacturing, because plants buy simulation before they have done the basic mapping that would have found the obvious bottleneck for free.
- What is a digital twin in manufacturing?
- What can a twin see that mapping cannot?
- What are the three levels of digital twin maturity?
- Are you ready for a digital twin?
- What data does a twin actually need?
- How do you build one without wasting the investment?
- What are the most common digital twin mistakes?
- Digital twins: operator FAQ
- About the Stagnation Assassin
What is a digital twin in manufacturing?
A digital twin is a virtual model of your production system, connected to live data from equipment, execution systems, and inventory records, that mirrors what the physical plant is doing. It enables real-time constraint identification and lets you test scheduling and capacity changes in software before committing anything on the floor.
The distinction that matters is between a simulation and a twin. A simulation is a model you build, run, and interpret. A twin is a model that stays connected, continuously fed by what is actually happening, so it reflects current reality rather than the conditions that existed when someone built it. That connection is the whole difference, and it is also the part most vendors gloss over during the demo.
What you get from that connection is the ability to ask questions without consequences. What happens to throughput if we change the batch sequence? Where does the constraint move if we take that machine down for maintenance next Tuesday? What if this order gets expedited? Those questions normally get answered by trying it and finding out, which is expensive when the answer is bad.
I have led transformations at Berkshire Hathaway, Illinois Tool Works, and Whirlpool, and I want to be direct about my position on this technology before going further. Digital twins are genuinely powerful and they are the single most commonly misspent line item in manufacturing technology budgets. Both statements are true. The difference between the two outcomes is almost never the software. It is whether the plant did the unglamorous foundational work first.
What can a twin see that mapping cannot?
A constraint that migrates with product mix. Conventional mapping and OEE analysis produce a snapshot, so they identify where the constraint sits under the conditions you measured. A twin runs continuously across changing mix, which reveals that the limiting operation may shift between processes as the order book changes.
This is the use case that justifies the investment, and it is worth being precise about why. When you map a value stream, you measure over a period, usually a few days. Whatever mix ran during those days determines what you find. If your plant runs a genuinely varied order book, the constraint you identified may be the constraint for that mix and not for next month’s.
A metal forming operation I have written about elsewhere ran into exactly this. It needed to schedule four parallel lines across thousands of product configurations with special customer requirements, and conventional scheduling could not find batch sizes and sequences that both minimized changeovers and met delivery dates. The plant built a twin integrated with its manufacturing execution system, sensors, and inventory databases, and added a scheduling agent trained by reinforcement learning to generate optimal order sequences from real production constraints.
The scheduling gains were real. But the finding that mattered most was structural: the true constraint migrated between operations depending on product mix, and that migration had been invisible to conventional analysis. No single mapping exercise would ever have found it, because every mapping exercise measures one mix at a time.
A constraint that migrates with product mix is invisible to any single mapping exercise, because every mapping exercise measures one mix at a time. Plants in this situation spend years investing in whichever operation happened to be limiting during the week they measured, then wonder why throughput never responds.
What are the three levels of digital twin maturity?
Descriptive twins mirror current state and show where work is accumulating right now. Predictive twins simulate what happens under changed conditions. Prescriptive twins recommend or execute the optimal action, often using machine learning. Most plants need only the first level, and most buy the third.
Level 1: descriptive, a live mirror
The model reflects current state from live data. You can see where work in process is accumulating and which operation is currently limiting flow, in real time rather than at the weekly production meeting. This alone changes behavior, because it lets non-constraints adjust before the constraint starves rather than after.
Level 2: predictive, a what-if engine
The model runs forward under conditions you specify. What happens if we take heat treat down Tuesday? What if this order jumps the queue? What if demand rises 20 percent? You test consequences in software rather than discovering them on the floor, which is where the capital avoidance case usually lives.
Level 3: prescriptive, an optimizer
The model recommends or directly sets the optimal action, typically scheduling sequences and batch sizes, often driven by machine learning trained on real production constraints. This is where the metal forming case operated, and it found sequences human planners had missed for years. It is also the level with the highest failure rate, because it demands data quality most plants do not have.
The honest guidance is to earn your way up this ladder. A descriptive twin delivering real-time constraint visibility is a genuine operational upgrade and is achievable in most plants with reasonable instrumentation. Jumping straight to prescriptive optimization on top of unreliable data produces confident recommendations built on garbage, which is considerably worse than no recommendations at all.
Are you ready for a digital twin?
You are ready when you have already found and exploited your obvious constraint, your process data is measured rather than estimated, and your remaining question is genuinely one that requires simulation. If your constraint is visible to anyone who walks the floor, a twin will confirm what you already knew at considerable expense.
Here is the readiness test I apply, and it has saved clients more money than any technology I have recommended.
- Have you mapped the value stream and identified a constraint? If not, do that first. It takes three to five days and costs almost nothing.
- Have you fully exploited that constraint? Changeover reduction, downtime elimination, subordination of upstream processes. If the constraint still sits idle during production, a twin will just model your idle constraint in higher resolution.
- Is your process data measured or estimated? If cycle times come from the ERP standard rather than a stopwatch, your twin will faithfully simulate a plant that does not exist.
- Does your constraint actually move? If you run a stable product mix and the same operation limits you every month, the migration use case does not apply and the investment case weakens sharply.
- Can you act on what it tells you? Real-time constraint visibility only helps if someone is empowered to adjust upstream production in response.
I have watched companies spend millions on simulation software while ignoring a bottleneck their own operators named accurately in the first five minutes of conversation. The technology was not the problem. The sequencing was. Technology amplifies intelligence. It does not substitute for it, and a sophisticated model pointed at an unexamined plant produces expensive precision about the wrong things.
What data does a twin actually need?
Four feeds at minimum: equipment state and cycle times from sensors or machine controls, order and routing data from the execution system, inventory positions including work in process, and quality or rework rates. The model is only as accurate as these feeds, which is why data quality determines success far more than software selection.
Each feed has a characteristic failure mode worth anticipating.
Equipment state and cycle times. Needs to come from actual machine signals or measured observation, not from routing standards. I have seen ERP standards off by 60 percent against stopwatch reality. Feed that into a twin and every downstream conclusion inherits the error, delivered with the false confidence that a sophisticated model provides.
Order and routing data. Must reflect what actually gets made, including the rework loops and unofficial routings that never made it into the system. The official process shows material flowing cleanly from A to B to C. The real process includes inspection, rework, and a staging area nobody documented.
Inventory positions. Physical counts, not system counts. If the system believes you hold 500 units and the floor holds 847, the twin will model queue behavior that does not match reality, and queue behavior is precisely what reveals constraints.
Quality and rework rates. Defects consume constraint capacity invisibly. A twin blind to rework will overstate available capacity at exactly the operation where capacity matters most.
Notice that three of those four failure modes are the same failure: trusting the database over the floor. That is the foundational discipline, and it is why plants that have already done rigorous loss measurement build successful twins and plants that have not, do not.
How do you build one without wasting the investment?
Scope narrowly, validate against known reality, and expand only after the model has proven it can reproduce outcomes you already understand. Start with one value stream, one line, or one cell. A twin of the entire plant built before any twin has been validated is the fastest route to an expensive model nobody trusts.
Step 1: pick one value stream
Choose the flow where the constraint question is genuinely unresolved, ideally one with real product mix variation, since that is where a twin earns its keep. Resist modeling the whole plant. Scope discipline here is what keeps the project finishable.
Step 2: instrument and verify the data
Establish the four feeds and verify each against physical observation. Stopwatch a sample of cycle times and compare to what the feed reports. Count inventory physically and compare to system positions. Fix the gaps before modeling, because every gap becomes a modeling error you will not detect later.
Step 3: build and back-test
Model the flow, then run it against a historical period you already understand. Does the twin reproduce the throughput, queue positions, and constraint location you actually observed? If it cannot reproduce the past, it has no business predicting the future. This validation step gets skipped constantly and it is the one that determines whether anyone trusts the output.
Step 4: run the questions that justified the build
Test the scenarios you built it for. Where does the constraint sit across your real mix range? What does a maintenance window on that asset cost? Which sequencing rule maximizes throughput? Answer the original questions before adding capability.
Step 5: expand deliberately
Extend scope or maturity level only after the first twin has produced a decision you acted on and a result you measured. That evidence is what protects the budget and what tells you whether level two or three is warranted.
If a model cannot reproduce a historical period you already understand, it has no business predicting anything. Back-testing against known throughput, queue positions, and constraint location is the validation step teams skip most often, and it is the one that determines whether the plant ever trusts the output.
What are the most common digital twin mistakes?
Four recur: buying simulation before doing basic mapping, feeding the model ERP estimates instead of measured reality, modeling the entire plant before validating any of it, and treating the twin as a replacement for judgment rather than an amplifier of it.
Mistake 1: buying it instead of looking
The most expensive mistake in the category. A plant with an obvious, visible constraint commissions a simulation project instead of spending a week measuring. Months later the model confirms what the operators said at the start. Do the mapping first. If it answers the question, you just saved the entire investment.
Mistake 2: garbage inputs, confident outputs
ERP standards, quoted lead times, and system inventory counts feel authoritative and are routinely wrong by wide margins. A twin built on them produces precise, well-visualized conclusions about a plant that does not exist. Verify every feed against physical observation before modeling.
Mistake 3: boiling the ocean
Teams attempt a whole-plant twin as the first build. Scope expands, validation never happens, the timeline stretches past leadership patience, and the project dies with nothing shipped. One value stream, validated, beats a plant-wide model that never gets trusted.
Mistake 4: outsourcing the thinking
The model recommends a sequence and nobody asks whether it makes sense. Prescriptive systems trained on incomplete constraint data will confidently optimize toward the wrong objective. Keep an experienced operator in the loop who can say that a recommendation is impossible, and treat that objection as information about the model rather than resistance to it.
My own error with this technology was enthusiasm about sequencing. I once pushed a plant toward a predictive twin when what it needed was two weeks of honest measurement and a changeover reduction on an operation everyone had already identified. The twin would have been useful eventually. It was not what was in the way, and pursuing it delayed the fix that actually mattered by a quarter. Digital capability is worth building. Build it after the fundamentals, not instead of them.
Digital twins: operator FAQ
What is a digital twin in manufacturing?
A virtual model of a production system connected to live data from equipment, execution systems, and inventory records, so it mirrors what the plant is actually doing. It enables real-time constraint identification and lets you test scheduling, capacity, and maintenance decisions in software before committing them on the floor.
How does a digital twin identify bottlenecks?
It runs continuously against live data rather than producing a snapshot, so it shows where work accumulates in real time and across changing conditions. Its distinctive capability is detecting a constraint that migrates between operations as product mix changes, which single-period mapping exercises cannot see.
When is a digital twin not worth building?
When your constraint is already obvious, when you have not yet fully exploited it, when your process data comes from ERP standards rather than measurement, or when your product mix is stable enough that the same operation limits you every month. In those cases mapping and exploitation deliver more for far less.
What data does a digital twin need?
Equipment state and measured cycle times, order and routing data reflecting real flow including rework loops, physical inventory positions rather than system counts, and quality and rework rates. Accuracy of these feeds determines model quality far more than software choice, so verify each against physical observation before modeling.
About the Stagnation Assassin
Todd Hagopian is a Fortune 500 transformation executive who has generated $3B+ in shareholder value across Berkshire Hathaway, Illinois Tool Works, Whirlpool, and JBT Marel, where he serves as VP of Global Product Strategy. Known as The Stagnation Assassin, he is the author of two published books: The Unfair Advantage: Weaponizing the Hypomanic Toolbox and Stagnation Assassin: The Anti-Consultant Manifesto. His blog is published in 15+ languages and read by operators worldwide. Bring him to your stage via the speaking page or connect with him on LinkedIn.
Next step: a readiness check
Before you spend six figures on simulation, find out whether you need it. Book a 20 minute readiness check and I will help you determine whether your constraint is already visible, whether your data would survive contact with a model, and whether your constraint is one that actually moves. Start the check here.