Konzept: Dekomposition von Geschäftsprozessen
Die Dekomposition von Geschäftsprozessen ist eine Lösung, die eine Präzisierung der Geschäftsanwendungsfälle erlaubt, um die Darstellung von Geschäftsanwendungsfallrealisierungen in Form von UML-Aktivitätsdiagrammen zu vereinfachen.
Beziehungen
Hauptbeschreibung

Einführung

Ein Geschäftsprozess ist eine Gruppe von logisch zusammengehörigen (und normalerweise sequenziell angeordneten) Aktivitäten, die die Unternehmensressourcen verwenden, um definierte Ergebnisse zur Unterstützung der Unternehmensziele bereitstellen, indem Sie, häufig für einen externen Teilnehmer, z. B. einen Kunden oder Partner, Wertschöpfung in Form eines Produkts oder Services liefern. Der Prozess, der in Unterprozesse untergliedert sein kann, verfügt über zugehörige Unternehmens-, Ressourcen- und Datenmodelle, um alle Aspekte des Prozesses zu erfassen, wozu nicht nur die ausführenden Rollen gehören sondern auch erforderliche/verwendete Ressourcen, Eignerschaft von Ressourcen, Abrechenbarkeit, Definitionen von Elementen, die an die Aufgaben und von den Aufgaben geliefert werden, usw.

Dies ist eine sehr konkrete Sicht eines Prozesses. Daher wird hier die Ansicht vertreten, dass Geschäftsprozesse Realisierungen von Geschäftsanwendungsfällen des begrenzenden Geschäftssystems sind. Daher kann darauf dieselbe Taxonomie angewendet werden wie auf Geschäftsanwendungsfälle (siehe Richtlinie: Geschäftsanwendungsfallmodell):

  • Kern: Hierbei handelt es sich um die nach außen gerichteten Geschäftsprozesse, die die Wertschöpfungskette bereitstellen.
  • Management: Hierbei handelt es sich um die internen Geschäftsanwendungsfälle, die die Wertschöpfungskette koordinieren.
  • Unterstützung: Hierbei handelt es sich um die internen Geschäftsanwendungsfälle, die die Wertschöpfungskette unterstützen.

Prozesse können ereignisgesteuert sein, d. h., sie werden durch Bedingungen ausgelöst (und resultieren in einem Artefakt: Geschäftsereignis), die sich aus der Führung des Geschäfts ergeben.

Prozessebene

In Konzept: Große Organisationen modellieren (ein Auszug ist unten aufgeführt) wird eine Vorgehensweise beschrieben, um den Anforderungen des leitenden Managements sowie der Eigner von Geschäftsprozessen gerecht zu werden. Dazu werden Geschäftsanwendungsfälle auf zwei Detaillierungsebenen definiert:

"Das Modell für die Entscheidungsträger könnte eine Gruppe von Geschäftsanwendungsfällen der hohen Ebene enthalten, die Absicht und Zweck der Organisation veranschaulichen. Das Modell für die Prozesseigner könnte eine Gruppe detaillierter Anwendungsfälle enthalten, die veranschaulichen, wie die Organisation intern funktionieren muss. Für jeden Geschäftsanwendungsfall der hohen Ebene könnten Sie einen oder mehrere detaillierte Anwendungsfälle definieren, die dieselben Aktivitäten in der Organisation darstellen..."

In der Abbildung ist diese Präzisierung von Anwendungsfällen dargestellt.

Darstellung der Präzisierung von Geschäftsanwendungsfällen

Beachten Sie, dass die detaillierteren Anwendungsfälle der unteren Ebene weiterhin Anwendungsfälle desselben Geschäftssystems wie die Anwendungsfälle der hohen Ebene sind, d. h., dass sie nach wie vor eine Blackbox-Sicht des Verhaltens dieses Geschäftssystems darstellen. Für jede dieser Ebenen von Anwendungsfällen existiert eine zugehörige Realisierung, die als Geschäftsprozess beschrieben werden kann. Daher kann diese Art der Analyse als Prozessdekomposition betrachtet werden.

Die Prozessdekomposition analysiert Geschäftsprozesse und Unterprozesse bis zu einer Detaillierungsebene, auf der es praktikabel und hilfreich ist, ein Aktivitätsdiagramm für den Unterprozess zu erstellen. Die Arbeitsvorgabe für die Prozessdekomposition kann von Geschäftsprozessmodellen der Ebene 1 kommen, die möglicherweise nur als Ergänzung geschrieben und den zugehörigen Geschäftsanwendungsfällen der Ebene 1 durch Realisierungsbeziehungen zugeordnet wurden. Ein Prozess der Ebene 1 ist die detaillierte Beschreibung der Aufgabe eines Geschäftssystems und erfüllt auf diese Weise, wie oben erläutert, die Anforderungen des leitenden Managements.

Die Prozessdekomposition resultiert in einer Reihe von dokumentierten Prozessen der Ebene 2, die im Geschäftsanalysemodell als Geschäftsanwendungsfallrealisierungen erfasst werden. Auf der Ebene 2 ist es normalerweise möglich, ein Aktivitätsdiagramm für den Prozess zu erstellen, daher existieren in der Regel drei Ebenen der Dekomposition: Prozess der Ebene 1, Prozess der Ebene 2 und Aktivität (bestehend aus Aktivitätsknoten). Eine Realisierung des Geschäftsanwendungsfalls kann auf mehrere Arten dargestellt werden. In dieser Dokumentation werden Aktivitätsdiagramme vorgestellt (siehe Richtlinie: Diagramme im Geschäftsanalysemodell), weil sie über eine Form und Semantik verfügen, die den meisten Geschäftsanalysten, die an der Modellierung von Geschäftsprozessen interessiert sind, vertraut ist. Solche Modelle sind besonders hilfreich beim Ermitteln von Ineffizienzen in aktuellen Prozessen, mit deren Hilfe Möglichkeiten der Automatisierung und Geschäftsumgestaltung aufgezeigt werden können.

Dekomposition von Geschäftsprozessen in SOMA im Vergleich zur Anwendungsfallpräzisierung

IBM Global Business Services (GBS) Service-Oriented Modeling and Architecture (SOMA) beinhaltet eine Lösung und eine Gruppe von Verfahren für SOA, die als Brücke zwischen Geschäft und IT fungieren.

In den Abbildungen unten werden die Ergebnisse der Prozessdekomposition, die SOMA aufzeigen würde, den entsprechenden Ergebnissen zugeordnet, die die Geschäftsmodellierung mittels der Präzisierung von Geschäftsanwendungsfällen erzielt. Diese Abbildungen werden gezeigt, um darzustellen, dass die beiden Lösungen tatsächlich nur eine unterschiedliche Terminologie und unterschiedliche Darstellungen für dieselben Konzepte verwenden und letztlich dasselbe Ergebnis zeigen - eine Reihe von Geschäftsprozessbeschreibungen, die als Brücke zur Automatisierung verwendet werden können, beispielsweise mittels IT-Systemen und Services in einer SOA-Initiative (Service-Oriented Architecture, siehe SOA).

Darstellung der Prozessdekomposition

Die oben dargestellte Abbildung zeigt die Dekomposition des Prozesses in Unterprozesse und Anwendungsfälle in einer in SOMA verwendeten Notationsform. Der Begriff eines Unterprozesses ist ein praktisches Konstrukt, das verwendet wird, um weitere Ebenen der Präzisierung eines Prozesses rekursiv, durch Aufzeigen seiner Bestandteile (Unterprozesse), anzugeben.

Sobald der Punkt erreicht wird, an dem Interaktionen des Benutzersystems betrachtet werden, wird die Dekomposition gestoppt und der Unterprozess als Unterprozess auf Blattebene bezeichnet. Ein Unterprozess auf Blattebene ist potenziell eine Kombination von Systemanwendungsfällen. Beispielsweise könnte ein Unterprozess auf Blattebene mit dem Namen "Prozessreihenfolge" Anwendungsfälle mit den Namen "Kundennamen abrufen", "Kundenadresse abrufen" und "Bestellartikel abrufen" enthalten.

Die Abbildung unten zeigt die entsprechende Struktur ausgedrückt in der Notation der RUP-Geschäftsmodellierung.

Darstellung der Zuordnung in der Präzisierung von Geschäftsanwendungsfällen

Diese Struktur zeigt dieselben drei Ebenen, wobei die Unterprozesse auf Blattebene durch Aktionsknoten im Aktivitätsdiagramm dargestellt werden.

Beachten Sie, dass das, was SOMA als Anwendungsfälle der untersten Ebene zeigt, nicht Geschäftsanwendungsfälle im Sinne der hier gegebenen Definition sind, sondern dass es sich dabei, ebenso wie bei den zugehörigen Aktivitätsknoten (Aktionsknoten) in den Realisierungen der Geschäftsanwendungsfälle, um den Ort möglicher Interaktion(en) mit IT-Systemen handelt. Die Anwendungsfälle in SOMA sind daher den Anwendungsfällen ähnlicher, die in der in RUP beschriebenen Anwendungsentwicklung entstehen (siehe Richtlinie: Von Geschäftsmodellen zu Systemen).

Bei Verwendung von UML-Aktivitätsdiagrammen zur Modellierung von Geschäftsprozessen ist es möglich, wichtige Mitarbeiter, wichtige geschäftsrelevante Meilensteine und Ereignisse, Abfolgen der Aufgaben und Abhängigkeiten, geänderte und ausgetauschte Geschäftsentitäten und Interaktionen innerhalb und zwischen Unternehmen zu ermitteln. Ein Prozessmodell sollte konkret angeben, "was" stattfinden muss und nicht "wie" Aufgaben ausgeführt werden, da letzteres ein Aspekt von Geschäftsprozessen ist, der sich im Laufe der Zeit, insbesondere infolge von Änderungen in der Geschäftsumgebung oder -technologie, ändern kann.