Target Operating Model (TOM) Design for Established Companies

What a Target Operating Model actually is

A Target Operating Model (TOM) is a concrete description of how a company will run in order to deliver its strategy — the processes it will perform, the capabilities it will need, the way it will be organized, the systems and data it will rely on, and the governance that holds it together. It is not an org chart, and it is not a strategy deck. It sits between the two.

The current operating model is whatever the company has ended up with: a mix of legacy structures, informal habits, tools bought at different points, and reporting lines drawn around people rather than work. The target is the version the leadership team has decided, in writing, is fit to deliver the next three to five years of the strategy. The gap between the two is the design problem an operating-model engagement exists to solve.

When companies need a new operating model

Established companies rarely commission an operating model out of curiosity. It is almost always triggered by a specific event: a new strategy the current organization visibly cannot deliver, a merger or acquisition, a shift from product-led to platform-led, a change from single-country to multi-country, or a stall in growth that the leadership team can no longer attribute to a single function. In each case the underlying signal is the same — the way work moves through the company is now the bottleneck, not the market.

The six layers of an operating model

A working TOM has six layers. Each layer answers a specific question, each is designed in sequence, and each produces an artefact that the next layer depends on. Designing the layers in a different order — or, more commonly, designing the organizational chart first and reverse-engineering everything else — is the single most reliable way to produce an operating model that nobody follows.

1. Strategic intent

The design starts with strategy, restated in operating terms. What is the company trying to be distinctively good at? Which customer segments and channels does that require? Which outcomes must the operating model over-serve, and which is it allowed to be merely competent at? A useful strategic-intent artefact is one page: no more than five operating implications, each attributable to a specific strategic choice.

2. Value chain and capabilities

The value chain describes, end to end, how the company creates and captures value — from market insight through delivery and after-sales. Underneath the value chain sits a capability map: the discrete things the business must be able to do (for example, "manage strategic accounts", "operate a regulated product recall", "underwrite a new market"). Capabilities are technology-agnostic, structure-agnostic, and named as verbs. Each is rated on how differentiating it is to the strategy and how mature the business is in it today. That two-axis view drives every subsequent design decision.

3. Process architecture

Processes are the concrete flows of work that realize the capabilities. A useful process architecture has three levels: the core processes that create value for customers, the enabling processes (finance, HR, IT, legal) that make the core possible, and the management processes that plan and control the whole system. Each process has a named owner, a set of inputs and outputs, and clear handoffs to adjacent processes. Handoffs are where operating models fail; they deserve as much design attention as the boxes.

4. Organization and roles

Only now is it possible to design the organization. The structure follows the process architecture, not the other way round. The design specifies units, spans of control, the depth of the hierarchy, and the split between line and functional accountability. Each role has a written charter: purpose, decisions it owns, decisions it contributes to, and the KPIs it is measured against. Where structure has to compromise (for example, a single leader carrying two capabilities that would ideally be split), the compromise is written down as a design decision, not left implicit.

5. Technology and data

Systems and data are the fifth layer, not the first. The design specifies the system of record for each key data object (customer, product, order, employee), the interfaces between systems, the flow of the master data through the value chain, and the boundary between what the business will buy and what it will build. Technology choices made before the process architecture is stable produce configuration debt that survives for years.

6. Governance and performance

The final layer is how the operating model holds together. It has three components: the decision-rights matrix that specifies who decides, consults, and is informed on the recurring decisions of the business; the operating cadence that schedules those decisions into a recurring rhythm of meetings; and the KPI system that reports whether the model is performing as designed. Without this layer, the previous five drift within a quarter.

The artefacts a design engagement produces

A TOM engagement should leave the company with a small, canonical set of artefacts. They are the operating model. Nothing else is.

• Strategic-intent statement — one page, signed off by the executive team.
• Value chain and capability map — one page each, with maturity and differentiation ratings.
• Level-1 process map — the core, enabling and management processes with named owners.
• Organization design — structure, roles, charters, and the design decisions behind them.
• Systems and data blueprint — systems of record, interfaces, and master-data flow.
• Governance pack — decision-rights matrix, operating cadence, KPI set.

Six artefacts, kept short, versioned, and owned. When a future decision has to be made against the operating model — a reorganization, a system replacement, a change in cadence — these are what it is checked against.

Common failure modes

Most operating-model designs that fail do so in one of the following ways.

• The org chart is designed first. Structure is decided before the process architecture, and the rest of the model is bent to fit the reporting lines.
• Capabilities are named as functions. "Marketing" and "Finance" appear on a capability map. Capabilities are cross-functional by definition; if they map one-to-one to the current org, the map is describing the past.
• The design is not decided. Multiple options are carried indefinitely because the executive team cannot agree. An undecided model is worse than a chosen imperfect one.
• Technology is chosen too early. A platform is selected before the level-1 process is stable, and the platform's structure becomes the operating model by default.
• No governance layer. The model is designed but no decision-rights or cadence are set, so the old habits of decision-making reassert themselves within a quarter.

A design sequence that holds

For an established company of roughly $20m to $1bn in revenue, we typically run the design over ten to fourteen weeks, sequenced as follows.

Weeks 1–3: intent and capabilities

Interview the executive team and the next layer down. Restate the strategy as operating implications. Draft the value chain and the capability map. Rate capabilities on differentiation and maturity. Present the shortlist of capabilities the operating model must over-serve. Get an executive sign-off on the intent artefact before moving on.

Weeks 4–7: process and organization

Design the level-1 process map with the process owners. Draft the organization design options — usually two — and test each against the capability priorities. Choose one. Write the role charters for the top two layers. Where trade-offs are made, record them as design decisions, not omissions.

Weeks 8–10: systems, data and governance

Overlay the current systems on the process map, identify the systems of record, and flag the interfaces that will need to change. Design the decision-rights matrix and the operating cadence — see our guide on the operating cadence for how those are built. Pick the KPIs and their definitions. Produce the governance pack.

Weeks 11–14: transition plan and handover

Sequence the moves from the current model to the target. Group them into no more than three waves. Assign each wave a sponsor, a milestone and a KPI it must move. The output is a transition plan the leadership team commits to, not a slide deck. The engagement closes when the first wave has an owner, a date and a budget.

Operating-model design vs. reorganization

Operating-model design is often confused with reorganization. They are not the same. Reorganization changes structure in isolation — reporting lines move, but processes, systems and governance do not. Operating-model design changes structure only after processes, capabilities and governance have been redesigned, and only to the extent that structure needs to change to serve them. In practice, a well-designed operating model often requires less structural change than the leadership team initially assumes, and more change to process ownership, decision rights and system boundaries.

When outside help is worth it

Operating models can be designed internally, and often are. Outside help is worth it in two situations. The first is when the leadership team is inside the current model — the conversation cannot be had cleanly without an external chair who can hold the design discipline. The second is when the design has to be produced quickly enough to precede a business event — a fundraise, an integration, a market entry — and internal capacity is already committed to running the current business.

Momentum IM runs operating-model engagements as design-and-implement, not advisory. We produce the six artefacts alongside the executive team, sequence the transition, and stay through the first wave of the rollout. Typical horizon is ten to fourteen weeks for the design and a further quarter to land the first wave.