Defining the Business Capability - A Cheat Sheet

http://www.bainstitute.org/resources/articles/defining-business-capability-cheat-sheet

A business capability defines “what” a business does at its core. This differs from “how” things are done or where they are done. Business capabilities are the core of the business architecture(i). Before I go further, let me say that this is not an article on the importance of the business capability or capability mapping. If you have doubts about this, read some of the other posted articles or white papers on the topic to build your familiarity. This article is for those of you who already understand the value of business capability mapping and need to go to the next stage.

As companies launch business capability building exercises, many business architecture teams struggle with the issue of what is or is not a capability. I have included some simple guidelines to keep your efforts on track as you embark upon your journey. Determining if something is or is not a capability, differentiating capabilities from other capabilities and validating these issues within the context of your business model can be challenging. The following guidelines provide insights into how capabilities can be identified and differentiated when establishing your capability map.

1. Determine if a capability is actually a capability because it describes what – not how – something is being done.
   Faxing and emailing are not capabilities because they describe ‘how’ a capability fulfilled. Similarly, mailing an invoice is not a capability. Capital Management is a capability because it describes what is being done.
2. Capabilities have outcomes.
   Communication with a client or customer is not really a capability because it has no clearly defined outcome. A Customer Information Management capability would, however, have the outcome of ensuring that a customer has high integrity information associated within it at all times. Lower level capabilities have more specific but related outcomes to their parent.
3. Make sure a capability is not a process or value stream.
   Topic categories that require movement, such as the concept of authorizing, validating or engaging in some sequence of activities fall into a process category. A process or value stream stands out because it veers into “how” something is being done.
4. Capabilities must be clearly defined.
   Capabilities must have clear definitions at every level. Calling something Account Management requires not just a definition of the management portion but also the account portion of the term. This forces a common view of your business.
5. Capabilities are unique in terms of intent.
   If two capabilities seem alike, question their intent. For example, if a Customer Management capability appears to be the same as a Partner Management capability, consider that customers are inherently different than partners (the fact that they may be one in the same notwithstanding) and demand a different set of management capabilities. Conversely, managing customer information could easily double for managing prospect information if the business can align it terminology and thinking around this concept.
6. Capabilities are framed by their parents.
   The relationship within a given capability between a parent and its children is not process centric but just a detailed refinement of the parent. For example, if a capability called Risk Rating is contained within a higher level capability called Solution Management, then this case of risk rating is focused on delivering or furthering a solution. If a Risk Rating capability is shown under a Risk Management capability within a Capital Management capability, it is mostly likely furthering an aggregate view of risk management that is not tied to a given solution.
7. Capabilities are unique based on the information they require and use.
   One capability may use or produce certain information that a similar sounding capability may not require or use. Again, an aggregate view of Risk Rating when decomposed may only look at a country or a class of customer while a similar sounding capability within the context of Solution Delivery looks only and entirely at information that is tied to that specific solution. In addition, a capability definition must align with the corresponding definition of that business asset. Account must be defined in the same way as it is in the definition of Account Management.
8. Capabilities can be framed by the roles and resources that have those capabilities.
   Can two people switch jobs and still perform adequately well in relation to two similar sounding capabilities? For example, if the corporate risk manager switches jobs with an underwriter, will each person still be able to fulfill their roles within an equivalent level of effectiveness?
9. Capabilities are purely business views of the business.
   It does not matter if a capability is automated or not. It is a capability if the business can and does have this ability – even if it is weak. Keep the discussion of systems on the sidelines as you go through this exercise. Later, when your capability map has matured, you can begin validating and using it through value stream, organization and IT asset mappings.

One last point here for those organizations just getting started. There is a degree of introspection involved in capability analysis that few people have experienced. Not everyone can sit through the sessions, but for those that do, the rewards are very real. Business people have said that it makes a very different part of your brain go to work. Another said that the journey of building the map is as valuable as the end result. Good luck, as you continue your journey.