Operating Model Design: The Five Lens Review
Most operating model reviews start in the wrong place. They open the cost base, find a number the board would like to be smaller, and work backwards to a structure that delivers it. The result is a set of cuts dressed up as design, with the rationale written afterwards. Staff recognise that pattern immediately, and they resist it.
Good operating model design runs the other way. It starts with what a function is for, reads what actually arrives at its door, follows how the work really gets done, and only then asks what it costs. Intology's Five Lens Function Review is the diagnostic method we use to do that, one function at a time, with the same lenses, stages and artefacts every time. The aim is simple: the second review should cost less than the first, and your own people should be able to run the third.
Why most operating model reviews produce cuts, not design
A cost-first review has an internal logic that is hard to escape once it starts. A savings target is set. A structure is drawn to hit it. Evidence is then gathered to support the structure. By the time anyone asks what the function is for, the answer has already been decided by the spreadsheet.
Three things go wrong as a result.
- The answer cannot be defended. When a redesign is challenged by staff, employee representatives or the board, "it hits the number" is not a defence. "It serves the purpose, handles the real demand and removes work that should never have existed" is.
- Restructure by org chart. Boxes and lines are the most visible part of an operating model and the least important. Moving them without changing decision rights, demand or process simply relocates the same problems.
- Nothing is repeatable. Each review is a bespoke exercise, run by whoever was available, producing a report nobody can reuse. The organisation learns nothing it can apply to the next function.
The Five Lens method is designed to fix all three.
The five lenses, in order
Every function is examined through the same five lenses. Each lens asks one question and produces one named artefact, so the client can picture the work before it starts and compare functions like for like once it is done.
| Lens | The question | What it produces |
|---|---|---|
| 1. Purpose | What is this function for, who is its customer, and what breaks if it stops tomorrow? | Function charter: purpose, customers, services and boundaries |
| 2. Demand | What actually arrives: volumes, sources, peaks, and how much is failure demand created upstream? | Demand profile, with avoidable demand quantified |
| 3. Work | How is the work really done end to end, including workarounds and spreadsheets? | As-is process maps with pain points and handoffs marked |
| 4. Capability | People, skills, spans, systems and data. Who decides what, and where do decisions queue? | Decision rights matrix and capability gaps |
| 5. Cost and value | What is the cost to serve, the cost per unit of demand, and the value returned? | Cost to serve baseline, read against lenses 1 and 2 |
The order is the method. Cost is read last so that it is judged against purpose and demand, not the other way round.
Purpose: what breaks if it stops tomorrow?
Many functions have never written down what they are for. The function charter forces the question, names the internal and external customers, and sets the boundaries with neighbouring functions. Disagreements surface here, early and cheaply, rather than in the middle of a restructure.
Demand: finding the failure demand
Failure demand is work caused by a failure to do something, or to do it right, somewhere else: the chasing call, the rework, the query about an unclear letter, the correction to data entered wrongly upstream. In many functions it is a large share of total volume, and it is invisible until someone counts it. Quantifying avoidable demand often changes the conversation entirely. The question stops being "how many people do we need?" and becomes "why are we creating this work at all?"
Work: how it is really done
Documented processes and real processes are rarely the same thing. The as-is maps capture the workarounds, the personal spreadsheets and the handoffs where work waits. These are usually where cost, delay and risk concentrate.
Capability: where decisions queue
A decision rights matrix shows who decides what, and more importantly where decisions stall waiting for someone with authority. Queued decisions are one of the most reliable signs that a structure is wrong, and one of the cheapest things to fix.
Cost and value: read last, on purpose
Only now is cost examined, as cost to serve and cost per unit of demand. Read against the charter and the demand profile, a cost baseline tells you where money is creating value and where it is absorbing failure demand. That is an analysis a board can act on and defend.
Five stages: Frame, Evidence, Compare, Design, Embed
The lenses define what is examined. The stages define how the work runs. If you are designing a target operating model across several functions, this is the sequence we repeat for each one.
- Frame. Agree the questions the redesign must answer, the success measures, what is out of scope and what is already decided. Most failed reviews skip this and discover halfway through that the sponsor wanted a different answer.
- Evidence. Gather data and map processes across all five lenses. Data quality is itself a finding: if a function cannot tell you its own volumes, that tells you something important, and it gets reported.
- Compare. Benchmark internally first, across your own regions, sites or services, because that comparison is like for like. Use external comparators only where credible ones exist.
- Design. Principles first, then decision rights, then options, then structure. In that order and never the reverse.
- Embed. Hand over the method, the artefacts and the templates so your team can run the next function themselves. This is the Embedded Change Model™ applied to operating model design.
The Design Table: five workshops with the people who do the work
Evidence alone does not produce a design that people will accept. The design is built in a structured series of five workshops we call the Design Table, each with a defined room, length and output.
| Session | Who is in the room | Length | Output |
|---|---|---|---|
| DT1. Purpose and demand | Function lead and their team | 90 minutes | Function charter and demand profile |
| DT2. Process reality | The people who do the work, not only managers | Half day | As-is map, pain points, failure demand |
| DT3. Principles and decision rights | Executive and function leads | Half day | Agreed design principles and decision rights matrix |
| DT4. Target design options | Function leads plus service representatives | Half day | Two or three options tested against the principles, with a recommendation |
| DT5. Challenge and commit | Sponsor, executive, and Intology as independent challenge | Half day | Decisions logged, risks named, sequence agreed |
The four rules of the room
- Evidence in the room. No assertion without data. Where there is no data, that absence is a finding and is recorded as one.
- Titles at the door. The person who does the work outranks the person who describes it.
- Design before structure. No boxes and lines until principles and decision rights are agreed. Structure is drawn last.
- Every decision logged, with its owner and its date. The log becomes the audit trail for the executive and the board.
Where independent challenge belongs
Almost every consultancy claims to offer challenge. In practice it is often a tone of voice sprinkled through the work as opinions. In the Five Lens method, challenge is a named role with a defined place and a defined audience.
- It has a place. Challenge is strongest at DT5 and at each stage gate, where Intology tests the design against the evidence and says plainly where it does not hold.
- It has an audience. Usually the sponsor, the executive team or the board. Establishing who the challenge is for before scoping the work matters, because it shapes the reporting.
- It requires independence. Intology has no software to sell and no implementation arm to protect. A firm whose delivery practice stands to win the follow-on work cannot credibly tell you the design does not need it. We explore this further in whether independent advisors can challenge your transformation plan.
Honest positions on benchmarking and process mapping
Two positions are worth stating early, because they build more credibility than any promise of a rich benchmark library.
External benchmarks are thinner than most proposals suggest. In many sectors, credible external comparators are scarce and rarely like for like. Internal benchmarking across your own regions and services usually carries more weight with a board, because nobody can argue that the comparison is unfair.
Undocumented processes need a discovery step first. If process mapping is in scope, the as-is is usually not documented. A short data discovery should come before anyone commits to an analysis timescale. Committing to dates before you know the state of the data is how reviews overrun.
Above all, your people own the answer. Intology provides the method, the evidence and the challenge. That division of labour is what makes a design survive after the consultants leave, and it is the same principle behind our view on team augmentation versus embedded change.
Frequently asked questions
What is failure demand, and why does it matter in operating model design?
Failure demand is work created by a failure elsewhere: chasing, rework, corrections and repeat contacts. It matters because sizing a function on total demand bakes that waste into the new design. Quantifying avoidable demand first means the redesign removes work rather than simply reallocating it.
Should a functional review start with cost?
No. Starting with cost produces a savings target, then a structure to meet it, then a justification written afterwards. Reading cost last, against purpose and demand, produces a design that can be defended to staff, employee representatives and the board, and it usually finds savings a cost-first review misses.
How long does a function review take?
It depends on the size of the function and the state of its data. The Design Table itself is five sessions, one of 90 minutes and four of a half day. The larger variable is evidence gathering, which is why a short data discovery comes before any analysis timescale is committed.
Is internal or external benchmarking more reliable?
Internal benchmarking is usually more reliable and more persuasive, because comparing your own regions, sites or services is like for like. External comparators are useful where credible ones exist, but in many sectors they are thin and hard to match to your context.
Who should own the operating model design, the consultant or the organisation?
The organisation. The consultant should bring the method, the evidence and the independent challenge, and then hand over the artefacts and templates so the next function can be reviewed in-house. A design owned by the consultant tends to leave with the consultant.
Talk to us
If you are planning a functional or operating model redesign and want a method your organisation can repeat, rather than a one-off report, arrange a confidential conversation with a senior Intology consultant. You can also read more about our wider independent business transformation work.