Links to articles from series:
Business Capability Modelling Overview (article 1)
Business Capability in-depth explanation (article 2)
Business Capability Model and its use cases (article 3)
Business Capability Modelling workshop recipes (article 4)
What exactly is Business Capability?
Business Capability is an abstraction that represents the ability of the business to achieve a specific outcome or value. Capability is a potential that the business possesses. Business Capability is a way to encapsulate business volatility inside of the abstraction. By encapsulating volatility, we are creating stable connections and dependencies between parts of the model. Business Capability remains stable if we focus on the question ‘what?’ and not on questions: ‘how?’, ‘who?’ and ‘to whom?’. But what does it mean?
Ability To
Business Capability is the ability of a business to achieve a specific outcome or value. You should be able to describe business capability with a sentence that starts with: “It is an ability to…”, like, “Apartment Handover is an ability to accommodate a person efficiently and smoothly on demand.”
Abstraction
Business Capability is not precise. Its outcome defines it, and you can achieve the same outcome in different ways or for other purposes. Due to that, Business Capability could be instantiated in many different ways. We could achieve efficient person accommodation by delivering keys by a property manager or by sending SMS with a password to the electronic lock. The outcome would stay the same so that we can develop an abstraction like Apartment Handover.
Outcome not output
The capability should be defined by its outcome. We should not differentiate two capabilities when they result in different outputs but the same outcome; in this case, we should merge them into one abstraction. The outcome is not equal to the output. The output is only quantitative when the outcome is also qualitative. If you are organizing a birthday party, then a successful party & happy kids are the outcomes you would like to achieve. Organizing a clown or cooking a birthday cake might help, but those are one of many possible outputs. There are other ways to make kids happy; ten small puppies should do the work too! Focus on those things that matter, like happy kids, and not how you will achieve it. When you are modeling capabilities, you should try to build them around expected outcomes, not outputs.
Product or a service
You should think about Business Capability as a complete whole or something autonomous. You should be able to sell your capabilities as a product or service outside of your own company, or other way around, you should be able to outsource it.
Interior
Let’s look closer at what we can find inside a single capability. Business Capability is a combination of Roles, Processes, Information, and Tools. To be able to deliver capability, you have to utilize many company resources. First of all, you need to have the right people with the skillset. Usually, those people have some processes around their work, and they also need access to some pieces of information and tools.
A good example is a capability like “Cleaning services.” You need to have a cleaning staff (roles), they should perform their work in a specific order to make it more efficient (process), they also need to know what and how to clean it (information). And finally, to do their work, they require a vacuum cleaner (tools).
Capability is stable, unique, lacking purpose & decomposable
Stability
The adequately designed capability should not change in time. If you would travel ten years back or into the future, your company should still contain the same capability. The capability should also not depend on the people performing it or those on the receiving end.
Uniqueness
Capabilities in the organization should follow the MECE principle. MECE stands for: mutually exclusive and collectively exhaustive. It means that inside your organization, capabilities should not be duplicated, there should be only one instance of each of them, and capabilities should not overlap.
Lack of purpose
Capabilities should be created in isolation from the context in which they might be used. The capability should be reusable in a different contexts.
Decomposable
Capabilities can form a hierarchical structure. Higher-level capabilities can be decomposed into lower-level capabilities.
Capability verification – 4-step validation
How would you know if your capability is a true capability designed by definition? You can apply 3-step validation.
Step 1: Time travel
Ask yourself questions: how this capability was done 10-20 years ago? How this capability will be done, or the same outcome will be delivered 10 years from now? Use your imagination. Your answers should not change the name and meaning of business capability. If you noticed that your capability was changing in time, you probably miss some better abstraction.
Step 2: Ask for a favor
Could I ask some other role/person/actor/system/robot to deliver the same outcome? Has it changed the name or meaning of your capability?
Step 3: Different customer and different context
Can you imagine using your capability in a different situation/setting/context? Could you use a cleaning service, not in the apartment but also in the office? You should be able to do that.
Step 4: Capability as a product
Could you create a small company that has a purpose to provide just this one capability? Can you imagine how you will market it as a product? Could it be outsourced to another company?
Key takeaways:
Business Capability
- can be described with the sentence: “X is an ability to…”
- is an abstraction
- is defined by its outcome
- is a standalone product or service
- is a combination of Roles, Processes, Information, and Tools
- is stable, unique, lacking purpose & decomposable
- can be verified with 4-step validation
Links to articles from series:
Business Capability Modelling Overview (article 1)
Business Capability in-depth explanation (article 2)
Business Capability Model and its use cases (article 3)
Business Capability Modelling workshop recipes (article 4)
