Business Capability Modeling

Business capabilities and business processes are usually regarded as different things. A business capability describes a potential or an ability for achieving a certain goal or outcome whereas a business process describes the order and logic of activities required to create a product or service for a customer. In that sense, business processes can realize capabilities, usually in combination with other resources, like people, technology or information.

Capability management is used within the military context but also found its way into general enterprise architecture management where it can serve as a concept both business and IT practitioners can relate to. So you should be able to find articles about capability management in these realms. Specifications for DoDaf, NAF or ArchiMate will also include references to the capability concept.

Thank you very much. Yes, I also know these definitions. But I need it more, not to say very, precise. If you look at these definitions, there is also a parallel:

"A business capability describes a potential or an ability for achieving a certain goal or outcome."

"A business process describes the order and logic of activities required to create a product or service for a customer. "

The creation of "a product or service for a customer" is also an outcome or goal. To perform a process step is also a capability, isn't it?

If you have a look at "leanIX - business-capabilities-Whitepaper.pdf", p.2: "Recruit  talented employees” is called Capability. Why is it not a process (Activity to an Object) or an element of a value chain (a business process without processing logic)?

To perform a process step is not a capability. You employ a capability to perform a process step. So the capability may be, that you have the necessary skills and resources to perform s.th., e.g. a certain process step. The fact that you employ the capability in a process step in the context of a process is something you would document at the process step in the manner "capability supports process step". Example: You have a capability "Print document", which supports the process step "Print invoice" in one process and "Print delivery note" in another (part of the) process. The capability is realized through a printer in conjunction with some print server services you don't want to detail every time you print any document. You may view capabilities as "functionality as a resource". You don't care in how many places "Print document" will be used. You might care. If you report on the usage of the capability "Print document" you get an overview of how many processes still rely on paper production.

You may want to describe the process to deliver a certain capability. Then the capability comes close to the concept of a "Business service". A "Business service" adds a well-defined interface (including SLA) to a capability. You see that you can describe capabilities at different levels of granularity, which is why you may describe a hierarchical capability architecture. My example was very granular.

Why is "Recruit talented employees" a Capability and not a process? You certainly need a process to be able to recruit talented employees in a repeatable manner. The difference is, that you can describe a process and use the ability to recruit talented employees when the need arises just like you use an IT system to capture some data. You don't need to describe it again, you just refer to it and the corresponding talent recruitment process will be triggered transparently. Certainly you will need to provide some input described in the corresponding Business service to make it happen, but that's it.

With an architecture of your capabilities you may gain insights for make-or-buy decisions, if you lack a capability to realize a new process. You may also gain insights where you have marketable capabilities (aka Business services). For example Amazon developed a capability to quickly provision servers for peak traffic in the Christmas season. AWS is the result and became the new prime source of revenue.

Not sure if this helps, but I've read a few times that capabilities focus on the "what" of the organization whereas processes on the "how". In the "Recruit talented employees" example this means it is left open what means are used to implement or achieve this capability. If it were a process, the flow of activities would describe what to do in order to recruit talented employees.

I don't necessarily agree with this view because I'd actually be interested in how a capability is implemented. This would make it possible to better evaluate its current performance and devise improvements for the future. Same goes for processes, though.

Thank you very much for your very valuable feedback.

I am sorry, I understand everything what you are saying, but still do not understand the real difference.

Why is "Print document" a capability and "Print invoice" not? Is the usage of a document not also a HOW? Wouldn’t be “Creation of a proof” the correct capability?

You say that I can “view capabilities as "functionality as a resource. You don't care in how many places ‘Print document’ will be used.” This sounds that a capability bundles or groups similar process steps in different business processes. It is like a vertical and the business process is horizontal, running through or using different capabilities.

My understanding is that “Recruit talented employees" could also be seen as a part of a more general business process. ‘Recruit’ than ‘manage staff’ à ‘terminate’.

A lot of people recommend using a Value Chain as starting point (Capabilities at level 0). Are they really capabilities? For me a Value Chain reflects a high level Business Processes (I cite: “Value chains are large‐scale business processes”) or “Business Process Groups”. E.g. ‘Product Development’ / ‘Production’ than ‘Sales’ than ‘Customer Service’. “Sales’ starts with ‘Sales Planning’ and ends with ‘Pricing’ or ‘Order Management’. So this is also a process (at least a tendency). Ok, I do not say that I perform “’Product Development’ with CAD (‘create new product with a CAD diagram). But this is just another level of detail. As you see in in Porter’s value chain, the “parts” of the value chain have the name of capabilities (see “IT Management”, “Financial Management”). You do not see process logic, but a tendency.

If you would say a business capability is a process group (without process logic or sequence), than I would understand everything immediately. My understanding is that Capabilities can be modelled as a hierarchy of process groups. As soon as they can be modeled with flow logic (e.g., gateways in BPMN), they are Business Processes. Hopefully you do not tell me that I am wrong.

Hello,

I agree with everything you say. With my examples I apparently made too many assumptions.

"Print invoice" was my example for something business process related, which occurs in an "invoicing" process (or whatever greater entity comprising "invoicing" you may want to look at). "Print document" I understood as an IT functionality (not a "document" in the sense of some proof) which is completely business process agnostic. You provide resources to print s.th. on paper, including some IT infrastructure so your workstations can eventually talk to your printers in a different room. If you print season's greetings, invoices, contracts, quarterly reports is irrelevant, but any of these business needs will require a "print s.th. on paper" capability and justify having this capability.

You have a vast set of business activities in any typical organization. Processes and capabilities describe different aspects of these:

• Capability maps are usually captured as a hierarchical taxonomy, grouping similar business activities together, in a way that fits your industry. Nobody ever maps every single activity within a capability. We typically want to keep a capability map stable, so we can reason about e.g. which business processes, organizations, IT systems, business information, and policies support and constrain which capabilities and sub-capabilities, and where we might profitably optimize and address risks. 
• Business processes are ways of sequencing business activities in repeatable ways in order to achieve defined outcomes. In a typical hierarchical business process breakdown, each Function at the higher level is expanded into one or more lower-level sub-processes (varying e.g. by organization, geography, product area). We usually want to tinker with processes to meet changes in our business landscape, and need to accept different ways of doing things depending on context.

Thus, while both concepts are about organizing more-or-less atomic business activities, and the highest level of process model expressed as a Value Added Chain Diagram resembles a high-level capability map, capabilities are about stable classifications, whereas processes are about optimized sequences. In ARIS, you might want to capture supports relations between Business Capability and Functions, and possibly directly between Business Capability and Application System Type, Information Cluster/Entity Type, Organizational Unit &c. 

Occasionally, one capability map is not enough: there isn't a single right taxonomy for every purpose. When we talk about IT systems, for example, IT Capabilities might want to group activities into traditional subsets such as Enterprise Resource Planning, Customer Relationship Management, Communication & Collaboration, or Network Management – most of which are not necessarily the best Business Capabilities – in order to talk about IT strategy, roadmap planning and identify system landscape overlaps. But it's up to you whether that complexity is worth it. 

I understand and agree with your descriptions for Capability and Process as separate things, but I'm not clear if we should attempt to link them or not. 

If we have a Capability Hierarchy with 'n' levels, as we drill down to the lowest level...should we connect the lowest capability to its process? or maybe we should not even try?

Is there a concept of Vertical and Horizontal navigation in Aris? Should I be able to navigate from the highest level of a capability (the representation of a group of activities) down to the specific process for a particular activity (vertical) and also horizontally to document end-to-end processes across business units?

For example, documenting a horizontal process for 'idea-to-market' would be something like: 'Design Product' > 'Approve Product' > Build > Sale. This would require re-using the low-level processes defined for each low-level capability under 'Design', 'Approve', 'Build' and 'Sale'.

Does it make sense?

I would rather view things from the process perspective. Many organizations do horizontal processes like "idea-to-market" or "campaign-to-cash". If you already maintain a capability architecture, you may want to know, where the capabilities support the processes. So they model the capabilities as resources supporting the process. A typical place to do this is the function allocation diagram (FAD) or directly in an EPC. (If you use BPMN you would do it in the FAD). If you want to do the mapping at a more abstract level you could define FADs to value-added chains and map higher level capabilities there like the example you gave. (You see "high" and "low" level capability is already a very relative term. Don't start an argument on this. Choose the definition that is right for you. More detail comes at a cost. Your stakeholders decide on the benefit.)

The decision to do so or not depends on the stakeholders you have with concerns like

• which business processes does my capability support?
• which capabilities are obsolete?

You would also need to create awareness with the process analysts that they should document their usage of capabilities and encourage them to identify more capabilities.

When you navigate through your capability hierarchy you can ask any object where it occurs and if it occurs in a process or FAD. Alternatively you can look at the connections tab to see which "supports" connections the capabilities have. This way you can navigate to the process landscape and inspect the support. If you find a capability with no "supports" connection it is either obsolete or your process modelling is incomplete with respect to capability support. Or it is at a too generic level that you do not want to use as a process support.

Thank you M.,

Looking at things from this perspective is very useful.

Regards

Hello M.

I found this thread and the distinction between the two also very useful.

I want to zoom in on the below how I could achieve that

"If you already maintain a capability architecture, you may want to know, where the capabilities support the processes. So they model the capabilities as resources supporting the process. A typical place to do this is the function allocation diagram (FAD) or directly in an EPC."

I discuss at the moment for EPC how to bring the Capabilities into the process models.

Are there any thoughts on how that might be achieved within an EPC (Not BPMN) ?

Is there any futher information on the detail i.e. can the capabilities be defined as an object or is there another way ?

Thanks

Alistair 

Yes, certainly. Capabilities are objects available in EPC and Service architecture models. If I am not mistaken the connection is "Capability supports Activity" (or function/process step ... whatever you call it in your context). You might use the Service architecture models as structured libraries of Capabilities and then reuse them in your EPC just like you do with roles or application system types.

Observe that capabilities will have "library" owners responsible for their description. You can reflect that in the partitioning of your Service architecture/Capability architecture.