Creating Capability Maps that Matter
By Bernard Gagnon and Pierre Hadaya
July 2020
Both the Current Capability Map and the Target Capability Map are recognized as key business architecture deliverables because they respectively represent what the organization is currently doing and what it will need to do in the future. When properly constructed, these maps can greatly facilitate some very important work. This includes, first, the identification and analysis of a majority of the organization’s strengths and weaknesses. The second is the feasibility analysis of each alternative considered during strategy formulation. Indeed, business capability maps help identify and analyze, for each of the alternatives considered, the key changes needed to the organization to implement it. The third is the design of the organization’s complete target business architecture, which includes perspectives additional to that of capabilities, and its transformation plan.
It’s not a simple task to create business capability maps that truly facilitate the work listed above. Indeed, most of the maps we have seen are greatly limited in their utility, often because they’re conceptual maps of the organization’s information systems instead of true business capability maps. Such information system maps can be very useful, but shouldn’t be confused with business capability maps.
To facilitate the creation of business capability maps that truly matter, we have, over the years, identified a set of requirements these maps must meet and have derived design principles from them. This first part of the article will review the most important requirements and the principles we have derived from them. Part 2 will provide many examples of true business capabilities and of things that are sometimes identified as such, but aren’t.
Requirements
The most important requirements are as follows:
- Be business, instead of technology, oriented.
- Be accepted by key stakeholders as a valid representation of what the organization does today or what it will need to do in the future.
- Be easy to understand and readily usable in presentations and discussions with executives, managers, subject matter experts, IT enterprise architects, and other stakeholders.
- Facilitate the optimization of the flow of work, material, and information between capabilities to maximize the value they collectively create for the organization’s customers, owners, partners, and employees.
- Facilitate the determination of the resources from which each capability is, or shall be, built.
- Facilitate the identification of changes that need to be made to the resources that make up each capability in order to transform it as specified in the target business capability map.
Principles
The most important principles are as follows:
Principle 1: Each map must be solidly grounded on the concept of business capability defined by the business strategy literature
The concept of business capability originates from the business strategy literature. The oldest mention of the term we have been able to find is in a 1965 book entitled Business Policy by Learned et al. The concept has been further developed since then, mainly in the extensive Resource-Based View of the Firm (RBV) and Dynamic-Capability literature published since the 1980s. The most notable authors of this literature (see reference section for a list of key articles and books) have over time arrived at a fairly good agreement as to the nature of business capabilities. Our definition of the concept is based on their work:
A business capability is a set of resources that, by working together, gives the organization the ability to purposefully produce a particular business output.
It follows from this definition that a business capability:
- Has for its purpose the production of a particular and concrete business output. Examples of such outputs are products, services, sales, invoices, financial reports, and new product designs. As these examples demonstrate, the output can be for external or internal use.
- Involves actions as indicated by the word “produce.” To that effect, many of the RBV and Dynamic-Capability authors indicate that any given capability leverages one or more processes.
- Exists not on its own, but as the combined effects of multiple resources. The above-mentioned notable authors make it very clear that a business capability isn’t the result of just a technology asset or any other single resource. Instead, a business capability arises from the purposeful combination of different types of resources—including processes, technology assets (e.g., machines and IT systems), and information.
It is important to distinguish the concept of business capability from that of technical capability. The former is an ability that an organization has, while the latter is an ability, or functionality, that a machine or computer system possesses.
Principle 2: Represent the organization’s business capability hierarchy
The business capabilities of an organization form a hierarchy. Indeed, an organization typically has between 10 and 20 high-level business capabilities. They collectively produce all of the organization’s outputs. However, each of these capabilities produces only a distinct subset of the organization’s total outputs. To do so, they each rely on lower-level capabilities of their own, i.e., on their sub-capabilities. Each of these sub-capabilities produces a distinct subset of its parent capability’s output. Thus, the resources the high-level capabilities are made of are sub-capabilities. These sub-capabilities may in turn be made up of one or more levels of lower-level sub-capabilities. The end result is a capability hierarchy.
The sub-capabilities at the bottom of this hierarchy can’t be subdivided into lower-level sub-capabilities. They are thus referred to as “atomic.” The atomic capabilities of an organization rarely all belong to the same level in the hierarchy. They’re distributed over several levels. The level to which a particular atomic capability belongs to depends on its nature and that of its parents up the hierarchy. Our research (Hadaya, Gagnon 2017) and that of other authors has led us to conclude that the resources that make up atomic capabilities are organizational units, processes, information, know-how, technology assets (e.g., information systems, machines, factories, vehicles) and sometimes brands or natural resource deposits (e.g., oil fields, ore deposits). Think of these resource types as the “people-process-tools” of organizations, only structured in a manner appropriate for the complete and rigorous design and modeling of any organization’s business architecture.
It follows from this principle that capability maps shouldn’t be mere reflections of the organizational structure. The reasons for this are threefold. The first is that a manager can often be assigned responsibilities that are very different in nature. For example, the IT department may be under the responsibility of the CFO. This in no way makes the capability to develop information systems a component of the Manage Financial Resources capability. Second, organizations often have many capabilities that aren’t revealed by an examination of their organizational structure. For example, very rarely can you find a department with inventory control in its name. However, an inventory control capability exists in a great many organizations. Third, often a capability leverages multiple organizational units. For example, the Design Products capability may call upon the engineering, manufacturing, and marketing departments.
Principle 3: Avoid redundancies
To avoid redundancy in the map, no two capabilities should have the same purpose, i.e., to produce the same particular business output.
Respecting this principle requires some thought. For example, to manufacture products you need the sub-capability to fabricate some of their parts and that of purchasing others. Now, the capability of purchasing items is also needed for other purposes. To avoid redundancy, this capability should only be present once on the map. In the case of the capability to purchase items, we usually locate it under a level one capability dedicated to everything related to sourcing and its management.
Principle 4: Name each capability using the “verb-object” format
The name of a capability should make its purpose clear. As indicated in Principle 1, that purpose is to produce a particular output. Put another way, that purpose is to perform some action to an object—ex., fabricating products, selling products, testing products. The name of a capability should thus include a verb to identify the dominant type of action involved. As shown by the above three examples, changing that verb can completely transform the purpose of a capability. The name of a capability should also indicate the object to which these actions are performed—that object can be physical or not. This is why the verb-object format is best for naming capabilities. Preferably the verb should be in the infinitive or end in “ing.” Examples of capabilities named this way are: Deliver Services, Resolve IT Incidents, and Formulate Strategic Plan. The purpose of each of these capabilities is made very clear by this naming convention. Furthermore, this way of naming capabilities is identical to the way most people complete the sentence “I’m capable of…” with statements such as “riding a bike” or “driving a car.”
The verb should be as indicative as possible of the nature of the dominant type of action involved. This means that the verb “manage” should only be used for capabilities whose purpose is truly to manage something. In 1917, Henry Fayol identified the four functions of management as plan, organize, direct, and control (PODC). This has withheld the test of time and is still taught today by most management schools around the globe. So the name of a capability should include the verb manage only when its purpose includes at least one of the four PODC functions. When a capability’s purpose includes more than these four functions, then its name should also include a second verb to reflect the other dominant type of action involved. For example, the capability that takes care of everything related to product manufacturing should be named something like Manage and Perform Product Manufacturing. This capability can then be broken down into two sub-capabilities: Manage Product Manufacturing and Manufacture Products. Proceeding this way keeps related capabilities together, clarifies the purpose of each capability, and makes the parent of the others clear.
Principle 5: Language of the organization
Capabilities should be named as much as possible using the language of the organization and without needless abstractions. Indeed, people with no or limited understanding of the concept of business capability should readily be able to understand that the map identifies the things the organization does or needs to do. They should also easily recognize these things. Thus, the verb(s) and object in the name of each capability should be, as much as possible, terms that are in common use within the organization.
Principle 6: Validate the maps
The map should be validated by key stakeholders to ensure that it meets the requirements listed in the introduction of this document.
Conclusion
This first part of the article presents some of the most important principles that should guide the development of business capability maps that matter. They make the maps easy to understand by people with little or no understanding of the concept of business capability and enable these maps to be used for a variety of purposes.
In the second part of this article, we will provide examples drawn from a business capability map built using the above principles. We will also give examples of things that are sometimes identified as business capabilities but aren’t.
References
- Amit, R., Schoemaker, P. J. H. (1993), Strategic Assets and Organizational Rent, Strategic Management Journal, Vol. 14, pp. 33–46
- Barney, J. B. (1991), Firm Resources and Sustained Competitive Advantage, Journal of Management, Vol. 17, No. 1, pp. 99–120
- Collis, D.J. (1994), How Valuable are Organizational Capabilities, Strategic Management Journal, Vol. 15, pp. 143–152
- Eisenhardt, K. M., Martin, J. A. (2000), Dynamic Capabilities. What are they?, Strategic Management Journal, Vol. 21, pp. 1105–1121
- Grant, R. M. (1991), The Resource-Based Theory of Competitive Advantage: Implications for Strategy Formulation, California Management Review, Spring 1991
- Learned, E.P., Christensen, C. R., Andrews, K. R., Guth, W. (1965), Business policy. Homewood, IL: Irwin.
- Makadok, R. (2001), Towards a synthesis of the resource-based and dynamic-capability views of rent creation, Strategic Management Journal, Vol. 21, p. 387–401
- Peteraf, M. A. (1993), “The cornerstones of competitive advantage: A resource-based view” Strategic Management Journal, Vol. 14, No. 3, pp. 179–191.
- Teece, D. J., Pisano, G., Shuen, A. (1997), Dynamic Capabilities and Strategic Management, Strategic Management Journal, Vol. 18, No. 7, p. 509–533
- Wernerfelt, B. (1984), A Resource-based View of the Firm, Strategic Management Journal, Vol. 5, pp. 171–180.
- Hadaya, P., Gagnon, B. (2017), Business Architecture — The Missing Link in Strategy Formulation, Implementation and Execution, ASATE Publishing.
- Fayol, Henri (1917), Administration industrielle et générale; prévoyance, organisation, commandement, coordination, contrôle, Paris, H. Dunod and E. Pinat, OCLC 40224931