Business Capabilities E-Book

Wolf Pfannenstiel

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2023

Seitenzahl: 514

Beschreibung

Praxisleitfaden für Enterprise Architects - Umfassend und anwendungsbezogen - Ein Buch aus der Praxis für die Praxis - Mit »Real-world«-Beispielen von Capabilty Maps aus Unternehmen Das Konzept der Business Capabilities zur Beschreibung von Geschäftsfähigkeiten ist im Enterprise Architecture Management schon lange erfolgreich im Einsatz. Doch die Möglichkeiten zum nutzbringenden Einsatz von Capabilities sind deutlich umfangreicher und bieten sich bei vielen Aufgaben im Rahmen der Unternehmensentwicklung an. Dieses Buch bietet eine systematische Einführung in die Grundlagen, die Anwendung und die Vorbereitung für den Einsatz von Capabilities in der Praxis: von der Definition und den Eigenschaften von Capabilities über den Unternehmenskontext, Objekt- und Beziehungstypen und Kategorisierung sowie Einordnung in Rahmenwerke und Methoden bis hin zur Modellierung von Capabilities. Es gibt Ihnen einen flexiblen Werkzeugkasten an die Hand für den Einsatz von Capabilities in diversen Anwendungsfällen der Unternehmensentwicklung.

Leseprobe

Dr. Wolf Pfannenstiel arbeitete nach Studium und Promotion in Informatik an der TU Berlin zunächst mehrere Jahre als Business- Analyst und Softwareproduktmanager, bevor er sich auf Enterprise Architecture Management spezialisierte. Business Capabilities nutzt er als konzeptionelles Werkzeug seit mehr als 15 Jahren erfolgreich in Projekten verschiedener Art und Branchen. Seit 2015 arbeitet er bei der Innovationeers GmbH als Enterprise- und Lösungsarchitekt und begleitet sowohl die Vorbereitung als auch die Umsetzung von Innovations- und Transformationsvorhaben bei Konzernen und großen Mittelständlern.

Copyright und Urheberrechte:

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Wolf Pfannenstiel

Business Capabilities

Geschäftsfähigkeiten als effektivesWerkzeug für die Gestaltung vonUnternehmens- und IT-Architekturen

Wolf Pfannenstiel

[email protected]

Lektorat: Christa Preisendanz

Lektoratsassistenz: Julia Griebel

Copy-Editing: Ursula Zimpfer, Herrenberg

Layout & Satz: Wolf Pfannenstiel

Herstellung: Stefanie Weidner, Frank Heidt

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;

detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-86490-964-1

PDF

978-3-96910-985-4

ePub

978-3-96910-986-1

mobi

978-3-96910-987-8

1. Auflage 2023

Copyright © 2023 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde mit mineralölfreien Farben auf FSC®-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie. Hergestellt in Deutschland.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

Der erste Mal bin ich im Jahr 2006 mit Business Capabilities in Berührung gekommen, als ich beim Aufbau einer neuen IT-Architektur-Abteilung eines großen Logistik-Konzerns meine ersten Erfahrungen in der Disziplin des Enterprise Architecture Management machen durfte. Schon damals habe ich Business Capabilities (kurz Capabilities) als hilfreiches, fachlich ausgerichtetes Strukturierungsmittel kennengelernt, das sowohl die Architekturarbeit an sich erleichtert als auch die so wichtige Verständlichkeit von Architekturergebnissen verbessert. Seitdem haben sich Capabilities für mich zu einem Handwerkszeug entwickelt, das ich im Rahmen meiner Arbeit als Enterprise- und Lösungsarchitekt immer wieder aktiv einsetze.

Prominente und umfangreiche Rahmenwerke, wie beispielsweise TOGAF, nutzen das Konstrukt der Capabilities, doch in diesen Rahmenwerken findet sich typischerweise weder eine präzise, stringente Definition des Capabilities-Elements noch kommen sie durchgängig und konsistent zum Einsatz. Insbesondere das Thema der Modellierung von Capabilities kommt oftmals viel zu kurz, wenn es überhaupt adressiert wird. Der Nutzen von Capabilities ist jedoch eingeschränkt, wenn das eingesetzte Capability-Modell von unzureichender Qualität ist. Leider hapert es gerade bei der Qualität von Capability-Modellen häufig. Was manchmal als akademische Kleinlichkeit oder Pedanterie angesehen wird, würde ich in vielen Fällen eher als notwendige Präzision bezeichnen. Präzision hilft dabei, konsistente, gut verständliche Arbeitsergebnisse zu erstellen. Ungenauigkeit und fehlende Präzision führen oft zur Notwendigkeit, Ergebnisse zu interpretieren, und somit fast zwangsläufig zu Missverständnissen mit möglicherweise gravierenden Folgen. So ist der Anspruch an dieses Buch eine möglichst systematische und konsistente Betrachtung von Business Capabilities.

Vor etwa drei Jahren hatte ich die Idee, meine gesammelten Erfahrungen und das erworbene Wissen zum Thema Capabilities festzuhalten und anderen Menschen zugänglich zu machen. Ich fing an, eine erste Struktur für eine Dokumentation zu erstellen, und habe dann Stück für Stück die Inhalte zusammengetragen. Ich konnte nicht einschätzen, ob mein »Machwerk« von Interesse für einen Verlag sein könnte oder ob Lektorat und Reviewer vor Langeweile vom Stuhl kippen würden. Umso erfreuter bin ich, dass der dpunkt.verlag mein Buch verlegt. Ich danke insbesondere den anonymen Reviewern, die mir neben aller Kritik vor allem sehr wertvolle und wirklich motivierende Impulse gegeben haben, was ich zur Abrundung an Inhalten noch ergänzen sollte. Ich hoffe, mit diesem Buch eine kompakte und zugleich verständliche Informationsquelle für die Praxis geschaffen zu haben, die gleichermaßen als Einführung und Nachschlagewerk für das Thema Business Capabilities dienen kann. Wenn das Buch meiner Leserschaft gefällt und das Tor zum Einsatz von Business Capabilities öffnet oder einen bereits eingeschlagenen Weg in diese Richtung leichter macht, dann wäre ich darüber sehr glücklich, denn dann erfüllt das Buch seinen Zweck. Ich freue mich in diesem Zuge über Rückmeldungen und Berichte zu eigenen Erfahrungen und Projekten.

Ich verwende in diesem Buch so weit wie möglich deutsche Begrifflichkeiten. Ausnahme sind selbstverständlich etablierte, englische Fachbegriffe, zu denen auch der für dieses Buch zentrale Begriff »Business Capability« gehört. Zur Bezeichnung von Rollen, Akteuren, Personengruppen usw. verwende ich das generische Maskulinum. Selbstverständlich meine ich damit Menschen beliebigen Geschlechts.

Ich möchte dieses Vorwort dazu nutzen, Olaf Seemann meine Wertschätzung und meinen Dank auszudrücken. Er begleitet mich seit vielen Jahren sowohl als mein »Boss« als auch Kollege auf Augenhöhe. Ich danke ihm für die produktive Zusammenarbeit, die mir immer wieder die Möglichkeit geboten hat, Capabilities in vielen externen und internen Projekten einzusetzen. Gemeinsam teilen wir das Interesse an Capabilities und die Überzeugung ihrer Nützlichkeit. Ein herzlicher Dank geht auch an alle anderen ehemaligen und aktuellen Mitglieder des Teams bei den Innovationeers – insbesondere an Dr. Nelly Bubner und Daniel Hückelheim – für spannende Diskussionen, gemeinsame Modellierungen und Anwendungen von Capability-Modellen. Ebenso ist es mir ein Bedürfnis, mich bei meinem Kollegen Dr. Thomas von Lingen dafür zu bedanken, mir die organisatorische Seite der Unternehmensentwicklung nähergebracht zu haben. Ich schätze euch alle sehr.

Für ihr großes Verständnis und ihre unschätzbare emotionale Unterstützung danke ich von Herzen meiner Ehefrau, die insbesondere in der letzten Phase des Schreibens so manchen Abend und manches Wochenende auf gemeinsame Zeit mit mir verzichtet hat.

Ich widme dieses Buch meiner Tochter Samoa.

Wolf PfannenstielSwisttal, Februar 2023

Inhaltsverzeichnis

IBusiness Capabilities verstehen und einordnen

1Einführung

1.1Herausforderungen der Unternehmensentwicklung

1.1.1Transparenz

1.1.2Rasanter Wandel

1.1.3Digitale Komplexität

1.1.4Methodik

1.1.5Entscheidungs- und Steuerungsfähigkeit

1.1.6Agilität

1.2Business Capabilities im Überblick

1.3Nutzen von Capability-Modellen

1.4Inhalt und Zielgruppen des Buchs

2Definition und Eigenschaften von Business Capabilities

2.1Grundlegende Definition von Capabilities

2.2Struktur eines Capability-Modells

2.3Geforderte Eigenschaften von Capabilities

2.3.1Überschneidungsfreiheit

2.3.2Vollständigkeit

2.3.3Abgeschlossenheit

2.3.4Kohärenz

2.3.5Verständlichkeit

2.3.6Einheitlichkeit

2.3.7Akzeptanz

2.3.8Stabilität

2.4Abgrenzung des Capability-Konstrukts

2.4.1Abgrenzung zu Rahmenwerken

2.4.2Abgrenzung zu Methoden

2.4.3Abgrenzung zur Unternehmensmodellierung

2.4.4Abgrenzung zu schwergewichtigen Capability-Ansätzen

2.4.5Abgrenzung zu Geschäftsprozessen

2.5Zur Geschichte von Business Capabilities

3Business Capabilities im Unternehmenskontext

3.1Verknüpfung mit Unternehmenselementen

3.1.1Vorgaben und Steuerung

3.1.2Geschäftsarchitektur – Markt und Umwelt

3.1.3Geschäftsarchitektur – interne Organisation

3.1.4IT-Architektur

3.1.5Analyse und Bewertung

3.2Kategorisierung von Capabilities

3.2.1Eigenschaften von Kategorisierungen

3.2.2Statische vs. dynamische Kategorisierung

4Einordnung in Rahmenwerke und Methoden

4.1Unternehmens- und IT-Architekturgestaltung

4.1.1BIZBOK – Business Architecture Body of Knowledge

4.1.2TOGAF – The Open Group Architecture Framework

4.1.3Zachman Framework

4.2Reifegradmessung und Optimierung

4.2.1CMMI – Capability Maturity Model Integration

4.2.2IT-CMF – IT-Capability Management Framework

4.2.3Lean Six Sigma

4.3Business- und Anforderungsanalyse

4.3.1BABOK – Business Analysis Body of Knowledge

4.3.2IREB – International Requirements Engineering Board

4.4Agile Methoden

4.4.1Scrum

4.4.2SAFe – Scaled Agile Framework

IIBusiness Capabilities einsetzen

5Anwendungsfälle für Business Capabilities

5.1Beschreibung von Sichten

5.2Basissichten

5.2.1Sicht 1: Capability-Karte

5.2.2Sicht 2: Angereicherte Capability-Karte

5.2.3Sicht 3: Capability-Tabellenhierarchie

5.3Matrixdarstellungen für zweistellige Beziehungstypen

5.3.1Sicht 4: Capability-Objekt-Beziehungsmatrix

5.4Funktionale Bebauung

5.4.1Sicht 5: Capability-Bebauung (Matrix)

5.4.2Sicht 6: Capability-Bebauung (Tabellenhierarchie)

5.4.3Sicht 7: Funktionale Prozessbebauung

5.5Definition von Vorhabenumfängen

5.5.1Sicht 8: Funktionale Vorhabenumfänge (Karte)

5.5.2Sicht 9: Funktionale Vorhabenumfänge (Tabellenhierarchie)

5.5.3Sicht 10: Funktionale Vorhabenstufen

5.5.4Sicht 11: Vorhabenabgleich (Matrix)

5.6Migrationsbeschreibungen

5.6.1Sicht 12: Capability-Migration (Applikation)

5.6.2Sicht 13: Capability-Verteilung

5.6.3Sicht 14: Funktionale Applikationsmigrationen

5.7Realisierung von Marktprodukten

5.7.1Sicht 15: Marktproduktunterstützung (Karte)

5.7.2Sicht 16: Marktproduktanforderungen

5.8Nutzen- und Potenzialanalyse

5.8.1Sicht 17: Capability-Realisierung (Ist)

5.8.2Sicht 18: Capability-spezifische Nutzenpotenziale

5.9Architekturdokumentation

5.9.1Sicht 19: Capability-basierte Zielarchitektur

5.10Capability-basierte Analysen und Bewertungen

5.10.1Sicht 20: Capability-basierte Heatmap

5.11Anforderungen von Wertketten

5.11.1Sicht 21: Wertkettenanforderungen (Matrix)

6Fallstudien

6.1Fallstudie System-Monitoring

6.1.1Monitoring-Capabilities

6.1.2Diskussion der Modellierung

6.1.3Skizzierung der Anwendungsfälle

6.2Fallstudie Güterproduktion

6.2.1Capability-Modell für das verarbeitende Gewerbe

6.2.2Abgleich des Modells mit einem LeanIX-Standardmodell

6.3Fallstudie digitale Fahrzeugdienste

6.3.1Wertschöpfungskette digitaler Fahrzeugdienste

6.3.2Auswahl der Fahrzeugdienste

6.3.3Capability-Modell für digitale Fahrzeugdienste

6.3.4Capability-Bedarf der Fahrzeugdienste

6.3.5Entwicklung der Zielbebauung

6.3.6Festlegung zentraler Anforderungen

IIIBusiness Capabilities für den Einsatz vorbereiten

7Modellierung von Business Capabilities

7.1Entwurfs- und Schnittkriterien

7.1.1Objektorientierter Schnitt

7.1.2Funktionsorientierter Schnitt

7.1.3Kontextorientierter Schnitt

7.1.4Wahl der Schnittkriterien

7.1.5Ungeeignete Entwurfs-/Schnittkriterien

7.1.6Überschneidungsfreiheit bei großer Modelltiefe

7.2Informationsquellen für die Modellierung

7.2.1Geschäftsprozesse

7.2.2Wertketten

7.2.3Informations-/Datenmodelle

7.2.4Applikationen

7.2.5Ressourcen

7.2.6Kompetenzen

7.2.7Marktprodukte

7.2.8Organisationseinheiten

7.2.9Kanäle

7.2.10Strategien

7.2.11Regelwerke

7.2.12Ereignisse

7.3Bezeichnungen von Capabilities

7.3.1Ungeeignete Namen und Bestandteile

7.3.2Einheitlichkeit von Bezeichnungen

7.3.3Aktivitätsbezeichnungen

7.3.4Namenskonventionen

7.4Orthogonale Modellierungsaspekte

7.5Capabilities für vererbte Objekttypen

7.5.1Capabilities nur für die Basisklasse

7.5.2Capabilities für jede Unterklasse

7.5.3Capabilities für Basisklasse und Unterklassen

7.6Wahl der Reihenfolge der Ebenenmodellierung

8Leitfaden für die Einsatzvorbereitung

8.1Voraussetzungen für den Capability-Einsatz

8.2Vorbereitung des Capability-Einsatzes

8.2.1Prüfung der Voraussetzungen

8.2.2Herbeiführen der Entscheidung

8.2.3Aufsetzen des Capability-Modells

8.2.4Tipps für die Praxis

8.2.5Alternative Ordnungsrahmen

8.3Technische Werkzeuge

8.3.1Architektur- und Capability-Software

8.3.2LeanIX

8.3.3CAPAMAP

8.3.4Sparx Enterprise Architect

8.3.5Allgemeine Werkzeuge

IVAnhang

AAusgewählte Objekt- und Beziehungstypen

A.1Beschreibung der Objekt- und Beziehungstypen

A.2Anforderungen

A.3Applikationen

A.4Auswirkungen

A.5Befunde

A.6Ereignisse

A.7Informationsobjekttypen

A.8IT-Infrastrukturkomponenten

A.9Kanäle

A.10Kompetenzen

A.11Marktprodukte

A.12Organisationseinheiten

A.13Orte

A.14Partner

A.15Prozesse

A.16Regelwerke

A.17Ressourcen

A.18Rollen

A.19Schnittstellen

A.20Strategien

A.21Technologien

A.22Vorhaben

A.23Wertketten

A.24Ziele

BVertiefte Einordnung ausgewählter Rahmenwerke

B.1BIZBOK

B.1.1Bestandteile von BIZBOK

B.1.2Capabilities im BIZBOK-Metamodell

B.1.3Wertströme und Capabilities

B.1.4Fazit

B.2TOGAF

B.2.1TOGAFs Architecture Capability

B.2.2Das TOGAF-Metamodell und Capabilities

B.2.3Business Capabilities in der ADM

B.2.4TOGAF-Leitfaden zu Business Capabilities

B.2.5Fazit

B.3CMMI

B.3.1Modellstruktur und Reifegrade

B.3.2Der Capability-Begriff in CMMI

B.3.3Fazit

B.4BABOK

B.4.1Struktur von BABOK

B.4.2Nutzung von Capabilities in BABOK

B.4.3BABOK-Technik: betriebliche Fähigkeitsanalyse

B.4.4Fazit

B.5Scrum

B.5.1Eigenschaften von Scrum

B.5.2Nutzung von Capabilities mit Scrum

B.5.3Fazit

B.6SAFe

B.6.1Eigenschaften von SAFe

B.6.2Möglicher Einsatz von Business Capabilities in SAFe

B.6.3Fazit

Abbildungsverzeichnis

Tabellenverzeichnis

Literaturverzeichnis

Index

Teil I

Business Capabilities verstehen und einordnen

1Einführung

Kein Unternehmen kommt heute mehr ohne Informationstechnologie aus. Die IT-Applikationen und digitalen Werkzeuge sind geschäftskritische Bestandteile der Unternehmensarchitektur, ohne die im Tagesgeschäft so gut wie nichts mehr geht.

In vielen Unternehmen wächst die IT-Landschaft seit Jahrzehnten und hat typischerweise eine hohe Gesamtkomplexität erreicht. Nicht selten hat man es mit Hunderten oder noch mehr Systemen und Schnittstellen zu tun, die erst im Zusammenspiel einen effektiven Geschäftsbetrieb ermöglichen. Unter dieser Komplexität leidet oftmals die Fähigkeit, Änderungen an der IT-Landschaft leicht und flexibel vornehmen zu können. Gleichzeitig gibt es jedoch eine Reihe von Faktoren, die Unternehmen zu immer schnellerem Agieren zwingen. Zu diesen Faktoren gehören der stetige Wandel von Märkten und Kundenansprüchen, das rasante Fortschreiten der technologischen Entwicklung mit dem Druck der Digitalisierung und die fortlaufenden Änderungen zu beachtender Gesetze und Regularien, um nur einige zu nennen. Wenn sie weiterhin erfolgreich sein möchten, zwingen diese Veränderungen Unternehmen zu ebenso stetiger Anpassung der Unternehmensarchitektur – inkl. Änderungen an IT-Landschaften, Technologiewahl oder sogar am Geschäftsmodell selbst. Zahlreiche und komplexe Vorhaben sind die Folge, die in immer kürzerer Zeit auf immer mehr Anforderungen reagieren müssen. Dies impliziert auch einen höheren Anspruch an die zu bewältigenden Führungsaufgaben und Entscheidungsprozesse in Unternehmen. Das Management muss in hoher Taktung auf neue Impulse und äußere Anforderungen reagieren. Eine aktive Steuerung zur nachhaltigen Umsetzung von Vorhaben wird damit zunehmend schwieriger. Um große IT-Landschaften und die zu ihrer Weiterentwicklung notwendigen Vorhaben erfolgreich ausgestalten und steuern zu können, sind geeignete Methoden und Werkzeuge erforderlich.

Dieses Buch beschäftigt sich mit »Business Capabilities« (kurz Capabilities), die ein solches, vielseitig einsetzbares Werkzeug bei der Unternehmensentwicklung darstellen. Capabilities repräsentieren Geschäftsfähigkeiten, die ein Unternehmen zur Umsetzung seines Geschäftsmodells benötigt.

Im Rahmen des Enterprise Architecture Management (EAM) werden Capabilities bereits seit geraumer Zeit als Werkzeug verwendet, und in erfolgreichen EAM-Werkzeugen wie LeanIX sind sie integraler Teil des Metamodells [47]. Schon lange bezeichnet der Branchenverband bitkom Capabilities als Bindeglied zwischen Geschäftsprozessmanagement, IT-Architektur und Geschäftsstrategie [80].

In diesem Buch möchte ich zunächst eine leichtgewichtige und zugleich flexible Variante von Capabilities vorstellen, die sich in Unternehmen als ein zentraler, fachlich orientierter Ordnungsrahmen in verschiedenen Arten von einmaligen Vorhaben (z.B. Projekten) und regulären Linientätigkeiten einsetzen lassen. Neben der konzeptionellen Definition zeige ich die Einbettung von Capabilities in den Unternehmenskontext, stelle eine Reihe nützlicher Anwendungsfälle vor und präsentiere einige Fallstudien. Zudem enthält das Buch eine Anleitung zur Modellierung von Capabilities sowie einen Leitfaden für deren Einführung. Abschnitt 1.4 zeigt den Aufbau des Buchs ausführlich.

Auch wenn vermutlich die meisten bejahen würden, dass eine strukturierte und systematische Herangehensweise an komplexe Themen hilfreich ist, so steht man als Verwender des Begriffs »Methodik« in Unternehmen nicht selten im Verdacht, ein praxisferner, akademischer Theoretiker zu sein. Ich definiere in diesem Buch kein Rahmenwerk und keine Methode im engeren Sinne, möchte jedoch aufzeigen, dass die stringente Anwendung eines methodischen Werkzeugs nicht im Widerspruch zu effizientem, praxistauglichem Vorgehen stehen muss. Im Gegenteil, diese Stringenz verhilft zu mehr Einheitlichkeit, Transparenz und Verständnis, die allen Beteiligten zugutekommt.

1.1Herausforderungen der Unternehmensentwicklung

Unternehmensentwicklung ist ein komplexes Unterfangen, für dessen Komplexität verschiedene Faktoren verantwortlich sind. Die folgenden Abschnitte führen einige dieser Faktoren als wesentliche Herausforderungen für Unternehmen auf. Einen Überblick darüber, wie Capabilities dabei helfen können, diese Herausforderungen zu meistern, gibt Abschnitt 1.3.

1.1.1Transparenz

Unternehmen sind heute komplexe Gebilde, die aus einer Vielzahl abhängiger Elemente bestehen. Zu diesen Elementen gehören unter anderem die Geschäftsprozesse, Organisationseinheiten, Marktprodukte und IT-Applikationen. Die Weiterentwicklung eines Unternehmens erfordert die Veränderung der relevanten Unternehmenselemente, sodass das Unternehmen die gesetzten Ziele seiner Bemühungen zur Weiterentwicklung möglichst gut erreicht.

Die Disziplin der Unternehmensmodellierung beschäftigt sich damit, die wesentlichen Elemente von Unternehmen systematisch zu erfassen und miteinander in Beziehung zu setzen. Ein Modell des Unternehmens kann dabei helfen, Transparenz über den jeweiligen Status quo zu erlangen, Analysen zu erstellen und Handlungsbedarfe zu ermitteln [75]. Auch wenn Unternehmensmodellierung ein nützliches Unterfangen ist, so ist diese Aufgabe sowohl komplex als auch zeitaufwendig. Bei den meisten Unternehmen fehlen daher umfängliche Unternehmensmodelle. Gleichzeitig geht damit allerdings auch ein Mangel an Transparenz einher, der insbesondere bei der Umsetzung komplexer Veränderungsvorhaben äußerst hinderlich ist. Plant man ein Vorhaben und kennt dabei die betroffenen Unternehmenselemente sowie deren Abhängigkeiten nicht, so sind spät entdeckte Hindernisse und unerwartete Schwierigkeiten vorprogrammiert. Benötigt wird insbesondere ein übergreifend gültiger Ordnungsrahmen, der eine fachlich orientierte, funktionale Einordnung von Unternehmenselementen ermöglicht.

Statt eines systematischen, wiederverwendbaren Ordnungsrahmens nutzen die Linien-, Vorhaben- oder Themenverantwortlichen in Unternehmen jedoch oftmals eigene Strukturierungs- und Beschreibungsmittel, die ad hoc definiert und nicht ausreichend systematisch aufgebaut sind. Eine Wiederverwendung dieser Mittel ist weder vorgesehen noch wäre sie sinnvoll möglich. Ergebnistypen und Darstellungen sind über organisatorische bzw. Vorhaben hinweg nur schwer vergleichbar. Damit ist es insbesondere für das Management schwierig, einen übergreifenden Überblick zu gewinnen.

Capabilities für sich alleine modellieren ein Unternehmen nicht erschöpfend, können jedoch für viele Zwecke als übergreifend nutzbarer Ordnungsrahmen dienen, der die Vergleichbarkeit von Ergebnistypen erhöht und sich somit auch zur Verbesserung der Transparenz im Unternehmen eignet.

1.1.2Rasanter Wandel

Unternehmen haben es mit einer Reihe von exogenen (von außen kommenden) und endogenen (von innen stammenden) Einflüssen zu tun, die ständig neue Änderungen erforderlich machen. Relevant sind hier beispielsweise die folgenden Faktoren:

Prozesse und IT-Applikationen müssen sich immer wieder an die sich ändernden Gesetze und Regularien anpassen.

Reorganisationen in Unternehmen sind nicht selten und bedeuten immer Anpassungen von Verantwortlichkeiten, Rollen und Zugehörigkeiten, die auch mit Veränderungen von Tätigkeiten des Personals verbunden sind.

Die schnell voranschreitende technologische Entwicklung bietet einerseits fortwährend neue Chancen, bedingt jedoch andererseits auch die schnelle Alterung des eingesetzten Technologieportfolios, die zum Handeln zwingt, möchte die Unternehmung nicht ebenso fortwährend (weitere) technische Schulden aufbauen.

Die Kundschaft wird zunehmend anspruchsvoller und fordert neue, innovative Produkte mit digitalem Zugang und digitalem Mehrwert.

Mitbewerbern, die digitale oder andere Innovationen bieten, muss das Unternehmen etwas entgegensetzen, um nicht den Anschluss am Markt zu verlieren.

Die Liste der Einflussfaktoren ließe sich leicht noch erweitern und detaillieren. Quintessenz an dieser Stelle ist, dass Unternehmen sich immer schneller verändern müssen und gleichzeitig die Komplexität von Produkten, Technologien, Regularien usw. immer größer wird.

Die Steuerung des Unternehmens gerät im Angesicht dieses rasanten Wandels zur Herausforderung. Es ist schwer, überhaupt noch Konstanten zu identifizieren, die eine halbwegs stabile Orientierung über die Zeit bieten. Prozesse, Produkte, IT-Applikationen, Organisationseinheiten – all diese Elemente scheinen ungeeignet, da sie sich zu schnell verändern (müssen) und eher »bewegliches Ziele« denn stabiler Ordnungsrahmen sind.

Capabilities können als stabiler konzeptioneller Ordnungsrahmen mit einem fachlich-funktionalen Fokus eine feste Größe im sonst so raschen Wandel des Unternehmens sein. Gut modelliert, kann ein Capability-Modell ein zentrales Orientierungsmittel sein, mit dessen Hilfe Veränderungen transparent gemacht, geplant und umgesetzt werden können.

1.1.3Digitale Komplexität

Der Begriff »Digitalisierung« gehört zurzeit zweifelsohne zu einem der am häufigsten verwendeten Schlagworte, wenn man über Unternehmensentwicklung spricht. Die Digitalisierung ist allerdings kein neues Phänomen. Schon seit Jahrzehnten erzeugt die technische Entwicklung neue Potenziale, und Unternehmen nutzen diese, um Prozesse zu automatisieren und effizienter zu machen.

Es lassen sich einige wesentliche Faktoren identifizieren, die gerade in den vergangenen Jahren das digitale Potenzial deutlich vergrößert haben:

Miniaturisierung – Die Miniaturisierung erlaubt die Ausstattung von immer mehr »Dingen« mit leistungsfähigen IT-Komponenten (Hard- und Software) und ist die Basis für den Ausbau des »Internet of Things« (IoT) [32]. Selbst Autoschlüssel, Spülmaschinen oder Spielzeuge sind heute internetfähig und verbinden sich mit zentralen Komponenten in der Cloud, um Informationen auszutauschen oder digitale Dienste aufzurufen.

Konnektivität – Die verbesserte Konnektivität ermöglicht die Übertragung von mehr und mehr Daten über weitere Entfernungen in kürzerer Zeit. Insbesondere 5G als neue Übertragungstechnologie verspricht sehr kurze Latenzzeiten, durch die sich anspruchsvolle Echtzeitanforderungen einer vernetzten Welt erfüllen lassen.

Leistungsfähigkeit – Die erhöhten Rechen- und Speicherkapazitäten erlauben eine immer komplexer werdende Verarbeitung und Speicherung von immer mehr Daten in akzeptabler Zeit und zu vertretbaren Kosten.

Die Digitalisierung ermöglicht es also immer besser, Prozesse und Transaktionen auf elektronische Weise statt auf physischer Ebene durchzuführen. Produkte und Dienstleistungen lassen sich im digitalen Raum stärker kombinieren und integrieren. Die Ortsgebundenheit von Produkten und Leistungen nimmt immer stärker ab und verschwindet zum Teil gänzlich.

Mit der stärkeren Digitalisierung und Vernetzung nimmt auch die Komplexität der IT auf Realisierungsseite insgesamt zu. So werden die Architekturen »großflächiger«, da sie mehr und mehr Bestandteile des Geschäftsmodells und der Unternehmen abdecken müssen. Zudem erhöht sich der Grad an Integration der Architekturbestandteile. Gleichzeitig erfordert der Markt differenziertere Produkte, die dennoch für die Anwenderschaft einfach zu handhaben und zu bedienen sind. Zwischen IT und Fachseiten gibt es weiterhin sehr unterschiedliche Perspektiven, doch durch die Digitalisierung und die digitalen Geschäftsmodelle rücken sie immer näher aneinander. Bei der Unternehmensentwicklung ist ein Einklang beider Seiten – das sogenannte Business-IT-Alignment – zu berücksichtigen und herzustellen.

Capabilities fokussieren auf die Geschäftsfähigkeiten im Sinne des »Was«. Sie sind daher zunächst unabhängig von ihrer (technischen oder anderweitigen) Realisierung. Mit einer Zuordnung zu technischen Architekturbestandteilen einerseits (Technologien usw.) und fachlich geprägten Architekturelementen andererseits (Produkte usw.) eignen sich Capabilities ideal als Brücke zwischen Geschäftsmodell/Fachlichkeit und IT.

1.1.4Methodik

Im besten Fall findet die Unternehmensentwicklung im Einklang mit der Unternehmensstrategie statt. Neben der Umsetzung strategischer Ziele gibt es, wie in Abschnitt 1.1.2 dargelegt, eine Reihe von Auslösern für Aktivitäten der Unternehmensentwicklung. Maßnahmen können von punktuellen Aufgaben in der Linienorganisation über kleinere und mittelgroße Projekte bis hin zu großen Transformationsprogrammen reichen. Abschnitt 1.1.1 hat als Gemeinsamkeit aller dieser Vorhaben aufgezeigt, dass man sie beschreiben muss, um sie einordnen, planen, umsetzen und steuern zu können.

In den vorangegangenen Abschnitten war an einigen Stellen die Rede von benötigten fachlich-funktionalen »Ordnungsrahmen« zur Beschreibung der relevanten Unternehmenselemente, um Transparenz zu gewinnen und Betrachtungskontexte nach fachlichen Gesichtspunkten zu strukturieren. Der Duden definiert den Begriff »Ordnungsrahmen« recht allgemein als »für einen bestimmten Bereich vorgegebene, festgelegte Strukturen und Regeln« [20]. In Wikipedia heißt es: »Ein Ordnungsrahmen strukturiert ein System, indem es seine einzelnen Elemente umfasst und anhand ihrer Beziehungen zueinander anordnet« [97].

Oftmals fehlt es in Unternehmen an passenden und einheitlich genutzten Ordnungsrahmen mit fachlich-funktionaler Orientierung. Für einen solchen Ordnungsrahmen lassen sich folgende Anforderungen definieren:

Flexible Einsetzbarkeit – Die Einsetzbarkeit darf sich nicht auf einige wenige, spezielle Anwendungsfälle beschränken. Je höher die Wiederverwendbarkeit ist, umso nützlicher ist der Ordnungsrahmen und umso eher etabliert er sich in der Organisation. Die Anwendungsfälle müssen insbesondere zur Unterstützung von Entscheidungs- und Steuerungsaufgaben geeignet sein. Der Einsatz muss in verschiedenen kleineren und großen Vorhaben und Betrachtungskontexten möglich sein.

Hohe allgemeine Verständlichkeit – Der Ordnungsrahmen muss für alle Beteiligten möglichst leicht verständlich sein. Idealerweise hat er eine Brückenfunktion zwischen Fachlichkeit und IT.

Zeitliche Stabilität – Es ist eine hohe zeitliche Stabilität erforderlich, um als fester Ankerpunkt gegenüber den vielen veränderlichen Größen im Unternehmen dienen zu können.

Angemessener Definitions-/Pflegeaufwand – Der Ordnungsrahmen sollte mit überschaubarem Aufwand zu modellieren sein. Konkret heißt das, dass in Vorhaben der Zeitanteil zur Erstellung des Ordnungsrahmens angemessen und vertretbar sein muss. Die Erstellung ausführlicher Unternehmensmodelle sprengt üblicherweise den Rahmen dessen, was in Vorhaben möglich und realistisch ist.

Capabilities erfüllen alle diese Anforderungen, wie Kapitel 2 ausführlich zeigen wird.

Fachlich-funktionale Ordnungsrahmen können Teil von vollständigen Rahmenwerken (»Frameworks«) sein, wie etwa im Kompendium für Enterprise Architecture Frameworks von Dirk Matthes dargestellt [55]. Typischerweise ist eine ganze Reihe abhängiger Bausteine wie Metamodelle, Ebenen-/Schichtenmodelle, Methoden, bewährte Praktiken, Reifegradmodelle, Techniken, Werkzeuge usw. Bestandteil solcher Rahmenwerke. Ihr Einsatz bringt daher nicht selten eine beachtliche Grundkomplexität mit sich. Oftmals schaffen es solche Rahmenwerke im Unternehmen nicht weit über einige zentrale Abteilungen (wie z.B. die Architekturabteilung) hinaus, da sie schlicht zu komplex, zu umfangreich und auch nicht flexibel genug einsetzbar sind. Als Beispiel sei »The Open Group Architecture Framework« (TOGAF) genannt, das eine Fülle sehr guter Ansätze und die jahrelange Erfahrung vieler kompetenter Beitragender enthält, dessen Umfang und Komplexität in Summe jedoch nahezu erschlagend ist [88]. (Eine nähere Betrachtung von TOGAF ist Gegenstand von Anhang B.2.) Gerade für kleinere und mittelgroße Vorhaben sind solche Rahmenwerke daher in aller Regel zu komplex und aufwendig zu adaptieren. Doch ganz ohne Ordnungsrahmen geht es auch nicht, also statt eines komplexen Rahmenwerks besser einen einfachen Ordnungsrahmen wie das Capability-Konstrukt wählen.

1.1.5Entscheidungs- und Steuerungsfähigkeit

Die zuvor geschilderten Probleme der fehlenden Transparenz und des hohen Veränderungsdrucks bewirken (oder verstärken zumindest) einen weitverbreiteten Mangel an Entscheidungs- und Steuerungsfähigkeit, den man in Unternehmen nicht selten vorfindet. Dieser Mangel betrifft aus der Natur der Sache heraus vor allem die Führungskräfte, die sich oft einem erhöhten Handlungsdruck ausgesetzt sehen.

Aufgabe der Führungskräfte ist es, Veränderungsimpulse schnell in den Unternehmenskontext einzuordnen und daraus Handlungen abzuleiten. Die dazu notwendige Entscheidungsfähigkeit hängt auch von einer möglichst großen Objektivierung der Entscheidungskriterien ab. Hierbei hilft eine gemeinsame Verständnisbasis der Situation und der Handlungsmöglichkeiten. Ziel ist es, (wieder) mehr Freiräume für die Unternehmensentwicklung zu schaffen.

Capabilities können bei der Definition und Bewertung von Entscheidungskriterien helfen. Entscheidungskriterien lassen sich auch direkt an Capabilities knüpfen und können so auch einen Rahmen für die Entscheidungsfindungen bieten. Capability-Modelle sind somit ein geeignetes Werkzeug zur Unterstützung von Entscheidungsfindungen und helfen damit auch bei der Verbesserung der Steuerungsfähigkeit.

1.1.6Agilität

Die zuvor genannten Herausforderungen verlangen von Unternehmen eine höhere Flexibilität in ihrer Entwicklung. Das Unternehmen und seine Teams müssen schnell auf Veränderungen und neue Anforderungen reagieren können. Eine frühzeitige Rückmeldung seiner Kundschaft auf neue Produkte, Dienstleistungen und die Interaktion am Markt sind hilfreich, um schnell und kundenorientiert mit Anpassungen reagieren zu können. Zu langfristige Planungen und zu starre Anforderungs- und Entwicklungsprozesse stehen jedoch oftmals der benötigten Flexibilität im Wege. Diese Erkenntnis ist nicht neu und hat in den letzten Jahrzehnten eine ganze Reihe agiler Methoden als Antwort hervorgebracht, um Unternehmen zu mehr Agilität zu verhelfen [63]. Richtig angewendet, bieten agile Methoden Unternehmen eine gute Lösung, sich von zu starren Planungs- und Veränderungsmustern zu lösen [96, 51].

Wie Abschnitt 4.4 beleuchten wird, vertragen sich Capabilities als konzeptionelles Werkzeug sehr gut mit agilen Ansätzen.

1.2Business Capabilities im Überblick

Bisher wurden einige der Herausforderungen skizziert, vor denen Unternehmen heute bei ihrer Entwicklung stehen. Die hier vorgestellten Capabilities sind ein flexibles und leichtgewichtiges Konstrukt, das als konzeptionelles Werkzeug und fachlich-funktionaler Ordnungsrahmen einen wertvollen Beitrag zur Bewältigung der oben genannten Herausforderungen leisten kann.

Um erfolgreich am Markt agieren zu können, braucht ein Unternehmen bestimmte Fähigkeiten, die mithilfe von Informationstechnologie effizient unterstützt oder sogar erst ermöglicht werden. Diese Fähigkeiten lassen sich durch das Konstrukt der Capabilities auf systematische Weise repräsentieren. Abbildung 1–1 zeigt ein erstes Beispiel eines Capability-Modells mit drei Ebenen.

Abb. 1–1: Beispiel eines Capability-Modells

Das Beispiel umfasst die typischen Fähigkeiten, die ein Unternehmen für das Management von Aufträgen und die Abrechnung gegenüber seinen Kunden benötigt.

Im Kontext von Veränderungsvorhaben der IT-Landschaft ist ein wesentlicher Aspekt die Unterstützung des Geschäfts durch die IT. Der »Leitfaden Enterprise Architecture Management« des bitkom e.V. sieht Capabilities als Bindeglied zwischen dem Geschäftsprozessmanagement, der IT-Architektur und den strategischen Anforderungen eines Unternehmens [80]. Diese Sichtweise passt sehr gut zu der in diesem Buch verwendeten Definition von Capabilities. Abbildung 1–2 zeigt schematisch, wie Capabilities als ein stabiler, fachlich-funktionaler Ordnungsrahmen ein konzeptionelles Fundament im Unternehmen darstellen können.

Abb. 1–2: Capabilities als stabiler Ordnungsrahmen

Viele Elemente der Unternehmensarchitektur ändern sich durch äußere und innere Einflüsse häufig. Verändert sich das Geschäftsmodell nicht, so bleiben hingegen die benötigten Fähigkeiten des Unternehmens – und somit das zugehörige Capability-Modell – stabil.

Passend modelliert und eingesetzt, bieten Capabilities ein ausdrucksstarkes, flexibles Arbeitsmittel zur Umsetzung verschiedener Anwendungsfälle. Diese Anwendungsfälle reichen von Aufgabenstellungen der Enterprise- und Lösungsarchitekten über die von Business-Analysten bis hin zu Projekt- und Programmleitern sowie Führungskräften in Linienorganisationen.

1.3Nutzen von Capability-Modellen

Capabilities sind für Unternehmen und Vorhaben verschiedener Größen geeignet, entfalten ihren Nutzen jedoch gerade bei größeren Vorhaben in besonderer Weise, da sie ein geeignetes Strukturierungsmittel zur Reduktion bzw. Beherrschung von Komplexität sind. Abbildung 1–3 illustriert die flexible Wahl von Ausschnitten eines Gesamtmodells von Capabilities, um eine Fokussierung auf die relevanten Unternehmensteile und die benötigte Abstraktionsstufe des jeweiligen Betrachtungskontexts zu erreichen.

Abb. 1–3: Flexible Wahl von fachlicher Abdeckung und Granularität

Die »horizontale« Ausdehnung bestimmt den fachlichen Abdeckungsgrad, wobei man hier die volle Flexibilität von einzelnen Detail-Capabilities bis hin zum Gesamtunternehmen mit dem vollständigen Capability-Modell nutzen kann. Die »vertikale« Ausdehnung bestimmt den gewünschten Detailgrad, der je nach Bedarf von den Haupt-Capabilities auf oberster Ebene bis hinunter auf die tiefste Detailebene mit einer sehr feinen Granularität reichen kann.

Capabilities sind ein mächtiges und flexibles Arbeitsmittel für verschiedene konzeptionelle und architekturbezogene Aufgabenstellungen, das in vielen Anwendungsfällen sinnvoll zum Einsatz kommen kann [64]. Kapitel 5 beschreibt eine Reihe solcher Anwendungsfälle für Capabilities im Detail.

Capabilities sprechen die Sprache der Fachseiten, da sie für sich genommen weitestgehend von IT-Aspekten befreit sind. Sie sind ideal zur Kommunikation zwischen Fachseiten und der IT-Organisation geeignet; sie schlagen die Brücke zwischen Geschäft und IT, indem sie eine gemeinsame Sprache etablieren.

Die folgende Aufzählung fasst einige der wesentlichen Nutzeneffekte von Capability-Modellen zusammen, ohne näher auf diese einzugehen:

Verständliches Hilfsmittel zur Schaffung von Transparenz über verschiedene Aspekte des Unternehmens

Einfach visualisierbarer Überblick über benötigte Fähigkeiten im Kontext eines Betrachtungsgegenstandes (z.B. eines Projekts, einer Marktproduktstrategie o.Ä.)

Gemeinsame, fachlich einheitliche Sicht auf Vorhaben (z.B. Umfänge, Status usw. im Rahmen des Projektportfoliomanagements)

Übersichtliche Visualisierung von Sachverhalten und Abhängigkeiten mit einem fachlich gehaltvollen Ordnungsrahmen

Stabiler Ordnungsrahmen für fachlich-funktionale Beschreibungen und Dokumentation

Funktional vollständige Checkliste zum Überprüfen bzgl. Vollständigkeit/Abdeckung (fachliche Bebauung, Projektabdeckung u.a.)

Beherrschung von Komplexität durch Capability-basierte Aufteilung des Problems in kleinere Teile (funktionale Dekomposition)

Gemeinsames, einheitliches Verständnis über einen Betrachtungsgegenstand (insbesondere Umfang, Struktur, Semantik und Begrifflichkeiten)

Basis zur einheitlichen Kommunikation zwischen Vorhaben, Anspruchs- und Fachgruppen usw.

Vermeidung von Missverständnissen und von uneinheitlicher Begriffsnutzung

Einfache Vergröberung oder Detaillierung des Betrachtungsgegenstandes durch hierarchische Struktur (»hinein-/herauszoomen«)

Hilfreiches Werkzeug zum Herbeiführen von Managemententscheidungen und Gewinnung von Führungskräften als Sponsoren für Maßnahmen und Vorhaben

Potenzial zur Überwindung von Silos durch Fokus auf Fähigkeiten ohne organisatorische Abgrenzung

Funktional ausgeprägtes Gestaltungselement für die Unternehmens- und Lösungsarchitektur (Entwurf, Bewertung, Migration usw.)

Leicht verständliche Basis für Analysen, Reifegradmessungen und Einschätzungen

Bei allen bisher benannten Vorteilen des Capabilities-Konstrukts muss man allerdings auch festhalten, dass Capabilities kein »Wundermittel« sind, mit dessen Einsatz ein Unternehmen alle Herausforderungen quasi automatisch meistert. Dieses Buch soll helfen, Capabilities möglichst nutzbringend einzusetzen.

1.4Inhalt und Zielgruppen des Buchs

Das Buch besteht aus drei Hauptteilen mit insgesamt acht Kapiteln, die Capabilities an sich und den Umgang mit ihnen ausführlich beschreiben. Der Anhang bietet eine vertiefte Betrachtung von Capabilities im Kontext verschiedener Unternehmenselemente und methodischer Rahmenwerke.

Teil I

legt die Grundlagen zum Verständnis von Capabilities und deren Einordnung in den jeweiligen Unternehmenskontext.

Kapitel 2

bietet eine Definition von Capabilities mit wichtigen Eigenschaften von Capability-Modellen als Basis für die nachfolgenden Kapitel. Es ist daher für jeden Leser der weiteren Kapitel wichtig, um ein grundlegendes Verständnis zu erlangen, wie Capabilities in diesem Buch verstanden werden und welche ihre zentralen Eigenschaften sind. Das Kapitel enthält auch einen Abschnitt zur Abgrenzung der Capability-Definition von ausgewählten anderen Definitionen aus der Literatur.

Den Kontext im Unternehmen, in den sich Capabilities einfügen (müssen), um Nutzen zu entfalten, beschreibt

Kapitel 3

. Dazu werden insbesondere verschiedene Unternehmenselemente betrachtet, die man mit Capabilities auf sinnvolle Weise in Beziehung setzen kann. Beispiele sind Organisationseinheiten, Marktprodukte, Applikationen oder Technologien. Diese Elemente bilden zusammen mit den Capabilities und ihren Beziehungen zueinander ein mächtiges Beschreibungs- und Gestaltungsmittel für Unternehmen.

Capabilities sind als konzeptionelles Werkzeug schon seit geraumer Zeit im Einsatz und Bestandteil verschiedener methodischer Rahmenwerke.

Kapitel 4

gibt einen Überblick über vier prominente Rahmenwerke und nimmt für diese jeweils eine Einordnung der Verwendung von Capabilities sowie einen Abgleich mit der in diesem Buch verwendeten Capability-Definition vor.

Teil II

beschreibt, wofür und wie man Capability-Modelle in der Praxis verwenden kann.

Der eigentliche Nutzen von Capabilities entsteht bei ihrer Verwendung in konkreten Anwendungsfällen, wie sie z.B. in größeren Projekten erforderlich sind.

Kapitel 5

beschreibt eine Reihe solcher Anwendungsfälle, die auf Basis von Capabilities helfen, wichtige Fragestellungen in konkreten Anwendungskontexten wie z.B. Projekten oder Linienaufgaben zu beantworten.

Kapitel 6

präsentiert drei an reale Projekte angelehnte Fallstudien und skizziert die jeweilige Verwendung von Capabilities, um einen Eindruck größerer Anwendungskontexte zu ermöglichen. Die verwendeten Capability-Modelle werden ganz oder in Auszügen beschrieben und ihre Modellierung diskutiert.

Teil III

zeigt, was notwendig ist, um Capabilities als Werkzeug im Unternehmen praktisch einzusetzen.

Um aus dem Einsatz von Capabilities einen Nutzen ziehen zu können, ist das Vorhandensein eines passenden Capability-Modells erforderlich. Wie man Capabilities modellieren kann und was es dabei zu beachten gilt, beschreibt

Kapitel 7

.

Kapitel 8

bietet eine grobe Anleitung, wie man Capabilities zum Einsatz bringen kann. Neben der Prüfung von Voraussetzungen und vorbereitenden Schritten betrachtet dieses Kapitel auch eine Reihe technischer Werkzeuge, die man für die Modellierung und Darstellung von Capabilities nutzen kann.

Der Anhang bietet Vertiefungen und Detaillierungen von Inhalten aus

Teil I

des Buchs, die sich selektiv je nach Bedarf und Interesse lesen lassen.

Anhang A

vertieft die Betrachtung der in

Kapitel 3

eingeführten Unternehmenselemente sowie der dazugehörigen Beziehungstypen, indem es jeden Objekttyp beschreibt, verwandte Begriffe diskutiert und die zugeordneten Beziehungstypen mit Beispielen und möglichen Beziehungsattributen detailliert.

Einige der in

Kapitel 4

skizzierten Rahmenwerke sind Gegenstand einer ausführlicheren Darlegung in

Anhang B

. Dieser Anhang gibt einen tieferen Einblick in das jeweilige Rahmenwerk und betrachtet insbesondere die Frage, wie Capabilities im Kontext des Rahmenwerks zum Einsatz kommen (können).

Empfohlene Kapitel je Zielgruppe.Das Buch richtet sich an verschiedene Zielgruppen, deren Umgang mit Capabilities sich zum Teil deutlich voneinander unterscheidet. Die folgende Aufzählung nennt die wichtigsten Zielgruppen mit typischen Aufgaben, die im Zusammenhang mit Capabilities stehen.

Enterprise-Architekt

Gestaltung der Unternehmensarchitektur auf Capability-Basis

Erstellung/Pflege des Capability-Modells des Unternehmens

Unterstützung bei Definition und Anpassung von Capability-Modellen oder Modellausschnitten für Anwendungskontexte (z.B. Projekte)

Unterstützung bei der Umsetzung von Anwendungsfällen

Lösungsarchitekt

Gestaltung von Lösungsarchitekturen mithilfe von Capability-Modellen

Adaption und Detaillierung des Capability-Modells des Unternehmens für (einzelne oder mehrere) konkrete IT-Lösungen

Umsetzung von Anwendungsfällen für Architekturzwecke

Business-Analyst

Nutzung eines Capability-Modells als Analysebasis in Anwendungskontexten

Umsetzung von Anwendungsfällen für Analyse- und Konzeptionszwecke

Requirements Engineer/Anforderungsingenieur

Nutzung des Capability-Modells des Unternehmens oder des Anwendungskontexts als Basis für die Erfassung, Strukturierung und Pflege von Anforderungen

Unterstützung von Anwendungsfällen für Requirements Engineering/Anforderungsmanagement

Projektleitung

Nutzung (durch andere Projektmitglieder) erstellter Projektartefakte auf Basis von Capabilities zur Unterstützung der Aktivitäten des Projektmanagements

Führungskraft (Ebene 3 oder tiefer) (Management)

Aktive Nutzung von Capabilities als methodisches Hilfsmittel für Führungsaufgaben (z.B. Transparenzschaffung, Planung)

Unterstützung bei der Umsetzung von Anwendungsfällen

Führungskraft, Ebenen 1 + 2 (Senior Management)

Interpretation entscheidungsrelevanter Ergebnistypen, die Capabilities als methodisches Mittel nutzen

Tabelle 1–1 ordnet den Zielgruppen die zur Lektüre empfohlenen Kapitel zu.

Kapitel

Anhänge

Zielgruppe

2

3

4

5

6

7

8

A

B

Enterprise-Architekt

Lösungsarchitekt

Business-Analyst

Requirements Engineer

Projektleitung

Führungskraft (Ebene 3 oder tiefer)

Führungskraft (Ebene 1 und 2)

Tab. 1–1: Empfohlene Kapitel je Zielgruppe

Die Tabelle unterscheidet drei Arten der Empfehlung für die Lektüre, die jeweils mit einem speziellen Symbol in der Tabelle gekennzeichnet sind:

– Die vollständige Lektüre des Kapitels ist für die Zielgruppe empfehlenswert.

– Die Lektüre der Einleitung des Kapitels sowie einzelner Beispiele (z.B. einzelne Anwendungsfälle oder Fallstudien) ist als Ergänzung sinnvoll, um sich mit dem Thema vertiefend vertraut zu machen.

*– Hier ist eine auszugsweise Lektüre des Kapitels empfohlen, die sich nach den Interessen bzw. dem anstehenden Einsatzzweck richten sollte. Es beinhaltet Ausführungen zu speziellen Themen (z.B. zu einem bestimmten Rahmenwerk) und eignet sich zum Nachschlagen. So können beispielsweise gezielt die Beschreibungen einzelner Objekt- und Beziehungstypen oder Anwendungsfälle studiert werden, wenn diese für den Leser (aktuell) eine hohe Relevanz besitzen.

2Definition und Eigenschaften von Business Capabilities

Für Business Capabilities gibt es keine einheitliche Definition in der Literatur [98]. Der englische Begriff steht übersetzt recht allgemein u.a. für »Geschäftsfähigkeit« oder »Geschäftsfertigkeit«. Der Capability-Begriff für sich allein bedeutet »Fähigkeit«, »Fertigkeit« oder »Befähigung«. Auch in anderen Wissenschaften wie der Soziologie oder dem Gesundheitswesen findet der Capability-Begriff Verwendung [1].

Das vorliegende Buch nutzt eine leichtgewichtige Definition von Capabilities, die sich von anderen Ansätzen vor allem bzgl. der integralen Bestandteile von Capabilities unterscheidet. Die hier vorgestellte Variante minimiert die integralen Bestandteile von Capabilities, indem sie sich auf den deklarativen Charakter einer Fähigkeit beschränkt. In diesem Sinne repräsentiert eine Capability immer eine Art Anforderung, zu etwas in der Lage bzw. befähigt zu sein. Ausprägungen im Sinne der konkreten Realisierung von Fähigkeiten mithilfe von Mitarbeiterkompetenzen, organisatorischen Vereinbarungen, Informationstechnologie, Prozessen, Daten, Ressourcen usw. werden hier als etwas Separates und nicht als Teil der Definition von Capabilities betrachtet. Ebenso wenig gehören nicht funktionale Anforderungen oder Eigenschaften (z.B. Leistungsfähigkeit o.Ä.) zu einer leichtgewichtigen Capability. Einige andere Ansätze nutzen »schwergewichtigere« Capability-Definitionen, in denen Realisierungs- und andere Aspekte als integrale Bestandteile mit zu einer Capability gehören [74]. Wesentliche Vorteile einer leichtgewichtigen Definition sind die größere Flexibilität der Nutzung und die geringere Komplexität der Modellierung von Capabilities.

Um deutlich zu machen, was der Anspruch an das in diesem Buch präsentierte Capability-Konstrukt ist und was nicht, enthält Abschnitt 2.4 einige vertiefende Ausführungen zur Abgrenzung.

2.1Grundlegende Definition von Capabilities

Als Grundlage für die weitere Verwendung des Capability-Begriffs in den nachfolgenden Kapiteln dieses Buchs folgt zunächst die spezifische Definition der leichtgewichtigen Capabilities. Der Einfachheit halber verwende ich im Buch unter Auslassung von »leichtgewichtig« sowie dem Kontextpräfix »Business« die kurze Bezeichnung »Capability«.

Definition Capability

Eine Capability steht für eine von einer Unternehmung zur Umsetzung ihres Geschäftsmodells benötigte Fähigkeit, eine Aktivität im Sinne einer Aufgabe auszuführen.

Das Capability-Modell eines Unternehmens umfasst die Gesamtmenge der Capabilities, die der Umsetzung des Geschäftsmodells dienen. Der Fokus einer Capability liegt ausschließlich auf dem funktionalen Kern der Geschäftsfähigkeit, der nur das »Was« beschreibt, aber nicht das »Wie«. Eine Capability definiert also, was ein Unternehmen tut oder fähig sein muss, zu tun, aber nicht, wie (und womit) dies realisiert wird oder werden soll. Eine Capability bezeichnet somit einen funktionalen Baustein im Sinne einer Geschäftsfähigkeit oder Geschäftsfertigkeit, die ein Unternehmen zur Realisierung seines Geschäftsmodells benötigt. Sie abstrahiert mit dieser Definition so weit wie möglich von allem, was nicht den funktionalen Kern betrifft, sodass Aspekte wie z.B. innere Abläufe, die technische Realisierung oder gewünschte nicht funktionale Eigenschaften nicht Teil der Definition sind.

Capabilities werden in der Regel durch Personal, Prozesse und IT unterstützt bzw. realisiert, jedoch gehören diese Entitäten hier nicht zur Definition der Capabilities selbst. Grundlage für diese Definition ist die Annahme der grundsätzlichen Austauschbarkeit der zu einer Realisierung gehörenden Elemente. Eine Fähigkeit kann auf mehreren Wegen und mit unterschiedlichen Mitteln realisiert werden, sodass Capabilities als Beschreibungselemente flexibler einsetzbar werden, sofern ihre Definition von jeglichen Realisierungsaspekten abstrahiert.

Beispiel.Als erstes Beispiel für eine Capability sei die Auftragserfassung betrachtet, die im Sinne einer Geschäftsfähigkeit zunächst nur ausdrückt, dass das betreffende Unternehmen in der Lage sein muss, Aufträge zu erfassen. Die Capability umfasst keine weiteren Eigenschaften oder Aspekte, d.h., sie definiert nicht, auf welche Weise die Auftragserfassung erfolgen soll (z.B. papierbasiert durch Einscannen von Papierbelegen, webbasiert, per mobiler App, telefonisch o.Ä.). Insbesondere sollte die Definition von Capabilities weder die Organisationsstrukturen noch das Geschäftsprozessmodell eines Unternehmens widerspiegeln. Abschnitt 2.4.5 beleuchtet den Zusammenhang zwischen Capabilities und Prozessen. Ebenso wenig sind IT-Applikationen oder deren Module geeignete Capabilities.

Diese leichtgewichtige Definition von Capabilities beschränkt zwar den Umfang einer Capability (bzgl. ihrer inhaltlichen Bestandteile und ihres semantischen Gehalts), jedoch stellt gerade diese Eigenschaft eine ihrer großen Stärken dar: Solange sich das Geschäftsmodell eines Unternehmens nicht ändert, bleibt das Capability-Modell stabil, auch wenn sich andere Eigenschaften des Unternehmens oder nicht funktionale Anforderungen ändern mögen, wie z.B. der Technologieeinsatz, Mengengerüste oder die Ausgestaltung von Geschäftsprozessen. Die Capability ist damit sehr flexibel einsetzbar, denn sie selbst trägt keine festen Eigenschaften mit sich herum, sondern kann je nach Kontext mit unterschiedlichen Eigenschaften, Anforderungen oder Architekturelementen verknüpft werden. Diese Eigenschaft wird in den weiteren Kapiteln detailliert deutlich werden. Kapitel 3 widmet sich den Unternehmenselementen, die explizit keine Bestandteile von Capabilities sind, jedoch je nach Bedarf im Anwendungskontext mit Capabilities in Beziehung gesetzt werden können, um Zusammenhänge und Abhängigkeiten zu beschreiben. Eine weitere Vertiefung der Verknüpfung von Capabilities mit anderen Objekttypen findet sich in Anhang A.

2.2Struktur eines Capability-Modells

Der Aufbau eines Capability-Modells ist hierarchisch. Das bedeutet, eine Capability kann bei Bedarf in mehrere, feingranularere Unter-Capabilities aufgespalten werden, und bis auf das oberste Element hat jede Capability des Capability-Modells genau eine übergeordnete Capability. Formal gesehen handelt es sich bei einem Capability-Modell somit um einen Baum.

Der Wurzelknoten des Gesamtmodells (Ebene 0) repräsentiert das betrachtete (konkrete oder fiktive) Unternehmen als Ganzes. Die Betrachtung von Teilbereichen (= Teilbäumen) ist möglich, sodass das oberste Element des Teilmodells in diesem Fall lediglich den jeweils betrachteten Ausschnitt des Unternehmens repräsentiert. Abbildung 1–3 (S. 12) illustriert die Möglichkeit der flexiblen Auswahl von Teilmodellen. Abbildung 2–1 zeigt ein einfaches Capability-Modell mit zwei Ebenen, wobei die oberste Ebene hier nicht das Gesamtunternehmen repräsentiert, sondern nur den funktionalen Teilbereich des Auftragsmanagements.

Abb. 2–1: Einfaches Capability-Modell für das Auftragsmanagement

2.3 Geforderte Eigenschaften von Capabilities

Die hierarchische Struktur der Capabilities stellt lediglich die wesentliche strukturelle Anforderung an ein Capability-Modell dar. Daneben gibt es noch weitere wichtige Eigenschaften, die Tabelle 2–1 in der Übersicht zeigt. Die nachfolgenden Abschnitte erläutern diese Eigenschaften näher.

Eigenschaft

Kurzbeschreibung

Überschneidungsfreiheit

Capabilities dürfen sich inhaltlich nicht überschneiden.

Vollständigkeit

Alle für den Betrachtungsgegenstand benötigten Geschäftsfähigkeiten müssen abgedeckt sein.

Abgeschlossenheit

Das Capability-Modell darf keine überflüssigen (nicht benötigten) Capabilities umfassen.

Kohärenz

Die Gruppierung von Capabilities zu übergeordneten Capabilities muss nach Gesichtspunkten fachlicher Zusammengehörigkeit erfolgen.

Verständlichkeit

Das Capability-Modell muss für die gewünschten Zielgruppen gut verständlich sein.

Einheitlichkeit

Die Capabilities müssen einheitlich definiert sein (z.B. Schnittkriterien, Benennung).

Akzeptanz

Die direkten und indirekten Nutzer müssen das Modell akzeptieren und als nützlich empfinden.

Stabilität

Das Capability-Modell muss über die Zeit möglichst stabil sein, sofern sich das Geschäftsmodell nicht ändert.

Tab. 2–1: Geforderte Eigenschaften von Capabilities

2.3.1Überschneidungsfreiheit

Die Eigenschaft der Überschneidungsfreiheit stellt sicher, dass benötigte Geschäftsfähigkeiten nur an einer Stelle im Capability-Modell verortet sind. Dies vermeidet Redundanzen und sorgt für Eindeutigkeit bei der Zuordnung von anderen Entitäten des Unternehmens (z.B. Applikationen) zu Capabilities. Besteht beispielsweise die Aufgabe, einer Applikation eine von ihr unterstützte Capability zuzuordnen, dann ist letztere genau an einer Stelle im Capability-Modell zu finden, sodass eine eindeutige Zuordnung möglich ist. Die funktionale Überschneidungsfreiheit ist einer der wesentlichen Unterschiede zu Prozessmodellen. Prozesse können durchaus inhaltliche Überschneidungen haben, wenn z.B. Teilabläufe oder einzelne Schritte in mehreren Prozessen identisch sind. Umfassen verschiedene Capabilities eine gleiche Teilfähigkeit, so darf diese nicht jeder der Capabilities redundant untergeordnet und somit mehrfach in das Modell aufgenommen werden. Stattdessen ist eine solche Teilfähigkeit »herauszufaktorisieren« und an genau einer Stelle im Modell als Capability zu verorten.

Die Überschneidungsfreiheit ist eine der wichtigsten Eigenschaften von Capability-Modellen. Wird die Überschneidungsfreiheit verletzt, so schränkt das den Wert aller auf dem Capability-Modell aufsetzenden Ergebnistypen stark ein, da für die überschneidenden Capabilities eine »Beliebigkeit« entsteht und so die Eindeutigkeit von Capability-Zuordnungen verloren geht.

2.3.2Vollständigkeit

Eine wesentliche und zugleich recht offensichtlich benötigte Eigenschaft ist die Vollständigkeit eines Capability-Modells. Es dürfen keine für den jeweiligen Betrachtungskontext erforderlichen Capabilities im Modell fehlen, denn ansonsten lassen sich die gewünschten Anwendungsfälle nicht vollständig erarbeiten und darstellen. Maßgeblich für die Bestimmung bzw. Überprüfung der Vollständigkeit des Capability-Modells ist der jeweilige Betrachtungskontext. Dies kann das Gesamtunternehmen mit allen insgesamt benötigten Fähigkeiten sein, zu denen neben denen des Kerngeschäfts dann auch Querschnittsfunktionen wie z.B. Personalmanagement und Finanzverwaltung gehören sowie die auf Weiterentwicklung des Unternehmens ausgerichtete Fähigkeiten wie z.B. Strategieentwicklung. Oftmals reicht jedoch ein Ausschnitt des Unternehmens, sodass das zu definierende Capability-Modell im Sinne des Betrachtungskontexts vollständig sein kann, wenn z.B. nur eine Hauptfähigkeit des Unternehmens wie die Produktion abgedeckt ist.

Idealerweise verfügt ein Unternehmen über eine vollständige und detaillierte Capability-Modellierung für den Gesamtumfang der benötigten Fähigkeiten des Unternehmens. Damit der hohe Zeitaufwand einer solchen Detailmodellierung für das Gesamtunternehmen nicht auf einmal anfällt, kann der Entwurf eines Capability-Modells auch in mehreren Iterationen erfolgen. Hier bieten sich aktuelle Vorhaben (z.B. große Projekte) mit Bedarf für Capability-basierte Anwendungsfälle an, in deren Rahmen der jeweils für das Vorhaben relevante Teil des Gesamt-Capability-Modells ausdefiniert werden kann. So kann das Capability-Modell Stück für Stück wachsen, wobei in jedem Schritt die geforderte Vollständigkeit gegeben ist, da der jeweilige Betrachtungskontext vollständig abgedeckt ist.

2.3.3Abgeschlossenheit

Die ersten beiden Eigenschaften Überschneidungsfreiheit und Vollständigkeit bilden zusammen ein Eigenschaftspaar, das oft auch als »MECE« bezeichnet wird. »MECE« steht als Akronym für »mutually exclusive, collectively exhaustive«, also frei übersetzt für »paarweise disjunkt« (= überschneidungsfrei) und »insgesamt erschöpfend« (= vollständig). Was die passende Abdeckung eines Betrachtungskontexts durch ein Capability-Modell betrifft, so gibt es allerdings noch eine weitere notwendige Eigenschaft, nämlich die der Abgeschlossenheit.

Abgeschlossen bedeutet, dass ein Capability-Modell keine Elemente umfasst, die nicht benötigt werden. Ohne diese Eigenschaft könnte ein Capability-Modell auch überflüssige Elemente enthalten, die im schlimmsten Fall sogar unsinnig sein könnten, ohne dass die ersten beiden Eigenschaften der Überschneidungsfreiheit und der Vollständigkeit verletzt würden.

Anmerkung.Das Prinzip MECE für die Definition von Ordnungsrahmen ist in Anbetracht der obigen Ausführungen also selbst eigentlich nicht MECE, da die Eigenschaft der Abgeschlossenheit fehlt und somit die Eigenschaft der Vollständigkeit – der Teil »CE« – nicht erfüllt ist.

2.3.4Kohärenz

Mit Kohärenz in Bezug auf ein Capability-Modell ist gemeint, dass die Modellierung von Capabilities und insbesondere die Zusammenfassung von Capabilities zu übergeordneten Capabilities in der nächsthöheren Ebene des Modells nach fachlich-logischer Zusammengehörigkeit erfolgen muss.

Das Capability-Modell aus Abschnitt 2.2 (siehe Abb. 2–1) ist kohärent, da jeweils alle Unter-Capabilities einer Capability fachlich zusammengehören. Im Gegensatz dazu zeigt Abbildung 2–2 ein Beispiel für ein Capability-Modell mit verletzter Kohärenzeigenschaft.

Abb. 2–2: Beispiel eines inkohärenten Capability-Modells

Folgende Probleme in Bezug auf die Kohärenz bestehen in diesem Beispiel:

Die Capability

Liefertermin prüfen

gehört zwar zum Auftragsmanagement, jedoch in die übergeordnete Capability

Auftragsprüfung

und nicht zur

Auftragserfassung

.

Die Fähigkeit, eine Stanzmaschine zu warten, hat nichts mit Auftragsprüfung und auch im weiteren Sinne nichts mit Auftragsmanagement zu tun, sondern würde z.B. in eine übergeordnete Capability

Produktion

o.Ä. gehören.

Die Capability

Auftragsdaten erfassen

passt zwar zum Auftragsmanagement, müsste jedoch Teil von

Auftragserfassung

statt von

Auftragsdelegation

sein.

Auch die Capability

Vertrieb planen

passt inhaltlich nicht zum Auftragsmanagement und somit auch nicht als Unter-Capability der

Auftragsdelegation

. Hierfür müsste es eine übergeordnete Capability wie

Vertrieb

o.Ä. geben, oder die Capability wird zunächst weggelassen, wenn der Vertrieb nicht zum Betrachtungsgegenstand gehört.

Weitere Aspekte wie Vollständigkeit usw. betrachtet das Beispiel nicht. Auch wenn die Verletzungen der Kohärenz in dem in Abbildung 2–2 angegebenen Beispiel recht offensichtlich sind, so ist die Erkennung von Inkohärenzen nicht immer einfach. Ebenso wenig ist es eine leichte Aufgabe, eine kohärente Modellierung herzustellen. Es gibt im Regelfall viele verschiedene Möglichkeiten, ein kohärentes Capability-Modell für den gleichen Betrachtungsgegenstand zu definieren. Es gibt nicht das eine richtige Modell. Um eine kohärente Modellierung sicherzustellen, sollte in jedem Fall vorab eine Festlegung der Schnittkriterien erfolgen. Schnittkriterien definieren eine Vorgabe, welche Aspekte der fachlichen Zusammengehörigkeit die Modellierung leiten sollen. Zudem helfen Schnittkriterien dabei, die Einheitlichkeit des Capability-Modells als weitere wichtige Eigenschaft von Capability-Modellen zu gewährleisten (siehe Abschnitt 2.3.6). Abschnitt 7.1 vertieft das Thema Schnittkriterien.

2.3.5Verständlichkeit

Ein Capability-Modell, das so gut wie niemand außer dem Modellierungsteam versteht, ist für ein Unternehmen nutzlos. Ein gutes Capability-Modell kann ein zentrales Arbeitsmittel für viele verschiedene Anwendungsfälle in diversen Kontexten sein. Voraussetzung für eine effektive Nutzung ist allerdings, dass alle Beteiligten das Modell verstehen. Das Capability-Modell sollte sich daher an der Begriffswelt des Unternehmens orientieren, sodass die Verwender die enthaltenen Begrifflichkeiten in den Capability-Bezeichnungen eindeutig interpretieren können. Hier ist allerdings auch Vorsicht geboten, denn die Nutzung von Begriffen in Unternehmen in keineswegs immer einheitlich oder eindeutig. Man hat es beispielsweise mit Synonymen zu tun, d.h., eine Abteilung benutzt für dieselbe Entität einen anderen (synonymen) Begriff. Schlimmer noch sind Homonyme, wenn also derselbe Begriff für Unterschiedliches verwendet wird und somit »überladen« ist. Dann können verschiedene Teams trefflich aneinander vorbeireden.

Begriffe sollten in Capability-Modellen immer eindeutig und mit einer klar definierten und abgestimmten Bedeutung verwendet werden. In manchen Fällen kann es hilfreich sein, für eine Capability-Bezeichnung einen neuen Begriff einzuführen, der bisher nicht genutzt wird und somit weder überladen noch vorbelastet sein kann. Die Definition eines Capability-Modells bietet somit auch die Chance, uneinheitliche Begriffe zu vereinheitlichen, um so das gemeinsame Verständnis eines Themas und die Kommunikation im Unternehmen zu verbessern.

Idealerweise ist ein Capability-Modell nahezu selbsterklärend, wenn Struktur, Schnitt und Bezeichnungen im Modell gut gewählt sind. Nichtsdestotrotz sollte immer eine Dokumentation des Capability-Modells erfolgen, d.h., jede Capability erhält mindestens eine kurze, verbale Beschreibung. Oftmals hilft die Erstellung der Dokumentation auch dabei, Lücken oder Ungereimtheiten im Modell aufzudecken. Die klare Beschreibung und Abgrenzung von Capabilities fällt dann u.U. schwer und liefert einen Hinweis, dass etwas noch nicht »rund« ist.

2.3.6Einheitlichkeit

Die Summe der Fähigkeiten, die ein Unternehmen benötigt, hängt einzig von dessen Geschäftsmodell ab. Das bedeutet nicht, dass sich das Capability-Modell automatisch aus Letzterem ergibt, denn es gibt sehr viele verschiedene Möglichkeiten, die Gesamtmenge an Fähigkeiten in Capabilities zu schneiden. Diese Modellierungsfreiheiten betreffen u.a. die gewünschte Granularität, d.h. den zu modellierenden Detailgrad der Fähigkeiten ebenso wie die Gruppierung von Capabilities zu den übergeordneten Capabilities auf der nächsthöheren Modellebene. Damit ein Capability-Modell gut les- und pflegbar ist, sollten bei der Modellierung einheitliche Entwurfs- und Schnittkriterien zum Einsatz kommen. Da die Schnittkriterien bei der Modellierung von so großer Bedeutung sind, widmet sich der Abschnitt 7.1 speziell diesem Thema.

Theoretisch gibt es unzählige Möglichkeiten, ein Capability-Modell uneinheitlich zu gestalten. Der Fantasie sind hier kaum Grenzen gesetzt, doch die meisten davon sind tatsächlich rein theoretischer Natur und daher keiner weiteren Betrachtung wert. (So würde z.B. wohl niemand – außer einem Spaßvogel vielleicht – ernsthaft auf die Idee kommen, jede Capability des Modells in einer anderen Sprache zu benennen.) Nichtsdestotrotz sind in der Praxis immer wieder uneinheitliche Capability-Modelle anzutreffen, und so sollen die folgenden Unterabschnitte einige Eigenschaften näher beleuchten, die für die Einheitlichkeit eines Capability-Modells besonders relevant sind.

Einheitliche Modellierungstiefe

Die Modellierungstiefe ist eine Eigenschaft, die zumindest in vollständigen Capability-Modellen in jedem Ast des jeweiligen Modellbaums einheitlich sein sollte. Diese Eigenschaft bewirkt eine gleichmäßige Detaillierung aller Geschäftsfähigkeiten. Abbildung 2–3 zeigt beispielhaft ein Capability-Modell, bei dem die Modellierungstiefen nicht einheitlich sind, sodass ein unbalancierter Baum von Capabilities entsteht.

Abb. 2–3: Capability-Modell mit uneinheitlicher Modellierungstiefe

Hat ein Capability-Modell keine einheitliche Modellierungstiefe, lässt es sich auch nicht einheitlich handhaben. Benötigt ein Projektteam z.B. für eine detaillierte Analyse die Capabilities auf der Modellebene 3, doch nur einige Capabilities der Ebene 2 haben entsprechende untergeordnete Capabilities auf Ebene 3, so lässt sich die Analyse nicht wie gewünscht durchführen. Für die nicht ausmodellierten Capabilities der Ebene 2 müsste sich das Team für die Analyse mit einer gröberen Granularität begnügen, was zwangsläufig auch zu einer Uneinheitlichkeit der Ergebnisse führen würde.

Anmerkung.Abschnitt 2.3.2 hat die Möglichkeit zur iterativen Entwicklung eines Gesamt-Capability-Modells für ein Unternehmen aufgezeigt. Ein iteratives Vorgehen impliziert jedoch, dass Modellbereiche in ihrer Detailtiefe während der Modellentwicklung nicht einheitlich sind, da einige Bereiche schon stärker (in weitere Ebenen) ausdifferenziert sind, während andere Teile noch einen gröberen Modellierungszustand haben. Ein Capability-Modell muss also nicht unbedingt zu jedem Zeitpunkt ausbalanciert sein. Entscheidend ist, dass die in Anwendungsfällen verwendeten Teile des Capability-Modells jeweils einheitlich sind. Auch hier gilt demnach wieder, dass der jeweilige Betrachtungskontext den Bezugspunkt für die geforderte Eigenschaft des Capability-Modells vorgibt.

Konsistente Namensgebung

Die Forderung nach Einheitlichkeit gilt auch für die Namensgebung der Capabilities. Der Aufbau der Bezeichnungen für Capabilities sollte einheitlich sein, und nach Möglichkeit sollte eine dokumentierte Namenskonvention diesen Aufbau spezifizieren. Empfehlungen zu Namenskonventionen sind in Abschnitt 7.3 zu finden.

Erfahrungsgemäß wird die Eigenschaft der Einheitlichkeit in der Praxis nicht immer berücksichtigt. Gründe dafür sind z.B. fehlende oder nicht dokumentierte Vorgaben, wenn mehrere Modellierer am selben Capability-Modell arbeiten. Unbestätigten Gerüchten zufolge soll es sogar Fälle von mangelnder Disziplin oder gar Ignoranz gegenüber Modellierungskonventionen geben.

2.3.7Akzeptanz

Die Eigenschaft der Akzeptanz ist eigentlich keine Eigenschaft des Capability-Modells an sich, sondern eines des Prozesses seiner Entwicklung und Einführung. Ein noch so gut modelliertes Capability-Modell nützt wenig, wenn die relevanten Interessengruppen und Akteure das Modell nicht akzeptieren. Eine notwendige (allerdings nicht hinreichende) Voraussetzung für die Akzeptanz eines Capability-Modells ist dessen Verständlichkeit, die als wichtige Eigenschaft bereits in Abschnitt 2.3.5 definiert wurde.

Es ist in der Regel wenig hilfreich, wenn eine externe Beratung ein Capability-Modell für ein Unternehmen definiert und dabei die wesentlichen internen Akteure im Entwicklungsprozess nicht ausreichend beteiligt. Die externen Berater mögen aufgrund ihrer jahrelangen Erfahrung vielleicht in kürzester Zeit die Capabilities auf ausgeklügelte Weise und inhaltlich passend modellieren, aber wenn sie dabei die internen Mitarbeiter nicht mitnehmen, dann ist das kaum hilfreich. In der Regel soll nämlich später die interne Belegschaft mit dem Capability-Modell arbeiten und diese muss es dazu sowohl verstehen als auch als konzeptionelles Werkzeug akzeptieren. Zudem braucht es interne Multiplikatoren, die voll hinter dem Capability-Modell stehen und sowohl dessen Sinnhaftigkeit als auch die Inhalte erklären können. Das Capability-Modell als Ordnungsrahmen muss zentral definiert bzw. mindestens über alle betroffenen Organisationseinheiten abgestimmt und kommuniziert werden.

2.3.8Stabilität

Einige Elemente von Unternehmen sind häufigen Änderungen unterworfen. So ändern sich des Öfteren Prozesse und Abläufe z.B. aus Gründen der Effizienzsteigerung, zur Anpassung an neue gesetzliche Vorschriften oder durch die Einführung neuer fachlicher Applikationen. Das Produktportfolio wird an neue Vertriebskanäle und Trends angepasst. Gerade in größeren Unternehmen gibt es auch häufig Restrukturierungen der Aufbauorganisation mit neu geschnittenen Abteilungen und Arbeitsgruppen sowie der damit verbundenen Rochade von Führungskräften und Belegschaft. Während sich einige Elemente häufig ändern, so ist der Anspruch an ein Capability-Modell, dass es möglichst stabil bleibt. Durch die Definition einer Capability als Geschäftsfähigkeit und den Fokus auf das »Was« ist die Stabilität möglich, solange sich das Geschäftsmodell des Unternehmens nicht ändert. Eine solche Änderung impliziert, dass das Unternehmen auch neue oder veränderte Fähigkeiten braucht. Wenn beispielsweise ein Hersteller von Möbeln in Zukunft auch Transport- und Aufbaudienste für seine Möbel anbieten möchte, so ist dies eine Änderung des Geschäftsmodells mit Bedarf an neuen Fähigkeiten. Für das Beispiel muss das Unternehmen u.a. die Fähigkeiten für Transport und Aufbau sowie für Vertrieb, Organisation und Abrechnung dieser Dienstleistungen in das Capability-Modell aufnehmen.

Durch die Stabilität des Capability-Modells lässt sich ein nachhaltiger Effizienzgewinn bei der methodischen Unterstützung der Unternehmensentwicklung erreichen: Ist das Capability-Modell im Unternehmen etabliert, so dient es in Vorhaben als wohlbekannter, konzeptioneller Ordnungsrahmen, der nicht immer wieder neu erfunden werden muss. Erstellte Sichten bleiben zumindest in der Dimension der Capabilities konstant und brauchen nur in Bezug auf die veränderlichen Elemente angepasst zu werden. Das Capability-Modell unterstützt als zeitlich stabile Größe Konzeption, Analyse, Planung und andere Aktivitäten.

Die geforderte Stabilität des Capability-Modells verträgt sich bei der Modellierung der Capabilities nicht mit der Nutzung von sich häufig ändernden Elementen des Unternehmens als Modellierungs- bzw. Schnittkriterien. So sollten beispielsweise keine konkreten Produktausprägungen, Applikationsnamen, Technologien, Prozesse oder Organisationseinheiten als Basis für die Modellierung dienen. Kapitel 7 befasst sich ausführlich mit der Modellierung von Capabilities und der Wahl von Schnittkriterien.

Beispiel.Hat ein Telekommunikationsunternehmen einen besonderen Tarif »Familienspezial« für Familien im Angebot, so könnte die Idee aufkommen, für die Abrechnung eine Capability Familienspezialtarifabrechnung zu modellieren. Diese Capability wäre jedoch hinfällig, sobald das Unternehmen den Tarif durch einen anderen ersetzt oder diesen auch nur umbenennen würde. Die Stabilitätseigenschaft fordert nicht, dass ein Capability-Modell in Stein gemeißelt sein muss. Evolutionäre Verbesserungen, insbesondere auf Detailebene, sind grundsätzlich sinnvoll.

2.4Abgrenzung des Capability-Konstrukts

Dieses Buch definiert ein leichtgewichtiges Capability-Konstrukt, das so weit wie möglich von allen Realisierungsaspekten und anderen Eigenschaften abstrahiert, die nur die realisierten Ausprägungen der repräsentierten Fähigkeiten betreffen. Um die Erwartungen der Leserschaft an Inhalt und Zweck dieses Buchs zu schärfen, fasst die folgende Aufzählung wichtige Abgrenzungen zusammen. Die nachfolgenden Abschnitte erläutern die einzelnen Abgrenzungsthemen näher, siehe Verweise in Klammern.

Das Buch definiert kein eigenes Rahmenwerk (siehe

Abschnitt 2.4.1

).

Es hat nicht den Anspruch, eine durchgängige Gesamtmethode zu spezifizieren (siehe

Abschnitt 2.4.2

).

Der Zweck des definierten Capability-Konstrukts ist nicht die umfängliche Unternehmensmodellierung (siehe

Abschnitt 2.4.3

).

Das Capability-Konstrukt ist leichtgewichtig (siehe

Abschnitt 2.4.4

).

Capabilities beschreiben keine Abläufe und sind insofern nicht als Geschäftsprozesse anzusehen (siehe

Abschnitt 2.4.5

).

2.4.1Abgrenzung zu Rahmenwerken

Ein Rahmenwerk kombiniert Prinzipien, Techniken, erprobte Vorgehensweisen und methodische Ansätze, die sich auf eine bestimmte Menge von Basiselementen beziehen, die oftmals in Form eines Metamodells spezifiziert sind. Entscheidend für ein Rahmenwerk ist, dass all diese Elemente einem durch das Rahmenwerk festgelegten, übergeordneten Zweck dienen. Ein Rahmenwerk definiert somit nicht nur die vorgenannten Elemente für sich, sondern kombiniert sie in einer Weise, die auch das Zusammenspiel der Elemente definiert und dem angestrebten Zweck dienlich ist. Das Rahmenwerk BIZBOK ist beispielsweise ein Rahmenwerk für Geschäftsarchitektur, das dazu dient, Unternehmen für jeden Schritt der Gestaltung der Geschäftsarchitektur eine nützliche Unterstützung zu bieten [7]. Mit diesem Verständnis definiert dieses Buch kein Rahmenwerk. Zwar ist die Unterstützung der Unternehmens- und IT-Architekturgestaltung ein übergreifender Zweck, dem die Inhalte dieses Buchs dienen, doch für ein ganzes Rahmenwerk zu diesem Thema wäre weitaus mehr erforderlich, als »nur« ein Capability-Konstrukt und seine Verwendung zu beschreiben.

Der hier vorgestellte Ansatz beschreibt also eine leichtgewichtige Form von Business Capabilities, wie sie in ähnlicher Form in einigen gängigen Rahmenwerken Verwendung finden (können). Das gesamte Kapitel 4 ist der Einordnung des hier vorgestellten Capability-Konstrukts in existierende Rahmenwerke gewidmet. Anhang B vertieft die Betrachtung einiger dieser Rahmenwerke. Das Capability-Konstrukt selbst, die in Kapitel 3 vorgestellten Objekttypen mit ihren Beziehungen zu Capabilities und die illustrierten Anwendungsfälle in Kapitel 5 lassen sich in verschiedenen Anwendungskontexten auch ohne ein Rahmenwerk nutzen. Die hier präsentierten Inhalte sind insofern komplementär zu den einschlägigen Rahmenwerken zu verstehen.

2.4.2Abgrenzung zu Methoden

Eine Methode beschreibt ein systematisches Vorgehen zu einem definierten Zweck. Methoden können sich auf Notationen (wie z.B. die Unified Modeling Language oder ArchiMate stützen, jedoch bildet eine Notation für sich allein genommen noch keine Methode [89, 60]. Ebenso sind bestimmte Darstellungsformen (z.B. matrixförmige Bebauungssichten o.Ä.) noch nicht als Methode zu bezeichnen, auch wenn sie sich – ebenso wie eine Notation – im Rahmen einer Methode nutzen lassen. Zu einer Methode gehört immer die Definition eines systematischen Vorgehens.

Ich beschreibe zwar verschiedene methodische Ansätze, d.h. Anleitungen, wie das Vorgehen bei Definition und Nutzung von Capabilities aussehen kann, jedoch definiere ich keine Beschreibung einer vollständigen Gesamtmethode wie z.B. die »Architecture Development Method« (ADM) von TOGAF [88]. Dieses Buch ist insofern keine eigenständige, umfängliche Methodenbeschreibung, sondern ein methodischer Baukasten zur Nutzung in Transformations- und anderen Vorhaben der Unternehmensentwicklung.

2.4.3Abgrenzung zur Unternehmensmodellierung

Ein Unternehmen lässt sich auf verschiedene Weisen beschreiben. Art und Umfang der Beschreibung hängen davon ab, welchen Blickwinkel man einnehmen möchte und welche Aspekte relevant sind. Ein mit der Architekturentwicklung der IT-Landschaft betrauter IT-Architekt wird ein Unternehmen ganz anders beschreiben als ein Gärtner, der für die Pflege der Büropflanzen und der Grünflächen auf dem Betriebsgelände zuständig ist. Die Disziplin der Unternehmensmodellierung wird schon seit Jahrzehnten beforscht und praktiziert [95, 75]. Ein Unternehmensmodell beschreibt ein Unternehmen aus verschiedenen Perspektiven mit ausgewählten Aspekten, um Zusammenhänge und Abhängigkeiten aufzuzeigen. Ziel ist es, auf Basis der gewonnenen Transparenz die Integration von Organisationseinheiten und Prozessen innerhalb des Unternehmens zu verbessern sowie die IT-Landschaft mit ihren Datenflüssen zu optimieren.

Das hier definierte Capability-Konstrukt dient in erster Linie dazu, die Fähigkeiten zu benennen, die ein Unternehmen zur Umsetzung seines Geschäftsmodells braucht. Diese Fähigkeiten sind zwar ein sinnvoller Teil einer Unternehmensbeschreibung, jedoch nicht geeignet, ein Unternehmen in Gänze zu beschreiben. Insofern erhebt das hier vorgestellte Capability-Konstrukt nicht den Anspruch, ein Unternehmen vollumfänglich modellieren zu können. Dennoch können Capabilities in ihrer hier verwendeten Definition als wesentliches Konstrukt in die Unternehmensmodellierung eingebettet werden. Dies ist insbesondere im Zusammenspiel mit den weiteren Unternehmenselementen denkbar, die Kapitel 3 beleuchtet.

2.4.4Abgrenzung zu schwergewichtigen Capability-Ansätzen

Der hier verwendete Ansatz definiert Capabilities als reine Fähigkeiten konzeptioneller Natur. Capabilities beschreiben insofern keine umfänglichen Fertigkeiten im Sinne konkreter Realisierungen, sondern sind davon losgelöst. Andere Ansätze haben deutlich reichere, gehaltvollere und implizit auch komplexere Definitionen von Capabilities. So zählen in einigen Ansätzen beispielsweise auch Elemente wie Ressourcen, ausführende Rollen oder benötigtes Wissen zu den integralen Bestandteilen von Capabilities. Die genannten Elemente stellen wichtige Aspekte für die Realisierung der Capabilities dar, und insofern ist ihre Betrachtung wertvoll. Das vorliegende Buch abstrahiert bei den Capabilities weitestgehend von Realisierungs- und anderen anreichernden Aspekten einer Fähigkeit: Eine Capability repräsentiert in diesem leichtgewichtigen Ansatz eine reine »Fähigkeit« an sich, d.h. beschränkt sich auf das »Was« und abstrahiert somit vom »Wie«. Eine Capability besteht daher im Gegensatz anderen Ansätzen nicht aus mehreren Komponenten [74]. Auch wenn die Definition von Capabilities damit semantisch »ärmer« ist, reicht die Beschränkung auf die Repräsentation einer Fähigkeit für die Definition eines konzeptionellen Ordnungsrahmens meiner Erfahrung nach vollkommen aus.

Eine Capability trägt also für sich genommen keinen »Ballast« mit sich herum, sondern lässt sich nach Bedarf des jeweiligen Kontexts und Anwendungsfalls durch semantisch reichhaltige Zuordnungen um weitere benötigte Elemente oder Aspekte anreichern. Diese bedarfsweise Anreicherung führt zu einer großen Flexibilität des Ansatzes, da die Anreicherungen nicht fest mit einer Capability verknüpft bzw. nicht Teil ihrer Definition werden. Dem In-den-Kontext-Setzen von Capabilities widmet sich dediziert das Kapitel 3.

2.4.5Abgrenzung zu Geschäftsprozessen