A method for designing operating models: place each decision loop on a two-axis map to measure the variety it has or can absorb. It can move only in the directions the operational physics permits.
In short
Operating Model Physics places every decision loop on the Variety Map. It counts two numbers for it: the gate and the size. After that, it moves it one axis at a time where the physics allows. Why? Because usually target operating model roadmaps have no test. Often their maturity ladder holds only one vector. On top of that, the AI-powered workforce redesign redistributes work and has no check gates to validate whether the prescribed activities will hold.
What is Operating Model Physics?
An operating model is a portfolio of loops, and physics can test each loop's place.
Operating Model Physics is a method for designing operating models. Each decision loop is placed on a two-axis map by where operational surprises are absorbed and how. Just two numbers: a. whether the model's responses can match what arrives and b. how much of such variance comes from the outside of company walls. Then it is moved, one axis at a time, only in the directions actual variability stress test permits.
Strategy still chooses (and defines "No" to specific aspects of choices). The physics only forbids and constrains - that's the whole difference from the two habits it replaces.
What does a target operating model (TOM) leave out?
A TOM says where to go. Operating Model Physics says whether it can stick and get sustained.
A target operating model is a diagram and direction of where the organisation should be: which functions, in which places, on which systems. It also includes governance and critical policies. I've designed several of those myself, and inherited many during transformation programmes I delivered. None of them includes testing or relevant simulations. Nothing in such a strategy document clearly states whether a loop moved to the centre will still answer inside its response window, or whether a rule book written for last year's exceptions will survive this year's (as COVID did with just-in-time models).
The maturity ladder (or curve) has the opposite challenge. It carries a direction, manual to autonomous (or self-driven, as some AI gurus define it), and applies it to every loop at once. My issue is that two loops at the same maturity can be very different work activities: one is a rule set in a data centre somewhere in Europe, and the other is a rule set on a truck delivering a container to the port of Santos in Brazil. The maturity assessments often can't capture such differences because they look at things from an aggregation perspective.
And the word itself does the damage because of some psychological inertia - low maturity reads as a fault. As a result, the loops that should stay there are pushed up until the exception queue becomes the operating model. We know what it means to manage operations by exceptions - operating models would lift or move problems instead of real EBITDA.
The forming trend is the workforce and org. structure redesign. It consists of various steps such as:
- value drivers definitions
- workflows mapping
- decisions about what work should be eliminated
- distributing what's left among employees and AI (sometimes + contractors).
The new direction is emerging: managers become coaches (some even start calling them the 'middleware'), teams get smaller, and the question of who does the work is declared the wrong question. In my opinion, it's a better habit than the other two, at least because it starts with the work but has no test. A workflow is a sequence of operational (or any other) activities. A limitation of viewing things through a workflow lens is that it lacks sensing, response configurations, and the ability to handle external variances. For example, it's hard to predict whether a workflow (when delegated to Agentic AI) is likely to sustain results in cases when the shipping line or the local regulator does something no one expected.
Any methodology or framework can point to work or activities that can be potentially removed. The main constraint I see there is that it can't say which decision loops are likely to fail. Failures usually arrive (and they always will) after the people who used to absorb them have been counted as P&L-relevant savings. It's also impossible to identify which loops will hold after all the corporate changes and restructuring initiatives.
Operating Model Physics (aka first principles) aims to preserve the strategy's objective and the operating model vectors. It also keeps the ladder as one axis of a map, and maintains the redesign's starting point - the work. It just adds the element that all three were missing: two measurements per loop.
What are the parts of the framework?
My main objective is to shape our mental models when we approach TOM or agentic AI initiatives. The framework is a work in progress (and will change over time), but so far it has eight main blocks. Please read it in order the first time, and then as needed.
The Variety Map is a starting point. It frames and scopes everything else combined with the spectrum that scales it. The four archetypes (you can replace them with your own definitions) are the map's edges. The physics of operations provides a clear signal whether a loop will hold where it's required or going to be placed. Moves and methods will guide how to shift and shape a loop so it sticks. The final stroke comes at the crosswalk and glossary modules, where we translate the whole analysis stack into the words/definitions you already apply in your operational context.
| Sheet | What it answers |
|---|---|
| The Variety Map | Two axes + one square + every loop at a point |
| The encoding spectrum | Five stages of one loop: T1 to T5 |
| Four archetypes | Craft - Desk - Engine - Autopilot |
| The physics | The gate and the size - counted on one loop |
| The moves | Four directions with each being gated |
| The method | Map, measure, move - one loop at a time |
| Crosswalk | Where the familiar tools land |
| Glossary | One vocabulary for the set |