Bizbok 5.5 from the Business Architecture Guild mentions an interesting concept that I’d like to discuss here: the capability instance. I’d like to caution that this description is a concept rife with conflicts. I’ll explain in a moment.
For those of you who don’t have a copy of the Bizbok 5.5, first off, get one. But for the sake of expediency, the description I’m referencing comes from section 2.2. in a subsection titled “The Capability Instance”
“As a rule, capabilities exist in multiple business units and enable multiple value streams and value stream stages. As a result, a useful concept called a “capability instance” has emerged that allows practitioners to associate unique attributes, such as effectiveness or automation levels, with specific instances of a given capability in practice. A capability instance is defined as “a specific realization of a capability, as it exists or is envisioned to exist, in the context of a given business unit, value stream, or other situational context.” In practice, identifying capability instances provides the business architecture practitioner and consumer with flexibility to assign unique heat map values and other ratings to a capability based on its effectiveness or impact within a given business unit or value stream.”
OK… so why my concern?
Almost a decade ago, I set out inside Microsoft to stop the raging debate about the definition of capabilities. At the time, our business architecture team was using the concept of capabilities derived from the Microsoft Motion framework (very much like the definition used by the Business Architecture Guild today) as composed of People, Process, and Tools. (We added “Information”). However, the Business Process Innovation team was busy creating certifications for Six Sigma that describe processes as having people (in roles) and tools under the activities. They saw no value in the concept of a capability at all. I got my Six Sigma Green Belt and saw the problem. Their use of language was sufficiently different from the words used by Enterprise Architecture that our two teams were creating problems for one another.
During this time, I blogged rather extensively on the difficulty of aligning these concepts. I went back to source materials from such thought leaders as Michael Hammer and Michael Porter and held lengthy conversations with teams involved in business process management as well as business architecture.
The results, which I presented at the BPM conference at Stevens Institute of Technology, was that we could bring together business process management and business architecture if we recognized one very important principle: a business capability is a concept. It cannot be realized. A business process is a conceptual description of a realizable set of activities. A process description is only interesting once the process is realized. They are different in the ability to realize them.
A business capability is a concept. It cannot be realized.
In that frame of mind, when I discuss measurement of a capability, I measure the maturity of the constituent elements. I measure the people, the processes, the tools, and the information independently. The capability measurement, if used, is a score of these four individual elements.
(Bizbok uses different framing: they now view a capability as composed of Organization, Value Streams, Resources, and Information, a distinction that I’m stepping over for now… a deeper discussion for a different blog post).
The point is that the notion that you are measuring the effectiveness of a capability is silly. You are measuring the effectiveness of a business process. You are using the concept of a capability to allow you to compare completely distinct business processes that have similar impacts on the organization.
The moment you cross the line and allow yourself to view a capability as something that can have an instance, you also cross the line between “what” a business does, and “how” a business does it. The value proposition of the business capability concept collapses if you cross that line.
I soundly reject the notion of a capability instance as a mechanism to measure and apply attributes that belong in the world of business process measurement and management. If there are other uses of the capability instance concept, I’m open to them.
Note that it is OK to create a score of a capability in a specific instance. Is that a measure of a capability instance? In a way, yes. For example: the score of an accounts payable capability in customer refund handling is distinct from the score of an accounts payable capability in vendor management. By comparing these scores, am I measuring the effectiveness of a capability instance? No. That’s a measure for the underlying process. It’s a carful distinction.
Make the distinction.
Interesting blog. Good explanation. I wonder how you would measure the maturity of a capability. And how to deal with that.
Btw when talking about capability instance I’d rather think about the organizational concept …. Role having a goal major tasks and skills and personal profile.
Hi Harry, A capability is different from a capability instance. It is the global concept of a capability. So if the organization has multiple instances of the level 3 capability “acquire customer”, then the maturity of that capability is the maturity of the organization as a whole to acquire a customer, not the maturity of one specific instance.
So what if we are discussing a retail bank. One line of business is for retail checking accounts. In that context, “acquire customer” is a capability that is fulfilled through marketing and the placement of locations convenient to retail customers (in the US, it is not uncommon to see branches of a bank in a grocery story. These are primarily locations for acquiring customers for checking accounts.
A different line of business would be home loans. Acquiring a customer is often more successful if the customer already has a checking account at the bank and trusts the bank. So in this context, acquiring a customer is often a matter of closed marketing — marketing to your existing customers. Of course, there are customers who are acquired through other means, such as purchasing a loan from a broker and marketing to non-customers who then get both a home loan and a checking account.
How do you compare the maturity of the “acquire customer” capability across two very different lines of business? To be fair, you probably don’t. You CAN compare some elements of that capability, and I would suggest that it makes more sense to break the capability down one more level and compare those elements. How well do you do acquisition planning? Acquisition scenario analysis? Online acquisition tools? etc. At the level of “customer acquisition”, comparison, and therefore enterprise maturity assessment, is neither meaningful nor useful.
How do think processes are supposed to relate to a ‘capability instance’? Can you or should you have ‘process instances’? Or should a process be the same at the high level, with multiple instances at a low level?
Be careful of assuming that the mappings we have discussed as being included in a capability are, in some way, database records. There’s a big jump from the conceptual notion of “processes map to capabilities” to the physical “name of process mapped to a capability”. In a mature organization, processes are managed in a process hierarchy that is typically broken down by the various processes in the value stream. Therefore a process called “agreement management” that is part of the “sales” process is distinct from the “agreement management” process that is part of the “vendor onboarding” process. How they are differentiated is a matter for implementation.
It is valid to ask: does the organization have a mature “agreement management” capability and it is rational to measure the maturity of the two above-named processes differently. It would be a rare company that would have similar processes for a sales team as for a vendor onboarding team, especially if it is a supply chain vendor or if the company is offering a cloud service and the vendor in question is a core dependency for the cloud service. The level of discipline and due diligence is an order of magnitude different than that done for an agreement with a customer.
So what is the maturity of the “agreement management” capability if we do not have capability instances?
First off, I’d question whether “agreement management” is actually a business capability. Certainly not at Level 1 or Level 2. But assuming, for the sake of argument, that it is, let’s consider the implications.
We can map (and measure) the process “sales – agreement management” to the agreement management capability.
We can similarly map (and measure) the process “vendor management – agreement management” to the agreement management capability.
Inside a process we include the people who perform *that* process and the tools used for *that* process. The maturity of *that* process can be determined because the process is tangible. It is implemented.
The measurement of the capability is necessarily distinct from the multiple processes mapped to it. The measurement of a capability should be associated with strategic values of the enterprise: importance, risk, repeatability, compliance, effectiveness, efficiency, and security. We can measure these in the case of a single process mapped to a capability or multiple processes mapped to a capability. We can discuss the strategic importance of a capability independent of where it is implemented, and the risk of capability failure even though that failure is likely to occur in one of the mapped processes, and not at the capability level itself.
Processes are implemented. There is no concept of a process that is not implemented. Even if the first iteration of the process has not occurred yet (future process), processes are always tangible. They have a context, and actual people and tools are aligned to them. Capabilities have no such constraint. Therefore, the answer to the question “would you have a process instance?” is “by definition, yes.”