How to Turn a Digital Twin Into a Repeatable Decision Process

Keep a scenario library

A scenario library is a short, named list of model runs that every new decision reuses. After two or three projects, it should contain:

• a base case: the plant as it runs today, with the normal order mix
• a peak case with the highest demand and the hardest mix you plan for
• disruptions such as a breakdown at the bottleneck, a late supplier or an absent crew on one shift
• ramp-up: the first weeks of a new line or product, with lower output and more stops
• rejected options, kept with the reason they lost so they do not return under a new name

Each scenario gets a name, a date, an owner and one sentence on which question it answers. New studies copy a dated base case instead of changing the old one. An approval can then cite "Base case, March, with breakdown scenario" instead of a vague "the simulation".

Keep an assumption register

An assumption register is one shared list of the inputs every scenario uses. It ends the meeting where finance quotes one number, operations another and engineering a third. The rows below are illustrative.

Three columns do most of the work. Evidence says whether a value was measured, taken from a supplier or only estimated. Owner names the person who answers when it is wrong, and Used in lists the scenarios to rerun when a row changes. Estimated rows need a date by which someone verifies them. Ranges also suit the model, whose stochastic simulation varies each input within its spread.

Use one way to compare and present options

Repeatability needs the same rules for every decision. All options face the same scenarios from the library, and results always appear on the same measures: output, flow time, waiting, utilization of stations and vehicles. The decision page names the winning option, its weak spot, and the condition that would reopen the decision.

When the rules stay the same, a board can compare this year's investment with last year's. We describe the comparison step in detail in How to Compare CAPEX Options When Every Scenario Looks Plausible.

Review each investment against the model

A post-investment review usually checks budget and schedule. It rarely checks whether the line works the way the approved scenario said. The digital twin can close that gap.

Use the model in the review when the approval referred to named scenarios, and the line's output or transport load now differs from what was expected. Update the model with the layout as built, the real shifts and the actual cycle times. Then rerun the approved scenarios and compare. You learn whether the plan was wrong, the floor differs from the plan, or ramp-up is simply slower. Each answer leads to a different action.

Leave the model out when the review is only about procurement or contracts, or when no dated baseline exists. Comparing reality with a model nobody approved proves nothing.

Whatever the result, update the assumption register so the next project starts from corrected values.

Bring the model into monthly reviews and continuous improvement

Monthly operations reviews mostly look back: output, downtime, scrap, cost. Add one short block that looks forward. List the changes planned for the next 4 to 8 weeks, such as a new product, a moved machine or a different shift pattern. Test those changes as variants on a copy of the base model, in the base case and one stress case, and compare with last month's run. The base model itself is updated only after a change is in place on the floor. Keep at least one stress case the same every month, so the results stay comparable.

Continuous improvement works the same way. Before a team moves a buffer, changes a picking route or reassigns work, it tests the idea in the model. Does the whole flow improve, or does the bottleneck move to the next station? Ideas that fail in the model never reach the floor. The ones that pass are implemented once and recorded, and the base model is then updated to match the floor.

Speed is what makes this practical. In a layout optimization project for a furniture manufacturer, mapping the production area took several days, while further AI-driven optimization took seconds instead of days. Once the model exists, the next question is cheap to ask.

Set it up in one quarter

1. Start from your best past project. Turn its model, scenarios and assumptions into the first library and register.
2. Name the owners. Engineering, operations, finance and a model steward, as described in Who Should Own the Digital Twin Model?.
3. Add the last two decisions. Record their scenarios and assumptions, so the library has a history.
4. Use it on one real decision. Choose one that matters, and do not allow exceptions to the rules.
5. Add the monthly forward block to the operations review.

The same idea applies to machine data. For the IoT side, see How to Turn IoT Into a Repeatable Operating System in a Brownfield Factory.

FAQ

What is a scenario library in a digital twin?

It is a named, dated set of model runs, such as base case, peak, disruption and ramp-up, that every new decision reuses. It keeps results comparable from one project to the next.

What should an assumption register contain?

Each input with its value or range, the evidence behind it, an owner, the date it was last checked and the scenarios that use it. Estimated values should be marked and given a date for verification.

When should a post-investment review use the digital twin?

When the approval was based on named scenarios and the line now performs differently than expected. Without a dated baseline from the approval, the model adds little.

Do we need live machine data for this process?

No. The library and register work with static data, updated by their owners when the plant changes. Live data from DBR77 IIoT is a later stage, when the model is used every month and you want it to follow the plant between those updates.

Conclusion

This month, open the folder of your last simulation project. Copy its base case, cycle times and stress cases into a first library and register, mark each value as measured or estimated, and give every estimated row an owner and a date.

Sources

• DBR77, Case study: Layout optimization (summary on this site)
• DBR77 Digital Twin, Deterministic vs stochastic simulation