A practical guide to building your target operating model

A target operating model is the future-state blueprint that converts your strategy into concrete operational arrangements across people, processes, technology, data, and governance. It is not a reorganisation chart, nor is it an IT project. Your first move: commission a current-state diagnostic and run a stakeholder alignment workshop before you design anything. Frameworks such as McKinsey 7S and POLISM give you the structural language; platforms like Oakandnine give you the live data to make that language real.

Key takeaways

A target operating model is only as durable as the governance and live data that support it after the design phase ends.

Table of Contents

• What is a target operating model, and how does it differ from your current model?
• What core elements must every TOM specify?
• Which frameworks help you structure a TOM?
• When do organisations build or update a TOM?
• How do you design a TOM from diagnostic to blueprint?
• How do you govern TOM implementation?
• How do you measure whether your TOM is working?
• What does a TOM project typically cost and how long does it take?
• What causes TOM programmes to fail, and how do you avoid it?
• Your immediate checklist to commission a TOM project
• What most leaders underestimate about TOM work
• Oakandnine gives your TOM a live foundation, not a static blueprint
• Sources

What is a target operating model, and how does it differ from your current model?

The confusion is understandable. Three terms circulate in every transformation programme, and conflating them costs months of misaligned effort.

Your business model describes how you create and capture value: your customers, your proposition, your revenue logic. Your current operating model (the as-is) describes how you actually run today: the processes, systems, and structures that exist right now, with all their workarounds and legacy constraints. Your target operating model is the to-be description, converting strategy into the operational arrangements you need to deliver the business model at a future point in time.

Consider a UK financial services firm merging two back-office functions after an acquisition. The current operating model reveals duplicate teams, incompatible systems, and conflicting governance. The TOM defines the single integrated function they are building: the processes that will be standardised, the technology platform that will replace the legacy pair, and the governance model that will own performance from day one. Without that blueprint, every workstream makes local decisions that collectively produce a new mess.

HBR research makes the point bluntly: many organisations are simply not structured to execute their stated strategy, and operating model misalignment is one of the most common root causes of poor execution.

What core elements must every TOM specify?

A TOM that only redesigns the org chart will fail. You need to make explicit design decisions across every dimension that determines how work gets done. Starkhorn's practical guide identifies six interrelated components; most practitioners add a seventh for performance. Here is what each requires you to define:

• Purpose and strategy alignment: The two or three strategic outcomes the TOM is designed to deliver, expressed as measurable commitments rather than aspirations.
• Processes: Which end-to-end processes will be standardised, which will be centralised, and which will remain locally owned; documented as swimlane maps with clear handoffs.
• People and capability: The skills, roles, and headcount the future state requires; a capability gap map against the current workforce.
• Structure and governance: Reporting lines, decision rights, and the governance bodies that will own performance and resolve escalations.
• Technology and data: The systems, integrations, and data architecture required; which platforms are retained, replaced, or newly procured.
• Locations and suppliers: Where work is performed, which activities are outsourced, and the supplier management model that governs third-party delivery.
• Performance and KPIs: The metrics, targets, and reporting cadence that will confirm the TOM is delivering its intended value.

The weighting you give each element depends on your programme's trigger. A cost-reduction programme will spend the most design time on processes, locations, and suppliers. A digital transformation will weight technology, data, and capability most heavily. Decide which elements need the deepest design work in your scoping workshop, before you allocate resources.

Which frameworks help you structure a TOM?

Frameworks matter because they give your design team a shared vocabulary and prevent critical dimensions from being overlooked. Two are referenced consistently across consulting practice.

McKinsey 7S

McKinsey 7S groups the organisation into seven interdependent elements: Strategy, Structure, Systems, Shared Values, Style, Staff, and Skills. The model's practical value in TOM work is its explicit separation of hard elements (Strategy, Structure, Systems) from soft elements (Shared Values, Style, Staff, Skills). That distinction forces leaders to confront the cultural and behavioural changes a new operating model demands, not just the structural ones. If your TOM redesigns the process layer but leaves the management style and shared values untouched, the new model will be rejected by the organisation within months.

POLISM and layered models

POLISM (People, Organisation, Location, Information, Systems, Management) is a layered framework used widely in UK transformation programmes. It maps directly onto the core TOM elements and is particularly useful for functional or shared-service redesigns where you need to show how each layer changes from as-is to to-be. KPMG's six-layer TOM follows a similar logic: Process, People, Service delivery model, Technology, Performance insights, and Governance. The advantage of layered models is that they produce a structured blueprint you can hand to workstream leads with clear ownership of each layer.

Choosing the right framework

Pick McKinsey 7S when your transformation is enterprise-wide and cultural resistance is a known risk. Use POLISM or a six-layer model when you are designing a specific function, shared service, or regional operating unit and need a layer-by-layer blueprint your workstream leads can own. At the diagnostic stage, use whichever framework your executive sponsor already recognises, because alignment on language at the top accelerates every conversation below it.

When do organisations build or update a TOM?

The trigger shapes the TOM's scope and emphasis. Roland Berger's organisational design practice cites M&A, digital change, and margin pressure as the most common catalysts. Here is how each shapes the design focus:

• Merger and acquisition integration: The TOM defines the combined entity's processes, governance, and technology stack. Priority elements are structure, governance, and process standardisation. The risk without a TOM is that two organisations run in parallel indefinitely, destroying the synergy case.
• Digital transformation: The TOM specifies the future-state technology and data architecture alongside the new ways of working that depend on it. Capability and technology elements dominate. For practical guidance on digital transformation best practices in UK mid-market organisations, the design principles are consistent: define the operating model before selecting the technology, not after.
• Cost reduction and efficiency programmes: The TOM identifies which activities to consolidate, automate, or exit. Process, location, and supplier elements receive the most design attention.
• Rapid scale or market entry: The TOM establishes the repeatable operating model that can be deployed across new geographies or customer segments without reinventing governance each time. Standardisation of processes and a clear technology platform are the priority.

Each use case also determines whether you need an end-to-end enterprise TOM, a functional TOM (finance, HR, supply chain), or a regional TOM for a specific market. Scope that decision in your first workshop.

How do you design a TOM from diagnostic to blueprint?

The Opex Society's operating model body of knowledge sets out the canonical sequence. Here is a practical version with recommended deliverables at each stage:

1. Define scope and design principles. Agree what the TOM covers, what it does not, and the five to seven principles that will guide every design decision (e.g. "customer-facing processes are never outsourced"). Deliverable: scope statement, design principles document.
2. Current-state diagnostic. Map as-is processes, systems, data flows, and capabilities. Identify friction points, duplication, and gaps. Deliverable: as-is process maps, capability inventory, pain-point register.
3. Capability mapping. Define the capabilities the future state requires, rated by current maturity. This is where value-chain thinking and capability descriptions determine what to standardise, centralise, or keep local. Deliverable: capability map with maturity ratings.
4. Target capability and process design. Design the future-state processes as swimlane maps, define the service delivery model, and specify data and system requirements. Deliverable: to-be process maps, service model description, data architecture outline.
5. Organisational design. Define roles, reporting lines, headcount, and decision rights. Produce a RACI for key decisions. Deliverable: org design options, RACI matrix, role profiles.
6. Technology and data requirements. Specify which systems are retained, replaced, or newly built; define integration requirements and data governance. Deliverable: technology roadmap, data governance framework.
7. Gap analysis and phased roadmap. Compare as-is to to-be across all elements, size the gaps, and sequence the work into phases with dependencies, owners, and milestones. Deliverable: gap analysis, phased roadmap, business case.

Co-design at every stage is not optional. Roland Berger's consulting approach is explicit: TOMs rooted in co-design with employees and grounded in capability mapping produce more durable outcomes than those handed down from a small design team. Run validation workshops at the end of steps 3, 4, and 7 to stress-test assumptions before you commit to the roadmap.

How do you govern TOM implementation?

Design is the easier half. Execution is where most programmes lose momentum, and the governance model you put in place in the first month largely determines whether the TOM lands or drifts.

The governance stack

A pragmatic three-tier structure works for most UK mid-market programmes:

• Steering committee (monthly): Executive sponsor, CFO, and functional heads. Owns the business case, resolves cross-functional conflicts, and approves scope changes.
• Transformation office (weekly): Programme director and workstream leads. Tracks milestones, manages dependencies, and owns the RACI. The transformation office is the connective tissue between design intent and delivery reality.
• Workstream leads (daily/weekly): Own delivery of their TOM layer (process, technology, people, etc.) and escalate blockers to the transformation office within 48 hours.

RACI for TOM decisions

For each major decision category (scope changes, technology selection, headcount changes, governance policy), assign a single Accountable owner. Distributing accountability across committees is the single fastest way to stall a programme. A change management software guide for mid-market teams covers tooling that supports RACI tracking and decision logging at scale.

Change management in a UK context

UK organisations must factor in statutory consultation obligations when restructuring roles, TUPE regulations where services transfer between employers, and GDPR requirements when redesigning data flows and system access. None of these are afterthoughts; they belong in the programme plan from week one. Employee consultation, done well, also produces better design: the people closest to the work know where the current model breaks.

Typical implementation risks and mitigations:

• Scope creep: Enforce a formal change-control process from day one; every scope addition must be assessed against the business case.
• Technology delays: Run technology procurement in parallel with process design, not sequentially; a six-month procurement cycle will stall the entire programme if it starts late.
• Capability gaps: Identify training needs during the diagnostic, not after go-live; build learning pathways into the roadmap.
• Stakeholder fatigue: Communicate progress monthly to the wider organisation; silence breeds resistance.
• Governance vacuum: Appoint the transformation office before the design phase ends, not after.

Pro Tip: Appoint your executive sponsor before you commission the diagnostic. A TOM without a named, empowered sponsor at C-suite level will be deprioritised the moment a quarterly trading pressure arrives.

How do you measure whether your TOM is working?

Teneo's TOM design practice is clear: performance insights and governance must be built into the model explicitly, not bolted on at the end. Measurement starts with the design principles you set in step one and ends with a live reporting pack that the steering committee reviews every month.

Sample KPIs by TOM element:

• Process: End-to-end cycle time, error rate, rework volume, cost per transaction.
• People and capability: Role vacancy rate, capability maturity score, training completion rate, employee effectiveness index.
• Technology and data: System uptime, integration failure rate, data quality score, time-to-insight.
• Governance: Decision cycle time, escalation resolution time, policy compliance rate.
• Financial: Cost-to-serve, margin per product line, revenue per FTE.
• Supplier and location: Supplier SLA adherence, third-party risk score.

The distinction between leading and lagging indicators matters here. Cycle time and error rate are lagging: they tell you what happened. Capability maturity scores and training completion rates are leading: they predict whether the model will perform. You need both. Set targets at the design stage, not after go-live, and build thresholds that trigger a governance review when a KPI moves outside its acceptable band.

A practical reporting cadence: workstream leads report weekly on milestone and risk status; the transformation office produces a fortnightly dashboard covering KPIs, risks, and decisions required; the steering committee reviews a monthly pack covering business case progress, financial KPIs, and strategic milestones. For guidance on linking TOM outcomes to margin improvement, the financial KPI layer is where the business case is either validated or challenged.

What does a TOM project typically cost and how long does it take?

Timelines and costs vary with organisational size and programme scope, but the phases are consistent.

Typical timeline bands:

• Diagnostic and scoping: 4–8 weeks for a mid-market organisation; longer for complex multi-site or multi-entity programmes.
• Design (target state and gap analysis): 8–16 weeks, depending on the number of TOM elements in scope and the co-design cycle required.
• Pilot: 8–12 weeks to test the new model in one function, region, or process before scaling.
• Scale and embed: 6–18 months for full deployment, change management, and capability building.

Major cost drivers:

• Consultancy and design time (typically the largest single cost in the diagnostic and design phases).
• Technology changes: procurement, configuration, integration, and data migration.
• Training and change management: learning design, delivery, and communications.
• Transition costs: running old and new models in parallel during cutover.
• HR and redundancy costs where restructuring changes headcount.
• Vendor integration and third-party contract renegotiation.

Scope is the primary lever on both timeline and cost. An end-to-end enterprise TOM for a 2,000-person organisation will take two to three times longer and cost proportionally more than a functional TOM for a single shared-service centre. Define scope tightly in week one and protect it.

What causes TOM programmes to fail, and how do you avoid it?

The failure patterns are well-documented. HBR's research on strategy execution identifies structural and systemic misalignment as the root cause in the majority of cases, not a lack of strategic ambition.

Research signal: Consulting evidence consistently shows that the majority of large-scale transformation programmes do not fully deliver their intended benefits, with weak linkage between strategy and operating model design cited as a primary cause.

Common pitfalls and how to counter them:

• Weak linkage to strategy: The TOM is designed around internal preferences rather than strategic outcomes. Counter it by anchoring every design decision to the two or three strategic commitments the TOM must deliver.
• Treating TOM as an org-chart exercise: Redesigning reporting lines without touching processes, technology, or governance produces a new structure running the old model. Every TOM element must be in scope.
• Neglecting data and technology: Organisations that design the people and process layers without specifying the technology and data requirements discover mid-implementation that their systems cannot support the new model. Technology requirements belong in the design phase.
• Insufficient governance: Programmes without a transformation office and a functioning RACI drift. Decisions accumulate, dependencies are missed, and the roadmap slips.
• Stakeholder disengagement: A TOM designed by a small team and announced to the organisation will be resisted. Co-design is not a consultation exercise; it is a design method that produces better outcomes and faster adoption.

One pattern worth naming: a UK professional services firm that redesigned its finance function without involving the finance team's operational leads produced a TOM that was technically sound but operationally unworkable. The process maps assumed system capabilities that did not exist and handoffs that the team had no capacity to execute. A six-week co-design cycle with the operational leads would have surfaced both issues before the blueprint was finalised.

Your immediate checklist to commission a TOM project

Act on these before your first vendor or internal briefing:

1. Appoint an executive sponsor with authority to make decisions on scope, resources, and escalations.
2. Commission a current-state diagnostic covering processes, systems, capabilities, and governance across the functions in scope.
3. Define success metrics at the outset: the two or three KPIs that will confirm the TOM has delivered its intended value.
4. Assemble a transformation team that includes operational leads, not just central strategy or IT.
5. Identify quick wins in the diagnostic that can be delivered within 90 days to build momentum and demonstrate value to the steering committee.
6. Prioritise TOM elements by programme trigger: cost reduction, digital change, M&A, or scale.

Sample executive brief (two lines you can adapt):

"We are commissioning a target operating model for [function/scope] to deliver [strategic outcome] by [date]. Success will be measured by [KPI 1], [KPI 2], and [KPI 3], with a phased roadmap reviewed by the steering committee monthly."

Invite to your first workshop: the executive sponsor, the heads of each function in scope, your HR director (for people and TUPE considerations), your CTO or head of technology, and at least two operational leads who know where the current model breaks.

What most leaders underestimate about TOM work

The programmes I have seen stall share a common pattern: the design was thorough, the framework was right, and the governance was documented. What was missing was a live connection between the model and the organisation's actual data.

A TOM built on a static PowerPoint blueprint starts degrading the moment the organisation moves. Headcount changes, system upgrades, process workarounds, and supplier shifts all alter the operating model in real time, but the blueprint does not update. Within six months, the steering committee is governing against a document that no longer reflects reality.

The question worth asking in your first executive meeting is not "which framework should we use?" It is: "How will we keep this model live once the design phase ends?" That question separates programmes that embed lasting change from those that produce a well-designed artefact that sits on a SharePoint drive.

The most durable TOMs I have encountered treat the model as an operating instrument, not a project deliverable. They connect the blueprint to real system data, real process performance, and real capability measures. That is the shift from TOM as a document to TOM as a management tool.

Oakandnine gives your TOM a live foundation, not a static blueprint

Most TOM programmes end with a well-structured document. Oakandnine starts where that document runs out.

Oakandnine's AI-driven platform connects your people, processes, and technology into a live operating model that updates as your organisation moves. Rather than a design artefact that becomes outdated within months, you get a continuously connected view of how your organisation actually works, where the friction sits, and which changes will move your margin and efficiency metrics. Backed by four decades of consulting experience, the platform turns the scattered data your organisation already holds into an integrated, queryable model that your transformation office can govern against in real time.

For mid-market leaders who need faster alignment, clearer roadmaps, and measurable results without a multi-year consulting engagement, Oakandnine offers a pilot deployment that produces a live operating model within weeks. Map and optimise your organisation to see how the platform works for your specific transformation context.

Sources

• Target operating model
• What Is a Target Operating Model? A Practical Guide | Starkhorn
• Is your company actually set up to support your strategy? | HBR
• Operating model | Opex Society

Recommended

• Oakandnine — Map and optimise your organisation
• Benefits of AI in business operations: a mid-market guide
• Improve margin strategy for mid-market leaders
• How to Improve Operational Efficiency in Business