Digital Twins Need a Business Decision

A digital twin is useful when it improves a defined operating decision. The label alone does not create value. A twin needs a real asset or process, current data, a model that fits the question, and an owner who can act on the result.

This guide shows how to move from a visual demonstration to a digital twin that supports maintenance, planning, quality, or energy decisions.

Start with the decision

Begin with the decision the organisation wants to make more reliably. It may be when to inspect equipment, how to schedule capacity, or how to test a process change.

A 3D view can be attractive without changing a decision. Write the decision, its current evidence, its cost of delay, and the person accountable for acting.

Name one decision.
Define the current workflow.
Set a measurable outcome.

Define the twin boundary

A twin may represent one machine, a production line, a building, a fleet, or a wider system. The boundary determines which sensors, records, models, and integrations are needed.

Start with the smallest boundary that can answer the question. A broad model with weak data is harder to operate than a narrow model with trusted inputs.

Name the asset or process.
List dependencies.
Document what is out of scope.

Separate data from the model

Sensor readings, maintenance records, control signals, schedules, and environmental data are inputs. The model turns those inputs into an estimate, forecast, or scenario. Keep the two layers visible.

A data feed can be current while the model is wrong for the decision. Validate freshness, quality, assumptions, and uncertainty separately.

Record source and timestamp.
Track missing data.
Document model assumptions.

Choose the right fidelity

More detail is not automatically better. Use the simplest model that can support the decision and explain its result to the people who use it.

High-fidelity simulation may be justified for design or safety work. A lower-complexity operational model may be better for a daily planning decision.

Match fidelity to risk.
Measure model error.
Review assumptions after changes.

Connect the twin to action

The twin must connect to a workflow. If a forecast identifies a risk, the system should create a review, recommend an action, or support a scheduled intervention.

Do not leave insight in a dashboard. Define the handoff, approval, escalation, and system of record.

Name the action owner.
Record decisions and overrides.
Measure time to action.

Govern access and trust

Operational data can expose production, facilities, customer, or safety information. Apply access controls, audit changes, protect interfaces, and define who can alter the model or data source.

Trust also depends on explainability. Users should see the evidence and limits behind a recommendation.

Separate view and edit rights.
Log model changes.
Show confidence and limitations.

Measure value after launch

Track whether the twin improves the original decision. Useful measures include downtime avoided, planning variance, inspection quality, energy use, rework, response time, and user adoption in the target workflow.

Do not use dashboard visits as the main proof. Activity is not the same as an improved outcome.

Set a baseline.
Compare like with like.
Review exceptions and false alarms.

What does not matter as much

The most photorealistic interface, the largest data lake, or the longest feature list does not prove value. A smaller model embedded in a real operating process may be more useful.

Use the visual layer when it helps the user understand the system. Keep the business decision at the centre.

Do not begin with a demo.
Do not hide uncertainty.
Do not scale before evidence.

Comparison table

Area	Practical question	Evidence to request
Scope	What does the twin represent?	Boundary, dependencies, exclusions
Model	Does it fit the decision?	Assumptions, error, uncertainty
Workflow	Who acts on insight?	Handoff, approval, record
Value	Did the decision improve?	Baseline, outcome, exceptions

FAQ

Is every 3D model a digital twin?

No. A twin needs a connection to a real asset or process and a purpose for using current data, models, or simulations to support decisions.

What is the best first digital twin project?

Choose one repeated decision with measurable cost or risk, accessible data, and a named owner. Start narrow.

Does a digital twin need real-time data?

Not always. The required freshness depends on the decision. Maintenance planning may use periodic data while control work may need much faster signals.

How should digital twin value be measured?

Compare the target decision with a baseline. Measure operational outcomes such as downtime, variance, quality, energy, or response time rather than screen usage alone.

Conclusion

The useful decision is the one that can be tested. Use the framework above to define the problem, identify the evidence, assign ownership, and review the result after launch. Clear scope beats a large claim, and a measured workflow beats a polished demo.

Product Analytics Needs a Decision, Not More Events

FinOps Starts with Useful Cost Ownership