Die dominierende Planungseinheit in den meisten Unternehmen ist das Projekt, dicht gefolgt vom System oder von der Anwendung. Beide sind praktisch, weil sie sich sauber darauf abbilden lassen, wie Geld freigegeben und wie die Umsetzung personell besetzt wird. Beide sind jedoch auch schlechte Einheiten, um über Strategie nachzudenken, denn keine ist stabil und keine lässt sich aggregieren. Ein Projekt ist ein temporäres Vehikel, das sich auflöst, sobald sein Umfang geliefert ist, und dabei seine Begründung mitnimmt. Ein System ist eine Umsetzungsentscheidung, die abgelöst werden wird. Wenn das Planungsgespräch in diesen Begriffen geführt wird, wird das Portfolio zu einer Einkaufsliste, deren Posten sich nicht vergleichen lassen, weil ein Programm zur Modernisierung des Zahlungsverkehrs und ein CRM-Upgrade in nicht vergleichbarer Sprache beschrieben und mit nicht vergleichbarem Nutzen begründet werden.

Die praktischen Symptome sind vertraut. Dieselbe zugrunde liegende Schwäche wird dreimal unter drei Projektnamen finanziert, weil niemand sie als eine einzige Sache erkannt hat. Investitionen konzentrieren sich dort, wo der lauteste Sponsor sitzt, statt dort, wo das Unternehmen am stärksten exponiert ist. Doppelarbeit häuft sich an, weil zwei Abteilungen jeweils eine Fähigkeit aufbauen, die in Wahrheit dieselbe Fähigkeit ist, die denselben Kunden bedient. Und wenn die Führung die berechtigte Frage stellt, was eine bestimmte Ausgabe der Organisation tatsächlich bringt, gemessen daran, was sie nun besser kann, kommt die Antwort im Vokabular der Liefergegenstände statt in dem der Ergebnisse.

Das ist heute aus zwei Gründen wichtiger als noch vor einem Jahrzehnt. Erstens sind Tempo und Kosten des technologischen Wandels gestiegen, sodass die Strafe für Investitionen an der falschen Stelle schneller zu Buche schlägt. Zweitens ist die Systemlandschaft stärker verteilt und mischt Legacy-Plattformen, Standardsoftware und Cloud-Dienste, was das Denken auf Systemebene noch weniger geeignet macht, eine Frage auf Geschäftsebene zu beantworten. Capability-basierte Planung ist wichtig, weil sie der Führung eine Sprache gibt, die stabil genug ist, um danach zu planen, und abstrakt genug, um unternehmensweit vergleichen zu können.

Eine Business-Capability ist ein Ausdruck dessen, was eine Organisation tut, bewusst getrennt davon, wie, wo oder durch wen sie es tut. Einen Kunden onboarden ist eine Capability. Das Onboarding-Portal, das KYC-Team und der Dienst zur Identitätsprüfung gehören zu den Dingen, die sie realisieren. Die Disziplin, das Was vom Wie zu trennen, ist der eigentliche Kern, denn genau diese Trennung macht die Capability stabil, während die Umsetzungen darunter im Wandel sind. Eine gut gebildete Capability wird als stabile, substantivorientierte Fähigkeit benannt, sie wird einmal für das gesamte Unternehmen definiert, und sie kodiert weder das aktuelle Betriebsmodell noch die aktuelle Technologie.

Capabilities werden in einer Capability-Map organisiert, einer strukturierten Zerlegung des Unternehmens in Ebenen. Ebene eins enthält eine kleine Zahl grober Gruppierungen, typischerweise zwischen zehn und zwanzig, die das gesamte Geschäft abdecken. Jede zerfällt in Ebene zwei und, wo sinnvoll, in Ebene drei und wird feingranularer, ohne jemals in Prozessdetails abzugleiten. Die Map ist kein Prozessmodell und kein Organigramm. Ein Prozess beschreibt eine Abfolge von Schritten über die Zeit. Eine Organisationseinheit beschreibt, wer an wen berichtet. Eine Capability beschreibt eine stabile Fähigkeit, die viele Prozesse ausüben und zu der viele Einheiten beitragen. Diese drei zu verwechseln ist die häufigste Art, ein Capability-Modell schon bei der Geburt zu verderben.

Die Map verdient ihren Wert erst, wenn sie in zwei Richtungen verbunden ist. Nach oben wird jede Capability mit den strategischen Ergebnissen und Zielen verknüpft, denen sie dient, sodass sich der Anspruch auf die Fähigkeiten zurückverfolgen lässt, von denen er abhängt. Nach unten wird jede Capability mit den Anwendungen, Daten, Menschen und Prozessen verknüpft, die sie realisieren, sodass sich eine Entscheidung über eine Fähigkeit auf alles zurückverfolgen lässt, was sie berührt. Mit beiden Verknüpfungen wird die Capability zu einem Verbindungspunkt. Eine strategische Priorität löst sich in die wenigen Capabilities auf, auf denen sie wirklich ruht, und jede davon löst sich in die konkreten Systeme und Teams auf, die sich ändern müssten. Die Heat-Map macht dies handlungsfähig: Jede Capability wird auf Dimensionen wie strategische Bedeutung, aktueller Reifegrad, Kosten, Risiko und Geschäftswert bewertet und visuell dargestellt, sodass die kleine Gruppe von Capabilities, die zugleich hochbedeutend und schlecht bedient sind, sofort ins Auge fällt. Diese Schnittmenge, hohe Bedeutung bei geringer Leistung, ist der Ort, an den die Investition gehört.

Capability-Modellierung ist nicht neu, doch mehrere Entwicklungen haben sie von einer Diagramm-Übung hin zu einem lebendigen Planungsinstrument verschoben. Die erste ist die Reifung von Enterprise-Architecture-Repositories und Portfolio-Werkzeugen zu Plattformen, die die Capability-Map als erstklassiges Objekt halten und sie an das Anwendungs- und Technologie-Inventar binden. Wenn die Map mit realen Daten darüber verbunden ist, welche Anwendungen welche Capabilities zu welchen Kosten und mit welcher technischen Gesundheit unterstützen, hört die Heat-Map auf, eine Workshop-Meinung zu sein, und wird zu einer belastbaren Einschätzung der Systemlandschaft. Die Bewertung kann teilweise abgeleitet statt vollständig behauptet werden, und genau das verleiht ihr Autorität vor einem Finanzausschuss.

Die zweite ist die Ausrichtung von Capabilities an Value Streams und an produktorientierten Betriebsmodellen. Wenn Organisationen ihre Finanzierung von Projekten hin zu langlebigen Produktteams umorganisieren, braucht die Frage, wofür jedes Team verantwortlich ist, eine stabile Antwort, und Capabilities liefern sie. Ein Produkt oder eine Stufe eines Value Streams wird in den Capabilities verankert, die es liefert, sodass die Verschiebung von der Projektfinanzierung hin zur dauerhaften Produktfinanzierung die Capability-Map als Rückgrat erbt, statt den Umfang in jedem Planungszyklus neu zu erfinden.

Die dritte ist die Schärfung der Make-or-Buy-Überlegung, während Software zu Subscription- und Cloud-Bereitstellung übergeht. Wenn die meisten Capabilities durch einen Standarddienst erfüllt werden können, wird die strategische Frage, welche Capabilities wirklich differenzierend und daher wert sind, gebaut oder gestaltet zu werden, und welche notwendig, aber nicht differenzierend sind und daher am besten gekauft und standardisiert werden. Capability-basierte Planung ist der natürliche Ort, um diese Entscheidung bewusst zu treffen, statt anbieterweise. Die vierte Entwicklung ist das Aufkommen von KI und Automatisierung als mögliche Realisierungen. Eine Capability-Perspektive hält die Frage diszipliniert: nicht, wo wir ein Modell aufsetzen können, sondern welche konkreten Fähigkeiten sich durch Augmentierung wesentlich verbessern würden, und ob diese Fähigkeit wichtig genug ist, um die Exposition zu rechtfertigen. In jedem Fall ist die Map dasjenige, was verhindert, dass ein allgemeiner Trend wahllos angewendet wird.

Der Unterschied zwischen einer Capability-Map, die Investitionen über Jahre leitet, und einer, die leise aufgegeben wird, liegt fast vollständig in der Design-Disziplin. Das erste Prinzip lautet, dass Capabilities Ergebnisse beschreiben, nicht Organisation. Wenn eine Capability nach einer Abteilung oder einem aktuellen System benannt ist, wird sie in dem Moment neu gezeichnet, in dem sich eines von beiden ändert, und die Stabilität, die den ganzen Ansatz rechtfertigte, geht verloren. Die Map muss eine Reorganisation unberührt überstehen. Dies ist das einzelne am schwersten zu haltende Prinzip, weil die Menschen im Raum das Geschäft naturgemäß so beschreiben, wie sie es erleben, durch ihre eigene Funktion.

Das zweite Prinzip ist eine einheitliche, konsistente Abstraktionsebene innerhalb jeder Schicht der Map. Geschwister sollten in etwa gleich granular sein, sodass nicht ein Ast bis ins feine operative Detail zerlegt wird, während ein anderer grob bleibt. Ungleichmäßige Zerlegung zerstört die Vergleichbarkeit, und Vergleichbarkeit ist der Grund, warum die Map existiert. Das dritte Prinzip ist, dass Capabilities so weit wie praktikabel überschneidungsfrei und vollständig sein sollten: Jede bedeutsame Fähigkeit des Geschäfts erscheint einmal und nur einmal. Überschneidung erzeugt das Problem der Doppelfinanzierung, das die Map lösen sollte, und Lücken verbergen Exposition.

Das vierte Prinzip ist die bewusste Eins-zu-viele-Beziehung zwischen einer Capability und ihren Realisierungen. Eine einzelne Capability kann von mehreren Systemen geliefert werden, und ein einzelnes System kann zu mehreren Capabilities beitragen. Diese Viele-zu-viele-Abbildung ehrlich zu bewahren, statt eine ordentliche Fiktion von einem System pro Capability zu erzwingen, ist das, was die Map Doppelarbeit und Fragmentierung sichtbar machen lässt. Das fünfte Prinzip betrifft die Heat-Map selbst: Ihre Bewertungsdimensionen müssen explizit definiert und konsistent angewendet werden, und Bedeutung muss an der Strategie gemessen werden, nicht daran, wie viel Aufmerksamkeit eine Capability derzeit erhält. Eine Capability kann beschäftigt, teuer und gut besetzt sein und dennoch wenig zum strategischen Anspruch beitragen, und nur eine ehrliche Bedeutungsachse wird das aufdecken. Schließlich muss die Map als lebendiges Asset mit einem klaren Eigentümer geführt werden, denn ein ungepflegtes Capability-Modell verfällt innerhalb eines einzigen Planungszyklus zu einem historischen Artefakt.

Die Tapeten-Map. Der häufigste Fehlschlag ist eine Capability-Map, die als einmaliger Liefergegenstand erstellt, kurz bewundert und dann nie mit irgendetwas verbunden wird. Ohne Verknüpfungen nach oben zur Strategie und nach unten zu den Systemen und ohne eine Heat-Map, die eine Entscheidung antreibt, ist sie ein Bild. Der Test ist einfach: Wenn keine Investitionsentscheidung anders getroffen wurde, weil die Map existiert, dann ist die Map gescheitert, egal wie elegant sie aussieht.

Das getarnte Organigramm. Wenn Capabilities rein aus Abteilungsleitern gewonnen werden, die ihre eigenen Bereiche beschreiben, spiegelt die Map am Ende die aktuelle Struktur wider. Sie liest sich plausibel, ist aber brüchig, und sie führt genau die Instabilität wieder ein, die Capabilities beseitigen sollten. Das Heilmittel ist, Fähigkeiten so zu benennen, dass sie auch dann noch zuträfen, wenn die gesamte Organisation morgen umstrukturiert würde.

Das getarnte Prozessmodell. Teams gleiten häufig von Capabilities in Prozesse ab und zerlegen eine Fähigkeit in ihre Schritte. Die Map füllt sich mit Verben und Abfolgen, wird riesig und verliert die Abstraktion, die sie für die Planung nützlich machte. Eine Capability beantwortet, was das Geschäft kann; in dem Moment, in dem sie in welcher Reihenfolge zu antworten beginnt, ist sie zu einem anderen Artefakt geworden.

Falsche Präzision in der Heat-Map. Eine Heat-Map, die nach Workshop-Stimmung eingefärbt ist, trägt die visuelle Autorität von Daten ohne deren Substanz. Wenn eine Capability rot markiert wird, weil ein lautstarker Stakeholder frustriert ist, oder grün, weil sich niemand beschwert hat, führen die Farben in die Irre. Bewertungen brauchen eine benannte Grundlage, idealerweise teils in objektiven Signalen wie Kosten, Störungsraten oder Anwendungsgesundheit verankert, und die Begründung der Bewertung muss festgehalten werden, damit sie hinterfragt werden kann.

Den Ozean auskochen. Versuche, jede Capability bis auf die tiefste Ebene zu modellieren, bevor man überhaupt etwas mit der Map anfängt, erschöpfen ihre Sponsoren lange bevor sie Wert liefern. Die Systemlandschaft ist groß, die Bereitschaft für Workshops ist endlich, und eine vollständig zerlegte Map, die eintrifft, nachdem sich das Planungsfenster geschlossen hat, hilft niemandem. Die Disziplin besteht darin, bis zu der Tiefe zu modellieren, die eine Entscheidung erfordert, und nicht weiter. Herrenloser Verfall vollendet das Muster: Selbst eine gute Map driftet, sobald niemand mehr für ihre Aktualität verantwortlich ist, von der Systemlandschaft ab und verliert leise das Vertrauen der Menschen, für die sie gebaut wurde.

Nashua begreift Capability-basierte Planung als Mittel zu einer Entscheidung, nicht als Modellierungsprojekt mit eigenem Selbstzweck. Wir beginnen bei der Strategie, denn eine Capability-Map hat keine Bedeutungsachse, solange die angestrebten Ergebnisse der Organisation nicht explizit gemacht sind. Gemeinsam mit der Führung ermitteln wir, was das Geschäft erreichen will, und daraus, von welchen Capabilities diese Ergebnisse tatsächlich abhängen. Das verankert die Übung vom ersten Workshop an an der Konsequenz, statt eine umfassende Map auf der Suche nach einem Zweck zu erzeugen.

Anschließend konstruieren wir die Capability-Map selbst, zerlegt bis zu der Tiefe, die die aktuellen Entscheidungen rechtfertigen. Wir sind bewusst bei den Design-Prinzipien: ergebnisorientierte Benennung, eine konsistente Abstraktionsebene und eine Map, die eine Reorganisation überstehen würde. Wir widerstehen dem Sog hin zum Prozessdetail und hin zum Organigramm, weil wir gesehen haben, wie beides das Ergebnis leise ruiniert. Wo ein brauchbares Capability-Modell bereits existiert, bewerten und verfeinern wir es, statt neu zu beginnen, denn Kontinuität des Vokabulars ist an sich wertvoll.

Der Schritt, der die Map in einen Plan verwandelt, ist die Bindung der Capabilities an die Systemlandschaft. Wir verknüpfen jede Capability mit den Anwendungen, Daten und Prozessen, die sie realisieren, und stützen uns dabei auf das Anwendungsportfolio und, wo die Information vorliegt, auf reale Signale zu Kosten und technischer Gesundheit. Diese Abbildung legt Doppelarbeit, Fragmentierung und Lücken unmittelbar offen, und sie lässt die Heat-Map auf Evidenz statt auf Stimmung ruhen. Wir bewerten Capabilities nach Bedeutung, Reifegrad, Kosten und Risiko mit einer expliziten und festgehaltenen Begründung, und wir stellen die Schnittmenge aus hoher Bedeutung und geringer Leistung als Shortlist für Investitionen dar. Von dort arbeiten wir mit der Organisation daran, diese Shortlist in eine nach Capability ausgedrückte Veränderungs-Roadmap zu übersetzen, sodass jede Initiative klar benennt, welche Fähigkeit sie verbessert und um wie viel. Durchweg sind wir ehrlich bezüglich Tiefe und Tempo, modellieren bis zu der Auflösung, die eine Entscheidung braucht, und behandeln die Map als lebendiges Asset mit einem benannten Eigentümer statt als ein abzulegendes Dokument.

Was Nashua auszeichnet, ist das Beharren darauf, den Kreis von Strategie über Capability über System bis zur Investition zu schließen und ihn über die Zeit geschlossen zu halten. Viele Organisationen können eine Capability-Map erstellen. Weniger können eine erstellen, die an ihre reale Anwendungslandschaft gebunden, auf belastbarer Evidenz bewertet und damit verbunden ist, wie Geld tatsächlich freigegeben wird, sodass sich eine Änderung der strategischen Priorität sauber in eine Änderung dessen auflöst, wohin die Investition geht. Diese verbindende Arbeit, unspektakulär und präzise, ist der Ort, an dem der Wert Capability-basierter Planung entweder realisiert oder verloren wird, und es ist der Ort, auf den sich unsere Praktiker konzentrieren.

Es gibt zudem eine praktische Konsequenz, die verändert, was die Arbeit voraussetzen darf. Wenn ein Engagement eine Capability verlangt, die noch nicht existiert, muss es nicht auf einen Beschaffungszyklus oder die Roadmap eines Anbieters warten. Die Nashua 360 Enterprise Platform ist darauf ausgelegt, nahezu jede Funktion in hohem Tempo zu ermöglichen, durch extremes Vibe Coding: Was benötigt wird, wird in einfacher Sprache beschrieben und schnell generiert, aber stets innerhalb fester Architekturprinzipien und unter strenger Qualitätssicherung, sodass Geschwindigkeit niemals auf Kosten von Kohärenz, Sicherheit oder Kontrolle geht. Die Wirkung ist strategisch und nicht bloß praktisch. Sie verschiebt die Make-or-Buy-Grenze, hält Optionalität günstig und lässt die Architektur der Strategie folgen, statt die Strategie zu dem zu verbiegen, was zufällig im Regal stand.

Auf die Kombination kommt es an. Eine Capability-Map für sich ist ein Diagramm, und Portfolio-Werkzeuge für sich sind eine Datenbank von Anwendungen ohne geschäftliche Bedeutung. Nashua führt beides zusammen: die dauerhafte Sicht darauf, was das Geschäft können muss, gehalten gegen die lebendige Realität der Systeme, Daten und Kosten, die sie realisieren, und so geführt, dass das Bild wahr bleibt, während sich Strategie und Systemlandschaft entwickeln. Das Ergebnis, das unsere Kunden behalten, ist kein Liefergegenstand, sondern eine Fähigkeit. Die Führung gewinnt eine stabile Sprache, in der sie über Veränderung nachdenken kann, eine Heat-Map, die Investitionen auf echte Exposition statt auf Lärm lenkt, und die Gewissheit, dass sich jeder eingesetzte Euro auf eine Fähigkeit zurückführen lässt, in der besser zu werden das Geschäft bewusst gewählt hat. Das bedeutet es, in das zu investieren, was das Geschäft können muss, und es ist die Disziplin, die zu erhalten Nashua existiert.