The operating model comes after the system. It never does.

Most transformation leaders believe the operating model comes after the system. Choose the platform. Configure it. Then work out how the business runs on it.

It never happens in that order. A programme cannot skip the operating model. It can only skip designing it.

The moment a system goes live, an operating model exists. Somebody owns each step. Somebody approves the exception. Somebody decides what to do when the case does not fit. If nobody designed those answers, the vendor's default configuration supplies some of them and the people at the desks supply the rest.

Why it gets skipped

Nobody on the programme is paid to do it. The vendor is paid to configure. The programme is paid to hit the date. The business is paid to run today's operation. Deciding how the business will run tomorrow sits between all three, so it falls into the requirements phase by default.

Requirements gathered without a designed future state describe the present. The team documents how things work now, the system is built to match, and the organisation gets its old way of working, automated. Old furniture, new house.

The bill arrives later, labelled stabilisation. Workarounds, a phase two, a second round of requirements for things the business needed all along.

An operating model is not a document. It is a set of decisions, made once before requirements or a thousand times after go-live.

What it actually is

Who owns this. Who decides that. What happens when the rule does not apply. Each of those decisions gets made either once, deliberately, before requirements, or repeatedly and quietly after go-live by whoever happens to be holding the problem.

So the question is not whether your programme has an operating model. It does. The question is who on your programme is paid to design it.