“Digital twin” is overused, so it gets misunderstood
When someone tells me “we want a digital twin,” I don’t automatically get excited. I get cautious.
Because I’ve seen two very different things called the same name:
- a pretty 3D that looks great in slides and changes nothing
a living model that exposes bottlenecks, risk, and drift before they turn into urgency.
I only call the second one a digital twin.
## What a digital twin is (in the way that matters)
To me, a digital twin is an operational mirror with three properties:
-
it represents the real system as structure (states, constraints, dependencies)
-
it is fed by real data on a defined cadence
it returns decision value, not just visuals: it shows where risk is accumulating and what condition is missing to move.
If it doesn’t do all three, it’s a mock-up.
## The “diorama twin” trap
The diorama twin is common:
-
3D plant layout
-
colors
-
animations
and then you ask, “what decision will change tomorrow?” and nobody knows.
That happens because teams build a mirror without truth. Without truth, the mirror returns aesthetics.
## The real payoff: seeing the near future
A well-scoped twin doesn’t give you a nicer picture of today. It gives you an edge:
it helps you see the near future of your operation.
Not sci-fi. Practical things:
-
which queue will grow if you accept a change
-
which project looks fine but is actually incomplete
-
which constraint will break your week unless you act now
where rework is quietly consuming capacity.
That’s what I care about: early detection.
## Three twin types (and the mistake of trying to do all at once)
I always ask: a twin of what?
Product twin: as-designed vs as-built, configurations, variants.
Process twin: real flow, states, queues, exit conditions.
Asset twin: machines, availability, micro-stops, maintenance signals.
The common mistake is doing everything in one leap. I prefer something tougher and more profitable:
a small twin that decides before a large twin that only displays.
## Where twins become relevant in project-driven operations
The pain is rarely “manufacturing.” It’s coordination: variability, dependencies, time windows, changes, and completeness.
So the twin often delivers in four fronts:
-
invisible bottlenecks (moving, mix-driven, rework-driven)
-
incompleteness (“almost ready” is dangerous)
-
change that sneaks in without cost
plans that ignore real constraints.
## My quick test: do you have operational states—or just opinions?
Before we talk twins, I look for a minimum condition: clear states.
If the language is “in progress,” “almost,” “about to ship,” with no shared criteria, you don’t need a twin first—you need operational language.
A twin doesn’t invent truth. It amplifies it.
## Signals a twin can pay back
daily replanning is normal and still late
friction (rework/urgency/extra visits) is the real cost
project status lives in conversations
partial shipments are more common than admitted
quality is discovered late and eats capacity silently
customer changes don’t translate into new promise/cost
nobody fully trusts dates, but they’re promised anyway
bottlenecks move and keep surprising you
remove one key person and visibility collapses
## Signals you’re heading toward a diorama
“we want a 3D factory view”
“we want it to look modern”
“we want big screens”
Not illegitimate, but those goals are reputational, not operational. I prefer measurable return.
## The question that decides success: which decision must improve?
I don’t accept “build a twin” without a target decision. Without a decision, it becomes expensive entertainment.
Examples of decision targets:
“is this project promisable with evidence?”
“what should go first to protect the installation window?”
“which missing component will break complete shipping?”
“what cause is creating repeated rework and fake capacity?”
## How I assess maturity without giving the full implementation
I look at:
-
identity (can you track a project without reinterpretation?)
-
truth (shared definitions of “complete/ready/approved”)
-
cadence (does reality update when it matters?)
-
ownership (who owns the model?)
risk limits (what decides vs what suggests vs what requires validation?)
## Vendor questions I use to detect substance
what sources feed the twin and how often?
what happens with missing/contradictory data?
how are constraints represented (capacity/queues/quality/missing)?
what part is simulation vs measured reality?
how does it prove it predicts better than spreadsheets + experience?
what is auditable for decisions?
## Closing
A good twin is uncomfortable: it exposes incompleteness, hidden cost, moving bottlenecks, and evidence-free promises.
That discomfort is exactly why it works.
If you want, we can review it in 15 minutes: whether your pain matches a twin (and which kind), where return is likely, and the minimum conditions to avoid building a diorama.
Diagnóstico express
