I have been thinking about capability maps. One of the participants on my course Designing Operating Models http://www.ashridge.org.uk/dom had a consultant do a big capability map as the first step in designing a TOM. I think it is also one of the first steps in Enterprise Architecture – but I am less familiar with this process.
She explained that she was overwhelmed by this capability map, as were her executive colleagues. It did not seem to provide any leverage for creative thinking, and it did not help with the communication of either the current state or the “to be”. This made sense to me, because I have often looked at capability maps and wondered if this is a good way into the problem.
So I have been thinking about what I do.
I like to start with a visualisation of the current state. I like to put the key stakeholders on this visualisation. So, for a retail business, we laid out the link between customers and suppliers. We started with customers, then put marketing next, then the service engineers who visited customers, then the three retail channels, then logistics, then commercial, then suppliers. Support activities like Finance and HR were positioned alongside this flow. Sometimes the visualisation is a flow chart like this. But other times the visualisation is an organisation chart as a model or maybe a map of locations or … The key is to identify some of the major activity chunks and how they relate to each other.
This visualisation then makes it easy to conceive of alternatives – to do “what ifs”. One can move the chunks about on the page and think about different relationships and even different chunks. I don’t particularly think of the chunks as capabilities, although they could be converted into capabilities.
I then like to choose a few (one or two or three) chunks to focus on. I choose ones that I think are interesting because they affect other chunks or because they are likely to change a lot or because they are being affected by technology or because they link to a critical stakeholder. So in the retail company we focused on Commercial because it links to suppliers, is a major power base and drives what goes on the shelves in the stores or on the website.
I then go through the visualisation process again at this lower level of detail, often going right down to the lowest level of detail to understand the processes used by the buyers or how the buyers control shelf-space allocation or.. Here I might lay out some detailed process and wonder how it could be done ten times as fast and at a tenth of the cost. I might also wonder what would happen if the incentive structure is changed for these people or if the department is staffed by different kinds of people. I do thought experiments at the lowest level of detail using my PILOS model – process, information, location/property, organisation/people and suppliers – and tools like IDEA or ASIAA or SPACI. This detailed work usually generates some insights that are relevant to the design challenge at the highest level. The insights often come from a better understanding of how this chunk links to other chunks or how this chunk could transform its work.
I like to have agreed some high level design principles to help me as I am wallowing in the details. But, some thought experiments will not be driven by design principles. The process is more creative than that. Also, the details often suggest additional design principles that are relevant at a higher level.
Exploring the detail in a couple of areas gives energy for creative work on the “to be” visualisation. Often this involves changes in power structures and some tough political fights. These cannot be won with a capability map. You need clever ways of representing the “to be” and clever arguments about why it will be much better for the business.
Once I have a “to be” agreed, then I clarify what falls within each of the chunks, how they relate to each other and what capabilities are needed within each chunk. This is where the capability maps start to be useful. But sometimes I go straight to the elements of my PILOS model – processes, information, location/property, organisation/people and suppliers. Of course a capability is just processes, information, people, property and suppliers – so one is doing the same work, but it is often easier to go straight to PILOS. Of course the process, etc exists to achieve something, so it is critical to think of the design principles for the process particularly those that come from the stakeholders of the process. Defining it as a capability can be helpful, but is not always the most helpful thing to do at this stage.
Ultimately one moves down to detailed process mapping, job descriptions, data capture rules, decision authorities and such like. At this point is it sometimes quite helpful to have a capability descriptor to help guide some of these low level choices. But good design principles are just as useful.
So what is the role of a capability map? Varied and not always useful. What do you think?
Since writing this blog I have been exposed to a few more capability maps. My thought is that the main benefit is that they help with issues of ‘standardisation’ across organisational units and ‘integration’ between different processes. The people who have developed the maps – the enterprise or business architect – has enough knowledge to be able to point out opportunities for standardisation and areas where integration issues may have been overlooked. It is a bit like the Knowledge for a London cab driver. It save the client having to figure out the best route.
I can see why capability maps are useful to business improvement experts. They can identify “maturity” (or skill) levels and pinpoint important capabilities that need attention. I can also see why capability maps are a useful aid for resource allocation. It is possible locate improvement projects by capability to see if the company has a balanced approach.
But I do not really understand the attraction of capability maps for enterprise architects. It seems to me that these are artifacts that should be produced after the design work has been done rather than as part of the design process. So course, if you are making small adjustments from an “as is” to “to be”, then a capability map may be a good way of representing this. But I do not see it as a primary tool in the process of design.
Pingback: Maybe there is a role for a capability map | Ashridge on Operating Models
(I think I have resolved my posting problems!!)
The approach that I have adopted to capability maps starts from a high level – consider an organisation as a single capability, (which may well be what it is in the broader context of the market ecosystem in which it operates), and then break it down into more detail. So, they don’t have to be overwhelming as experienced by your course participant.
I separate the capabilities into three streams:
a) Strategic (encompassing key governing capabilities)
b) Enabling (resource management capabilities)
c) Core value adding – the primary value chain capabilities
If this is done to reflect the capabilities required for the future business model and operating model, one can start a gap assessment of these against current capabilities, and then focus on establishing more detail, only for those with a significant gap – this saves time and effort on current capabilities that are adequate for future needs, directing attention to the key gaps where new capabilities or significant transformation may be required.
I agree Peter in part. The problem I have with the Enterprise Architecture approach to capabilities is the desire to be comprehensive. If you take the alternative approach suggested by Roger Martin – see my post https://ashridgeonoperatingmodels.com/2014/04/16/maybe-there-is-a-role-for-a-capability-map/, then the objective is not comprehensiveness but importance. The capability map consists of only five or six “distinctive capabilities” and everything else is linked to these five or six. This becomes much less overwhelming.
I would like to see an example of your approach -which you say achieves the same thing.
With respect to my comment on your other comment, I like your division of “Strategic”, “Enabling” and “Core value adding”. But I don’t think that any of these categories quite match Michael Porter’s “activity system map” idea ), the basis for Roger Martin’s ideas. The activity system map to me is much more strategic because it is focused on what is important and how the different capabilities support each other.
So often, I come across an HR department or an IT department building a capability but without an understanding of what the organisation’s distinctive capabilities are or how this new capability will reinforce them. In fact I am often part of the problem. One of the things I do is to help build organisation design capability in HR business partners – but these efforts are rarely aligned with strategy or business model or operating model – and, of course, there is no assessment of the financial impact if we are successful in building the capability.
I build the capability map from the business model and operating model. So, that makes sure that the focus is on “what is important’ – because the business model focus prompts questions such as:
a) who are our customers?
b) what are our product / service offerings?
c) what is the value proposition for the customer?
d) in what way is this differentiated from the offerings of competitors?
So, that moves one to identifying those capabilities that are distinctive and important. But sometimes it is not the distinctive capabilities that are the issue – it is some of the other capabilities which are critical to the value chain if the end product / service is to be of sufficient quality, reliability, etc.
I, too, have seen HR / Organisation Development that is bottom up, and Quality Management / Process Management that is bottom up. These approaches do not “cut the mustard”. So, it is not sufficient to do “capability development”, and there are effective and ineffective capability mapping initiatives. But poor practice or immature practice is not the basis for challenging an approach / discipline.