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