An operating model is a set of decisions about who decides
The phrase intelligent enterprise is usually used to describe a technology estate. The more useful meaning is an operating model: a design in which business objectives, roles, processes, data, automated capability, governance and the improvement cycle are aligned rather than assembled independently. The failure of most such programmes is not a bad component. It is that the components were designed by different people against different assumptions, and the misalignment appears when the business runs something end to end.
Seven elements, and the order they must be designed in
The elements are usually presented as a list of equal importance. They are not: each one constrains the ones after it, and sequence matters far more than completeness. A working model leaves behind a decision rights register, a process map, a data dictionary, a capability catalogue, a control matrix and a backlog of improvements, each tracing back to the objective above it.
- Business objectives, stated as outcomes with owners and a number attached. Not a capability ambition, but what must differ for a customer, a cost or a cycle time.
- Roles, including the decision rights the objectives imply. Most programmes skip this step, and it decides whether automation has anything to decide.
- Process, redesigned around those decisions rather than inherited from the departmental structure.
- Data, defined against the process: what an entity is, which record is authoritative, who owns each definition.
- AI capability, applied where the work is genuinely ambiguous and left out where a rule will do.
- Governance, defining what the system may do, who approves, what is retained, who reviews it.
- Continuous improvement, the mechanism by which the model changes with the business.
Alignment is a chain, and a chain fails at its weakest link
The design should be read as a chain. Each link passes something to the next, and the value of the whole is bounded by the weakest link rather than by the average of its parts. Reading it as a chain also makes the gaps visible: an objective nobody owns, a role that predates its decision, a record with two definitions, a capability that guesses, a control without a reviewer.
How an aligned model passes from one element to the next
| Link | What it passes on | Fails when |
|---|---|---|
| Objective to role | Accountability for an outcome | No role holds the number |
| Role to process | Authority to decide | The process predates the decision |
| Process to data | A definition of what matters | The record has no owner, or has two |
| Data to capability | Context that can be trusted | The system reads and guesses |
| Capability to governance | Evidence of what was done | No trace, no reviewer, no boundary |
| Governance to improvement | A rate of change worth making | Nothing measures whether it worked |
The element most often missing is the first one
Plenty of operating models have a governance section, a capability catalogue and a data strategy, and no statement of what the business is trying to change. When that happens the model becomes an infrastructure plan, the projects become selectable from a list of possibilities rather than derived from a strategy, and the portfolio resembles a list of things the technology team found interesting. The symptom is easy to spot: the objectives can be replaced without disturbing the model.
Where artificial intelligence is genuinely not the answer
Several parts of this design are not technology problems and should not be dressed up as such. A decision with no owner does not acquire one through a system. A contested definition does not resolve itself through a schema. A process that exists because of a regulation cannot be simplified away by making it faster. And a business that cannot describe what it wants to change will not benefit from changing fast.
The boundary is worth stating precisely. AI is a good fit where the input is unstructured, the volume is high, the outcome is checkable and an error is recoverable. It is a poor fit where the rule is known but unenforced, where the error is not recoverable, or where the difficulty is agreement rather than information. The engineering of the first category is in enterprise agent engineering, and the choice of technique in when to use AI, rules or conventional automation.
How the design should be sequenced
A model produced in a single pass will be wrong, because the later elements are only knowable once the earlier ones have been argued. The practical approach is a vertical slice: one outcome, one role, one process, the data it needs, one automated step, the governance around it and the measure of whether it worked. Each repetition is cheaper, because the definitions exist.
- Write the objective as an outcome, a number and an owner, and require the other six elements to be consistent with it.
- For the chosen slice, name the decision and the role that owns it before touching data.
- Write the data definitions and their owners, and confirm who keeps them true.
- Set the boundary of what the system may do, and what happens when it is wrong.
- Agree the measure and the review date, and put both in the calendar before the build.
- Decide what the model must allow to change later, and who may.
How to know the model is working
An operating model is not an artefact. It is a set of arrangements that either makes the intended behaviour easier or does not. The evidence appears in a few places: a decision that used to require a meeting now has a single owner and a threshold; a disputed definition is written down and owned; an exception that used to surface at month end is raised the day it happens.
If none of that holds after two quarters, the model is a diagram rather than a design, whatever the document says. The organisational and process work accompanying the technology is described in business and organizational transformation, and the governance that makes the result defensible is in enterprise AI governance begins with business accountability.