A capability is the ability to execute a process

This paper might be a little controversial because I’m talking about business capabilities and how they relate to business processes, a topic that causes more than its fair share of confusion and debate.

Get some process practitioners and enterprise architects together and ask them to explain business capabilities. Take plenty of popcorn. It’s likely to be quite a show.

I’ve been around too long to think I’ll solve those problems either here or at any other time, but at least I can share my views. The short version of which is that a capability is no more, and no less, than the ability to execute a process.

Some definitions

As with so much of process work – and the rest of life! – definitions are important and many disagreements stem, at least in part, from different understandings. Let’s try to avoid that problem here and establish common ground based on agreement about the basic concepts, or at least an understanding of where we agree to disagree.

I’ve spent most of my working life talking, thinking, recording, and writing about process-management. Everything needed to understand my process view is freely available here on my website. Two summary points here to give context.

Firstly, when I think of a process, its not just a series of activities. As well as the activities there are all the elements that are used to execute and manage the process – people, systems, data, applications, paperwork, buildings, trucks, regulations etc. My view of a process is not just about boxes and arrows with some directional logic. I was very fortunate that my first exposure to process modeling was a genuine database/repository platform and not just a drawing package, and we could capture and consider all the elements that allow a process to deliver value.

Secondly, the purpose of all our process work must be about demonstrably improving organizational performance in valued ways. The purpose of process is performance. Process documentation is a tool, not an outcome. Processes deliver value to stakeholders; they execute organizational strategy. Process management and improvement activities are only authentic if they are improving value delivery and clarifying strategy. Two videos you might find useful here and here.

The Business Architecture Guild in its BIZBOK® Guide defines capability as “A particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.”

In the TOGAF® Standards published by The Open Group, capability is defined as “An ability that an organization, person, or system possesses.”

Those are two definitions from leaders in the enterprise architecture field with lots to say about business capabilities. They are clear and agree that a capability is an ability or capacity possessed by an organization (or other entity) that is required to achieve a particular outcome. It’s the ability to do something consistently and well.

Of course, the purpose of any conversation about capabilities and processes must be to find ways to enable improved organizational performance, not just to get better definitions. Our work must be about performance, not semantics.

It’s the process, isn’t it?

For this process guy listening to these conversations, I hear that a capability is the ability to execute a process. The only way we “do something” in our organizations is via the execution of a business process. Maybe you’ve got a different view, but my process mindset view takes me to that point all the time. Here’s another video.

This is not to dismiss or denigrate capabilities. We need to be capable of executing our processes. That’s what it’s all about.

An example

Here’s an example. You might say an organization has a capability called Partner Management. We need the ability to work productively with partners to deliver the mission. The process view of that in my terms would be a process called maybe Nurture Partner Relationships, or maybe it’s Maintain Partner Ecosystem.

If we’re managing Nurture Partner Relationships, actively managing it in the active process management terms that I describe in many places including here, what would modelling and managing a capability add?

I don’t see the value. I don’t see a need. If we’ve defined the process architecture in the right way and we’re actively managing high impact processes, then I think we are already achieving what is needed. We have identified the work that needs to be done along with all the resources necessary, we’ve set PKPIs and targets, and we are tracking the process operation and context looking for performance gaps. What’s missing?

We do need the capability to execute Nurture Partner Relationships, of course, and we’ll measure it and understand what’s working and what’s not working and how we can make it better. We’ll focus all our powers of analysis on innovation on the performance of the process looking at all the resources it uses and the context in which it operates.

In actively managing a well-defined process, aren’t we achieving what is needed?

And, not or

We do need a process architecture. A capability architecture and model can be useful. No matter how functionally flexible an organization is, or wants to be, there will also be an organizational chart. They are all different perspectives of the same organization. There’s no equivalence between them. We might derive each in various ways from strategy, but it doesn’t mean one is just a reworked version of the other. All those artifacts are important, useful, and different.

Then the magic happens?

In discussions about capabilities and processes we sometimes see what I call the magic arrow. We’ll see a capability, perhaps a whole model, and then an arrow that goes off to one or more processes. The implication is that the capability decomposes (or at least somehow resolves itself) into a process. And I’m never sure what that really means or how it happens. It works in PowerPoint but in real life, not so much.

The bad news is, as always, there is no magic.

Certainly, I don’t see processes being decomposed, or derived from, from capabilities. The highest-level processes reflect the promises made in the strategy, and then we decompose processes down as many levels as is useful.

When I’m putting together a process hierarchy or architecture, I start with the strategic intent documents (vision, mission, purpose, mandates, objectives etc.), not just with a capability model. They indicate promises we have made to customers and other stakeholders and those promises are fulfilled through the proper execution of our processes. Of course, there’s a video.

If a capability model already exists, we’ll use it as part of the strategic situation analysis documentation. If a capability model doesn’t already exist, I would not feel the need to create one.

Advantage process

As you may have gathered by now(!) I prefer to manage processes rather than capabilities. I have no problem with capability modeling and management as tools to help develop better understanding of an organization’s purpose and strategy, but I go straight to processes to manage strategy execution and value delivery.

Focusing directly on active process management has these advantages:

• All management is about achieving targeted levels of performance. Processes deliver organizational performance so focus on them.
• Processes reflect value flows; they show how an organization delivers on its promises to its stakeholders.
• Processes at every level usefully decompose into subprocesses. Every process has at least two subprocess – it’s processes all the way down!
• Processes are direct and practical, not abstract; their meaning can be easily described since every process exists to deliver known outputs.
• A process architecture provides a coherent hierarchical picture of the whole organization showing how the organization achieves strategy execution.

And that can all happen without mention of capabilities.

In summary

How do we summarize?

A capability is the ability to execute a process. That’s clear and even if the language varies, we all seem to agree with that.

A capability model/architecture is useful. It can provoke productive conversation about what the organization is about. I find a capability model useful, but not mandatory and it’s never, for me anyway, a replacement for the process view and related work.

A capability model is a different view, a different perspective of the organization. I think of a capability model and related artifacts as being part of the statements of strategic intent where it fulfills a valid purpose in defining the organizational abilities that we need to keep this show on the road and make it successful.

When I help clients establish and operate process-based management, we go to the full set of whatever already exists in the portfolio of statements of strategic intent and that can be quite variable in different formats. A capability model might be included.

That strategic intent portfolio might be a couple of paragraphs or a library of material. Whatever form it takes, that’s where we start because we want to know what promises have been made because it’s our processes that are going to deliver on those promises.

Capabilities can be very useful, and many people get lots of use out of that.

Personally, I’ve never found that I must have capability definitions to establish and sustain process-based management based on the principles and practices of active process management as I have spent 20 years developing and documenting.

And one more time – here’s a video.

Do you disagree? Am I lacking a capability?

John Murray suggested this topic. If there an issue you’d like me to cover, let me know.