The steering committee has budget for one big supply chain project this year. The consultant’s deck has two options side by side. On the left, a control tower: live trucks, exceptions, OTIF. On the right, a digital twin: drag a slider, close a highway for a monsoon week, watch the network react. Every head in the room turns right.
Build the control tower first, because a digital twin is only as honest as the live record it is calibrated against, and most manufacturers do not have that record yet.
The two answer different questions
A control tower answers what is happening now and what needs action today. A digital twin answers what would happen if: a plant stops for a week, a carrier exits, a monsoon closes a ghat road. One is about operating; the other is about deciding before you operate.
That difference is why they get pitched as alternatives. They are not. A twin is a model of your plants, RDCs, lanes, carriers and stock. A model needs parameters: transit times, loading times, carrier reliability, demand at each depot. Our guide to the supply chain digital twin covers what goes inside one. The question for this post is where those parameters come from.
A twin built on master data inherits its optimism
Without a live record, the twin is fed from master data: the transit time in the ERP lane table, the loading time in an SOP, the carrier’s promised placement window. These numbers were written once and rarely revisited. They describe how the network was designed to work, not how it works.
A twin running on them will give answers that look precise and are quietly wrong. Worse, it will be wrong in the comfortable direction, because promised numbers are almost always faster than real ones.
Nobody notices at first. The twin’s outputs feel reasonable, the scenarios get presented to the board, and the buffer stock is sized on them. The error only shows up months later, when a real disruption hits and the RDC runs dry a day earlier than the model said it would.
A worked example: one lane, two transit times
Take an illustrative lane, not a customer case. A plant ships to an RDC 600 km away. The RDC sells 40 tonnes a day and holds 64 tonnes, so it has 64 ÷ 40 = 1.6 days of cover.
| Twin on master data | Twin on tower data | |
|---|---|---|
| Transit speed | 300 km/day (lane table) | 200 km/day (observed on past trips) |
| Normal transit | 600 ÷ 300 = 2.0 days | 600 ÷ 200 = 3.0 days |
| Shortfall at RDC | (2.0 − 1.6) × 40 = 16 t | (3.0 − 1.6) × 40 = 56 t |
| Monsoon week, speed −20% | 600 ÷ 240 = 2.5 days, 36 t short | 600 ÷ 160 = 3.75 days, 86 t short |
The master-data twin says the monsoon costs 36 tonnes of lost cover, so one extra truck of buffer stock fixes it. The twin calibrated on real trips says 86 tonnes, more than double. The scenario was identical. Only the source of one parameter changed, and the decision flipped from one truck to three.
A digital twin fed from master data simulates the network you designed, not the one you run.
The tower is what calibrates the twin
A working control tower produces exactly the numbers a twin needs, as a by-product of running the day. Every trip leaves a record of real transit time. Every gate visit leaves timestamps for each stage, so loading and dwell times are measured, not assumed. Carrier delays are attributed with a reason, so reliability is a number rather than a reputation.
ETA logic is a good test. A tower that projects arrival from the speed a truck has actually managed since billing, as described in our note on ETA calculation for trucks, is already collecting the speed distribution the twin will need for every lane. Build the tower and the twin’s inputs accumulate on their own.
A sensible sequence for most manufacturers
- Gate and dock first. Timestamp each stage inside the plant, so loading and dwell are measured.
- Trips and exceptions next. Bring carrier, GPS and ERP data onto one record with written KPI rules.
- Stock and expiry. Add RDC stock and batch shelf life, so exceptions can be weighed against cover.
- Then the twin. Run scenarios on parameters drawn from a few months of real trips.
This is the shape SCM for Manufacturers follows: the gate-to-proof-of-delivery module is live in production, and the scenario twin sits on that same record. A monsoon week in the twin uses the lane speeds the tower has already seen.
Where a twin can come first
There is a fair case for starting with the model. If the decision is strategic and one-off, such as where to put a new RDC or whether to close a plant, you do not need live data. You need a network model, sensible assumptions and a few scenarios. A static design study does that well, and waiting a year for tower data would be silly.
Two cautions apply. First, label the assumptions plainly, and stress-test the transit times, since that is where master data errs most. Second, do not let the study become the operating twin by default. A model built for a one-time decision drifts out of date the moment the network changes.
The other honest exception is a network that is already well instrumented. If your carriers and gates already feed a clean, agreed record, you have the tower’s data without the name, and the twin can start now.
What to do this week
- List the five parameters your planned twin would depend on most, such as transit time and loading time.
- For each, write down where the number comes from today: a measured trip log or a master table.
- Compare the lane-table transit time with real arrivals for your three busiest lanes.
- If the gap is large, put gate and trip capture ahead of the twin on the roadmap.
The twin is the prize, and it is worth building. Build it on a record that has already been argued over and settled. More on both in our SCM for Manufacturers guides.