What a capability is, and what it is not

A business capability is something the business does or can do to reach an outcome. The BIZBOK Guide from the Business Architecture Guild and the TOGAF Standard both describe a capability as an ability the business has to achieve a specific purpose. At Mangrove, Partner credit management is a capability: deciding each partner shop's credit limit and terms, and keeping orders inside them.

Look at how that capability works today. A finance analyst sets limits in the ERP finance module, and a typical shop gets $1,500 on 14-day terms. When a rep needs a one-off increase, the rep emails finance. About 1 phone order in 6 waits for such an approval, roughly 4 working hours each time, and the answers live in a spreadsheet with no audit trail. In two years the same job may run through a rules service that approves most requests inside the Partner app in seconds. The people, the steps and the systems will all have changed. The capability and its name will not. That stability is what makes the map useful: a picture that survives the next reorganisation and the next system replacement can be the fixed frame that every plan hangs on.

Four things often sit on a first draft looking like capabilities:

Naming rules make the difference visible. Name a capability as a noun phrase: the thing the business works on, plus an action noun. "Partner credit management", "Route planning", "Partner order capture". Avoid verbs ("Approve credit"), channels and tools ("Phone ordering", "WMS"), quality words ("Fast delivery") and department names. Give each box a one-sentence definition, so two people reading "Partner support" picture the same job, and a business owner who answers for how well it performs.

Levels, bands and Mangrove's map

A capability map is a hierarchy. Level 1 (L1) shows the whole company on one page, usually in 8 to 12 boxes. Each L1 box splits into level 2 (L2) children, often 3 to 8 of them. Level 3 exists, but draw it only for the few places where you are about to invest and need the detail. A full L3 map of a company has hundreds of boxes and nobody reads it.

Three rules keep the hierarchy honest:

• One parent. Every child sits under exactly one parent, so its score and its owner are never counted twice.
• No gaps, no overlaps. The children together cover everything the parent does, and no two children do the same job. Analysts call this MECE.
• Even detail. Boxes on one level are about the same size of job. "Finance" and "Route planning" are not peers.

Many maps also sort the L1 boxes into three bands. Strategic capabilities set direction. Core capabilities are how the company creates value for its customers; for a grocer that is buying, storing, moving and selling goods. Supporting capabilities keep the company running: finance, people, technology. The bands help a reader find their way, and they hint at how to invest. A core capability that makes Mangrove different may deserve custom work, while a supporting one is often best served by a standard package (the trade-off in Build, buy or partner).

Notice what is missing: no "Partner app", no "Sales department", no "Lagoon Digital". Phone orders and app orders are two channels for one capability, Partner order capture. The phone and the app are two ways of doing it, and "how" belongs in process models and the systems list.

For the three-year plan you zoom into the partner business. Its L2 capabilities sit under six different L1 parents, which is normal: one business line uses jobs from all over the company.

Partner information management surprises people. A shop's name, address, credit limit and rep live in three places today: the Partner app, the ERP and the reps' spreadsheets. About 1 shop record in 8 disagrees between them. Nobody owns that data as a job, so nobody owns the problem. Naming it as a capability gives it a definition, a score and an owner.

Heat mapping: importance times gap

A heat map colours each capability by how much it needs investment. Score every L2 box on two scales from 1 to 5, using anchors you write down before anyone scores.

Strategic importance comes from the goals, here the board's G1 (double partner-shop revenue, from about $52M to about $104M a year by the end of FY2029), G2 (two new cities by mid FY2028) and G3 (cut the cost to serve a partner order by 30%). Performance gap comes from evidence: numbers, audits, incidents, support end dates.

Importance (from goals G1-G3)            Performance gap (from evidence)
5  main lever: a goal fails without it    5  failing today: measured losses, no control
4  a clear lever for one goal             4  large measured gap to the target
3  enables capabilities that are levers   3  works today, will not scale to the plan
2  small or indirect effect               2  small gap, a few complaints
1  no link to this plan's goals           1  meets what the plan needs

Score = importance x gap (1 to 25)
Hot 15 or more    Warm 8 to 14    OK 7 or less

Multiply, do not add. A product is high only when both numbers are high. Take capability A, importance 5 and gap 1, and B, importance 3 and gap 3. Added, both score 6 and look equal. Multiplied, A scores 5 and B scores 9. A matters a lot and already works, so money spent there buys little. A broken capability that the goals do not need also stays cold, which is how a heat map protects the budget from loud but low-value problems.

Here are the partner L2 scores, with one line of evidence each. The evidence is what lets the table survive a challenge.

The same scores read differently on a grid. Put the performance gap across and importance up. Every capability becomes a dot, and the top-right corner is where the money should go first.

Capability-based planning: tie every initiative to the map

A heat map on its own is a nice poster. It starts to steer money when initiatives are planned against it. TOGAF describes this as capability-based planning: change is planned and judged by the capabilities it improves. In practice it comes down to three habits.

• Every initiative names the capabilities it lifts, and by how much. "Credit rules service with in-app requests: Partner credit management, gap from 5 to 2 by the end of FY2028, measured as 9 approvals in 10 decided within 5 minutes." That target is an outcome in the sense of OKRs and outcome goals, and it gives finance something to check later.
• Lay the initiatives over the heat map and look for two mismatches. A hot capability with no initiative is a hole in the plan. An initiative that lifts only green capabilities needs a reason, or it waits.
• Re-score every planning cycle. When an initiative works, the gap falls, the box cools, and the money moves on to the next hot box.

This is how the map connects to the course chain from Why enterprise architecture exists: goals give importance, evidence gives the gap, and each funded initiative points at the boxes it changes. When the board asks why the plan spends money on credit approvals, the answer takes one line: it is the hottest box on the map, and here is the number that will show the money worked.

Initiative (proposal)                 Lifts (score)
Rep mode in the Partner app           Partner order capture (20), Sales rep management (6)
Credit rules service, in-app requests Partner credit management (25), Partner order capture (20)
Mobile wallet collections             Invoicing and collections (16)
WMS version 7 to 9 upgrade            Order fulfilment at DCs (12)
Loyalty badges in the Partner app     Partner support (6)

Hot with no initiative:   Route planning (16), Partner information management (15)
Initiative on green only: Loyalty badges (goes back to its sponsor with a question)

Mobile wallet collections means letting shops pay invoices from a wallet like M-Pesa, UPI or GCash, so less cash passes through reps and drivers. Each line in that block is a question you can ask in a meeting, and none of them needs a framework name to make sense.