Over the last year I have been going round in circles in my thinking about language.   I am convinced that the best place to start when doing operating model work is with a stakeholder map that helps identify the stakeholders of the organisation being designed and helps clarify what is in scope and what is out of scope and where the hand-offs will be.

The second step is to create a high-level process map of the main operating activities needed to deliver value to each customer segment that the organisation is trying to serve.   Of course, if the organisation is an internal function or a government department or a charity, then the “customer segment” is a group of similar beneficiaries or stakeholders.

On my course at Ashridge Business School, I refer to this high-level process map as a “value chain map“: typically it is limited to 4-8 steps for each “value chain”; and the map includes a value chain for each “segment” the organisation is trying to serve.   It is then possible to compare across the “value chains” to identify steps that can be combined, need to be linked or need to be kept separate – my CLS tool (combined, linked, separate).  There are other things that can been done with the “value chain map”.  It can be used to highlight the sources of advantage.  It can also be used to identify problem areas.

I then use the value chain map to create an organisation model.   The basic idea is that each value chain is a “unit” (business unit) in the high-level structure and “combined” activities become central functions (either “shared services” or “core resources” or …).  If large numbers of steps are combined, the organisation becomes just one value chain, with each operating step reporting up to the top.  Using the organisation model, I then add in “support functions”, like Finance, HR, IT, Legal, Strategy, etc.   These two outputs – the value chain map and the organisation model – are the core visuals of the operating model.  Other visuals include a location map, a process and IT ownership map, etc.

This approach differs from the approach used in Business Architecture which starts with a capability map.   Trying to understand the differences between my approach and the capability map approach has been causing me to go round in circles.

I have concluded that there are very few differences, especially if I change my language from “value chain” to “capability chain” or even “chain of operating capabilities required to deliver value to the customer”.  The difference is that a value chain map only focuses on the “chain of operating capabilities”.  It does not include any of the support capabilities (like Finance or Legal) or management capabilities (like Strategy or Performance Management).    A capability map often positions these management and support capabilities at the top of the map and the operating capabilities lower down.  In contrast, the value chain map focuses 100% on the operating capabilities.

I then use the “organisation model” as the tool for adding in the management and support capabilities.  The power of this tool is that it helps define the role that these management and support activities take with regard to the operating capabilities: are they shared services or policy capabilities or championing capabilities or core resources?

In my not very humble view the “capability chain” plus “organisation model” approach has big advantages over the “capability map” approach:

1. It ensures focus on the operating work of the organisation – what needs to get done to deliver value to the customers.  Capability maps often appear to give more focus on the support capabilities than on the operating capabilities, which potentially makes sense if you are coming from IT.
2. It ensures that the model for doing the operating work – what is combined, linked and kept separate – is defined before attention is given to the support and management work.  This helps ensure that the support and management work is set up so that it supports the operating work rather than creating tensions with the operating work.
3. It encourages the designer to think about how the different “capabilities” in the organisation are going to work together, something that seems to be missing in most capability maps.

The only disadvantage that I can detect is that the “value chain plus organisation model” approach introduces organisation structure into the thinking quite early on.  The “capability map” approach is more organisation structure agnostic.  I say more agnostic rather than completely agnostic because in practice most capability maps are influenced by the normal organisation structures: finance capabilities are typically lumped together under Finance and marketing capabilities under Marketing.

So this raises in my mind the question of whether I should refer to “value chain” or “capability chain”.   The phrase “value chain” works well for those who have been trained in strategy: in Michael Porter’s concept.  But it does not work well for Business Architects or Enterprise Architects, who like to talk about capabilities.  There are also many other communities, like HR, that like to convert strategy into capabilities requirements rather than value chains.   Of course it is not as simple as whether to refer to capability chains or value chains.   The lean community prefer terms like “process map” or “value stream”.

Maybe there is no solution to this language problem.  But recently I have been talking myself into using capability chain.

Comments welcome.