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.’
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