2016-05-15

1 Introduction

Capability is a very important concept for any enterprise. Capability is used to manage the relationships between the enterprise mission and the enterprise successful functioning.

Enterprise mission is a short and catchy statement which describes a reason WHY an enterprise is doing what is it doing. Mission links the goals (nouns) and activities (via verbs or gerunds).There are a few patterns for the mission statement:

“do this until that is achieved”, e.g. “Eliminate poverty”

“do this while you are achieving that”, e.g. “Earn money by making cars”

“do this because of that”, e.g. “Create a better everyday life for the many people”

Enterprise successful functioning is a result of the behaviour of a complex socio-technical system (or even a system of systems).

To be able to manage the relationships between the enterprise mission and enterprise successful functioning, it is necessary to make these relationships explicit, reliable (with formally validated quality) and quantitative. Capability is one of the key artefacts to do this.

Note 2: In theory, the decomposition is strictly hierarchical, i.e. some “complex” capabilities are built from some subordinated “simple” capabilities. Also, it is possible to say “aggregated capabilities” and “detailed capabilities”. For example, aggregated capability “Collaboration” comprises the following detailed ECM capabilities (not exhausted list):

Sharing files

Pattern “One writer and many readers”

Pattern “Few managers, several members (writers) and many visitors (readers)”

Co-editing

Invitation of any internal person as a visitor (reader or writer)

Invitation of any external person as a visitor (reader or writer)

Notifications (or alert)

Local copy for off-line work

etc.

Note 3: In practice, there is no exact hierarchy of discrete-units-of-purpose within an enterprise because some discrete-units-of-purpose can be shared.

Note 4: Some capabilities may be outsourced.

Note 5: If outsourcing and sharing are ignored, all enterprises in the same industry sector (e.g. telecom) have the same capability-as-discrete-unit-of-purpose decomposition. (Such a decomposition also called “industry sector reference model”, e.g. https://en.wikipedia.org/wiki/Business_Process_Framework_(eTOM) ).

A capability may be implemented in one of the following ways:

Internally as a business function (including people, resources, tools and other functions)

Externally as a commodity which are available from the market (e.g. banking)

Externally as partnership with a service provider

Deliberately missing (because of some reasons, e.g. maturity level)

For example, the capabilities of an IT department can be implemented as the following:

Governance, Business Analysis, PMO, Application Support – internally

Infrastructure – externally as the partnership with an IaaS provider

Development – externally as the partnership with an ecosystem of providers

Testing – externally as commodity, e.g. testers are available for 11 $ per hour

Service desk – externally via contract with a company MMM

Enterprise IT Architecture – deliberately missing

Again, internally implemented capability is a business function. Capability itself is an abstract construction.

3 Building internal implementations of capabilities as business functions

An internal implementation of a capability (actually a business function) may use other functions (all subordinated and some shared) and some tools. How to select tools for an implementation of a particular business function? Obviously, the selection must be explicit and quantitative to be able to verify a choice tool is the best. Also, it is mandatory to avoid unjustified duplications at the scale of an enterprise (or “silo” effect).

Thus, it is necessary to establish relationships between the capability demand (i.e. requirements of a particular business function) and the capability supply (i.e. features of some tools).

A few intermediate layers (see figure below) are necessary to make these relationships explicit and practical.

Concrete Business Capability – concrete functionality needed for the business, also known as requirements.

Uniform Business Capability – enterprise-wide agreed functionality, which may be implemented once and reused many times (usually based on good business practices and business patterns).

The use of the mentioned above capabilities is described below. Imagine (see figure below) an implementation of the business function B1 that comprises the business function C3 (which is “smaller” than B1) and the tools T1, T2, T3 and T9.

This implementation of the business function B1 requires (in addition to C3) some concrete business capabilities (as requirements described by the owners of the B1) – B1A, B1B, ... B1Z (see figure below). Their implementations reply on the tools T1, T2, T3 and T9.

All the tools expose some specific technical capabilities. Some of those capabilities implement the concrete business capabilities of the business function B1 (see figure below).

Some of the concrete business capabilities from various functions may be very similar. For example, the delegation of authority is a stable and well-defined business pattern ( see http://improving-bpm-systems.blogspot.ch/2012/07/practical-process-pattern-dam.html ). Also, there are numerous “good business practices” proven by practice and helped many companies to avoid “trial and error” improvements. Thus is it logical to have a set of uniform business capabilities that is actually, enterprise-wide collection of good business practices.

So, one of the concrete business capabilities of the business function B1, e.g. B1A, was agreed to match the uniform business capability BC10 (see figure below).

In the similar manner, some of specific technical capabilities can be similar. For example, the specific technical capability T1B and the specific technical capability T2A are the same generalized technical capability TC30 (see figure below).

Thus the tool T2 can be eliminated because its specific technical capability T2A can be provisioned by the tool T1 with its specific technical capability T1B (see figure below).

4 Example

The business requested some “collaboration” functionality to exchange information among staff members, volunteers, and service providers. The requested concrete business capabilities (primarily aggregated) are the following:

All of these concrete business capabilities were mapped against the generalised technical capabilities as shown in table below (columns “Capability demand”). Additional columns “Capability supply” show the level of provisioning of those generalised technical capabilities by an in-house ECM tool.

5 Other interpretations of the concept ‘capability’

Performance-related interpretation: capability is a measure of how well a function with achieving a desired result. Such a measure can be qualitative or quantitative. Numerous “heat maps” use this interpretation (see figure below).

The important consideration for performance measurement of capabilities is that a function is considered “self-contained” thus capability of a function depends on capabilities of all other functions and tools used by this function (see figure below).

Capacity-centric interpretation: capability is availability of resources required to achieve a desired result. This is very ERP-oriented interpretation.