capability-map

Capability Map

Build a Business Capability Map that shows what the organisation does, how well technology supports each capability, and where to invest next.

---

Core Concept

A capability describes what a business does, not how or who does it. "Payment Processing" is a capability. "Stripe integration" is an implementation. Capabilities are stable; implementations change.

---

Step 1 — Define the Capability Model

From the user's description, build a three-level hierarchy:

Level 1 — Domain        (e.g. "Customer Management")
  Level 2 — Capability  (e.g. "Customer Onboarding")
    Level 3 — Sub-cap   (e.g. "Identity Verification")

For common industries, use the reference archetypes in references/archetypes.md as a starting point, then adapt to what the user describes.

Aim for 5–8 Level 1 domains, 3–6 Level 2 capabilities per domain. Go to Level 3 only when the user needs that granularity.

---

Step 2 — Score Each Capability (when requested)

For each Level 2 capability, ask the user to rate (or infer from context):

Dimension	Scale	Meaning
Strategic importance	1–5	How critical to business strategy?
Current maturity	1–5	How well does current tech support this?
Investment priority	High / Medium / Low	Where should investment go?

Gap = Strategic importance minus Current maturity. Capabilities with Gap ≥ 2 are priority investment areas.

---

Step 3 — Map Applications to Capabilities

If the user provides an application list, map each application to the capabilities it supports:

| Application | Capabilities supported | Coverage |
|---|---|---|
| Salesforce CRM | Customer Onboarding, Account Management | Strong |
| Legacy Mainframe | Payment Processing, Reconciliation | Weak — modernisation candidate |

Surface: gaps (capabilities with no application support) · overlaps (multiple apps doing the same thing) · modernisation candidates (critical capability, weak app support).