A Target Operating Model defines how an organization will be structured, governed, and resourced to deliver on its strategy. It is the bridge between strategic intent and organizational reality — the design that tells you not just where you are going, but how the organization needs to be configured to get there.
What a TOM Actually IsMost organizations confuse a TOM with an org chart. The org chart is one small piece of it.
An org chart describes reporting lines. A Target Operating Model describes the full system by which an organization operates — its capability structure, governance model, processes, sourcing strategy, technology enablement, and the performance management framework that keeps it accountable to delivering outcomes. It answers six questions that an org chart cannot:
What capabilities does the organization need to have? How will decisions be made and by whom? Which activities will be done internally and which sourced externally? How will processes flow across organizational boundaries? What technology enables the operating model? How will performance be measured and managed?
A TOM that only addresses organizational structure has answered one of those six questions. Organizations that design only to the org chart level wonder why the restructuring did not produce the results it promised — because the other five dimensions were never redesigned to match.
"The operating model is the missing link between strategy and execution. Most strategies fail not because they were wrong, but because the organization was never redesigned to deliver them."
A recurring finding in post-transformation reviewsA complete TOM addresses all six dimensions — not just structure.
Each dimension is a design problem in its own right. The decisions made in each one constrain and enable the decisions in the others. A sourcing decision, for example, directly shapes organizational structure, governance requirements, and technology needs. Designing dimensions independently — as most organizations do — produces a TOM where the pieces do not fit together.
1. Capability Structure
Which capabilities the organization needs, at what level of maturity, and how they are organized and owned. This is the foundation — without a defined capability structure, every other dimension of the TOM is designed in a vacuum.
2. Organizational Design
How capabilities are grouped into organizational units, where decision authority sits, and how the structure enables rather than constrains the way work actually flows. This is where the org chart fits — as one output of the design, not the whole design.
3. Governance Model
How decisions are made, who makes them, and how accountability is established and enforced. Governance is the operating system of the operating model — without it, structure without governance produces organizational drift.
4. Sourcing Strategy
Which capabilities are delivered internally, which are shared across business units, and which are sourced externally. Every sourcing decision has organizational, process, technology, and governance implications that must be designed accordingly.
5. Process & Information Flow
How work moves across the organization — including across the boundaries that the org chart creates. Process architecture at the TOM level is concerned with cross-functional flows, handoffs, and information requirements, not individual task steps.
6. Technology Enablement
What technology the operating model requires to function — not a system inventory, but a view of which capability areas need technology investment and what characteristics that technology must have to support the operating model design.
Six steps. Each one depends on the one before it.
TOM design is not a linear process in practice — there is iteration between dimensions as design decisions in one area surface constraints in another. But the sequence below reflects the logical dependencies that must be respected. Getting the order wrong is one of the most common reasons TOM efforts stall.
Establish the Strategic Context
The TOM must be anchored to a specific strategy. Before any design work begins, the strategic intent must be clearly defined — what the organization is trying to achieve, over what time horizon, and what constraints (financial, regulatory, organizational) bound the design. A TOM designed without a clear strategic anchor produces an operating model optimized for the present, not the future. This step also includes a current-state assessment: how is the organization currently configured, where are the gaps against strategic requirements, and what does the operating model need to change to close them?
Define the Capability Requirements
What capabilities does the target operating model require? This is where a business capability model becomes indispensable. The capability model identifies what the organization needs to be able to do — which existing capabilities need to be strengthened, which need to be built, which can be rationalized or sourced externally. Without this step, organizational and process design decisions are made without a clear view of what the organization actually needs to be able to do in the target state.
Design the Sourcing Model
For each capability area, determine whether it will be delivered internally, shared across business units, or sourced externally. This is one of the most consequential design decisions in a TOM because it shapes everything that follows — org structure, governance, process design, and technology requirements all change significantly depending on how a capability is sourced. Sourcing decisions should be driven by strategic importance, scale, competitive differentiation, and operational risk — not by cost alone.
Design the Organizational Structure and Governance
With capability requirements and sourcing decisions established, design the organizational structure that will own and deliver those capabilities — and the governance model that will make it function. Org design at this stage is capability-driven: which capabilities need to be co-located to enable effective collaboration, which need to be separated to maintain accountability, and where shared services or centers of excellence are the right model. Governance design defines decision rights, escalation paths, performance management cadences, and the accountability framework that keeps the structure functional.
Map the Process and Information Architecture
Define how work flows across the organizational structure — paying particular attention to cross-functional handoffs, which are the most common source of operating model friction. At the TOM level, process design is concerned with end-to-end flow across capability areas, not individual task steps. Information architecture identifies what data and reporting each part of the operating model needs to function and how that information moves across organizational boundaries.
Define the Technology Enablement Model and Transition Roadmap
Identify the technology requirements the operating model creates — not as a system shopping list, but as a view of which capability areas require technology investment and what those systems need to do. This feeds directly into technology roadmap and application rationalization planning. The final output of TOM design is a sequenced transition roadmap: how does the organization move from its current configuration to the target model, in what order, with what dependencies, and against what timeline? The roadmap must be sequenced to deliver early operating model improvements rather than deferring all value to a distant target state.
TOM efforts fail in predictable ways. Most of them are avoidable.
Designing the org chart first
Organizational structure is the most visible dimension of a TOM, so it tends to get designed first — before capability requirements, sourcing decisions, or governance are established. The result is a structure designed in a vacuum that has to be retrofitted to the operating model requirements it should have driven. Restructuring that begins with the org chart almost always has to be partially redone once the other dimensions surface constraints the chart did not account for.
No capability foundation
The TOM is designed without a validated capability model. Organizational and process design decisions are made based on how the business currently describes itself — by function, by department, by product line — rather than by what the organization actually needs to be able to do. The resulting operating model reflects the current structure with modifications, rather than the structure the strategy requires.
Governance treated as an afterthought
Governance is designed last, lightly, or not at all — added to the TOM as a set of committee names and meeting cadences rather than as a functioning decision-making system. Operating models without real governance drift back toward the old ways of working within 12 to 18 months as day-to-day decisions accumulate outside the new structure's intent.
No transition roadmap
The TOM describes the target state in detail but provides no sequenced path from the current state to the target. Without a transition roadmap, implementation becomes a project management problem with no architectural grounding — decisions about sequencing, dependencies, and trade-offs get made by whoever is closest to the work rather than by whoever understands the operating model design.
Designed without frontline input
The TOM is designed by leadership and consultants, validated with leadership, and handed to the organization for implementation. The people who know how work actually flows — where the real handoffs are, where the process friction lives, where the governance breaks down — were not in the room. The result is a target state that looks coherent on paper and breaks in practice at the exact points the frontline could have predicted.
Not every operating model problem requires a full TOM. Know which one you need.
A full Target Operating Model design is the right tool when the strategic change is significant enough to require redesigning multiple dimensions of how the organization operates — capability structure, governance, sourcing, process, and technology together. If you are integrating two organizations post-merger, entering a new market, executing a major digital transformation, or restructuring in response to a fundamental shift in strategy, you need a TOM.
If the problem is more contained — a single function underperforming, a specific process that needs redesign, a governance gap in one business unit — a targeted intervention in that dimension is more appropriate than a full TOM exercise. The overhead of a full TOM process is only justified when the scale of organizational change demands it.
The test is straightforward: if fixing one dimension of your operating model without touching the others will produce the outcome you need, do that. If the dimensions are interdependent enough that fixing one without redesigning the others will just move the problem, you need a TOM.