Hans-Christian Grung-Olsen alerted me to an article in BP Trends by Paul Harmon titled Processes and Capabilities.

So first to summarize Paul Harmon’s excellent article. He points out that a process is a sequence of work steps that produce some valued outcome. He used pizzas as an example. The process – take dough, shape it into a pizza, place on a pizza tray, add tomato, cheese and toppings, cook, take it off the tray and place in a box, give the box to the customer and take the money – involves a series of work steps. The outcome is a pizza in a box in the hands of the customer. The “capability” is the ability to deliver this outcome repeatedly so that a series of customers can leave with pizzas in a box.

A capability is not a process and it is not an outcome. It is the ability to create the outcome – the pizza in a box paid for by the customer. It is not the ability to execute the process because it may be possible to create the outcome with a different process. For example, “buy prepared pizza, cook, place in box, give to customer and take money”. The outcome is the same (well the pizza might not be quite as good), so the capability is the same, even though the process is a bit different. Of course, if we defined the outcome as a “hand-made pizza, prepared in front of the customer, in a box ….” then the first process is probably the only one possible. The more detail that you put into the description of the outcome, the more likely you are to have only one process that will deliver it. So “a hand-made pizza, prepared in front of the customer, with mushrooms and peperoni, cooked for 8 minutes in a wood fired oven, served in a recyleable box, paid for by credit card” is almost a statement of the process. The capability is then the ability to execute this process.

“Capability” has become an attractive term because it is possible to define the outcome you want to be capable of delivering without defining the process steps or the organisation. This makes it easier to identify similar capabilities in different parts of the organisation and to centralize them, reducing duplication; standardize them, building on best practice; and invest in innovation, enabling even better practice. A “capability model” is a tool that helps with this thinking. It involves grouping like capabilities, such as “pizza production management” or “take money management”.  By grouping capabilities, the model makes it easier to identify opportunities to centralize and standardize. The “capability model” is particularly helpful for IT Functions because a single IT application is a capability that may have multiple use cases in different parts of the organisation.

The “capability model” tool has been drilled into many business and enterprise architects and others, and is widely used.  But few are aware of its downsides. The biggest problem comes from taking capabilities away from their process flow context and grouping them by capability type.

Lets take the pizza example. One of the sub-capabilities is “take payment”.  Even at this level of detail, there are different possible processes for the same outcome – payment by cash giving change, payment by credit card with a tap, payment by credit card with a pin, opening an account for credit, etc. If we abstract the “take payment” capability from its process flow context and group it with “take payment” for other lines of business (e.g. coffee or a bag of groceries), we can easily fall into the trap of building a “take payment” capability that is “centralized”, “standardized”, “more efficient” and “lower cost”, but which fails to take into account the particular process flow context of each line of business.  Think about the pizza customer standing at the counter, salivating over the delicious pizza aroma.  He or she will be upset by any payment process that does not allow him or her to gobble the pizza before it starts to cool. So, it is vital for the pizza area to have a process that is local and can cater for those who have cards and those who have cash and maybe even those who have forgotten both, but are willing to deposit their car keys while they eat the pizza and then find a friend to lend them the cash to redeem their keys.

My observation is that the loss of context that can occur when capabilities are grouped in a capability model often leads to over centralization and over standardization … and, hence, a less good architecture or operating model than is needed.

So, what is the solution? My solution is to replace capability modelling or mapping with a tool called “value chain map”. In this tool, every work step is recorded in its process flow along with clarity about who the “customer” is for that process (often an internal customer) and what the “value proposition” is for that customer. So the pizza example would have “member of the public who wants to eat pizza” as the customer and “a hand-made pizza, prepared in front of the customer, with mushrooms and peperoni, cooked for 8 minutes in a wood fired oven, etc” as the value proposition. The work steps in the process would be similar to those already described. I call this combination – process, value proposition and customer – a value chain. Others call it a value stream. In lean 6 sigma, it is just a process. Labels here do not matter much.  What is important is that each process flow is clear.

Other value chains for other value propositions to the same customer or to different customers are laid out alongside this pizza value chain to form a value chain map. For example, there might be a value chain for a mug of barista prepared coffee. There might also be a value chain for a bag of groceries. The work step “take payment” appears in all three value chains … and, when laid out in a value chain map, the three “take payment” work steps can be positioned as a column – one under the other. The rows in the map are the three process flows, one for pizza, one for coffee and one for a bag of groceries. The columns are “capability” columns: a group of work steps that have similar outcomes. The “take payment” capability column could be labelled “take payment management”.  What is important is that each of the three “take payment” capabilities is presented within its process flow and value proposition context, so that the particular customer need and the collaboration with the steps before and after is clear.  

Presenting all the “take payment” steps in a column, raises the same questions as a capability model: should the “take payment” work steps be centralized and standardized or not?  The alternative to centralization is for the barista to take payment for coffee, the pizza chef to take payment for the pizza and the check-out person to take payment for the bag of groceries. If the decision is to have three different payment points for the three different products, it might still be possible to centralize or standardize the technology or processes used. In other words, the value chain map achieves the same grouping as a capability model, and raises the same questions, but in a way that keeps each capability in its process flow context. This helps the architect or designer think about the coordination problems or customer service issues that might arise from centralization or standardization.

The other power of the value chain map is that the default position is not to centralize or standardize.  The logic for this default position is that it is normally easier to deliver the value proposition – “hot pizza in a box” or “barista coffee” – to the total satisfaction of the customer and to make a profit, if all of the activities in the process are designed with the customer in mind and managed by someone who has total responsibility for customer satisfaction and profit.  This person then has the power, for example, to change the “take payment” process, if the local cash machine is not working, and his or her customers still want pizza, but have no immediate way of paying.

Given this default position (build separate capabilities for each work step in each value chain), capabilities should only be standardized or centralized when the gains in terms of cost reduction or increased customer satisfaction are large enough to offset the risks that centralization or standardization will constrain operational flexibility in a way that increases cost or loses customers. 

Assessing the costs and benefits of moving away from the default position is often tricky because on one side it is usually possible to identify tangible cost savings from centralization or standardization, while on the other side the negatives are often risks that are hard to put a figure on (the risks from loss of operational flexibility or reduced cooperation between steps in the value chain).  Tangible savings on one side and difficult to assess risks on the other can bias the cost benefit analysis towards choosing centralization.  By having a default position of not centralizing unless the gain is significant and undisputed, and by keeping each work step in its process flow context, the bias is reduced if not eliminated.  

Without taking this example any further, I hope that you are thinking what I am thinking. If you have one central place for taking payment and one standard process, you may have pizza or coffee customers standing in line behind customers with trollies of groceries, while their pizza or their coffee cools and their frustration mounts. A decentralized and non-standardized approach, possibly one that involves payment in advance while waiting for the pizza to cook or the coffee to brew, might be better. Of course, a decentralized and non-standardized process, does not mean that some of the tools used (the credit card machine or the cash machine) and some of the supporting IT applications (for example the app that transmits the data to the leger) should not be standardized and centralized.  But the default starting position would be not to do this, unless the gain is significant compared to the risks. 

The problem with the capability model tool is that it implies the opposite default position: it implies that the capability should be standardized and centralized unless a powerful argument can be presented to show why it should not be.  Now, in theory, intelligent people using either approach, should come to the same answer. However, in practice, the tool that you use can bias your orientation and the choices you make.

While I have never worked in a pizza parlour, I have experienced the pain of over centralization and over standardization, even in a business school, which is normally a highly decentralized environment.  I was running a portfolio of courses that required marketing.  But “marketing management” had been centralized and standardized, which meant that my courses never got the marketing that they needed – and I know this because previously I had control of my own marketing.

But I can also see the world from the other end of the telescope.  I recognise that, if you work in IT, you will have experienced the pain of too much decentralization, too many applications with similar capabilities and too much cost.  So, it is not surprising that capability models are attractive tools to enterprise architects: these architects are typically looking for opportunities to standardize and reduce duplication.   

My warning against the use of capability models, therefore, is probably aimed more at business architects and operating model professionals than at enterprise architects.