What an order delivery control tower should actually do

Control tower is one of those phrases that has been applied to so many things it now mostly signals ambition rather than capability. It gets used for a dashboard, for a weekly meeting, and occasionally for something that deserves it.

Since it is the first thing we are building, it is worth being specific about what we think it has to do to earn the name.

It is organised around a commitment, not a process

Most operational software is organised by function. Production planning here, purchasing there, quality somewhere else. That matches how the business is structured and it is why the dependencies between them are nobody's screen.

A control tower inverts that. The unit is the customer commitment, and everything that threatens it is gathered against it regardless of which department owns the underlying fact. The order is the row. Material, production, quality and dispatch are attributes of that row, not separate systems to be visited in turn.

This sounds obvious and it is structurally quite hard, because it means resolving the same physical thing across systems that name it differently.

It scores the whole book, not the exceptions

A late order report lists what has already slipped. That is a record, not a warning.

A control tower assesses every open order against its promised date, including the ones that currently look fine, because the point is to catch the transition from fine to at risk while there is still room. Most of the book will be healthy most of the time, and the system has to be comfortable saying so without manufacturing alarm to justify itself.

A system that flags everything has not prioritised anything. It has moved the triage problem to a new screen.

It explains itself without being asked

The fastest way to kill one of these systems is to show a planner a red order with no reason attached. They will go and check it manually, because they are accountable and the system has not earned trust yet. Having checked manually twice and found the flag wrong once, they will stop looking at it.

So the evidence is not a drill-down behind an icon. It is the main content: the purchase order line that moved, the works order that cannot now start, the inspection that has not cleared, each with its source record and its timestamp. The risk score is a sorting aid. The evidence is the product.

It knows how long is left

Two orders can be equally at risk and require completely different responses, because one can still be recovered and the other cannot.

Time remaining is the dimension that makes a queue actionable. It is also genuinely difficult, because it depends on lead times that are nominally in the system and actually in somebody's head. Getting this approximately right is worth more than getting the risk score precisely right.

It proposes moves and names their cost

This is where most implementations stop, and it is the part that decides whether the thing is useful.

Knowing an order is at risk is a small fraction of the work. The real question is what to do: expedite the component and pay for freight, resequence production and push a different order, split the shipment, substitute a part, or accept it and re-promise the date before the customer chases.

Each of those costs something somewhere else, and that cost is exactly what a connected view can calculate and a human cannot, quickly, across a whole book. A system that surfaces the options with their consequences attached is doing the difficult part. One that stops at the red flag has handed it back.

It keeps the decision with a person

None of this should end with software changing a production schedule or emailing a customer on its own.

The decisions involved have commercial consequences and depend on context that is not in any system: which customer is mid-negotiation, which supplier owes you a favour, which line manager is already stretched. The system's job is to make the choice well-informed and fast. The choice stays with the person who owns the outcome, and the system records what they chose.

It learns from what happened

Once decisions are recorded alongside outcomes, something more useful becomes possible: knowing which interventions actually work.

Most operations have strong institutional beliefs about this that have never been tested. Expediting may be routinely wasted on orders that would have landed anyway. A supplier may have a far worse record than their reputation. That feedback loop is slow to accumulate and hard to argue with once it exists.

The honest summary

A control tower is an order risk queue, with evidence, with time remaining, with recovery options costed, and with an owner for each decision. Everything else is a dashboard with a more confident name.