Einführung
Dieses Konzept beschreibt, wie Modellierungstools und -verfahren, die in der Softwareentwicklung und anderen Bereichen
der Entwicklung verwendet werden, für die Geschäftsmodellierung eingesetzt werden. Das Konzept, das hier beschrieben
wird, basiert auf dem Component Business Model (CBM), das von IBM Global Business Services entwickelt und verwendet
wird. Die Frage, wie ein solches Modell zusammen mit traditionelleren Geschäftsmodellen integriert werden kann, hat
allerdings dazu geführt, dass diese Anleitung erstellt wurde.
Dieser Abschnitt basiert überwiegend auf vorhandenen Anleitungen im RUP-Plug-in Geschäftsmodellierung und zeigt damit,
dass zwischen diesen beiden Methoden mehr Ähnlichkeiten als Abweichungen existieren, obwohl die CBM-Modelle häufig für
andere Entscheidungsfindungen verwendet werden als ein RUP-Geschäftsmodell. Sie sollten insbesondere die folgenden
Abschnitte lesen.
-
Konzept: Geschäftsarchitektur beschreibt die architekturellen Sichten, die
normalerweise zur Beschreibung eines Geschäfts verwendet werden, sowie einige der Treiber zur Betrachtung der
Geschäftsarchitektur.
-
Konzept: Große Organisationen modellieren beschreibt die Partitionierung
eines Geschäfts in autonome Einheiten, die über klar definierte Services miteinander kommunizieren.
-
Richtlinie: Geschäftssystem (und Aufgabe:
Geschäftssystemkontext definieren) beschreibt ausführlicher, wie Sie vorgehen müssen, um Geschäftssysteme in
derselben Weise zu verwenden wie CBM-Geschäftskomponenten:
Geschäftssysteme "partitionieren große Geschäftsmodelle in voneinander abhängige Zuständigkeitsbereiche.
Geschäftssysteme kapseln ihre Ressourcen und stellen Services über klar definierte Schnittstellen zu anderen Teilen
des Geschäfts bereit"
Das Component Business Model
Das am häufigsten beschriebene Arbeitsergebnis, das sich bei Verwendung von CBM ergibt, ist die Component Map.
Eine typische CBM Component Map ist unten dargestellt (aus der Webressource "A component-based approach to strategic
change"). Wie Sie sehen können, sind die Geschäftskomponenten in Form eines Rasters angeordnet und nach ihrem
Kompetenzbereich (der manchmal als Funktionsbereich oder Domänenbereich bezeichnet
wird) und ihrer Aktion kategorisiert. Der Wert dieser Map besteht nicht einfach nur darin, dass das Geschäft
als eine Gruppe von Komponenten betrachtet werden kann, sondern darin, dass die Analyse des Geschäfts eine sorgfältige
Erstellung der Gruppe von Komponenten zur Folge hat und ihre Abhängigkeiten und Interaktionen beschreibt. Die folgenden
Erläuterungen basieren auf der Beschreibung von CBM, die auf der zugehörigen IBM Website (in englischer Sprache) zu
finden ist.
Das IBM Component Business Model bietet eine neue Art der Betrachtung Ihres Geschäfts. Es stellt das gesamte
Geschäft in einem einfachen Gerüst dar, das auf einer einzigen Seite Platz hat. Es ist eine Weiterentwicklung der
traditionellen Sichten eines Geschäfts, wie Geschäftseinheit, Geschäftsfunktion, Geschäftsgeografie oder
Geschäftsprozess.
Die Component Business Map zeigt geschäftsfeldübergreifende Aktivitäten ohne geografische Einschränkungen oder
Einschränkungen durch interne Silos oder Geschäftseinheiten. Mit Hilfe der Component Business Map können Sie das
gesamte Unternehmen auf einer einzigen Seite sehen.
Diese Perspektive, die Ihr Unternehmen in einer einzigen Seite zeigt, erlaubt Ihnen eine Sicht auf Ihr
Geschäft, die nicht durch Schranken verbaut ist, durch die möglicherweise wichtige Änderungen verhindert werden.
Sie können sehen, welche Geschäftskomponenten wirklich zu Differenzierung und Wertschöpfung beitragen. Sie können
feststellen, wo Lücken in der Funktionalität sind, die geschlossen werden müssen. Mit Hilfe der Komponentensicht
können Sie Möglichkeiten der Effizienzsteigerung und Kostensenkung im gesamten Unternehmen feststellen.
Identifizieren Sie die Komponenten, bei denen Sie die größten Auswirkungen erzielen können, und beginnen Sie
dort.

Abbildung 1 - Beispiel einer CBM Map
Das Konzept der Geschäftskomponente ist also sehr wichtig und sollte etwas ausführlicher definiert werden, bevor die
Ähnlichkeiten zwischen der CBM- und RUP-Geschäftsmodellierung näher betrachtet wird. Jede Geschäftskomponente gibt
einen Grundbaustein Ihres Geschäfts an und umfasst Folgendes:
-
Mitarbeiter - der organisatorische Aspekt der Komponente,
-
Prozess - die von der Komponente ausgeführten Funktionen und ihre Implementierung,
-
Technologie - die Technologie, die die Komponente unterstützt und die die von ihr bereitgestellten
Services implementiert.
Außerdem stellt die Geschäftskomponente ein oder mehrere Services für das Geschäft bereit (und ist von diesen
abhängig). Diese Services werden von den Mitarbeitern, dem Prozess und der Technologie innerhalb einer
Geschäftskomponente unterstützt.
Modellierungsprozess
Während die Component Map unter den von CBM produzierten Artefakten dasjenige ist, das am meisten sichtbar ist (auf
alle Fälle im publizierten Material), umfasst das Modell weitaus mehr als nur dieses Bild. Beispielsweise werden
"Unternehmensprozesse" als Prozesse beschrieben, die zum Geschäft gehören und in der Regel im Kundenkontakt sind. Diese
Prozesse werden als eine Choreografie der von den Geschäftskomponenten bereitgestellten Services implementiert.
Allerdings enthält eine Geschäftskomponente auch selbst Prozesse, bei denen es sich entweder um Prozesse zur
Implementierung der bereitgestellten Services handelt, oder potenziell um eigene Managementprozesse. Dies wird auch in
Richtlinie: Geschäftssystem erläutert, wobei die Analogie von Geschäftssystemen und
Geschäftsanwendungsfällen verwendet wird.
Die RUP-Geschäftsmodellierung verwenden
Zu Beginn wird in der Tabelle unten eine Zuordnung zwischen den Konzepten des oben eingeführten CBM und den
Arbeitsergebnissen in der aktuellen RUP-Geschäftsmodellierung vorgenommen.
* - Dieses Element ist im aktuellen UML-Profil für die Geschäftsmodellierung nicht vorhanden (siehe Whitepaper: Rational UML Profile for Business Modeling).
Die folgende Abbildung zeigt, wie diese Zuordnung in UML (mit Hilfe von Rational Software Modeler) mittels der in der
Tabelle oben aufgelisteten Profilelemente realisiert werden kann. Beachten Sie, dass die Geschäftskompetenzen die
Geschäftssysteme enthalten. Dadurch wird sichergestellt, dass die Komponente nicht in mehreren Kompetenzen erscheinen
kann. In Bezug auf die Aktionen (die Zeilen in der oben aufgeführten CBM Map) wurden keine speziellen
Organisationselemente im Modell unten aufgenommen. Es erscheint jedoch vernünftig, ein Merkmal zum Geschäftssystem
hinzuzufügen, um diese Informationen zu erfassen.

Abbildung 2 - Beispiel einer UML-Map für Geschäftskomponenten
Nachdem eine Gruppe von Geschäftskomponenten/-systemen identifiziert wurde, werden als nächstes die Services definiert,
die von diesen Komponenten bereitgestellt werden (und von denen diese Komponenten abhängig sind). Eine ausführlichere
Beschreibung hierzu finden Sie unter Richtlinie:
Geschäftssystem. In dieser Richtlinie wird die bereitgestellte/erforderliche Funktionalität jedoch als
"Leistungsspektrum" beschrieben. Zusammenfassend lässt sich dies in einem Beispiel darstellen. Die Abbildung unten
zeigt eine Geschäftskomponente/ein Geschäftssystem, das zwei separate Services bereitstellt, die als Schnittstellen
modelliert sind und von der Komponente realisiert werden. Auf diese Weise können nicht nur die Services modelliert
werden, sondern gegebenenfalls auch die Geschäftsfunktionen in jedem Service. Diese Art der Modellierung der
Abhängigkeiten zwischen den Services ist eindeutig und erzeugt ein strukturelles Modell, das mit der oben erläuterten
CBM Map beinahe identisch ist.

Abbildung 3 - Beispiel einer UML-Geschäftskomponente mit Services
Modellierungsprozesse
In Bezug auf den Modellierungsprozess in UML beschreibt RUP die Verwendung eines Artefakt: Geschäftsanwendungsfalls zum Erfassen von
Prozessbeschreibungen mit den detaillierten Implementierungsabläufen der Artefakt: Anwendungsfallrealisierung. Bezüglich der in CBM
beschriebenen Trennung von Unternehmensprozessen von Komponentenprozessen sind sehr ähnliche Anleitungen in der Richtlinie: Geschäftssystem zu finden, in der dargelegt wird, dass
Geschäftsanwendungsfälle einerseits Geschäftssysteme überschreiten können und andererseits potenziell einem
Geschäftssystem gehören können.
Links
|