Demystifying the Relationship Between Processes and Capabilities: A Modest Proposal

The BPM and BA fields were in quite the lather in 2014 about the topic of capabilities vs. processes. We recently printed out 196 pages of commentary about this by members of the popular BPTrends discussion group on Linked-In, triggered by several articles written by Paul Harmon, Bill Ulrich and others, and the debate is still raging. BPM and BA folks are generally a contentious bunch anyway, but this this string of opinion-swapping has set some kind of record for invective, snide retorts, supercilious corrections, hairsplitting, scalpings, pronunciamentos and other rhetorical flourishes. It's like an episode of “When Animals Attack,” only with pundits as said attackers.

So we have some trepidation about joining this circus, but we do believe the subject is an important one and that we may be able—at the risk of being attacked ourselves—to make some useful points. The main reason for making our own case about capabilities vs. processes is that as instructors of BPM courses for newcomers, we're running into many who are seriously confused and looking for clarification. When the opinion-makers are squabbling, it can be tough for novices to know what to think and they feel pressured to join a side. Yet we believe there is great value for ourselves as BPM and BA professionals to have a shared understanding of key terms and vocabulary, and there is also value for leaders of organizations to learn from us the potential synergy of capabilities and processes.

The BPM and BA fields were in quite the lather in 2014 about the topic of capabilities vs. processes. We recently printed out 196 pages of commentary about this by members of the popular BPTrends discussion group on Linked-In, triggered by several articles written by Paul Harmon, Bill Ulrich and others, and the debate is still raging. BPM and BA folks are generally a contentious bunch anyway, but this this string of opinion-swapping has set some kind of record for invective, snide retorts, supercilious corrections, hairsplitting, scalpings, pronunciamentos and other rhetorical flourishes. It's like an episode of “When Animals Attack,” only with pundits as said attackers.

So we have some trepidation about joining this circus, but we do believe the subject is an important one and that we may be able—at the risk of being attacked ourselves—to make some useful points. The main reason for making our own case about capabilities vs. processes is that as instructors of BPM courses for newcomers, we're running into many who are seriously confused and looking for clarification. When the opinion-makers are squabbling, it can be tough for novices to know what to think and they feel pressured to join a side. Yet we believe there is great value for ourselves as BPM and BA professionals to have a shared understanding of key terms and vocabulary, and there is also value for leaders of organizations to learn from us the potential synergy of capabilities and processes.

So what is the argument about? Essentially some significant leaders of the BA/EA field are arguing that the best approach for defining, analyzing and improving an organization is focusing on its capabilities rather than its processes. Processes are included processes in the scope of things to be analyzed and changed, but processes become subordinate to capabilities, the “how” a capability is executed. Well, that sets fireworks off among some BPM folks who have long championed processes as the essence of an organization's ability to perform—in other words, processes are capabilities. BA leaders strike back by saying that capabilities are quite different from processes, and in fact they are significant in the strategic realm, whereas processes are, after all, only tactical—all about the nuts and bolts of getting work done—and therefore by implication less important. But there seems to be more than disagreement going on here; many of the exchanges on Linked-In are couched in terms that echo the old Dan Ackroyd-Jane Curtin debates on Saturday Night Live that always ended with the catchphrase, “Jane, you ignorant….”) There is an undertone of resentment from the BA folks (“You process people think processes are so important”) and a bit of patronizing from the process folks (“You just want capabilities to be more important than processes because it's all you have”). And nobody, so far, has budged an inch.

So what's a reasonable way out of this impasse? We think by accepting that each side of the argument has a valid point or two, and that each has a few weaknesses. And we do believe a blend of both can yield both a unified viewpoint and a methodology useful to everyone. We believe that:

• A capability describes something an organization is able to do, given that all the right elements are in place. Borrowing from the military (which seems to understand the concept of capabilities better than anyone), let's say the U.S. military is expected to have the capability “to fight a war on at least two continents at the same time”.
• A capability is fundamentally about potential—about an organization's expected performance. A capability is about what should happen in the future given certain conditions or a triggering event (like a world war).
• A capability is big—a big deal, a strategic question, a complex combination of things. In order to fight a war on two continents, the military needs all kinds of things: It's going to need troops, of course, but also weapons and ammo and food and transport. Being or becoming capable is in large part about getting in place the resources necessary to act. And of course, the act itself—those are the processes, the step-by-step what has to be done and how it has to be done. A good word for all of these things in combination was suggested by George Stalk, who wrote about capabilities back in the 1980's. He called all these supporting things “infrastructure”.
• We also think it would be helpful to look back at the work earlier thinkers have done regarding the concept of organizational capabilities. Capabilities is not a new notion at all, but one that has been circling in business literature for a couple of decades, although these earlier ideas are rarely cited in today's online debates.

Pralahad and Hamel introduced the term “core competencies” in 1990.ⁱ They defined core competencies as “the collective learning in the organization, especially how to coordinate diverse production skills and integrate multiple streams of technologies.” Further, they noted that “if core competence is about harmonizing streams of technology, it is also about the organization of work and the delivery of value.” In other words, a broad definition of “core competencies” includes both processes and all the other things required to execute those processes—which sounds a lot like a capability and its supporting infrastructure.

Stalk et al made the argument that the essence of making an organization capability-based was to design and link its processes in ways that are hard and costly to imitate, thereby creating competitive advantage. To him, processes are the key organizational elements that need to be designed, linked and managed. He formulated the following four principles of capability-based competition:ⁱⁱ

1. Business processes are the building blocks of corporate strategy
2. Success depends on transforming business processes into capabilities that provide customer value
3. Investments in infrastructure is needed
4. Capabilities cross functions and CEO needs to be the champion

Both core competencies and capabilities (as defined by Stalk) emphasize strategy. While core competence emphasizes technological and production expertise at specific points along a value chain, capabilities are broader and can encompass the entire value chain. For example, the capabilities for Honda (discussed by Stalk in his article) include “dealer management and product realization.”

So our own position regarding capabilities and processes is based largely on Stalk's work, in particular his four principles and his contention that:

• A capability is strategic only when it begins and ends with a customer
• A capability is a set of business processes strategically understood
• Development of infrastructure to support a capability is a strategic necessity

What are the implications of this definition? To the BPM folks we would argue:

• Processes and capabilities are related but different from each other.
• Capabilities are about more than processes; therefore, they are not equivalent.
• A capability at a strategic level consists of networks of processes and all the resources to execute them. Such an infrastructure is highly complex, more than process architecture. Instead, a capability is a combination of processes and resources—an infrastructure of processes, technology, people, materials, equipment, management practices, policies and anything else required to create and deliver products and services and compete effectively.

Some BPM folks have argued that their definition of process encompasses all these things listed as infrastructure (i.e., that processes include the resources to execute them, and that if you don't include them then all you're talking about is “process design”) and that therefore processes are equivalent to capabilities. But if we look at Geary Rummler's last two books, there is little to support this viewpoint. Rummler wrote nothing about capabilities, but he did propose that organizations are composed of three dimensions—the resource dimension, the work dimension (i.e., the system of work processes) and the management system. It is the role of the management system to keep the other two dimensions integrated and balanced, which means they are not automatically integrated; they tend instead to be out of balance and it is management's unending chore to keep the resources appropriately deployed to the right kinds of work. And his final definition of process (“A process is a construct for organizing value-adding work…”) also makes clear that a process is a design and is not automatically populated with its appropriate resources.

To the BA/EA folks we would argue

• Capabilities are indeed strategic; so they should be few in number.
• Therefore, having huge “maps” of sub-capabilities and then attempting to somehow relate them to sub-processes via higher level value streams is a lot of monkey work and merely a word substitution game (is “Inventory Management” a capability or a process? Who cares?)
• Capabilities are derived from customer needs, not from internal wants or needs

To newcomers trying to understand the arguments and seeking guidance, we would say each side has tremendous value for companies, and that fact should not get lost in the haze of battle. Trying to have one side “win” is silly and distracting. A combination of concepts and methodologies is possible. A simple approach you can recommend to clients:

• Capabilities are about the potential an organization has (or should develop) to accomplish its strategies.
• Identify those few capabilities that give competitive advantage.
• Then define not just processes but all pieces of the infrastructure necessary to carry out the strategy.

We've just briefly touched on a lot of subjects and there is work yet to do, especially to define the elements of infrastructure to support a capability and outline in more detail a methodology that combines the best thinking about capabilities and processes.

ⁱPralahad, C.K. and Gary Hamel, “The Core Competence of the Corporation”, Harvard Business Review, (May- June 1990): 79-90

ⁱⁱStalk, George, and Philip Evan and Lawrence Shulman, Competing on Capabilities: The New Rules of corporate Strategy, Harvard Business Review, (March- April 1992): 57-68