Grundlagen der Modellierung - Prozess- und Ablauf- und Geschäftsprozessmodellierung
Prozess-, Ablauf- und Geschäftsprozessmodellierung
Petri-Netze
Im Jahr 1939 wurden von Carl Adam Petri die Petri-Netze Entwickelt um seine Kenntnisse chemischer Prozesse anschaulich zu machen. Im Jahr 1941 begann er dann damit seine neue Modellierungsform zu erweitern, um ein strukturiertes Modell zur Formulierung und Lösung der spezifischen Problemstellungen von Computersystemen zur Verfügung zu stellen. Als Entwicklungsgrundlage der Petri-Netze dienten auch die Zustandsautomaten. (Reisig, 2010, S. IX)
Mit einem Petri-Netz werden diskrete Systeme abgebildet. Das bedeutet, dass das System und seine Abläufe und Zustände von einem bestimmten Zeitpunkt abhängig sind. Weiter ermöglichen sie die Modellierung und Abbildung verteilter Systeme.
Aufbau eines Petri-Netzes
Ein Petri-Netz besteht aus einem oder mehreren Abläufen, welche immer eine zeitliche Abhängigkeit und einen bestimmten Zustand haben. Der Zustand wird hierbei jedoch in Form von Token abgebildet, welche immer von einem Platz zum nächsten weitergereicht werden können. Die grundlegenden Elemente eines Petri-Netzes sind (Reisig, 2010, S. 22ff):
- Plätze, welche als Kreis oder Ellipse dargestellt werden,
- Transitionen, welche als Quadrate oder Rechtecke dargestellt werden,
- Kanten, die als Pfeile dargestellt werden, und
- Token, welche entweder als ausgefüllter Punkt, oder als bestimmtes Element, abgebildet werden.
Ein wesentliches Element sind die Token. Sie befinden sich an bestimmten Plätzen und werden an verarbeitende Stellen, die Transitionen, weitergeben. Diese erzeugen wiederum neue Token und legen diese wiederum an Plätzen ab. In manchen Modellteilen kann es daher so aussehen, als würden die Transitionen Token „weitergeben“, sofern derselbe Token-Typ, in gleicher Anzahl in die Transition eingeht und sie wieder verlässt. Tatsächlich handelt es sich jedoch immer um eigene eingehende und ausgehende Token.
In der Abbildung "einfaches Petri-Netz" ist ein einfaches Petri-Netz dargestellt, welches einen einfachen Token vom Platz A über die Transition b zum Platz C weiterreicht.
Nach einem Ablaufschritt wurde der Token dann „weitergereicht“ und befindet sich am Platz C. Konkret hat jedoch die Kante zwischen A und b zu einer Entnahme des Tokens aus A geführt. Die Transition b wurde nun dadurch ausgelöst und hat, angeleitet durch die Kante zwischen b und C einen neuen Token am Platz C abgelegt. Dies ist nachfolgend in der Abbildung "einfaches Petri-Netz zum Zeitpunkt t+1" wieder grafisch dargestellt.
Diese ersten beiden Beispiele nutzen die einfachste Form von Token, ohne spezielle Ausprägung. Dieser Form eines Petri-Netzes wird als elementares Netz bezeichnet.
Es ist auch möglich die Token selbst mit einem bestimmten Typ zu versehen. Damit können die verarbeitenden Transitionen von ganz bestimmten Token abhängig gemacht werden. Wenn es beispielsweise einen Token-Typ „Kaffeetasse“ und einen Token-Typ „Kaffeebohne“ gibt, kann eine Transition auch von der Existenz beider bestimmter Typen im vorhergehenden Platz abhängig gemacht werden, um dann wiederum einen Token vom Typ „volle Kaffeetasse“ im nachfolgenden Platz abzulegen. Wenn mehrere Token-Typen unterschieden werden, dann muss die zuständige Kante auch mit den weiterzugebenden Token beschriftet werden. Im nachfolgenden Beispiel, in der Abbildung "einfaches Petri-Netz einer Kaffeezubereitung", ist ein simpler Ablauf einer Kaffeezubereitung in Form eines sehr einfachen Petri-Netzes abgebildet. Grundvoraussetzung ist hierbei, dass sich genügend Kaffeebohnen und leere Tassen im Platz „Küchenschrank“ befinden. Erst wenn die Token der Kante vorhanden sind, wird die Transition „Kaffeezubereitung“ gestartet, welche wiederum eine „volle Kaffeetasse“ im Platz „Küchentisch“ ablegt. Die Token sind, der Einfachheit halber, in Form von Piktogrammen dargestellt.
In diesem Modell wird nun eine Bohne und eine Tasse aus dem Platz „Küchenschrank“ durch die Bedingung der Kante entnommen und an die Transition „Kaffeezubereitung“ übergeben. Diese wiederum generiert eine volle Kaffeetasse und legt sie in den Platz „Küchentisch“. Nach der Abarbeitung befindet sich damit im Platz „Küchenschrank“ eine Kaffeebohne und im Platz Küchentisch eine „volle Kaffeetasse“.
Eine Transition kann sowohl mehrere eingehende, als auch mehrere ausgehende Kanten haben. Um die Aktion der Transition auszulösen, müssen immer alle eingehenden Kanten erfüllt sein. Erst wenn alle nötigen Kanten erfüllt werden, werden auch die vorausgesetzten Token der vorangehenden Plätze entnommen. Wird nur ein Teil der eingehenden Kanten erfüllt, bleiben somit alle Token in den Plätzen liegen, bis sie dann gemeinsam entnommen werden können. In der Abbildung "einfaches Petri-Netz einer Kaffeezubereitung mit mehreren Startplätzen" wurde das Beispiel der Kaffeezubereitung nun um einen zweiten eingehenden Platz „Kaffeedose“ erweitert, welcher nun die Bohnen enthält.
Damit ein Nachfüllen der Tassen und Bohnen, sowie die Entnahme des fertigen Kaffees möglich sind, werden nun eigene eingehende Transition eingeführt, welche eine Interaktion des Systems mit äußeren Einflüssen erlauben. Diese Transitionen nennt man kalte Transitionen. Es wird generell zwischen heißen und kalten Transitionen unterschieden. Eine heiße Transition wird einem System immer automatisch aktiv, sobald ihre Vorbedingungen erfüllt sind. Eine kalte Transition ist zusätzlich noch von äußeren Bedingungen abhängig und wird somit nicht automatisch aktiv. Zur besseren Kennzeichnung werden kalte Transitionen mit dem Zeichen „ε“ [1] gekennzeichnet, was wiederum auf ihren externen Charakter hinweisen soll.
Nachfolgend, in der Abbildung "Petri-Netz „Kaffeezubereitung“ mit ein-/ausgehenden Transitionen", wurde das Modell der Kaffeezubereitung nun um das Nachfüllen der Kaffeebohnen und Kaffeetassen, sowie um die Entnahme des fertigen Kaffees vom Küchentisch erweitert.
In dem Beispiel würde immer so viel Kaffee gekocht wie, aufgrund der verfügbaren Kaffeetassen und Kaffeebohnen möglich ist. Die Entnahme der fertigen Kaffees aus dem Platz „Küchentisch“ ist möglich, tritt jedoch nicht sicher ein. Wird die Transition „Kaffee trinken“ nicht von außen abgerufen, so füllt sich der Küchentisch immer weiter an.
Eine weitere mögliche Anwendung von Transitionen und Kanten ist die Angabe einer zusätzlichen Bedingung. Diese kann den Inhalt eines übergebenen Token prüfen und verhält sich damit wie eine Variablenabfrage, wobei der Token die Variable darstellt. Damit lassen sich beispielsweise auch Zähler abbilden. Die Bedingung wird dazu in das Transition-Symbol geschrieben und muss zusätzlich zu den eingehenden Kanten erfüllt werden.
Um die Anwendung von Bedingungen in Transitionen zu erläutern wurde das Kaffeezubereitungsbeispiel nun um einen Hinweis zu Entkalkung der Kaffeemaschine erweitert, der nach 100 zubereiteten Kaffees auftreten, und dann nach der Bestätigung des Hinweises durch die Serviceperson wieder auf 0 gesetzt werden, soll.
Da die Geschwindigkeit der Ausführung der Transitionen nicht einheitlich ist, wird im aktuellen Beispiel die asynchrone Abarbeitung des Petri-Netzes deutlich. So kann die Transition „Kaffeezubereitung“ natürlich auch mehr Zeit in Anspruch nehmen, als die simple Transition „Zähler ausführen“. Durch das Auslösen der Transitionen mittels Token, wird eine Verteilung der Aufgaben erreicht, welche zwar parallel jedoch nicht unbedingt synchron abgearbeitet werden. Da es sich bei Transitionen immer um Aktionen handelt, welche asynchron laufen, darf eine Transition nie direkt eine Kante zu einer anderen Transition haben, da dadurch eine direkte Abhängigkeit entstehen würde. Auch darf im Gegenzug kein Platz eine direkte Kante zu einem anderen Platz haben, da ohne Transition nicht klar wäre, in welchem Platz sich ein Token dann befinden würde.
Berechnungen und Plätze mit Zahlenwerten
Zusätzlich zur einfachen Entnahme und Generierung von Token können Kanten auch Berechnungen mit der Token Anzahl des zugehörigen Platzes durchführen. Die Funktionsweise und Darstellung dieser Rechenmöglichkeiten sind nun nachfolgend, anhand eines einfachen Modells mit zwei Plätzen, einer Transition und den zugehörigen Kanten, genauer beschrieben.
Den Plätzen A und B in Abbildung 40 können durch ihre zugehörigen Kanten und die Transition b Token entnommen und hinzugefügt werden. Dies geschieht normalerweise in Richtung der Pfeile. Eine Kante mit einem Pfeil in Richtung des Platzes legt einen Token in dem Platz ab und eine Kante mit einem vom Platz wegzeigenden Pfeil entnimmt einen Token aus dem Platz.
Wenn ein Platz nur einen Standardtyp von Token enthält, kann er auch als Wert geschrieben werden. In der Abbildung "Plätze mit der Token Anzahl in Werte Schreibweise" noch einmal das vorherige Beispiel in der Schreibweise als Werte.
Es ist nicht relevant, ob ein Platz als Oval, oder als Kreis gezeichnet wird. Bei der Darstellung der Token Anzahl als Zahl ist ein runder Platz ausreichend und platzsparender. In der Abbildung "Runde Plätze mit der Token Anzahl in Werte Schreibweise" ist noch einmal dasselbe Modell mit runden Plätzen dargestellt.
Durch die Angabe einer Formel mit einer Variable, können Berechnungen mit dem
Wert (der Token Anzahl) des Platzes durchgeführt werden. Die Variable (z.B. x) steht dabei für den aktuellen Wert des zugehörigen Platzes. In der Abbildung "Berechnungen durch Formelangaben der Kanten" wird durch die Ausführung der Transition b die Token Anzahl von A um zwei Reduziert und die Token Anzahl von C um 5 erhöht. Die Kante zwischen A und c ist dabei die Vorbedingung zur Ausführung der Transition. Sind nicht genügend Token in A um die Berechnung durchzuführen, wird sie auch nicht ausgeführt. Nach der Ausführung des Beispiels hat der Platz A den Wert 0 und der Platz C den Wert 5.
Diese Berechnungen müssen jedoch nicht zwingend der Pfeilrichtung entsprechen. Die Pfeilrichtung bezieht sich bei einer Formel nur auf die Auslösung der Transition (Pfeil zur Transition löst sie aus. Pfeil weg von der Transition geschieht durch die Auslösung). Ein Beispiel einer Token Entnahme entgegen der Pfeilrichtung ist in Abbildung 44 dargestellt. Dabei werden bei Erfüllung der Kante zwischen A und b jeweils fünf Token von C abgezogen. Nach Ausführung des Beispiels hat somit A den Wert 0 und C den Wert 5.
Der Wert (=Token Anzahl) eines Platzes darf nicht negativ sein. Wäre der Wert des Platzes C hier nicht 10, sondern kleiner als 5, dann wäre das ein Fehler. Dieser kann jedoch, wie nachfolgend beschrieben, durch eine zusätzliche Bedingung in der Transition verhindert werden.
Soll der Wert eines Platzes an eine Bedingung übergeben werden, erfolgt dies durch eine eigene Kante die nur den Variablennamen (z.B. x) enthält. Diese Kante führt keine Änderung an dem Wert des Platzes durch, sondern übergibt nur den Wert an die Transition. Das Modell aus der Abbildung "Berechnungen durch Formelangaben der Kanten entgegen der Pfeilrichtung" wurde in der Abbildung "Bedingung einer Transition mit Übergabe des Wertes eines Platzes" um eine Bedingung erweitert, welche überprüft, ob der Wert des Platzes C größer oder gleich 5 ist, um einen möglichen Fehler bei der Ausführung der Transition zu verhindern. Der Wert des Platzes C wird dazu durch eine eigene Kante mit der Variable y an die Bedingung der Transition b übergeben.
Abbildung verteilter Systeme
Durch die Anwendung von kalten und warmen Transitionen können Systemgrenzen und Schnittstellen definiert werden. Im Fall eines verteilten Systems können damit nun asynchrone Abhängigkeiten zwischen einzelnen Systemen modelliert werden. Um ein Beispiel für eine solche Schnittstelle zu schaffen wird nachfolgend, in der Abbildung "Petri-Netz „Geschirrspülen“", ein einfaches Modell eines Geschirrspülers entwickelt, welches dann mit dem Petri-Netz der Kaffee Zubereitung kombiniert wird.
Nun wird das Petri-Netz des Geschirrspülens mit dem der Kaffeezubereitung kombiniert. Die Nahtstellen sind dabei die kalte Transition „Schmutzige Tasse einfüllen“ und „Kaffee trinken“, sowie „Tasse nachfüllen“ und „Saubere Tasse entnehmen“. Da eine Transition nicht direkt in eine andere Transition übergehen kann, sonst wären die Vorgänge synchron und damit nur eine einzige Transition, muss dazwischen jeweils ein eigener Platz definiert werden, an dem sich die Tassen befinden, solange die „abholende“ Transition noch nicht bereit ist. Die Kombination der beiden Systeme ist nun nachfolgend in der Abbildung "Kombiniertes Petri-Netz „Kaffeekochen und Geschirrspülen“" dargestellt.
Geschäftsprozessmodellierung
Ergänzend zu den bereits betrachteten Modellen der Prozess- und Ablaufmodellierung gibt es noch einige spezielle Geschäftsprozessmodelle. In dieser Lektion werden nun die Grundlagen von zwei der diesbezüglich wichtigsten Modelle erläutert. Diese Modelle dienen der organisatorischen Betrachtung von Geschäftsprozessen und werden auch von Nicht-Technikern eingesetzt. Sie dienen oft auch als gemeinsame Basis bei der Spezifikation der Anforderungen von IT-Systemen und ihrer Unterstützung der Geschäftsprozesse.
Ereignisgesteuerte Prozessketten (EPK)
Die Ereignisgesteuerten Prozessketten (EPK) wurden 1992 durch Keller, Nüttgens und Scheer entwickelt. Sie wurden von den Petri-Netzen abgeleitet und dienen der prozessorientierten Modellierung von Geschäftsprozessen. Sie sind Teil des Rahmenkonzeptes der Architektur integrierter Informationssysteme (ARIS) und dort im Bereich der Steuerungssicht angesiedelt. Zusätzlich zu den Prozessabläufen ermöglichen Sie in ihrer aktuellen Version auch direkte Verbindungen zur Daten- und Funktionssicht. Das ARIS-Konzept selbst wurde entwickelt, um die Vielzahl unterschiedlicher Methoden der Anwendungsentwicklung und Unternehmensentwicklung zu strukturieren. (Keller G., 1992, S. 3f)
Die "Ereignisgesteuerte Prozeßkette" stellt den zeitlich-logischen Ablauf von Funktionen und eine Verknüpfung der Elemente des Daten- und des Funktionsmodells dar. Sie ist somit eine zentrale Komponente innerhalb der Informationsmodellierung. (Keller G., 1992, S. 15)
Aufbau einer EPK
Eine EPK besteht aus Elementen, Pfaden und Operatoren. Der Prozess wird durch die möglichen Pfade beschrieben, welche zu Elementen hin und von ihnen weg führen. Mittels Operatoren können diese Pfade geteilt, parallelisiert und auch wieder zusammengeführt werden.
Die möglichen Elemente einer einfachen EPK sind:
- Ereignisse und
- Funktionen.
Ein Ereignis stellt dabei einen eingetretenen Zustand dar und ist damit eine passive Komponente des Systems. Funktionen werden von Ereignissen ausgelöst und damit gestartet. Sie können wiederum Ereignisse auslösen und so weiter. Eine Funktion stellt dabei eine bestimmte Tätigkeit dar, welche für den Prozess ausgeführt wird. Das bedeutet auch, dass auf ein Ereignis niemals ein Ereignis und auf eine Funktion keine Funktion folgen kann. (Keller G., 1992, S. 10f)
Die Pfade des Kontrollflusses werden als gestrichelte Linie dargestellt. Der Kontrollfluss entspricht dabei dem Prozessablauf. Pfade des Datenflusses werden durch durchgehende Linien repräsentiert. Dabei handelt es sich um die Verbindung von Informationsobjekten und Organisationseinheiten zu den Funktionen, welche später im Abschnitt 4.1.2 genauer beschrieben werden. Die grafische Darstellung von einem Ereignis, welches eine Funktion auslöst ist in der Abbildung "EPK: Ereignis und Funktion" dargestellt.
Der Prozessablauf wird über einen Token-Ansatz abgearbeitet. Das bedeutet, dass immer ganz bestimmte Teilpfade des Kontrollflusses aktiv sind, wobei es möglich ist, eine parallele Ausführung mehrerer Pfade durchzuführen, indem der aktuelle Token auf mehrere Teilpfade aufgeteilt wird. Ein Zusammenführen oder Synchronisieren mehrerer Pfade zu einem einzigen Pfad ist ebenfalls möglich. Diese Teilung und Zusammenführung erfolgt über logische Operatoren. Folgende Operatoren sind dabei möglich:
- exklusiver Oder-Operator (XOR),
- inklusiver Oder-Operator (OR) und
- Und-Operator (AND).
Die Darstellung der logischen Operatoren erfolgt mittels Kreissymbol mit dem jeweiligen Typ darin. Die Darstellungsformen der Operatoren-Typen sind in der Abbildung "EPK: Operatoren" angeführt.
Beim exklusiven Oder-Operator wird genau einer der Pfade ausgewählt und der Prozessfluss dort weitergeführt. Bei einem inklusiven Oder-Operator wird der Prozesspfad an einem oder mehreren möglichen Pfaden fortgesetzt. In beiden Fällen ist der eingeschlagene Weg von dem Eintreten des nachfolgenden Ereignisses abhängig. Ein Oder-Operator darf daher nur von einer Funktion weg zu mehreren Ereignissen führen aber nicht von einem Ereignis zu mehreren Funktionen. Anderenfalls wäre nicht eindeutig unter welchen Umständen (Ereignis) welcher Pfad gewählt werden soll.
Der Und-Operator kann sowohl nach einem Ereignis, als auch nach einer Funktion eingesetzt werden. Er teilt immer den aktuellen Pfad in mehrere parallel ausgeführte Pfade. Es ist somit damit auch möglich durch ein einzelnes Ereignis mehrere Funktionen auszulösen.
Werden die Operatoren für die Zusammenführung mehrerer Kontrollflüsse verwendet, gilt die oben beschriebene Logik ebenfalls. So werden beim inklusiven Oder-Operator mehrere Pfade zu einem zusammengeführt und beim exklusiven Oder-Operator einer aus mehreren Pfaden fortgesetzt. Beim Und-Operator wird abgewartet, bis alle eingehenden Kontrollflüsse vorhanden sind und dann mit dem ausgehenden Kontrollfluss fortgesetzt. Er kann daher für die Synchronisierung mehrerer Abläufe verwendet werden. Sollen mehrere Prozessflüsse an einer Stelle synchronisiert werden, jedoch getrennt weiterlaufen, kann dies mit zwei aufeinander folgenden Und-Operatoren geschehen. Diese Vorgehensweise ist im Beispiel in der Abbildung "EPK: Synchronisation mehrerer paralleler Kontrollflüsse" dargestellt.
Um in einer EPK die Ausführung eines Sub-Prozesses anzustoßen werden Prozesswegweiser eingesetzt. Diese ermöglichen die Auslagerung von komplexeren oder mehrfach genutzten Prozessteilen in eigene Prozesse. Der Prozesswegweiser repräsentiert dabei immer die komplette Ausführung des Sub-Prozesses. Das bedeutet, dass nach seinem Aufruf auf die Abarbeitung des aufgerufenen Prozesses gewartet, und der Prozessfluss danach hinter dem Prozesswegweiser wieder fortgesetzt wird. Das Symbol eines Prozesswegweisers ist das einer Funktion mit einem dahinter befindlichen Ereignis. Er wird als Funktionsaufruf behandelt und daher immer von einem Ereignis aufgerufen. Weiter folgt ihm auch immer ein Ereignis nach. Der Aufruf eines Prozesswegweisers ist in der Abbildung "EPK: Prozesswegweiser" dargestellt.
Erweiterte Ereignisgesteuerte Prozessketten (eEPK)
Die erweiterten Ereignisgesteuerten Prozessketten (eEPK) sind eine direkte Ergänzung der EPK um weitere Elemente. Dadurch ist es möglich das Prozessumfeld und Zuständigkeiten genauer zu beschreiben.
Die wesentlichen Zusatzelemente sind:
- Organisationseinheiten und
- Informationsobjekte.
Die Zusatzelemente werden mittels Informationspfaden, welche als Pfeile mit durchgehenden Linien gezeichnet werden, mit den zugehörigen Funktionen verbunden. Sie sind damit genau diesen Funktionen zugeordnet.
Die Organisationseinheiten repräsentieren die Prozessteilnehmer, welche die zugehörige Funktion durchführen. Prozessteilnehmer können bestimmte Organisationseinheiten oder Funktionen eines Unternehmens sein. Sie werden als Oval mit einem innenliegenden vertikalen Strich an der linken Seite gezeichnet und beinhalten den Namen des Prozessteilnehmers.
Informationsobjekte dienen der Darstellung von Daten, welche von der zugehörigen Funktion genutzt oder erstellt werden. Als Daten gelten hier jedoch alle Arten von Informationen, auch wenn sie nicht in elektronischer Form vorliegen. Die Darstellung eines Informationsobjektes geschieht in Form eines Rechtecks mit spitzen Ecken (im Gegensatz zu den abgerundeten Ecken der Funktion).
Eine Funktion mit zugehörigen Daten und einer Organisationseinheit ist in der Abbildung "eEPK: Organisationseinheit und Informationsobjekt" dargestellt.
Objektorientierte Ereignisgesteuerte Prozessketten (oEPK)
Bei den objektorientieren Ereignisgesteuerten Prozessketten handelt es sich um eine andere Form der Herangehensweise an die Modellierung. Im Gegenzug zur herkömmlichen, rein prozessbezogenen Betrachtung, überwiegt hierbei der Objektbezug. Das bedeutet insbesondere eine Definition von Objekten und ihrer Interaktionen. Die Geschäftsprozesse werden hierbei über die Abbildung der Objekte und ihrer Interaktion mittels ereignisgesteuerter Nachrichten realisiert. Die in dieser Form modellierten Objekte können daher auch als Geschäftsobjekte bezeichnet werden. (Scheer, Nüttgens, & Zimmermann, Objektorientierte Ereignisgesteuerte Prozeßkette (oEPK) - Methode und Anwendung, 1997, S. 16ff)
Zuerst werden die einzelnen Objektklassen modelliert, welche selbst Variablen und Methoden enthalten können. Für den Nachrichtenaustausch werden den Objekten weiter Ereignisse zugewiesen, welche dann im Prozessfluss verwendet werden können.
Zur Definition einer Objektklasse wird ein, vom EPK Prozessfluss getrenntes, Modell erstellt, welches die Objektklasse und ihre zugehörigen Funktionen und Instanzvariablen beinhaltet. Weiter werden alle möglichen Ereignisse angeführt, die von der Objektklasse ausgelöst werden können. Das Symbol der Instanzvariablen ist ein Rechteck, welches links und rechts mit einem Halbkreis abgeschlossen wird. Sie repräsentieren die Daten des Objektes. Die Funktionen des Geschäftsobjektes können auch als Methoden bezeichnet werden. Eine mögliche Modellierung einer oEPK Objektklasse ist in der Abbildung "oEPK: Modell einer Objektklasse" dargestellt.
Die Einbindung der Objektklasse in eine EPK geschieht direkt über das Objektklassen-Symbol. Es wird dabei wie eine Funktion eingesetzt, wird von Ereignissen aufgerufen und kann wiederum selbst Ereignisse auslösen. Die einzelnen Funktionen, Instanzvariablen und Ereignisse des Objektes werden hier nur angeführt, wenn sie an der jeweiligen Position der EPK gerade verwendet werden. Alle übrigen Komponenten werden ausgeblendet. Es werden daher auch nur die Folgeereignisse angeführt, welche an dieser Position ausgelöst werden können.
Beispiel einer eEPK
Im Beispiel, in der Abbildung "eEPK Beispiel einer Kaffeeküche", soll der Prozess einer Kaffeezubereitung in einer Büroküche modelliert werden. Die Teilnehmer des Prozesses sind alle Mitarbeiter der Abteilung und ein Service-Verantwortlicher. Sobald ein Mitarbeiter einen Kaffee möchte, prüft er zuerst ob die Kaffeemaschine korrekt funktioniert. Ist dies der Fall, sucht er sich einen Kaffee (Espresso, Ristretto oder Lungo) aus und bereitet diesen zu. Nach der Zubereitung trinkt er den Kaffee und hat seinen Kaffeebedarf damit gestillt. Sollte die Kaffeemaschine nicht funktionieren, informiert er den für das Service verantwortlichen Kollegen. Dieser setzt die Kaffeemaschine wieder in Stand und informiert anschließend wieder die Mitarbeiter der Abteilung.
Business Process Model and Notation (BPMN)
Die Business Process Model and Notation (BPMN) wurde ursprünglich von Stephen A. White entwickelt und 2004 von der Business Process Management Initiative (BPMI) veröffentlicht. Seit Februar 2011 gibt es die BPMN nun in ihrer aktuellen Version 2.0, welche offiziell von der Object Management Group (OMG) verabschiedet und publiziert wurde. BPMN dient der Modellierung von Prozessen und kann daher andere Strukturen, wie eine übergeordnete Prozesslandschaft und Ablauforganisationen, nicht abbilden. (Freund & Rücker, 2014, S. 8f, 22)
Alle Elemente und der Aufbau von BPMN 2.0 sind in der zugehörigen, 538 Seiten langen, Spezifikation (Object Management Group (OMG), 2011) genau definiert. Nachfolgend werden nun die davon wichtigsten Grundaspekte erläutert.
Aufbau der BPMN
Die BPMN kann in fünf Hauptelementtypen gegliedert werden (Freund & Rücker, 2014, S. 23):
- Flussobjekte,
- verbindende Objekte,
- Artefakte,
- Teilnehmer und
- Daten.
Die Flussobjekte beschreiben alle Entscheidungen, Aktivitäten und Ereignisse. Sie werden selbst wiederum über die verbindenden Objekte vernetzt und mit Hilfe der Artefakte beschrieben. Ergänzend können dann noch die Teilnehmer und relevanten Daten des Prozesses in das Modell eingefügt werden.
Generell wird, ähnlich wie bei den EPK, ein Token-Ansatz verwendet. Der Prozessfluss findet also entlang des definierten Pfades statt, welcher von einem Token durchlaufen wird. Dieser kann wiederum in mehrere parallele Token geteilt und umgekehrt wiederum zu einem einzelnen zusammengeführt werden.
Die möglichen Flussobjekte sind
- die Aktivität,
- das Event und
- das Gateway.
Die grafische Darstellung der Flussobjekte ist in der Abbildung "BPMN Flussobjekte" ersichtlich.
Die Aktivität beschreibt dabei eine konkrete Tätigkeit, die bei ihrem Aufruf durchgeführt wird. Diese kann in komplexeren Modellen wiederum selbst aus Unteraktivitäten bestehen. Auf diese Form der weiteren Untergliederung wird hier jedoch nicht weiter eingegangen. Eine Aktivität hat immer eine Bezeichnung und kann zusätzlich eine bestimmte Ausprägung haben. Diese wird in der linken oberen Ecke in Form eines Symbols angezeigt. Aktivitäten werden oft auch als Aufgaben bezeichnet, wenn sie selbst nicht mehr in Teilaufgaben teilbar sind. Ein Beispiel hierfür wäre die Zubereitung eines Kaffees mit einer Kaffeemaschine. Das „Zubereiten eines Espressos“ wäre eine Aktivität, da sie auch weiter in „Tasse unterstellen“ und „Espressotaste drücken“ geteilt werden könnte. Der Druck auf die Espressotaste hingegen wäre eine Aufgabe, da sie nicht weiter teilbar ist.
Eine Aktivität ohne spezielle Ausprägung wird als abstrakt bezeichnet. Die unterschiedlichen Ausprägungen und ihre Symbole sind in der Abbildung "BPMN Aktivitäten mit Ausprägung" aufgelistet und beschrieben.
| Aktivitätsausprägung | Symbol | Beschreibung |
|---|---|---|
| Service-Aktivität | wird durch ein automatiches System durchgeführt | |
| Sende-Aktivität | führt das Senden einer Nachricht durch (Erstellung und Versand) | |
| Empfangs-Aktivität | führt das Empfangen einer Nachricht durch (Empfang und Verarbeitung) | |
| Benutzer-Aktivität | wird durch einen oder mehrere Menschen durchgeführt | |
| Manuelle-Aktivität | wird durch einen oder mehrere Menschen manuell und ohne IT Unterstützung durchgeführt | |
| Geschäftsregel-Aktivität | führt eine BPMN Geschäftsregel aus (wird in dieser Lektion nicht weiter behandelt) | |
| Script-Aktivität | führt ein Script innerhalb der Prozessumgebung aus (wird in dieser Lektion nicht weiter behandelt) |
BPMN Aktivitäten mit Ausprägung (Object Management Group (OMG), 2011, S. 385, 430)
Weiter ist es möglich, über eine Aktivität einen Sub-Prozess aufzurufen. Damit kann das Modell vereinfacht und mehrfach ausgeführte Prozessabläufe zusammengefasst werden. Ein Sub-Prozess wird durch ein kleines Quadrat mit einem Pluszeichen in der Mitte des unteren Bereiches der Aktivität dargestellt. Der Inhalt des Sub-Prozesses wird in Form eines eigenen Pools modelliert, welcher in diesem Abschnitt weiter unten genauer beschrieben wird. Ein Beispiel für einen Sub-Prozess Aufruf ist in der Abbildung "BPMN Sub-Prozesses Aufruf" dargestellt.
Ein Event ist ein bestimmtes Ereignis, welches eintreten und ausgelöst werden kann. Es kann dabei sowohl von außerhalb ausgelöst werden, als auch durch den modellierten Prozess selbst. Dabei wird zwischen Start-, Zwischen- und End-Events unterschieden. Ein Start-Event ist ein Ereignis, welches außerhalb des modellierten Prozesses ausgelöst wird und damit einen Einfluss auf einen Teil des Prozesses von außen hat. Start-Events werden daher auch zum Start des Prozesses eingesetzt. End-Events beenden einzelne Abläufe des Prozesses. Ist kein Teil des Prozesses mehr aktiv, da jeder Pfad in einem End-Event geendet hat, ist damit der gesamte Prozess beendet. Eine Ausnahme ist hierbei das End-Event vom Typ Terminierung, welches bei seinem Aufruf den gesamten Prozess beendet. Weiter gibt es noch Events, welche innerhalb des Prozesses ausgelöst werden und wiederum einen anderen Teil des eigenen Prozesses beeinflussen. Diese Events werden als Zwischen-Events bezeichnet.
Je nachdem um welchen Event Typ es sich handelt wird die Umrandung des Kreises anders dargestellt. Die unterschiedlichen Event-Typen sind in der Abbildung "BPMN Event-Typen" dargestellt.
Der Start eines Prozessflusses wird immer durch ein oder mehrere Start-Events begonnen und durch ein oder mehrere End-Events beendet.
Zusätzlich kann der Typ eines Events durch einen zugehörigen Auslöser oder ein Resultat beschrieben werden. Die wichtigsten Auslöser oder Resultate sind:
- Nachricht,
- Signal,
- Timer,
- Bedingung,
- Verknüpfung und
- Terminierung.
Bei einer Nachricht handelt es sich um eine Benachrichtigung von außen an den Prozess oder umgekehrt, sowie möglicher Benachrichtigungen zwischen Aktivitäten. Signale sind, im Gegensatz zu Nachrichten, Benachrichtigungen welche ohne bestimmte Empfänger an alle gerichtet sind, die sie auffangen können. Timer erlauben, zwischen den Aktivitäten ein bestimmtes Zeitintervall oder einen Zeitpunkt abzuwarten und Start-Events in einem bestimmten Intervall oder Zeitpunkt zu starten. Bei Bedingungen handelt es sich um Events, welche unter einer bestimmten Bedingung ausgeführt werden oder auf eine bestimmte Bedingung warten. Bei den Verknüpfungen handelt es sich um einen Sonderfall von Events, welche eine grafische Möglichkeit darstellen den Prozessfluss innerhalb des Diagramms zu unterbrechen und an einer anderen Stelle fortzusetzen. Dabei ist es wichtig, die Verknüpfung an beiden Stellen im Diagramm gleich zu benennen. Die Terminierung beendet den gesamten Ablauf unmittelbar nach ihrem Eintreten, egal ob noch parallele Aktivitäten offen sind, oder nicht.
In Tabelle 7 findet sich eine Tabelle der wichtigsten Symbole der Auslöser und Resultate und in welchen Event-Typen ihre Verwendung zulässig ist.
Tabelle 7 – BPMN Event Auslöser und Resultate (Object Management Group (OMG), 2011, S. 261)
| Symbol | Zulässig als Start-Event | Zulässig als Zwischen-Event | Zulässig als Ende-Event | |
|---|---|---|---|---|
| Nachricht | Ja | Ja | Ja | |
| Signal | Ja | Ja | Ja | |
| Timer | Ja | Ja | Nein | |
| Bedingung | Ja | Ja | Nein | |
| Verknüpfung | Nein | Ja | Nein | |
| Terminierung | Nein | Nein | Ja |
Gateways dienen dem Ablauffluss zwischen den Aktivitäten untereinander und zwischen Aktivitäten und Events. Sie ermöglichen den Ablauf zu teilen und wieder zusammenzuführen. Der Ablauf findet dabei immer nach dem Token-Ansatz statt. Das bedeutet, dass es immer einen bestimmten Teil des Pfades gibt, der gerade aktiv ist. Durch die Teilung des Prozess-Flusses mittels Gateways können mehrere parallele Abarbeitungen erfolgen und auch bestimmte Pfade unter bestimmten Bedingungen ausgewählt werden.
Die wichtigsten Gateway-Typen sind:
- Exklusives Oder (Entweder-Oder Verbindung),
- Inklusives Oder (Und-Oder Verbindung),
- Parallel (Und Verbindung) und
- Komplex (Kombination mehrerer Verbindungsarten).
Mit einem exklusiven Oder-Gateway werden mögliche Pfade vorgegeben, von denen genau einer eingeschlagen werden kann. In der Abbildung "BPMN: Exklusives Gateway" ist die mögliche Verwendung von Gateways mit exklusivem Oder dargestellt. Hier löst des Event Start die Aktivität 1 aus und wird nachher durch das exklusive Oder geteilt. Je nachdem ob Bedingung 1 oder Bedingung 2 erfüllt ist, wird der Ablauf bei Aktivität 2 oder Aktivität 3 fortgesetzt. Damit beide Aktivitäten am Event Ende abschließen können, werden die Pfade nach den beiden möglichen Aktivitäten wieder über ein exklusives Oder zusammengeführt. Grundsätzlich werden Pfade immer mit demselben Gateway-Typ zusammengeführt, mit dem sie auch geteilt wurden.
Bei einem inklusiven Oder-Gateway werden mögliche Pfade vorgegeben, von denen einer oder mehrere eingeschlagen werden können. In der Abbildung "BPMN: Inklusives Gateway" ist die mögliche Verwendung von Gateways mit inklusivem Oder dargestellt. Hier löst des Event Start ebenfalls die Aktivität 1 aus und wird nachher durch das inklusive Oder geteilt. Je nachdem ob Bedingung 1 oder Bedingung 2, oder beide Bedingungen, erfüllt sind, wird der Ablauf bei Aktivität 2, Aktivität 3 oder bei beiden Aktivitäten parallel fortgesetzt. Damit beide Aktivitäten am Event Ende abschließen können, werden die Pfade nach den beiden möglichen Aktivitäten wieder über ein inklusives Oder zusammengeführt. Das zusammenführende inklusive Oder wartet, je nach der Anzahl der eingeschlagenen Pfade des verteilenden inklusiven Oder auf nur eine oder beide eingehenden Aktivitäten.
Damit es bei der Aufteilung der Pfade nicht zum Stillstand des Gesamtablaufes kommen kann wird empfohlen, bei Oder-Bedingungen, einen zusätzlichen Standardfluss ohne Bedingung zu modellieren welcher ausgeführt wird, wenn keine der übrigen Bedingungen zutrifft (ähnlich dem Default-Zweig eines Select-Case Statements). (Freund & Rücker, 2014, S. 39f)
Bei einem Parallel-Gateway werden mögliche Pfade vorgegeben, welche alle gleichzeitig, ohne zusätzliche Bedingungen, eingeschlagen werden. In der Abbildung "Parallel Gateway" ist die mögliche Verwendung von Parallel Gateways dargestellt. Hier löst des Event Start wieder die Aktivität 1 aus und wird nachher durch das Parallel Gateway geteilt. Der Ablauf wird daher parallel bei Aktivität 2 und Aktivität 3 fortgesetzt. Damit der Prozess-Fluss, nach der Ausführung beider Aktivitäten, am Event Ende abschließen kann, werden die Pfade wieder über ein Parallel Gateway zusammengeführt. Das bedeutet, dass das Gateway abwartet, bis beide seiner Eingangspfade, nach dem Abschluss aller parallel ausgeführten Aktivitäten, aktiv sind und erst dann die Ausführung mit der Auslösung des Events Ende fortsetzt.
Ein komplexes Gateway kann zur Kombination mehrerer verketteter Gateway-Arten in einem einzelnen Gateway genutzt werden. Die Aktivierung der einzelnen Pfade ist dabei von einer rein verbalen Bedingung abhängig, welche beliebig komplex sein kann (z.B.: zwei Aktivitäten aus fünf möglichen müssen ausgeführt werden). Genauso verhält es sich auch beim Zusammenführen paralleler Pfade. In der Abbildung "BPMN: komplexes Gateway" ist die mögliche Verwendung von komplexen Gateways dargestellt. Hier löst des Event Start wieder die Aktivität 1 aus und wird nachher durch das Gateway geteilt, wobei zwei aus fünf möglichen Aktivitäten ausgeführt werden müssen. Nach dem Abschluss der beiden Aktivitäten wird dann die Ausführung wieder mit der Auslösung des Events Ende fortsetzt. Die verbale Beschriftung der Gateways erfolgt dabei direkt mittels Freitext-Anmerkungen.
Wie im vorherigen Beispiel der komplexen Gateways bereits eingesetzt, gibt es die Möglichkeit bestimmte Freitext-Anmerkungen zu einzelnen Elementen zu machen, indem eine eckige Klammer mit einer gestrichelten Linie mit dem jeweiligen Element verbunden wird. Hinter die Klammer wird dann die Freitext-Anmerkung geschrieben. Diese Anmerkungen gehören zur Gruppe der Artefakte.
Ein weiteres Artefakt ist die Gruppierung. Dabei können mehrere Teile des Diagramms durch ein gepunktet-gestricheltes Rechteck eingefasst werden, um ihre logische Zusammengehörigkeit zu verdeutlichen. Dies hat jedoch keinerlei Auswirkung auf die Funktionalitäten des Prozesses. In das System zusätzlich eingebrachte eigene Symbole gelten auch als Artefakte und haben ebenfalls keine Auswirkung auf den Ablauf. Ein Beispiel für eine Gruppierung ist in der Abbildung "BPMN: Gruppierung" dargestellt. Hier sind die Elemente Aktivität 2 und Aktivität 3 zu einer Gruppe mit der Bezeichnung Gruppe 1 zusammengefasst. Auf den Ablauf des Modells hat dies jedoch keinerlei Auswirkung.
Die Teilnehmer eines Prozesses werden über Pools mit darin optional enthaltenen Lanes dargestellt. Dabei ist zu beachten, dass es sich bei einem Teilnehmer nicht immer um eine Person, sondern auch um eine Personengruppe, Rolle, Organisationseinheit oder auch um ein bestimmtes System handeln kann. Innerhalb eines Pools werden all die Prozessteile dargestellt, die von seinen Teilnehmern ausgeführt werden. Innerhalb eines Pools können weitere Unterteilnehmer definiert werden, welche den definierten Teilnehmerkreis weiter unterteilen. Diese Unterteilungen werden als Lanes bezeichnet und können wiederum weiter ineinander verschachtelt werden. Wichtig ist dabei, dass diese Unterteilnehmer innerhalb des übergeordneten Teilnehmerkreises an demselben Prozess beteiligt sind. Eine Aktivität wird dabei immer in der Lane des Teilnehmers eingezeichnet, der sie durchführt. Soll eine Aktivität von mehreren Teilnehmern durchgeführt werden, muss sie in jeder Lane separat eingezeichnet werden. Eine Aktivität darf nicht über mehrere Lanes hinweg gezeichnet werden. Der Grund dieser Regel liegt in der Eindeutigkeit der Aktivitätsdurchführung und Zuständigkeit. Wird beispielsweise eine Aktivität entweder von Teilnehmer 1 oder Teilnehmer 2 ausgeführt, wird sie vorab über ein exklusives Oder-Gateway in zwei idente Aufgaben in beiden Lanes aufgeteilt und anschließend wieder zusammengeführt. Damit ist sichergestellt, dass für ihre Ausführung genau einer der beiden Teilnehmer erforderlich ist. In der Abbildung "BPMN: Pool mit Lanes" ist ein einfaches Prozessdiagramm dargestellt, welches das Zusammenspiel mehrerer Lanes in einem Pool zeigt. Hier führt nach dem Start des Prozesses Teilnehmer 1 die Aktivität 1 aus. Danach werden Aktivität 2 von Teilnehmer 2 und Aktivität 3 von Teilnehmer 3 gestartet. Sobald beide Aktivitäten abgeschlossen sind, wird noch Aktivität 4 von Teilnehmer 1 ausgeführt und der Prozessfluss danach abgeschlossen. Es wurde in diesem Beispiel weiter davon ausgegangen, dass Aktivität 2 und Aktivität 3 thematisch zusammengehören und daher eine Gruppierung eingezeichnet. Dies hat jedoch keinen Einfluss auf den Ablauf und dient einzig der Übersichtlichkeit.
Gibt es in einem Prozessdiagramm mehrere Pools, stellen diese getrennte Teilnehmerkreise mit getrennten Prozessabläufen dar. Es handelt sich dabei um kollaborative Prozesse. Hierbei ist zu beachten, dass die Prozesse nicht direkt über Gateways oder Aktivitäten miteinander verknüpft werden dürfen, da sie in getrennten Systemen stattfinden. Zur Interaktion mehrerer Pools werden Nachrichtenflüsse verwendet. Diese werden als gerichtete gestrichelte Linie dargestellt. Dabei muss beachtet werden, dass ein Gateway keine direkten Aufrufe von Aktivitäten in einem anderen Pool durchführen darf und auch nicht mit Gateways des anderen Pools verknüpft werden kann. Befindet sich ein Nachrichtenfluss direkt zwischen zwei Aktivitäten, handelt es sich um eine Abstimmung der Aktivitäten mittels Nachrichten. Zwischen einer Aktivität und einem Ereignis wird ein Ereignis ausgelöst oder empfangen. Zusätzlich ist es möglich, nicht mit einem Prozessteil eines Pools, sondern mit seinen Teilnehmern zu interagieren. Dazu wird ein Nachrichtenfluss direkt zur Außenkante des gewünschten Poos gezeichnet. Damit ist es auch möglich, Nachrichten an und von Teilnehmern darzustellen, deren Prozess inhaltlich nicht modelliert wird.
Die unterschiedlichen Formen von Nachrichtenflüssen sind in der Abbildung "BPMN: Mehrere Pools und Nachrichtenflüsse" dargestellt. Hier gibt es zwei verschiedene Prozessabläufe zweier unterschiedlicher Teilnehmerkreise und damit unterschiedlicher Pools. Der Teilnehmerkreis 1 teilt sich selbst wiederum in zwei unterschiedliche Teilnehmer, welche mittels Lanes in den Pool integriert sind. Der erste Nachrichtenfluss findet zwischen Aktivität 1 und dem Startevent im Pool von Teilnehmerkreis 2 statt. Dabei wird durch die Ausführung von Aktivität 1 eine Nachricht ausgelöst, welche gleichzeitig auch der Start-Event von Teilnehmerkreis 2 ist. Der nächste Nachrichtenfluss geschieht zwischen Aktivität B und Aktivität 3. Hier benötigt Aktivität 3 Informationen aus Aktivität B. Der letzte Nachrichtenfluss geschieht durch Ausführung von Aktivität 4. Diese benachrichtigt jedoch kein Element in Teilnehmerkreis 2, sondern den Teilnehmerkreis 2 selbst.
Web Service Business Process Execution Language (WS-BPEL)
Bei der Web Service Business Process Execution Language (WS-BPEL) handelt es sich um eine Möglichkeit, die in der BPMN modellierten Prozesse in einem technischen Prozessmodell abzubilden. Dazu wird eine XML Struktur verwendet, welche viele der BPMN Elemente und ihre Interaktionen beinhaltet. Das Hauptaugenmerk liegt hierbei in der Zusammenführung von Webservices zu einem integrierten Prozess. WS-BPEL war ursprünglich der direkte Vorgänger von BPMN und ist durch seine spezielle Ausrichtung, hin zu XML Webschnittstellen, sehr in seinen Anwendungsmöglichkeiten beschränkt. (Freund & Rücker, 2014, S. 231f)
In der BPMN 2.0 Spezifikation sind die Überführungen von der BPMN zur WS-BPEL im Detail beschrieben. (Object Management Group (OMG), 2011, S. 445ff)
Beispiel eines BPMN
In diesem Beispiel soll der Prozess einer Kaffeezubereitung in einer Büroküche modelliert werden. Die Teilnehmer des Prozesses sind alle Mitarbeiter der Abteilung. Diese untergliedern sich in die Mitarbeiter, die Kaffee trinken wollen, und den Mitarbeiter, der ebenfalls für die Wartung der Kaffeemaschinezuständig ist.
Sobald ein Mitarbeiter einen Kaffee möchte, prüft er zuerst ob die Kaffeemaschine korrekt funktioniert. Ist dies der Fall, sucht er sich einen Kaffee (Espresso, Ristretto oder Lungo) aus und bereitet diesen zu. Nach der Zubereitung trinkt er den Kaffee und hat seinen Kaffeebedarf damit gestillt. Sollte die Kaffeemaschine nicht funktionieren informiert er den Service-Verantwortlichen der Abteilung. Dieser überprüft wiederum die Kaffeemaschine hinsichtlich ihrer möglichen Probleme. Ist sie verkalkt, entkalkt er sie, fehlen Bohnen, füllt er Bohnen nach und wenn sie defekt ist, beauftragt er den Hersteller-Service mit einer Reparatur. Alle Probleme können auch gleichzeitig vorhanden sein, daher ist es auch möglich, dass er mehrere der Servicetätigkeiten parallel vornimmt. Im Falle eines Gerätedefektes wird der Service-Verantwortliche wieder vom Hersteller-Service informiert, sobald die Kaffeemaschine repariert ist. Sind alle Servicearbeiten beendet, und die Maschine damit wieder einsatzbereit, informiert der Service-Verantwortliche Kollege die Mitarbeiter der Abteilung. Stellt er hingegen fest, dass überhaupt kein Problem besteht, informiert er direkt die Mitarbeiter der Abteilung, ohne Servicetätigkeiten durchzuführen.
- ↑ Epsilon