A supply chain control tower detects a problem, decides the response, and makes sure the decision is carried out. If what you are being sold detects and displays but cannot decide or act, it is a dashboard with a better name. This distinction is the whole subject, and it explains why so many of these programmes end with screens nobody opens by month 9.
I have reviewed a number of these deployments, and the ones that worked shared a feature that appears in no vendor comparison: one named person was allowed to spend money at two in the morning without asking permission. Several of the failures had better software than the successes.
The four layers, and how each one fails
| Layer | Job | Typical failure |
|---|---|---|
| Data ingestion | Pull orders, shipments, inventory and carrier events into one place | Master data mismatch, where one site carries four identifiers and nothing reconciles |
| Event model | Turn feeds into states such as late, at risk or short | Alerts fire on every deviation, so staff mute them inside three weeks |
| Decision logic | Propose or pick the response, with cost attached | Recommends air freight that no budget holder will authorise |
| Execution and audit | Push decisions back into the systems that move goods, and record the outcome | Read-only integration, so every decision is re-typed by hand into another system |
Buyers examine the 4th layer last, and it decides whether the investment returns anything. A tower with read-only integration cannot close the loop, so it can never prove its own value. When renewal arrives 24 months later, nobody can point to a shipment that was saved, and the budget goes elsewhere.
The maturity ladder, described honestly
Vendors generally describe 4 stages. Knowing which one you are buying matters, because the price gaps are large and the capability gaps are larger.
- Visibility. Shows where things are. Genuinely useful, and routinely sold as the entire product.
- Predictive. Estimates arrival and flags shipments likely to miss. Worth paying for only if the estimate beats your own planners on 8 lanes out of 10, which is a testable claim and rarely tested.
- Prescriptive. Proposes a specific response with a cost comparison. Master data quality stops being negotiable at this stage.
- Autonomous. Executes defined responses inside limits nobody approves individually, which is the same boundary question raised by AI agents quoting freight. Few operations run here, and governance rather than technology is the barrier in every deployment I have seen since 2019.
Most organisations that ask me about a control tower want stage 3 behaviour and hold data that supports stage 1. Discovering that after signature is expensive, and a 2 week data audit finds it in advance.
The data you need before you shop
These systems do not fail on algorithms. They fail on inputs, and the required inputs are specific. Ocean freight needs carrier milestone events, vessel position data from AIS, and a booking reference that survives transshipment. The Digital Container Shipping Association, formed in 2019 by Maersk, MSC, CMA CGM and Hapag-Lloyd, publishes the track and trace standards that make those events comparable between carriers, and a provider who cannot say which version they consume is guessing.
Road freight needs EDI 214 status messages or a carrier API, plus an honest answer about subcontracting, because the subcontractor's driver is not on your provider's app. Tendering and settlement add the 204, the 990 and the 210 to the same conversation. Above transport, you need inventory positions refreshed more often than nightly, open purchase orders with committed dates, and a location master where every site holds exactly one identifier.
That last item sounds trivial and causes more delay than any other, as the 5 months below show. I watched one programme spend that time reconciling plant codes between an ERP and two warehouse systems before a single piece of tower logic ran. A useful pre-purchase test costs nothing: take 10 shipments that went wrong last quarter and reconstruct by hand, from your current systems, the moment each problem first became knowable. If your team cannot build that timeline manually, no platform will build it automatically.
Build or buy
| Approach | Sensible when | Real cost centre | Risk |
|---|---|---|---|
| Planning suite module | You already run that vendor's planning stack | Licence plus configuration, usually a commitment of 3 to 5 years | Strong inside the vendor's data model, weak at outside data |
| Visibility specialist | Your gap is transport events and arrival estimates | Per-shipment or per-lane pricing that scales with volume | Excellent at transport, not a decision engine |
| Build on a platform you own | You have engineering capacity and unusual processes | People, permanently, rather than a project budget | You now own a product and must staff it |
| Assemble around your transport management system | Most exceptions are transport exceptions | Integration work per carrier, often 6 weeks each | Thin view of inventory and demand |
The categories matter more than the names, but names make them concrete. Kinaxis, founded in 1984, o9 Solutions, founded in 2009, and Blue Yonder, bought by Panasonic in 2021 at a reported 7.1 billion dollars, sell planning-centred products with a tower on their own data model. SAP and Oracle position modules inside their broader suites. Project44 and FourKites, both founded in 2014, are transport visibility specialists. E2open, founded in 2000, sells a network platform, and Altana works on supplier mapping beyond the first tier.
The governance lesson from TradeLens
TradeLens, launched by Maersk with IBM in 2018, was discontinued in 2022 after 4 years. The software functioned, and more than 175 organisations joined, including five of the six largest container carriers. What it never received was enough of their actual data, because a platform owned by your largest competitor is somewhere to be present rather than somewhere to commit.
For an internal programme the transferable lesson concerns ownership rather than blockchain. A tower owned by one business unit that needs data from three others will be starved in the same way TradeLens was. Whoever owns it must either own the data or hold the authority to require it, and that question belongs in the design phase rather than in the third steering committee.
Measures that survive a finance review
Dashboard logins and alert counts are vanity metrics, and they are what most programmes report. These five are defensible:
- Time from knowable to known. If a delay was detectable on Monday and your team learned on Thursday, those 3 days are the job.
- Exception closure time. Hours between an alert and a decision recorded against it. Rising alert counts with flat closure time means you bought noise.
- Expedite spend. Emergency air freight and premium road should fall, because problems surface early enough for cheaper answers.
- Share of exceptions closed automatically. The only honest measure of maturity, and the one vendors avoid quoting.
- Estimate accuracy against two baselines. Compare predicted arrival with actual arrival and with your planners' own estimates, since beating a carrier's estimate is easy and beating an experienced planner is not.
The sequence that works
Start with one exception type that costs real money and that you can count, such as ocean containers missing an inland rail connection. Instrument that single flow end to end, including the execution step, then give one named person authority to act inside a stated limit. Run it for a quarter and compare closure time and expedite spend against the previous quarter.
This produces an unimpressive first demonstration and a defensible business case, which is the right order. Connecting every data source before choosing a decision to improve is how these programmes become two-year integration projects that finish with a screen and no evidence. Should the first version fail to change one decision inside 90 days, buying additional layers will not rescue it.