Target Operating Model: Definition and Examples

A target operating model (TOM) is a future-focused blueprint that defines how an organisation must operate to deliver its strategy, across people, process, technology, data, governance and performance measures. It is critical to aligning technology with business strategy, yet its meaning remains unclear to many organisations. In our work with PE-backed, mid-market and enterprise businesses, a missing or poorly defined target operating model is one of the most common reasons transformation programmes falter. Many organisations that do commission one end up with a well-presented document and an unchanged business, because the TOM was treated as an artefact to produce rather than a change to embed.

This guide sets out what a target operating model is, how it differs from an operating model, the six layers it has to cover, worked examples, a step-by-step approach to designing one, and the reason most never make it off the page.

What is a target operating model?

A target operating model is a future-focused blueprint that defines how an organisation must operate to execute its strategy. It describes the desired end-state configuration of people, processes, technology, data, governance 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, a systems architecture or a strategy document. Each of those is a single layer of a TOM, and a model built from any one of them in isolation fails predictably: restructure without process change and the same problems move between boxes; re-platform without changing decision rights and an inefficiency is automated at speed.

Target operating model vs operating model

An operating model describes how a company creates and delivers value today. A target operating model is the desired future state: how the organisation must operate to achieve its strategic objectives. The distinction is directional. The operating model is descriptive of the present, while the TOM is prescriptive and forward-looking, driving change rather than documenting it.

A TOM therefore only has meaning against an honest picture of the current operating model, and this is where many exercises quietly go wrong. Organisations are usually candid about their strategy and less candid about their present state, because the present state records decisions made by people in the room. 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. Our guide to the Johnson and Scholes strategy model covers how strategic position, choices and action relate, and the operating model is where the action becomes concrete.

Why a clear target operating model matters

Organisations undergoing change, whether scaling rapidly, integrating acquisitions or transforming digitally, face complex challenges in bringing new technologies and evolving business objectives together. A clearly defined target operating model is the blueprint for how the organisation should operate in future to deliver value consistently. Without it, businesses risk misalignment between strategy and execution, fragmented processes, and inefficiencies that erode competitive advantage.

Boards, technology leaders and transformation directors rely on the TOM to guide resource allocation, governance and technology investment. When it is absent or poorly articulated, teams focus on isolated improvements and the result is siloed initiatives that do not support the overarching business goals. That means wasted budget, falling stakeholder confidence and slower time to market during transformation.

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 inside them: order to cash, procure to pay, hire to retire, and whatever is genuinely distinctive about how the organisation creates value. Processes should be described end to end rather than by department, because the failures that cost money almost always sit 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.

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 the structure looks like, but what capabilities the organisation needs that it does not have today, and where they will come from.

3. Technology and data

The application estate, the integration approach and the data foundation underneath both. In many mid-market and PE-backed businesses this layer has become the constraint rather than the enabler. Ambitions for automation and AI are routinely defeated here, because the data foundation was never designed and the ERP was implemented to a vendor's template rather than to the business model. The focus should be on how technology enables capability, not on the specifics of legacy systems.

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 determines whether anything else in the model works. If decision rights do not change, the operating model has not changed, whatever the organisation chart says. Our guide to building an enterprise governance framework goes deeper.

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 reverts to the old behaviours, because people optimise for what is counted.

Common IT operating models and structures

Within the technology function, the target operating model usually lands on one of three patterns, each suited to different organisational contexts.

Centralised model

Decision-making authority and resources are concentrated in a single IT function. This allows standardisation, economies of scale and stronger governance, but can slow response times and reduce flexibility for individual business units.

Decentralised model

IT responsibilities are spread across business units or regions. This enables faster innovation and responsiveness to local needs, but can introduce duplication of effort and governance gaps.

Hybrid model

Core services and governance stay central, while business units keep some autonomy to manage their own technology within guardrails. This balances control and flexibility, and it is the pattern most mid-market and PE-backed groups end up with.

Organisational structures that support each model

The organisational structure has to support the chosen operating model. A functional structure groups teams by discipline (infrastructure, applications, security, support) and suits a centralised model, building deep expertise but risking silos. A matrix structure assigns people to both functional roles and project teams; it encourages cross-functional collaboration in hybrid models but needs strong leadership to manage dual reporting lines. A business-unit structure embeds technology resources within business units, supporting a decentralised model with close business alignment at the cost of duplication and inconsistent standards.

Target operating model examples

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 and 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.
• 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.
• 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 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 governance layer. The other five layers describe things to build. Governance describes something to give away, and it is the layer that delivers the outcome. Organisations find the building easy and the giving away hard, which is why so many models deliver the systems and not the margin.

A hybrid technology model in financial services. A mid-sized financial services firm needed greater agility under heavy regulatory pressure. Security, compliance and platform management were retained centrally; business units gained autonomy to select applications and manage project delivery within guardrails; and cross-functional matrix teams were formed for transformation initiatives. The result was faster time to market, better risk management and clearer accountability.

A PE-backed consolidation. A PE-backed business struggling with inconsistent IT delivery and fragmented customer experience redesigned its target operating model around unified digital platforms and consolidated governance. Operating costs fell by 20% and product launches accelerated.

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

1. Anchor to strategy. Clarify the markets, products and customer segments the business prioritises, and 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. Map capabilities and evidence the current state. Identify the capabilities critical to those outcomes, then map the real processes, technology and structures with the people who run them. 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, it is a three-year model, and pretending otherwise simply moves the failure into delivery.
5. Sequence for value and define the measures. Order the roadmap by which changes release value earliest and which dependencies genuinely block others, not by architectural tidiness, and set the KPIs and success criteria at the same time. 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 added at the end. It is a design constraint from step one.

Design principles that hold up in practice

• Flexibility: build in modular processes and scalable technology so the model can absorb market and technology change without a redesign.
• Cross-functional collaboration: silos are the enemy of alignment, so governance should create shared accountability across business and technology.
• Technology enablement over technology ownership: design for capability, using cloud services, automation and data platforms that support agility and insight.
• Balanced governance: risk-based controls matched to the organisation's risk appetite and compliance obligations, protecting the business without stifling innovation.
• Clear accountability: roles and reporting lines defined unambiguously, so no decision falls between two owners.

Common mistakes in target operating model design

• Failing to link the TOM explicitly to business strategy, which leads to misaligned priorities and wasted effort.
• 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.
• Overcomplicating the model with unnecessary detail instead of focusing on critical capabilities and flows.
• Sizing the gap optimistically to keep the business case attractive, producing a model no one can implement.
• Ignoring culture and change management in the design, which impedes adoption.
• Neglecting the governance structures that create accountability and decision discipline.
• Treating the TOM as a static document rather than an evolving framework, when the only deliverable that counts is a business that works differently.

Digital transformation and the target operating model

Digital transformation is often the catalyst for revisiting or creating a target operating model. A common pattern is an organisation layering new digital capabilities onto a legacy operating model, which leads to inefficiency and accumulating technical debt. Successful transformation means rethinking how the organisation operates at its core: customer journeys, automation, decision rights and data flows.

The TOM must also be built to evolve, because technology and markets will keep shifting. Embedding review and continuous improvement mechanisms lets leadership adjust resources and processes proactively without major disruption. In practice, a light review each year and a fuller reassessment after any major acquisition, disposal or change in strategy keeps the model current.

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, tested across hundreds of engagements and backed by genuine research. If you want a defensible framework and a comprehensive design, they will provide one.

What the model tends to miss is not intellectual but structural. The commercial shape of a large-firm engagement rewards the design phase, where the intellectual property and the leverage sit. Implementation is often a separate mandate 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. That is not a criticism of capability. It is a description of an incentive, and it matters because on this subject the design is the easier 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 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, a function head to accept a group standard over a local preference, or 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 running change alongside the design and handing 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 say the design is complete but cannot say who has agreed to give up what, the model will not land.

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. With multiple expansion no longer a reliable route to return, houses are investing in operational value creation, and technology, data and ERP diligence have moved up the agenda.

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. In a five-year hold, an operating model that takes three years to land has consumed most of the window before the value shows 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.

Who should lead target operating model design

Executives benefit from the perspective of an experienced senior technology leader who sits outside the organisation's history. An independent CIO, CTO or transformation director brings an objective view unencumbered by legacy politics, bridges business strategy and technical execution, identifies cyber and technology risk early in the design, and makes sure the model supports data-driven decisions. Intology is independent of the platform vendors and systems integrators, so the model we design is the one the business needs rather than one that suits an implementation partner's practice mix.

See our approach to operating model redesign. Where the business needs senior technology leadership to own the model, see fractional and interim CIO; where the gap between current and target state needs dedicated delivery accountability, see interim transformation director.

Frequently asked questions

What is a target operating model (TOM)?

A target operating model is a future-focused blueprint that defines how an organisation must operate to execute its strategy. It describes the desired end state across process, organisation and people, technology and data, governance and decision rights, locations and sourcing, and performance measures, and gives transformation programmes a concrete guide.

How is a target operating model different from an operating model?

An operating model describes how the organisation works today. A target operating model describes how it needs to work to deliver the strategy. The operating model is descriptive and the TOM is prescriptive, and the value of the exercise sits in the honestly evidenced gap between them.

What are the components of a target operating model?

Six layers: process, organisation and people, technology and data, governance and decision rights, locations and sourcing, and performance and KPIs. Each must be designed coherently so that a change in one is reflected across the others. Missing or underdeveloped layers, most often governance, are a common reason programmes underdeliver against the business case.

How do you design a target operating model?

Anchor to the strategic outcomes, evidence the current state, design the target across all six layers, test the gap honestly, sequence the roadmap for value, and design the change alongside the model. It needs cross-functional input and senior sponsorship; without both, outputs tend to be siloed and do not hold up under scrutiny.

When does a business need a target operating model?

Most often during significant change: digital transformation, mergers and acquisitions, post-carve-out integration, or a strategic pivot that makes the current operating model unfit for purpose. It is also valuable during rapid growth, since scaling without a defined operating model produces inconsistency, duplication and governance gaps that get harder to resolve the longer they are left.

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.

Can a target operating model stay relevant in a fast-changing industry?

Yes, if it is maintained as a living framework with built-in review points. The TOM should be revisited as markets, regulation and technology shift, rather than treated as a one-off design.