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:
- 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.
- 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.
- 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.
I still view the two tools (value chain maps and capability models) as different and use them with different audiences to achieve different objectives. The approaches address different levels of detail and it’s up to the practitioner to pick the right one, not the audience.
How the capabilities in a capability model interact is an interesting point. That’s usually modelled as “business services”, which describe how the capabilities offer services to the other capabilities. An information model, in abstract, describes the information that exists in an organisation. Used to connect business services, it shows what information is created, used, updated by a business service.
Peter, Please say more. They are two different tools, but when do you use one and when do you use the other and why? What are the different objectives you are trying to achieve.
I am not sure that I agree that the approaches address different levels of detail. Both tools can be used at a high level or taken down two or three levels. Also, as I point out, a value chain is just a capability chain of the operating capabilities. So they are not really different at the basic building block level.
If you consider a capability to be an attribute of a subsystem (as per Stefan Haeckel), then it becomes possible to see that whether each subsystem is named on the basis of the capability it holds or the value it delivers, the capability chain and value chain are the same thing, just with different class types and different labels.
There is a tendency to through the capability model out with the bathwater, whereas there are good quality capability models which pass the test above – largely because the way they are composed is by considering entity lifecycles and value chain analysis!! But there are also many capability models which have no particular rigour and are largely a representation of what makes sense to the creator.
Having seen many different capability models, value streams, results chains – I am confident that they are all alternate representations of the same thing (when comparing high quality examples applied to the same enterprise).
Peter, I like this comment very much. I have probably seen too many capability maps that “have no particular rigour”. But I am also concerned that the capability map methodology typically does not place the operating work (buy, make, sell) in centre stage. Maps often start with “formulate strategy” and/or “govern decisions” rather than “win customers” or “serve customers”. It is really just a point about focus. We probably all end up in the same place, taking different routes to get there. Thanks you for commenting. Please add more words of wisdom.
Pingback: Tools for examining an existing or proposed operating model | Ashridge on Operating Models
Pingback: Linking transformation projects to strategic intent | Ashridge on Operating Models
Just passing on by, interesting conversation. Capability model has a very significant role in addressing demand and supply problem whether it is with business partners or internally between users (on demand side) and IT community (on supply need), there is a need to have a shared view of things to plan and organize and agree on things and priorities. It emerged from a need to look at things neutral (like non-political for budget purposes and planning. Political means organizational say). Therefore It needs to be as neutral and simple in lingo as possible, each capability needs to be as distinct and mutually exclusive as possible. But it has to be a shared perspective for entire organization of work company does to bring about outcomes, earn, satisfy customer or even value. Value part comes from building competencies… It should not be an invention of one persons head but collective interpretation of what company does. All these things have to be done in a way to do overlay analysis…. processes are what business users understand, because they think that way. IT or suppliers understand capabilities to help those in demand….
There are lot of capability models out there, and yes there is lot of value but then if you have your head way up in the clouds, then you may not gain mass adoption at lowly people. Make it grassroots not a corporate thing that big wigs throwing awesome graphs at people. At the end of the day, people care about their family and interested in making an earning to support them. So if capability model is a way of them making the company more innovative then you have a game. I never seen any smart ideas come from the top, its always people at the bottom of the pool scratching for a name for themselves.
So look at from supply and demand point of way. Layering with organization (political), employee(human processes), are most effective to become skilled as business relationship managers. Capability model is your tool The key is understanding the information flows, all these will need to be automated in future.
Good luck friends.