Prozessdarstellungen. Ein Vergleich von UML, EPK und BPMN

Inhaltsverzeichnis

1 Einleitung

2 Erläuterung der Methoden von EPK, UML und BPMN
2.1 Definition und Anwendung von EPK
2.2 Definition und Anwendung von UML
2.2.1 Use-Case-Diagramme
2.2.2 Aktivitätsdiagramme
2.3 Definition und Anwendung von BPMN
2.3.1 Gateways
2.3.2 Ereignisse
2.3.3 Beispiel zur Anwendung und Modellierung mit BPMN

3 Vergleich von EPK, UML und BPMN
3.1 Anwendbarkeit in der Geschäftsprozessmodellierung
3.2 Verbreitungsgrad
3.3 Notationselemente

4 Schlussfolgerung

5 Literaturverzeichnis

Anhang
Anhang A
Anhang B
Anhang C
Anhang D
Anhang E

Abbildungsverzeichnis

Abbildung 1 Darstellung der wichtigsten Symbole einer EPK (eigene Darstellung nach Scheer 2002 und Alexej Kloos 2015)

Abbildung 2 Beispiel eines vereinfachten Prozesses (eigene Darstellung)

Abbildung 3 Bestandteile der UML (nach Rupp und Queins 2012)

Abbildung 4 Beispiel eines Use-Cases (eigene Darstellung)

Abbildung 5 Erweiterung des Use-Case-Diagrammes um Akteur (eigene Darstellung)

Abbildung 6 Use-Case-Diagramm zum Bankalltag (eigene Darstellung)

Abbildung 7 Darstellung einer Kante (eigene Darstellung)

Abbildung 8 Übersicht der Kontrollelemente von Aktivitätsdiagrammen (eigene Darstellung)

Abbildung 9 Darstellung eines Objektknotens (eigene Darstellung)

Abbildung 10 Darstellung einer Aktion (eigene Darstellung)

Abbildung 11 Darstellung des Prozesses zur Bearbeitung eines Kundenauftrages im Unternehmen (eigene Darstellung)

Abbildung 12 Basiselemente der BPMN (vgl. Jakob Freund, Bernd Rücker 2012)

Abbildung 13 Übersicht von Gateways (Wikipedia.org 2015)

Abbildung 14 Start-, Zwischen- und Endereignisse in Blankoform (eigene Darstellung nach Allweyer 2015)

Abbildung 15 Vergleich EPK, UML und BPMN im Jahr 2010

Abbildung 16 Vergleich EPK, UML und BPMN im Jahr 2009

Abbildung 17 Vergleich der Notationselemente aus BPMN, UML und EPK (Christian Pikalek 2011; Klaus Kruczynski 2008)

Abbildung 18 Umfrage zur Nutzung von Modellierungsmethoden (Jakob Freund)

Abbildung 19 Notationselemente BPMN (Allweyer Thomas 2015)

Abbildung 20 Überblick der Ereignisse in BPMN (Allweyer Thomas 2015)

Abbildung 21 Beispiel zur Modellierung mit BPMN (Allweyer Thomas 2008)

Abbildung 22 Überführung EPK in BPMN (Jakob Freund, Bernd Rücker 2012)

Abbildung 23 Überführung UML in BPMN (Jakob Freund, Bernd Rücker 2012)

1 Einleitung

Die fortschreitende Technologie und die damit verbundenen komplexen Zusammenhänge haben eine große Auswirkung auf die Prozessgestaltung und -darstellung. Vor allem im betrieblichen Umfeld wird eine übersichtliche Prozessdarstellung essentiell, um die Profitabilität und somit die Existenz eines Unternehmens gewährleisten zu können. Der damit verbundene Wettbewerbsdruck wirkt sich stark auf die Gestaltung von Unternehmens- und Geschäftsprozesse aus. Das Prinzip eines Lean Processes und der voranschreitende Gedanke des Lean Managements gewannen immer mehr an Bedeutung, um die Sicherheit der Zukunft eines Unternehmens nicht zu gefährden. Vor allem interne, aber auch externe Abläufe mussten drastisch verbessert und effizienter gestaltet werden. Somit erlangte eine übersichtliche und effiziente Darstellung solcher Prozesse große Bedeutung. Daher sind Methoden und Modelle wichtig, die vor allem bei der Softwareentwicklung unterstützen und auch zunehmend komplexe Prozesse abbilden können.

Die Arbeit soll eine Auswahl an Methoden und Modellen aufzeigen und erläutern. In diesem Zusammenhang werden drei Unterschiedliche Ansätze beschrieben. Als erstes wird die Notation Anwendung einer ereignisgesteuerten Prozesskette (kurz EPK) beschrieben. Der zweite Teil handelt von der Modellierung mit Hilfe der Unified Modelling Language (kurz UML). In diesem Abschnitt wird speziell auf Use-Case-Diagramme und Aktivitätsdiagramme eingegangen. Des Weiteren wird im dritten Teil der Arbeit Business Process Management Notation (kurz BPMN) näher betrachtet. Darüber hinaus soll in einer Gegenüberstellung der drei genannten Notationen ein Vergleich bezüglich der Modellierung eines Geschäftsprozesses, des Verbreitungsgrades und der Notationselemente erfolgen. Abschließend wird im letzten Teil ein Ausblick über die Bedeutung solche Methoden und Modelle hinsichtlich der zukünftigen Entwicklung gegeben.

Die Arbeit verfolgt somit das Ziel, die drei genannten Methoden zu unterscheiden und zu vergleichen. Dabei bedient sie sich einer geeigneten Auswahl der Modelle und deren Notationen, die für eine erfolgreiche Prozessdarstellung nötig sind.

2 Erläuterung der Methoden von EPK, UML und BPMN

2.1 Definition und Anwendung von EPK

Die Methode der ereignisgesteuerten Prozesskette wurde erstmals 1992 von Professor August-Wilhelm Scheer der Universität des Saarlandes in Saarbrücken zusammen mit der SAP AG entwickelt (vgl. Scheer 2002). Mit Hilfe der EPK lassen sich Prozesse, die eine geringe Komplexität aufweisen, überschaubar und einfach abbilden.

Die Darstellung eines Ablaufes im Rahmen einer EPK besteht aus einem gerichteten Graphen, der sich entlang des Pfades durch unterschiedliche Situationen aufspaltet und letztendlich am Ende des Prozesses in einen Vorgang oder Ziel zusammengeführt wird. Dabei bedient sich die EPK grundlegenden Syntaxregeln. Prinzipiell beruht diese auf dem Konzept des Ereignisses, der Bedingung und der Funktion (vgl. Knollmayer und Herbst 1993). Prozesse erfordern je nach Komplexität Entscheidungen, die durch die Erfüllung bestimmter Bedingungen unterschiedliche Ergebnisse liefern können. Um solche Abfolgen abbilden zu können, werden in der EPK zusätzlich Operatoren zur Verknüpfung benötigt (vgl. Knollmayer und Herbst 1993). Die nachfolgende Grafik bietet einen Überblick über die wichtigsten Symbole und Operatoren einer ereignisgesteuerten Prozesskette.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Darstellung der wichtigsten Symbole einer EPK (eigene Darstellung nach Scheer 2002 und Alexej Kloos 2015)

Die Darstellung eines Prozesses mit Hilfe einer EPK erfolgt entlang eines gerichteten Graphen ohne eine Schleife. Dabei stehen die Objekte immer in einer 1:1- Beziehung (vgl. Gadatsch 2012). Des Weiteren wechseln sich Ereignis und Funktion stets ab, wobei das Ereignis den jeweiligen Zustand vor oder nach einer Funktion beschreibt. Eine Funktion ist folglich ein Ablauf, eine Aktion oder eine Aufgabe, die ein Ereignis prägen und verändern kann (vgl. Gadatsch 2012).

Nachfolgende Graphik zeigt ein einfaches Beispiel einer EPK anhand eines Prozessablaufes, der sich wie unten erklärt aufbaut:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 Beispiel eines vereinfachten Prozesses (eigene Darstellung)

Die Graphik zeigt den Ablauf eines einfachen Prozesses. Nachdem ein Unternehmen einen Auftragseingang bearbeitet hat, muss es diesen schließlich versenden. Zum Versand stehen die Optionen „Deutsche Post“, „UPS“ und „Spedition“ zur Verfügung. Der Operator „XOR“ beschreibt hierbei, dass genau eine der drei Möglichkeiten getroffen wird. Abschließend stellt das Unternehmen die Leistung in Rechnung.

Die ereignisorientierte Prozesskette findet vor allem Anwendung in der Evaluation und Implementierung von Software, in der Geschäftsprozessmodellierung sowie zu Zwecken von Prozessoptimierungen (vgl. Scheer 2002).

2.2 Definition und Anwendung von UML

Die ersten Ansätze der Unified Modeling Language sind auf die 1990er Jahre zurückzuführen. Die UML entstand in einer Verbindung unterschiedlicher Modellierungsmethoden und entwickelte sich in aufsteigenden Versionen weiter. Durch die unterschiedlichen Stadien der UML entstand letztendlich ein Modell, das in der Praxis eine durchaus hohe Relevanz erlangte (vgl. Amberg 1999).

Die UML unterstützt bei der Darstellung von Systemen und Prozessen. Sie setzt sich aus unterschiedlichen Elementen zusammen, die je nach Anforderung des Systems oder des Prozesses verwendet werden.

Insgesamt besitzt die UML 14 unterschiedliche Typen, die in nachfolgender Graphik aufgelistet sind:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 Bestandteile der UML (nach Rupp und Queins 2012)

Wie die Abbildung zeigt lässt sich die UML in zwei Teilbereiche gliedern. Strukturdiagramme beschreiben statische, nicht veränderbare Modelle. Dabei können sich Daten ändern, jedoch bleiben die Beziehungen zueinander bestehen. Im Gegensatz dazu sind Verhaltensdiagramme von dynamischer Art. Es können sich also Objekte durchaus verändern.

Im weiteren Verlauf der Arbeit werden Use-Case-Diagramme und Aktivitätsdiagramme genauer erläutert. Use-Case-Diagramme werden hauptsächlich verwendet, um Auswirkungen eines Systems oder eines Prozesses auf die direkt betroffene Umwelt herausfinden möchte. Dabei wird die externe Sicht des Systems dargestellt (vgl. Rupp und Queins 2012). Aktivitätsdiagramme hingegen zeigen eine detaillierte Darstellung eines Prozesses. Hier sind auch komplexe Situationen abbildbar.

2.2.1 Use-Case-Diagramme

Unter einem „Use-Case“ versteht man zu Deutsch einen „Anwendungsfall“, bei dem die Funktionalität eines Systems mit Hilfe eines einfachen Modells beschrieben wird. Dabei sind Akteure, die die eigentlichen Nutzer darstellen, die hauptsächlich handlungstreibenden Personen oder Nachbarsysteme (vgl. Rupp und Queins 2012). Ein Use-Case bildet somit einen aus Sicht des Akteurs dargestellten Prozess dar. Ein Akteur kann hierbei unterschiedliche optionale Use-Cases bedienen. Um die Auswirkungen eines Systems auf dessen Umwelt festzustellen, können komplette Use-Case-Diagramme erstellt werden. Dabei sind folgende Objekte Bestandteil eines Use-Case-Diagramms (vgl. Rupp und Queins 2012):

- Assoziationen und Beziehungen
- System und Systemgrenze
- Akteure
- Use-Cases

Der nachfolgende Absatz behandelt nun die zuletzt genannten Notationselemente von Use-Case-Diagrammen. Hinter einem Use-Case steht meist ein kompletter Prozess. Zum Beispiel würde das Use-Case „Geld am Automaten abheben“ den kompletten Prozess vom Einstecken der Karte bis hin zur Entnahme des Geldes abbilden. Dabei sind ebenso Fehler, dass zum Beispiel kein Guthaben vorhanden oder die Karte nicht lesbar ist, inkludiert. Use-Cases werden in Form einer Ellipse dargestellt (vgl. Rupp und Queins 2012):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 Beispiel eines Use-Cases (eigene Darstellung)

Ein Use-Case wird immer von einem zuständigen Akteur gestartet. Im oben genannten Fall steckt dieser seine Karte in den Automaten. Das Use-Case „Geld am Automaten abheben“ erzielt das Ergebnis, dass der Akteur Bargeld erhält. Somit kann das Use-Case-Diagramm wie folgt erweitert werden:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 Erweiterung des Use-Case-Diagrammes um Akteur (eigene Darstellung)

Der Akteur kommuniziert auf externer Ebene mit dem System (vgl. Rupp und Queins 2012). Dabei stellt ein Akteur nicht zwangsläufig immer eine Person dar, sondern kann wie bereits erwähnt ein anderes System verkörpern sowie andere unterschiedliche Gegenstände.

Den Rahmen eines Use-Case-Diagramms bildet das System an sich, welches durch eine Systemgrenze in Form eines Rechteckes gekennzeichnet wird. Innerhalb des Systems laufen die unterschiedlichen Use-Cases ab. Die Use-Cases können auch zueinander in Beziehung stehen. Insgesamt gibt es zwei Arten von Beziehungen (vgl. Rupp und Queins 2012). Zum einen versteht man unter einer sogenannten „Include-Beziehung“, dass ein Use-Case das Verhalten eines anderen Use-Cases zur Folge hat. Somit hat das Use-Case „Geld am Automaten abheben“ zur Folge, dass durch die Eingabe des PIN eine Authentifizierung durchgeführt wird. Zum anderen existiert auch eine „Extend-Beziehung“. Diese Art der Beziehung bezeichnet einen potentiellen, aber nicht zwangsläufigen Zusammenhang zweier Use-Cases. Das heißt, dass ein Use-Case um ein anderes Use-Case erweitert werden kann, aber nicht muss (vgl. Rupp und Queins 2012). Folgende Darstellung zeigt das Use-Case-Diagramm mit einer Auswahl von Use-Cases und Akteuren im Bankalltag:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 Use-Case-Diagramm zum Bankalltag (eigene Darstellung)

Das in Abbildung 6 aufgeführte Use-Case-Diagramm ist nicht vollständig und könnte um weitere Akteure, Use-Cases und Beziehungen ergänzt werden. Zur Veranschaulichung und Übersichtlichkeit wurde eine Auswahl getroffen.

Use-Case-Diagramme werden hauptsächlich zu Beginn der Entwicklung und Planung von Prozessen, Software oder Ähnlichem verwendet (vgl. Rupp und Queins 2012). Aufgrund der Übersichtlichkeit und Veranschaulichung von potentiellen Auswirkungen der Prozesse auf deren Umwelt lassen sich leichter Vorkehrungen treffen. Somit kann der Planungsprozess erleichtert werden. Ebenso lassen sich komplexe Systeme durch die primitive Struktur einfacher abbilden (Rupp und Queins 2012).

Dieses Kapitel hat nun die Grundlagen eines Use-Case-Diagrammes beschrieben. Allerdings bedarf es nach Erstellen dieser Methode noch einer detaillierten Darstellung der Use-Cases an sich, hinter welchen durchaus komplexe und vollständige Prozesse stehen. Daher stellt die Arbeit im nächsten Schritt eine mögliche Darstellung der Use-Cases vor.

2.2.2 Aktivitätsdiagramme

Bei der Modellierung und Abbildung von Prozessen sind Aktivitätsdiagramme sehr hilfreich. Eine Aktivität ist dabei die „Menge von potentiellen Abläufen, die sich in der Realität unter bestimmten Randbedingungen abspielen“ (Rupp und Queins 2012).

Im Wesentlichen ist ein Aktivitätsgramm flussorientiert und läuft entlang unterschiedlicher Aktionen. Zur Abbildung eines komplexen Prozesses besitzt diese Methode einige ausgewählte Notationselemente (vgl. Rupp und Queins 2012):

- Aktivitäten
- Aktionen
- Objektknoten
- Kontrollelemente zur Prozesssteuerung
- Kanten

Der allgemeine Ablauf wird als Aktivität bezeichnet. Zur Beschreibung einer Aktivität werden unter anderem Aktionen benötigt, die innerhalb des Gesamtablaufs einen eigenen Prozess darstellen. Neben den Aktionen gibt es noch sogenannte Objektknoten. Diese liefern zum Beispiel Input, der für den weiteren Ablauf von Bedeutung ist, oder symbolisieren einen Output. Des Weiteren werden zur Steuerung des Gesamtprozesses Kontrollelemente benötigt. Die Elemente bieten die Möglichkeit bedingte Entscheidungen zu treffen und können die Reihenfolge des weiteren Ablaufes beeinflussen (vgl. Rupp und Queins 2012). Prozesse können somit unter anderem

- parallel und synchron ablaufen,
- aufgeteilt und zusammengeführt werden,
- durch unterschiedliche Bedingungen verschiedene Ergebnisse liefern.

Insgesamt werden alle Notationselemente durch gerichtete Kanten verbunden. Im nächsten Schritt werden nun die genannten Elemente erklärt (vgl. Rupp und Queins 2012).

Kanten sind gerichtete Verbindungselemente zwischen zwei Knoten. Sie werden unterschieden in Kontroll- und Objektflüsse. Bei Kontrollflüssen verbindet eine Kante zwei Aktionsknoten oder einen Aktionsknoten und ein Kontrollelement. Solche Kanten liefern also keinerlei Daten, sondern beschreiben nur die Ablaufrichtung. Im Gegensatz zu den Kontrollflüssen verbinden Objektflüsse Objekteknoten miteinander oder einen Objektknoten mit einer Aktion. Auf diesen Kanten können Daten und Informationen übermittelt werden. Beide Arten werden mit einem einfachen gerichteten Pfeil abgebildet:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7 Darstellung einer Kante (eigene Darstellung)

[...]