Operating Model (Standardisation and Integration)

The idea

Jeanne Ross, Peter Weill and David Robertson at MIT CISR argued that strategy changes too often, and says too little, to guide IT. What does guide it is the operating model: the level of business process standardisation and integration the company needs to deliver to its customers.

Two questions give four models:

1. Diversification — low standardisation, low integration. Units run their own processes and share little data, as in a holding company of distinct businesses.
2. Coordination — high integration, low standardisation. Units share customers, products or data but keep their own ways of working.
3. Replication — high standardisation, low integration. Units run the same processes independently, as in a franchise.
4. Unification — high on both. One set of processes and shared data across the whole company.

In Enterprise Architecture as Strategy (2006) they define enterprise architecture as the organising logic for processes and IT that reflects these requirements. Choose the model, and the architecture follows.

Why it works

It is more stable than strategy. Strategies shift with markets and leaders; how a company wants its units to work together changes much less often. Architecture built on the operating model stays useful through several strategies.

It turns vague ambition into design constraints. "One customer view" means integration; "the same order process everywhere" means standardisation. Each has a different price and a different architecture.

It exposes the hidden choice. Many programmes fail because they quietly assume Unification in a business that runs as Diversification. Naming the model makes the gap a leadership decision, not a project surprise.

Where it applies

• Enterprise platform decisions, such as a single ERP, a shared CRM or a common data platform, which only pay off in some models.
• Mergers and acquisitions, where the question is whether the new unit is integrated, standardised, both or neither.
• Shared services and sourcing, where centralising a process only makes sense if it is meant to be standard.
• Governance and target-state roadmaps, where the model tells you which standards to enforce and where to allow local choice.

How to apply

1. Ask leadership, not IT. Put the two questions to executives: which processes must be the same, and which data must be shared.
2. Place the business, and its parts. Different levels can have different models: a group may be Diversified while each division is Unified.
3. Derive what must be common. List the shared data, processes and technology the model implies; that is your core.
4. Test current programmes against it. Flag any that assume more standardisation or integration than the model calls for, or less.
5. Revisit on big change. An acquisition, a new channel or a regulatory shift can move the business to a different model.

Example scenario

A retail group with five regional brands was two years into a single global ERP. Each region resisted the common processes, and the programme was over budget. The architecture team asked the board the two questions: the brands sold to different customers, shared few suppliers and wanted local pricing and assortment. That is Diversification with a little Coordination, not Unification.

The group stopped the single ERP. It kept a shared finance and reporting layer and a common supplier master, and let each brand run its own commerce stack within security and data standards. Spending fell, and the regions stopped treating architecture as an obstacle.

Questions to ask

When not to use it

• Single-unit companies, where there are no units to standardise or integrate across.
• Early-stage ventures still finding their market, where processes change too fast to decide yet how much to standardise them.

How it misleads you