Those who have been following this blog will know that I have devoted four or five entries to the issue of capability maps. Mainly because I have not seen the need for them and because they can obscure the core operating processes and give too much prominence to the support processes.
So I thought I would share an excellent comment on this topic from David Winders. In 2009, he wrote an article “Capability Frameworks” from which I have stolen some choice paragraphs and added some of my own text and edits. In other words the text in inverted commas is 85% David and 15% me. Apologies David, if I have inadvertently subverted your meaning, but I thought you were making some great points with two excellent examples (one of course is now no longer topical!)
“In nearly every encounter with fellow business architects the subject of capability frameworks seems to come up in discussion. In nearly every case, people are trying to establish their understanding of this approach and seeking to get further information or comfort from discussion with an outsider who might have the answer.
I have concluded that we need to recognise the differences between capability frameworks and process architectures and understand where they add value and where they don’t. We need to perhaps use more concise language that is business-focused and be aware that different disciplines use conflicting terms like “business services” creating unnecessary confusion. I would suggest that “business building block” is better than the ambiguous term “capability” to describe a portion of the business that delivers something, but with reference to the capability in the name of the building block.
Capabilities focus on outputs whilst processes are concerned with actions. In financial services a high-level process architecture often looks nigh on identical to a high-level capability model. Hence, in a process dominant sector like financial services, people look at capability models and say “what is the point?” Apart from a slightly different naming convention – process is verb-followed-by-noun (Make Payments) whilst capability is often noun-followed-by-verb, (Payment Making) – there is little difference between the two.
A possible reason for the convergence of process and capability models maybe due to reluctance to define capabilities. If you ask people in an organisation steeped in delivery, particularly in a high volume processing area, they are often more focused on what their department does day to day than what the department delivers to a customer. If you ask what the capabilities are, you universally will get a list of processes. It is quite difficult to ask people to forget how they do things, and think about what the deliverables are instead, and what the outputs mean to customers or the rest of the organisation’s value chain.
Military enterprise architectures MODAF/DODAF do give special focus to capability frameworks, as the military is more interested in what it can achieve than in designing repeatable activities in the form of processes; from an architecture perspective the capability of a platoon or a gun is more important than how it is deployed in the process of executing a particular battle (the process view).
A topical subject at the moment (2009) is the 65th anniversary of the allied DDay landings in Normandy, where the capabilities of “Fuel Supply” and “Stores and Provisions Supply” were provided through the technologies of pipeline under the ocean (PLUTO) and floating harbours (Mulberry Harbour). There was a process content in these “Overlord” capabilities: they were part of the DDay process. But military people doing architecture work are interested in their capabilities to support and maintain mechanized divisions in the field of combat (for example gallons per day or tons per hour).
Like so many things, there is a danger that we get too intellectual about the techniques, tools and language we use. There are situations where the capability language and focus will be most helpful, and others where the process language is likely to be more useful. The only real guide is that it must be appropriate for the audience that receives it. It may well be academically interesting for us in business architecture to have these debates but what value does this add to the business that pays the bills?”
So maybe I should stop my agonising about capability maps? But, there is some value in discussing tools. If we use the best tools, we are likely to do good work. David’s point is that it is horses for courses. Tools should be chosen to suit the situation.
Ashridge on Operating Models 
“In financial services a high-level process architecture often looks nigh on identical to a high-level capability model.”
It may be a naive question on my part, but wouldn’t the difference between the process architecture and the capability model represent unexploited opportunities?
Yes it would; not a naive point at all in fact really profound. The question is would they recognise capabilities that they don’t use?
Capabilities are great for understanding a complex physical system by extracting “root definitions” and attempting to avoid political and ego driven bias.
> I would suggest that “business building block” is better than the ambiguous term “capability” to describe a portion of the business that delivers something, but with reference to the capability in the name of the building block.
This is a good example of context, perspective and world-view being critical to how we see things, and whether we see value or not.
I can understand why Andrew would prefer BBB, but here is the simplest reason that it is not a suitable alternative. Which would you say to a business person?
a) Do you have the appropriate capabilities to realise your business goals?
b) Do you have the appropriate business building blocks to realise your business goals?
For me, the latter does not “roll of the tongue”. We use “capability” in everyday business language – we don’t use BBB at all. I prefer to engage using the business language of my client, than to introduce foreign language and terminology. Having an IT background, I already have too much technical language and marketing hype as assumed background for most people’s liking. I don’t need to introduce more!!
Ah, Peter, wise words! But, actually you would not say capability. You would say “ability” or “skills”. And when you refer to ability or skill you are referring to the actions not the outcomes. So the way the word capability is used in “capability map” is not the same as the way any executive would use it. Also, as we have discussed previously, capability is normally reserved for advantaged abilities, at least in the board room.
Business building block is David’s term. I included it because it shows how different practitioners are reaching for language to describe what we are working on. The key in my view is to have real clarity about what you are doing and be flexible about what you call things, because different people you talk to will use different words.
BBB comes from TOGAF 8.0/9.0; I was exploring this topic seven years back when capbilities were new on the block -ignoring the pun! – when people were getting quite confused between high level processes and this “new” concept.
Peter’s language comment I would agree with but apparently capabilities is a foriegn word in the boardroom too as Andrew advised me recently; he sits on several boards as an Non Exec. so perhaps both terms suffer from this language issue?
From my perspective, writing seven years later in 2016, capabilities as a concept is more well-known now than it was back then and therefore the word capability is much more an accepted concept today. It is the preferable word of the two in business conversations and perhaps when talking to I.T types with inputs to TOGAF/Archimate and the like you can translate to BBB.I agree the least number of terms the better!
Re capability and process …
These two words are used so widely and so often that it is no surprise that there is no single consistent meaning and interpretation attached to each of them. The challenge, in part, is that when used as part of a particular discipline or methodology, they need to be clearly defined, understood and applied. Loose use, inconsistent use, low maturity examples do not mean that it is not possible to establish clarity and to realise value from their use.
As Andrew knows, I am quite comfortable with both terms, and am very clear about the different circumstances in which I will use the terms and how they add value. As an example, the simplest differences in my use of these terms, is that I use:
a) process as how and capability as what
b) process as verb and capability as adjective (because it is always capability of x)
c) process as outside-in and capability as inside-out
Each of these are quite distinct and convey that the two terms will be used quite differently.
That they can be used interchangeably on a high level diagram is no surprise to me, because I find that in these circumstances they are each different perspectives of an underlying model:
a) Process perspective of a systems model
b) Capability perspective of a systems model
In my use of these two viewpoints, I have a different purpose / intent when using a process perspective than using a capability perspective.
Hope that helps a little in differentiating these – and conveys that I violently agree with the view – horses for courses!!
Peter, Why not expand a little. Give some examples of your three types of difference. I liked David’s distinction between “making payments” and “payment making”. But using your “capability of …” would work with both: capability of making payments and capability of payment making.
Also give some examples of “different purpose/intent”. I think many readers of this blog are not sure when to use capability map and when to use process maps/value chains/value streams. Or refer us to one of your LinkedIn pieces. Andrew
> But, actually you would not say “capability”. You would say “ability” or “skills”. …
Andrew, there are several issues at play here. The primary issue is that you are imposing your worldview on me and others. When you suggest that I or others would say “ability” – you are really saying that YOU would say … As I can assure you that I would say “capability” and I know other Directors who would say “capability”.
I just did a search of the Australian Institute of Company Directors website and Director Resource Centre, and found numerous “hits” on capability, ranging from individual to organisational capability.
I appreciate that a Board typically is interested in “strategic” capabilities, and hence will use the word without prefixing it to reflect those capabilities in which it has greatest interest. This is simply a subset of the entire set of capabilities that any enterprise exercises to realise its goals and aspirations.
Were I to allocate more time, I am sure I could provide a wide range of references to capability beyond the narrow scope that you apply.
Peter, No intention to offend. I meant “one” rather than “you” – sorry. But you don’t address the point about the word capability having a different meaning when used in common language: to me it means skill or ability, in other words, more about the action than the result/outcome. Whereas in “capability map” it means “outcome” or “deliverable” I think.
We are probably dancing on the head of a pin here. You like capability maps. I am suspicious of them. That is probably where we should leave it.
To elaborate on differences a little further …
Process is typically a descriptor of how to achieve an objective. The objective reflects the ends and the process the means. This reflects an outside-in view. Nominate the objective and the output, and explore options, strategies, alternative processes for achieving the objective. The process is the means by which a system transforms an input into an output. Hence, the process name is a “handle” for the system or a viewpoint of the system.
Capability is typically a descriptor of “the ability to”. It holds the system and its means as constant and explores potential ends which the system might also support. This reflects an inside-out view. Nominate the capability and consider what ends can (or can’t) be achieved / realised. Again, the capability name is a “handle” for the system of which the capability is an attribute.
One entails black box thinking, the other white box thinking.
As to labels, whilst there are conventions, the importance attaches to how the entities are being viewed and analysed – not to their labels. As you have identified, one can construct other renditions that make the labels look quite similar.
Andrew
Several thoughts for your consideration:
a) I don’t think this is about two meanings – common language and strategic language. I have already acknowledged the wide and diverse use of this word, and I am not trying to sweep every form of usage into one meaning. There is a very simple “logic” that can be applied here – strategic capabilities automatically implies the existence of non-strategic capabilities. Or put another way, you advocate that there is a set of capabilities that are strategic – ergo, the remainder of the enterprise can be viewed as capabilities, too.
b) With the increasing degree of market disruption and demand for enterprise change, a wider range of capabilities have the potential to be strategic today and non-strategic tomorrow. If a capability is no longer strategic, that does not mean it is not needed – a strategic capability may have a critical dependency on the former strategic capability.
c) There is more to be “unpacked” in relation to capabilities and outcomes – perhaps another article some time soon!
d) I would be interested in your take on “Synthesis, capabilities and overlooked insights” – McKinsey Quarterly, Sep 2014
e) This is not about me “liking” capability maps – this is about the value in identifying capability gaps and capability dependencies which better inform business transformation initiative formation and investment portfolio planning – in a manner whereby business outcomes are enhanced and delivered at lower cost and lower risk.
Andrew – I am just reading Soft Systems Methodology in Action – Chapter 3 – An Application of SSM in Industry – which describes its application in ICI in the Information & Library Services Division
p61 the following text struck a chord in relation to our discussion here …
+ the question … was to be “what business are we (ILSD) are we in and what capability is required in the 1980’s
+ another objective is to upgrade the problem solving capability of ILSD
I keep on coming across business use of “capability” well beyond the constraints that you apply to the term. I will be interested to understand what you make of such usage.
Peter, As always, helpful clarifications. Thank you. I agree that capability has a wide set of meanings. But, within the phrase “capability map” it has a rather precise meaning: although in most capability maps I have not seen it used in this precise way. Hence, I agree that, as regards the operating work needed to deliver the value, that is little difference between a capability map and a value chain map. The difference is that the capability map includes the support work, Finance, HR, Business Planning, etc, which is not included in a value chain map. Maybe this is the reason that I like doing an organisation model immediately after a value chain map: because it allows me to add in all the support activities – so that I get a picture of the whole.
A capability map also would give me a picture of the whole, but with less information about the nature of the relationships between different parts of the whole.
This dialogue has helped me understand the benefits and disadvantages of different ways of doing things – thank you.
Andrew
Can you point me to some clear guidance on value chain maps? In a different forum, I have another person telling me that value chain encompasses all the support activities. So, it is rather confusing if the term is being used in different ways (just as capability map seems to be used in different ways!!)
Note: an enterprise capability map (in my terms) covers supporting activities as well as core value adding activities, so I have no need to do an organisation model after a capability model – because I have the whole picture already!!
Michael Porter’s original value chain does include the support functions. But the value chain maps that I do focus only on the core value adding activities for each product/market segment that the organisation is trying to serve. So for Ashridge Business School there is an open courses value chain, a tailored courses value chain, a consulting value chain, a research value chain … even a weddings value chain (we have a beautiful house!). If you lay out these value chains identifying 5 to 7 steps/activities for each, it is then possible to lay them out side by side to see where activities might be combined, where links might be set up and where similar activities should be kept separate to ensure appropriate tailoring. For example event admin for weddings probably needs to be kept separate from event admin for courses!
My blog has some articles on value chain maps – if you use the “categories” index.
i recognise that doing value chain maps this way means that I need an “organisation model” to incorporate the support functions/activities. However, what I gain is an initial focus on the core value adding activities and an ability to think about these across different value chains without the complications of all the support activities. My observation of capability maps is that because they have everything together there is less potential to present multiple value chains and/or to focus on the links across the chains. But, I am sure that it would be possible to use capability maps in this way …. in fact I have labeled them “capability chains”. So we are probably not far apart Peter.
Lot to learn from here from above post as well as discussion among experts.