I assume that readers of this article already have a first understanding of what a business capability is. If this is not the case, please read this article on what you need to know about business capabilities first.

Many organizations start with business capabilities because someone had the idea to use them somehow. Business capabilities are still a relatively new concept and there is little agreement and accepted literature when it comes to the theory of the concept, especially in terms of definitions, development methods, use cases, and standards.

Several organizations have tried to establish standards, yet, the scope of their standards ends at the boundaries of their organizations. The results are little available guidance, heterogeneous development results, few success stories, and many skeptic stakeholders.

In order to support organizations struggling with developing business capabilities, I have summarized my top 12 lessons learnt that I experienced during the past few years:

1. Understand the Exact Use Cases

Understand your use cases to determine what exactly you need. Business capabilities can support many different use cases, such as alignments of business and IT, across merging companies, or for strategic planning of future budgets and projects. However, do not assume that one can use one business capability map for all! The business capabilities required for different use cases will be very different in terms of number, level of detail, number of levels, and information and components that should be mapped.

• A rationalization approach for an application landscape might for instance need just a few business capabilities and mapped information. Those could be applications, cost information, the lifecycle of the underlying technology, and business happiness with the overall outcome.
• A demand management approach, on the contrary, might need a large and detailed amount of capabilities. For such a use case, more than 20+ business capabilities can be mapped to a demand. The objective is to decide how many of these are already covered by existing solutions. Information to be mapped might then be scalability, interdependencies, etc.
• For a merger, you will not need any detailed capabilities, because you must stay on a level that is still comparable across the companies.

 

2. Know All Your Stakeholders

Identify all relevant stakeholders for a particular business capability area. If you only work with one department to identify the business capabilities of a particular area, do not expect a holistic business capability map as result. Take the example of pricing. It is not only done by the Marketing Department but is also impacted by many more areas in the business. The following areas also impact it:

• the development and production costs,
• strategic aspects from the Strategy Department,
• the local sales shops that have to eventually consider transport, import, taxes, temporally and local discounts etc.

Similarly, contract management is not only needed when a customer buys a product or service, but also with suppliers, business partners, etc, Your organization might eventually be present in different markets and have different divisions that are all a bit different, use different applications, and follow different processes. However, they all pay onto the same stack of business capabilities that in the end represent the business capability map of your company.

3. Understand and Explain the Difference to Processes

Be prepared for tight discussions with “process people”. Many organizations have put a tremendous effort into developing detailed and sophisticated process descriptions for their organizations. Also, process descriptions are often more mature than business capabilities and hence there will always be some strong supporters of processes that do not consider the business capabilities as a viable alternative – at first. It is one of the key success factors of business capabilities to emphasize their benefits over processes, which is why I will briefly mention them here:

First, a business capability is always defined and named as common as possible to maximize understanding from all kinds of stakeholders. For instance, it must not include company specifics, such as a technology or a particular process step. On the contrary, processes can vary greatly between two different companies, and even if their name is the same, the actual content can be very different from each other.

Secondly, business capabilities have always three components, which are process, people, and technology. Being the result of several components makes business capabilities more stable over time than its single components, for instance, a process.

Thirdly, business capabilities aim to provide an exhaustive view of the company without overlaps. They are theoretical concepts that are chosen to minimize the interdependencies across two different capabilities. This makes it possible to analyze them separately. In contrast, processes reflect the actual doing of a company and they are not optimized for an independent analysis.

With these advantages at hand, it is crucial to also understand the great disadvantage of business capabilities, which is their theoretic nature. To benefit from capabilities, an organization needs to have the concept understood and defined for itself – which is challenging without good existing guidelines. This brings us to the fourth lesson to consider.

 

4. Communicate the Concept Over and Over

Be well prepared to explain the concept of business capabilities 1,000 times and more to members of your organization – on all different levels. I have spent endless hours presenting and discussing the concept of business capabilities. A major takeaway from this was that sharing and being able to reuse the content should have a very high priority.

Generally, be prepared to answer questions such as Why capabilities? How does it help us in our current situation? Why is it better than the last two concepts we tried? Why should we use them? How will you do it? What results do you expect? What’s in it for the executive level? For business? For me? There are endless questions.

 

5. Provide Strict Guidance on the Development

Develop and communicate very clear guidance on what the business capability that you expect looks like. If you have already searched for business capability maps of other organizations, you noticed that, depending on the source, the results can differ a lot. Again, this is due to the missing standardization, as even the new TOGAF 9.2 strives for new digital topics, such as business capabilities only on a very high level

(Update: TOGAF tries to provide some standardization for the topic of business capabilities with its Series Guide: Business Capabilities – which indeed provides one of the best summaries so far).

If there is no centrally accepted guidance, every stakeholder will create business capabilities that differ in terms of detail, the dimension, the components considered, and the wording. All those aspects make it challenging to harmonize and compare the results later on.

From my experience, explanations cannot be detailed enough to sufficiently define a business capability in a way that people independently come to the same results. Instead, I prefer to provide small examples of how the business capability map should look like in the end. This way, attributes such as detail level, grammar, components, scope etc. become clear and are immediately captured.

 

6. Reuse and Lever Existing Inputs

Reuse as much of existing sources as possible – internally and externally. A first business capabilities draft is often much closer to the status quo than theory would suggest. This is not bad at all, as it helps the organization to slowly change its mindset towards a capability-based view. Understand the first version of a business capability map as a starting point that your organization can use. As a next step, consolidate further and identify more capabilities that belong together. Also, identify whether there is still one or the other process in the map that can be transformed.

When it comes to internal sources, consider strategy papers, process descriptions, organizational charts, or functionalities of your applications. When it comes to external sources, consider global process standards from APQC or FrameworX. However, be aware that none of these input sources is perfect and each has its advantages and disadvantages.

How to get started with modelling business capabilities and which input to take is an important step.

 

7. Be Aware of the Disadvantages of the Concept

One of the disadvantages of the sources is that there will be a bias towards one of the components of business capabilities: people, process, or technology. The type of bias will depend on the source you decide for. If you use process descriptions to develop a first business capability map draft, the result will somehow be similar. There will be no swim lanes, responsible, or repetitive detailed process steps anymore. However, it will make clear that for instance HR is organized from hire to fire or R&D has capabilities from research to patent lifecycle management.

On the other hand, if you start to investigate the functionalities of your applications and cluster them logically, there will also be a bias. The result is very likely to have a technology bias, as you went through the systems one after another and considered every technical detail.

Lastly, if you start with an organizational chart, you might quickly have your first business capability level at hand. Such a capability map would include capabilities such as Marketing, Production, and Procurement. However, there is a high risk that you capture too much of your organizational specifics (i.e. people component) that you do not want on your maps, such as divisions or regional organizations.

8. Think Long-Term – do not Expect Short-Term Results

Be prepared to not be able to deliver fast results or add value quickly. The biggest risk to the long-term success of business capabilities is that they are very theoretical. They are a concept that needs time to add value to an organization. Like most areas of enterprise architecture, the concepts need to be accepted by many people within the organization. Therefore, data needs to be collected and analyzed, and the implications need to be communicated and again accepted.

This all takes time and there is a risk that the added value becomes quickly zero if key stakeholders do not support the idea. Also, top management must understand that the real benefits will be realized in the long term. There might even be no positive effects in the short term at all!

It is therefore highly important to show the value added by business capabilities whenever possible, especially when there are discussions about the worthiness of the concept.

 

9. Look Out for Every Opportunity to Pilot and Showcase

What this means for you is that you must be sensitive to opportunities. Your goal should be to show the value of business capabilities through pilots or showcases. There are enough opportunities if you continuously search for them. Be sensitive to stakeholders that show more interest in your work than others. They might just think alike and understand the real potential behind it. Look out for early-on projects that suffer to harmonize a part of the landscape or that miss a clear representation of their strategic way forward. All these situations might provide you with a good chance to show some value of your draft business capability map.

 

10. Manage Expectations

In all you do, do not expect to get 100% accurate and final results. Enterprise architects, especially business architects, know that their work never provides a definite answer. However, the business might not be used to this. Business architects are used to providing recommendations, directions, or a couple of options. In contrast, business often looks at the definite numbers of the business case.

As business capabilities are an enterprise architecture concept, they are conceptualized to provide recommendations across a wide spectrum of questions. They are not made to provide definite answers, as they will always lack some information. Lacking information can be:

• more detailed business capability levels,
• interdependencies that the concept does not consider,
• information that was not captured for the analysis or has changed in the meantime,
• and tacit knowledge from domain or solution architects that were not involved.

11. Decide on the Right Tool Based on the Target State and Operating Model

Get tool support to manage updates on the vast amount of data that you will have. There are different options, starting from Excel lists, SharePoint solutions, and all kinds of specialized EA tools, from lean to highly sophisticated. In the end, also the tool must fit your purpose. However, be aware that developing business capabilities and mapping information to them, as well as using them and displaying the results is an iterative activity that typically takes much more time than initially expected.

Therefore, think wisely from the start: How many data sets will you have to manage? How many persons should have access to view and edit data? What kind of visual representation do you expect? How often do you want to allow updates or new releases? What security level is needed for the data? Depending on your answers to those questions, you can derive a first impression of what kind of tool support you need.

 

12. Understand the type of capabilities that you need

In this article, I have talked about business capabilities. However, many people confuse those with similar concepts. IT (or technical) capabilities, for instance, have a much stronger focus on technology and solutions that can cut through many different business capabilities and hence cannot be displayed in the same capability map. An example would be the ability to identify spelling errors and duplicated data entries in your master data and perform data cleansing activities.
Another type of capability that becomes increasingly popular and is regularly confused with business capabilities is Digital capabilities. The major difference between digital capability maps is that they do not have the goal to describe all aspects of a company but solely focus on aspects that are of interest for digitization. Because their use cases differ from those of business capabilities, they are typically more detailed and are all described with only one level. 

If you want to understand the use cases of business capabilities and how they can help organizations transform, read my article “Top 5 Use Cases for Business Capabilities to Transform an Organization”.