A supply chain control tower is easy to justify and hard to finish. The business case writes itself — one view across orders, inventory, transport and suppliers — and the first release usually delivers exactly that. A screen with everything on it.
Then it gets used less each month, until it survives as a report somebody screenshots for a Monday meeting. The reason is consistent, and it is not a technology failure. A dashboard tells you something is wrong. It does not tell you what to do, and it does not do it.
The distinction that decides the outcome
Visibility and orchestration are different products with different requirements, and conflating them is the single most common scoping error.
Visibility answers what is happening. It needs data integration, a common identifier across systems, and tolerable latency. It is genuinely hard, and it is the easier of the two.
Orchestration answers what should happen, and then makes it happen. It needs the above, plus a decision model, plus write access to the systems that execute, plus an agreed policy about which decisions it may take alone. Vendor coverage of the category increasingly frames this as the next phase — moving from monitoring toward agentic capability that executes corrective action rather than merely flagging it.
Most programmes fund the first and promise the second. The gap between them is where the disappointment lives.
Four things a control tower must have to change a decision
| Requirement | Why it matters | Common shortfall |
|---|---|---|
| One identity per object | An order, shipment or SKU must be the same thing in every feeding system | Three systems, three keys, reconciliation by spreadsheet |
| Latency matched to the decision | A daily refresh cannot support an intraday diversion | Nightly batch presented as real time |
| An owner per exception type | Alerts with no named owner are noise within a fortnight | One shared inbox for everything |
| A defined action, not just a flag | The tower must offer or take the next step | A red cell and a phone call |
The third row is the most underestimated. A control tower that raises two hundred alerts a day, where nobody owns a specific category, trains its users to ignore it — and once that habit forms it does not reverse, however much the data quality improves afterwards.
Forecasting is where the value usually starts
If a full orchestration programme is too large to begin with, demand forecasting is the pragmatic entry point, and it is where adoption has concentrated. Research coverage of the area points to AI-based forecasting moving steadily into routine use across large organisations through the end of the decade, with resilience and disruption response as the driver rather than cost alone — ABI Research's assessment is a reasonable summary of that direction.
Forecasting works as a starting point for a structural reason: it produces a number that an existing process already consumes. Nobody has to change how they work to benefit from a better forecast, which means adoption is not blocked on behaviour change. Orchestration, by contrast, requires somebody to stop making a decision they currently make.
It also exposes data quality honestly. A forecast that is wrong because master data is wrong will be visibly wrong within a quarter, and that is a cheaper way to discover the problem than finding it during a cut-over.
Sequencing that tends to hold
- Fix identity first. One key per object across ERP, WMS and TMS. Everything downstream depends on it and nothing downstream can compensate for its absence.
- Pick three exception types, not thirty. Late inbound, short pick, and at-risk delivery are a reasonable starting set. Each gets a named owner and a defined response.
- Instrument the current response. How long does each exception take to resolve today, and how often is the resolution the same one? Repetition is the signal that a decision can be automated.
- Automate the repeated response only. Start where the same action is taken almost every time; keep the human for the rest.
- Measure decisions changed, not screens viewed. Usage statistics flatter a dashboard. The honest metric is how many decisions happened differently because of it.
What to expect
The realistic outcome of a first phase is not an autonomous supply chain. It is a shorter gap between an event and a response, on a small number of exception types, with the reasoning recorded. That is a modest-sounding result and it compounds, because each automated response produces training data for the next one and each resolved exception type frees attention for the next.
The programmes that fail are rarely the ones that aimed too low.
Key takeaways
- Visibility and orchestration are separate products; funding one and promising the other is the standard scoping error.
- A control tower needs one identity per object, latency matched to the decision, a named owner per exception type, and a defined action.
- Demand forecasting is the strongest entry point because it improves an existing process without requiring behaviour change.
- Automate only the responses that are already repetitive, and keep the human for the rest.
- Measure decisions changed, not dashboard sessions.