An enterprise builds a capability map and it is never used again. What makes capability mapping produce decisions rather than documentation?
Show the full answer Hide the answer
Why maps go unused
They are built as an inventory exercise, at a uniform level of detail, describing everything equally. A complete map of two hundred capabilities tells you nothing about where to act, and the effort of keeping it current is not repaid by any decision it enables.
What makes it produce decisions
1. Overlay assessments, not just structure. A capability map becomes useful when each capability carries judgements:
- Strategic importance — differentiating, competitive necessity, or commodity.
- Current maturity — how well is this done today.
- System support — which applications implement it, how many, and how well.
- Cost to operate.
The intersection of high importance, low maturity is an investment case. Low importance, high cost is a consolidation or buy case. One capability implemented by nine applications is a rationalisation case. The map's value is entirely in these intersections.
2. Asymmetric depth. Decompose deeply only where decisions are pending. Two levels everywhere and five levels in the area under review. Uniform depth is what makes maps expensive and useless.
3. Anchored to a live question. Built to answer "should we consolidate order management across regions" or "what does separating this business line cost", not "let us document the enterprise".
4. Owned, with an expiry. A map with no owner and no review trigger becomes wrong silently, and a wrong map is worse than none because it is used confidently.
The most valuable single overlay
Which capabilities are implemented more than once. In a large enterprise, the same capability — customer master data, pricing, document generation, notification — is typically implemented several times by different business units for historical reasons.
That overlay produces a concrete, arguable list of consolidation candidates with an estimable saving, which is the kind of output that funds the mapping exercise and justifies its maintenance.
The failure to avoid
Confusing the map with the architecture. A capability map says what the business does. It says nothing about whether those capabilities should be one service or twenty, synchronous or event-driven, shared or duplicated. Those are architectural decisions the map informs and does not make — and teams that treat the map as a service decomposition produce boundaries that ignore every technical constraint.