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.

Paul Harmon

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 Enterprise Alignment, 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 San Francisco. Paul can be reached at pharmon@bptrends.com


  1. Marco Mafra says:

    Thanks for sharing this article…. clear and concise !!

  2. This is fascinating stuff, Paul, and you have some great insights here.
    I’m not in any way trying to correct what you’ve done here, but I want to offer another perspective – around how architects often think about ‘capabilities’. We may find we’re still compatible because I may not be aware of some of the assumptions you make about what’s included in a process definition, but I’m not sure…
    I think it’s instructive to think about ‘capability’ in the military sense – at least partly because a lot of IT/biz architecture history actually has its roots in DoD etc work.
    Here, ‘capability’ specifically includes consideration of the assets required to achieve an outcome or deliver a service.
    If a ‘process’ describes a method for achieving an outcome, that’s not in itself enough – you absolutely can have a process for delivering some outcome, without having the capability to deliver it ‘on the ground’! You need a process, for sure, but you also need knowledge/information about the situation at hand, tools, physical assets, human resources, and so on. If you have the right process but the wrong assets or materials then you don’t have the capability.
    Just my 2c.

    • John Sacks says:

      As a business architect, former process engineer and retired military, Neil’s words resonate with me the most. Capabilities are used as a planning shorthand for all the stuff (people, process, technology, information) necessary to achieve a goal or task. In the military, capabilities (UTCs and higher order Force Modules) deliver an ability to perform specific services. Capabilities are used as building blocks to assemble a force able to accomplish the mission and are packaged this way because the military must be able to move its forces (people and equipment) around the world in a moment’s notice and agile enough to assemble a force tailored for the specific situation. Modern businesses don’t have the same requirements but can effectively use capability-based planning to ensure the proper resources are marshaled to achieve company goals.
      The other nuance I liked in Neil’s comment was his use of “outcome” and service as opposed to Paul’s use of “output” and process. I see services as the owner of outcomes, effectiveness metrics, and are customer-facing. Processes, as the “how”, are what internal managers worry about. Processes should be managed as efficiency plays and should be switched out or modified if the output does not drive desired outcomes.
      So I’m left with the idea that this article should have compared the relationship between capabilities and services, not processes.
      Just my 2c

    • Neil, Thanks for the kind words. I agree with much of what you say, but may disagree with some. You say: “you absolutely can have a process for delivering some outcome, without having the capability to deliver it ‘on the ground’! You need a process, for sure, but you also need knowledge/information about the situation at hand, tools, physical assets, human resources, and so on.”
      I assume this comment is a result of thinking of a process as a flow diagram, rather than thinking of a process more broadly. For me, a process includes not only a flow plan, but all the resources to execute it, including people, tools, etc., and the management support to make it happen. Can a process be deficient? Of course, but only because the people aren’t performing correctly, or they have the wrong tools, or the plan is suboptimal. So, process names and capability statements describe intent. The process describes everything that is done to realize the intent. I simply don’t recognize a distinction between having a process and needing people to implement the process — they are part and parcel of the same thing — getting the work done.

      I’m happy to respond to comments here, but point out that there is also a discussion on this column going on on the LinkedIn BPTrends Discussion site with lots of participants. Paul

  3. Excellent discussion! As a Sr. Level QA leader, I have seen many processes that are simply broken due tu inefficiency or stagnancy. The existence of a process doesn’t always mean it works. The capacity of a process depend upon its fluidity and ability to adjust to rapid change.

    This is a point that comes to mind for me when reading this post. Being clear about the quality of the organization’s capacity to sustain a process becomes a transformational need, if it is not operationally efficient or productive. Being able to articulate this opens opportunity for positive change and consultative advice!

  4. Paul, It seems to me that all of this discussion/defining “capability” is more than a little familiar. Back in the 60-70 we were talking about “function” and “functional decomposition”. But function turned out to be a slippery concept. The best, most elegant way of thinking about this, it seemed to me was IDEFO (nee SADT). A “process” in the SADT world creates outputs from inputs under “constraints” (controls) using “resources”. It seems to me now, that “capabilities” are one of those “resources”. To my way of thinking, focusing on capabilities may look like it will create the most flexible organization, but history seems to tell up, the best organization is the one that can produce the class of outputs required. 40 years ago, very few people would have asserted that electronics and software would one of the most “capabilities” required by an automobile?

  5. Hi Paul,
    really interesting article. This is the discussion I had long back with one of my business architect peers. I see processes and capabilities as two sides of the coins as you have rightly pointed out. I also struggle to relate to most of the architecture documentation with excessive focus on capabilities and breakdown of capabilities as Processes, People, System(assets), because a rightly documented process also provide the same details. This may be because it is easy to align capability to strategy and capability split-up in processes, people and assets to separate the concerns to invoke right change. Let us say a business strategy tries to enhance a particular capabilities but the capability breakdown in processes, people and assets will tell what is to enhance. Whether the process needs to be redesigned without changing/modifying too much of team or organizational set up or Systems needs to be updated etc. This may give clear focus and set right change initiative. I would argue that same can actually be achieved from processes also. But still not sure why business architects focus too much on capabilities than processes.

Speak Your Mind