One of the big challenges when designing service operations is how to link the design to the business 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. skills, technologies and processes.
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.
There are two types of Business Capability – Operational Capabilities and Organisational Capabilities. Operational Capabilities are created by tangible and intangible resources, e.g. technologies, processes, materials, infrastructure, skills and knowledge. Organisational Capabilities are created by purely intangible resources – the values, behaviour, skills, abilities and expertise of the organisation. They represent the ways that people and resources are brought together to accomplish work. They form the identity and personality of the organisation. Examples include the ability to innovate, business agility, ‘psychological safety’ and collaboration.
Many Business Capabilities are general, or “ordinary capabilities”, that are 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).
Business Capabilities are defined as part of creating a Strategic Architecture for the organisation. And they are realised by the Operating Model, more specifically through the design and delivery of the products and services that they enable.
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 might only appear once in the model, but within the operating model, there will be several instances, associated with the management of different types of case, e.g. customer complaints, claims, etc.
Stability. The Business Capabilities required by a business are relatively stable compared to how things are done, only changing as a result of changes 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 that the higher order capability is composed of. 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 and resolve down to a unique combination of resources.
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 business area. Typically this early engagement is driven by the current priorities of the business.
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 Partners”, “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 three parts – Definition, Title and Outcome. 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 be far from straightforward.
The label attached to a Business Capability should clearly relate to the definition. It should be a noun, or compound noun, e.g. Strategic Planning, Customer Management, Marketing, Creativity and Curiosity.
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 in the model. Note that duplication can exist at any level in the model; and across levels.
The final 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 in the future. Again, the Core Competence will take the form of a title and definition. This last step should form an integral part of the organisation’s strategic planning process.
In practice, it is extremely unlikely that you will develop a full Business Capability Model 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 and applying the 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.
Putting the BCM to Work
Having built your Business Capability Model, you can start to use it to develop different aspects of the Operating Model, i.e. to identify the resources and their resource capabilities, that each Business Capability requires across the various design domains, e.g. Process, People, Location and Technology. The Technology 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 Technology design domain – it neatly aligns to the logical design. For this reason, the Business Capability Model is sometimes referred to as the “Rosetta Stone” of Enterprise Design, as it provides a much sort after direct link between the business and Technology design domains.
The approach is to decompose a Business Capability to a level that defines a well bounded capability that is delivered by a similarly well bounded technology resource; and then to group these into logical components, or services.
In defining the technology capabilities, you are effectively defining the high level requirements, which can then be used directly to drive the delivery of well bounded and re-usable technology services.
Note that like all capabilities, resource capabilities are persistent. They only need to be defined once, avoiding the situation found in many organisations, where the same technology requirements are defined across multiple instances; and over multiple generations of the same enabling technology.
Technology resource capabilities also provide a foundation for the simplification and rationalisation of deployed technology resources:
- removing redundancies by eliminating and consolidating duplicate systems and information
- reducing overlaps by breaking capabilities into more modular systems, i.e. Logical Application Groups (LAG) and Logical Application Components (LAC)
- identifying and filling gaps, by enhancing existing systems, or acquiring new ones
Other Areas of Application
In addition to helping you develop the operating model, the Business Capability Model has several other areas of application.
Sourcing Decisions. I touched on sourcing earlier. Business Capabilities are very useful when it comes to deciding what to do in-house and what you might choose to outsource; and when analysing your supply chain. If a capability is critical to your competitive advantage (and by definition very few organisations possess it), then you are going to want to keep the associated resources that realise that capability in-house. If it is a commodity, then the option exists to potentially outsource the associated resources to someone who specialises in that capability.
When making sourcing decisions around the creation of new business models, Business Capabilities can be used to identify opportunities for collaborative advantage, i.e. the formation of strategic partnerships to create new value propositions, not possible individually.
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. A 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 future 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.
Technology Asset Lifecycle (or Portfolio) Management. The Business Capability Model provides a very good basis for managing the lifecycle of technology assets, both the 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 service life and where investments are best made. As mentioned earlier, 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”, you will often find multiple case management platforms/solutions being used across different parts of the business.
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 Business Capability reference models.
I would guard against the wholehearted use of these models. Your Business Capability Model 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 business design methods and techniques. It is important not to confuse them, or conflate them with Business Capability Modelling.
Two examples are “Process Capability”, used in Statistical Process Control (SPC) to refer to the performance of a process; and the “Capability Maturity Model (CMM)”, a well known design framework, used to express the management maturity of a business process.
A further example is “Capability Planning” and the use of the term “Business Capability” to refer to the capability of a business function. This is the source of much confusion, particularly in the world of IT. Superficially, Business Capability Modelling and Capability Planning can seem very similar, but they are very different.
Capability Planning places the emphasis on the doing, not just the ability to do, i.e. ‘capability’ here is referring to the ‘what’ of a business function, a logical and/or physical group of related activities. 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 and associated design frameworks.
In RBV-based Business Capability Modelling there is no direct equivalence between a Business Capability and an activity, or function, although they may often align. It is only about the ability to do something, not the actual doing.
To contrast, in Capability Planning, Financial Management is a business function, the capability of which is created by bringing together various associated activities and resources. In Business Capability Modelling, Financial Management is a capability, created by a set of resources, that is then utilised within the business, wherever that capability is required, i.e. within the Finance department, but potentially other areas as well, e.g. the Project Management Office (PMO).
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. Not least, Capability Planning is based on functional decomposition, which as a general design approach is not recommended, as it leads to the creation, or re-enforcement of operational silos; over specialisation and the fragmentation of processes and roles.
Further Reading….
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 Functional Capabilities of one form or another, not RBV-based Business Capabilities.
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 large section on “Business Capability Mapping” and several industry reference models. The theoretical basis is not given, but it aligns very well with the RBV-based approach outlined here.
BIZBOK also includes a section on “Value Mapping”. This provides some useful guidance on the use of Business Capabilities alongside value mapping. It also helps to clarify the ambiguity found in the main section.
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.
Organisational Capabilities is a very 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.
You may note that I do not recommend TOGAF as a source for further reading. TOGAF is a function-orientated framework and uses Capability Planning.
Also, a frequently referenced article is “A Business-Oriented Foundation for Service Orientation”, by Ulrich Homann, published in 2006. Ulrich’s definition of a Business Capability is often used. But this paper is also using the term within a functional context.
And More….
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/views and viewpoints, 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 content 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 the original version of 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: 05/03/2020