Richtlinie: Geschäftsanalysemodell
Ein Geschäftsanalysemodell definiert die Geschäftsanwendungsfälle aus der internen Perspektive der Geschäftssysteme und Mitarbeiter. Diese Richtlinie erläutert, wie ein Geschäftsanalysemodell entwickelt wird.
Beziehungen
Hauptbeschreibung

Erläuterung

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.

Komplexes Diagramm mit einem Beispiel für ein Geschäftsanalysemodell

Namenskonventionen

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.

Geschäftsobjekte und Geschäftsanwendungsfälle

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.

Das Geschäftsanalysemodell und Informationssysteme

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

Informationssysteme als Geschäftsakteure

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".

Informationssysteme explizit im Geschäftsanalysemodell

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.

Merkmale eines tauglichen Geschäftsanalysemodells

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.