Harmon on BPM: Processes and Capabilities

There has been a lot of discussion on the relationship between processes and capabilities. I can’t offer a definitive solution to discussion because some of the definitions of “capabilities” are incompatible with one another. What follows, however, is my take on what I believe to be the most useful approach to defining and using capabilities in a process-focused environment.

Let’s start with some definitions.

Process (Business Process). A Business Process describes how work is accomplished in an organization. The work performed in a Business Process transforms physical or informational inputs into outputs. A Business Process is comprised of a set of activities each of which may have its own set of activities. The complete set of Business Processes of an organization describes all the work undertaken by that organization. A Business Process may be comprised of highly structured and repetitive work or be loosely structured and exhibit high variation.

In other words, when we use the term “business process” we are referring to both large-scale processes, like value chains and value streams, and to small-scale processes, like tasks and activities. Similarly we are speaking of both well-defined procedural processes and loosely defined sets of activities used in “case management.” All are variations on business processes.

In essence, a business process describes how things are done, but it includes a description of the process output, which describes what results from the execution of the process. We name processes by combining a verb and a noun. Thus, for example, a process might be named: Make & Sell Pizzas. If we wanted to represent the process, graphically, we would picture the process as a rectangle with rounded corners and we would show inputs on the left and outputs on the right, as in Figure 1.

Figure 1

Capability. The Compact Oxford English Dictionary defines a capability as “the power or ability to do something.” In a business context, a capability describes something that an organization is able to do.

We name a capability by saying that an organization has the ability to produce something, or is able to do something. Thus, we might say that our pizza company has the (cap)ability to produce pizzas, or is able to produce pizzas.

Getting even more specific, a capability describes the ability to generate something that results from the execution of a specific process. Or, if you prefer, it describes what would result if a process were to be executed. Ultimately without describing the process, you won’t know what you mean when you say the organization is “able to produce a pizza.” The process describes the content of the capability claim.

Thus, a particular organization might say that it has the ability to produce pizzas. A capability does not describe how to do it, but simply states that an organization could generate a particular result, if an appropriate process were executed. We might modify Figure 1 to picture this, as in Figure 2.

Figure 2

Please note: We are not saying that a capability is an output or a specific result. A capability is an ability to generate an output or a result. Capabilities stand between processes, that describe how to do work , and results, that describe what is produced. Thus, capabilities are a kind of shorthand for describing something an organization can do. For graphic purposes we will find it convenient to represent a capability as an output arrow — which lies between the process box and the named output.

As a strong generalization, we don’t discuss capabilities much when we talk about process redesign or improvement. Capabilities are usually used in discussions of business architecture. They provide a shorthand way for business people to talk about what they want a group or organization to be able to do.

Some Corollaries

It is possible to describe abilities or results without specifying how to produce those results. This happens when an entrepreneur announces that he wants to create a company to produce widgets. The entrepreneur knows what he wants the new organization to be able to do, but may not yet know how to do it.

Similarly, it is possible to produce a desired result in more than one way. Thus, it’s possible to list some things that you would like an organization to be able to do, without knowing what process you will use to produce the desired result. It’s possible to speak of an organization that can deliver pizzas in more than one way – as, for example, via bike messenger or via delivery truck. Or, perhaps the company will subcontract delivery to another organization. Thus, it’s possible to create a list of the capabilities an organization might have, or desire, without having a list of the processes required to produce the desired results. This can be useful when managers want to talk about new projects. Such a manager might say something like: “If we are going to be able to produce widgets, we will need to be able to machine both aluminum and plastic parts.”

There’s nothing wrong with using capability statements as a kind of shorthand in a management discussion. Eventually, however, one will need to get more specific and define how one will machine aluminum and plastics parts, and then set up some trials to be sure you can, in fact, produce the desired results in an efficient and consistent manner. In other words, you might start with statements of capabilities and talk about desired results, but sooner or later you will need to shift to talking about how the processes needed to assure that you really can implement your desired capabilities. This is especially important when one is concerned with improving such a process, or considering ideas to replace or significantly change the process, or to understand the potential inherent to a process, i.e. to apply capabilities to do new things.

Processes, Capabilities, and a Business Architecture

We already said that the term “capabilities” isn’t much used in discussions of process redesign, but it commonly used in discussions of business architecture. Let’s consider how a we might use either a process or a capability in the creation of a business architecture. In Figure 3 we picture a bank process architecture. This architecture pictures all of the level 1 and some of the level 2 processes in a single value chain: Provide Customer Products and Services.

Figure 3

What is really important here, given our discussion of the difference between processes and capabilities, is that when we work with managers to develop architecture, we do not define >how the various processes will work! Instead, during our initial discussion, we simply use what we informally refer to as process names as a shorthand for the processes that make up a value chain.

This brings us to a key point: How is a process name different from a capability? We could quibble about the fact that process names emphasize how we do things (verb-noun) and capability names referring to something the organization can do (able to do x), but that’s really pretty trivial distinction at the level of abstraction we are dealing with here. In fact, neither a process name, as used in most process architectures, or a capability statement describes how something is done. They simply indicate that the organization is or should be able to do something. In other words, at the business architecture level, process names and capability statements are essentially the same!

I think one of the reasons that there has been so much confusion about processes and capabilities is that people haven’t been clear what they are actually talking about. Many of those contributing to these discussions come from the IT side of their organizations, and tend to think of processes rather concretely – as specific flow diagrams that software developers might automate. Thus, for those individuals, something more abstract – like capability statements – is needed for architectural work. Many process people, however, have been developing business architecture for decades – check Geary Rummler’s book, Improving Performance, which was published in 1990 if you are in any doubt of this – and process architects have always used process names just as I have described them above. When someone starts to talk about “processes” as if they always describe how, and ignore the fact that process people often use process names as a short hand to suggest what an organization is able to do, then you have confusion.

In fact, process names and capability statements are just two different ways to describe the same thing. Consider Figure 4, where I show one bit of the business process architecture from Figure 3. The diagram shows a hierarchy. A level 1 process: Create Product/Service, is composed of three subprocesses, which are pictured inside the larger process box. Below, I have shown how there is one “level 1” capability associated with the level 1 process and there are, as well, three “level 2” capabilities, one associated with each of the subprocesses that make up the level 1 process. Below the process figure, I show how one could create a map of the relationship between the three level 2 capabilities and the level 1 capability.

Figure 4

Once we focus on how people are actually using the term “capability” and what they are actually doing when they generate hierarchies of capabilities, we find that they are doing exactly the same thing that most process analysts do when they create a business architecture using “process names.”

Obviously many process people will wish to continue using an approach that we have used for decades. We prefer to build business process architectures using “process names” to designate the processes an organization must control. Others, unfamiliar with using process names to describe high level processes, apparently prefer to speak of “capabilities.” As long as everyone realizes that it doesn’t make any real difference – that both are just a shorthand way that business people can discuss what they want their organizations to be able to do, — there shouldn’t be any problems. Since it doesn’t make any real difference in practice, we can only hope that the arguments between those who prefer “processes” and those that prefer to speak of “components” will blow over in the near future and we can all get back to helping business organizations improve their performance.

• Bio
• Latest Posts

Paul Harmon

Executive Editor and Founder, Business Process Trends In addition to his role as Executive Editor and Founder of Business Process Trends, Paul Harmon is Chief Consultant and Founder of BPTrends Associates, a professional services company providing educational and consulting services to managers interested in understanding and implementing business process change. Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business problems. He is the author of Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures (2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as a senior consultant and head of Cutter Consortium's Distributed Architecture practice. Between 1985 and 2000 Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component Development Strategies. Paul has worked on major process redesign projects with Bank of America, Wells Fargo, Security Pacific, Prudential, and Citibank, among others. He is a member of ISPI and a Certified Performance Technologist. Paul is a widely respected keynote speaker and has developed and delivered workshops and seminars on a wide variety of topics to conferences and major corporations through out the world. Paul lives in Las Vegas. Paul can be reached at pharmon@bptrends.com

Latest posts by Paul Harmon (see all)

• Harmon on BPM: A General Management Model - July 4, 2022
• Processes and Capabilities - July 4, 2022
• Harmon on BPM: The Scope of Management - June 6, 2022
• Should Every Manager Be a Process Manager? - June 6, 2022
• Harmon on BPM: Management Processes - May 2, 2022