Im ersten Teil dieser Serie haben wir das Konzept der „Business-Capabilities“ umrissen und erläutert, warum es für die Umsetzung von Strategien so nützlich ist. Aber was genau ist dieses nicht ganz leicht zu fassende Konzept und wie definiert man Capabilities?
Wie in dem vorangegangenen Blogbeitrag erwähnt, müssen Sie verstehen und darstellen, was ein Unternehmen tun kann und muss, um seinen Auftrag zu erfüllen, bevor Sie sich mit der Organisationsstruktur, den Geschäftsprozessen, den IT-Systemen und anderen Implementierungsaspekten befassen. So erhalten Sie das „Gesamtbild“, das Sie benötigen, um die oben genannten Herausforderungen zu bewältigen: Zunächst sollten Sie sich von der Organisationspolitik und den technischen Beschränkungen lösen und sich auf das Wesentliche konzentrieren, das benötigt wird.
Wir haben bereits festgestellt, dass Business-Capabilities dazu dienen, die Fähigkeiten eines Unternehmens zu beschreiben, d.h. was es unabhängig von der tatsächlichen Umsetzung zu tun in der Lage ist. Was es tun kann, umfasst natürlich das, was es heute tut, aber es beschreibt auch sein Potenzial. Das macht es in strategischen Diskussionen besonders relevant.
Das Konzept wurde bisher hauptsächlich im Verteidigungsbereich verwendet und daraus in die Disziplin der Business-Architektur übernommen. Um aus dem NATO Architecture Framework zu zitieren: „Eine Capability ist die Fähigkeit, unter spezifizierten Standards und Bedingungen eine gewünschte Wirkung zu erzielen. […] In NAF ist der Begriff vorbehalten, um eine Fähigkeit zur Erzielung eines Ergebnisses zu spezifizieren. In diesem Sinne ist Capability dispositionell – d. h. Ressourcen können eine Capability besitzen, auch wenn sie dies noch nie unter Beweis gestellt haben.“
Wichtig ist, dass das Capability-Konzept funktions- und organisationsübergreifend ist. Capabilities sind nicht an bestimmte Abteilungen, Funktionen oder Rollen in der Organisation gebunden. Vielmehr wird eine Fähigkeit durch das Zusammenwirken verschiedener Personen, Prozesse, Technologien, Informationen und anderer Ressourcen aus dem gesamten Unternehmen erreicht.
Bei der Identifizierung von Capabilities sollten Sie darauf achten, dass diese nicht an bestimmte Gegebenheiten gebunden sind. Fragen Sie sich beispielsweise, ob sich eine Capability ändern würde, wenn Sie eine Abteilung aufteilen oder ein neues System implementieren würden, das an der Bereitstellung dieser Capability beteiligt ist. Wenn ja, dann haben Sie wahrscheinlich keine echte Capability identifiziert.
Diese Abstraktion von der Realisierung ist auch der Grund dafür, dass das Konzept manchmal etwas schwierig zu verstehen und zu vermitteln ist. Die meisten Menschen sind es gewohnt, in Bezug auf die Organisationsstruktur, die Leitungsspanne, die eigenen Systeme, die von ihnen verwalteten oder ausgeführten Geschäftsprozesse usw. zu denken. Wenn man beispielsweise Managern eine Capability-Map zeigt, suchen sie oft nach “ihrem” Teil, von dem sie glauben, dass sie dafür verantwortlich sind, weil er z. B. ihrer Abteilung ähnelt. Das ist natürlich ein Irrtum, aber es ist nicht immer leicht, diese instinktive Reaktion zu überwinden.
Das Wichtigste bei der Definition von Business-Capabilities ist daher, dass sie von Fachexperten (nicht von IT-Abteilungen) benannt und in geschäftlichen Begriffen definiert werden. Die Definition sollte für alle Beteiligten leicht verständlich sein. Bei jeder Capability sollte glasklar sein, was sie für das Unternehmen leistet. Allzu oft sehen wir Capability-Maps, die von IT-Architekten ohne ausreichenden geschäftlichen Input entwickelt wurden, die technische Begriffe und Funktionalitäten auf Systemebene statt echter Business-Capabilities verwenden, die sich auf die Produktion einiger Daten konzentrieren, statt echte Geschäftsergebnisse zu liefern usw.
Es ist hilfreich, ein Benennungsschema zu verwenden, das Capabilities klar von anderen Konzepten abgrenzt, z. B. von Geschäftsprozessen und Wertströmen. Während ein Prozess oder ein Wertstrom das “Geschäft in Bewegung” definiert, indem er Aktivitäten aneinanderreiht, um eine dynamische Perspektive auf das Geschäftsverhalten zu ermöglichen, definieren Capabilities das potenzielle Verhalten eines Unternehmens, das “ruhende Geschäft”. Prozesse und Wertströme werden häufig mit einem Substantiv-Verb-Schema benannt, z. B. “Versicherungsanspruch bearbeiten”. Verben werden daher am besten in den Bezeichnungen von Capabilities vermieden, um Verwechslungen zu vermeiden und die “ruhendes Geschäft”-Perspektive zu betonen. Ein solches Benennungsschema hilft auch bei der Identifizierung von Capabilities. Wenn Sie versucht sind, eine Capability wie einen Geschäftsprozess zu benennen, sind Sie dann sicher, dass Sie wirklich eine Capability gefunden haben?
Ein Ansatz, der im BIZBOK®-Guide empfohlen wird, besteht darin, jede Capability auf der Grundlage eines bestimmten Geschäftsobjekts zu identifizieren und sie mit der Namenskonvention „Geschäftsobjekt – Aktion“ zu benennen. Laut BIZBOK darf diese Aktion nicht mit einem Verb ausgedrückt werden; selbst Gerundien wie Engineering, Marketing und Accounting sind ausdrücklich verboten: „Mapping-Teams sollten vermeiden, Gerundien als Grundlage für die Benennung von Capabilities zu verwenden, da sie keine Geschäftsobjekte sind und nur Substantive im nominalen Sinne darstellen.“ Aber nicht mal ihre eigenen Beispiele halten sich an dieses Gebot. Außerdem beinhaltet dieser Ansatz eine Fokussierung auf Informationen bzw. Daten und nicht auf die wahren Fähigkeiten des Unternehmens.
Anstatt nur Geschäftsobjekte als Grundlage für die Zerlegung und Unterscheidung von Capabilities zuzulassen, bevorzugen wir die klassischen Begriffe der Kopplung und Kohäsion. Wählen Sie diejenigen geschäftsrelevanten Kriterien aus, die die höchste interne Kohäsion und die geringste externe Kopplung von Capabilities erzeugen. Auf diese Weise erhalten Sie in sich geschlossene Capabilities, die eine relativ unabhängige Existenz haben und als echte Geschäftskomponenten fungieren können. Geschäftsobjekte sind sicherlich eine Möglichkeit, die Fähigkeiten eines Unternehmens zu gruppieren, aber sie sind keineswegs das einzige Kriterium. Märkte, Regionen, die Einhaltung von Vorschriften, das Tempo des Wandels, soziale Beziehungen und verschiedene andere Aspekte können bei der Identifizierung und Zerlegung von Capabilities eine Rolle spielen.
Natürlich sollte man sich von Details der Umsetzung fernhalten und sich auf das Wesentliche konzentrieren, aber das ist eine graduelle Unterscheidung und nichts Absolutes. Als Business-Architekten neigen wir dazu, gut zu verallgemeinern und zu abstrahieren, aber wir müssen vorsichtig sein. Es gibt kein Unternehmen ohne echte Menschen, die im Rahmen eines sozialen Gefüges konkrete Tätigkeiten ausführen. Wenn Sie davon zu sehr abstrahieren, verlieren Sie mit Sicherheit Ihr Zielpublikum.
Lassen Sie sich also nicht von allzu starren oder abstrakten Identifikations- oder Benennungsschemata ablenken. Das bei weitem Wichtigste ist, dass der Name einer Capability weithin bekannt ist und ihre Definition von allen Beteiligten verstanden wird als etwas, was das Unternehmen zu tun in der Lage ist. Konsistenz und Abstraktion von Implementierungsdetails sind wichtig und nützlich, aber nicht, wenn sie auf Kosten des Geschäftsverständnisses gehen.
Diese allgemeinen Richtlinien sollen Ihnen helfen, die Business-Capabilities zu ermitteln:
In den nächsten Teilen dieser Serie werden wir ausführlicher auf Capability-Based Planning, die Analyse, die Beziehungen zu anderen Konzepten der Unternehmensarchitektur und vieles mehr eingehen. In der Zwischenzeit können Sie in unserem Whitepaper weitere Einblicke in unsere Überlegungen zu diesem Thema gewinnen.