Operating Model Design: Match Four Models to a Staged Plan for Leaders
An operating model defines how your organisation arranges capabilities, processes, people and technology to turn strategy into repeatable outcomes. Choosing one deliberately prevents the rework that comes from building the wrong processes for the wrong purpose. The choice rests on two diagnostic axes, standardisation and integration, which combine into four distinct models we unpack below.
TL;DR:
- Score process standardization and integration independently: units can follow identical workflows without sharing data, so one combined maturity score can misdirect investment.
- Choose technology by quadrant: diversification favors local systems, coordination needs integration and master data, replication benefits from templates, and unification requires shared platforms.
- Unification is not a maturity target; it can impose the highest implementation cost, while separate divisions or functions may need different models.
- Assess current data flows, set scope, score both axes, then define capabilities and a roadmap; establish ownership, decision rights, metrics, and escalation paths before technology build.
Table of Contents
- What is an operating model, and how does it differ from a business model?
- The two diagnostic axes and four operating-model archetypes
- A step-by-step operating model design workflow
- Key principles of effective operating model design
- Implementation checklist: people, process, technology and governance
- Which scope should you apply each model at?
- Why we built our method around staged delivery
- How we help you design and embed your operating model
- FAQ
- Sources
What is an operating model, and how does it differ from a business model?
A business model describes what you do and why it creates value: your customers, your offer, your revenue logic. An operating model describes how you deliver that value reliably, day after day.
The components you design are consistent across sectors: capabilities, processes, people, technology, governance and metrics. Get these wrong and your business model stays theoretical. Get them right and strategy becomes something your teams can actually execute without reinventing the approach each time a new initiative lands.
This distinction matters most in technology and process investment. Without an explicit operating model, every project team makes its own call on what to standardise and what to leave local, which is how organisations end up with multiple versions of the same workflow and no shared data to show for it.
The two diagnostic axes and four operating-model archetypes
Jeanne Ross, Peter Weill and David Robertson, in work later published through Harvard Business School Publishing, set out two axes that determine your operating model: business process standardisation (do units run the same process the same way) and business process integration (do units share data and transactions across boundaries). Plotting these axes against each other produces four models, each with its own practical implication, as explained by MIT Center for Information Systems Research.
- Diversification: low standardisation, low integration. Business units operate independently with different customers and processes; IT spend should stay local and lightweight rather than forcing shared infrastructure.
- Coordination: low standardisation, high integration. Units share customers or data but run different processes, so the investment priority is integration platforms and master data management.
- Replication: high standardisation, low integration. Units run near-identical processes with little shared data, the classic franchise pattern, so template systems and repeatable deployment tooling matter most.
- Unification: high standardisation, high integration. Processes run on a shared platform, which can deliver tight control but may be expensive and disruptive to implement.
Each quadrant implies a different answer to “where do we spend”, and conflating the two axes is the most common reason organisations pick the wrong target.
A step-by-step operating model design workflow
Designing an operating model works best as a sequence rather than a workshop exercise. Here is a practical order leaders can follow:
- Assess the current state. Map your key outcomes to the processes and data flows that actually produce them, including where data breaks down between teams.
- Choose the design scope. Decide whether you are designing for the whole enterprise, a division, a product line or a shared-services function, since each can sit in a different quadrant.
- Score the two axes separately. Rate standardisation and integration independently for the scope you chose, then locate the target quadrant rather than assuming one.
- Design the capability map. Decide which capabilities and processes should be standardised enterprise-wide, which stay local, and where data needs to flow across boundaries.
- Build a pragmatic roadmap. Sequence foundational investments, governance fixes and early quick wins, each tied to a measure that tells you whether the change is working.
This sequence keeps the diagnostic honest: you score before you design, and you design before you build, which avoids the common trap of buying a platform first and discovering the target model afterwards.
Key principles of effective operating model design
A handful of rules separate operating model work that sticks from work that gets quietly shelved.
Treat the four-model framework as diagnostic, not a maturity ladder. Unification is not automatically “better” than Diversification; it fits certain value-creation patterns and not others, and MIT CISR’s research notes that many organisations aim for Unification despite it being the costliest model to implement.
Score integration and standardisation separately rather than bundling them into one “maturity” number, since a business can be highly standardised without sharing any data at all. Align your IT and data spend to the quadrant you are actually targeting, not the one that looked impressive in a strategy deck, a point Microsoft Learn’s operating model overview makes directly about where investment should focus. Finally, clarify decision rights and governance early, before the technology conversation starts, because unclear ownership is what turns a sound design into a stalled rollout.
Implementation checklist: people, process, technology and governance
Translating the design into delivery means working through several areas in parallel.
- People: define roles and decision rights for the new model, run a capability-gap assessment against what the target quadrant demands, and plan training or hiring to close it.
- Process: decide explicitly which processes become standardised enterprise-wide and which stay local, then assign named process owners for each.
- Technology: identify the master-data needs, integration platforms, template systems or APIs that your chosen quadrant actually requires, not a generic technology wish list.
- Governance and metrics: set outcome metrics, escalation paths and a feedback cadence so the model can evolve as the business changes.
Pro Tip: Start governance and metrics before the technology build, since a platform with no escalation path or ownership tends to drift back to the old, uncoordinated way of working over time.
Readers building this out in stages often find it useful to see how a business operating system comes together across several parts, and how RevOps alignment work sequences governance before efficiency gains, both of which echo the order above.
Which scope should you apply each model at?
An organisation can legitimately sit in different quadrants at different altitudes. A group holding company might run Diversification at the enterprise level while a shared-services finance function underneath it runs Unification, and a retail division runs Replication across its stores.
Run the diagnostic separately for the group, each division and each shared-services function rather than forcing one answer across the whole organisation. As a rule of thumb: favour Unification when you need predictable, end-to-end service with tight control; favour Replication when you are scaling a repeatable format across many similar units; favour Coordination when units need shared customer or data visibility but genuinely different processes; and favour Diversification when units create value in fundamentally different ways and forcing shared infrastructure would only slow them down.
Why we built our method around staged delivery
We built our staged Build, Iterate, Optimise, Embed and Grow approach because the steps above only create value once they are resourced and sequenced, not just diagrammed. The foundation stage and early governance fixes can help a well-designed model avoid drifting back into ad hoc working.
— Chris
How we help you design and embed your operating model
We work through a staged process, Build, Iterate, Optimise, Embed and Grow, that takes you from a launch-ready foundation to ongoing managed capability, rather than leaving you with a framework diagram and no delivery path.
A starter engagement typically produces a working foundation on a practical timeline, a practical roadmap sequenced the way this guide describes, and a clear next stage once the first wins are banked. If you are weighing up tools to support the integration and shared-data work a Coordination or Unification model demands, platforms such as Betterpresence are worth knowing about for automating document and compliance workflows. For your operating model itself, book a discovery call and we will map out where your foundation stands today and what the next stage should look like.
FAQ
What are the four types of operating models?
The four models, set out by Ross, Weill and Robertson, are Diversification, Coordination, Replication and Unification, generated from two axes covering process standardisation and process integration, as detailed by Harvard Business School Publishing. Each implies a different pattern of shared data and shared process across business units.
What are the three main principles of the operating model?
Definitions vary, but useful principles include deciding what runs the same way across the organisation, what shares data across boundaries, and how the model keeps delivering value as conditions change. These map closely to the diagnostic axes used in the four-model framework.
What is the difference between an operating model and organisational design?
An operating model covers how capabilities, processes, data and technology combine to deliver outcomes, while organisational design focuses specifically on reporting lines, team structures and roles within that model. Organisational design is one input into an operating model, not a substitute for it.
What should an operating model contain?
At minimum, an operating model should define your core capabilities, the processes that deliver them, the people and decision rights involved, the technology and data flows that support them, and the governance and metrics that keep it on track. The Wikipedia entry on operating models summarises these as the standard components practitioners expect to see.
Sources
- Center for Information Systems Research
- Diversification, Coordination, Replication, and Unification | Microsoft Learn