Target Operating Model: A Practical UK Guide

Most organisations that commission a target operating model end up with a beautiful document and an unchanged business. The slides are clear, the diagrams are elegant, the workshops were well attended. Eighteen months later, the same people are making the same decisions in the same way, and the board is asking why the investment case never landed. The problem is rarely the design. It is that a target operating model is treated as an artefact to be produced rather than a change to be embedded.

This guide sets out what a target operating model actually is, the six layers it has to cover, what one looks like in practice, and the reason most of them never make it off the page.

What is a target operating model?

A target operating model, often shortened to TOM, is a description of how an organisation needs to work in order to deliver its strategy. It defines the processes, people, technology, governance, locations and performance measures that together turn strategic intent into day-to-day operation. It is the bridge between what the board has decided and what the business actually does.

That definition matters because of what it excludes. A target operating model is not an organisation chart. It is not a systems architecture. It is not a strategy document. Each of those is a single layer of a TOM, and a model built from any one of them in isolation will fail predictably: restructure without process change and you move the same problems between boxes; re-platform without decision-rights change and you automate an inefficiency at speed.

Target operating model vs current operating model

The word doing the work is "target". A TOM only has meaning against an honest picture of the current operating model, and this is where most exercises quietly go wrong. Organisations are usually candid about their strategy and dishonest about their present state, because the present state is a record of decisions people in the room are responsible for.

A useful target operating model therefore starts with an evidenced current state, not an aspirational one. If the gap between current and target is not uncomfortable, the current state has been described politely rather than accurately, and the resulting model will understate the change required.

Where the TOM sits between strategy and delivery

Strategy answers where the organisation is going and why. Delivery answers what gets built and when. The operating model sits between them and answers how the organisation has to work for the strategy to be deliverable at all. Skip it, and the programme portfolio becomes a list of initiatives with no shared logic.

Classic strategy frameworks are useful here as an input rather than a substitute. Our guide to the Johnson and Scholes strategy model covers how strategic position, choices and action relate to one another, and the operating model is where the "action" column becomes concrete.

What a target operating model includes: the six layers

Frameworks vary in labelling, but a complete target operating model framework has to cover six layers. Leave one out and the model has a hole in it that implementation will find.

1. Process

The end-to-end value streams and the processes that sit inside them: order to cash, procure to pay, hire to retire, and whatever is genuinely distinctive about how this organisation creates value. Processes should be described end to end rather than by department, because the failures that cost money almost always live at the handoffs. This layer depends on evidenced process mapping rather than assumption. Our process mapping guide covers the as-is and to-be discipline in detail.

2. Organisation and people

Structure, roles, capabilities, spans and layers, and the skills the target state actually requires. The question that separates a real TOM from a reorganisation is not "what does the structure look like" but "what capabilities does this organisation need that it does not currently have, and where will they come from".

3. Technology and data

The application estate, the integration approach, and the data foundation underneath both. This layer has become the constraint rather than the enabler in most mid-market and PE-backed businesses. Ambitions around automation and AI are routinely defeated at this layer, because the data foundation was never designed and the ERP was implemented to a vendor's template rather than to the business model.

4. Governance and decision rights

Who decides what, at what threshold, with what information, and how quickly. This is the layer most often reduced to a committee diagram, and it is the one that determines whether anything else in the model works. If decision rights do not change, the operating model has not changed, whatever the org chart says. Our guide to building an enterprise governance framework goes deeper on this.

5. Locations and sourcing

Where work is performed and by whom: in-house, shared service, outsourced, offshored, or delivered by partners. The sourcing model is a design decision with a long tail. It sets the cost base, the control model, and the flexibility the organisation will have in three years.

6. Performance and KPIs

The measures that tell the board whether the target operating model is working, and the management rhythm that reviews them. If the new model is measured with the old metrics, the organisation will revert to the old behaviours, because people optimise for what is counted.

A worked target operating model example

Definitions are abundant and examples are scarce, so here is what the six layers look like when applied to a recognisable situation: a mid-market services business, roughly £80m turnover, grown by acquisition, now under pressure to improve margin.

The current state. Four acquired businesses operating as four businesses. Three finance systems and two CRMs. Every material decision escalates to the group executive because no one below it has a mandate. Quotes take eleven days because pricing approval sits with one director. Margin is unclear by contract because the data does not reconcile across entities.

The target state, layer by layer.

• Process: one end-to-end quote-to-cash process across all four entities, with local variation permitted only where a genuine client or regulatory difference requires it. Variation becomes an exception to be justified rather than a default to be accommodated.
• Organisation and people: commercial capability pushed into the entities, back office consolidated into a group shared service. Net headcount broadly flat, but the shape changes materially.
• Technology and data: single finance platform and single CRM, with a group data model defined before the migration rather than discovered during it. A common contract and client master is the precondition for everything else.
• Governance and decision rights: pricing authority delegated to entity MDs up to a defined threshold, with group approval reserved for genuine exceptions. This single change is what takes the quote cycle from eleven days to two.
• Locations and sourcing: one shared service centre, transactional finance consolidated, client-facing roles kept local.
• Performance and KPIs: contract-level margin visible monthly by entity, replacing group-level revenue as the primary management measure.

The instructive point is the fourth bullet. Layers one, two, three, five and six all describe things to build. Layer four describes something to give away, and it is the layer that delivers the outcome. Organisations find the building easy and the giving away almost impossible, which is why so many models deliver the systems and not the margin.

How to design a target operating model: a six-step process

1. Anchor to strategy. Write down the two or three strategic outcomes the model exists to deliver. Anything in the design that cannot be traced to one of them is scope, not requirement.
2. Evidence the current state. Map the real processes with the people who run them, and measure rather than assume. Expect this to be the most politically uncomfortable step.
3. Design the target across all six layers. Layers designed in isolation produce a model that cannot be implemented, because the dependencies between them are where the cost sits.
4. Test the gap honestly. Size the change in each layer. If the technology gap is two years and the capability gap is three, the model is a three-year model, and pretending otherwise simply relocates the failure to delivery.
5. Sequence for value, not for tidiness. Most roadmaps are ordered by architectural neatness. They should be ordered by which changes release value earliest and which dependencies genuinely block others. Our guidance on crafting a roadmap for organisational evolution covers the sequencing logic.
6. Design the change alongside the model, not after it. Adoption is not a workstream you add at the end. It is a design constraint from step one.

Common mistakes in target operating model design

Four recur often enough to be predictable. Designing the structure first, which turns the exercise into a reorganisation with a better name. Copying a reference model from a firm that operates nothing like yours. Producing a model no one can implement, because the gap was sized optimistically to keep the business case attractive. And treating the document as the deliverable, when the only deliverable that counts is a business that works differently.

McKinsey, Deloitte and KPMG target operating models: what they get right and what they miss

The large firms are searched for by name on this topic, and it is worth being fair about why. Their models are rigorous, well tested across hundreds of engagements, and backed by genuine research. If you want a defensible framework and a comprehensive design, they will give you one. The reference architectures are good, and the analytical horsepower is real.

What the model tends to miss is not intellectual. It is structural. The commercial shape of a large-firm engagement rewards the design phase, which is where the intellectual property and the leverage sit. Implementation is a separate mandate, often with a different team, and the people who understood why a decision right was drawn in a particular place are frequently no longer in the room when it is being fought over. The output is excellent. The landing is someone else's problem.

That is not a criticism of their capability. It is a description of an incentive. It matters because on this subject the design is the easy half.

Why most target operating models never land

A target operating model fails at implementation for a reason that is almost never technical. The design describes a set of behaviours the organisation has not agreed to adopt, and no one owns the gap between the two.

People do not resist operating models because they misunderstand them. They resist because the model asks a director to surrender pricing authority, asks a function head to accept a group standard over a local preference, or asks a management team to be measured on something that will initially look worse. Those are rational objections to real losses, and a communications plan does not answer them.

This is the problem the Embedded Change Model™ was built to solve. Rather than treating change as a discipline that runs alongside the design and hands over at go-live, it embeds the change effort inside the design itself: the people who will operate the model help shape it, decision rights are negotiated during design rather than imposed after it, and adoption is measured as a delivery outcome rather than reported as a sentiment score. The test is simple. If the programme can tell you the design is complete but cannot tell you who has agreed to give up what, the model will not land.

This is also why a target operating model is not a one-off exercise. Models decay as the business changes around them, and the useful question is how often to revisit rather than whether to. We have written separately on how frequently a target operating model should be reassessed.

Intology works on this end of the problem. We are independent of the platform vendors and the systems integrators, which means the model we design is the one the business needs rather than the one that suits an implementation partner's practice mix. More on our approach to business transformation.

The target operating model in a PE-backed context

In a PE-backed business the operating model has become the vehicle for the value creation plan rather than a governance exercise that follows it. KPMG's 2026 UK Private Equity Landscape research makes the point plainly: with multiple expansion no longer a reliable route to return, houses are investing in operational value creation, and technology, data and ERP diligence has moved to the top of the agenda. Several are now hiring operating partners specifically for ERP and cyber, because those are the foundations everything else depends on.

The practical consequence is that operating model work starts during diligence rather than after completion. The question at the deal table is no longer only what the asset is worth, but what it would have to become, how long that takes, and whether the management team can run the target model at all. A value creation plan that has not been tested against an operating model is a set of ambitions with a deadline.

The clock sharpens everything. In a five-year hold, an operating model that takes three years to land has consumed most of the window before the value shows up in the exit multiple. Sequencing is not an administrative detail in this context. It is the plan. More on our work with private equity backed businesses.

Frequently asked questions

What is a target operating model?

A target operating model is a description of how an organisation needs to work in order to deliver its strategy, covering process, organisation and people, technology and data, governance and decision rights, locations and sourcing, and performance measures. It is the bridge between strategic intent and daily operation.

What is included in a target operating model?

Six layers: process, organisation and people, technology and data, governance and decision rights, locations and sourcing, and performance and KPIs. A model missing any of these has a gap that implementation will expose, most commonly in governance and decision rights.

What does a target operating model look like in practice?

It is a set of connected artefacts rather than a single diagram: end-to-end process designs, a capability and structure view, an application and data architecture, a decision rights matrix, a sourcing model, and a measurement framework, all traceable back to the strategic outcomes they serve.

What is the difference between a target operating model and an operating model?

The operating model is how the organisation works today. The target operating model is how it needs to work to deliver the strategy. The value of the exercise sits in the honestly evidenced gap between them.

How long does target operating model design take?

Design typically takes eight to sixteen weeks depending on scale and the quality of existing process documentation. Implementation is measured in years, not months, and any timeline that suggests otherwise has underestimated the capability and data gaps rather than solved them.

Who owns the target operating model, the board or the programme?

The board owns it. A programme can design and deliver a target operating model, but only the board can authorise the changes to decision rights and measurement that make it real. Where ownership is delegated entirely to a programme, the model tends to deliver systems and structures without the behavioural change that produces the return.