The system went live. Nobody changed who does what

Most AI programmes have a go-live date. Few have a date on which the work around the system changes. The model is deployed, the interface works, and the next morning people do what they did yesterday, with one more window open.

The technology changes what is possible. The operating model decides what actually happens, and it is the part most programmes leave as a diagram.

What changes when a system takes on part of the work

Some work moves from doing to checking. A person who used to write the first draft, classify the ticket or match the invoice now reviews what the system produced. That is a different job, with a different pace and a different kind of fatigue, and it needs to be described as one.

Exceptions concentrate. The system handles the routine cases and the hard ones remain. The people left with the work now see only its difficult part, all day. Staffing and targets set for the old mix stop making sense.

Handoffs move. Wherever the system sits in the process, somebody passes work to it and somebody takes work back. Each of those points needs an owner, or cases fall between the system and the team and nobody notices until a customer does.

Decision rights shift. Who may overrule what the system did? Who decides that it should do less for a while? Who approves changes to how it behaves? If none of this is written down, the default answer is the engineering team, which is rarely who should be deciding.

Some roles disappear. Usually not whole jobs — parts of them. Saying so early and honestly costs less than letting people find out from the system, and it is the conversation most plans avoid.

Infographic

What needs redesigning besides the system

1. 01Division of workWhat the system does, what people do, what people check.
2. 02ExceptionsWho gets the hard cases, and with what staffing.
3. 03HandoffsWhere work enters the system and who takes it back.
4. 04Decision rightsWho may overrule, restrict or change the system.
5. 05MeasurementHow you can tell the new division of work is functioning.

What “in practice” means

A useful operating model is not a picture of boxes. It is a description, role by role: this is what the week looked like, this is what it looks like now, these are the new handoffs, this is who to call when the system is wrong.

It also describes the first month honestly. The first weeks after a change are uncomfortable: new handoffs get missed, checking feels slower than doing the thing yourself, and the old way is always one click away. A plan that names that month — and says who is available to help during it — gets through it. A plan that leaves it out reads the discomfort as failure.

Governance sized to the company

A twenty-person company does not need a steering committee for this; it needs one person with authority and an hour a week. A two-thousand-person company cannot proceed without one, because the decisions cross too many budgets. The mistake runs both ways: small firms borrow enterprise governance and stall, large ones run a cross-departmental change on goodwill.

The test is simple. When the system and a team disagree, how long does it take to get a decision, and who makes it? If the answer is “it depends” or “we would need to call a meeting”, governance is the wrong size, in whichever direction.

What to ask for

If you are commissioning an AI programme, ask to see the operating model before the build finishes, not after it. Specifically: which roles change and how; which roles or tasks disappear, and what happens to the people; who owns each new handoff; who can reduce what the system does unattended; and the two or three numbers that will show the new division of work is functioning.

If those answers are not available a few weeks before go-live, the go-live date is a technology date, and the change will happen later or not at all.

Then ask who owns the operating model once the programme ends. It will need revising as the system takes on more of the work, or less of it, and the team that wrote the first version will not be there. An operating model without an owner is accurate for about as long as nothing changes.

How we approach it

In an AI transformation engagement the operating model is written in practice rather than as a diagram: role by role, with the new handoffs and the first uncomfortable month, and with governance sized to the organisation instead of copied from a template.