Digital Twins That Earn: Turn the Model Into a Control System in 90 Days

I have seen the same movie in industrial tech, connected devices, and enterprise software. A leadership team gets excited about a digital twin. A slick virtual replica appears. People discover “aha” moments. Then the twin quietly becomes a slide in a quarterly deck, because nothing in operations actually changed.

The problem is not the twin. The problem is the contract around it. If a twin is not allowed to change decisions, it will be reduced to theatre.

I am reacting to a recent case where a Danish company rebuilt processes virtually and leadership reported a string of revelations at SAS Innovate On Tour 2026. Revelations are cheap. Control is hard. Control is where margin, delivery reliability, and working capital move.

When I ran a smart-building and home-automation business unit with full P&L responsibility, we had connected sensors, cloud telemetry, and dashboards everywhere. The teams did not lack data. What we lacked at first was a disciplined link between data, decisions, and weekly execution. Later, when I ran operations across engineering, production, supply chain, and service in electrification and energy storage, the same lesson repeated: instrumentation only matters when it changes the operating system of the company.

Here is the operator playbook I use to turn a “digital twin” into a control system in 30, 60, and 90 days.

1) Define the twin by the decisions it will replace

Most twins start as a model of reality. Operators should start with a list of decisions that reality is currently failing.

I use a simple rule: if the twin does not change at least three recurring decisions inside 90 days, it is not a control system. It is an expensive diagram.

Pick decisions that are:

• Frequent: weekly or daily, not annual strategy.
• Costly when wrong: scrap, expedite fees, service overload, missed revenue, inventory bloat.
• Owned: a named decision-maker can say yes or no, and will be held to the result.

Examples that qualify:

• Which orders we promise this week, and which we delay.
• Which SKUs we build next, and what we freeze.
• Which field issues we pull forward into the next release, and what we defer.
• Which customers get scarce capacity, and at what price.

Examples that do not qualify: “improve collaboration”, “increase transparency”, “create shared understanding”. Those can be side effects, not success criteria.

2) Instrument the minimum viable truth, not the maximum possible data

A twin dies in two common ways. First, it tries to ingest everything. Second, it inherits every argument about data quality and never ships.

As a former Head of R&D rebuilding a cross-domain organization (embedded, cloud, electronics, mechanics, QA), I learned to treat data like an interface. You do not need perfection. You need a stable contract and explicit error handling.

Start with four truth layers, in this order:

1. Financial truth: price, cost, margin logic, warranty accrual rules. This must be deterministic and auditable.
2. Flow truth: lead times, WIP states, constraints, queue times, throughput.
3. Asset truth: machine availability, yield, changeover patterns, maintenance windows.
4. Demand truth: backlog, forecast, cancellations, customer priority rules.

The instrumentation you need in the first 30 days is often boring:

• Consistent order status transitions.
• A single definition of “ready”, “blocked”, “shipped”, “accepted”.
• Timestamped events for the main path, not every edge case.
• A mapping table that reconciles ERP item IDs with engineering BOM reality.

If you want a practical mental model, treat it like connected sensors in buildings. Sensors do not buy you uptime by themselves. Discipline does. That is why I care more about the data contract than the 3D rendering. If this topic resonates, my related piece Connected Sensors Don’t Buy You Uptime. Operating Discipline Does. covers the same failure mode from another angle.

3) The 30/60/90 plan: force the twin to earn its seat

You do not “roll out” a twin. You prosecute a sequence of decision replacements.

Days 0 to 30: pick one control loop and make it trustworthy

Goal: one weekly decision is made from the twin, not from gut feel and spreadsheets.

• Choose one loop: promise dates, production sequencing, service triage, or inventory replenishment.
• Define the output: a weekly recommended plan that a named owner must accept, modify, or reject.
• Publish an error budget: where the twin can be wrong, and what happens when it is.
• Stop debating fidelity: you are building a control system, not a flight simulator.

Deliverable at day 30: a single page “twin packet” used in the weekly ops meeting. Not a dashboard zoo.

Days 31 to 60: wire it into the meeting where money decisions happen

Goal: the twin becomes the agenda.

• Make variance the language: plan vs actual, and why. No status reporting.
• Turn exceptions into work: every red flag creates a ticket with an owner and due date.
• Add one commercial lever: pricing, allocation rules, or expedite fees, so operations and revenue are coupled.

This is also where you prevent the most common trap: letting the twin live in an innovation team. If the COO, operations lead, or business unit lead does not run the meeting from it, it will not survive.

Days 61 to 90: expand to three decisions and attach a P&L scoreboard

Goal: three recurring decisions are meaningfully different because the twin exists.

• Add the second loop: if you started with production sequencing, add promise dates, or service triage.
• Add the third loop: usually inventory policy or engineering change prioritization.
• Attach P&L mechanics: working capital, scrap, warranty, expedite costs, service cost per case, gross margin leakage.

Deliverable at day 90: a monthly QBR section where the twin is used to explain outcomes and commit to next-month changes. If QBRs are not your language, then pick the equivalent: whatever monthly ritual allocates resources and escalates tradeoffs. That is where the twin must live.

4) Hard-wire it into cadence: weekly ops and monthly QBR

A twin becomes a control system when it changes what people do every week. Not when it produces prettier answers.

I use a fixed cadence template.

Weekly ops (60 minutes) agenda

• 10 min: last week’s plan vs actual, top three variances only.
• 20 min: this week’s recommended plan from the twin, and explicit decisions.
• 20 min: constraints review, what we will not do, and who escalates what.
• 10 min: confirm owners, due dates, and the next instrumentation fix.

Rule: no one brings their own numbers. If the twin is wrong, you fix the data contract. You do not fork reality into ten spreadsheets.

Monthly QBR (or equivalent) agenda insert

• Three P&L lines the twin is supposed to influence.
• What decisions changed, with before and after policy statements.
• What failed, and what instrumentation will be added next month.

This is the same philosophy I apply when building SaaS ventures like Shopeno and IBHQ. Product decisions only matter when they are embedded into recurring behavior: onboarding, support, pricing enforcement, risk controls. If you like that framing, AI Leadership Is Workflow Leadership: Own the Handoffs makes the same point in a different domain.

5) Guardrails: keep the twin from becoming an expensive toy

I have three non-negotiables.

• One owner: a twin without an operator owner becomes a tech demo. Assign a single accountable leader for decision adoption.
• One version of truth for decisions: you can have multiple models, but only one place where decisions are recorded and tracked.
• A kill rule: if it does not replace decisions by day 90, stop and re-scope. Do not keep funding “insights”.

Also, keep narrative AI in the right layer. Use it to explain variances, draft action lists, and summarize tradeoffs. Do not let it touch the financial truth layer where determinism matters. I wrote that more explicitly here: LLMs Belong in the Narrative Layer, Not in the Financial Truth Layer.

My opinion: a twin is a management system, not a model

The most useful digital twin is not the most realistic. It is the one that is allowed to overrule humans in small, bounded ways, every week, with accountability when it is wrong.

If your twin does not show up in the weekly ops agenda, it is not real. If it does not show up in the monthly resource allocation conversation, it will never touch P&L. And if it cannot survive a day-90 “earn it or kill it” review, you did not build a control system. You built workshop theatre.

Pick one loop. Instrument the minimum viable truth. Replace one decision in 30 days. Replace three in 90. Then let the numbers, not the novelty, decide what happens next.