One of the big challenges when designing service operations is how to link the design to the business model/strategy of the organisation and ensure that it is strategically aligned. One very powerful way of achieving this is through the application of a strategic management concept called the “Resource Based View (RBV) of a firm” and an associated technique called “Business Capability Modelling”.
The basic principle is that to deliver their Business Model and Strategy, organisations require the ability to do certain things – they require a set of “Business Capabilities”, created by having access to a set of tangible and intangible ‘resources’, e.g. assets, processes, technologies, locations, people, skills, knowledge, behaviour etc.
Business Capabilities are about the ‘what’, not the ‘how’. They are about the ability to do things, not the doing of, nor how these things are done.
Many of these capabilities will be ‘ordinary capabilities’, required just to run the business, but others, either individually or in combination, will create a sustainable competitive advantage and/or be core to the success of the organisation – referred to as the organisation’s “Core Competences” (you will also find the terms “Core Capabilities” or “Strategic Capabilities” being used).
The Business Capabilities and Core Competences are defined through the definition of a Strategic Architecture; and the Business Capabilities are used to drive the design of the operating model, through the identification of the resources required to deliver each capability.
Key Characteristics of a Business Capability
Business Capabilities have certain key characteristics:
Uniqueness. A Business Capability is unique and well bounded. It does not overlap with another capability and is not repeated within the model. To give an example, “Case Management” would only appear once in the model, but is likely to be a feature of many other capabilities. But it is only called out once and linked to other capabilities through the establishment of a dependency relationship in the model.
Stability. The Business Capabilities required by a business are relatively stable, only changing as a result of a major change to the Business Model. This is because the things a business needs to be able to do changes less frequently than how these things are done. To give an example, originally you could only check-in for a flight at the airport through a face-to-face transaction. Now you can check-in on-line, or at a self service kiosk at the airport. The capability to be able to check-in for a flight has not changed, but how you do it has; and very significantly.
Decomposition. A Business Capability is decomposed into lower level capabilities. These define the more specific capabilities the higher order capability is dependent on. As an example, “Customer Management” is a very high level capability and there will be lots of views about what it means. To work through this, it is necessary to break it down further, into lower level capabilities, that are more revealing about the ability required.
Building your Business Capability Model
Building a Business Capability Model is part science, part art. It is also not a minor undertaking, so it is essential to adopt an incremental and iterative approach to its development, based on the priorities of the business.
In the case of an existing organisation, the first step is to identify the existing capabilities. This is often approached as a top-down exercise, but it is easier to create a basic framework and then refine this from the bottom up, by talking to the business about the capabilities they require in a particular area.
If developing a new Business Model, then the Business Capabilities should be defined as part of the Business Model and Strategy. If using the Business Model Canvas, replace the “Key Activities” and Key Resources” with the Business Capability Model view, initially only focusing on the key Business Capabilities required to deliver the Business Model.
A Business Capability has two parts – the definition and a title. A clear, unambiguous and comprehensive definition is key. It should always be in the form “the ability to do x”. This is one of the most time consuming aspects, for example, an identified capability may be “Brand Management”, but defining exactly what this means in terms of your own organisation may not be straightforward.
The label attached to a Business Capability should clearly relate to the definition. It should be a noun, compound noun, or noun-verb, e.g. Creativity, Strategic Planning and Customer Management.
To build a Business Capability Model, identify each Business Capability. Then group these to provide some logical structure. Then decompose each Business Capability further to identify specific aspects of the Capability, that are unique, well bounded and warrant being called out in their own right. Note that this often helps to fully define the high level Business Capability, i.e. the identification of the lower order capabilities brings a better understanding of the higher order capabilities.
Having build the basic model, the next step is ‘Normalisation’. This is the process of removing any duplication of the Business Capabilities across the model. Typically, the initial draft of the Business Capability Model will have specific instances of a Business Capability scattered across it (particularly if developed bottom up). Normalisation is the process of identifying them and bringing them under a single Business Capability and establishing the relationships in the model. Note that duplication can exist at any level in the model; and across levels.
Below I have shown a simple worked example, based around a set of Business Capabilities that all businesses require, dull but essential – Finance.
The next step is to identify the Core Competences, those individual, or groups of Business Capabilities, that provide, or will provide, a sustainable competitive advantage, or are/will be core to the success of the organisation. Again, the Core Competence will take the form of a title and definition. This needs to be done as part of the strategic planning process.
The final step is to identify the resources associated with each Business Capability, i.e. to create the relationships to your operating model. This step is covered in more detail below.
In practice, it is extremely unlikely that you will develop a full BCM at the first pass. It is more likely that you will either develop an initial high level version, or one focused on specific areas of the business. Just be aware that you will almost certainly need to re-jig the model as you develop it further, so keep this in mind when applying the model, particularly if using it within a tool to create relationships to other design domains – unless you are prepared for a lot of rework!
It is important that your Business Capability Model covers the entire extended enterprise, including your strategic partners. Sourcing is again about the ‘how’ rather than the ‘what’. Do not make the mistake that just because you have already outsourced something, you somehow no longer require the Capability within your enterprise model. In fact, on building the model, you may reach a very different view on what to outsource and what to keep in-house.
If your Business Model is predicated on collaboration with others, then you will need to reflect this in the way you build up the Business Capability Model.
The final stage in the development of a Business Capability Model is to identify the Resources that each Business Capability requires, or more specifically the relationships between the capabilities and the operating model, e.g. Process, People, Location and IT design domains. The IT Domain requires a special mention, as it is here that the use of Business Capabilities yields a particular and very powerful benefit.
Technology Enabled Business Capabilities
The Business Capability Model has a powerful characteristic when viewed from the IT design domain – it neatly aligns to the logical IT design, particularly in the case of IT Service Orientated Architecture (SOA). For this reason, the Business Capability Model is sometimes referred to as the “Rosetta Stone” of Enterprise Architecture, as it provides a much sort after direct link between the business and IT design domains.
The approach is to decompose a Business Capability to a level that defines a well bounded capability that is delivered purely by a technology resource, sometimes referred to as an ‘IT Capability’; and then to group these into “Logical Application Components”, or Logical IT Services (in the case of SOA).
In defining the IT Capabilities, you are effectively defining the IT high level requirements, which can then be used directly to drive the delivery of well bounded and re-usable IT services. Note that like all Capabilities, IT Capabilities are persistent. They only need to be defined once, avoiding the situation found in most organisations, where the same IT requirements are defined across multiple instances; and over multiple generations of the same enabling IT.
Putting the BCM to Work
In addition to helping you develop the operating model and to make sourcing decisions, the Business Capability Model has several other areas of application.
Investment Decisions. Where a Business Capability Model is developed within an existing operation, the organisation will already have some of these Business Capabilities established across many areas of the business. The most common application of the Business Capability Model is to determine how these existing (current state) capabilities measure up to the strategic (future state) capabilities required; and to drive decisions around investment priorities. A heat-map is produced, highlighting those Business Capabilities to be further developed and programmes/projects of work identified to both develop the Capabilities and deliver the new/re-designed Business Services that will be utilising them.
Strategic Alignment. For existing in-flight projects, or for new projects not directly derived from the use of the Business Capability Model, the BCM can be used to assess their impact, i.e. what Business Capabilities will be enhanced by the project. This assessment can be used to ensure that the project is strategically aligned. It is not unknown for an existing project to be stopped as part of such an exercise.
IT Asset Lifecycle (or Portfolio) Management. The Business Capability Model provides a very good basis for managing the lifecycle of IT assets, both IT services and the underlying technologies and infrastructure. If you know what the relationship is to your Business Capabilities, you can better understand how the lifecycle of these assets impacts your business, e.g. the degree of risk if nearing the end of their lifecycle; and where investments are best made. You can also use the relationship mapping to identify technology duplication, i.e. the existence of duplicate solutions in relation to a single Business Capability. If you take a very commonly required Business Capability such as “Case Management”, it is also very common to find multiple case management platforms/solutions being used across different parts of the organisation.
Merger and Acquisitions. The Business Capability Model can be used to compare the strategic merging of two organisations and the Business Capabilities that each will bring to the table; and how these might be leveraged within the new, combined organisation.
Use of Industry Reference Models
It can be quick to assume that all organisations working in a given business sector, e.g. Logistics, Financial Services and Insurance, require the same core set of Business Capabilities. This has lead to quite a lot of effort being made to create standard, industry specific BCM reference models.
I would guard against the wholehearted use of these models. Your BCM needs to be aligned to your Business Model, not some generic version for the industry, which is unlikely to represent the cutting edge. It needs to be expressed in your terms, reflecting your culture and strategic outcomes. I strongly recommend that you define independently and only draw on these models where it makes sense to do so, e.g. where it allows you to focus on the definition of your Core Competences, rather than the more general capabilities that you require.
Other “Capability” based Methods and Techniques
The term “Capability” is used in other contexts and within other methods and techniques that are similar to the RBV approach described here. A brief word on one of these, as it is a source of much confusion, particularly in the world of IT.
RBV-based Business Capability Modelling should not be confused with the concept referred to as “Capability Management”, or “Capability Planning”. This concerns ‘operational capabilities’ – generally defined as “the things a company needs to do to execute its business strategy”.
The emphasis here is on the doing, not just the ability to do, i.e. ‘Capability’ here is referring to the direct physical realisation of a capability, as an activity, or function. An often quoted example would be the assembly of a set of resources to provide a particular defence capability; and indeed, capability planning is heavily used in the Defence sector. It is also found in Sourcing Decisions and the application of ‘Specialisation’, e.g. using “Component Business Modelling”.
In RBV-based Business Capability Modelling there is no direct equivalence between a Business Capability and an activity, or function. It is only about the ability to do something, not the actual doing. The ability to write a best selling book, is not the same as the activity of writing a best selling book.
Some people find this distinction difficult to understand, being rather abstract, but it is key to the successful application of Business Capabilities to the architectural design of the enterprise. The problem with Capability Planning is that it is essentially ‘functional decomposition’, which leads to the creation, or re-enforcement of operational silos; and the fragmentation of processes and roles.
In short, this is a bit of a minefield. There are lots of articles, but quite a bit of confusion has crept in (as I’ve highlighted above). It’s not helped by the fact that most articles do not mention their theoretical basis, so it is often difficult to know where they are coming from. But in most cases, people are actually talking about activity-based Capability Planning, not RBV-based Business Capability Modelling.
I would definitely recommend reading “Putting Capabilities to Work” by Jeff Scott. Very much on the same page; and expands on some of the application areas I’ve covered here, with some very colourful visuals.
With some reservations, I can also recommend the “Business Architecture Body of Knowledge (BIZBOK)”, produced by the Business Architecture Guild. This includes a section on “Business Capability Mapping”, which sits reasonably well with the RBV-based approach I’ve outlined here, although strangely they reference an article which definitely does not. It also includes several industry reference models. You will need to join the Guild to obtain the publication, but if using, or planning to use Business Capabilities, or are interested in Business Architecture as a discipline, then this might be worthwhile.
What I refer to as ‘soft’ Business Capabilities is an interesting area and can be quite hard to identify and define, but increasingly are a major source of sustainable competitive advantage. This article on Creativity and “psychological safety” should provide some food for thought.
And if you want to delve into the capability-based theory of the firm in more detail, I’ve provided links to several key publications in my companion article on the Resource-based View of the Firm.
Most Enterprise Architecture tool vendors have added Business Capability Modelling to their offerings. As well as creating the basic model, they allow you to create the relationships to other design domains and views, e.g. the Business Model and Operating Model views. If a large corporation, a good tool is well worth considering (assuming you don’t already have one). That said, I have got by with MS Excel and Visio on a smaller scale. A free Visio-based Starter Pack is available from Orbus Software. If looking at a tool, check its meta-model (its definition of the Business Capability ‘object’ and the relationships that can be created), to ensure that it properly supports the modelling of Business Capabilities as outlined here.
And finally, I have also produced a blog post to accompany this article, where I provide some examples of my practical experience of applying RBV-based Business Capability Modelling, across a range of different types of project.
First Published: 26/03/2018 Latest Updated: 27/03/2018