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)”
- 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
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
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.
- HTML5 specifications for web browsers as defined by W3C (generalised technical capability)
- HTML5 implementations in Chrome, IE, Safari, etc. (specific technical capability)
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.
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).
- 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
5 Other interpretations of the concept ‘capability’
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.