Target Operating Model: A Practitioner's Guide to Designing One

Key Takeaways

• A Target Operating Model describes future-state capabilities, processes, structure, technology, data, and governance — not just an org chart or a systems diagram.
• Capabilities, not org structure, should anchor TOM design, because what the business needs to do changes far more slowly than who does it.
• Designing a TOM is a bounded exercise; implementing it is a multi-year program with its own roadmap and governance.
• The transition roadmap deserves as much rigor as the target-state design — most TOM efforts stall in the gap between current and future state, not in the design itself.
• A TOM that never gets revisited becomes as stale as the organic operating model it replaced; treat it as a living reference, not a one-time deliverable.

What a Target Operating Model Is (and Isn't)

A TOM describes a future state across six dimensions in enough detail to guide investment decisions — it is not a slogan, a single diagram, or a restated strategy.

The difference between a strategy and a TOM is the difference between a destination and a route. A strategy states what the organization is trying to achieve — enter a new market, cut cost-to-serve, shift to a subscription model. A TOM describes how the organization will be structured and run to get there: which capabilities need to exist or improve, how work will flow end to end, who has decision rights, what technology underpins the work, and how performance gets measured along the way. It's also worth separating three terms that get used loosely. A business model describes how the organization creates and captures value — subscription versus one-time sale, direct versus channel. An operating model describes how the organization is run today. A target operating model describes how it intends to be run at a defined point in the future. All three matter, but only the TOM is a design artifact meant to change what currently exists.

The Six Dimensions a TOM Has to Cover

Most operating model failures trace back to one dimension being ignored while another gets all the attention — usually technology, at the expense of governance or capability.

Treat these as interdependent, not sequential — a governance change without a matching process change just moves the bottleneck somewhere else.

1. Business capabilities — the abilities the organization needs to execute the strategy, described in terms of what the business does, not who does it or how.
2. Processes — the end-to-end workflows that turn capability into delivered outcomes for a customer or internal user.
3. Organizational structure — roles, teams, reporting lines, and the location and sourcing strategy behind them.
4. Technology and infrastructure — the platforms and systems that enable and automate the work.
5. Data and information — the data assets and governance practices that make decisions possible in the first place.
6. Governance and decision rights — who decides what, how performance gets measured, and how the model itself gets changed.

Signs an Operating Model Has Drifted Out of Alignment

None of these on its own means an organization needs a formal TOM effort. Several at once points to an operating model that has fallen behind the strategy it's meant to support.

• Strategy and day-to-day operations tell two different stories, and no amount of project management closes the gap.
• A merger or acquisition left duplicate functions and conflicting processes that were never fully integrated.
• Customer experience is inconsistent across channels, because each channel effectively runs its own operating model.
• Technology spend keeps rising without a matching improvement in business outcomes.
• Decisions are slow because ownership is unclear and most things end up escalated to the executive team.
• A major transformation is planned, with a real risk of automating the current mess rather than a better version of it.

Building a TOM: A Six-Phase Approach

TOM design is a bounded project — typically a couple of months for the design itself — followed by a much longer implementation program. The six phases below are one workable sequence; the names matter less than doing each step deliberately.

1. Strategic alignment and scoping — confirm the strategic objectives the TOM needs to serve, decide whether it's enterprise-wide or a single business unit, and name who governs the effort.
2. Current-state assessment — map today's operating model across all six dimensions, and be explicit about what's already working; not everything needs to change.
3. Future-state design — define target capabilities, redesigned processes, structural options, technology direction, and governance for each dimension.
4. Gap analysis and prioritization — compare current to target state dimension by dimension, and rank the gaps by strategic importance and how hard they are to close.
5. Transition roadmap — sequence the work into waves with real milestones, owners, and dependencies; this is where most of the actual risk in a TOM program lives.
6. Implementation and iteration — execute in waves, track a small set of KPIs tied to the strategy, and revisit the target state as conditions change.

From Current State to Target State

The comparison that matters isn't current versus target in the abstract — it's the specific gap in each dimension, because that gap is what determines where investment needs to go.

A current operating model is usually the byproduct of years of organic growth, acquisitions, and decisions made under deadline pressure rather than a deliberate design — capabilities duplicated across units at inconsistent maturity, processes that work well within a department but fragment end to end, technology carrying real technical debt, and decision rights that default to committee because no one formally owns them. A target operating model doesn't have to fix every one of these to be useful; it has to say, dimension by dimension, what 'good' looks like and how far the organization currently is from it. The size of that gap, not the elegance of the target-state diagram, is what should drive where the transformation budget goes first.

Anchoring the Design in Business Capabilities

Starting TOM design with the org chart tends to produce a reorganization that feels like change but leaves the underlying work unchanged. Starting with capabilities avoids that trap.

Capabilities describe what the business does — process claims, manage supplier relationships, price a policy — independent of who currently does it or what system supports it. That makes them a more stable anchor than an org chart, which shifts with every leadership change, or a technology roadmap, which shifts with every vendor renewal. A capability-based TOM design follows a simple logic: identify the capabilities the strategy actually depends on, assess how mature each one is today, define the maturity it needs to reach, and only then design the process, people, technology, and governance changes required to close that specific gap. A useful, low-tech way to prioritize is to rank each capability by how strategically important it is, how large the current-to-target gap is, and how much implementation risk closing it carries. A capability that's central to the strategy with a wide gap and manageable risk should get funded ahead of one that's easier to fix but marginal to the strategy — even though the easy one looks more attractive on a project plan.

• Core capabilities directly deliver the value proposition — the things customers are actually paying for.
• Supporting capabilities enable the core ones without being differentiating on their own — HR, finance, IT infrastructure.
• Strategic capabilities shape direction — portfolio management, innovation, corporate development.
• Governance capabilities keep the rest under control — risk management, compliance, audit.

Where TOM Implementation Goes Wrong

A well-designed target state is not the hard part. Getting from here to there is.

• Trying to change every dimension at once instead of sequencing the work into waves with real breathing room between them.
• Designing a model that looks right on paper but conflicts with how the organization actually makes decisions day to day.
• Letting a technology purchase decide the operating model, rather than designing the model first and picking technology to fit it.
• Designing in isolation, without the people who will actually run the new model in the room.
• Launching without a small set of KPIs that would tell you, within a quarter, whether the new model is working.
• Treating the TOM as a finished deliverable instead of a reference that gets revisited as strategy and market conditions change.

Choosing a Framework to Structure the Work

None of the established frameworks are mandatory, and the right choice depends more on what your stakeholders will actually use than on which is theoretically most complete.

The Business Architecture Guild's BIZBOK provides the most complete method for capability and value stream mapping, and suits organizations with a dedicated business architecture practice that can invest in the up-front modeling. The Operating Model Canvas is a lighter, visual approach better suited to a single business unit or a team that needs quick alignment without a heavy methodology. TOGAF, from The Open Group, and its modeling notation ArchiMate extend naturally into operating model work for organizations that already run a mature enterprise architecture practice and want the TOM to plug into that existing structure. None of these is wrong; the mistake is spending more time choosing a framework than using one.

Frequently Asked Questions

Q: How long does it take to build a Target Operating Model? A: The design phase — current-state assessment through transition roadmap — typically takes a couple of months for a single business unit and longer for an enterprise-wide effort. Implementation, in contrast, usually runs across multiple years in waves. Q: Who should own a TOM effort? A: Ownership needs an accountable executive sponsor and a cross-functional steering group; a TOM designed solely by an architecture team without business ownership tends to sit on a shelf. Q: Is a Target Operating Model the same as an org design project? A: No. Org design is one output of TOM work — it addresses the organizational-structure dimension — but a TOM also covers capabilities, process, technology, data, and governance, and org changes made without the other five tend not to stick. Q: How often should a TOM be updated? A: Treat it as a living reference: revisit it on a fixed cadence, such as annually, or immediately after a material shift in strategy, market conditions, or a major acquisition. Q: What's the biggest risk in a TOM program? A: Underinvesting in the transition roadmap. The target-state design gets the attention; the sequencing, ownership, and change management needed to actually get there is where most programs lose momentum.

Pro Tips

• Start with capabilities, not the org chart. Naming what the business needs to do, before deciding who does it, keeps the design honest when reorg politics show up later.
• Sequence the rollout instead of redesigning everything at once. A TOM that tries to change every dimension in parallel usually stalls; pick the one or two dimensions with the widest current-to-target gap and start there.
• Assign a name to every decision right in the governance section — decision rights that are implied rather than assigned tend to default back to committee.
• Revisit the TOM on a fixed cadence, such as annually or after a material strategy shift, rather than waiting for it to visibly break.