***

Background and intro

In recent years, the word capability has steadily been drawing attention in the business world as a way to narrow the gap between business and IT. A capability is described by Ulrich and Rosen, (p.1, 2011) as:

A business capability, or simply a “capability,” defines what a business does. It does not communicate or expose where, why, or how something is done---only what is done. Specifically, the business capability is “a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.

Understanding what a business does is at least as important as understanding how it does it. Focusing on the what rather than on the how often provides the right level of abstraction of complex ecosystems in a way that can be easily digested by business executives and planning teams. Dissecting a business as a set of basic capabilities allows one to view complex organizations and business environments in a wide range of different ways. Additionally, one could zoom in on lower levels of abstraction to reach higher levels of detail depending on the needs of the target audience.

Consider the example of the high-level capability called customer 360°. This capability refers to having a complete picture of the customer and this is a capability many organizations may benefit from. A customer may be called a taxpayer in the context of a government institution, a patient in the context of a hospital and a student in the context of a university. Being able to manage different aspects of a customer might be imperative for many businesses depending on their business strategy. For instance, customer 360° as a high-level capability could entail the customer trend analysis and customer management information capabilities as lower-level capabilities.

In other words, this means that capabilities are concerns that could be refined into lower-level capabilities that in turn could be further refined. The advantage of functional decomposition in this hierarchical and modular way is that it increases the reusability of capabilities across business lines, enterprises or even industries. Additionally, decomposing capabilities in different levels of abstraction offers a better sense of how capabilities fit in on the overall view of the enterprise.

Capabilities should follow certain principles as follows:

  1. Capabilities define what a business does and not how a business does it. This implies that a capability does not refer to a process or value stream.
  2. Capabilities are nouns, not verbs. To make the distinction between a capability and a process, capabilities should be named with nouns such as customer management instead of a verb managing customers.
  3. Capabilities should be defined in business term and not in technical terms. Executives and other business professionals should be able to clearly understand what a capability means ---and take ownership of it---without being bothered with the technical details of the systems that implement it.
  4. Capabilities should be stable (i.e. least volatile) as possible. There is a fundamental set of high-level capabilities that are necessary to run a business regardless of the sector of industry it is located in. Additionally, high-level capabilities may rarely change within an organization unless there are significant changes to its business strategy or organization.
  5. Capabilities are not redundant. Capabilities appear once and only once on a capability maps even though they are shared by more than division, business line or business unit of an enterprise.
  6. There should only be one business capability map per business. In order to bring transparency across the organization, there should be a single unified and harmonized business capability map per business. Therefore, business capabilities spread throughout different business units, divisions, department, lines of business, etc should be only appear once in the business capability map.
  7. Capabilities map to---but are not the same as---business processes, business units, Lines of Business (LOBs) and value streams. There is rarely a one-to-one mapping between a business process, a business unit, an LOB or a value stream, and a capability. Therefore, mistaking a capability with one these other concepts may result in an overly complex overview of things that are constantly repeated across the enterprise. Additionally, we’re trying to understand the what rather than the how and this would not be possible if capabilities are mistaken with process-related concepts.
  8. Automated capabilities are still business capabilities and not IT capabilities. Capabilities are owned by the business as they are made by and for the business. Therefore, a capability that has been automated with an IT system is not an IT capability. Instead, it is nothing else than an automated business capability.
  9. Capabilities are the most valuable when incorporated in the overall pictures of a business’ ecosystem. While being useful in a stand-alone basis for discussion and planning, capabilities fulfil their biggest potential by being combined into a larger business capability map that represents the business ecosystem of an enterprise.