Result

Capability management: The achievement of business goals depends on capabilities

Capability management makes it easier for companies to act more effectively in both their daily operations and in times of crisis. It also helps with the development and implementation of appropriate strategies and digitalization projects. That, at least, is the way it’s supposed to be in theory. CBA Lab conducted interviews with 17 experts from nine different business sectors in order to find out whether the theoretical benefits of capability management actually manifest themselves in practice. CBA Lab also identified the areas in which capability management results in the most added value, as well as where typical implementation pitfalls are to be found.

The basic idea is quite simple: Your capabilities determine whether you will be able to achieve your goals. Or, to put it the other way around: If you want to achieve certain goals, you need to have certain capabilities. The capabilities approach used at companies is based on this same logic. Still, gaining transparency with regard to existing capabilities is a much more complex undertaking in (large) organizations. That’s why companies categorize capabilities and depict them in capability maps in order to obtain a clear overview of the situation.

Achieving this type of transparency is especially helpful when a company changes its goals or sets new ones. In such a situation, a capability map makes it very easy to determine whether the company actually possesses the right set of capabilities to achieve the new or changed goals. If this is not the case, or not completely the case, the capabilities that are lacking can be developed in a targeted manner, provided the goals in question are important enough to justify the effort and expense involved.

The cross-silo approach is the key

The benefit offered by the capabilities approach is that it is based on a company-wide cross-silo concept. “Nobody asks whether a certain capability exists in Department XY or Division Z – for example direct online communication with end customers,” says Uwe Weber, a CBA Lab Ambassador and co-author of the whitepaper with the same title as the “Capabilities – Best Practices” workstream it is based on. “Instead, the question is whether such a capability exists at all, and what its maturity level is.”

This company-wide approach not only ensures a higher degree of transparency (one that can also be achieved more rapidly) regarding existing capabilities and those that need to be acquired; it can also lead to a better common understanding of IT and business and the capabilities needed for these, provided the approach is implemented correctly. This in turn means that both the IT and business organizations need to employ the capabilities approach and use the same language to describe capabilities.

In situations in which requirements change quickly and a large number of changes need to be made, a comparison between (business) goals and existing/needed capabilities using the capabilities approach proceeds much more quickly than is the case with conventional analysis and planning methods. In addition, capability management ensures there will be no differences between the views and perceptions of IT and business organizations and the languages they use to describe capabilities.

Nobody asks whether a certain capability exists in Department XY or Division Z – for example direct online communication with end customers. Instead, the question is whether such a capability exists at all, and what its maturity level is. 

Added value in many application scenarios

More specifically, capability management can create added value in connection with the following use cases:

• Demand management: Comprehensive resource planning and requirements analyses. Targeted management of resources within the company. Use of synergies to reduce costs. This can be applied far beyond the IT organization. When a new product is to be manufactured, for example, a company always needs to determine which capabilities and resources already exist and which need to be acquired.
• Platform strategies: Specialized descriptions of platforms; integration of existing services. Use of synergies from existing services. This is extremely helpful in connection with loosely linked systems and microservices especially, as one can lose sight rather quickly of the range of existing capabilities in these areas.
• IT architecture plans: Structuring standardization at one’s own company or a company spin-off on the basis of the blueprint of the reference capability map. The sharpened focus on the capabilities at one’s own company makes it possible to much more quickly identify missing capabilities at companies to be acquired.
• Reference modeling: Standardisierung im eigenen Unternehmen oder die Ausgründung von Unternehmen nach der Blaupause einer Reference Capability Map strukturieren. Der geschärfte Blick auf die eigenen Fähigkeiten macht fehlende Capabilities bei Unternehmen, die erworben werden sollen, sehr viel schneller sichtbar.
• Scenario analyses: Scenario analyses can be used to prioritize the strategic development of a company’s own business capabilities – and thus make the company more successful.
• Innovation management: Professional structuring can, for example, lead to a comprehensive overview of the current status of digitalization, which is very important when new digitalization projects are being planned.
• M&A assessments: Faster and more extensive comparison of the capabilities at one’s own company and those at a company that has been acquired or might be acquired. Rapid identification of redundancies.
• Competitive differentiation: Use of various methods for identifying one’s core areas of expertise and the capabilities that can ensure a successful future. This may sound somewhat trivial, but the fact is that if a company operates in a market with similar competitors, it’s very helpful if it can accurately describe its own strengths if it wishes to communicate these to its customers, for example.

Experience with structuring and delineation is important

Experience and communication skills are crucial when it comes to structuring capabilities and differentiating between them. There are three basic approaches that can be used to identify and structure capabilities: The top-down approach, the bottom-up approach, and the bimodal approach. The experience of the companies that participated in the CBA Lab workstream shows that the bimodal approach is the best approach for describing capabilities as precisely as possible and structuring them in a capability map. The most abstract capability levels – Capability Level 0 and Capability Level 1 – do not display any strong differentiation potential in a company-wide context. Level 0 designations such as “Customers and products” or Risk management” are often the same as the designations for corresponding domains at a company. The situation with regard to Level 1 is similar – e.g. designations such as “Marketing” or “Sales.” Such capabilities can easily be specified by top management.

Differentiation becomes more pronounced on Levels 2-5. Whereas, for example, the “Sales management” capability on Level 0 appears to be generally applicable, and the “Acquisition and sales” designation on Level 1 is viewed by responsible managers as encompassing similar capabilities (even at different companies), the associated Level 2 capabilities of “Sales negotiation,” “Quote generation,” and “Sales processing” can be quite different from one another. The members of the workstream therefore recommend incorporating those directly responsible into the process for defining the elements of these levels and granting them at least the right to make proposals.

The following key questions can help with formulating capabilities and differentiating between them:

• How (finely) granular do I need the capabilities to be?
• What is the specific question that I wish to model?
• How big is my company?
• What is my idea for structuring?
• Where can standard capabilities be utilized?
• What belongs together technically and in terms of business – and what doesn’t?
• In which areas is a high degree of flexibility needed?

As few maps as possible

Defining and structuring capabilities can be a drawn-out process, and a company-wide capability map can be used much more efficiently than a large number of different maps. That’s why the workstream members urgently recommend that a separate map not be created for every new use case. Instead, the existing company map should be used and only expanded for areas where such expansion is truly needed.

Dos and Don’ts

The dos and don’ts of capability management were extensively discussed in the workstream. Here are some of the conclusions drawn by the working group for the various phases of capability management:

With regard to the “Development” phase, the working group recommends the following, for example:

• Do not create a new capability map for every question in the development process but instead pursue the goal of a company-wide capability map for the entire organization – and only go into more detail if this generates added value. “If companies don’t take this to heart, those involved will get bogged down in details and at some point will no longer be understood by everyone else,” is how Uwe Weber describes this don’t.
• Don’t develop business capabilities along the existing organizational structure or the existing application landscape; instead, initially examine them independently of these. “If one focuses on the requirements of the organizational structure or the existing application landscape, they will just get more of the same, but they won’t get a cross-silo layer of transparency,” Weber explains.

Instead, the working group recommends the following, for example:

• Keep business capabilities and the methodology used as simple as possible. Says Weber: “Lucidity and transparency are the key to capability management that is effective and successful – and not just carried out over and over again as a type of dry run.”
• The right stakeholders need to be brought in at the right time. “If, for example, I bring in experts at the generalized level, I will never be able to establish highly abstract capabilities that can be used for an entire domain,” says Weber. “Conversely, if I get members of the board of management involved at the detailed level, I will never be able to produce a sufficient specialized description of the desired capability.”

With regard to the “Utilization” phase, the working group recommends the following, for example:

• In projects, do not focus on explanations but instead on the application and the added value of capabilities. Weber interprets this as follows: “If the people involved want to convince departments or units of the effectiveness of the capabilities approach, the best thing to do is to explain what the capabilities can be used for and what benefits they offer – and not focus too much on what each capability actually means.”

With regard to the “Governance” phase, the working group expresses it opposition to rigid corporate bodies, for example:

• Do not discuss changes in rigid corporate bodies. Weber explains this don’t as follows: “Rigid corporate bodies are not useful here; communities consisting of people who are directly involved with the capabilities are much more efficient.”

Communication, communication, communication

Effective communication is the decisive factor for gaining acceptance for the capabilities approach. “Without the right communication strategy, you run the risk that capability management will just turn into a bunch of colorful pictures stowed away in a drawer somewhere,” Weber explains.

The workstream therefore specifically references four best practices:

1.     Define, explain and clearly differentiate between the terms you use, and do so in an understandable manner – It is crucial to establish a common understanding of capabilities and to ensure that definitions are as simple, clear, unambiguous, and understandable as possible. A key aspect with regard to making sure that terms are unambiguous is to view and describe capabilities independently of processes and organizational charts. Business units often think in terms of processes (how is something done) or organizational charts (who does what). Capabilities enable a more general view of things and describe WHAT the company actually does.

2.      Keep things simple at the beginning and then expand later on – The capability model should initially be kept simple and only expanded later (when the main features are generally understood) to include additional artifacts or objects.

3.     Design capabilities to be self-explanatory – The concept of capability management already offers the ideas, terms, and differentiation possibilities that are needed for a definition. The workstream recommends making capabilities as self-explanatory as possible using a clear vocabulary that doesn’t leave room for interpretation. That way, users can quickly get accustomed to the approach.

4.     Always define and describe the context – The context in which capabilities are to be used must be defined and clearly described.