Ein Geschäftsanalysemodell definiert die Realisierung der Geschäftsanwendungsfälle aus der internen Perspektive der
Geschäftssysteme und Mitarbeiter. Das Modell definiert, wie Personen und Systeme, die in dem Geschäft arbeiten, und die
Dinge, die sie bearbeiten und verwenden (Geschäftsentitäten), miteinander in Relation stehen müssen (statisch und
dynamisch), damit die gewünschten Ergebnisse erzielt werden. Es legt den Schwerpunkt auf die Rollen in den
Aufgabengebieten und ihre aktiven Zuständigkeiten. Das Modell zeigt alle Kollaborationen, die erforderlich sind, um die
Geschäftsanwendungsfälle zu realisieren, und alle Klassen, aus denen Objekte instanziert werden, um diese Rollen zu
binden (zu erfüllen).
Die Schlüsselelemente des Geschäftsanalysemodells sind im Folgenden beschrieben:
-
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.
-
Mitarbeiter sind die aktiven Einheiten des Geschäfts. Im Geschäftsanalysemodell
stellen sie eine Abstraktion eines Menschen, einer Software oder sogar eines Systems mit Personen, Hardware und
Software dar (das anders als ein Geschäftssystem nicht weiter in Geschäftsanalyse- oder Geschäftsdesignmodelle
zerlegt wird). Ihre Zuständigkeiten werden im Geschäftsanalysemodell definiert.
-
Geschäftsentitäten stellen Liefergegenstände, Ressourcen und wichtige
Einzelinformationen dar, die verwendet oder erzeugt werden.
-
Geschäftsereignisse stellen wichtige Vorkommen im täglichen Geschäftsbetrieb
dar, die andere Geschäftsprozesse auslösen können.
-
Geschäftsregeln, Deklarationen von Richtlinien oder Bedingungen, die während der
Ausführung der Geschäftsprozesse erfüllt werden müssen.
-
Geschäftsanwendungsfallrealisierungen zeigen, wie Geschäftssysteme, Mitarbeiter,
Geschäftsentitäten und Geschäftsereignisse für die Durchführung eines Geschäftsanwendungsfalls zusammenarbeiten.
Die Geschäftsanwendungsfallrealisierungen werden mit folgenden Elementen dokumentiert:
-
Klassendiagrammen, die beteiligte Geschäftssysteme, Mitarbeiter und
Geschäftsentitäten zeigen,
-
Aktivitätsdiagrammen, in denen Verantwortlichkeitsbereiche die
Zuständigkeiten von Geschäftssystemen oder Mitarbeitern zeigen und Objektflüsse veranschaulichen, wie
Geschäftsentitäten im Workflow verwendet werden.
-
Ablaufdiagrammen, die die Details der Interaktionen zwischen
Geschäftssystemen, Mitarbeitern und Geschäftsakteuren zeigen und veranschaulichen, wie während der Durchführung
eines Geschäftsanwendungsfalls auf Geschäftsentitäten zugegriffen wird.
Das Geschäftsanalysemodell bringt Struktur und Verhalten zusammen. Geschäftsanwendungsfallrealisierungen ordnen die
Prozessbeschreibungen (Geschäftsanwendungsfälle), die das gewünschte Verhalten spezifizieren, den strukturellen
Elementen in der Organisation zu. Schauen Sie sich hierzu die Abbildung an, die der Liste hinter der Liste folgt.
Im Folgenden sind verschiedene Merkmale des Geschäftsanalysemodells beschrieben:
-
Das Geschäftsanalysemodell ist ein Brückenartefakt, das geschäftliche Problemstellungen in einer Weise formuliert,
die Softwareentwicklern vertraut ist, aber trotzdem nur Geschäftsinhalte enthält. Es konsolidiert das, was wir über
den Geschäftsbereich wissen in Form von Objekten, Attributen und Zuständigkeiten.
-
Es untersucht die wesentlichen Kenntnisse im Geschäftsbereich so, dass ein Übergang vom Denken über geschäftliche
Problemstellungen zum Denken über Softwareanwendungen möglich ist.
-
Es ist eine Möglichkeit, Anforderungen zu festigen, die von den zu erstellenden Informationssystemen realisiert
oder unterstützt werden sollen.
-
Die Einigung auf Geschäftsobjektdefinitionen, Beziehungen zwischen Objekten und die Namen für die Objekte und
Beziehungen zwischen Objekten ermöglicht, dass Geschäftsbereichkenntnisse in einer präzisen Form dargestellt werden
können, die von Geschäftsbereichsexperten verstanden wird und geprüft werden kann.
Im Allgemeinen sollten Sie für Geschäftssysteme, Mitarbeiter, Geschäftsentitäten und Geschäftsereignisse kurze,
beschreibende Namen verwenden, die eindeutig sind und nicht mit anderen Namen verwechselt werden können. Manchmal kann
es erforderlich sein, mehrere Wörter zu verwenden, um den Zweck des Modellelements zu beschreiben und sicherzustellen,
dass der Name eindeutig und erkennbar ist, insbesondere in einem weiter gefassten Kontext (was für künftige Pläne von
Bedeutung sein kann).
Ein Geschäftssystem ist eine Sammlung zusammengehöriger Zuständigkeiten mit einem bestimmten Zweck und sollte deshalb
in einer Weise benannt werden, die diesen Zweck widerspiegelt. Es kann verführerisch sein, generische Namen oder
Schlagwörter (z. B. Clientservices) zu verwenden. Stellen Sie auf jeden Fall sicher, dass der Begriff wirklich tauglich
und beschreibend ist. Im Allgemeinen sind substantivierte Verben relativ hilfreich (z. B. Lieferung oder Liefern,
Rechnungsstellung oder Verkauf), da sie auf den Zweck des Geschäftssystems verweisen (z. B. Kundenmanagement oder
Zielakquisition). Weitere Informationen hierzu finden Sie im Artikel Richtlinie:
Geschäftssystem.
Mitarbeiter sollten so benannt werden, dass ihre Zuständigkeiten zum Ausdruck kommen. Beschreiben Sie nicht die
Funktion (im Fall von "menschlichen" Mitarbeitern), sondern die Rolle, die der Mitarbeiter in der
Anwendungsfallrealisierung übernimmt. Diese Rolle spiegelt sich in dem Zweck wider, zu dem der Mitarbeiter an der
Realisierung des Geschäftsanwendungsfalls beteiligt wird. Weitere Informationen finden Sie auf der Seite Richtlinie: Mitarbeiter.
Stellen Sie sich einen Prozess vor, in dem Daten von einem Mitarbeiter in ein System eingegeben und dort gehalten
werden, bis ein zweiter Mitarbeiter die Daten prüft und genehmigt, bevor sie verarbeitet werden (z. B. in
Darlehensanwendungen in einer Bank). Der Mitarbeiter, der die Daten eingibt, können Datentypist oder Sachbearbeiter für
Datenerfassung genannt werden. Mögliche Namen für den zweiten Mitarbeiter sind Prüfer, Berechtigender oder
Freigebender. Der Name "Sachbearbeiter für Datenerfassung" hat den Nachteil, dass er zu "menschlich" klingt, während
die letzten drei Namen zu irgendeinem Zeitpunkt möglicherweise weiter qualifiziert werden müssen (z. B.
Hypothekenberechtigender, wenn die Bank damit beginnt, Versicherungspolicen zu makeln).
Geschäftsentitäten sollten so benannt werden, dass die Informationen, die sie darstellen, klar zum Ausdruck kommen.
Geschäftsentitäten müssen immer im Geschäftsglossar definiert werden, weil es gewöhnlich erhebliche
Meinungsunterschiede in Bezug auf Definitionen und Beziehungen gibt. Nehmen Sie in den Namen von Geschäftsentitäten
keine Zustände oder Eigenschaften auf. Die Namen von Geschäftsentitäten sollten einen Singular und nicht einen Plural
ausdrücken. Weitere Informationen finden Sie auf der Seite Richtlinie:
Geschäftsentität.
Geschäftsereignisse sollten so benannt werden, dass das Vorkommen bzw. die Zustandsänderungen, die das Ereignis
darstellt, zum Ausdruck kommt. Beschreiben Sie im Namen nicht den Auslöser des Ereignisses oder die Reaktion auf das
Ereignis. Die Spezifikation des Ereignisses ist von den Auslösern unabhängig. Weitere Informationen finden Sie auf der
Seite Richtlinie: Geschäftsereignis.
Während Sie die Mitarbeiter und Geschäftsentitäten studieren, die an den unterschiedlichen Anwendungsfällen Ihres
Geschäfts teilnehmen, stellen Sie möglicherweise fest, dass sich einige so ähnlich sind, dass sie im Grund eine Klasse
bilden. Selbst wenn die verschiedenen Geschäftsanwendungsfälle keine identischen Anforderungen haben, können die
Klassen ähnlich genug sein, um als identisches Phänomen eingestuft zu werden. In diesem Fall können Sie die ähnlichen
Klassen zu einer Klasse zusammenführen. Dies ergibt einen Mitarbeiter oder eine Geschäftsentität, die genügend
Beziehungen, Attribute und Operationen hat, um alle Anforderungen der verschiedenen Geschäftsanwendungsfälle zu
erfüllen. Das Diagramm am Ende des Abschnitts "Erläuterung" zeigt, wie Mitarbeiter und Geschäftsentitäten an
unterschiedlichen Geschäftsanwendungsfallrealisierungen beteiligt sind.
Mehrere Geschäftsanwendungsfälle können deshalb recht unterschiedliche Anforderungen an ein und dieselbe Klasse haben.
Wenn Sie mehrere Angestellte haben, die die beschriebenen Rollen übernehmen können, haben Sie flexible Angestellte, die
in mehreren Positionen arbeiten können. Ihr Geschäft wird dadurch flexibler.
Im Geschäftsanalysemodell stellen die Mitarbeiter die Rollen dar, die die aktiven Einheiten des Geschäfts spielen,
während die Geschäftsentitäten die Dinge darstellen, die von den aktiven Einheiten bearbeitet werden. Mit einem
Geschäftsanalysemodell definieren Sie, wie die Mitarbeiter (und auf höherer Ebene die Geschäftssysteme) interagieren
müssen, um die gewünschten Ergebnisse für den Geschäftsakteur zu erzielen. Wir haben zuvor gesagt, dass ein Mitarbeiter
eine Abstraktion eines Softwaresystems darstellen kann. Wenn Sie den Geschäftsmodellierungskontext verlassen,
verwenden Sie ein Systemanwendungsfallmodell und ein Designmodell, um dieses Softwaresystem zu spezifizieren.
Die Geschäftsmodellierung und die Softwaremodellierung sprechen unterschiedliche Problembereiche auf zwei
unterschiedlichen Abstraktionsebenen an. Halten Sie sich an die allgemeine Regel und respektieren Sie diesen
Unterschied. Verhindern Sie, dass Details der Softwaremodellierung in die Geschäftsmodelle eindringen, und
konzentrieren Sie sich auf den Geschäftszweck der Mitarbeiter.
Wenn Sie die Interaktionen und Merkmale von Mitarbeitern im 'AS-IS'-Modell (insbesondere solche Rollen, die von
"menschlichen" Mitarbeitern übernommen werden), das Vorkommen und den Einsatz von Geschäftsereignissen und die für
Geschäftsentitäten ausgeführten Operationen untersuchen, kann eine gewisse Beziehungsheuristik zwischen den
Geschäftsmodellierungs- und Systemmodellierungskontexten bei der Suche nach Automatisierungsmöglichkeiten hilfreich
sein. Verbindungen, Assoziationen und Attribute im Geschäftsmodell können Aufschluss über Automatisierungsmöglichkeiten
geben:
-
Ein Angesteller in der Rolle eines bestimmten Mitarbeiters entspricht einem Systemakteur des Informationssystems.
Er wird wahrscheinlich am besten unterstützt, wenn die Informationssysteme so strukturiert sind, dass seine ganze
Arbeit in einem Geschäftsanwendungsfall von einem Systemanwendungsfall unterstützt wird.
-
Wenn der Geschäftsanwendungsfall umfangreich oder von langer Dauer ist oder Arbeit aus mehreren unabhängigen
Bereichen kombiniert, kann ein Anwendungsfall in einem Informationssystem alternativ eine Operation des
Mitarbeiters unterstützen.
-
Für die Dinge, die Mitarbeiter bearbeiten und die als Geschäftsentitäten modelliert werden, gibt es in
Informationssystemen häufig Darstellungen. Im Objektmodell eines Informationssystems kommen diese
Geschäftsentitäten als Entitätsklassen vor.
-
Geschäftsereignisse werden häufig als Nachrichten in SOA-Softwaresystemen oder als Aufgaben in
Workflowautomationssystemen implementiert.
-
Assoziationen und Aggregationen zwischen Geschäftsentitäten bilden häufig die Basis für entsprechende Assoziationen
und Aggregationen zwischen Entitätsklassen im Designmodell.
-
Deshalb greift ein Anwendungsfall in einem Informationssystem auf Entitätsklassen im Designmodell zu, die die
Geschäftsentitäten darstellen, auf die der unterstützte Geschäftsanwendungsfall zugreift.
-
Ein Geschäftsakteur, der ein Geschäftsinformationssystem direkt verwendet, wird zu einem Systemakteur des
Informationssystems im Systemmodellierungskontext.
Diese Beziehungen sind hilfreich, wenn Anforderungen für die Informationssysteme identifiziert werden, die das Geschäft
unterstützen sollen.
Lesen Sie den Abschnitt über automatisierte Mitarbeiter auf der Seite Richtlinie: Von Geschäftsmodellen zu Systemen.
Manchmal stellen die Angestellten eines Geschäfts über ein Informationssystem Kontakt zu den Angestellten eines anderen
Geschäfts her. Aus der Perspektive des modellierten Geschäfts, ist dieses Informationssystem ein Geschäftsakteur.
Beispiel:
Ein Softwareentwickler versucht, ein Problem in dem Produkt zu verstehen, für das er verantwortlich ist. Um
festzustellen, ob das Problem auf das verwendete Programmiertool zurückzuführen ist, besucht er den WWW-Server des
Anbieters und studiert die Liste der bekannten Probleme im aktuellen Release des Programmiertools. Auf diese Weise
interagiert der Mitarbeiter "Softwareentwickler" mit dem Geschäftsakteur "WWW-Server des Anbieters".
Wenn Sie die Bearbeitung von Geschäftsentitäten durch Mitarbeiter modellieren, ist es offensichtlich, dass viele der
Operationen für die Geschäftsentitäten mit Unterstützung eines Werkzeugs oder Tools, z. B. computerbasiert, ausgeführt
werden. Ob Sie dies explizit als Informations- oder anderes System modellieren (und es damit durch einen Mitarbeiter
darstellen), richtet sich nach der Bedeutung des Geschäfts. Sie würden beispielsweise kein einfaches Desktopsystem mit
Textverarbeitungs- und Spreadsheet-Funktionen als eigenen Mitarbeiter modellieren. Wenn Sie jedoch ein
Informationssystem in einem Geschäft finden, das direkt von Kunden verwendet wird, und diese Interaktion einen
wichtigen Teil der Geschäftsservices darstellt, kann dies wirtschaftlich so wichtig sein, dass Sie es im
Geschäftsanalysemodell zeigen. Services für Telefonbanking sind gute Beispiele für diese Art von Informationssystem.
In diesem Fall gehen Sie wie folgt vor:
-
Betrachten Sie das Informationssystem als vollständig automatisierten Mitarbeiter, der mit einem Akteur
interagiert.
-
Wenn das Informationssystem mit einem der anderen Mitarbeiter oder Geschäftsentitäten in Relation steht, sollten
Sie diese Beziehung durch eine Verbindung oder Assoziation veranschaulichen. Vielleicht informiert das System einen
Mitarbeiter über seinen Fortschritt oder verwendet Informationen, die eine Geschäftsentität betreffen.
-
Beschreiben Sie den Mitarbeiter und die Liste der Services, die das Informationssystem im Geschäftsanalysemodell
darstellen, in kurzen Worten.
-
Modellieren Sie alle Details und Merkmale des Informationssystems und seiner Umgebung in einem untergeordneten
Informationssystemmodell.
-
Führen Sie eine Namenskonvention ein, so dass ein vollständig automatisierter Mitarbeiter innerhalb der Mitarbeiter
leicht zu identifizieren ist. Verwenden Sie beispielsweise ein Präfix oder ein Suffix wie "automatisierter
<Name_des_Mitarbeiters>" oder "System: <Name_des_Mitarbeiters>". Sie können sogar einen Stereotyp mit
einem bestimmten Symbol definieren.
Geschäftssysteme, Mitarbeiter, Geschäftsentitäten und Geschäftsereignisse führen gemeinsam die Aufgaben aus, die in den
Geschäftsanwendungsfällen beschrieben sind, nicht mehr und nicht weniger. Das Geschäftsanalysemodell liefert ein
taugliches und umfassendes Bild der Organisation auf einer entsprechenden Abstraktionsebene.
Übergang zum Geschäftsdesignmodell
Das Geschäftsdesignmodell ist die Weiterentwicklung des Geschäftsanalysemodells mit Optionen (und der zugehörigen
Begründung) für die Realisierung und unter Umständen die Umstrukturierung von Mitarbeitern bei Personen, Software oder
Systemen (die sich wiederum aus Personen, Software und/oder Hardware zusammensetzen). Das Geschäftsdesignmodell zerlegt
diese nicht weiter, d. h. die Aufgabe nachfolgender System- oder Softwareentwicklungsarbeiten.
|