Control towers: the operating model behind the screen

Decision rights come first

Before any technology, the design question is which decisions the function may take alone, which it may take with a defined approver, and which it may only recommend. Reallocating stock between customers, resequencing production, upgrading a service level, releasing a hold — each needs an explicit answer. A coordination function without delegated authority becomes a very expensive alerting service, and the people it alerts learn to act on their own instincts anyway.

Exceptions need thresholds and playbooks

The value comes from responding consistently to recurring situations, so each exception class should have a defined trigger, a first response, an escalation path and a time limit for resolution. Late inbound consignments, supplier confirmation failures, quality holds and demand spikes all recur often enough to be proceduralised. Writing the playbook also exposes how many exceptions are generated by internal policy rather than external events.

Scope: what the tower does not do

Effective functions are narrow. They coordinate across the boundaries where nobody else has a view — between sites, between suppliers and plants, between regions — and they leave execution with the teams who own it. Towers that absorb daily operational work become a second operations department, duplicating effort and blurring accountability. The boundary should be written down, because it will be tested during the first serious disruption.

Staffing and hours determine credibility

A function covering a network that operates across time zones has to decide its own coverage honestly. Continuous cover is expensive and only justified where events genuinely arrive around the clock and the response cannot wait. Where it is not justified, defining a handover protocol and an out-of-hours escalation route is more useful than pretending to constant availability. Experience matters more than headcount: judgement about which exceptions are worth disturbing people for cannot be scripted.

Frequently asked questions

Does a control tower require dedicated technology?

Not initially. Many start by consolidating existing data into a shared exception view and proving that centralised decisions produce better outcomes. Technology becomes worthwhile once the process is stable, because it removes manual collation rather than supplying the missing authority.

Should the function be internal or outsourced?

It depends on where the decisions sit. Coordination of transport execution is often outsourced successfully, while decisions that trade one customer's service against another's rarely are, because they require commercial judgement and accountability the provider cannot hold.

How is its performance measured?

By outcomes it can influence: how quickly exceptions are detected and closed, how many are resolved without escalation, and the service and cost consequence of the decisions taken. Counting alerts generated measures activity and encourages exactly the wrong behaviour.