Processes and capabilities

My opinions on processes and capabilities have changed.  That doesn’t sound like a sesmic shift, does it ?  That sounds like I’d been considering it and I’d changed my views based on new evidence.  People are allowed to change their mind, aren’t they ?  But that’s not how this felt; this felt like a fundamental realignment, like the sun started to go around the moon or mice started to chase the cat.  I’d been talking to people about capability models for years, eschewing process models and I suddenly found capability models to be just a tool, not the answer that I’d always thought that they were.  So how did this come about ……….. ?

I was challenged recently to build a process architecture, from scratch, for an existing organisation and to make use of a team of business analysts to capture the more detailed processes.  I quickly sketched both a level 0 process model and a level 0 capability model and it was immediately clear that only the process model described what the organisation did and was useful for the business analysts.  We used the business model canvas as a level 0 process model.  I should have drawn a rich picture, framed for posterity, but laughter in the room curtailed my early attempts at art.  The canvas clearly showed the organisation did; it was immediately understandable and comprehensive.  We then moved on to level 1 – a set of value streams, ala Porter.  Level 2, the first ‘real’ processes, were the steps necessary in each value chain and I left the business analysts to define levels 3-5, while I started the operating model.

So what’s the use for a capability model ?  The answer to that become clear as I reviewed the level 4 processes some time later.  The processes were mis-leveled, but that’s to be expected.  What I hadn’t counted on was the ingenuity of those interviewed to capture the business processes.  They’d managed to make very similar process steps sound completely different between divisions: the levels were different, the steps were different and the nomenclature was different.  Whilst removing the dichotemy was one of the reasons that we’d got the job, I was stuck.  I couldn’t change the processes but I needed to demonstrate the similarities bewteen them.  What I needed was an independant framework that I could use to demonstrate that the processes were similar across divisions.

So we mapped each process step to a (set of) capabilities.  I’d used the capability model in the TM Forum eTom Frameworx as a start-point and that was useful to demonstrate to the business analysts what the difference was between a capability and a process.  Once we’d reviewed the capabilities necessary to deliver each process step, we were ready to ‘discuss’ them with the process leads and explain the similarities in their processes.  Showing the process leads that the capabilities necesssary to deliver the processes were identical allowed them to see that the processes should be similar too.  Objective achieved !

But what of the capability model ?  Is it just a tool to clarify processes ?  Well yes: in this case, it was.  However, if I’d been asked at the outset to define the capabilities that the organisation offered, I would have started with level 1 being a capability map and the decomposition would have uncovered which processes delivered which capability.

So, in summary, it’s not necessary to chose between processes and capabilities: pick the approach that delivers the right output.  In this case, in the age of the ‘digital organisation’ I was probably asked the wrong question: I should have been asked to define the capabilities that the organisation offers to market, not look inward at the processes and ignore the customers.

Organisation Design from the Capability Model

It seems that so many changes, at the level that Enterprise Architecture is involved, trigger changes to the people element of capabilities that all Enterprise Architectures should have a very good understanding of the Organisation Model.  The term ‘Organisation Model’ can be used to cover many different things so, for this post, I’ll restrict the definition to be ‘Organisation Structure’: things like teams, reporting lines, employee measurements.  It’s always easier to change technology and processes than it is to change people.  People change takes so much longer than swapping out a particular technology but is an often forgotten component of ‘Change’.  The Organisation Model is one of the first documents that is drawn up, either conciously or unconciously, when a new Enterprise is being created and, arguably, remains the most important during the life of the Enterprise.

How do you design a whole organisation, a complete Enteprise ?  Which teams do you need and what should their reporting lines be ?  How should they be incentivised and what’s best for the Enterprise as a whole ? This article discusses whether Enterprise Architecture models can help build an Organisational Model. There’s not always an Enterprise Architect at hand to assist at the very beginning of an Enterprise so EAs are usually involved when an Enterprise changes.

There are several different organisational design models; models that are used to create an Organisation Design.  (examples include the McKinsey 7S model, Galbraith’s and Burke-Litwin)  Many of these use the tenets of Business Architecture such as Vision, Goals, process and systems.  I’ve previously written about the capability model, the capability value chain and the relationship to high-level processes.  These are part of the Business Architecture and parts of the Business Architecture seem to assist or maybe replace other organisational design models.

The capability model shows the whole Enterprise laid out in a page as a set of ‘things’ that the Enterprise needs to be able to do.  The capability value chain organises those capabilities into a high-level process and shows which are the main capabilities and which are the support acts.  Putting logical breaks between those main capabilities is the first step to building an Organisation Structure.  With a set of breaks in the value chain, there’s now a rough set of departments that are necessary in the enteprise.  A different department would be responsible for all of the value chain capabilities between the breaks.  Each break though, causes tension in the Enterprise because two departments have to interact.  This tension can be eased by describing clear interfaces and agreements between the two departments.

This way of building an enterprise does create a very mechanistic, rather than organic, organisation but I’ve encountered more mechanistic organisations than I have organic.  It also leads to a functional (e.g. marketing, sales, delivery, finance) organisation, rather than, for example, a product or customer focussed one.  Those different types need to be borne in mind when putting breaks between the capabilities and deciding whether there should one or multiple instances of the capabilities.  Once the splits have been put in place, the supporting capabilities, need to be grouped into departments too.  However, one supporting capability can support multiple main capabilities and so these could be modelled as shared services.

Once the departments have been created, the measures and incentives need to be added too.  To reach these measures and incentives, each capability can be analysed to determine a set of sensible KPIs.  Whilst I say ‘sensible’, experience is necessary in drawing-up KPIs that are transparent and measure the enterprise correctly without creating perverse incentives.  However, once the KPIs have been reviewed, the can be turned into measures for the department and incentives for individuals.

From a capability value chain, I think that technique gets us to a rough sketch of an organisation, doesn’t it ?

Capability Value Chains and Process

The postbag is bulging with arguments that the capability value chain is actually just a process model.  In the wider Enterprise Architecture discussion, there seem to be a lot of people still debating whether capabilities are just the same as processes so this is my $2c into the debate.

The standard definition of a process is that it is an ordered set of activities that translate an input into an output.  When developing process models, we typically start with a very high-level model of what the Enterprise does to translate the inputs into the outputs, or use Porters Value Chain.  Obviously, those inputs and outputs vary between Enterprises so it’s not possible to be more specific than that.  That high level model usually only covers the ‘happy day’ scenario, not all of the different paths that can be taken in the detailed process, let alone showing the proceses that cope with error scenarios.  Those ‘unhappy day’ scenarios are only documented once the high-level process is broken down into more detailed processes.  At a more detailed level, the activities necessary to handle the different paths and scenarios are depicted on the process diagram and at that detail level, the diagram starts to need swimlanes.  Swimlines split activities by the teams that provide that acitivity.  Those teams are usually clustered around a particular skillset (e.g. sales, debt collection, kettle maintenance) and those skillsets are supported by a set of tools.

Once a process starts to move between swimlanes, it’s clear that different teams and skillsets are necessary before the process can work.  The teams offer different capabilities and all the process is showing is that different capabilities are linked together in a specific order.  In fact, if we build a capability model then processes could be depicted, not as straight lines along a swimlane, but as diagonal lines between capabilities, without swimlanes.

So are processes different to capabilities? No, I don’t think so when we’re still looking at things from a high-level.  Once lots of detail is necessary to document a process with lots of swimlanes then it’s very definitely a process because the intention of a capability model is not to break the capabilites down to a level of detail that could be used as activities in a detailed process.  The intent of a capability model is to be able to see the Enterprise on a page, not to provide layers and layers of detail for each capability.  However, it’s true that detailed activities in a process should be able to be classified as part of a capability.

It’s the layout of the tasks that separates proceses and capabilities: capabilities show all of the different things that a business can do; processes show the order in which those capabilities are triggered to translate a particular input to a particular output.

Capabilities and Value Chains

Building a capability map seems to be ‘the in thing’ at the moment.  Capabilities have centre stage at Enterprise Architecture conferences and feature in Enterprise Architecture.  Like many others, I’ve built a capability architecture and had it widely agreed.  What has been built is a simple map of a complex business.  That’s a laudable achievement but is it useful ?

The map isn’t useful as a model of the business, it’s really just a picture.  A cartographer includes features of the landscape into their maps so that their map is a model of the terrain. What features should be included on a capability map to make it into a useful model of the enterprise ?

This article proposes the evolution of the capability map into a Capability Value Chain by including dependencies between capabilities.  This creates a small, neat and useful model of the Enterprise.  Not a picture, but a model.

Many people will know Value Chains from ‘Porters Value Chain’, a very useful tool that helps to define what the key activities of the enterprise are.  But hang on, isn’t that what we’re doing with capabilities – defining the activities of the Enterprise ?

Capabilities, the “what the Enterprise does”, describe all of the activities of the company.  There are, of course, some capabilities that have to exist to enable others.  e.g “Maintain kettle” has to exist before “Make the tea”.  If these capability dependencies are (simply) documented then the capability map starts to turn into a model.

Once the dependencies have been documented, it’s possible that many capabilities depend on just a few.  If many capabilities depend on a few key ones then are the key capabilities the most important to the Enterprise ?  On the contrary, in my industry, the important capabilities are those that are valued most highly by the customer.  There aren’t that many businesses that can exist without customers so it seems sensible to denote the customer facing capabilities as the most important.  Those capabilities that are valued more highly form the value chain and those that are dependencies form the mesh of capabilities that support that value chain.  The order of the chain, for my industry, is decided by the customer’s journey through the enterprise.

When the dependencies have been documented, they can be analysed to gain some useful intelligence.  it’s now simple to show the nuance that’s well known: any effort to improve a capability must include analysis of the capabilities upon which it depends before.  Reusing the analogy: making a hotter cup of tea depends on having a well maintained kettle.

A cup of tea sounds good right now …