Capability as discrete unit of purpose

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”
• “do anything to achieve this”, e.g. “Go there, don't know where, bring that don't know what, but this must make me happy”.

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.

Unfortunately, the concept ‘capability’ has no commonly-agreed definition. Different people understand it differently ( see http://improving-bpm-systems.blogspot.ch/2015/10/concepts-crisis-in-it-and-sister-domains.html ). This article offers a reconciliation between several interpretations (or projections) of this concept.

There are two major interpretations of the concept ‘capability’:

1. Capability as discrete-unit-of-purpose (do right things)
2. Capability as measure-of-performance (do things right)

Mainly the first interpretation will be discussed below.

Related blogposts - http://improving-bpm-systems.blogspot.ch/search/label/%23%23terminology

2 Capability as discrete unit of purpose

The mission of an enterprise can be decomposed into an approximate hierarchy of discrete-units-of-purpose must describe WHAT an enterprise must be doing to conduct its mission.

An example (see figure below) is a strict hierarchical decomposition of the “rent-a-car” business into capabilities-as-discrete-unit-of-purpose.

Note 1: Potential synonym of “capability-as-discrete-unit-of-purpose” is “capability-as-a-discrete-unit-of-mission”.

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).
• Generalised Technical Capability – Industry “de-facto” or “de-jure” standards for functionality of particular class of tools (e.g. DBMS, DMS, web browser).
• Specific Technical Capability – Particular functionality implemented by a particular tool, also known as features.

Example:

• HTML5 specifications for web browsers as defined by W3C (generalised technical capability)
• HTML5 implementations in Chrome, IE, Safari, etc. (specific technical capability)

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:

• Multilingual
• Omni-channel
• Various audiences
• “Book shelf” as static documentation (slow changing by designated groups)
• “Tool box” as operational documentation (changing with the speed of operations by groups which are involved in operations)
• “Forum” as interactive knowledge capturing and exchange (ah-hoc changes by communities of practices – speed of Internet discussions)
• “News channels” as real-time information (feeds and streaming)
• Activity monitoring

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.


Thanks,
AS