Not for the first time in my career, I’ve come across a bit of confusion, in the last week or so, on the term ‘business capabilities’. People are confused on:
- how to interpret a business capability ‘map’- they assume it depicts the organization’s structure
- the connection between business capabilities and individual capabilities
- the value of looking at business capabilities at all
When I mentioned this, someone pointed out to me that ‘Business capability is a very academic topic for most people and is likely to lead to confusion and a feeling that by working with them the programme team is insufficiently rooted in reality.’ They were arguing that business capabilities are the kind of internal workings that people didn’t need to know about, and should be ‘hidden’. My view is that having a good grasp of what business capabilities are and how they can be used acts to reduce the confusion.
Business capabilities are described as the ‘what’ of the organization. The Open Group defines them as follows: (Thanks to Tom Graves for alerting me to this)
‘A business capability represents the ability for a business to do something. A more formal definition is as follows: A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.’
You can watch a presentation on business capabilities from Open Group or download their whitepaper on the topic by creating an account.
Having identified an organization’s business capabilities, it is up to others – including organization designers – to convert the ‘what’ into ‘how’. As Open Group says ‘Critically, a business capability delineates what a business does without attempting to explain how, why, or where the business uses the capability.’
In trying to represent the ‘what an organization does’ the choice of business capabilities over value chain or process mapping, for example, is based on the premise that business capabilities are more stable than these other approaches (which also are more related to the ‘how’).
Typically, business architects develop capability maps. (Although I heard today that enterprise architects do too. But I’m not going to be drawn on the difference between business and enterprise architects).
For the most part business architects consider each capability as comprising a combination of strategy, process, people, information and technology. (Note that some architects use different elements and combinations of them). Developing the capability map can be a complex process – unless you buy off the shelf ones – involving close partnering with stakeholders and numerous iterations. (See one method for developing capabilities here, and look at Captera’s examples of a capability map here).
It is these maps that lead to the first confusion. The maps cluster the capabilities into what can be interpreted as a structure/organization chart, but the map is not the org chart. Open Group explicitly states that:
‘A common mistake is to transpose the organizational chart onto the frame of the business capability model itself. Quite often, multiple business units are involved in creating or delivering a single business capability. Organizational structures are also far more transient by nature than business capabilities. Avoid where possible a tight alignment between the functional names that denote business units, and the top-level business capabilities.’
A capability map is not the org chart because a capability is a ‘what’, and the org chart is part of the ‘how’. Take a capability like Recruitment Management, described, in Open Group’s paper, as ‘The ability to solicit, qualify, and provide support for hiring new employees into the organization.’ This capability (the what), can be operationalised (the how) in a multitude of different ways via various permutations of people, process, information and technology – depending on the organizational resources and strategy.
The ‘how’ do we do what we do is another set of discussions, decisions, choices and trade-offs from which an organization chart is one element that will ultimately emerge.
The second confusion is a related one – often an individual employee’s skills/competences are described as ‘capabilities’. Where you have a business capability of Recruitment Management, for example, remembering that the capability is a combination of people, process, technology and strategy – what exactly are the people’s capabilities required to work that business capability?
There isn’t a related individual capability of ‘recruitment management’, the individual capabilities are a bundle of things like social media savvy, networking, etc.
This confusion can be resolved by changing the language of the organization, to make it perfectly clear that capability refers to business capability and that competence, or skills, or attributes (not capability) refers to individuals.
The third confusion about why are we looking at capabilities when they are academic, theoretical, and hard to understand leads to other suggestions – can’t we just map processes, or value streams? The point here is that they are not either/or – they are different ways of looking at an organization. If you think of the capability as being relatively stable or static, but the process you use for delivering it as changing over time then you need both. Take recruitment management again. The ‘how’ it is done changes over time, but the what it does stays the same. William Ulrich explains the relationship between different organizational views very neatly.
Once the confusions are addressed, business capability maps can be a useful addition to an organization designer’s practice. Where do you stand on doing your organisation design work using business capabilities? Let me know.
Image: Capabilities Banner
Naomi Stanford 
Naomi, A browse through my blog http://www.ashridgeonoperatingmodels.com will show that I have something of an aversion to capability maps, and much prefer using process maps (value chain maps in my language). I find that a capability map feels like a redundant step. The strategy states the what – who we will serve and what we will offer them – so why do we need an additional layer of whats? Once you have the strategy, you should go straight to the “how”: what process steps are we going to put in place to deliver this strategy. Yes there are different ways of doing the how: but, if you want to get clarity about your organisation design or operating model, you want to be clear about which of the different ways you are choosing. The intermediate step of laying out a capability map is just a delaying tactic! Of course the process map will only give you the main steps of work needed to deliver the value proposition. It will not include recruitment management, for example (unless the business is a head hunter). So there is a need to add all of the support activities, such as recruitment management or strategic planning or financial accounting. These, in my experience are best added into the thinking when doing an organisation chart (or even better, using my tool the organisation model). So my advice to anyone who is not already a fan of capability maps is ignore them: you don’t need them. They are difficult to understand. They leave senior managers bemused about why all this work has been done. They are often confused with and organisation chart. Life is easier without them.