What is a business capability map? Definition and demarcation
In a nutshell: Capability = "What". Process = "How". Function = "Who". A capability map orders the "what"; process models order the "how", org charts the "who". Mixing the three layers does not produce a capability map — it produces a shortened process diagram.
A business capability is the smallest stable unit of business architecture. It names an ability — for example "customer order management", "material requirements planning" or "group consolidation" — without stating process, roles, sequence or tooling. A capability map is the structured, mostly hierarchical collection of all capabilities of a company on typically two to three levels.
The TOGAF standard anchors this distinction in Phase B (Business Architecture) and describes business capabilities as intentionally stable against restructuring and technology change (TOGAF Series Guide: Business Capability Planning, The Open Group, 2023). The IIBA BABOK Guide — Business Capability Analysis (chapter 10.6) lists capability analysis as a canonical technique for surfacing functional gaps before IT investment decisions.
Unlike process landscapes, a capability map has no sequence, no arrows, no verbs. It is static and deliberately movement-free. That absence of motion is exactly what makes it valuable for ERP selection: it keeps the functional target stable while vendor demos, market shifts and internal debates would otherwise move the requirements list week after week.
Why capability maps matter to the DACH Mittelstand in 2026
In a nutshell: Mittelstand companies must solve two structural problems at once in 2026: modernise ERP landscapes under cloud-migration pressure and set up AI initiatives with a traceable business link. Both fail without a functional bracket — and that bracket is the capability map.
In our projects we see the same mechanism repeat: without a capability view, 600- to 800-page requirements catalogues emerge that demand everything and prioritise nothing. Managing directors then decide on vendors without knowing which of the listed requirements actually differentiate their business.
The market context sharpens the issue. The DSAG Investment Report 2026 states that 24 percent of DSAG member companies use the SAP Integrated Toolchain including capability modelling fully or partially, with a further 39 percent planning to; the report notes that AI will change every architecture and every business capability. The Bitkom EAM Guide confirms this: without a capability view, Mittelstand companies lack the functional bracket for ERP, cloud and AI investments.
A regulatory shift compounds it. The European Interoperability Reference Architecture anchors the business-capability layer as the top of its four interoperability layers. Private-sector DACH companies increasingly align their capability maps with this reference model, because supply chains and B2B interfaces can no longer be documented soundly without a shared functional vocabulary.
Practical example: capability map as an ERP-selection filter in the DACH Mittelstand
In a nutshell: A DACH machinery manufacturer with around 300 employees condensed its capability map to 14 level-1 and 47 level-2 capabilities in three workshop days. Six hundred pages of requirements turned into 90 decision-relevant scoring points — and the ERP-selection decision was made six weeks later, roughly seven months ahead of schedule.
A warning first: from more than 1,200 projects in the DACH Mittelstand we see that around 70 percent of capability maps in their first iteration end up too fine-grained — and thereby miss their purpose as a decision instrument. The value lies not in completeness but in separating power.
An anonymised machinery manufacturer with around 300 employees was preparing an ERP replacement. Over more than 30 years the company had lived through three ERP releases; the current requirements document had grown to 600 pages, four vendors were on the shortlist, and every demo shifted the requirements again. Together with the board, the business units and IT, we condensed the discussion into 14 level-1 and 47 level-2 capabilities across three workshop days. Three were marked as differentiating, the rest as business-critical commodity or hygiene.
The consequence for vendor selection was unambiguous. The three differentiating capabilities required depth-fit evidence — with reference-customer proof and a load test. The forty commodity capabilities accepted standard scope, with no further deep-dive. That decision became possible only after the capability map had lifted the discussion off detail ping-pong onto the strategic plane.
How we use capability maps methodically in ERP selections
In a nutshell: In our methodology the capability map is not an end in itself but the first concrete step after strategic clarification via the Business Model Canvas. It forms the functional bridge between business model and vendor selection — in four cleanly separated phases.
A capability map cannot be derived from a tool. It emerges from facilitated conversations in which managing directors negotiate their own business in functional language for the first time — the line between "real competitive advantage" and "habit" lies in the discussion, not in the software. From our experience, four phases can be cleanly distinguished — building on the strategic clarification via the Business Model Canvas.
Phase 1 — capturing the functional target. A three-day capability workshop with the board, business-unit heads and IT leadership produces a capability map with 12 to 18 level-1 and 40 to 80 level-2 capabilities. This granularity is deliberately pragmatic: corporate libraries with more than 200 capabilities cannot be maintained in the Mittelstand and obscure the strategic levers.
Phase 2 — assessment and differentiation. Each capability receives two values: a target maturity and a differentiation label (differentiating, business-critical commodity, or hygiene). This is the most important and most uncomfortable phase, because it forces the board to state honestly what the company actually earns money with — and what it does not. Typically only three to five genuine differentiators remain.
Phase 3 — the sourcing decision. For every assessed capability we settle the delivery route along the Make-Buy-Configure triangle. The differentiating capabilities are tested for genuine in-house build or deep customisation; the commodity and hygiene capabilities are pushed consistently towards configuration in the standard. The result is a sourcing map that pre-empts later customisation debates.
Phase 4 — the vendor filter and selection. Maturity, differentiation and sourcing combine into a weighted scoring grid. Differentiating capabilities steer targeted depth demos and reference checks; commodity capabilities are covered by standard references. We bring this assessment together in our vendor-neutral SCOReX selection methodology, which separates vendor marketing transparently from actual coverage. Clarity, structure, practice — three anchors that carry the approach.
Common mistakes with capability maps — the anti-pattern catalogue
In a nutshell: Capability maps rarely fail at the concept stage and often fail at execution. From more than 1,200 projects we know four recurring anti-patterns that surface regularly in Mittelstand work — they cost weeks of project time and devalue the instrument.
The depth trap is the most common mistake. Teams drill down to level 3 or 4 and produce 200 or more capabilities. The result is a map no one maintains, that buries the strategic levers and sits outdated in the archive after six months. Granularity must follow the decision question, not a claim to completeness — in the Mittelstand it almost always ends at level 2.
The tool trap begins with the assumption that a capability map can be derived from an EAM tool. The tool stores and visualises the map — but it does not produce the strategic separation between differentiation and commodity. Buying the tool licence before the method reverses the order and funds an empty database. Facilitated assessment first, then the tool to manage it.
Capability-process conflation shows itself as soon as verbs appear in capability names. "Capture orders" is a process. "Customer order management" is a capability. The distinction seems academic but has operational consequence: leaving verbs in the map destroys stability against reorganisation and the actual value of the capability view. The EAM Initiative TU Munich lists this distinction as a methodological core criterion.
The missing strategy link is the most damaging anti-pattern. A capability map without a connection to business model, market position and competition describes only activities — it makes no strategic statement. In the Mittelstand this connection is mandatory, because investment budgets are limited and every misallocation in EAM and ERP selection stays felt for years.
Frequently asked questions
A capability map describes what a company must be able to do, without sequence or movement. A process landscape describes how those abilities are executed, with sequence, interfaces and responsibilities. The capability map is stable across reorganisations; the process landscape changes with every organisational adjustment. The two views complement each other — one does not replace the other.
From our work with Mittelstand companies between 100 and 2,000 employees in DACH, the pragmatic corridor is 12 to 18 level-1 and 40 to 80 level-2 capabilities. Corporate libraries with 200-plus capabilities cannot be maintained in the Mittelstand, obscure the strategic levers and stop being updated after six months. Granularity follows the decision question, not theoretical completeness.
The capability map is the central filter between functional target and vendor standard scope. It replaces the traditional requirements document as the leading vendor-selection artefact by compressing requirements into 30 to 80 decision-relevant scoring axes. Depth demos are set up deliberately for differentiating capabilities; commodity capabilities use standard references. In our projects this halves vendor-selection time without losing quality.
Next steps
A capability map is not documentary garnish in the Mittelstand — it is the first concrete step in any well-founded ERP selection. It keeps the functional target stable while market, vendors and internal debates move. Anyone who builds a capability map cleanly separates differentiating from commodity, replaces requirements sprawl with functional scoring axes, and resolves the Make-or-Buy question in the same view. Anyone who skips it decides on seven-figure investments without a stable functional foundation.
If you are planning an ERP selection or an EAM initiative within the next twelve months, now is the moment to start with a capability map. We have guided DACH Mittelstand companies through exactly this phase for three decades — from the first capability sketch to the vendor decision. See also our insights on ERP selection in the Mittelstand.
