A chief operating officer is judged on decisions, not on departments
A chief operating officer who is measured on departmental performance will receive departmental performance: cost per function, headcount per function, a balanced scorecard in which every function improves and the customer still waits. The reason is structural. When a plan is organised around functions, each function optimises its own measure, and the seams between them are nobody's job. A supplier error that becomes a re-worked order, an approval nobody was told about, a customer promise the delivery schedule was never briefed on: these are not failures of any single function. They are outcomes that no function is measured on.
Inventory the decisions the business actually makes
The work starts by replacing the organisation chart with a decision inventory. Not the decisions the company says it makes, but the ones genuinely made, daily, often by somebody whose name appears in no process document.
- Collect the decisions people remember arguing about in the last quarter, then check which of them recur on a cycle. Recurring decisions are the ones an operating model can actually support.
- For each recurring decision, record who decides today, who is consulted, who finds out afterwards, and what evidence the decider held at the moment of deciding.
- Mark the decisions where the evidence is assembled by hand, in a spreadsheet built the night before, a phone call, an inbox. These are the points where live operational information should be aimed, and the subject of continuous operational intelligence.
- Write down the decisions that nobody makes under their own name. A decision without an owner is usually taken by whoever has most patience, and it is taken late.
Decision rights need a name, a threshold and a boundary
Organising operations around decisions means writing down, for each recurring decision, the things that are currently implicit and uncontested.
What an explicit decision right contains
| Element | The question it answers | Why it matters |
|---|---|---|
| Owner | One named role decides, not a committee | Committees defer, and deferral leaves no trace in the data |
| Threshold | What inputs force escalation | Without it, every case becomes an escalation |
| Reversibility | Whether the decision can be undone cheaply | It sets how much evidence is needed before acting |
| Evidence | What the decider is entitled to see | It is the real specification of the data required |
Visibility means seeing the state of a decision, not the activity
Most operational dashboards report activity: orders placed, tickets closed, units shipped. Activity measures are always available and almost never diagnostic, because a team that does nothing and a team that does twice as much produce the same information in opposite directions. What an operating leader needs to see is the state of the decisions that matter: how many are waiting, how long they have been waiting, what they are blocked on, and which have aged past the point at which the answer is still worth having.
That is a much smaller set of numbers, and it is where workflow visibility pays. If the state of each decision is visible, the queue forms by itself, the ageing item becomes visible before it becomes an escalation, and the resource that was going to be spent rescuing the oldest case is instead spent on the newest one. The engineering of decision support, with its approvals and exception paths, is covered in enterprise agent engineering.
Where artificial intelligence helps and where a rule does not
Decision support is not one technical problem. Three techniques suit three different parts of it, and the common failure is to apply one of them everywhere.
- Rules and conventional automation for decisions that are already specified: threshold checks, routing, reconciliation, escalation. These are deterministic, cheap to test, and the right tool for a repeatable rule.
- Language models for the parts of a decision that require reading unstructured material, such as a long email thread, a supplier dispute history or a set of exception notes. Reading is what these do well, and they are a poor substitute for a threshold.
- Predictive models where the aim is to anticipate rather than to decide: which orders are likely to miss a date, which accounts are likely to dispute an invoice.
And artificial intelligence is not the answer to the design question itself. If a decision has no owner, a model will not acquire one. If the evidence is contradictory, a model will pick a side silently. The redesign work has to be done by the business, and it decides whether the technology has anything to be applied to. The technical boundary is set out in when to use AI, rules or conventional automation.
Operational performance has to be measured as outcomes with owners
Department-level measurement fails because the things that matter operationally cross the departments. A late supplier confirmation is a procurement fact, a production fact, a customer promise and a cash fact. Measured separately, none of the four moves when the promise is missed.
- Time from order to commitment, measured once, owned by the unit that makes the commitment.
- Cost of correcting, including consequential cost, measured on the process rather than split across functions.
- Age of exceptions, owned by whoever can clear them rather than whoever created them.
- Decisions waiting beyond their threshold, counted for the business rather than for a team.
The operating rhythm has to change with the model
New decision structures produce a different management rhythm, and the rhythm is where the model either takes hold or quietly reverts. A weekly decision review whose agenda is built from the ageing list rather than from reports is the practical test. If the meeting still runs on last month's aggregates, the redesign has not reached the calendar.
The purpose of all of this is to make operational performance legible in the week it happens, which is the subject of from monthly reports to continuous operational intelligence, and to sit inside a wider structure described in designing an intelligent enterprise operating model.