Was ist eine Capability Map? Definition und Abgrenzung
Auf den Punkt: Capability = „Was". Prozess = „Wie". Funktion = „Wer". Eine Capability Map ordnet das „Was"; Prozessmodelle ordnen das „Wie", Organigramme das „Wer". Wer die drei Schichten vermischt, baut keine Capability Map, sondern ein verkürztes Prozessdiagramm.
Eine Business Capability ist die kleinste stabile Einheit der fachlichen Architektur. Sie benennt eine Fähigkeit — zum Beispiel „Kundenauftragsabwicklung", „Materialbedarfsplanung" oder „Konzernkonsolidierung" — ohne Aussage über Prozess, Rollen, Abläufe oder Werkzeuge. Eine Capability Map ist die strukturierte, meist hierarchische Sammlung aller fachlichen Fähigkeiten eines Unternehmens auf typischerweise zwei bis drei Ebenen.
Der TOGAF-Standard verankert diese Trennung in Phase B (Business Architecture) und beschreibt Business Capabilities als bewusst stabil gegen organisatorische Umstrukturierungen und Technologiewechsel (TOGAF Series Guide: Business Capability Planning, The Open Group, 2023). Auch der IIBA BABOK Guide — Business Capability Analysis (Kapitel 10.6) führt Capability-Analyse als kanonische Technik, mit dem ausdrücklichen Ziel, fachliche Lücken vor IT-Investitionsentscheidungen sichtbar zu machen.
Im Gegensatz zu Prozesslandkarten kennt eine Capability Map keine Reihenfolge, keine Pfeile, keine Verben. Sie ist statisch und bewusst arm an Bewegung. Genau diese Bewegungsarmut macht sie für die ERP-Auswahl so wertvoll: Sie hält das fachliche Zielbild stabil, während Vendor-Demos, Marktentwicklung und interne Diskussionen das Lastenheft sonst Woche für Woche verschieben würden.
Warum Capability Maps für den DACH-Mittelstand 2026 entscheidend sind
Auf den Punkt: Mittelständische Unternehmen müssen 2026 zwei strukturelle Aufgaben gleichzeitig lösen: ERP-Landschaften unter Cloud-Migrationsdruck modernisieren und parallel KI-Initiativen mit nachvollziehbarem Geschäftsbezug aufsetzen. Beides scheitert, wenn die fachliche Klammer fehlt — und genau diese Klammer ist die Capability Map.
In unseren Projekten sehen wir denselben Mechanismus immer wieder: Ohne Capability-Sicht entstehen 600- bis 800-seitige Lastenhefte, die alles fordern und nichts priorisieren. Geschäftsführerinnen und Geschäftsführer entscheiden dann über Vendoren, ohne zu wissen, welche der gelisteten Anforderungen tatsächlich differenzierend für ihr Geschäft sind.
Der Marktkontext verschärft das. Laut DSAG-Investitionsreport 2026 nutzen 24 Prozent der DSAG-Mitgliedsunternehmen die SAP Integrated Toolchain inklusive Capability-Modellierung ganz oder teilweise, weitere 39 Prozent planen den Einsatz; der Bericht hält fest, dass KI jede Architektur und jede Business Capability verändern wird. Auch der Bitkom-Leitfaden Enterprise Architecture Management bestätigt: Ohne Capability-Sicht fehlt Mittelstandsunternehmen die fachliche Klammer für ERP-, Cloud- und KI-Investitionen.
Hinzu kommt eine regulatorische Verschiebung. Die European Interoperability Reference Architecture verankert die Business-Capability-Schicht als oberste der vier Interoperabilitäts-Layer. Auch privatwirtschaftliche DACH-Unternehmen orientieren ihre Capability Maps zunehmend an diesem Referenzmodell, weil Lieferketten und B2B-Schnittstellen ohne ein gemeinsames fachliches Vokabular nicht mehr tragfähig dokumentiert werden können.
Praxisbeispiel: Capability Map als ERP-Auswahl-Filter im DACH-Mittelstand
Auf den Punkt: Ein DACH-Maschinenbauer mit rund 300 Mitarbeitenden hat seine Capability Map in drei Workshop-Tagen auf 14 Level-1- und 47 Level-2-Capabilities verdichtet. Aus 600 Lastenheftseiten wurden 90 entscheidungsrelevante Bewertungspunkte — die ERP-Auswahl-Entscheidung fiel sechs Wochen später, rund sieben Monate früher als geplant.
Eine Warnung vorab: Aus über 1.200 Projekten im DACH-Mittelstand sehen wir, dass rund 70 Prozent der Capability Maps in der ersten Iteration zu fein granular geraten — und damit ihre Wirkung als Entscheidungswerkzeug verfehlen. Der Wert liegt nicht in der Vollständigkeit, sondern in der Trennschärfe.
Ein anonymisierter Maschinenbau-Mittelständler mit rund 300 Mitarbeitenden stand vor einem ERP-Replacement. In über 30 Jahren hatte das Unternehmen drei ERP-Releases erlebt, das aktuelle Lastenheft war auf 600 Seiten gewachsen, vier Vendoren standen in der Shortlist, und jede Demo verschob die Anforderungen erneut. Gemeinsam mit Geschäftsführung, Fachbereich und IT verdichteten wir die Diskussion in drei Workshop-Tagen auf 14 Level-1- und 47 Level-2-Capabilities. Drei davon wurden als differenzierend markiert, die übrigen als geschäftskritisches Commodity oder Hygiene.
Die Konsequenz für die Vendor-Auswahl war eindeutig. Bei den drei differenzierenden Capabilities forderten wir Tiefenfit — mit Referenzkundennachweisen und Lasttest. Bei den vierzig Commodity-Capabilities wurde der Standardumfang akzeptiert, ohne weitere Vertiefung. Diese Entscheidung war erst möglich, nachdem die Capability Map die Diskussion vom Detail-Ping-Pong auf die strategische Ebene gehoben hatte.
Wie wir Capability Maps in ERP-Auswahlen methodisch einsetzen
Auf den Punkt: In unserer Methodik ist die Capability Map kein Selbstzweck, sondern der erste konkrete Schritt nach der strategischen Klärung über das Business Model Canvas. Sie bildet die fachliche Brücke zwischen Geschäftsmodell und Vendor-Auswahl — in vier klar getrennten Phasen.
Eine Capability Map entsteht nicht aus einem Tool, sondern aus moderierten Gesprächen, in denen Geschäftsführerinnen und Geschäftsführer das eigene Geschäft erstmals in fachlicher Sprache verhandeln. Die Trennschärfe zwischen „echtem Wettbewerbsvorteil" und „Gewohnheit" liegt in der Diskussion, nicht in der Software. Aus unserer Erfahrung lassen sich vier Phasen klar trennen — aufbauend auf der strategischen Klärung über das Business Model Canvas.
Phase 1 — Erhebung des fachlichen Zielbilds. In einem dreitägigen Capability-Workshop mit Geschäftsführung, Fachbereichsleiterinnen und Fachbereichsleitern sowie der IT-Leitung entsteht eine Capability Map mit 12 bis 18 Level-1- und 40 bis 80 Level-2-Capabilities. Diese Granularität ist bewusst pragmatisch gewählt: Konzern-Bibliotheken mit über 200 Capabilities sind im Mittelstand nicht zu pflegen und verdecken die strategischen Hebel.
Phase 2 — Bewertung und Differenzierung. Jede Capability erhält zwei Werte: einen Soll-Reifegrad und ein Differenzierungs-Label (differenzierend, geschäftskritisch-Commodity oder Hygiene). Diese Phase ist die wichtigste und zugleich die unbequemste, weil sie die Geschäftsführung zwingt, ehrlich zu benennen, womit das Unternehmen tatsächlich Geld verdient — und womit nicht. Erfahrungsgemäß bleiben am Ende nur drei bis fünf echte Differenzierer übrig.
Phase 3 — Sourcing-Entscheidung. Für jede bewertete Capability klären wir den Umsetzungsweg entlang des Sourcing-Dreiecks Make, Buy, Configure. Die differenzierenden Capabilities prüfen wir auf echte Eigenentwicklung oder tiefe Anpassung; die Commodity- und Hygiene-Capabilities führen wir konsequent auf Konfiguration im Standard zurück. Das Ergebnis ist eine Sourcing-Landkarte, die spätere Customizing-Diskussionen vorwegnimmt.
Phase 4 — Vendor-Filter und Auswahl. Aus Reifegrad, Differenzierung und Sourcing entsteht ein gewichtetes Bewertungsraster. Differenzierende Capabilities steuern gezielte Tiefen-Demos und Referenzprüfungen, Commodity-Capabilities werden über Standardreferenzen abgedeckt. Diese Bewertung führen wir in unserer herstellerunabhängigen Auswahlmethodik SCOReX zusammen, die Vendor-Marketing transparent vom tatsächlichen Erfüllungsgrad trennt. Klarheit, Struktur, Praxis — diese drei Anker tragen das Vorgehen.
Häufige Fehler bei Capability Maps — der Anti-Pattern-Katalog
Auf den Punkt: Capability Maps scheitern selten am Konzept, oft an der Ausführung. Aus über 1.200 Projekten kennen wir vier wiederkehrende Anti-Muster, die in Mittelstandsprojekten regelmäßig auftauchen — sie kosten Wochen Projektzeit und entwerten das Werkzeug.
Die Detailtiefe-Falle ist der häufigste Fehler. Teams bohren bis auf Level 3 oder 4 hinunter und produzieren 200 und mehr Capabilities. Das Ergebnis ist eine Karte, die niemand mehr pflegt, die die strategischen Hebel verdeckt und nach sechs Monaten veraltet im Archiv liegt. Die Granularität muss der Entscheidungsfrage folgen, nicht dem Anspruch auf Vollständigkeit — im Mittelstand endet sie fast immer auf Level 2.
Die Tool-Falle beginnt mit der Annahme, eine Capability Map ließe sich aus einem EAM-Werkzeug ableiten. Das Werkzeug speichert und visualisiert die Karte — es erzeugt aber nicht die strategische Trennschärfe zwischen Differenzierung und Commodity. Wer die Tool-Lizenz vor der Methodik kauft, hat die Reihenfolge umgedreht und finanziert eine leere Datenbank. Erst die moderierte Bewertung, dann das Tool zur Verwaltung.
Die Capability-Prozess-Vermischung zeigt sich, sobald Verben in Capability-Namen auftauchen. „Aufträge erfassen" ist ein Prozess. „Kundenauftragsabwicklung" ist eine Capability. Die Unterscheidung wirkt akademisch, hat aber operative Konsequenz: Wer Verben in die Map lässt, verliert die Stabilität gegen Reorganisation und damit den eigentlichen Wert der Capability-Sicht. Die EAM-Initiative TU München führt diese Trennschärfe explizit als methodisches Kernkriterium.
Der fehlende Strategiebezug ist das schädlichste Anti-Muster. Eine Capability Map ohne Anbindung an Geschäftsmodell, Marktposition und Wettbewerb beschreibt nur Aktivitäten — sie liefert keine strategische Aussage. Im Mittelstand ist diese Anbindung zwingend, weil Investitionsbudgets begrenzt sind und jede Fehlinvestition in EAM und ERP-Auswahl spürbar bleibt.
Häufig gestellte Fragen
Eine Capability Map beschreibt, was ein Unternehmen tun können muss, ohne Reihenfolge oder Bewegung. Eine Prozesslandkarte beschreibt, wie diese Fähigkeiten ausgeführt werden, mit Sequenz, Schnittstellen und Verantwortlichkeiten. Die Capability Map ist stabil über Reorganisationen, die Prozesslandkarte ändert sich mit jeder organisatorischen Anpassung. Beide Sichten ergänzen sich, eine ersetzt die andere nicht.
Aus unserer Erfahrung mit Mittelständlern zwischen 100 und 2.000 Mitarbeitenden in DACH liegt der pragmatische Korridor bei 12 bis 18 Level-1-Capabilities und 40 bis 80 Level-2-Capabilities. Konzern-Bibliotheken mit 200 plus Capabilities sind im Mittelstand nicht zu pflegen, sie verdecken die strategischen Hebel und werden nach sechs Monaten nicht mehr aktualisiert. Die Granularität folgt der Entscheidungsfrage, nicht der theoretischen Vollständigkeit.
Die Capability Map ist der zentrale Filter zwischen fachlichem Soll und Vendor-Standardumfang. Sie ersetzt das traditionelle Lastenheft als Hauptdokument der Vendor-Auswahl, weil sie die Anforderungen auf 30 bis 80 entscheidungsrelevante Bewertungsachsen reduziert. Tiefen-Demos werden gezielt für differenzierende Capabilities aufgesetzt, Commodity-Capabilities werden über Standardreferenzen abgedeckt. Diese Verkürzung halbiert in unseren Projekten die Vendor-Auswahlzeit ohne Qualitätsverlust.
Nächste Schritte
Eine Capability Map ist im Mittelstand kein dokumentarisches Beiwerk, sondern der erste konkrete Schritt jeder fundierten ERP-Auswahl. Sie hält das fachliche Zielbild stabil, während Markt, Vendoren und interne Diskussionen sich bewegen. Wer eine Capability Map sauber baut, trennt Differenzierendes von Commodity, ersetzt Anforderungs-Wildwuchs durch fachliche Bewertungsachsen und führt die Make-or-Buy-Entscheidung in derselben Sicht. Wer sie überspringt, entscheidet über siebenstellige Investitionen ohne stabile fachliche Grundlage.
Wenn Sie planen, in den nächsten zwölf Monaten eine ERP-Auswahl oder eine EAM-Initiative aufzusetzen, ist jetzt der richtige Zeitpunkt, mit einer Capability Map zu starten. Wir begleiten DACH-Mittelständler seit drei Jahrzehnten in genau dieser Phase — von der ersten Capability-Skizze bis zur Vendor-Entscheidung. Lesen Sie dazu auch unsere Einblicke zur ERP-Auswahl im Mittelstand.
