Methoden der Geschäftsprozessmodellierung im Vergleich

Aus Winfwiki

Wechseln zu: Navigation, Suche

Fallstudienarbeit

Hochschule: Hochschule für Oekonomie & Management
Standort: Bremen
Studiengang: Bachelor Wirtschaftsinformatik
Veranstaltung: Fallstudie / Wissenschaftliches Arbeiten
Betreuer: Dipl.-Phys. Frank Guderwarning.png„Dipl.-Phys. Frank Guder“ gehört nicht zu den möglichen Werten dieses Attributs (Dipl-Inf._(FH)_Jörg_Muschiol, Dr._Vladimir_Stantchev, Prof._Dr._Ralf_Hötling, Prof._Dr._Uwe_Kern, Dipl-Inf._(FH)_Christian_Schäfer, Prof._Dr._Gregor_Sandhaus).
Typ: Fallstudienarbeit
Themengebiet: Methoden der Geschäftsprozessmodellierung im Vergleich
Autor(en): Dirk Buchholz, Christian Guodys, Sven Tietjen
Studienzeitmodell: Abendstudium
Semesterbezeichnung: SS11
Studiensemester: 2
Bearbeitungsstatus: vergeben
Prüfungstermin: 09.07.2011
Abgabetermin: 09.07.2011


Inhaltsverzeichnis


1 Einleitung

1.1 Thema

In der heutigen wirtschaftlichen Situation herrscht unter den Unternehmen ein enormer Wettbewerbsdruck. Somit ist auch eine zunehmende Bedeutung des Geschäftsprozessmanagements erkennbar. Die Unternehmen versuchen durch Geschäftsprozessoptimierung überflüssige Prozesse zu erkennen und, falls möglich, zu eliminieren. Da heutzutage die meisten Prozesse auf Informations- und Kommunikationssystemen aufbauen, spielt die EDV (elektronische Datenverarbeitung) dabei eine sehr wichtige Rolle. Diese wissenschaftliche Arbeit beschäftigt sich mit einem Vergleich der drei wichtigsten Methoden der Geschäftsprozessmodellierung. Es werden folgende Methoden behandelt: Modellierung mit UML (Unified Modeling Language), EPK (ereignisgesteuerten Prozessketten) und BPMN (Business Process Model and Notation).

1.2 Abgrenzung und Aufbau der Arbeit

In dieser Arbeit werden keine Vorkenntnisse über die Modellierung von Geschäftsprozessen mit EPK, UML oder BPMN vorausgesetzt. Im Laufe der Arbeit werden die verschiedenen Methoden definiert. Diese Arbeit ist in drei Teile gegliedert. Der erste Teil definiert die Schlüsselbegriffe und grenzt diese ab. Der Hauptteil befasst sich mit den bereits zuvor genannten Methoden der Geschäftsprozessmodellierung und deren Vergleich. Abschließend befasst dich die Arbeit mit einem allgemeinen Fazit.

1.3 Zielsetzung der Arbeit

Das Hauptaugenmerk dieser Arbeit liegt in der Einführung der verschiedenen Modellierungsarten und ihren Darstellungsformen für Geschäftsprozesse. Ein weiteres Ziel ist es, einen Vergleich mit ihnen durchzuführen.

1.4 Begriffdefinition

In diesem Abschnitt werden die Begriffe Geschäftsprozess und Geschäftsprozessmodellierung eingeführt.


Geschäftsprozess: Ein Geschäftsprozess ist ein betriebswirtschaftlicher Vorgang, der einen definierten Start und ein definiertes Ende besitzt. Die Aufgaben laufen nacheinander oder parallel ab und werden entweder manuell, teil-automatisiert, oder automatisiert erfüllt. Für die Erfüllung der Tätigkeiten werden die Unternehmensressourcen benötigt. Geschäftsprozesse stellen die Ablauforganisation dar, d.h. sie tangieren unter Umständen mehrere Abteilungen. Sie haben ein oder auch mehrere Ziele, die sich aus den Unternehmenszielen ableiten.[1]


Geschäftsprozessmodellierung: "Die Geschäftsprozessmodellierung als Unterstützungsinstrument des Prozessmanagements umfasst die Konstruktion, Wartung und Anwendung von konzeptionellen Modellen der Geschäftsabläufe von Unternehmen und Verwaltungen. Sie dient der Anwendungssystem- und Organisationsgestaltung aus der Sicht der betrieblichen Abläufe."[2]


Prozeßorientierung und Unternehmensmodellierung werden viel diskutiert und es gibt eine zunehmende Zahl an Werkzeugen, die helfen sollen, die Aufgabe einer prozeßorientierten Unternehmensmodellierung zu bewältigen.[3] Trotz rückläufiger Budgets und einem allgemeinen Trend zur Kostenreduktion investieren deutsche Unternehmen viel Geld in die Optimierung ihrer Arbeitsabläufe und Aufbauorganisation.[4] Die Tatsache, daß in einer Zeit immer kürzer werdender Innovationszyklen und einer Periode des Zeitwettbewerbs nicht generell auf eine umfassende und damit aufwendige Modellierung der Unternehmen verzichtet wird, läßt sich mit einem Wandel des Verständnisses von Modellierung erklären.[4] Modellierung bedeutet immer Abstraktion, d.h. Konzentration auf das, was zum jeweiligen Zeitpunkt als wesentlich erachtet wird und insofern ist die Modellierung der Unternehmesrealität zeitbezogen.[5]

2 Methoden

2.1 EPK

"Ereignisgesteuerte Prozessketten (EPKs) sind das Werkzeug für die Analyse und Beschreibung von Geschäftsprozessen. Diese Methode und die dazugehörigen grafische Beschreibungstechnik (Notation) für Geschäftsprozesse wurde von Scheer und seinen Mitarbeitern im Rahmes ihres ARIS-Konzepts entwickelt."[6] "Sie ist ein zentraler Bestandteil des SAP-Systems, was ein sehr wichtiger Faktor für ihre schnelle Verbreitung war. Sie baut auf Petri-Netzen auf und ist in unterschiedlichen Komplexitätsstufen darstellbar. Die EPK ist auf der Ebene des Fachkonzeptes als semantisches Prozessmodell der Steuerungsebene zur Beschreibung der fachlichen Inhalte zugeordnet."[7] "Als Konzept ist ARIS ein Rahmenwerk zur Beschreibung von Unternehmen und betriebswirtschaftlichen Anwendungssystemen."[8]


Die Tabelle 1 erläutert die bei der Erstellung einer EPK genutzten Notationen.

Entnommen aus: Wolters und Kaschny (2010), S. 39 / Tab.-Nr.1: EPK Notation
Entnommen aus: Wolters und Kaschny (2010), S. 39 / Tab.-Nr.1: EPK Notation


2.1.1 Ereignisse

"Unter Ereignisse werden hier betriebswirtschaftliche relevante Ereignisse verstanden. Diese Ereignisse beeinflussen und steuern auf die eine oder andere Weise die Abläufe im Unternehmen.


Einige Beispiele dafür sind:

  • Ein Auftrag ist eingetroffen.
  • Angebot ist gültig
  • Auftragsbestätigung ist übermittelt
  • Kundenanfrage ist abgelehnt
  • Kunde ist neu (als Ergebnis einer entsprechenden Prüfung)


Zur Definition von Ereignissen können wir […] auf den umgangssprachlichen Ereignisbegriff zurückgreifen, allerdings mit der Ergänzung, dass es sich um betriebswirtschaftlich relevante Ereignisse handeln muss, die für den betrachteten Geschäftsprozess Bedeutung haben."[9] Im Aris-Gesamtkonzept ergeben sich aus den betriebswirtschaftlichen Problemstellungen dreizehn Komponenten, wobei für jede einzelne Komponente eine geeignete Beschreibungsmethode bzw. ein Modellierungsmodell auszuwählen ist, um die organisatorischen Aspekte richtig und vollständig abzubilden.[10]


Dieser Ansatz wird auch ARIS-Haus genannt.

Entnommen aus: Seidlmeier (2006), S. 25 / Abb. 1.1: ARIS-Haus
Entnommen aus: Seidlmeier (2006), S. 25 / Abb. 1.1: ARIS-Haus


"Zu Beginn eines Organisationsprojekts konzentriert man sich zunächst auf das Erarbeiten der sogenannten Betriebswirtschaftlichen Problemstellung.

Diese Problembeschreibung beinhaltet typischerweise:

  • Ausgangssituation
  • Schwachstellen des Istzustandes
  • Ziele, die mit den neuen Geschäftsabläufen erreicht werden sollen
  • Anforderungen an die zukünftigen Informationssysteme
  • Mögliche Lösungsansätze


Schwachstellen sind beispielsweise:

  • Medienbrüche z.B. zwischen DV-bezogener und manueller Bearbeitung
  • Organisatorische Brüche (häufiger Wechsel der verantwortlichen Organisationseinheit)
  • Datenredundanzen
  • Mehrfacherfassung
  • Zeitverzögerungen bzw. lange Durchlaufzeiten


Die im Rahmen der ARIS-Methodik geeignete Beschreibungsmethode dazu ist v.a. das Vorgangskettendiagramm (VDK)."[11]

Entnommen aus: Seidlmeier (2006), S. 27 / Abb. 1.2: Vorgangskettendiagramm
Entnommen aus: Seidlmeier (2006), S. 27 / Abb. 1.2: Vorgangskettendiagramm


Eine Ist-Erhebung und grafische Darstellung eines Beispielprozesses wird nun mit ARIS in der nachfolgenden Abbildung aufgezeigt:

Entnommen aus: Seidlmeier (2006), S. 13 / Abb. 1.3: Ist-Erhebung an einem Beispielprozess
Entnommen aus: Seidlmeier (2006), S. 13 / Abb. 1.3: Ist-Erhebung an einem Beispielprozess


"Zur Herleitung einer Architektur im ARIS-Sinne wird ein Modell für Unternehmesprozesse entwickelt, das alle wesentlichen Merkmale zur Beschreibung von Geschäfts- und Unterstützungsprozessen beinhaltet. Die hohe Komplexität des dabei entstehenden Modells (als Abbildung der betriebswirtschaftlichen Realität) […] wird auf einzelne handhabbare Beschreibungssichten und Beschreibungsebenen reduziert."[12] "Die Zerlegung der Sichten erfolgt derart, dass die Beziehungen der Komponenten innerhalb einer Sicht erhalten bleiben, zwischen den Sichten jedoch vorerst verloren geht oder nur eine relativ lose Kopplung bestehen bleibt."[13]


Entnommen aus: Seidlmeier (2006), S. 15 / Abb. 1.4: Beispieldarstellung mit Sichteneinteilung
Entnommen aus: Seidlmeier (2006), S. 15 / Abb. 1.4: Beispieldarstellung mit Sichteneinteilung


2.1.2 Funktionssicht

"Eine Funktion ist eine fachliche Aufgabe bzw. Tätigkeit an einem Objekt zur Unterstützung eines oder mehrerer Unternehmensziele."[14] "Funktionen beschreiben also, was gemacht werden soll. Alle Tätigkeiten in einem Geschäftsprozess werden in einzelne Teilaufgaben unterteilt. Sie erfassen bei Mitarbeitern deren operative Tätigkeit, bei einem Informationssystem so etwas wie eine Transaktion bzw. einem betriebswirtschaftlichen Funktionsbaustein."[15]

"Sie beschreibt in der Regel ein Informationsobjekt, an dem eine Verrichtung vorgenommen wird."[16] "Kein Unternehmen kommt heute ohne Datenbestände aus, die das Unternehmen selbst, seine Geschäftsobjekte und seine informationelle Umwelt ganz oder in Ausschnitten modellieren. Diese Datenbestände sind damit auch für die Abwicklung der Geschäftsprozesse von großer Bedeutung. In Ereignisgesteuerten Prozessketten schlägt sich dies so nieder, dass bei den Funktionen die jeweils benötigten oder entstehenden Infomationen angegeben werden. Dies können Kundendaten, die Angaben des früher erstellten Angebots, aktuelle Marktpreise oder eine andere Infomation sein, die für irgendeinen Abschnitt des Geschäftsprozesses von Bedeutung besitzt. In diesem Ansatz werden solche Daten als Informationsobjekte bezeichnet und in Verbindung gesetzt mit der Funktion, für die sie benötigt werden. Dann werden z.B. einer Funktion Auftragsbearbeitung Informationen zugeordnet

  • zu Kunden,
  • zum Angebot,
  • zu den Materialien,
  • zu den Konditionen,
  • zum Kundenauftrag und zum
  • Bedarf.


Die Beziehung zwischen Informationsobjekten und Funktionen hat eine Richtung. Funktionen benötigen Informationen aus Informationsobjekten, erzeugen aber auch welche, die dann zu den Informationsobjekten dazu kommen."[17]

"Zur Darstellung der Objekte der Funktionssicht und deren Beziehungen werden in ARIS vorzugsweise die Modelle Funktionsbaum und Zieldiagramm verwendet."[18]


Entnommen aus: Seidlmeier (2006), S. 16 f. / Abb. 1.5: Funktionsbaum / Abb. 1.6: Zieldiagramm
Entnommen aus: Seidlmeier (2006), S. 16 f. / Abb. 1.5: Funktionsbaum / Abb. 1.6: Zieldiagramm


2.1.3 Datensicht

"Die Datensicht beschreibt die für die Modellierung relevanten Informationsobjekte und deren Beziehungen zueinander. Hierzu werden erweiterte Entity-Relationship-Diagramme eingesetzt."[19] "Die Beschreibung der Datensicht, also der logischen Datenstruktur des Anwendungsfalles, ist methodisch anspruchsvoll. Es muss eine meist komplexe Struktur aus Entity-, Attribut- und Beziehungstypen erstellt werden. Für die Gestaltung eines Anwendungssystems wird das Fachkonzept der Daten zunehmend wichtiger. Je leichter Funktionen durch den Einsatz höherer Programmiersprachen in Anwendungssystemen abgebildet werden können, desto wichtiger ist es, vorher richtige Datenstrukturen aufzustellen. Hinzu kommt, dass bestehende Datenstrukturen nur schwer geändert werden können."[20]

2.1.4 Organisationssicht

"Mithilfe der Organisationseinheiten wird festgehalten, wo die in einer Funktion erfasste Aufgabe getätigt wird. Die Organisationseinheiten werden also den Funktionen zugeordnet. Sehr oft wird man heute, v.a. wenn der Personalbestand schon sehr niedrig ist und/oder sich das Unternehmen von der klassischen Aufbauorganisation wegbewegt, die Organisationseinheiten sehr klein fassen, evtl. sogar auf Stellenebene gehen, um genügend Aussagekraft für die Analyse der Schwachstellen zu erhalten."[21]

"Beispiele für (klassische) Organisationseinheiten in einem Industrieunternehmen sind Vertrieb, Personalwesen, Werk, Informationsvermittlungsstelle."[22]

"Beziehungen werden als Linien zwischen den Organisationsobjekten dargestellt und [...] als Kanten bezeichnet."[23]

Entnommen aus: Seidlmeier (2006), S. 19 / Abb. 1.7: Beispielhaftes Organigramm mit Organisationseinheiten
Entnommen aus: Seidlmeier (2006), S. 19 / Abb. 1.7: Beispielhaftes Organigramm mit Organisationseinheiten


2.1.5 Steuerungs- (Prozess-) sicht

"Mit der Zerlegung des Prozesses in einzelne Sichten (Funktionen, Daten und Organisation) wird zwar das Ziel der Komplexitätsreduzierung erreicht, allerdings gehen die Zusammenhänge der Prozesselemente zwischen den Sichten verloren. Aus diesem Grund wird eine weitere Sicht, die Steuerungssicht (auch Prozesssicht) aufgenommen, in der die Verbindungen zwischen den Sichten beschrieben werden."[24]

"In Geschäftsprozessen müssen oft mehrere Tätigkeiten parallel erledigt werden, um ein Ziel zu erreichen. Oder es gibt Alternativen: Entweder die eine oder die andere Tätigkeit führt zum Ziel. Genauso mit Ereignissen. Manchmal können alternative Ereignisse dieselbe Tätigkeit auslösen oder mehrere Ereignisse zusammen die Bedingung sein für den Beginn einer Tätigkeit."[25]

Folgende logische Verknüpfungsoperatoren gibt es für Ereignisse und Funktionen:

  • "UND Alle Ereignisse/Funktionen müssen eintreten, damit der Kontrollfluss fortgesetzt wird.
  • ODER Es muss mindestens ein(e) Ereigniss/Funktion eintreten, damit der Kontrollfluss fortgesetzt wird.
  • exklusives ODER Es muss genau ein(e) Ereigniss/Funktion eintreten, damit der Kontrollfluss fortgesetzt wird."[26]


"Durch das Hintereinanderschalten von Ereignissen und Funktionen entsteht eine zusammenhängende Kette, die den logischen Ablauf eines Prozess wiedergibt. Eine schlanke EPK enthält die Grundelemente Funktionen, Ereignisse und Verknüpfungsoperatoren (Regeln). Diese Grundelemente sind ebenfalls durch Linien, sprich Kanten, verbunden."[27]

Entnommen aus: Seidlmeier (2006), S. 21 / Abb. 1.8: einfache EPK
Entnommen aus: Seidlmeier (2006), S. 21 / Abb. 1.8: einfache EPK


"Die erweiterte ereignisgesteuerte Prozesskette eEPK entsteht aus einer schlanken, ergänzt um Aussagen wie Input bzw. Output Daten, ausführende Organisationseinheiten bzw. Stellen, benutze Anwendungssysteme usw."[28]

Entnommen aus: Seidlmeier (2006), S. 22 / Abb. 1.9: erweiterte EPK
Entnommen aus: Seidlmeier (2006), S. 22 / Abb. 1.9: erweiterte EPK


2.1.6 Vor- und Nachteile

Vorteile:

  • "Die EPK ist anwendungsübergreifend, d.h. sie dient nicht nur zur Modellierung von Abläufen innerhalb eines Softwaresystems, sondern kann Prozesse über verschiedene Systeme und auch verschiedene Unternehmen hinweg darstellen.
  • Sie ist sehr mächtig und umfassend. Es stehen sehr viele Konstrukte zur Verfügung, mit denen die unterschiedlichen Aspekte von Prozessen dargestellt werde können.
  • Sie enthält Konstrukte sowohl für organisatorische als auch für informationstechnische Aspekte und erlaubt somit eine durchgängige Betrachtung von Prozessen sowohl unter betriebswirtschaftlichen Fragestellungen als auch hinsichtlich ihrer Unterstützung durch Informationssysteme.
  • Sie lässt sich mit wichtigen Notationen anderer Sichten integrieren, wie z. B. Funktionsbaum oder Klassendiagramm, so dass eine umfassende, konsistente Unternehmensmodellierung möglich wird.
  • Sie ist auch für Nicht-IT-Fachleute verständlich.
  • Sie ist in der Praxis weit verbreitet."[29]


Nachteile:

  • "Die Nutzer müssen sich aus der Vielfalt der Konstrukte die für sie geeigneten auswählen und Modellierungskonventionen für ihren Anwendungsbereich definieren.
  • Sollen vorhandene Modelle für weitere Anwendungsbereiche genutzt werden, wie z.B. für Workflow Management oder Simulation, so müssen diese Modelle u.U. Grundsätzlich überarbeitet werden. Hier bieten solche Notationen Vorteile, die speziell auf die Workflow-Modellieferung oder die Simulation zugeschnitten sind. Dafür sind diese nicht so umfassend und von vorherein auf einen Anwendungsbereich eingeschränkt.
  • Auch wenn die Grundkonstrukte der EPK schnell erklärt und leicht zu verstehen sind, ist für die Erstellung aussagekräftiger und nützlicher EPK-Modelle dennoch ein nicht unbeträchtlicher Schulungs- und Einarbeitungsaufwand erforderlich."[30]


2.2 UML

"Die Unified Modeling Language™ (UML™) ist eine durch die Object Management Group (OMG) standardisierte graphische Sprache zur Beschreibung objektorientierter Modelle. Sie wurde durch Vertreter verschiedener Firmen entwickelt und standardisiert. Als Nachfolgerin verschiedener OO-Modellierungssprachen wie Booch (die mit den Wolken) OMT (Rumbaugh) und OOSE (Use Cases von Jacobson) integriert sie deren Ansätze und Ideen und führt sie fort."[31]


"UML definiert verschiedene Elemente zur Beschreibung von Modellen. Diese werden definiert durch folgende Kritierien:

  • Syntax – visuell definiert
  • Semantik – noch nicht formal definiert (an einigen Stellen können also Mehrdeutigkeiten auftreten)
  • Well-Formedness Rules
  • Notationen


UML wird standardisiert von der "Object-Management-Group", ist ein weithin akzeptierter oo-Ansatz. Unterstützt typische Modelle und Diagramme, die genutzt werden können für die Anforderungsdefinition, Analyse, Design, Implementierung."[32]

2.2.1 Diagrammarten

Entnommen aus: Nakhla (2011) S.8 / Abb.-Nr. 2.1: UML Diagrammarten
Entnommen aus: Nakhla (2011) S.8 / Abb.-Nr. 2.1: UML Diagrammarten

2.2.2 Anwendungsfalldiagramm (Use-Case-Diagram)

"Das Anwendungsfalldiagramm zeigt die Interaktion zwischen einem Akteur und einem (Teil-) System. Mit Anwendungsfalldiagrammen wird die statische Sicht von außen auf das entsprechende System dargestellt, indem die vom System bereitgestellten Dienste als Anwendungsfälle mit dem jeweiligen Akteur in Beziehung gesetzt werden. Da das Anwendungsfalldiagramm nur das wesentliche Verhalten eines Systems beschreibt, eignet es sich hervorragend, um mit Anwendern (z.B. potentiellen Kunden) die Grundfunktionen des Systems zu erschließen und abzustimmen und unterstützt den Entwickler im späteren Verlauf der Entwicklung - z.B. wenn man im weiteren Verlauf die Klassen im Klassendiagramm odelliert oder es schlussendliche an die Implementierung geht. Das Anwendungsfalldiagramm wird also i.d.R. ganz zu Beginn eines oftwareprojekts eingesetzt, um die Anforderungen an das System zu erfassen. Neben Anwendungsfällen und Akteuren kann das Anwendungsfalldiagramm auch Abhängigkeits-, Generalisierungs- und Assoziationsbeziehungen ähnlich dem Klassendiagramm enthalten, wobei diese dann zwischen den einzelnen Anwendungsfällen auftreten und eine leicht andere Semantik haben (vgl. weiterführende Literatur)."[33]

Entnommen aus Oose (2011) / Abb.-Nr. 2.2: Notationsübersicht: Anwendungsfalldiagramm
Entnommen aus Oose (2011) / Abb.-Nr. 2.2: Notationsübersicht: Anwendungsfalldiagramm


 Modellelemente des Anwendungsfalldiagramms

"Die Grafik aus dem Beispiel zeigt die elementaren Komponenten des Anwendungsfalldiagramms.

  • Anwendungsfall

Ein Anwendungsfall beschreib eine Menge von Aktionsfolgen aus Sicht des Akteurs, ohne dabei die genauere Implementierung zu spezifizieren. Jede Folge ist dabei eine Interaktion zwischen Akteur und System, kann also als Menge von Diensten angesehen werden, die das System seinen Anwendern bereitstellt.

  • Akteur

Ein Akteur steht für einen bestimmten Anwendertyp, der vom System gewisse Dienstleistungen abverlangt."[33]

  • Beziehungen

Ähnlich denen im Klassendiagramm, jedoch mit einer anderen Semantik. [34]

2.2.3 Klassendiagramm (Class Diagram)

"Das Klassendiagramm gehört in UML zu den statischen Strukturdiagrammen. Mithilfe des Klassendiagramms klassifiziert man Attribute und Operationen und veranschaulicht Beziehungen, die einzelne Klassen untereinander haben. Neben Struktur- und Verhaltensmerkmalen von Klassen werden in einem Klassendiagramm auch Beziehungen zwischen Schnittstellen und Kollaborationen grafisch dargestellt. Man modelliert also die statische Sicht eines Softwaresystems, wobei Attribute und Operationen zu sinnvollen Einheiten (Klassen) geschnürt werden. Hilfreich beim Erstellen von Kassendiagrammen kann das zuvor angefertigte Anwendungsdiagramm sein, mit dessen Hilfe man ggf. schneller und einfacher die Klassen identifizieren kann.

 Modellelemente des Klassendiagramms
  • Klasse

Eine Klasse beschreibt eine Menge an Objekten, die miteinander dieselben Attribute und Operationen haben. Grafisch wird eine Klasse in UML als ein Rechteck dargestellt. Jede Klasse enthält einen Abschnitt für einen eindeutigen Namen und i. d. R. einen weiteren Abschnitt für Attribute und einen dritten für Operationen. Zugriffsrechte auf Operationen und Attribute können durch voranstellen von Symbolen vor das entsprechende Element sichtbar gemacht werden. (z.B.“-„ für private, „+“ für public, „#“ für protected).

Entnommen aus Oose (2011) / Abb.-Nr. 2.3 : Notationsübersicht: Klassendiagramm
Entnommen aus Oose (2011) / Abb.-Nr. 2.3 : Notationsübersicht: Klassendiagramm


  • Generalisierung

Eine Generalisierung ist eine „ist ein“ Beziehung, die zwischen dem Speziellen und seinem Generalisierten besteht. Eine Generalisierung ist z.B. die Beziehung von einer Unterklasse (spezialisierten Klassen) zu seiner Oberklasse (generalisierten Klasse). Kurzum zeigt eine Generalisierung, welche Klasse von welcher abgeleitet ist und damit auf der Grundstruktur einer andere aufbaut.

  • Beziehungen

- Abhängigkeit

Eine Abhängigkeit ist eine Benutz-Relation. Sie wird mit einer gestrichelten Linie dargestellt, an dessen Ende ein Pfeil auf die Klasse zeigt, von der eine andere Klasse abhängt. Mit bhängigkeiten zeigt man also, dass eine Klasse eine andere „benutzt“. So hat die Klasse „Druckvorschau“ eine Methode namens „GetBitmapPrintout“, welche in ihrem Argument auf Klasse „Druckertreiber“ zurückgreift und damit von letztere Abhängig ist.

- Assoziation

Eine Assoziation zwischen Klassen besagt lediglich, dass diese in einer nicht näher beschriebenen Beziehung zueinander stehen. Zum Beispiel assoziiert man mit einem einzelnen Bücherregal zweifelsohne Bücher. Wir interpretieren die entsprechende Grafik so, dass sich von jedem Bücherregal auf die Bücher, die es beherbergt, schließen lässt. Umgekehrt wissen wir auch von jedem Buch, in welches Bücherregal es gehört. Die Navigationsrichtung ist also bidirektional, daher eine ungerichtete Assoziation. Ein andere Beispiel: Von Bankkonten hingegen können wir zwar auf den jeweiligen Inhaber - eine juristische Person - schließen, nicht aber von der Person darauf, welche Konten sie bei welcher Bank hat. In diesem Fall versehen wir die zugehörige Assoziation lediglich mit einem Pfeil vom „Bankkonto“ zur „juristischen Person“, so dass wir eine gerichtete Assoziation erhalten.

- Aggregation

Man verwendet Aggregationen anstatt Assoziationen, wenn das Verhältnis zwischen Elementen derart noch genauer beschrieben werden soll, dass das Einzelne ein Teil des Ganzen ist („Ist Teil von“ - Beziehung). Die Aggregation zeigt also lediglich auf, welches Element in der Organisationseinheit über dem anderen steht, sagt aber nichts darüber aus, dass der Lebenszyklus der Einzelnen an den des Ganzen gekoppelt ist.

- Kompsotion

Eine Komposition ist eine Erweiterung der Aggregation. Sie erweitert die Aggregation in der Weise, dass die Lebensdauer des Einzelnen an die des Ganzen gebunden ist, also mit ihm lebt und stirbt. Ein Attribut ist im wesentliche eine solche Komposition, wenn auch in einer anderen Schreibweise. Die Grafik zeigt die beiden Klasse „Fenster“ und „Nicht- Clientbereich“, verbunden über eine Komposition (Aggregation mit ausgefüllter Raute). Jedes Fenster hat also genau einen Nicht-Clientbereich (vgl. Multiplizität). Wird allerdings das Fenster als Ganzes."[33]


Beispiel:

Entnommen aus Oose (2011) / Abb.-Nr. 2.4: Notationsübersicht: Klassendiagramm
Entnommen aus Oose (2011) / Abb.-Nr. 2.4: Notationsübersicht: Klassendiagramm

2.2.4 Aktivitätsdiagramm (Activity Diagram)

"Aktivitätsdiagramme können einfache oder aber zusammen-gesetzte Zustände haben, Verzweigungen, Aufspaltungen und Zusammenführungen. Es können auch Operationen eines Objekts aufgerufen oder Signale an Objekte geschickt werden (vgl. Objektfluss). Trotz der starken Vereinfachung wird der kritische Pfad des Workflows erfasst und visualisiert.


Entnommen aus Oose (2011) / Abb.-Nr. 2.5: Notationsübersicht: Aktivitätsdiagramm
Entnommen aus Oose (2011) / Abb.-Nr. 2.5: Notationsübersicht: Aktivitätsdiagramm


  • Anfangs- und Endzustand

Der Logikfluss beginnt in jedem Aktivitätsdiagramm mit dem Anfangszustand und endet in einem Endzustand.

  • Aktionszustände

Bei Aktionszuständen handelt es sich um Zustände, in denen sich das System befinden kann (vgl. Automatenzustände). Jeder Aktionszustand repräsentiert die Ausführung einer Aktion. Ein Aktionszustand kann sowohl einen einfachen Namen tragen (z.B. „Zähler erhöhen“) oder einen Ausdruck (z.B. „i += 1“).

  • Kontrollfluss

Der Kontrollfluss wird als ein durchgezogener Pfeil dargestellt und gibt die Navigationsrichtung an – zeigt also auf den Folgezustand.

  • Objektfluss

Im Gegensatz zum Kontrollfluss wird der Objektfluss als gestrichelte Linie mit Pfeil dargestellt. Er zeigt auf das Objekt dessen Operation ausgeführt wird (vgl. Grafik)

  • Transition

Eine Transition wird als schwarz ausgefüllter Balken dargestellt, der entweder mehrere Kontrollflüsse zu einem vereint (nebenläufiger Zusammenfluss) oder aber umgekehrt einen Kontrollfluss in mehrer aufspaltet (nebenläufige Aufspaltung).

  • Verzeigung

Eine Verzweigung wird als symmetrische Raute dargestellt. Ihre ausgehenden Kontrollflüsse werden i.d.R. mit der Bedingung der Verzweigung beschriftet."[33]


2.2.5 Sequenzdiagramm (Sequence Diagram)

"Das Sequenzdiagramm zählt zu den Interaktionsdiagrammen und ist eines der UML- Diagrammtypen, mit welchem dynamische Aspekte eines Systems modelliert werden können. Sequenzdiagramme heben speziell die zeitliche Reihenfolge von Nachrichten hervor, mit denen die einzelnen Objekte untereinander kommunizieren. Sequenzdiagramme unterstützen das Dokumentieren des Logikflusses innerhalb einer Anwendung. In einem Sequenzdiagramm steht damit die zeitliche Folge der Abläufe im Fordergrund. So zeigt es neben einer Menge von Objekten auch die von diesen Objekten gesendeten bzw. empfangenen Nachrichten.

Entnommen aus Oose (2011) / Abb.-Nr. 2.6:  Notationsübersicht: Sequenzdiagramm
Entnommen aus Oose (2011) / Abb.-Nr. 2.6: Notationsübersicht: Sequenzdiagramm
 Modellelemente des Sequenzdiagramms

Grafisch betrachtet ist das Sequenzdiagramm eine Art Tabelle, in der Objekte entlang der x- Achse abgebildet werden, die Nachrichten zeitlich aufsteigend entlang der y-Achse (vgl. Beispiel). Das weiter links stehen Objekt ist i.d.R. das, welches die Nachricht schickt, das weiter rechts stehende Objekt jenes, welches die Nachricht empfängt. Die Abfolge der Ereignisse wird von oben nach unten gelesen. Der Zeitraum, in dem ein Element eine Aktion ausführt, wird als vertikaler Balken (Kontrollfokus) angezeigt; der Nachrichtenfluss zwischen den Elementen erfolgt horizontal. Innerhalb eines Sequenzdiagramms verzichtet man meist auf Fallunterscheidungen, modelliert dann einfach den alternativen Kontrollfluss in einem separaten Sequenzdiagramm.


  • Objekt

Das Objekt wir in UML wie die Klasse als ein Rechteck dargestellt. Um es aber von der Klasse unterscheiden zu können, wird sein Name unterstrichen. Speziell im Sequenzdiagramm werden die Objekte von links nach rechts angeordnet, i.d.R. in der Reihenfolge, in der sie Nachrichten schicken.

  • Lebensdauer

Damit auch die Lebensdauer eines jeden Objektes ersichtlich ist, wird diese als gestrichelte Linie angezeigt, die direkt an das Objekt (Rechteck) anschließt und im Laufe der Zeit nach unten erweitert wird - eben solange wie das Objekt existiert.

  • Aktivitätsbalken

Während das Objekt eine Aktivität durchführt (Nachricht sendet, empfängt oder sich aber einfach nur im Wartezustand befindet), wird die Lebenslinie des Objektes von einem vertikalen Balken überlagert. Dieser zeigt an, dass das entsprechende Objekt gerade „beschäftigt“ ist. Durch die Überlagerung der Lebenslinie mit dem Aktivitätsbalken ist stets gewährleistet, dass ein Objekt nicht noch vor Beendigung seiner Aktivität zerstört ist bzw. vor Aufnahme seiner Aktivität auch erzeugt wurde.

  • Nachrichten

Im Sequenzdiagramm kommt neben dem Objekt der Nachricht eine besondere Rolle zu, ist diese doch das Werkzeug, mit dem Objekte untereinander kommunizieren. Neben einfachen Nachrichten mit Mitteilungscharakter (z.B. WM_MOUSEMOVE) unterscheiden wir Nachrichten die einen Aufrufcharakter haben (z.B. Methodenaufrufe), asynchrone Nachrichten und Nachrichten-Rückgaben (z.B. Rückgabewerte). Der Nachrichtenfluss wird im Sequenzdiagramm generell horizontal eingezeichnet. Nachrichten lösen i.d.R. andere Nachrichten aus. Um die zeitliche Reihenfolge des Nachrichtflusses im Sequenzdiagramm zu visualisieren, werden die Nachrichten i.d.R. von oben nach unten angeordnet, entsprechend ihres Eintretens. Objekte können jederzeit erzeugt und zerstört werden, durch Empfang der entsprechenden Nachricht <<create>> bzw. <<destroy>>. Sobald ein Objekt durch Empfang der Nachricht <<create>> erzeugt wurde, wird sein Rechteck in eine Spalte des tabellenähnlich aufgebauten Sequenzdiagramms hinzugefügt und die Lebenslinie beginnt zu laufen. Sobald das Objekt die Nachricht <<destroy>> empfängt, endet seine Lebenslinie."[33]


2.2.6 Zustandsdiagramm (Statechart-Diagram)

"Das Zustandsdiagramm ist ein Automat, mit dem ebenfalls dynamische Aspekte von Systemen modelliert werden – genauer eine Folge von Zuständen, die z.B. ein Objekt im Laufe seines Lebens als Reaktion auf Ereignisse annehmen kann. Das Zustandsdiagramm wird also u.a. eingesetzt, um den Lebenslauf eines Objekts zu modellieren. Im Gegensatz zum Aktivitätsdiagramm zeigt das Zustandsdiagramm aber den Kontrollfluss von Zustand zu Zustand und nicht von Aktivitäten. Vom Sequenzdiagramm unterscheidet sich das Zustandsdiagramm dadurch, dass nicht die Interaktion zwischen den verschiedenen Objekten aufgezeigt wird, sondern das nach Ereignissen geordnete Verhalten des jeweiligen Objekts. Er ist also ganz besonders hilfreich beim Modellieren reaktiver Systeme. In solchen Systemen verweilen Objekte i.d.R. solange in ein und demselben Zustand, bis sie eine Nachricht erhalten oder auf ein Ereignis reagieren und damit vom visuellen Standpunkt aus ihren Zustand wechseln. Auch für das Zustandsdiagramm gilt, dass es lediglich die Elemente enthalten sollte, die wesentlich zum Verständnis des beschriebenen Aspekts sind.

 Modellelemente des Zustandsdiagramms

Das Zustandsdiagramm besteht im Wesentlichen aus den gleichen elementaren Komponenten wie das Aktivitätsdiagramm, wobei anstatt Aktivitäten Zustände von Objekten betrachtet werden.

  • Zustand

Ein Zustand ist eine Bedingung oder eine Situation im Leben eines Objekts, während der es einer Bedingung genügt, eine Aktivität ausführt oder auf ein Ereignis wartet.

  • Zustandsübergang

Der Zustandsübergang wird als ein durchgezogener Pfeil dargestellt, der auf den Folgezustand zeigt. In der Regel ist dieser eindeutig beschriftet. Neben den beiden genannten Modellelementen findet man in Zustandsdiagrammen auch Verzweigung, etc. (vgl. Aktivitätsdiagramm).

  • Beispiel zum Zustandsdiagramm"[33]


Entnommen aus Oose (2011) / Abb.-Nr. 2.7 Notationsübersicht: Zustandsdiagramm
Entnommen aus Oose (2011) / Abb.-Nr. 2.7 Notationsübersicht: Zustandsdiagramm

2.2.7 Vor- und Nachteile

Vorteile:

  • "Investitionsschutz für Modellierungswerkzeuge,
  • einfacher Modellaustausch,
  • bessere Modellwiederverwendung,
  • höhere Professionalisierung und
  • besseres Training."[35]


Nachteile:

  • "Die UML wird hinsichtlich semantischer Inkonsistenzen, Konstruktmehrdeutigkeiten, inadäquate Notationen und kognitiven Unzugänglichkeiten kritisiert.
  • Die hohe Komplexität der Sprache (beispielsweise umfasst die Sprachspezifikation mehr als 1200 Seiten) verursacht Schwierigkeiten bei ihrer Benutzung.
  • Bisher sind keine Werkzeuge verfügbar, die den Sprachstandard vollständig unterstützen.
  • Die Pflege des Standards ist schwerfällig und leicht fehleranfällig."[35]


"Dennoch bildet die UML einen wichtigen Meilenstein für die Systementwicklung. Wie aktuelle empirische Untersuchungen belegen, nimmt die UML trotz vorliegender Nachteile zunehmend die Rolle einer Lingua franca der Informationsmodellierung ein"[35]

2.3 BPMN

In diesem Abschnitt wird die Business Process Modeling Notation (BPMN), eine grafische Notation zur Darstellung von Geschäftsprozessen, näher erläutert. Sie ist in der letzten Zeit zusehends in das Blickfeld von Entwicklern gerückt, da sie zwei wichtige Funktionen in der Entwicklung moderner Unternehmenssoftware übernehmen will. Einerseits soll sie eine Kommunikationsbrücke zwischen der Fach- und der IT-Welt bilden, andererseits strebt sie die direkte Ausführbarkeit derart erstellter Prozesse an.[36]

2.3.1 Entstehung und Entwicklung

BPMN wurde ursprünglich von der BPMI (Business Process Management Initiative), einem Konsortium aus Vertretern der Software-Unternehmen, entwickelt und sollte zunächst eine grafische Notation zur Darstellung von Prozessbeschreibungen der Business Process Modeling Language bereitstellen.[37] Die erste Version wurde 2004 veröffentlicht. Im Jahr 2008 folgte die Version 1.1, die jedoch kaum nennenswerte Neuerungen enthielt. „Zwischenzeitlich ist die BPMI in der Object Management Group (OMG) aufgegangen. Diese Organisation ist durch Standards im Softwarebereich bekannt geworden, wie die bereits erwähnte UML […] .“[38] Version 1.2 wurde im Januar 2009 veröffentlicht. Die derzeit gültige Version 2.0 ist seit Januar 2011 gültig.[39]

2.3.2 Zielsetzung

Die BPMI entwickelte mit BPMN einen neuen Standard. In der BPMN-Spezifikation für die Version 1.1 wird die Zielsetzung unmissverständlich formuliert:


„The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.”[40]


Nach Meinung der BPMI soll die BPMN eine leicht verständliche Darstellungsform für Prozesse sein. Es soll dabei keine Rolle spielen, ob es sich um Analytiker handelt, die erste Grobentwürfe mit Auftraggebern und Facharbeitern entwickeln, um Programmierer, die den zu unterstützenden Prozess in einem Programm umsetzen, oder um Personen aus der Qualitätssicherung, die Prozesse überwachen müssen. Es geht also hauptsächlich darum, die beiden Seiten (Fachwelt, IT-Welt) durch eine grafische Notation zusammenzubringen.[41]

2.3.3 Modellierungsbausteine

„Es sollte betont werden, dass es einer der Ansätze zur Entwicklung von BPMN war, einfache und verständliche Mechanismen zur Erstellung von Geschäftsprozessmodellen zu schaffen. Darüber hinaus sollte es jedoch auch möglich sein, komplexe Geschäftsprozesse darstellen zu können. Um diesen gegensätzlichen Anforderungen gerecht zu werden, war es notwendig die grafischen Aspekte dieser Darstellung in spezifischen Kategorien zu organisieren. Damit wurde ein kleine Menge an Darstellungskategorien geschaffen, die es den Lesern von BPMN Diagrammen ermöglicht, die Basiselemente leicht wahrzunehmen und somit das Diagramm zu verstehen. […] Die fünf Basiskategorien der BPMN Elemente sind:

  • Flow Objects (Flussbausteine)
  • Data (Daten)
  • Connection Objects (Verbindungsobjekte)
  • Swimlanes (Schwimmbahnen)
  • Artifacts (Artefakte)


Flussbausteine sind die graphischen Hauptelemente, um das Verhalten von Prozessen dazustellen. Es gibt drei Flussbausteine:

  • Events (Ereignisse)
  • Activities (Aktivitäten)
  • Gateways (Schleusen)


Daten können durch die vier folgenden Elemente dargestellt werden:

  • Data Objects (Datenobjekt)
  • Data Inputs (Dateninput)
  • Data Outputs (Datenoutput)
  • Data Stores (Datenspeicher)


Darüber hinaus gibt es vier Möglichkeiten die Flussbausteine mit sich selber oder mit anderen Elementen zu verbinden:

  • Sequence Flows (Prozessfluss)
  • Message Flows (Nachrichtenfluss)
  • Associations (Assoziationen)
  • Data Associations (Datenassoziationen)


Es gibt zwei Möglichkeiten die Modellierungsbausteine durch Schwimmbahnen zu gruppieren:

  • Pools (Becken)
  • Lanes (Bahnen)


Artefakte werden verwendet um zusätzliche Informationen über den Prozess zu geben. Es gibt zwei standardisierte Arten von Artefakten. Die Modellierer oder die Modellierungstools haben aber die Freiheit so viele Artefakte hinzuzufügen wie notwendig. […] Es gibt derzeit folgende Artefakte:

  • Group (Gruppierung)
  • Text Annotation (Textanmerkung)“.[42]


2.3.3.1 Zentrale Modellierungsbausteine

Ereignis (Event): Ein Ereignis ist etwas, dass während eines Prozesses […] oder einer Choreographie […] ‘passiert’. Diese Ereignisse beeinflussen den Fluss des Modells und haben gewöhnlich einen Auslöser (Trigger) oder ein Ergebnis (Result) [Ereignisse werden als mit einer durchgehenden Linie gezeichnete Kreise dargestellt, Anm. d. Autors]. Das leere Kreiszentrum erlaubt Markierungen, um zwischen Auslöser und Ergebnis unterscheiden zu können. Es gibt drei Arten von Ereignissen […]:

  • Startereignisse
  • Zwischenereignisse
  • Endereignisse


BPMN Ereignis
BPMN Ereignis

Entnommen aus: OMG (2011a), S. 29 / Abb. 3.1: BPMN Ereignis


Aktivität (Activity): Eine Aktivität ist ein Überbegriff für Tätigkeiten […]. Eine Aktivität kann atomar oder nicht-atomar sein (zusammengesetzt) [Sie werden als abgerundete Rechtecke mit einer dünnen durchgezogenen Linie dargestellt, Anm. d. Autors]. Es gibt zwei Aktivitätstypen in einem Prozessmodell:

  • Sub-Process (Unterprozess)
  • Task (Aufgabe)

Aktivitäten werden in Standardprozessen und Choreographien genutzt.


BPMN Aktivitaet
BPMN Aktivitaet

Entnommen aus: OMG (2011a), S. 29 / Abb. 3.2: BPMN Aktivität


Schleuse (Gateway): Eine Schleuse wird genutzt um die Divergenz und Konvergenz des Prozessflusses in einem Prozess […] oder einer Choreographie […] zu kontrollieren. Sie bestimmt somit Verzweigungen, Gabelungen, Zusammenführungen und Verbindungen von Pfaden. Interne Marker zeigen an, um welche Schleusenart es sich handelt.


BPMN Schleuse
BPMN Schleuse

Entnommen aus: OMG (2011a), S. 29 / Abb. 3.3: BPMN Schleuse


Prozessfluss (Sequence Flow): Der Prozessfluss wird genutzt um die Reihenfolge darzustellen, in welcher die Aktivitäten in einem Prozesses […] oder einer Choreographie […] ausgeführt werden [Ein Prozessfluss gibt die Richtung des Flusses an und wird als dünne, durchgezogene Linie mit einem gefüllten Pfeilende dargestellt, Anm. d. Autors].


BPMN Prozessfluss
BPMN Prozessfluss

Entnommen aus: OMG (2011a), S. 29 / Abb. 3.4: BPMN Prozessfluss


Nachrichtenfluss (Message Flow): Der Nachrichtenfluss dient der Darstellung des Informationsaustausches zwischen zwei Teilnehmern, welche in der Lage sind, Nachrichten zu senden und zu empfangen […] [Der Nachrichtenfluss wird als gestrichelte, dünne Linie mit einem Pfeilende und einem kleinen Kreis als Quelle dargestellt, Anm. d. Autors].


BPMN Nachrichtenfluss
BPMN Nachrichtenfluss

Entnommen aus: OMG (2011a), S. 29 / Abb. 3.5: BPMN Nachrichtenfluss


Assoziation (Association): Eine Assoziation verbindet Informationen und Artefakte mit den graphischen BPMN-Elementen […]. Textanmerkungen […] und andere Artefakte […] können mit den graphischen Elementen verknüpft werden. Eine Pfeilspitze an einer Assoziation deutet eine eventuelle Flussrichtung (z.B. von Daten) an.“ [43]


BPMN Assoziation
BPMN Assoziation

Entnommen aus: OMG (2011a), S. 29 / Abb. 3.6: BPMN Assoziation


Schwimmbahnen (Swimlanes): „Pools [.] und Lanes repräsentieren Verantwortlichkeiten für Aktivitäten. Ein Pool oder eine Lane können eine Organisation, eine Rolle oder ein System sein.“[44]


BPMN Schwimmbahn
BPMN Schwimmbahn

Entnommen aus: BPMB (2009) / Abb. 3.7: BPMN Schwimmbahn


Datenobjekt (Data Object): Datenobjekte liefern Informationen darüber, was Aktivitäten benötigen um ausgeführt zu werden und/oder was sie produzieren. Datenobjekte können einzelne Objekte oder Sammelobjekte darstellen. Dateninput und Datenoutput liefern dieselben Informationen für Prozesse.


BPMN Datenobjekt
BPMN Datenobjekt

Entnommen aus: OMG (2011a), S. 30 / Abb. 3.8: BPMN Datenobjekt


Nachricht (Message): Eine Nachricht wird genutzt um eine Kommunikation zwischen zwei Teilnehmern darzustellen […].


BPMN Nachricht
BPMN Nachricht

Entnommen aus: OMG (2011a), S.30 / Abb. 3.9: BPMN Nachricht


Gruppierung (Group): Box um eine Objektgruppe derselben Kategorie. […] Eine Gruppierung hat keinen Einfluss auf den Prozessfluss in der Gruppe. Der Kategorie-Name erscheint auf dem Diagramm als Gruppenbezeichnung […] [Darstellung erfolgt in Form von abgerundeten Rechtecken mit gestrichelter Linie, Anm. d. Autors].


BPMN Gruppierung
BPMN Gruppierung

Entnommen aus: OMG (2011a), S. 30 / Abb. 3.10: BPMN Gruppierung


Textanmerkung (Text Annotation): […] Textanmerkungen geben dem Modellierer die Möglichkeit dem Leser des BPMN Diagramms zusätzliche Textinformationen zur Verfügung zu stellen […].“[45]


BPMN Textanmerkung
BPMN Textanmerkung

Entnommen aus: OMG (2011a), S. 30 / Abb. 3.11: BPMN Textanmerkung


2.3.3.2 Erweiterte Modellierungsbausteine

Dieses Kapitel dient der Einführung der wichtigsten erweiterten Modellierungsbausteine in BPMN. Mit diesen Bausteinen können nahezu alle Prozesse detailgetreu abgebildet werden, wodurch ein ziemlich korrektes Abbild der Realität entsteht.


Ereignisse:

Entnommen aus: BPMB (2009) / Tab.-Nr. 2: Erweiterte Modellierungsbausteine: Ereignisse
Entnommen aus: BPMB (2009) / Tab.-Nr. 2: Erweiterte Modellierungsbausteine: Ereignisse


Aktivitäten:

Entnommen aus: BPMB (2009) / Abb.-Nr 3.12: Erweiterte Modellierungsbausteine: Aktivitäten
Entnommen aus: BPMB (2009) / Abb.-Nr 3.12: Erweiterte Modellierungsbausteine: Aktivitäten


Schleusen:

Entnommen aus: BPMB (2009) / Abb.-Nr 3.13: Erweiterte Modellierungsbausteine: Schleusen
Entnommen aus: BPMB (2009) / Abb.-Nr 3.13: Erweiterte Modellierungsbausteine: Schleusen


Choreographien:

Entnommen aus: BPMB (2009) / Abb.-Nr 3.14: Erweiterte Modellierungsbausteine: Choreographien
Entnommen aus: BPMB (2009) / Abb.-Nr 3.14: Erweiterte Modellierungsbausteine: Choreographien


Daten:

Entnommen aus: BPMB (2009) / Abb.-Nr 3.15: Erweiterte Modellierungsbausteine: Daten
Entnommen aus: BPMB (2009) / Abb.-Nr 3.15: Erweiterte Modellierungsbausteine: Daten

2.3.4 Vor- und Nachteile

Vorteile:

  • "Einfache Erkennbarkeit in der Grundstruktur, bei Bedarf aber auch ausreichende Detaillierung
  • Optimale Verbindung zwischen Geschäftsprozessen und IT
  • Besonders gut geeignet für größere Projektteams, die aus Business- und IT-Vertretern bestehen
  • Standardisierung durch OMG"[46]

Nachteile:

  • "Komplexität
  • Schwierig zu erlernen
  • Ausführungsnähe
  • Viele fachliche Aspekte sind nicht berücksichtigt"[47]


2.4 Vergleich

In diesem Abschnitt werden die Modellierungsmethoden anhand verschiedener Parameter gegenübergestellt. Es werden folgende Parameter behandelt:

  • Übersichtlichkeit
  • Anzahl der Bausteine
  • Verantwortlichkeit für Prozesse und Tätigkeiten
  • Eignung als Modellierungsstandard[48]


Es handelt sich bei der Beurteilung der genannten Parameter um rein subjektive Einschätzungen der Autoren.


Übersichtlichkeit: Wie bereits Mehnert (2011) herausgefunden hat, wirken die BPMN Diagramme klarer und strukturierter als jene, die mit EPK modelliert wurden.[49] Ebenso verhält es sich beim Vergleich BPMN – UML. "Verglichen mit den Modellierungskonzepten der UML (für dynamische Aspekte) sind die Ereignisgesteuerten Prozessketten auf eine wohltuende Weise abgehoben. Sie konzentrieren sich auf die Metaebene, den Gesamtzusammenhang des jeweiligen Geschäftsprozesses und sind doch so detailiert, dass mit ihnen ohne Schwierigkeit der Bezug zu weiteren wichtigen Elementen der Unternehmensmodellierung (v.a. Datenbanken, aber auch Oranisationsstrukturen u.a.) hergestellt werden kann."[50]


Anzahl der Bausteine: Die Anzahl der Bausteine in BPMN und EPK ist annähernd gleich. Eine große Abweichung ist hingegen zu UML festzustellen. Es gibt viel mehr Arten der Modelierung, die Sprache ist sehr komplex und ist auf die objekt orientierten Programmiersprache ausgerichtet.


Verantwortlichkeiten für Prozesse und Tätigkeiten: Wir vertreten auch in diesem Punkt die Sichtweise von Mehnert (2011). Mit BPMN lassen sich die jeweiligen Verantwortlichkeiten klar und eindeutig abbilden. Durch die Schwimmbahnen ist immer klar erkennbar, welche Rolle oder Stelle wofür verantwortlich ist. EPK und UML besitzen diese Stärke leider nicht.[51]


Eignung als Modellierungsstandard: Alle Modellierungsformen fordern eine vorherige grundlegende Einarbeitung in das Thema Modellierung. Ohne Einarbeitung wären die Benutzer nicht in der Lage die Methoden korrekt anzuwenden. Die BPMN-Methode besitzt jedoch den Vorteil, „dass die Grundelemente […] weitgehend den bekannten Flussdiagrammen entsprechen“.[52] Auch wenn sich mit diesem Wissen noch nicht gleich ein BPMN-Diagramm modellieren lässt, so kann ein Benutzer ohne Vorkenntnisse ein einfaches Diagramm ohne Probleme verstehen.




Beispieldiagramme:

Entnommen aus: Kruczynski (2008), S. 34 / Abb.-Nr 4.1: Beispieldiagramm EPK: Dienstreiseantrag
Entnommen aus: Kruczynski (2008), S. 34 / Abb.-Nr 4.1: Beispieldiagramm EPK: Dienstreiseantrag


Entnommen aus: Kruczynski (2008), S. 35 / Abb.-Nr 4.2: Beispieldiagramm BPMN: Dienstreiseantrag
Entnommen aus: Kruczynski (2008), S. 35 / Abb.-Nr 4.2: Beispieldiagramm BPMN: Dienstreiseantrag

3 Schluss

"Im Laufe der Zeit entstanden verschiedene Notationen zu Prozessmodellierung. Häufig handelte es sich um proprietäre Notationen spezieller Modellierungstools oder Workflow Management-Systeme. [...] Im Bereich der fachlich orientierten Geschäftsprozessmodellierung wird häufig die Notation der Ereignisgesteuerten Prozesskette (EPK) eingesetzt. Deren Verbreitung erfolgte insbesondere durch das Modellierungswerkzeug ARIS von IDS Scheer und im Umfeld der SAP-Einführung. Allerdings handelt es sich bei der EPK nicht um einen Standard, die Unterstützung durch Modellierungstools anderer Hersteller ist eher gering [...]."[53] "Ereignisgesteuerte Prozessketten eignen sich sehr gut für die Beschreibung standardisierter Abläufe. Diese lassen sich problemlos, wenn einige Regeln beachtet werden, in das lineare und sequenzielle Schema von Ereignisgesteuerten Prozessketten abbilden. Sie sind nicht geeignet für Abläufe, die nicht diesem Schema entsprechen, deren mögiche Wege nur unzureichend vorherbestimmbar sind. Sie sind auch nicht geeignet für kreative oder auch nur komplexe Tätigkeiten. Um hier einsetzbar zu sein, müsste das Instrumentarium der Methode EPK gewaltig erweitert werden, was dann aber ihre Einsetzbarkeit für standardisierte Abläufe wiederum einschränken würde."[54]

"Andere Standards, wie z.B. die Aktivitätsdiagramme der Unified Modeling Language (UML), konnten sich in der Praxis nicht für die Geschäftsprozessmodellierung durchsetzen. Ihr Einsatz blieb weitgehend auf den Bereich des objektorientierten Software-Entwurfs beschränkt, wo die UML der akzeptierte Standard ist.

Mit BPMN (Business Process Model and Notation) scheint sich [..] erstmals ein Standard für die Prozessmodellierung auf breiterer Basis durchzusetzen. [...] Eine Reihe großer Unternehmen bildet ihre im Prozessmanagement tätigen Mitarbeiter in BPMN-Modellierung aus und rollt BPMN als unternehmensweiten Modellierungsstandard aus."[55]

4 Endnoten

  1. Vgl. Staud (2006), S. 7 f.
  2. Becker (2008)
  3. Kremar und Schwarzer (1994), S. 14
  4. 4,0 4,1 Gadatsch (2010), S. 1
  5. Vgl. Staud (2006), S. 2
  6. Staud (2006), S. 59
  7. Gadatsch (2010), S. 188 f.
  8. Seidlmeier (2006), S.12
  9. Staud (2006), S. 62
  10. Vgl. Seidlmeier (2006), S.24
  11. Seidlmeier (2006), S. 26 f.
  12. Staud (2006), S. 60
  13. Seidlmeier (2006), S. 13 f.
  14. Seidlmeier (2006), S. 15
  15. Staud (2006), S. 60
  16. Seidlmeier (2006), S. 15
  17. Staud (2006), S. 64 f.
  18. Seidlmeier (2006), S. 15
  19. Gadatsch (2010), S. 130
  20. Seidlmeier (2006), S.17
  21. Staud (2006), S. 63
  22. Staud (2006), S. 64
  23. Seidlmeier (2006), S. 19
  24. Seidlmeier (2006), S. 20
  25. Staud (2006), S. 66
  26. Staud (2006), S. 66
  27. Seidlmeier (2006), S.21
  28. Seidlmeier (2006), S.21
  29. Allweyer (2005), S. 182
  30. Allweyer (2005), S. 183
  31. Jeckle (2004)
  32. Drost (2003)
  33. 33,0 33,1 33,2 33,3 33,4 33,5 Hering (2003)
  34. Vgl. Balzert (2001)
  35. 35,0 35,1 35,2 Fettke (2009)
  36. Vgl. Stiehl (2009)
  37. Vgl. Allweyer (2009a), S. 10
  38. Allweyer (2009a), S. 10
  39. Vgl. OMG (2011b)
  40. OMG 2008, S. 1
  41. Vgl. Stiehl (2009)
  42. OMG (2011a), S. 27 f. (übersetzt von Dirk Buchholz)
  43. OMG (2011a), S. 29 (übersetzt von Dirk Buchholz)
  44. BPMB (2009)
  45. OMG (2011a), S. 30 (übersetzt von Dirk Buchholz)
  46. Franck und Henninger (2008), S. 15
  47. Allweyer (2010), S. 3
  48. Vgl. Mehnert (2010), S. 11
  49. Vgl. Mehnert (2010), S. 11
  50. Staud (2006), S. 505
  51. Vgl. Mehnert (2010), S. 11
  52. Allweyer (2009b)
  53. Allweyer (2009a), S. 9
  54. Staud (2006), S. 243
  55. Allweyer (2009a), S. 9

5 Verzeichnisse

5.1 Abkürzungsverzeichnis

AbkürzungBedeutung
ARISArchitektur integrierter Informationssysteme
BPMIBusiness Process Management Initiative
BPMNBusiness Process Model and Notation
EDVElektronische Datenverarbeitung
EPKEreignisgesteuerte Prozessketten
OMGObject Management Group
UMLUnified Modeling Language
VDKVorgangskettendiagramm

5.2 Abbildungsverzeichnis

Abb.-Nr.Abbildung
1.1ARIS-Haus
1.2Vorgangskettendiagramm
1.3Ist-Erhebung an einem Beispielprozess
1.4Beispieldarstellung mit Sichteneinteilung
1.5Funktionsbaum
1.6Zieldiagramm
1.7Organigramm mit Organisationseinheiten
1.8einfache EPK
1.9erweiterte EPK
2.1UML Diagrammarten
2.2Anwendungsfalldiagramm
2.3Klassendiagramm
2.4Klassendiagramm
2.5Aktivitätsdiagramm
2.6Sequenzdiagramm
2.7Zustandsdiagramm
3.1BPMN Ereignis
3.2BPMN Aktivität
3.3BPMN Schleuse
3.4BPMN Prozessfluss
3.5BPMN Nachrichtenfluss
3.6BPMN Assoziation
3.7BPMN Schwimmbahn
3.8BPMN Datenobjekt
3.9BPMN Nachricht
3.10BPMN Gruppierung
3.11BPMN Textanmerkung
3.12Erweiterte Modellierungsbausteine: Aktivitäten
3.13Erweiterte Modellierungsbausteine: Schleusen
3.14Erweiterte Modellierungsbausteine: Choreographien
3.15Erweiterte Modellierungsbausteine: Daten
4.1Beispieldiagramm EPK: Dienstreiseantrag
4.2Beispieldiagramm BPMN: Dienstreiseantrag

5.3 Tabellenverzeichnis

Tabellen-Nr.Tabelle
1EPK Notation
2Erweiterte Modellierungsbausteine: Ereignisse

6 Literatur- und Quellenverzeichnis

KurzverweisQuelle
Allweyer (2005)Allweyer, Thomas: Geschäftsprozessmanagement, W3L, Bochum 2005
Allweyer (2009a)Allweyer, Thomas: BPMN 2.0: Business Process Model and Notation: Einführung in den Standard für die Geschäftsprozessmodellierung, 2., aktualisierte und erweiterte Auflage, Books on Demand, Norderstedt 2009
Allweyer (2009b)Allweyer, Thomas: BPMN setzt sich durch in der Praxis, URL http://www.computerwoche.de/software/soa-bpm/1886445/index3.html, 2009 [03.07.2011 15:15]
Allweyer (2010)Allweyer, Thomas: Fachliche Geschäftsprozessmodellierung: Was fehlt der BPMN noch?, URL http://www6.cs.fau.de/events/wedekind75/allweyer.pdf, 2010 [05.07.2011 15:30]
Balzert (2001)Balzert: UML Kompakt, Spektrum Akademischer Verlag, Heidelberg 2001
Becker (2008)Becker, Jörg: Geschäftsprozessmodellierung, URL http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/is-management/Systementwicklung/Hauptaktivitaten-der-Systementwicklung/Problemanalyse-/Geschaftsprozessmodellierung, 2008 [03.07.2011 13:22]
BPMB (2009)o.V., BPM-Offensive Berlin - BPMB (Hrsg.): BPMN 2.0 Poster, URL http://bpmb.de/images/BPMN2_0_Poster_DE.pdf, 2009 [02.07.2011 14:46]
Drost (2003) Drost, Isabelle: Unified Modeling Language (UML), URL http://www.isabel-drost.de/bin/UMLLehrbrief.pdf, 2003 [01.07.2011 19:21]
Fettke (2009) Fettke, Peter: UML-basierte Modellierung, URL http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/is-management/Systementwicklung/Hauptaktivitaten-der-Systementwicklung/Problemanalyse-/Objektorientierte-Modellierung/UML-basierte-Modellierung, 2009 [28.06.2011 19:10]
Franck und Henninger (2008)Franck, Anna-Lena und Henninger, Thomas: BPMN 2008, URL http://www.bpm-guide.de/wp-content/uploads/2008/10/BPMN-2008.pdf, 2008 [01.07.2011 10:23]
Gadatsch (2010)Gadatsch, Andreas: Grundkurs Geschäftsprozess-Management, 6. Auflage, Vieweg+Teubner Verlag, Wiesbaden 2010
Hering (2003) Hering, Phillip B.: Unified Modeling Language (UML), URL http://ebookbrowse.com/uml-ausarbeitung-pdf-d97250807, 2003 [23.06.2011 20:23]
Jeckle (2004)Jeckle, Mario: Unified Modeling Language (UML), URL http://www.jeckle.de/unified.htm, 2004 [03.07.2011 15:33]
Kremar und Schwarzer (1994)Kremar, Helmut und Schwarzer, Bettina: Prozeßorientierte Unternehmensmodellierung, Verlag Gabler, Wiesbaden 1994
Kruczynski (2008)Kruczynski, Klaus: Prozessmodellierung im Wettbewerb: EPK vs. BPMN, URL http://www.wi.htwk-leipzig.de/fileadmin/fbwiwi/Wirtschaftsinfo/Publikationen/2008/Prozessmodellierung2.pdf, 2008 [03.07.2011 13:55]
Mehnert (2010)Mehnert, Michael: Einführung in die Geschäftsprozessmodellierung mit BPMN und Vergleich zu EPK, 1. Auflage, Grin Verlag, München 2010
Nakhla (2011) Nakhla, Fuad: Graphische Modellierungstechniken, URL http://ddi.in.tum.de/fileadmin/material/Lehrveranstaltungen/06/DDI1/UML.pdf, 2011 [01.07.2011 22:39]
OMG (2008)o.V., Object Management Group (Hrsg.): Business Process Model and Notation (BPMN) V1.1, URL http://www.omg.org/spec/BPMN/1.1/PDF/, 2008 [21.06.2011 12:24]
OMG (2011a)o.V., Object Management Group (Hrsg.): Business Process Model and Notation (BPMN) Version 2.0, URL http://www.omg.org/spec/BPMN/2.0/PDF/, 2011 [21.06.2011 15:31]
OMG (2011b)o.V., Object Management Group (Hrsg.): Business Process Model and Notation (BPMN), URL http://www.omg.org/spec/BPMN/index.htm, 2011 [21.06.2011 17:45]
Oose (2011) o.V., Oose.de (Hrsg.): UML Notation, URL http://www.oose.de/downloads/uml-2-Notationsuebersicht-oose.de.pdf, 2011 [28.06.2011 18:00]
Seidlmeier (2006)Seidlmeier, Heinrich: Prozessmodellierung mit ARIS, 2. Auflage, Vieweg & Sohn Verlag, Wiesbaden 2006
Staud (2006)Staud, Josef: Geschäftsprozessanalyse: Ereignisgesteuerte Prozessketten und objektorientierte Geschäftsprozessmodellierung für Betriebswirtschaftliche Standardsoftware, 3. Auflage, Springer Verlag, Berlin 2006
Stiehl (2009)Stiehl, Volker: Vermittler zwischen den Welten, URL http://it-republik.de/jaxenter/artikel/BPMN---Vermittler-zwischen-den-Welten-2531.html, 2009 [21.06.2011 14:17]
Wolters und Kaschny (2010)Wolters, Matthias und Kaschny, Martin: Geschäftsprozessmanagement in KMU, Band 1, Josef Eul Verlag, Köln 2010
Persönliche Werkzeuge