Target operating model: a practical two-site example

A target operating model describes how an organisation intends to run its work to deliver a chosen service or outcome. It connects processes, decision authority, people, data, technology and measures. A software diagram or a new organisation chart describes only part of it.

Two sites use the same order system. One promises a delivery date after checking available stock. The other phones production and types in a date manually.

Installing the same screen at both sites has not created a shared promise customers can rely on.

Start with the service the model must support

In this fictional distributor, customers can order products from either site. The company wants one understandable promise: a confirmed delivery date based on available supply, transport and the relevant release checks.

That choice raises operating questions. May each site define “available” differently? Who approves a promise that depends on unfinished production? Who contacts the customer if the date changes?

MIT CISR's public introduction to operating models highlights decisions about process standardisation and integration. The point here is to decide what the two sites must share, rather than assuming either complete centralisation or complete local freedom.

Compare the current and target ways of working

The team follows a real task through each site before drawing the target. Here is the fictional record it produces.

Decision or activity	Current practice	Target for this service
Check usable stock	Different local definitions	One definition excluding held and already allocated stock
Promise against future production	Informal phone agreement	Capacity and material check with recorded approval
Select the local loading slot	Local team knowledge	Remains a local decision within the confirmed transport plan
Resolve an intersite stock conflict	Competing emails	Named allocation owner with a documented priority rule
Notify a customer of a changed date	Depends on who notices	Order owner receives the exception and confirms the update

The target standardises the evidence behind the promise while retaining local loading decisions. Those are deliberate boundaries. A demand for “one process everywhere” would avoid the discussion about which differences are useful.

Connect the operating-model parts around one order

Take an order for 50 units. Site A has 30 usable units. Site B has another 20, but those have already been allocated to a different customer.

Under the new rule, the order cannot be promised from the apparent 50-unit physical total. The allocation owner must decide whether an approved reallocation is possible or whether new supply is needed. The available-to-promise and capable-to-promise note explains those different supply checks.

Several parts of the model now have to agree. The process needs the allocation step. The responsible people need authority and cover when absent. The data must distinguish physical stock from usable, uncommitted stock. The system must show that distinction and keep the decision record.

A measure should then show whether the confirmed date was met, using the agreed definition. Otherwise, a local team could improve its own dispatch statistic while the customer still receives an incomplete order.

Keep a capability map and a RACI in their proper roles

A capability map shows what the business needs to be able to do, such as allocate stock or confirm an order. The operating model explains how those capabilities will work together in this service.

A RACI matrix can record responsibilities. It will not, on its own, define the availability rule, the information shared or the handling of an absent decision owner.

There is no universal number of operating-model pillars that settles these choices. Use a structure that exposes the decisions the organisation needs to make and leaves the resulting work understandable.

Test the target before calling it implemented

Walk the 50-unit order through the proposed model, including the stock conflict and a missing approver. Check whether the people doing the work can identify the current status, the next decision and the customer contact.

Then trial a bounded scope with training, data and support in place. Compare the service result with the baseline and inspect the workarounds. A clean process map does not show whether people can use the model during a busy shift.

The BPM example covers ongoing process ownership and review. The target model needs that continuing management after the transformation project ends.

For the two sites, a useful outcome is a promise made from the same evidence, with a clear route when that evidence is insufficient. Buying another screen should follow that decision.

Source and example notes

• MIT CISR: Defining digital operating models. Public introduction on standardisation and integration.

All site practices, quantities and target decisions are fictional. The table illustrates one service design rather than a complete organisation-wide operating model or a universal framework.