Richtlinie: Geschäftssystem
Geschäftssysteme stellen eine unabhängige Funktionalität in einem Geschäft dar. Diese Richtlinie beschreibt, wie Geschäftssysteme identifiziert und modelliert werden.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

Geschäftssysteme stellen eine unabhängige Funktionalität in einem Geschäft dar. Sie werden verwendet, um die Struktur eines Geschäfts in verwaltbare Blöcke zu unterteilen und zu verstehen. Dies ist mit der Aufteilung einer Organisation in voneinander abhängige Einheiten vergleichbar. Rolle und Zweck der unterschiedlichen Teile einer Organisation sind jedoch für andere Teile der Organisation nicht immer verständlich, was zu suboptimalen Interaktionen bei der Ausführung eines Geschäftsprozesses führt.

Geschäftssysteme führen das Konzept der Partitionierung und Interdependenz einen Schritt weiter. Geschäftssysteme binden und enthalten nicht nur Rollen und Ressourcen (und möglicherweise andere Geschäftssysteme), sondern definieren explizit Schnittstellen oder die Gruppe von Services der Zuständigkeiten, die von ihnen gefordert werden können. Organisationen, die Service-Level-Agreements definieren, um die Interaktionen zwischen Abteilungen und externen Mitarbeitern formal zu spezifizieren und zu verwalten, definieren damit eigentlich Geschäftssysteme. Die Verwendung eines Geschäftssystems geht häufig Hand in Hand mit der Verwendung von Geschäftsmodellen auf verschiedenen Abstraktionsebenen (siehe Konzept: Große Organisationen modellieren).

Der Begriff "Geschäftssystem" darf nicht mit einem Softwaresystem verwechselt werden. Ein Geschäftssystem enthält Personen, Hardware und Software und hat damit eine höhere Abstraktionsebene als ein Softwaresystem.

Geschäftssysteme für die Unterstützung einer dynamischen Struktur

In seinem Buch Enterprise Modeling with UML beschreibt Chris Marshall, dass traditionelle, relativ statische Organisationsstrukturen in der heutigen Geschäftswelt, die immer dezentraler und dynamischer wird, nicht mehr ausreichend sind. Es kann nicht mehr davon ausgegangen werden, dass ein Teil der Organisation über einen längeren Zeitraum hinweg unverändert bleibt. Wie er in seinem Buch schreibt, "Value is created and delivered through value chains that form and disband over time. Indeed, the day when such a chain is formed for a single transaction may not be far away."

Organisationen sind organisch. Je mehr Druck vom Geschäftsumfeld auf sie ausgeübt wird, desto mehr müssen sie sich anpassen, um wettbewerbsfähig zu bleiben. Im Extremfall kann eine statische Organisationsstruktur in einen sehr dynamischen und rücksichtslosen Geschäftsumfeld verkümmern, und Unternehmen müssen sich, um überleben zu können, dynamischen Strukturen zuwenden.

In der traditionellen statischen Organisationsstruktur sind Abteilungsgrenzen rein konzeptionell. Obwohl dies ein Zeichen einer "offenen" und "informellen" Organisation sein kann, ist das Ergebnis, dass jede Person und jedes Segment der Organisation mit dem Rest der Organisation verflochten ist. Es wird extrem schwierig, einen Teil der Organisation vollkommen unabhängig von den anderen Teilen zu ändern oder zu verwalten. Mit Geschäftssystemen werden Partitionen und Grenzen eingerichtet. Interaktionen zwischen den Geschäftssystemen sind nur über die vordefinierten Schnittstellen zulässig. Diese Schnittstellen (möglicherweise formalisierte Service-Level-Agreements) werden zu den Dreh- und Angelpunkten, die die Organisation stützen. Der wichtigste Vorteil dieser Schnittstellen zwischen Geschäftssystemen ist der, dass unterschiedliche Teile der Organisation voneinander entkoppelt sind. Abhängigkeiten werden mit Hilfe von Zuständigkeiten definiert und nicht damit, wie diese Zuständigkeiten erfüllt werden.

Die Trennung der Spezifikation von Zuständigkeiten von der Realisierung der Zuständigkeiten sowie die Bindung von Benutzern des Geschäftssystems an die an seiner Grenze definierten Services anstelle der Bindung an die realisierenden Elemente innerhalb der Geschäftssystemgrenzen führt zu einer flexiblen Organisation, die in der Lage ist, ihre Struktur ohne Beeinträchtigung der Leistung ihrer Prozess schnell anzupassen. In einer solchen Organisation kann eine Funktion (die von einem Geschäftssystem definiert wird) geändert, verbessert oder ausgeliedert werden, während die Auswirkungen auf den Rest der Organisation minimal bleiben. Solange die Servicequalität nach der Änderung unverändert bleibt, können die Geschäftsoperationen störungsfrei fortgesetzt werden. Dieselbe Arbeit könnte ein Softwaresystem, eine Person oder eine gesamte Abteilung vor Ort oder an einem fernen Standort übernehmen.

Die Verwendung von Geschäftsereignissen für die Abstraktion von Interaktionen kann direkte Abhängigkeiten zwischen Geschäftssystemen noch weiter reduzieren. Da Geschäftsereignisse Zeit und Raum transparent machen, können Geschäftssysteme indirekt interagieren (siehe Richtlinie: Geschäftsereignis).

Anmerkung: UML-Modellierungsanweisung für Kapselung

Für die Modellierung eines Geschäftssystems mit UML haben wir bereits in der Beschreibung auf der Seite Arbeitsergebnis: Geschäftssystem auf Folgendes hingewiesen. Wenn die Kapselung nicht wichtig ist, sind die Geschäftssystemgrenzen wie in der zuvor beschriebenen traditionellen statischen Organisationsstruktur theoretisch. Und zumindest für Interaktionszwecke ist das Geschäftssystem während des Geschäftsbetriebs nicht vorhanden. Sie können dies in UML darstellen, indem Sie sagen, dass das Geschäftssystem (eine Art von UML-Komponente) nicht direkt instanzierbar ist. Es entsteht nur durch die Instanzierung seiner Bestandteile. Im nächsten Abschnitt beschreiben wir die Bereitstellung von Services in Geschäftssystemen. In diesem Fall beschäftigen wir uns mit Kapselung und zeigen auf, dass das Geschäftssystem mehr als nur eine theoretische Grenze hat, indem wir es direkt instanzierbar machen. Dabei wird das Geschäftssystem während Analyse und Design mit der Erwartung geprüft, dass die Grenzen im Betrieb in irgendeiner Form real werden.

Geschäftssysteme haben klar definierte Zuständigkeiten

Geschäftssysteme definieren explizit die Zuständigkeiten (auch Services genannt), die von ihnen angefordert werden können. Diese Spezifikation des Verhaltens ist wesentlich, weil sie die Entkopplung von Abhängigkeiten ermöglicht, die bereits im vorherigen Abschnitt erwähnt wurde. Ein Geschäftssystem, das seine Services nicht definiert, hat keine Bedeutung. Ein anderes Geschäftssystem hat abgesehen von der Ableitung aus dem Namen keine andere Möglichkeit, in Erfahrung zu bringen, welche Services das Geschäftssystem bereitstellt. Beispielsweise kann erwartet werden, dass ein Geschäftssystem mit dem Namen "Ressourcen" ("Ressourcenmanagement" in der Welt von Abteilungen) Services für die Anforderung einer Ressource, das Abfragen der Verfügbarkeit von Ressourcen und unter Umständen das Abfragen von Ressourcentypen oder -profilen bereitstellt.

Zuständigkeiten (oder Services) definieren die Mittel für die Interaktion mit dem Geschäftssystem und werden als Operationen der Schnittstellen zu diesem Geschäftssystem angegeben. Diese Schnittstellen sind Sammlungen zusammengehöriger Services und beschreiben als solche die Rolle, die das Geschäftssystem in einer bestimmen Interaktion übernehmen kann. In dem Beispiel, das dem nächsten Absatz folgt, sehen wir, dass jede Schnittstelle eine Sammlung logisch zusammengehöriger Services ist. Diese Schnittstellen (Cluster von Zuständigkeiten) werden dem Geschäftssystem zugeordnet, das für die Erfüllung dieser Zuständigkeiten verantwortlich ist. Wenn einer der bereitgestellten Services von außerhalb des Geschäftssystems angefordert wird, tritt ein Ereignis im Geschäftssystem ein, das die Erfüllung des angeforderten Service einleitet. Dieses für das Geschäftssystem interne Ereignis kann explizit als Geschäftsereignis definiert werden. Die Rollen und Ressourcen (Mitarbeiter und Geschäftsentitäten) im Geschäftssystem kollaborieren (intern) miteinander, um den angeforderten Service zu erbringen. Wir sehen also, dass dies ähnlich funktioniert wie zwischen dem Geschäft und seinen Kunden. Tatsächlich könnten wir das Geschäftssystem sogar als "Geschäft" modellieren. In diesem Fall wären die Anforderer der Services die Geschäftsakteure des Geschäftssystems.

Das folgende Beispiel zeigt die Geschäftssysteme einer generischen Institution für Finanzdienstleistungen. Zur besseren Verständlichkeit werden nur einige Abhängigkeiten zwischen Geschäftssystemen und Schnittstellen gezeigt. Aus diesem Diagramm geht hervor, dass die Zuständigkeiten erneut zugeordnet werden können, indem eine Schnittstelle einem anderen Geschäftssystem zugeordnet wird. Diese Zuweisung von Zuständigkeiten hat konzeptionell keine Auswirkung auf die Geschäftssysteme, die diese Services nutzen.

Diagramm, das Geschäftssysteme für eine generische Institution für Finanzdienstleistungen zeigt

Anmerkung: UML-Modellierungsanweisung für Services

Wir haben bereits erwähnt, dass die Modellierung eines Geschäftssystems als direkt instanzierbare Komponente ein starker Indikator dafür ist, dass die Grenzen des Geschäftssystems nicht nur konzeptionell zu betrachten sind. Wir können dieses Thema fortsetzen, indem wir die Zuständigkeiten der Geschäftssysteme durch eine analoge Anwendung des UML-2.0-Profils für Softwareservices modellieren. Obwohl sich dieses Profil auf Softwareservices bezieht, gelten die grundlegenden Ideen in diesem Profil gleichermaßen für Geschäftssysteme. Durch die Verwendung von UML-2.0-Ports für die Modellierung von Services können die Grenzen des Geschäftssystems weiter geprüft werden, indem eindeutige Interaktionspunkte mit klar definierten Schnittstellen zwischen Benutzern und Geschäftssystemen definiert werden. Diese Interaktionspunkte isolieren die Implementierung der Zuständigkeiten des Geschäftssystems vollständig von ihrer Bereitstellung für Kunden außerhalb des Geschäftssystems. Diese Methode bietet dem Geschäftsprozessanalytiker und anschließend dem Geschäftsdesigner eine Möglichkeit, die Komposition und die Choreografie von Services flexibel zu modellieren (um an den Grenzen des Geschäftssystems Mehrwertdienste bereitzustellen.

Geschäftssysteme enthalten Rollen und Ressourcen

Ein Geschäftssystem ist eine Abstraktion einer Sammlung von Personen, Hardware und Software, die zusammenarbeiten, um die Zuständigkeiten des Geschäftssystems zu erfüllen. Wir verwenden das Wort "Abstraktion", weil wir die internen Kollaborationen im Geschäftssystem nicht mit Personen, Maschinen und Software beschreiben, sondern mit Rollen und Ressourcen. Ein Geschäftssystem enthält Mitarbeiter und Geschäftsentitäten. Ein Mitarbeiter ist gemäß Definition in unserem Glossar eine Rolle, die ein System darstellt. Soweit es die Geschäftsmodellierung betrifft, ist das Geschäftssystem ein 'Blattsystem", d. h. es wird bei der Geschäftsmodellierung nicht weiter zerlegt. Während unserer Geschäftsmodellierungsstudie können wir Folgendes festlegen:

  • Personen können an eine bestimmte Mitarbeiterrolle gebunden werden. In diesem Fall können wir den Stereotyp <<Mitarbeiter>> (Worker) verwenden.
  • Die Rolle wird von Software (und zugehöriger Rechenhardware) ausgefüllt. In diesem Fall können wir den Stereotyp <<IT-System>> verwenden.
  • Die Rolle muss von einem komplexeren System übernommen werden, das selbst Personen-, Hardware- und Softwareressourcen verwenden kann, aber aus irgendeinem Grund nicht als ein Geschäftssystem eingestuft wird. Im folgenden Flughafenbeispiel können wir beispielsweise das Geschäftssystem 'Flüge' so modellieren, dass es Mitarbeiter enthält, die Passagiere transportieren, d. h. Flugzeuge. Flugzeuge sind komplexe eigenständige Systeme, aber ihr Verhalten und Design zu zerlegen, erfordert einen radikalen Paradigmenwechsel weg vom Geschäftsdenken. Deshalb können wir sie in diesem Kontext als Abstraktionen übernehmen (obwohl wir sicherlich daran interessiert sind, einige ihrer Merkmale, z. B. Ladekapazität, Reichweite und Kraftstoffverbrauch anzugeben) und ihnen den Stereotyp <<System>> zuweisen.

Eine Geschäftsentität ist eine Einzelinformation, die von Mitarbeitern erstellte oder bearbeitet wird. Diese Mitarbeiter können letztendlich Personen oder bestimmten Hardware- oder Softwaresystemen zugeordnet werden. Diese Abstraktion hilft uns, den Fokus auf die Rolle und die Schnittstellen des Mitarbeiters zu richten und die erforderlichen Zuständigkeiten zu bestimmen, ohne die (gewöhnlich unvollkommene) echte Situation einer bestimmten Person oder eines bestimmten Systems zu berücksichtigen.

Einige Ressourcen eines Geschäftssystems können virtuell sein. Beispielsweise kann ein Geschäftssystem einen großen Mainframe-Computer mit anderen Geschäftssystemen teilen, aber soweit es die Geschäftssysteme betrifft, haben sie eine eigene virtuelle Maschine. Die Zuordnung virtueller Ressourcen kann auf der Ebene mit der echten Ressource gezeigt werden. In vielen Fällen ist dies die Unternehmensebene (das vollständige Geschäft).

Geschäftsanwendungsfälle gehen quer durch Geschäftssysteme

Geschäftsanwendungsfälle dürfen einem Geschäftssystem nicht einfach zugeordnet werden. Geschäftsanwendungsfälle sind die Prozesse im Kundenkontakt, die eine Kollaboration von Geschäftssystemen, Partnern und Lieferanten erfordern. Dies wird als Wertschöpfungskette bezeichnet. Wie in der folgenden Abbildung gezeigt, kollaborieren Geschäftssysteme, um Geschäftsanwendungsfälle auszuführen.

Diagramm, das die Kollaboration zwischen einem Kunden, einem Partner, einer Regulierungsinstitution und einem Lieferanten zeigt.

Es gibt eine Ausnahme: Wenn Sie Geschäftsmodelle auf mehreren Abstraktionsebenen erstellen (siehe Konzept: Große Organisationen modellieren), können Geschäftsanwendungsfälle einem Geschäftssystem zugeordnet werden. Sie können das Geschäft beispielsweise als Ganzes oder eines der Geschäftssysteme dieses Geschäfts modellieren. In diesem Fall gibt es ein Geschäftsanwendungsfallmodell für das gesamte Geschäft, in dem die Geschäftsanwendungsfälle quer durch die Geschäftssysteme gehen (siehe Abbildung oben). Auf einer niedrigeren Ebene können die von einem bestimmten Geschäftssystem angeforderten Services als Geschäftsanwendungsfälle im Geschäftsanwendungsfallmodell des Geschäftssystems erfasst werden. Die Richtlinie, die beschreibt, dass Geschäftsanwendungsfälle in ihrer Gesamtheit nicht einem Geschäftssystem zugeordnet werden sollten, sollte dann wie folgt lauten: "Ein Geschäftsanwendungsfall auf einer bestimmten Ebene sollte in seiner Gesamtheit nicht nur einem Geschäftssystem auf einer niedrigeren Ebene zugeordnet werden."

Der funktionsübergreifende Charakter von Geschäftsanwendungsfällen ist einer der Gründe für das Interesse an der Geschäftsmodellierung und Umstrukturierung sowie an der Analyse der Kosten und der Leistung von Geschäftsprozessen (siehe Konzept: Aktivitätsbasierte Kostenrechnung). Es ist wertvoller zu verstehen, in welcher Relation die Kosten des gesamten Geschäftsanwendungsfalls zu dem Mehrwert für den Kunden stehen, als zu wissen, in welcher Relation das jährliche Budget einer der Abteilungen zum Gesamtbudget des Unternehmens steht.

Beispiele

Möbelgeschäft

Die folgende Abbildung zeigt die Geschäftssysteme für das Möbelgeschäft, das als Beispiel auf der Seite Richtlinie: Geschäftsziel und auf der Seite Richtlinie: Geschäftsanwendungsfallmodell verwendet wird. Dieses Möbelgeschäft lagert große Bestände in einem Warenlager, das an die Verkaufsräume angrenzt. Die Kunden können sich somit die angebotenen Produkte in den Verkaufsräumen ansehen und gekaufte Produkte direkt im Warenlager abholen. Für große Möbelstücke kann der Kunde eine Lieferung vereinbaren.

Diagramm, das Geschäftssysteme für ein Möbelgeschäft zeigt

Dieses Geschäft ist in drei voneinander abhängige Geschäftssysteme unterteilt. Jedes Geschäftssystem hat einen klaren Zweck und stellt klar definierte Services bereit (die im Diagramm nicht sichtbar sind). Die explizite Definition dieser gegenseitigen Abhängigkeiten und Interaktionen hilft bei der Optimierung des Geschäfts.

Flughafen

Ein Flughafen stellt Services für Fluggesellschaften und Passagiere und Besucher der Fluggesellschaften bereit. Da ein Flughafen ein sehr umfangreiches und komplexes Geschäft ist, macht es für die Modellierung Sinn, es in mehrere unabhängige Geschäftssysteme aufzuteilen. Jedes Geschäftssystem kann dann, wie in der folgenden Abbildung gezeigt, unabhängig als eigenes Geschäft modelliert werden.

Diagramm, das Geschäftssysteme für einen Flughafen zeigt

Im obigen Beispiel sehen wir, dass eine Fluggesellschaft an den Geschäftssystemen Passagiere und Flüge beteiligt ist. Der Luftverkehr wird von der Flugsicherung entsprechend der geltenden Gesetze und Regelungen reguliert. Einrichtungen in Flugzeughallen bieten Services für das Bodenpersonal der Fluggesellschaft an. Die Geschäftssysteme Passagiere und Flüge verwenden für Ankunft und Abflug die vom Geschäftssystem Gepäckabfertigung bereitgestellten Services. Das Geschäftssystem Unterhaltung könnte auch Flughafeneinrichtungen genannt werden und z. B. Läden, Wartebereiche, Parken und Transport enthalten.