Capability Maps: The Artefact That Unlocks Target Operating Model Design

The business capability map is one of the most useful artefacts a firm can maintain and one of the most commonly done badly. It looks simple: a taxonomy of what the business does, organised hierarchically. In practice, most firms either do not have one, have one that nobody uses, or have three that disagree. In each case, the target operating model work that depends on the capability map becomes slower and less defensible than it needs to be.

This post covers why the capability map is the right starting point for TOM design, what a good map looks like, and the disciplines that keep it useful beyond the initial consulting engagement that produced it. It draws on TOM work in banking, insurance, asset management and capital markets, where the capability framing is well established and the failure modes are repeatable.

What the capability map is for

A business capability is something the business does, independent of how it does it, who does it, or what systems it uses. "Manage customer relationships". "Assess credit risk". "Process claims". "Report regulatory capital". Capabilities are verbs and nouns describing what the business achieves, at a stable taxonomy that does not change when reorganisations happen, when systems change, or when processes are redesigned.

The reason this stability matters is that the capability map is the anchor against which everything else can move. A new target operating model redesigns how capabilities are organised and delivered. A new technology programme replaces how specific capabilities are supported by applications. A new regulation imposes requirements on specific capabilities. A new M&A integration merges capabilities between two firms. The capability map provides the common vocabulary that makes all of these changes comparable.

Without the map, every change has to reinvent the vocabulary. Different teams use different words, different levels of abstraction, different scopes. The result is that decisions are harder to make and easier to undo.

The anatomy of a good capability map

A good map has three levels of decomposition and follows three structural properties.

Level 0: the top level

The top level is a small number (typically 6 to 12) of value-stream-oriented or capability-oriented top-level groupings. In banking, these often look like: Customer Management, Product Management, Financial Management, Risk Management, Operations, Enabling Functions. In insurance, a similar shape: Customer Management, Underwriting, Claims, Reinsurance, Finance, Enabling Functions. The exact shape varies by firm, but the number should be small.

Level 1: the capability families

Each Level 0 grouping decomposes into 4 to 10 Level 1 capability families. For Customer Management in banking, this might be: Customer Onboarding, Customer Servicing, Customer Analytics, Customer Communications. Each Level 1 capability is something the firm recognisably does as a named function.

Level 2: the specific capabilities

Each Level 1 family decomposes into 3 to 8 Level 2 specific capabilities. For Customer Onboarding: Identity Verification, Know Your Customer, Source of Funds Assessment, Product Eligibility Assessment, Customer Data Capture. Level 2 is where the specific things the business does live.

Some firms decompose further to Level 3, typically when capability maps are used for detailed application portfolio management. Most TOM work only needs Level 2.

Property 1: mutually exclusive, collectively exhaustive

Every activity the firm performs belongs to exactly one capability at each level. Overlap confuses governance. Gaps leave activities unassigned. The discipline of checking MECE is not glamorous but is essential. Tools like BIAN's service domain model provide an industry reference that helps with MECE in banking.

Property 2: verb-noun naming

Capability names are verb-noun phrases describing what is done. "Assess credit risk" not "Credit risk". "Manage customer relationships" not "Customer Management". Verb-noun naming forces clarity about what the capability does versus just naming a domain.

Property 3: agnostic to how

The capability says what, not how. "Process claims" does not say whether the processing is manual, automated, in-house, outsourced, in London or Mumbai. The capability exists regardless. This is what makes the map stable across change.

Industry reference models

For most financial services domains, industry reference models provide a starting point. The BIAN service domain model is the canonical reference for banking capabilities. The ACORD framework is the canonical reference for insurance. The FIBO ontology provides a semantic reference that helps with vocabulary consistency across domains.

Using the reference model as a starting point and adapting it to the firm is usually faster than starting from a blank sheet, and produces a map that is more easily compared with peers.

Capability maps vs other maps

Capability map vs process map

Capabilities are stable. Processes are how capabilities are executed. A single capability ("Process claims") is implemented by many processes (motor claims process, home claims process, commercial claims process). Processes change when the process is redesigned. The capability does not change when the process does. See our post on process decomposition L0 to L5 for the complementary process dimension.

Capability map vs organisation chart

Organisations are how capabilities are resourced. A capability ("Assess credit risk") may be delivered by a credit risk team, distributed across business units, shared with an offshore centre, or run by a vendor. The organisation chart changes more often than the capability map. The capability map gives the organisation chart a stable vocabulary to describe itself against.

Capability map vs value stream

Value streams are how capabilities combine to deliver customer outcomes. A value stream like "Acquire a new customer" uses capabilities from Customer Management, Product Management, Risk Management and Operations. The value stream cuts across multiple capabilities. The capability map provides the building blocks. The value stream shows how they combine.

Using the capability map for TOM design

A target operating model is a design of how the firm's capabilities are delivered, by whom, in what locations, supported by what systems, within what governance. Every part of that design references the capability map.

The capability-to-organisation mapping

For each Level 2 capability, the TOM specifies which organisational unit is accountable for delivery. This mapping surfaces capability owners and exposes overlaps where two units believe they are accountable for the same capability.

The capability-to-location mapping

For each capability, the TOM specifies the location (or locations) of delivery. This is where offshoring, nearshoring, and centralisation decisions show up explicitly, and where the change impact assessment for location moves starts.

The capability-to-technology mapping

For each capability, the TOM specifies the primary application or platform. This is where the application portfolio intersects with the operating model, and where duplication, obsolescence and integration gaps surface.

The capability-to-performance mapping

For each capability, the TOM specifies the performance metrics that will be measured. Cost, quality, time, customer outcome. Without a capability-to-performance mapping, operating model performance is measured at the unit level rather than the capability level, which hides problems and suboptimises decisions.

See our post on target operating model transformation for the broader TOM framing and the TOM framework resource for a complete template set.

Common failure modes

Failure: the capability map as org chart

The map mirrors the organisational structure. Every team is a capability. When the org restructures, the map becomes wrong. Fix: the map is built from what the business does, not from who does it. Verb-noun naming helps enforce this.

Failure: the three-hundred-capability map

The map decomposes to Level 4 or Level 5 and ends up with 300 capabilities. Nobody uses it. Fix: stop at Level 2 for TOM work. Use Level 3 only for specific purposes (typically application portfolio rationalisation) where the granularity is useful.

Failure: the competing maps

Three different capability maps exist, maintained by enterprise architecture, operations, and business architecture. They disagree about capability names and scope. Governance conversations are about map reconciliation rather than substantive decisions. Fix: one authoritative map, owned by a named function, updated through a controlled change process.

Failure: the aspirational map

The map describes what the firm wants to do, not what it currently does. It is useful for target-state design but not for current-state analysis. Fix: maintain both a current-state and target-state view, or annotate the map with capability status (established, under development, aspirational).

Failure: the static map

The map is produced during a TOM engagement, baselined, never updated. Three years later, the firm has acquired a business, exited a product line, adopted a new technology platform. The map is wrong. Fix: the map is a living artefact with an owner, a change log, and a review cadence.

Connection to the broader artefact stack

The capability map connects to:

• The target operating model framework: the map is the core artefact on which the TOM is built.
• The context diagram: the scope of a programme is often a subset of the capability map.
• The value stream map: VSMs are within capabilities, and capability boundaries often explain why handoffs occur where they do.
• The business rules catalogue: rules are attached to specific capabilities.
• The stakeholder register: capability owners are a defined set of stakeholders.

These connections are what turn the map from a static taxonomy into an operational tool.

External references

The Business Architecture Guild BIZBOK guide is the canonical reference for business capability modelling. The BIAN service domain model is the industry standard for banking. The APQC process classification framework provides a cross-industry reference that can be adapted.

The short version

The capability map is the vocabulary of the business. When it is right, TOM design, application portfolio decisions, organisational moves and regulatory impact assessments share a common language and move faster. When it is wrong or missing, every one of those activities reinvents the vocabulary and the inconsistencies accumulate.

The map is not expensive to produce if an industry reference model is used as a starting point. Keeping it current is a small standing cost with a large compounding benefit. For any firm about to start a material TOM design, the capability map is the first artefact to invest in.

Our target operating model design service and business analysis service include capability mapping as the foundation for operating model work.