Capability Maps (cont'd)

In part 1 of this capability maps blog I presented the concept of a capability map, reasoning for developing and using one, and a source for getting started (APQC PCFs). In this second part, I will show you how to build and structure one for your business.

In part 1, I claimed that a capability is something an organization does independent of how or why. What an organization does is often choreographed processes performed by people using some thing or things. These things can be any job aid or tool, including technology tools. So, a capability is an ability of an organization to perform some specific purpose using an assembly of people, process and things.

If you took an opportunity to review the APQC PCFs you saw a couple of apparent structures.

• Capabilities form a hierarchy. For those familiar with OO concepts, capabilities form a containment hierarchy, and specifically they are in a composition relationship. In UML® you diagram this as shown in the diagram on the left. In a capability map it is common to diagram capabilities as actual containment and shown in the ArchiMate® diagram on the right.UML and Archimate

• Capabilities are either operational or supporting. Operational capabilities can be viewed as those capabilities that are needed to continue day-to-day business operations. Supporting capabilities, while important, are not directly associated with day-to-day operations. Without supporting capabilities your company's ability to produce quality products and conduct normal operations will erode. From a disaster recovery (DR) perspective, operational capabilities must be recovered first and quickly.

The appearance of the PCF models (shown in part 1) depicts supporting capabilities providing a foundation for operational capabilities. Additionally, operational capabilities can be viewed as a sequence of actions (progressing from left to right) that produce products or services. This alignment of operational capabilities should be familiar to anyone who has seen or reviewed a value chain diagram. Operational capabilities will be specific to your company or industry. Supporting capabilities can probably be taken directly from the APQC with few or no changes.

A capability is not a product, and it is not organizationally structured. I belabor this point because it is an important distinction. A capability is not the Human Resources department, and it is not a widget. To help guide you in the discovery of capabilities, it is useful to name capabilities in verb-noun fashion. A capability should have a name that completes the sentence, "<My company> has the ability to…." Your company does not have a Human Resources capability; it has the ability to Develop and Manage Human Capital. Your bank does not have a Business Checking Account capability; it has the ability to Create and Service Customer Accounts.

Let me collect the main points made so far.

• The APQC PCFs provide a good base from which to start your capability map.
• A capability is something of value your company has the ability to do.
• A capability is delivered using a combination of people, processes and things (assets).
• Capabilities form a containment hierarchy.
• Capabilities can be either operational or supporting.
• Operational capabilities are core to your company and specific to your industry.
• Capability names must complete the sentence, "<My company> has the ability to…."

Now let's take a look at a sample capability model that illustrates these points. The example is for the fictional healthcare company, HalenessHC. It covers levels 0 and 1.

Please don't view this example as complete or detailed. This is a fictional company, and I didn't consult with business owners to validate anything. When you build your capability map, you should leverage the expertise throughout your business. If you want to understand the capability to Develop and Manage Human Capital, go talk to people in your HR, Recruiting and Training departments. If you want to discover the Manage Financial Resources capability, start by talking to leaders in your accounting department.

Additionally, each capability needs to include a description. A well-formed sentence or two is sufficient. An example for capability 2.5 Manage Customer Communications might be:

This capability empowers <our company> representatives to cultivate customer relationships by providing marketing literature, educating them about our products and resolving any issues they may have.

So, while this example is not complete or detailed, it does pull together all the points made in this post. It provides a general example of what you should strive to create.

One final thought… this capability map uses a hierarchical numbering scheme. I chose to do this because it helps identify them as I refer back to the model in future posts. Since I am promoting a grass-roots effort to create your Business Engineering discipline, you should expect that your first iteration of a capability map will not be perfect. This means change is inevitable, so the numbering can get in the way - as we will see. Decide for yourself if numbering is helpful.

Whew! This post is getting pretty long. Let's stop here for now, and let things marinate for a bit. In the next post I will tie things together.

Next Blog Topic: Capability Maps (conclusion)

Happy Engineering!