Skip to content
Blueprint Catalog

    ↑↓ move · Enter open · Esc close

    10 — Wiki · Article 01

    What a Business Capability is, and is not

    A Business Capability names something the organization must be able to do. It is not a process, a department or an application, and the difference is what makes a capability map last.

    The short definition

    A Business Capability is an ability the organization needs in order to deliver its outcomes, described by what it achieves rather than by how, by whom or with which system. "Invoice customers accurately" is a capability; the billing team, the billing process and the billing application are three different ways of realizing it.

    Because it describes the what, a capability changes slowly. Teams reorganize, processes are redesigned and applications are replaced, while the need to invoice customers stays. That stability is the reason to model capabilities at all: they give strategy, investment and architecture a fixed frame to point at while everything underneath moves.

    What it is often confused with

    • A process: a sequence of steps with a start and an end. Processes realize capabilities; one capability usually needs several processes, and one process often draws on several capabilities.
    • A department or function: who does the work today. Mapping capabilities to the org chart reproduces the org chart and breaks at the next reorganization.
    • An application or product: the tool that supports the work. "CRM" is a product category; Account Management is a capability a CRM may support.
    • A skill or competency: what a person can do. In HR the word capability often means this, so say Business Capability when the difference matters.
    • A value stream stage: a step in delivering value to a stakeholder. Stages use capabilities; see Value streams, value stream mapping and processes.

    Levels

    Capability models are layered so each audience can read the level it needs. This catalog has eight macro domains at the top (the level many tools call L1), then L1 capabilities inside each domain, L2 beneath them and L3 at the most specific, with L4 only where an L3 genuinely splits. Each level should cover its parent completely without overlap among siblings, so an organization can roll anything mapped at L3 up to a domain without double counting.

    Industry blocks sit beside the cross-industry model rather than inside it: a manufacturer uses every cross-industry capability plus the manufacturing block, and the same is true for the other industries in the catalog.

    How capabilities are named and described here

    • Names are Title Case noun phrases of two to five words, with no verbs, and "Management" only where managing is the point.
    • An ampersand joins two halves only when they cannot sensibly be owned or funded apart, such as Records Retention & Disposition.
    • The description leads with the outcome the capability makes possible, then states the boundary.
    • In scope and out of scope lines make the boundary explicit, and each out of scope line points at the capability that owns it, because the same label means different things in different organizations.
    • Each name is unique across the catalog; when two capabilities shared a name, the 0.3.0 release merged true duplicates and renamed the rest.

    Further reading

    Written in our own words; the sources are linked, not copied. Product names are used only to cite them.

    ← All articlesNext: Using a capability map →