15.1 Verschiedene Ebenen

15.1.1 Vertikale Dimension

Zur Prozessmodellierung gehört, insbesondere im Kontext der Unternehmensmodellierung, dass Geschäftsprozesse auf unterschiedlichen Ebenen betrachtet werden. Ganz oben z.B. die Wertschöpfungskette, darunter auf einem mittleren Level die gesamte Prozesslandschaft mit hoch aggregierten Einzelaktivitäten, darunter eine Art Standardprozessmodellierung (bei der Geschäftsobjekte wie Rechnungen als solche verarbeitet werden), ganz unten, nahe „an der Programmierung“ eine programmnahe Prozessmodellierung.

Verschiedene Ebenen

Erst die Betrachtung dieser vertikalen Dimension im Prozessmodell erlaubt ein umfassendes Verständnis des Prozessgeschehens und eine wirklich umfassendes Prozessverständnis.

Die Ebenen spiegeln Aggregationsniveaus der im Prozess zu lösenden Aufgaben wider. Sehr hoch aggregiert ist z.B. die Aufgabe Leistungserbringung, die für jede Organisation Gültigkeit hat. Nicht ganz ernst gemeint, könnte dieses grundlegende Existenzmerkmal von Organisaionen als Ereignisgesteuerte Prozesskette so ausgedrückt werden:

Hier ist die Aussagekraft allerdings sehr gering.

Eine immer noch hohe Ebene, die aber schon mehr Aussagekraft hat, wäre (für Industrieunternehmen) eine Erfassung der Abteilungen und – ganz grob – der Beziehungen zwischen diesen. Z.B. also mit Beschaffung, Produktion, Lagerhaltung, Vertrieb. Sie wird für die Darstellung von Wertschöpfungsketten genutzt, wie auszugsweise in der nächsten Abbildung gezeigt (vgl. [Staud 2006, Abschnitt 8.2.3], auch für Beispiele), und auch für Prozesslandschaften (vgl. unten). Die dabei verwendeten Chevron-Symbole repräsentieren die Geschäftsprozesse des jeweiligen Bereichs.

Übersichtsnotationen

Diese Übersichtsnotationen finden auch in der Unternehmensmodellierung Verwendung. Jedes Element repräsentiert dabei inhaltlich zusammengehörige Geschäftsprozesse. Die Elemente sind linear angeordnet (auch mit Verzweigungen) und stellen auf diese Weise die repräsentierten Bereiche, wenn auch auf sehr einfache Weise, in Beziehung. Die folgende Abbildung zeigt ein Beispiel. Die Pfeile drücken die Verknüpfung zu vor- und nachgeordneten Bereichen aus.

Wesentlich weniger aggregiert ist dagegen eine Grobmodellierung von Geschäftsprozessen. Diese beschreibt den Prozess zwar noch integriert, fasst aber in den einzelnen Aktivitäten (bzw. Funktionen) ganze Prozessabschnitte zusammen. Insgesamt entsteht so eine eher oberflächliche Prozessbeschreibung. Solche Modelle sind Bestandteil der Übersichtsnotationen, wie sie zum Beispiel in der Unternehmensmodellierung nötig sind. Beispiele dafür sind die früher genutzten Szenarien in der SAP-Unternehmensmodellierung (vgl. [Staud 2006, Abschnitt 8.2.2]).

Grobmodellierung von Geschäftsprozessen

Eine Ebene tiefer kann die in Kapitel 12 schon eingeführte Modellierungsebene angesiedelt werden, bei der eine geschlossene Handlung eines Prozessteilnehmers in ein Basistheorieelement (eine Tätigkeit: Aufgabe/Funktion) gepackt wird und bei der die Geschäftsobjekte (Rechnung, usw.) als Ganzes erhalten bleiben. Diese wurde Standardprozessmodellierung genannt. Das ist also die Ebene, auf der Geschäftsobjekte sichtbar sind und Prozesshandeln erfasst werden kann, so dass die Modellierung des Kontrollflusses ohne Schwierigkeit möglich ist. Oftmals erfolgt dies im Rahmen einer Istmodellierung. Selbstverständlich lässt auch solch eine Definition noch Raum für unterschiedliche Aggregationsniveaus, bewältigt also auch nicht ganz den sog. Subjektivitätsfaktor 1 (vgl. Abschnitt 2.3).

Standardprozess­modellierung

Geht es darum, die Geschäftsprozesse programmgestützt abzuwickeln (vgl. Kapitel 17 – 19), muss die oben schon angeführte weitere, detailliertere, Modellierung folgen. Sie soll programmnahe Prozessmodellierung genannt werden. Sie dient zur direkten Vorbereitung der Systemanalyse und des Software Engineering, ist also Teil des Requirement Engineering. In der heutigen Situation sind dafür Aktivitäten und Zustandsautomaten der UML und die BPMN die Werkzeuge der Wahl. Für Detailanalysen, wenn eine bestimmte Situation programmtechnisch intensiv zu hinterfragen ist, sind Sequenzdiagramme sehr hilfreich. Hier kommen also Prozessmodellierung und Systemanalyse zusammen.

Programmnahe Prozessmodellierung

Mit „System“ ist hier IT-System gemeint. Dieses ist notwendig, so gut wie jeder Geschäftsprozess wird durch IT unterstützt und dies wird durch den Trend zur automatisierten Abwicklung von Geschäftsprozessen noch wichtiger.

Programmnahe Prozessmodellierung muss wesentlich detaillierter sein als eine Standardprozessmodellierung. Hier müssen die einzelnen „Handlungen“ so zerlegt werden, dass sie in Programmierkonstrukte abgebildet werden können. Genauso müssen die Geschäftsobjekte, falls sie dann Informationsobjekte sind, in ihre programmtechnischen Bestandteile zerlegt werden. Dies verdeutlicht, dass die Art der verarbeiteten Information in den unteren zwei Ebenen sehr unterschiedlich ist. Während in der Standardprozessmodellierung Geschäftsobjekte (also z.B. Rechnungen, Bestellungen, Lieferscheine, usw.) betrachtet werden, was ja auch dem Prozessdenken entspricht, geht es in der programmnahen Prozessmodellierung um Attribute, bzw. Variablen, usw., eben um die Information, in die das jeweilige Geschäftsobjekt für die Zwecke der Speicherung und Programmierung zerlegt werden musste. Die Semantik zu den Geschäftsobjekten ist da dann im jeweiligen Programm hinterlegt.

Insgesamt sind also folgende Ebenen sinnvoll: "Ganz oben" die Übersichtsdarstellungen, darunter auf einem mittleren Level Grobmodellierungen (mit der gesamten Prozesslandschaft oder Teilen davon) mit hoch aggregierten Einzelaktivitäten, darunter die Standardprozessmodellierung, ganz unten, nahe „an der Programmierung“ eine programmnahe Modellierung (vgl. [Staud 2019, Kapitel 14 und 15]).

Damit liegt dann eine vertikale Dimension in den Prozessmodellen vor (vgl. die folgende Abbildung). Erst die Betrachtung dieser vertikalen Dimension erlaubt ein umfassendes Verständnis des Prozessgeschehens und eine wirklich umfassende Prozessoptimierung.

Vertikale Dimension

Sie wird meist so eingerichtet, dass ein Element der oberen Ebene in genau abgegrenzte mehrere der unteren Ebene zerfällt. Hier also:

• Zu einem Element der Wertschöpfungskette/Prozesslandschaft (z.B. Vertrieb) gehören bestimmte (genau abgegrenzte) der Zwischenebene. Zum Beispiel die einschlägigen Szenarien.
• Zu jedem Element der Zwischenebene (Grobmodellierung) gehören ganz bestimmte Geschäftsprozesse der Standardprozessmodellierung (z.B. einzelne Geschäftsprozesse des Vertriebs) .
• Zu jedem Geschäftsprozess der Ebene der Standardprozessmodellierung gehören Elemente der programmnahen Prozessmodellierung. Auf dieser Ebene wird der Prozess als solcher detailliert beschrieben, außerdem wird in den Funktionen weiter spezifiziert.

Gaitanides betrachtet diese Gesamtthematik unter dem Stichwort Vertikale Ausdifferenzierung von Geschäftsprozessen und weist auf das Dilemma hin, dass sich mit zunehmender Detaillierung "die Transparenz und Übersichtlichkeit der Gesamtstruktur des Geschäftsprozesses" verringert, dass der hohe Detaillierungsgrad aber notwendig ist für die IT-Unterstützung [Gaitanides 2012, S. 162].

Modellierungsdilemma

15.1.2 Prozess- vs. Funktionsmodellierung

Hier noch ein Hinweis auf eine kritische Stelle bei der Erfassung oder Modellierung von Geschäftsprozessen: Die Unterscheidung von Prozess und Funktion.

Dieser Aspekt der vertikalen Dimension verdient wegen seiner Bedeutung hervorgehoben zu werden. In der Standardprozessmodellierung werden normalerweise bestimmte Tätigkeiten in elementare Einheiten zusammengefasst (Kalkulation erstellen, Kunde zusagen, Ware versenden, …). Einige dieser zusammengefassten Tätigkeiten weisen aber eine tiefere innere Struktur auf, die ebenfalls modelliert werden könnte, die aber nicht auf der Prozessebene angesiedelt ist, sondern auf einer detaillierteren Ebene. Durch diese wird die Funktion als solche erläutert. Dies wird Funktionsmodellierung genannt.

Funktionsmodellierung

Betrachten wir als Beispiel die textlichen Prozessbeschreibungen in [Staud 2017, Abschnitt 14.7]. Im Geschäftsprozesses Auftragsstart ist zu sehen, dass die ganz "normale" Prozessbeschreibung plötzlich detailliert wird. Sie beschreibt eine Funktion, die Art und Weise, wie die Stundenvorgaben für den Projektleiter berechnet werden [Staud 2017, Abschnitt 14.7.2]. Dies muss man erkennen, wenn man einen solchen Prozess modelliert. Sonst entsteht eine Prozessmodellierung, die auf sehr unterschiedliche Ebenen stattfindet, was nur bei gezieltem Vorgehen sinnvoll ist. Meist und auch hier ist es sinnvoll, diesen Teil des Prozesses in eine Funktion zu packen.

Beispiel

Dieses Beispiel ist wohl eindeutig. Dass es nicht immer so klar ist, Prozess und Funktion zu unterscheiden, zeigt die Aufgabe "Kostenstruktur eintragen" [ebenda]. Hier ist beides denkbar, weil die Funktion recht einfach strukturiert ist. Sie könnte also in die Prozessmodellierung einfließen. Die Empfehlung ist: Will man detailliert modellieren, z.B. im Rahmen einer Standardprozessmodellierung, wird man diese Stelle im Prozess ausweisen (vgl. [Staud 2014, Abschnitt 8.2]). Geht es eher um einen Überblick über den Prozess, wird man diese Tätigkeiten in eine Funktion packen.

<<mehr dazu im Seminar/in der Vorlesung>>

15.1.3 Prozesslandschaften

Den Rahmen für Geschäftsprozesse stellen Organisationen dar, wertschöpfende (Unternehmen) und nicht wertschöpfende (Verwaltungen, usw.). Bei Letzteren sollten die Bemühungen in Richtung möglichst hoher Effizienz zielen. Die organisationsrelevanten Tätigkeiten werden als Geschäftsprozesse bezeichnet, die Geschäftsprozesse insgesamt als Prozesslandschaft oder Prozesslandkarte.

Prozesslandschaft

Eine Prozesslandschaft besteht damit aus zahlreichen Geschäftsprozessen, die aufgerufen, durchgeführt und beendet werden. Bis auf wenige Ausnahmen sind alle Geschäftsprozesse einer Organisation miteinander verknüpft (im Sinne einer "loosen Kopplung"), was im Folgenden auch zu berücksichtigen ist.

Für einen Überblick zu Übersichtsnotationen und Grobmodellierungen vgl. [Staud 2006, Kapitel 8].

In Prozesslandkarten kann zwischen unterschiedlichen Prozesstypen unterschieden werden. So unterscheiden Alpar/Alt/Bensberg zwischen Führungsprozessen, Leistungsprozessen und Infrastrukturprozessen [Alpar, Alt, Bensberg u.a. 2014, S. 141] und Gadatsch unterscheidet Steuerungsprozesse, Kernprozesse sowie Unterstützungsprozesse [Gadatsch 215, Pos. 354].

Hier ein Beispiel eines Industrieunternehmens, das einen Schwerpunkt im Reklamationswesen setzen muss. Unterschieden und unterschiedlich grafisch dargestellt werden Management-, Kern- und Supportprozesse. Die Abteilungen werden manchmal durch Linien verbunden, wie in [Alpar, Alt, Bensberg u.a. 2014, S. 141] und drücken dann den Grobablauf aus.

Die folgende Abbildung zeigt eine Verbindung von Prozesslandschaft und vertikaler Struktur, wie sie die Entwickler von ARIS Express vorschlagen. Die inhaltlich sehr einfache Ausgestaltung stammt vom Verfasser.

Vertikal und horizontal

Aufgabe:

Vergleichen Sie die Beispiele in den folgenden Quellen hinsichtlich Aufbau und Struktur:

- [Gadatsch 2015, Pos. 354] ("Prozesslandkarte für eine Versicherung")

- [Alpar, Alt, Bensberg u.a. 2014, S. 141] ("Prozesslandkarte – Beispiel Reiseplattform")

- [Alpar, Alt, Bensberg u.a. 2014, S. 141] ("Generische Prozesslandkarte")

15.2 Muster in Geschäftsprozessen

Prozessmodellierung geht vom Geschäftsprozess aus, seinem Aufbau und seiner Semantik. So gut wie jeder Prozessabschnitt drückt Semantik aus. Zahlreiche davon tauchen immer wieder auf: Entscheidung fällen, Tätigkeit wiederholen, Bedingungen für den Fortgang, Aufgaben anstoßen, Datenobjekte erzeugen, Bedingungen und Zeitpunkte beachten, Prozesse starten und beenden, usw. Dies sind (sich oft wiederholende) Muster in Geschäftsprozessen. Die sie abbildenden Prozessmodellabschnitte sind dann Muster im Prozessmodell.

Semantik von Prozessabschnitten

Da sie sich oft wiederholen, einige kommen in so gut wie jedem nicht-trivialen Geschäftsprozess vor, lohnt sich die genauere Betrachtung. Dies sorgt für Effizienz und für weniger Fehler. Konkret: Es entstehen schneller korrekte Prozessmodelle.

Ich beschreibe diese Thematik oft mit …

Semantik sucht Syntax,

… denn bei der Modellierung von Geschäftsprozessen geht es dann darum, diese semantischen Muster in die Syntax der gewählten Modellierungsmethode umzusetzen. Man sucht also für eine bestimmtes semantisches Muster die geeignete Syntax der Modellierungsmethode.

Semantische Muster und ihre Umsetzung

In Abschnitt 15.2 werden die Muster grundsätzlich betrachtet – ohne Bezug zu einer Modellierungsmethode.

Abschnitt 15.3 betrachtet deren Umsetzung mit der BPMN, Abschnitt 15.4 zeigt, wie sie mit Ereignisgesteuerte Prozessketten umgesetzt werden. Diese Kapitel entstammen, leicht verändert, meinen Büchern zu Ereignisgesteuerte Prozessketten und zur BPMN ([Staud 2014a,b], [Staud 2017]).

Folgende Muster werden hier betrachtet:

• Prozessstart
• Prozessende
• Wiederholung, Rückschleife
• Entscheidungsfindung
• Abstimmung von Prozesshandeln
• Teilaufgaben anstoßen; Start mehrerer Aufgaben
• Bedingungen – einfach
• Bedingungen –Kombinatorik
• Wiederholung von Geschäftsprozessabschnitten
• Zeitpunkte
• Zeitfenster
• Warten
• Informationsweitergabe, -verarbeitung

15.2.1 Geschäftsprozess starten

Die Standardauffassung von Geschäftsprozessen in der Prozessmodellierung ist, dass sie gestartet, abgewickelt und beendet werden. Und dies jedesmal, wenn ihre Leistung erforderlich ist. Dass dies nicht immer so ist, merkt man spätestens, wenn man sich der Programmierung von Geschäftsprozessen und dem Thema „Geschäftsprozesse als Automaten“ widmet (vgl. [Staud 2019, insbesondere Kapitel 19 zu Zustandsautomaten]).

Starten, abwickeln, beenden

Hier soll es aber bei der „Standardauffassung“ bleiben. Dann werden also Geschäftsprozesse regelmäßig gestartet. Dies geschieht durch Ereignisse und kann auf folgende Weise geschehen:

• Durch ein externes Ereignis. Z.B. Auftrag geht ein.
• Durch ein internes Ereignis, d.h. in der Regel durch einen internen Geschäftsprozess.

Die Ereignisse können unterschiedlicher Natur sein, Z.B.:

• Eine ankommende Nachricht ("Auftrag geht ein")
• Eine Fehlermeldung ("Cloud-Anwendung nicht erreichbar")
• Zeitliche Aspekte ("Jeden Morgen um 3:00 Uhr startet die Kontrolle der Zahlungseingänge")
• Ein Signal ("Geldautomat wird aufgebrochen")
• Eine Kompensation ("Online-Buchung ist fehlgschlagen, anrufen!")
• Eine Bedingung ("Nachbestellen, weil Bestand unter 1000 und erwarteter Absatz 2000")

Die Ereignisse kommen aus der informationellen Umwelt des Geschäftsprozesses (des Unternehmens).

Ein Geschäftsprozess kann meist in einzelne Aufgaben zerlegt werden. Auch für diese gilt (natürlich), dass sie gestartet und dann auch beendet werden müssen. Scheer hat das in seiner Methode (den Ereignisgesteuerte Prozessketten) sehr klar ausgedrückt, indem er vor und nach jeder Aufgabe ein Ereignis platzieren lässt, das den Start bzw. die Erledigung signalisiert. Vgl. dazu [Staud 2014].

Tätigkeiten

15.2.2 Geschäftsprozess beenden

Ein weiteres triviales Muster ist das Beenden von Geschäftsprozessen. Dies kann ein einfaches Beenden sein, ohne direkte weitere Aktion.

Es kann aber auch mit einer Aktion verbunden ein. Z.B. dem Versenden des Angebots, nachdem dieses fertiggestellt wurde. Oder schlicht dem Versenden einer Nachricht.

Ende mit Aktion

Es kommt natürlich auch vor, dass ein Geschäftsprozess einen anderen nachfolgenden aufruft. Dann wird am Prozessende ein entsprechender Aufruf zu platzieren sein.

Ende mit Aufruf

15.2.3 Entscheidungsfindung

Das am weitesten verbreitete Muster in Geschäftsprozessen ist die Entscheidungsfindung. Dabei handelt es sich um Aufgaben, deren Lösung den weiteren Verlauf des Geschäftsprozesses steuert.

In der Vergangenheit wurden Entscheidungen durchweg von Menschen gefällt. Inzwischen sind dies – wenn es sich um sog. wohlstrukturierte Probleme (vgl. Abschnitt 2.4) handelt – oftmals Programme, mit oder ohne KI-Techniken.

Wer fällt die Entscheidung

Entscheidungen bedeuten immer Problemlösung. Für deren unterschiedliche Komplexität hat Simon bereits 1957 ein Schema vorgelegt (vgl. [Simon 1957]), das von Alpar et al. aufgegriffen wurde (vgl. [Alpar et al. 2014]). Es unterscheidet unstrukturierte, semi-strukturierte und wohlstrukturierte Probleme. Für eine Kurzdarstellung vgl. Abschnitt 2.4.

Unstrukturiert, semi-strukturiert, wohlstrukturiert

Problemlösungen und Entscheidungen benötigen eine informationelle Basis. Diese kann aus den Daten des Unternehmens und der informationellen Umwelt kommen. Sie kann aber auch durch Ereignisse (interne und externe) ausgelöst und fundiert sein.

Informationelle Basis

Die möglichen Ergebnisse von Entscheidungen können unterschiedlich strukturiert sein. Sehr oft liegen alternative Ergebnisse vor (Auftrag wird angenommen oder nicht). Möglich sind auch komplexere Ergebnisstrukturen. Z.B. solche, die Teilmengen von Entscheidungen zulassen. Dazu mehr in den folgenden Kapiteln.

Ergebnismuster

Ein letzter Aspekt betrifft die Anzahl der Entscheidungsträger. Ist es eine einzelne Person oder sind es mehrere zusammen.

Einzel- oder Gruppenentscheidung

15.2.4 Abstimmung von Prozesshandeln

Sehr oft muss eine nicht-triviale Tätigkeit mit anderen Prozessträgern und mit Externen abgestimmt werden. Beispiel: Die Rechtsabteilung des Unternehmens hat einen Vertrag entworfen (für das Mitwirken einer externen Unternehmensberatung) und muss ihn mit der Geschäftsleitung und dem Beratungsunternehmen bzgl. verschiedener Aspekte abstimmen.

Dies hat auch Kontrollaspekte. Im obigen Beispiel: Beim Zusammenspiel der Rechtsabteilung mit der Geschäftsleitung.

Kontrolle

Hier wird Informationstransport zum Thema. Abstimmung in diesem Sinn ist nur möglich, wenn das entsprechende Geschäftsobjekt (Vertrag, Rechnung, usw.) zwecks Abstimmung transportiert wird.

15.2.5 Bedingungen – einfach

Ein weiteres wichtiges Muster in realen Geschäftsprozessen ist, dass es bestimmte Bedingungen für den weiteren Fortgang des Geschäftsprozesses gibt. Z.B. die, dass man erst dann den Urlaubsantrag stellen darf, wenn man geprüft hat

Semantik: Bedingungen für Fortgang

• ob noch genügend Urlaubstage vorhanden sind,
• ob die Geschäftslage die Abwesenheit erlaubt und
• ob eine Vertretung für wichtige Fragen organisiert ist.

15.2.6 Bedingungen – Kombinatorik

Oben war der Ausgangspunkt, dass eine einzelne Bedingung zu prüfen ist. Sehr oft sind aber mehrere Bedingungen zu prüfen und deren Ergebnisse in Beziehung zu setzen. Ein (zugegeben einfaches) Beispiel, das auch in den folgenden Kapiteln aufgegriffen wird: Nach dem Eingang einer Anfrage wird die Fertigungskapazität und der Lagerbestand geprüft. Nur wenn beide Prüfungen positiv ausfallen, wird die Anfrage angenommen, sonst wird verhandelt oder abgesagt. Vgl. unten.

15.2.7 Teilaufgaben anstoßen

Es kommt in Geschäftsprozessen häufig vor, dass an einer bestimmten Stelle im Geschäftsprozess mehrere Tätigkeiten, die Teilaufgaben einer größeren Aufgabe sind, erledigt werden müssen. Zum Beispiel im Rahmen der Abschlusskontrolle eines Buchmanuskripts: Es muss die Seitenformatierung geprüft und korrigiert werden. Ebenso die Kopfzeilen. Außerdem müssen Index und Inhaltsverzeichnis neu erstellt werden.

15.2.8 Wiederholung von Geschäftsprozessabschnitten

Die Notwendigkeit, eine geleistete Arbeit wiederholen zu müssen, spielt in Geschäftsprozessen eine wichtige Rolle. Dabei handelt es sich entweder um ganze Geschäftsprozesse oder um Prozessabschnitte. Dieses Muster Wiederholung taucht daher in den meisten Geschäftsprozessen auf.

Es gibt Situationen in Geschäftsprozessen, wo man nur eine bestimmte Anzahl von Wiederholungen zulassen möchte ("Wiederholklausuren").

Kontrollierte Wiederholung

Ein anderes ganz ähnliches Muster ist ebenfalls oft in Geschäftsprozessen anzutreffen: Sich mehrfach wiederholende (repetitive) Handlungen. Zum Beispiel bei der Durchführung von Kundenbefragungen in einem Call-Center. Nach einer Befragung (z.B. per Telefon) werden die Ergebnisse festgehalten. Danach wird geprüft, ob noch ein weiterer Kunde zu befragen ist. Falls nein, schreitet der Prozess voran, falls ja wird der nächste Kunde befragt.

Sich mehrfach wiederholende Handlungen.

15.2.9 Zeitpunkte

Das folgende Muster gehört zum weiten Bereich der zeitlichen Dimension von Geschäftsprozessen: Zeitpunkte, zu denen eine bestimmte Aktion zu erfolgen hat, z.B.:

Muster Zeitpunkte

• Die Gehälter werden immer am vorletzten Tag des Monats überwiesen.
• Jede Nacht ab 2.00 Uhr startet die Abfrage des Zahlungseingangs und der Abgleich mit den offenen Posten.

15.2.10 Zeitfenster

Oftmals liegt in Geschäftsprozessen das folgende Muster vor: Für die Erledigung bestimmter Aufgaben gibt es ein Zeitfenster (Vorbereitung auf eine Klausur sollte vor derselbigen stattfinden; Angebotserstellung bis zum …), das einzuhalten ist. Etwas konkreter ergibt sich dies so, dass mehrere Tätigkeiten angestoßen werden und erledigt sein müssen, bevor der Zeitrahmen ausgeschöpft ist und der Geschäftsprozess weiter geht.

Muster Zeitfenster

15.2.11 Warten

Ein wesentliches Muster, das in Geschäftsprozessen auftritt, ist Warten. Warten auf die Entscheidung anderer, Warten auf Lieferungen, einen Zahlungseingang, auf das Monatsende, usw. Meist geht dem Warten eine eigene Handlung voraus, die einen anderen Träger oder einen Partner des Geschäftsprozesses betrifft und auf dessen Reaktion man dann wartet.

Muster Warten

15.2.12 Informationsweitergabe, -verarbeitung

In Geschäftsprozessen spielen Informationen aller Art eine wichtige Rolle. Meist treten sie als Geschäftsobjekte (Rechnungen, Angebot, …) auf. Aber auch Datenbankkomponenten sind, v.a. bei einer sehr detaillierten und evtl. programmnahen Modellierung, zu betrachten. Diese Informationen basieren heutzutage i.d.R. auf einer Unternehmensdatenbank.

Muster Informationen – Weitergabe und Verarbeitung

Hinzu kommen noch Informationen mit Nachrichtencharakter. Z.B. textlich formulierte Informationen (Anfragen, …) und Nachrichten (z.B. für Koordinierungsinformationen). Auch die für einen Workflow benötigten Informationsweitergaben gehören hierzu.

Nachrichten

Alle diese Informationstypen werden in Geschäftsprozessen erzeugt, verarbeitet, gelöscht und transportiert.

15.3 Muster mit der BPMN

----------

Vorbemerkung: Dieses Kapitel entspricht Kapitel 12 von …

Staud, Josef: Geschäftsprozessmodellierung mit der Methode Business Process Model and Notation (BPMN). Vilshofen 2017.

… weshalb es auch einige Überschneidungen mit obigem Abschitt gibt, was schon bald behoben wird. :)

Beschäftigt man sich einige Zeit mit konkreten Geschäftsprozessen, merkt man, dass bestimmte Prozesssituationen immer wieder auftreten. Zum Beispiel Entscheidungen oder die Notwendigkeit, mehrere Tätigkeiten gleichzeitig anstoßen zu müssen. In diesem Kapitel wollen wir von solchen Mustern in Geschäftsprozessen ausgehen und ihre Umsetzung in BPMN-Strukturen betrachten. Wir wechseln also die Perspektive, weg von einer syntaxgesteuerten, hin zu einer von der Semantik ausgehenden Betrachtungsweise.

Dies ist durchaus sinnvoll, weil in der Praxis ja zuerst die realen Geschäftsprozesse mit ihren Mustern da sind und für diese dann Modellstrukturen bzw. -fragmente gefunden werden müssen. Diese Situationen müssen dann bewältigt werden, Semantik sucht also passende Syntax. Folgende werden hier betrachtet:

Semantik such Syntax

• Geschäftsprozess / Tätigkeit starten
• Wiederholung, Rückschleife
• Entscheidungsfindung
• Teilaufgaben
• Bedingungen
• Zeitaspekte

15.3.1 Entscheidungsfindung

Das am weitesten verbreitete Muster in Geschäftsprozessen ist die Entscheidungsfindung. Auch dafür gibt es in der BPMN eine tiefe Detaillierung mit entsprechenden syntaktischen Varianten.

Der einfachste Fall

Entscheidungsfindung wird im einfachsten Fall durch eine Aufgabe modelliert, der ein Exclusive Gateway folgt. Die möglichen alternativen Ergebnisse werden an die Kanten geschrieben.

Gateway:

- Exclusive Gateway, verzweigend (datenbasiert))

Die Entscheidung ergibt sich aus dem Geschehen im Geschäftsprozess ("data based" also, in der Sprache der BPMN-Autoren). Der Entscheidungsvorgang hier soll zu alternativen Ergebnissen führen, entsprechend dem logischen exklusiven Oder (XODER).

Geht es um eine Situation, in der eine oder mehrere Aufgaben realisiert sein müssen, damit es im Fluss weitergeht oder der Fluss startet, wird das Inclusive Gateway benutzt.

Falls die Entscheidung durch externe Ereignisse vollzogen wird, ist die grafische Umsetzung mit Hilfe des ereignisbasierten Exclusive Gateway, das ein Zwischenereignis des Typs Empfangend enthält, vorgesehen. Danach werden die Ereignisse (vom Typ Zwischenereignis / empfangend) angefügt, die den Entscheidungsvorgang beschreiben. Die Entscheidung fällt also außerhalb.

Der folgende Auszug aus dem Beispiel zur Buchausleihe ([Staud 2017, Abb. 14.1-1]) zeigt es exemplarisch. Eine Sender-Aufgabe verschickt die Nachricht darüber, dass das gewünschte Buch ausgeliehen ist. Mit Hilfe des ereignisbasierten Exclusive Gateway und zweier empfangender Nachrichten-Zwischenereignisse wird modelliert, dass nun auf eine Nachricht bzw. auf den Ablauf einer Frist (Zeitgeber-Zwischenereignis / empfangend) gewartet wird.

Enthaltene Elemente:

- Sender-Aufgabe

- Exclusive Gateway / ereignisbasiert

- Nachrichten-Zwischenereignis, empfangend

- Zeitgeber-Zwischenereignis / empfangend

- Zwischenereignis / empfangend

Prozessstart

Falls modelliert werden soll, dass die zur Entscheidung führenden Ereignisse am Prozessanfang anfallen, muss wie folgt modelliert werden. Zuerst wird das Gateway für diesen Fall angegeben (mit einem Startereignis des Typs Mehrfach), dann die Ereignisse. Das Zusammenführen der Sequenzflüsse kann dann wie hier gezeigt erfolgen, also ohne ausdrückliche Betonung des "exklusiven" Charakters der Verzweigung. Die möglichen Handlungen werden durch ein Nachrichten-Zwischenereigns, ein Bedingungs-Zwischenereignis oder ein Signal-Ereignis angestoßen, alle vom Typ empfangend.

Enthaltene Elemente (Auswahl):

- Bedingungs-Zwischenereignis, empfangend

- Dienst-Aufgabe

- Exclusive Gateway / ereignisbasiert, für den Prozessstart

- Nachrichten-Zwischenereignis, empfangend

- Nutzer-Aufgabe

- Signal-Zwischenereignis, empfangend

Komplexe Entscheidungen

Handelt es sich um komplexere Entscheidungen, die z.B. auf einem Regelwerk beruhen, und will man dies ausdrücken, dann wählt man das Complex Gateway.

Verdeckte Entscheidungen

Die Möglichkeit, Ereignisse auf die Grenzlinie von Aufgaben zu setzen, schafft ebenfalls eine Kontrollstruktur, die zu Entscheidungen führt. Intern liegt in der Aufgabe eine Verzweigung vor, die man vom Ergebnis her so beschreiben kann: Das Grenzlinienereignis tritt ein oder nicht. Dies muss vom Träger der Aufgabe (Mensch, Programm, Maschine, …) entschieden werden. Falls dann das Ereignis eintritt, kommt es zur gegenüber dem "normalen Sequenzfluss" abweichenden auszulösenden Aufgabe. Im folgenden Beispiel ist dies ein Zeitgeber-Zwischenereignis / Grenzlinie, unterbrechend.

Ereignis:

- Zeitgeber-Zwischenereignis / Grenzlinie, unterbrechend

Auch Kompensationen entsprechend diesem Muster.

Mehrere zusammen

Möchte man ausdrücken, dass mehrere Akteure zusammen die Entscheidungsfindung realisieren (ohne den Entscheidungsweg näher zu spezifizieren) kann das Methodenelement Gruppe (group) genutzt werden. Nachfolgende Abbildung zeigt ein Beispiel.

Enthaltene Elemente (Auswahl):

- Gruppe

- Nachrichtenfluss

15.3.2 Teilaufgaben

Es kommt in Geschäftsprozessen häufig vor, dass an einer bestimmten Stelle im Geschäftsprozess mehrere Tätigkeiten, die Teilaufgaben einer größeren Aufgabe sind, erledigt werden müssen. Zum Beispiel im Rahmen einer Auftragsabwicklung, wie es das folgende Beispiel zeigt. Nach Eingang des Auftrags (hier modelliert als empfangendes Nachrichten-Zwischenereignis) werden der Auftragseingang angelegt, die benötigten Teile vom Lager angefordert, Fremdteile beschafft und die Produktionsplanung durchgeführt. Dies kann mit Hilfe eines verzweigenden Parallel Gateway realisiert werden. Damit werden die nach dem Gateway folgenden Aktivitäten angestoßen.

Enthaltene Elemente:

- Nachrichten-Zwischenereignis, empfangend

- Parallel Gateway, verzweigend

Dies ist keine Parallelität im wortwörtlichen Sinn, sondern nur ein gemeinsames Starten der Aufgaben.

15.3.3 Geschäftsprozess / Tätigkeit starten

An sich ist es eine übersichtliche Situation: Ein Prozess wird gestartet (BPMN-Autoren: instanziiert) wenn eines seiner Startereignisse eintritt [OMG 2011, S. 426]. In der BPMN hat dieser Vorgang aber zahlreiche Varianten, so dass sich ein genauer Blick lohnt. Einen ersten Einblick in die Varianten gibt die folgende Abbildung. Sie gibt alle möglichen Startereignisse an.

In Abschnitt 9.1.4 wurden die Festlegungen der BPMN-Autoren dafür angeführt. In Abschnitt 9.2 wurde die Bedeutung der sieben Start-Ereignistypen erläutert. Folgende Semantikvarianten können berücksichtigt werden:

• Prozessstart ohne besonderen Grund ([Staud 2017, Abschnitt 9.2-1) mit einem "None-Startereignis" (oberste Ebene)
• Prozessstart durch eine ankommende Nachricht ([Staud 2017, Abschnitt 9.2-2]), mit einem Nachrichten-Startereignis (oberste Ebene, Ereignissubprozesse)
• Prozessstart durch einen Fehler ([Staud 2017, Abschnitt 9.2.3]) mit einem Fehler-Startereignis (Ereignissubprozess, unterbrechend)
• Prozessstart durch zeitliche Aspekte ([Staud 2017, Abschnitt 9.2.4]) mit einem Zeitgeber-Startereignis (oberste Ebene, Ereignissubprozesse)
• Prozessstart durch eine Eskalation ([Staud 2017, Abschnitt 9.2.5]) mit einem Eskalations-Startereignis (Ereignissubprozesse)
• Prozessstart durch ein Signal ([Staud 2017, Abschnitt 9.2.6]) mit einem Signal-Startereignis (oberste Ebene, Ereignissubprozesse)
• Prozessstart aufgrund einer Kompensation ([Staud 2017, Abschnitt 9.2.8]) mit einem Kompensations-Startereignis (Ereignissubprozess, unterbrechend)
• Prozessstart durch das Erfüllen einer Bedingung ([Staud 2017, Abschnitt 9.2.9]) mit einem Bedingungs-Startereignis (oberste Ebene, Ereignissubprozesse)
• Prozessstart durch ein Ereignis aus mehreren ([Staud 2017, Abschnitt 9.2.12]) mit einem Mehrfach-Startereignis (oberste Ebene, Ereignissubprozesse)
• Prozessstart durch mehrere Ereignisse, die alle eintreten müssen ([Staud 2017, Abschnitt 9.2.13]) mit einem "Parallel Mehrfach-Startereignis" (oberste Ebene, Ereignissubprozesse)

Einige betreffen also den ganz normalen Start von Prozessen und Subprozessen (angestoßen vom Sequenzfluss), andere sind für Ereignissubprozesse gedacht, unterbrechend und nicht unterbrechend.

Start von Geschäftsprozessen

Der "ganz normale Start" (oberste Ebene) sieht ein Startereignis oder mehrere am Prozessanfang vor, so wie es viele Prozessbeispiele oben schon zeigten, weitere finden sich in [Staud 2017, Kapitel 14]. Hier zwei Beispiele:

Enthaltene Elemente:

- None-Startereignis / oberste Ebene

- Empfänger-Aufgabe

- Dienst-Aufgabe

Die folgende Abbildung zeigt, wie die Situation dargestellt wird, falls eine ankommende Nachricht den Prozess auslöst.

Enthaltene Elemente:

- Nachrichten-Startereignis

- Aufgabe, abstrakte

Eine weitere (wohl v.a. grafische) Variante für einen solchen Prozessstart erlaubt der Einsatz einer Aufgabe des Typs Prozessstart (Prozessstart-Aufgabe). Diese sind für eingehende Nachrichten gedacht, was in der Grafik durch das Symbol für ein Nachrichten-Startereignis links oben im Aufgabensymbol angedeutet wird. Aufgaben dieses Typs dürfen keine ankommenden Sequenzflüsse haben und sie müssen – natürlich – zur Instanziierung fähig sein.

Durch eine Aufgabe des Typs Prozessstart

Es kommt relativ oft vor, dass ein Geschäftsprozess aufgrund von Ereignissen gestartet wird, die "von außen" kommen. Typisches Beispiel ist ein Auftragseingang, der auf unterschiedlichen Medien erfolgen kann. Wird eine der Varianten realisiert, startet die Auftragsbearbeitung. Um diese Semantik zu erfassen, mussten die BPMN-Autoren ein eigenes Gateway schaffen, das verknüpfende ereignisbasierte Exclusive Gateway für den Prozessstart.

Verknüpfendes ereignisbasiertes Exclusive Gateway für den Prozessstart

Auch folgende Semantikvariante kommt vor: Mehrere Ereignisse müssen eintreten, damit ein Prozess startet. Hierfür wird das verknüpfende ereignisbasierte Parallel Gateway für den Prozessstart genommen. Diese Variante ist in [Staud 2017, Abschnitt 11.5] beschrieben.

Verknüpfendes ereignisbasierte Parallel Gateway für den Prozessstart

Start von Subprozessen

Subprozesse können durch einen ankommenden Sequenzfluss gestartet werden oder durch Ereignisse. Erstgenannte werden genauso behandelt, wie im obigen Abschnitt für Prozesse beschrieben. Zweitgenannte sind die Ereignisssubprozesse.

Die ganz allgemeine Semantik von Subprozessen ("zusammenhängende abgrenzbare Tätigkeitsfolgen") kann in der BPMN noch präzisiert werden:

• Soll der Subprozess im Sequenzfluss eingebettet sein oder nicht
• Soll er den aufrufenden Prozess unterbrechen oder nicht
• Soll er auf dessen Daten zugreifen können oder nicht
• Ist Verwendbarkeit an verschiedenen Stellen angedacht?

Betrachten wir die hier angebotenen Möglichkeiten.

(1) Subprozess im Sequenzfluss. Erlaubt die Semantik, dass der Subprozess einfach an einer bestimmten Stelle in den Sequenzfluss eingebunden wird, sind die "ganz normalen" Subprozesse die richtige Wahl.

Im Prozessmodell können diese entfaltet (sichtbar) oder verborgen eingefügt sein. Sie greifen auf die Daten des Prozesses zu, in den sie eingebettet sind, ihre Wiederverwendbarkeit ist dadurch eingeschränkt.

Der Start erfolgt einfach dadurch, dass der Sequenzfluss auf den Rand des Subprozesses stößt. Danach wird das Startereignis des Subprozesses aktiviert oder, falls kein Startereignis vorliegt, alle Aktivitäten, zu denen kein Sequenzfluss hinführt. Vgl. die Beispiele in [Staud 2017] in den Abschnitten 14.6 und 14.7, insbesondere die Abbildungen 14.6-5, 14.7-2, 14.7-5, 14.7-6, 14.7-7, 14.7-8, 14.7-9.

(2) Transaktionen

Der wesentliche Unterschied zu den Subprozessen oben besteht darin, dass eine Transaktion nach ihrem Start entweder ganz durchgeführt oder rückabgewickelt wird. Ein beliebtes Beispiel dafür ist eine Überweisung.

(3) Start von Ereignissubprozessen, unterbrechend

Mit dieser Variante werden Teilprozesse erfasst, die durch Ereignisse gestartet werden. Die dabei entstehenden Subprozesse werden Ereignissubprozesse genannt. Für einen solchen gilt:

• Er wird durch Ereignisse gestartet, die Verbindung zum Elternprozess erfolgt also durch empfangende und abgebende Ereignisse.
• Er unterbricht den aufrufenden Prozess.

Wesentlich ist, dass sich die Ereignisse nicht aus den Prozessdaten ergeben. Es können auch von "außen" kommende Ereignisse sein. Hier ein Beispiel:

Enthaltene Elemente:

- Ereignissubprozess

- Fehler-Schlussereignis

- Fehler-Startereignis / Ereignissubprozess, unterbrechend

- Kompensations-Zwischenereignis / abgebend

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

Hier nimmt der Geschäftsprozess also folgenden Weg:

• Falls der Fehler in der Aufgabe Belaste Kreditkarte auftritt, wird dies durch das abgebende Zwischenereignis Grenzlinie, unterbrechend im Ereignisraum bekannt gemacht.
• Das Startereignis des Subprozesses Bearbeitung Buchungsfehler (Typ Ereignissubprozess, unterbrechend) empfängt dieses Fehlerereignis und startet den Subprozess. Außerdem wird der aufrufende Prozess unterbrochen. Letzteres wird durch die durchgezogene Linie beim Fehler-Startereignis ausgedrückt.

Wie in [Staud 2017, Abbildung 12.1-1] zu sehen ist, können für diese Aufgabe ("unterbrechender" Start eines Ereignissubprozesses) folgende Ereignistypen zur Verfügung stehen: Nachricht, Fehler, Zeitgeber, Eskalation, Signal, Kompensation, Bedingung, Mehrfach und Parallel Mehrfach.

(4) Start von Ereignissubprozessen, nicht unterbrechend

Der Unterschied zum obigen Fall ist, dass hier der aufrufende Prozess (Elternprozess) nach Start des Subprozesses nicht abgebrochen wird, sondern weiter seinen Gang geht.

Im Prozess von [Staud 2017, Abbildung 14.3-1] müssen die beschafften Kreditkarteninformationen (Aktivität links oben) u.U. aktualisiert werden. Dies löst eine (in der Grafik nicht ausgewiesene) Nachricht aus, die dann im Ereignisraum vorliegt. Sie wird dann vom Nachrichten-Startereignis (Typ Ereignissubprozess, nicht unterbrechend) des Ereignissubprozesses Aktualisierung Kreditkarteninformationen empfangen. Dieser Nachrichteneingang löst dann den Ereignissubprozess aus. Dies soll nicht unterbrechend sein, was grafisch durch die gestrichelte Randlinie des Startereignisses angedeutet wird.

Enthaltene Elemente:

- Ereignissubprozess

- Nachrichten-Startereignis / Ereignissubprozess, nicht unterbrechend

- Schlussereignis

Insgesamt können folgende Ereignistypen hier als Startereignisse dienen: Nachricht, Zeitgeber, Eskalation, Signal, Bedingung, Mehrfach und Parallel Mehrfach.

(5) Wiederverwendbare Subprozesse

Dieses Methodenelement (Call Activity, verborgen oder entfaltet) ist geeignet, falls der aufgerufene Prozess die Kontrolle übernimmt. Der Subprozess ist also unabhängig vom aufrufenden Prozess. Vgl. das Beispiel in [Staud 2017, Abbildung 14.5-1].

15.3.4 Wiederholung, Rückschleife

Die Notwendigkeit, eine geleistete Arbeit wiederholen zu müssen, spielt in Geschäftsprozessen eine wichtige Rolle. Dieses Muster Wiederholung taucht daher in den meisten Geschäftsprozessen und Modellierungstheorien auf. Weil nach dem Rücksprung ein Abschnitt wiederholt wird, spricht man auch von einer Rückschleife. In der BPM liegen dafür folgende Varianten vor:

(1) Aufgabe mit Schleifenmarkierung (loop marker)

(2) Subprozess mit Kennzeichen Schleife

(3) Schleife im Prozess

Zu (1): Dies ist eher geeignet für Wiederholung "im Kleinen", im Rahmen einer Aufgabe. Z.B. "Maileingang abarbeiten".

Zu (2): Eher für längere Prozessabschnitte, solche, die typischerweise in einen Subprozess passen. Z.B. "Teilebeschaffung".

Zu (3): Für "echte" Rücksprünge im Geschäftsprozess. Wo also grafisch ausgewiesene Prozessabschnitte wiederholt werden. Dies sind dann prozessindividuelle Situationen, wo nicht der Abschnitt ausgelagert und evtl. an verschiedenen Stellen genutzt werden kann. Beispiele finden sich u.a. in Abbildung 10.5-3, 14.1-1, 14.7-1 und 14.7-7.

Alle hier angeführten Abbildungen stammen aus [Staud 2017].

In Abbildung 14.1-1 ("Buchausleihe") gibt es einen Rücksprung von Vorbestellung mitteilen über eine zweiwöchige Wartefrist zur Aufgabe "Ausleihstatus klären". Die Einbindung des Rücksprungs flussaufwärts geschieht ohne Gateway. Dies ist in der BPMN erlaubt, möglich ist dafür aber auch ein Exclusive Gateway.

In Abbildung 14.3-1 ("Flugbuchung") gibt es einen Rücksprung zu Kreditkarteninformation beschaffen. Er kommt von Belastung Kreditkarte über ein Fehlereignis und eine Kompensation für den Fall, dass noch nicht zu oft ein "Retry" versucht wurde. Ein weiterer Rücksprung kommt von einem Zwischenereignis Grenzlinie, unterbrechend zum gesamten Subprozess Buchung.

Ein ähnliches Muster ist das sich wiederholender (repetitiver) Handlungen. Zum Beispiel bei der Durchführung von Kundenbefragungen in einem Call-Center. Nach einer Befragung (z.B. per Telefon) werden die Ergebnisse festgehalten. Danach wird geprüft, ob noch ein weiterer Kunde zu befragen ist. Falls nein, schreitet der Prozess voran, falls ja wird der nächste Kunde befragt. Auch hierfür eignet sich diese syntaktische Struktur.

Muster repetitive Handlungen

15.3.5 Bedingungen

Ein weiteres wichtiges Muster in Geschäftsprozessen ist, dass es bestimmte Bedingungen für den weiteren Fortgang des Geschäftsprozesses gibt. Der einfachste Fall, dass nur eine einzige Bedingung erfüllt sein muss (oder dass man alle Prüfungen zu einer zusammengefasst hat), wird durch eine Aufgabe Prüfung und den zwei Ergebnissen erfüllt und nicht erfüllt modelliert. Z.B. bei den Bedingungen für die Genehmigung eines Urlaubsantrags, wo evtl. folgende Bedingungen erfüllt sein müssen:

• es müssen noch genügend Urlaubstage vorhanden sein
• die Geschäftslage muss die Abwesenheit erlauben
• eine Vertretung für wichtige Fragen muss organisiert sein

Die Umsetzung kann auf unterschiedliche Weise erfolgen. Eine einfache Lösung besteht darin, alle Einzelentscheidungen in ein Exclusive Gateway zu packen mit den zwei möglichen Ergebnissen "genehmigt", "nicht genehmigt". Vgl. die folgende Abbildung.

Enthaltene Elemente (Auswahl) und Konzepte:

- Exclusive Gateway / datenbasiert und verzweigend

- Aggregation

Dies ist dann auch ein Beispiel für Aggregation in Geschäftsprozessen. Mehrere Handlungen, hier sogar Einzelentscheidungen, werden in eine Aufgabe gepackt. Die dadurch entstehenden Einschränkungen bestehen darin, dass auf Einzelhandlungen (Teilentscheidungen) nicht eingegangen werden kann.

Eine detailliertere Modellierung sieht so aus, dass jede Teilprüfung einzeln angelegt wird. Diese müssen dann durch ein Parallel Gateway verknüpft und als Teilaufgaben gestartet werden. Jede der Teilentscheidungen kann dann negativ oder positiv ausfallen, was durch jeweils ein Exclusive Gateway modelliert wird. Die "positiven Sequenzflüsse" werden dann mit einem Parallel Gateway verknüpft, danach folgt die Funktion für das positive Gesamtergebnis. Das Parallel Gateway erzwingt, dass es zum positiven Gesamtergebnis nur kommt, wenn alle Teilprüfungen positiv ausgefallen sind. Durch ein Inclusive Gateway können dann die übrigen Fälle, wo ja mindestens eine Prüfung negativ ausfiel, dargestellt werden. Vgl. die folgende Abbildung.

Auch zu dieser Lösung passt das Token-Konzept der BPMN-Autoren. Das Parallel Gateway vor Urlaub genehmigen wird nur überwunden, falls alle "positiven" Token ankommen. Das Inclusive Gateway vor Urlaubsantrag ablehnen benötigt nur mindestens einen Token, um ein Token weiterzusenden. So trifft diese Syntax tatsächlich die gewünschte Semantik.

Enthaltene Elemente (Auswahl):

- Exclusive Gateway / datenbasiert und verzweigend

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

- Inclusive Gateway, verknüpfend

Diese Art der Modellierung erlaubt, bei den negativen Fällen weitere Handlungen zu berücksichtigen, um dann evtl. doch noch zu einem positiven Gesamtergebnis zu kommen.

Ist die Prozesssituation so, dass es für jede Kombination der Einzelprüfungen eine bestimmte Vorgehensweise gibt, dann kann dies syntaktisch so ausgedrückt werden: Nach jeder Entscheidung folgen die möglichen alternativen Ergebnisse. Bei jedem Ergebnis einer Aufgabe wird ein Parallel Gateway platziert, von dem Sequenzflüsse zu jedem Ergebnis der anderen Aufgaben führen. Vor die Aufgaben, die zu den Kombinationen passen, muss ebenfalls ein Parallel Gateway platziert werden. Die dort angekommenen Sequenzflüsse spiegeln die Semantik: Jeweils ein Ergebnis bei jeder Aufgabe. Diese Lösung beruht also auf der "syntaktischen " Eigenschaft der Parallel Gateways, dass es bei Verschmelzungen nur weiter geht, falls alle Token ankommen und bei Verzweigungen, dass alle Token "losgeschickt" werden.

Die folgende Abbildung zeigt dazu ein Beispiel aus dem in Abschnitt 14.6 vorgestellten Geschäftsprozess. Dort wurde diese Situation mit Hilfe eines Complex Gateway modelliert. Die Prozessbeschreibung (leicht verändert gegenüber Abschnitt 14.6, um die Kombinatorikstärker zu betonen):

Danach folgt – weiterhin durch den Vertriebsingenieur – die Prüfung, ob die Angebotslegungsfrist (ALF) realisiert werden kann. Parallel hierzu wird die für die Projektabwicklung notwendige Ingenieurgruppe auf ihre Auslastung hin überprüft. Ist die Kapazität vorhanden, die Angebotsfrist aber zu knapp, wird um Fristverlängerung nachgefragt. Wird diese nicht gewährt, erfolgt eine Absage. Ist absehbar, dass benötigte Ingenieurfachkräfte schon für längere Zeit aufgrund laufender Projekte ausgelastet sind, wird um Verschiebung gebeten.

Dies wird wie folgt modelliert: Die Prüfung der Angebotslegungsfrist kann zu zwei Ergebnissen führen: "ausreichend / nicht ausreichend". Genauso die Prüfung der Kapazität der Ingenieurgruppe: "Ingenieurkapazität reicht / reicht nicht". Die kombinierten insgesamt vier möglichen Ergebnisse werden nun bezüglich ihrer Konsequenzen im Text oben wie folgt beschreiben:

• Wenn beide Prüfungen positiv ausfallen geht es weiter im Geschäftsprozess, die Anfrage wird angenommen.
• Ist die Kapazität der Ingenieurgruppe nicht ausreichend und die Angebotslegungsfrist (ALF) realisierbar, wird um Verschiebung gebeten.
• Ist die ALF nicht realisierbar und sind Ingenieurkapazitäten vorhanden, wird um eine Fristverlängerung gebeten.
• Ist die Kapazität der Ingenieurgruppe nicht ausreichend und die ALF nicht realisierbar, erfolgt eine Absage.

Diese Semantik kann, wie beschrieben, durch den Einsatz von Parallel Gateways umgesetzt werden. Vgl. die folgende Abbildung.

Enthaltene Elemente (Auswahl) und Muster:

- Exclusive Gateway / datenbasiert und verzweigend

- Muster Kombinatorik

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

Vgl. für eine ausführlichere Darstellung [Staud 2014, Abschnitt 6.6].

15.3.6 Zeitaspekte

Zeitpunkte

Das folgende Muster in Geschäftsprozessen betrifft Zeitpunkte, zu denen eine bestimmte Aktion zu erfolgen hat. Beispiele:

• Die Gehälter werden immer am letzten Tag des Monats überwiesen.
• Zahlungen erfolgen immer am letzten Tag der Zahlungsfrist.
• Jede Nacht ab 2.00 Uhr startet die Abfrage des Zahlungseingangs und der Abgleich mit den offenen Posten.

Dies wird durch empfangende Zeitgeber-Zwischenereignisse modelliert. Zum einen im normalen Sequenzfluss (empfangend) oder auf der Grenzlinie von Aktivitäten.

Zeitfenster

Wir führen hier das Beispiel von oben zu Teilaufgaben fort. Wird wie oben aufgeteilt und will man den Prozess erst fortsetzen, wenn alle (Teil-)Aufgaben erfüllt sind, dann muss man die Sequenzflüsse mit einem Parallel Gateway wieder verknüpfen. Damit entsteht ein Muster, das hier Zeitfenster genannt wird, weil zwischen dem ersten und dem zweiten Parallel Gateway Aufgaben angeführt sind, die im selben Zeitraum erledigt werden müssen, damit es im Prozess weitergeht. Mit dem ersten Gateway werden die Teilaufgaben angestoßen und erst wenn alle realisiert sind, geht es über das zweite Gateway im Geschäftsprozess weiter.

Enthaltene Elemente (Auswahl) und Muster:

- Muster Zeitfenster

- Nachrichten-Zwischenereignis

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

Dies ist keine Parallelität im wortwörtlichen Sinn, sondern nur ein gemeinsames erledigt werden und es sind auch keine zeitlichen Fixierungen (maximal 2 Tage, …) vorhanden. Eine solche Semantik müsste auf andere Weise umgesetzt werden.

Warten, Zeitraum

Ein wesentliches Muster, das in Geschäftsprozessen auftritt, ist Warten. Warten auf eine Entscheidung anderer, Warten auf Produkte, Zahlungseingang, auf das Monatsende, usw. Meist geht dem Warten eine eigene Handlung voraus, die einen anderen Träger des Geschäftsprozesses betrifft und auf dessen Reaktion man dann wartet. Dies kann in der BPMN durch ein empfangendes Zeitgeber-Zwischenereignis modelliert werden. Der Sequenzfluss hält dann an und wird erst fortgesetzt, wenn die beim Ereignis formulierte zeitliche Bedingung erfüllt ist. Das folgende Prozessfragment zeigt ein Beispiel.

Enthaltene Elemente (Auswahl) und Muster:

- Dienst-Aufgabe

- Empfänger-Aufgabe

- Exclusive Gateway / datenbasiert und verzweigend

- Exclusive Gateway / ereignisbasiert

- Muster Rücksprung

- Nachrichten-Zwischenereignis / empfangend

- Zeitgeber-Zwischenereignis

15.4 Muster mit EPKs

----------

Vorbemerkung: Dieses Kapitel entspricht Kapitel 6 von

Staud, Josef: Ereignisgesteuerte Prozessketten. Das Werkzeug für die Modellierung von Geschäftsprozessen. Vilshofen 2014.

Alle hier angegebenen Verweise (auf Abbildungen, Textstellen) beziehen sich auf dieses Buch, NICHT auf diesen Text. Hinweise zu Bezugsmöglichkeiten der Bücher finden sich auf www.staud.info.

----------

Beschäftigt man sich einige Zeit mit Geschäftsprozessen, merkt man, dass bestimmte Ablaufsituationen immer wieder auftreten. Zum Beispiel Entscheidungssituationen oder die Notwendigkeit, mehrere Tätigkeiten gleichzeitig anstoßen zu müssen. In diesem Kapitel wollen wir von solchen Mustern in Geschäftsprozessen ausgehen und ihre Umsetzung in EPK-Strukturen betrachten. Wir wechseln also die Perspektive, weg von einer syntaxgesteuerten, hin zu einer von der Semantik ausgehenden Betrachtungsweise.

Perspektivenwechsel

Dies ist durchaus sinnvoll, weil in der Praxis ja zuerst die realen Geschäftsprozesse mit ihren Mustern da sind und für diese dann Modellstrukturen bzw. -fragmente gefunden werden müssen. Diese Situationen müssen dann bewältigt werden, Semantik sucht also passende Syntax. Dies ist auch für die meisten dieser Muster möglich. Folgende werden hier betrachtet:

Semantik sucht (halbwegs) passende Syntax

• Entscheidungsfindung
• Teilaufgaben
• Tätigkeiten starten
• Zeitfenster
• Zeitpunkte
• Bedingungen
• Kombinatorik
• Warten
• Wiederholung
• Repetitive Handlungen

15.4.1 Entscheidungsfindung

Das am häufigsten auftretende Muster in Geschäftsprozessen und Ereignisgesteuerten Prozessketten ist die Entscheidungsfindung, das Fällen einer Entscheidung bezüglich alternativer Möglichkeiten. Es ist sehr elementar und deshalb in den Syntaxmustern des vorigen Kapitels direkt präsent (Ereignisverknüpfung, erzeugte Ereignisse, XODER). Die nachfolgende Abbildung zeigt ein Beispiel.

Entscheidung 1
Genau ein Ergebnis

Die Semantik der Entscheidungsfindung wird also in der EPK durch eine Funktion, einen nachfolgenden XODER-Operator und alternative Ereignisse (hier auch Ergebnisereignisse genannt) dargestellt.

Entsprechendes gilt für Entscheidungen, die Teilmengen von Ergebnissen zulassen. Hier kann die Semantik so beschrieben werden: Bei der Entscheidungsfindung kommt es zu mindestens einer Tätigkeit aus einer Menge von Tätigkeiten. Modelliert wird dies durch eine Funktion, den ODER-Operator und eine Menge von Ereignissen, die alle zu Funktionen führen und von denen mindestens eines eintreten muss. Vgl. hierzu auch das direkt passende Basismuster Ereignisverknüpfung / Erzeugte Ereignisse / ODER. Die folgende Abbildung zeigt ein Beispiel. In der Funktion Prüfen, welche Aktion kommt es zu mindestens einer der durch die Ereignisse ausgedrückten Tätigkeiten.

Entscheidung 2
Mindestens ein Ergebnis

Wenn wir Menschen Entscheidungen fällen, fassen wir oft mehrere (Teil-)Entscheidungen zusammen. Beispiele dazu finden sich bei der Thematik „ungenaue ODER-Modellierung und deren Lösung“. Auch im Beispiel der nachfolgenden Abbildung liegt eine solche Situation vor. Ware ist eingetroffen, die Wareneingangsprüfung findet statt. Im Rahmen dieser wird entschieden, ob außer der Annahme der Ware eine Aktion (Einlagern, Umverpacken, Qualitätskontrolle) notwendig ist und welche. Die linke Seite der folgenden Abbildung zeigt die syntaktisch korrekte Lösung. Zuerst muss die Prüfung „Aktion notwendig oder nicht“ modelliert werden, dann die, welche Aktion(en) konkret nötig sind.

Entscheidung 3

"Ein Ergebnis" und "mindestens ein Ergebnis" zusammen

Die rechte Seite der Abbildung zeigt die „syntaktische Kurzfassung“.Hier werden nach der Funktion Wareneingangsprüfung zwei Operatoren hintereinander platziert für die beiden Teilentscheidungen.

Korrekt vs. verkürzt

XODER und ODER kompakt

15.4.2 Teilaufgaben und Tätigkeiten starten

Teilaufgaben

Es kommt in Geschäftsprozessen häufig vor, dass an einer bestimmten Stelle im Geschäftsprozess mehrere Tätigkeiten, die Teilaufgaben einer größeren Aufgabe sind, erledigt werden müssen. Zum Beispiel im Rahmen der Abschlusskontrolle eines Buchmanuskripts: Es muss die Seitenformatierung geprüft und korrigiert werden. Ebenso die Kopfzeilen. Außerdem müssen Index und Inhaltsverzeichnis neu erstellt werden.

Diese Semantik kann durch eine Funktion, einen nachfolgenden UND-Operator und eine Gruppe von verknüpften Ereignissen modelliert werden. Die Ereignisse geben die Teilaufgaben an. Die folgende Abbildung zeigt das oben angeführte Beispiel.

Funktion + nachfolgender UND-Operator

Geht der Prozess weiter, müssen die einzelnen Kanten mit Funktionen und Ereignissen ausgebaut werden. Als erstes kämen die Funktionen, die durch die Ereignisse angestoßen werden. Ein eventuelles Zusammenführen der Kontrollflusszweige würde dann auch wieder mit dem UND-Operator erfolgen (vgl. zum Zusammenführen von Kontrollflusszweigen auch Abschnitt 7.2).

Tätigkeiten starten

Obige Prozessstruktur (Teilaufgaben) wird oft auch eher als das gleichzeitige Anwerfen mehrerer Tätigkeiten interpretiert, v.a. wenn die Tätigkeiten eigenständig sind. Dies kann dann wie folgt modelliert werden: Ein auslösendes Ereignis zeigt den Bedarf, dann folgen die durch UND verknüpften gleichzeitig zu startenden Tätigkeiten. Die folgende Abbildung zeigt das vorige Beispiel in dieser EPK-Struktur. Auch diese Lösung war bei den Syntaxmustern voll präsent (Funktionsverknüpfung / auslösendes Ereignis / UND), vgl. [Staud 2014, Abschnitt 5.4-1].

Ereignis stößt mehrere Funktionen an.

Geht der Prozess weiter, müssen die einzelnen Kanten mit Ereignissen und Funktionen ausgebaut werden. Als erstes kämen die Ergebnisereignisse der angegebenen Funktionen. Ein eventueller Zusammenschluss zu einem Kontrollflusszweig würde dann auch wieder mit dem UND-Operator erfolgen.

Weiterführung

Die beiden semantischen Muster sind also inhaltlich identisch, v.a. wenn man berücksichtigt, dass es ja in der Prozessmodellierung grundsätzlich immer die Möglichkeit gibt, mehrere Tätigkeiten zusammenzufassen, wodurch die erste obige Lösung immer möglich wird.

Zu beachten ist noch, dass weder die Semantik des Geschäftsprozesses, noch die Syntax der EPK ausdrücken, dass es sich um eine Parallelität im technischen Sinn handelt. Es geht immer nur um das gleichzeitige Realisieren der Teilaufgaben (erste Lösung) bzw. um das gleichzeitige Anstoßen.

Keine Parallelität

15.4.3 Zeitfenster

Oftmals liegt in Geschäftsprozessen das folgende Muster vor: Mehrere Tätigkeiten werden angestoßen (wie im vorigen Abschnitt gezeigt) und müssen alle erledigt sein, bevor der Geschäftsprozess weiter geht. Es wird also sozusagen ein Zeitfenster aufgemacht für die Erledigung dieser Aufgaben.

Zeitfenster – „auf und zu“

Dies wird in EPKs dadurch ausgedrückt, dass die durch UND aufgesplitteten Kontrollflusszweige später wieder durch ein UND verknüpft werden. Damit bleiben die gestarteten Kontrollflusszweige nach der Abarbeitung vor dem zweiten UND stehen, bis alle ankommen. Erst dann geht es über den zweiten UND-Operator weiter. Diese Syntax trifft weitgehend die gewünschte Prozesssemantik.

Semantik findet Syntax

Das Zeitfenster ist in der Prozessmodellierung üblicherweise nicht absolut, es gibt weder einen irgendwie gesetzten fixen Startpunkt bzw. Schlusspunkt, noch wird die maximale Länge des Zeitfensters fixiert. Man könnte es aber natürlich einbauen, z.B. indem man ein Ereignis einfügt, das den maximalen Zeitrahmen erfasst und für den Fall des Überschreitens alternative Handlungen anstößt.

Die folgende Abbildung zeigt ein einfaches Zeitfenster mit anschließenden Handlungen. Zusätzlich wurde sozusagen eine pragmatische Komponenteder Prozessmodellierung umgesetzt: Im einfachen sequentiellen Teil nach dem Zeitfenster wurden die Ereignisse weggelassen. Dies wird in einigen Unternehmen so gehandhabt, um die EPKs kleiner und übersichtlicher zu halten. Es ist bei einfachen Abfolgen ohne Verzweigungen auch ohne weiteres möglich.

Gestaltungsregel:
Weglassen der Ereignisse in der einfachen sequentiellen Abfolge.

Wie schon im vorigen Abschnitt angemerkt, sollte die Semantik hier im Zeitfenster keine bestimmte Reihenfolge der Tätigkeiten verlangen, die Syntax der EPK drückt dies auch nicht aus. Sie ist modelltechnisch belanglos. Es gilt aber, dass es erst über den zweiten UND-Operator weitergeht, wenn alle Tätigkeiten erledigt sind.

Erst weiter nach dem zweiten UND, wenn "alles erledigt" ist.

15.4.4 Zeitpunkte

Das folgende Muster in Geschäftsprozessen betrifft Zeitpunkte, zu denen eine bestimmte Aktion zu erfolgen hat. Beispiele:

• Die Gehälter werden immer am letzten Tag des Monats überwiesen
• Zahlungen erfolgen immer am letzten Tag der Zahlungsfrist
• Jede Nacht ab 2.00 Uhr startet die Abfrage des Zahlungseingangs und der Abgleich mit den offenen Posten

Dieses Muster wird in Ereignisgesteuerten Prozessketten realisiert, indem das zeitliche Ereignis mit einem UND-Operator in den Kontrollflusszweig eingebunden wird. Die folgende Abbildung zeigt ein Beispiel. Ein weiteres findet sich in Abbildung 8.3-2.

Muster Zeitpunkte

Mit dieser syntaktischen Struktur können auch Zeitspannen in den Kontrollfluss eingebaut werden. Z.B., dass man nach der Veröffentlichung einer Stellenanzeige vier Wochen wartet, bevor man die Bewerbungen sichtet.

Zeitspanne

Abkürzungen:

PA: Personalabteilung

SchAbt: Schulungsabteilung

Zeitpunkte können auch als Startereignis eines Geschäftsprozesses gesetzt werden. Im folgenden Beispiel sollen an jedem Monatsende die Gehaltszahlungen gestartet werden. Hier spürt man deutlich die Vorstellung, dass die Geschäftsprozesse des Unternehmens natürlich in eine Umwelt eingebettet sind: zeitlich wie hier, aber auch informationell. Das folgende EPK-Fragment zeigt ein Beispiel.

Start-Zeitpunkte,
aus dem Ereignisraum der Organisation

Oftmals sieht man diese Lösung auch in Prozessmodellen, die den Prozess recht programmnah modellieren, um die Programmierung vorzubereiten. Das folgende Fragment stammt von dem Beispiel aus [Staud 2014, Abschnitt 8.6]. Die Semantik ist einfach: An allen Tagen, an denen eine Fälligkeitsprüfung durchgeführt werden soll, erfolgt diese um 5.00 Uhr morgens.

Die passende EPK-Syntax besteht aus zwei entsprechenden Ereignissen

• (Es ist) 5.00 Uhr morgens
• Fälligkeiten sind zu prüfen

die durch UND verknüpft sind. Durch diese Syntax ist gesichert, dass der Prozess erst startet, wenn beide Ereignisse eingetreten sind. Beide Ereignisse sind Startereignissedes Geschäftsprozesses.

Anmerkungen:

Muster: Start-Zeitpunkt mit zwei Startbedingungen.

Syntax: Zwei durch UND verknüpfte Startereignisse.

Wieder wird mithilfe des logischen UND dergestalt gesteuert, dass der Kontrollfluss stehen bleibt, bis der entsprechende Zeitpunkt erreicht oder das entsprechende Ereignis eingetreten ist.

Grundsätzlich geht es hier auch um das Warten (vgl. [Staud 2014, Abschnitt 6.7]), allerdings nicht auf eine externe Entscheidung, sondern auf einen Zeitpunkt. Das Eintreten eines bestimmten Zeitpunktes wird so zu einem externen Ereignis der Ereignisgesteuerten Prozesskette.

Warten

15.4.5 Bedingungen

Ein weiteres wichtiges Muster in realen Geschäftsprozessen ist, dass es bestimmte Bedingungen für den weiteren Fortgang des Geschäftsprozesses gibt. Z.B. die, dass man erst dann den Urlaubsantrag stellen darf, wenn man geprüft hat …

Semantik: Bedingungen für Fortgang

• ob noch genügend Urlaubstage vorhanden sind,
• ob die Geschäftslage die Abwesenheit erlaubt ("Abwesenheit möglich") und
• ob eine Vertretung für wichtige Fragen organisiert ist.

Oder so, wie im einführenden Geschäftsprozess von Kapitel 4. Dort war es so, dass dem Kunden nur zugesagt wird, wenn die Prüfungen der Fertigungskapazitäten und des Lagerbestandes positiv ausfallen.

Die Umsetzung in eine EPK geschieht wie folgt: Die Bedingungen werden durch Ereignisse modelliert. Diese werden nachfolgend mit UND verknüpft, danach folgt die Funktion, für die die Bedingungen existieren. Dies können natürlich auch mehrere sein.

Syntax: „Bedingungs“-Ereignisse“ mit UND verknüpfen

Die folgende Abbildung zeigt ein Beispiel, eingebettet in seine Prozessumgebung. Es verdeutlicht auch, dass für die zu verknüpfenden Ereignisse natürlich Funktionen existieren müssen. Das Beispiel stammt aus dem Geschäftsprozess von [Staud 2014, Kapitel 4] und wurde um eine dritte Bedingung erweitert. Die für dieses Muster wichtigen Abschnitte der EPK wurden mit dickerem Strich gezeichnet.

15.4.6 Kombinatorik

Betrachtet man obiges Beispiel genauer, könnte man fragen, was geschieht, wenn eine der Prüfungen negativ ausfällt. Z.B. die Kapazitätsprüfung. Wird dann um Aufschub gebeten? Oder die Lagerprüfung? Wird dann versucht, das Lager schnell aufzufüllen? Oder wenn beide Prüfungen negativ ausfallen? Gibt es dann gleich eine Absage? In [Staud 2014, Kapitel 4] wurde, weil es ein einführendes Kapitel ist, zu einer einfachen Lösung gegriffen. In Wirklichkeit müssten aber, wenn jede Prüfung zu zwei alternativen Ergebnissen führen kann, zwei mal zwei Kombinationen bedacht werden. Oder wenn drei Prüfungen mit z.B. 3, 4 und 2 möglichen Ergebnissen vorliegen, insgesamt 24 mögliche Ergebniskonstellationen. So will es die Kombinatorik.

Kombinatorische Explosion

Semantisch kann diese Situation wie folgt beschrieben werden: Mehrere Prüfungen müssen bezüglich des weiteren Fortgangs durchgeführt werden. Die Prüfungen führen zu alternativen Ergebnissen. Diese Ergebnisse bestimmen in Kombination den weiteren Fortgang des Geschäftsprozesses.

Die syntaktisch korrekte Umsetzung dieser Semantik wird am obigen Beispiel aus [Staud 2014, Kapitel 4] gezeigt, jetzt aber in voller Detailliertheit. Zuerst der Beginn dieses EPK-Fragments, vgl. die folgende Abbildung. Der Prozess startet durch das Eintreffen einer Anfrage. Diese stößt zwei Funktionen an (Muster Teilaufgaben). Jede soll (nur, aus Gründen der Übersichtlichkeit) genau zwei Ergebnisereignisse haben.

So weit so gut. Nun soll es so sein, dass für jede Kombination der Ergebnisse dieser zwei Prüfungen ein spezieller Fortgang des Geschäftsprozesses in der Semantik vorliegt:

Volle Kombinatorik

• Kapazität reicht nicht / Lagerbestand ausreichend: Mittelfristige Kapazität prüfen.
• Kapazität reicht nicht / Lagerbestand reicht nicht: Um 1 Woche Fristverlängerung bitten.
• Kapazität reicht / Lagerbestand ausreichend: Anfrage annehmen.
• Kapazität reicht / Lagerbestand reicht nicht: Anfrage ablehnen.

Dies ist in der Realität nicht immer so. Da kommt es vor, dass mehrere Kombinationen zu ein und demselben weiteren Fortgang führen. Hier wollen wir aber mal die „volle Kombinatorik“ betrachten.

Die folgende Abbildung (reduziert auf die Elemente, die verknüpft werden müssen) zeigt den ersten Lösungsschritt. Eine zentrale Rolle spielt hier der UND-Operator. Nach jedem Ereignis wird einer eingefügt (wodurch zwei Kanten weggehen können, zu jedem Ergebnis der anderen Prüfung eine) und auch vor jeder nachfolgenden Funktion. Dieser UND-Operator erlaubt ganz im Sinne von [Staud 2014, Abschnitt 6.5] (Muster Bedingungen) den Einbau von Bedingungen.

Nun zum Beispiel. Die folgende Abbildung zeigt den ersten Schritt. Die beiden Ereignisse Kapazität reicht und Lagerbestand reicht nicht werden mit der Funktion mit der Bitte um Fristverlängerung verknüpft. Diese wird nur angestoßen, falls „beide Kanten ankommen“, denn nur dann geht es über den UND-Operator weiter.

Nun wollen wir den sofortigen positiven Fortgang einbauen. Dazu wird vom Ereignis Kapazität reicht und von Lagerbestand ausreichend jeweils eine Kante zur Funktion Anfrage annehmen geführt.

Hier kann man nun bereits sehen, wie durch die UND-Operatoren vor den Funktionen die Semantik umgesetzt wird. Kommt bei einer Instanz des Geschäftsprozesses nur eine der beiden Kanten an, wird die entsprechende Funktion nicht ausgelöst. Dagegen sind die UND-Operatoren nach den Ereignissen syntaktisch motiviert, da ja beim Weiterführen mehrerer Kanten (wie auch beim Zusammenführen) immer ein Operator benutzt werden muss. Da hier beide Kanten „starten“ sollen, ist der UND-Operator der richtige.

Semantik durch UND-Operator

In der folgenden Abbildung sind alle restlichen Kanten eingefügt, außerdem wird auch die Prozessumgebung gezeigt. Von jedem der Ergebnisereignisse gehen so viele Kanten weg, wie die andere Funktion Ergebnisse aufweist. Hier also je zwei. Die Kanten müssen so eingefügt werden, dass sie der gewünschten Semantik entsprechen.

Abkürzungen:

GL: Geschäftsleitung

VU: Vertriebsingenieur

Ein weiteres ausführliches inhaltliches Beispiel hierzu findet sich im Geschäftsprozess Zoo in [Staud 2014, Abschnitt 8.4].

15.4.7 Warten

Ein wesentliches Muster, das in Geschäftsprozessen auftritt, ist Warten. Warten auf eine Entscheidung anderer, Warten auf Produkte, Zahlungseingang, auf das Monatsende, usw. Meist geht dem Warten eine eigene Handlung voraus, die einen anderen Träger des Geschäftsprozesses betrifft und auf dessen Reaktion man dann wartet.

Zeitaspekt Warten

Für die korrekte Modellierung solcher Wartesituationen in Ereignisgesteuerten Prozessketten gibt es grundsätzlich zwei Lösungen, die mit der folgenden Beispielsituation erläutert werden sollen:

• Eine Entscheidung ist gefallen, hier die für eine/n bestimmte Bewerber/in auf eine Stelle.
• Der weitere Verlauf hängt nun (aus Unternehmenssicht) von der Entscheidung eines Externen ab (ob sie/er die Stelle annimmt oder nicht).

Es muss also gewartet werden. Eine Lösung zeigt die folgende Abbildung. Nach dem Ereignis Bewerber/in ist benachrichtigt, das den Abschluss der eigentlichen Bewerberauswahl signalisiert, wird eine Wartefunktion eingefügt. Dies trägt auch der Tatsache Rechnung, dass Warten durchaus eine Tätigkeit ist. Die auf diese Funktion folgenden Ereignisse deuten die möglichen Beendigungen des Wartens an. Entweder durch eine Zu- oder eine Absage. Je nachdem werden dann die entsprechenden Funktionen angestoßen.

Warten auf Zu- oder Absage

Hier wird auf ein externes Ereignis gewartet. Dies kommt durchaus vor, da Geschäftsprozesse natürlicherweise auch auf diese Weise mit der Umwelt in Kontakt treten. Dabei wird also der weitere Verlauf des Geschäftsprozesses durch das Handeln Externer bestimmt.

Externes Ereignis

Neben dieser sozusagen konventionellen Lösung findet man auch die in der nächsten Abbildung angegebene. Bei ihr wird auf die Wartefunktion verzichtet. Unmittelbar nach dem Benachrichtigungsereignis folgt ein logischer Operator UND. Er soll signalisieren, dass der Kontrollfluss in beide Richtungen weitergeht, obwohl semantisch nur eine der beiden Alternativen eintreten kann. Vor den beiden weiteren UND-Operatoren bleibt der Kontrollfluss dann – sozusagen – stehen. Tritt nun eines der beiden Ereignisse ein, ist auf der entsprechenden Seite das UND erfüllt und die nächste Funktion wird angestoßen.

Das logische UND als Schalter

15.4.8 Wiederholung, Rücksprünge

Wie im „wirklichen Leben“ spielt die Notwendigkeit, eine geleistete Arbeit wiederholen zu müssen, auch in Geschäftsprozessen eine wichtige Rolle. Dieses Muster Wiederholung taucht daher in den meisten Geschäftsprozessen und Ereignisgesteuerten Prozessketten auf. Weil nach dem Rücksprung ein Abschnitt wiederholt wird, spricht man bezüglich der EPK auch von einer Rückschleife.

Wiederholung von Geschäftsprozess­abschnitten durch Sprung nach flussaufwärts

Im folgenden Beispiel geht es um die Endphase einer Bucherstellung. Wenn der Text inhaltlich fertig ist folgt die Abschlusskontrolle. Dabei wird die Seitenformatierung und die Kopfzeilengestaltung geprüft. Außerdem wird der Index neu erstellt. Sobald diese drei Tätigkeiten durchgeführt sind, wird das finale PDF-Dokument für den Verlag erstellt. Dieses wird dann geprüft. Oft werden da dann Fehler bemerkt. Falls dies der Fall ist, wird der vorangegangene Prozessabschnitt wiederholt. Dies so oft, bis die abschließende Prüfung des jeweils neu erstellten PDF-Dokuments zufriedenstellend ausfällt.

Beispiel Texterstellung

Die folgende erweiterte Ereignisgesteuerte Prozesskette zeigt, wie dieser Vorgang modelliert wird. Die Rückschleife beginnt immer aus einem Ereignis heraus, dem Ereignis, das den Bedarf an der Wiederholung eines Abschnittes aufzeigt. Im Beispiel der folgenden Abbildung ist dies die Tatsache, dass das PDF-Dokument Fehler zeigt. Die Rückschleife wird dann grafisch durch eine nach flussaufwärts führende Pfeillinie dargestellt, die mithilfe eines XODER-Operators vor einer Funktion wieder in den Kontrollfluss zurückgeführt wird. Diese Funktion muss natürlich die sein, ab der die Wiederholung des Geschäftsprozesses beginnt. Es ist wichtig, dass dieser Wiedereinstieg vor einer Funktion erfolgt, da nur damit die syntaktische Grundregel Ereignis und Funktion lösen sich ab eingehalten wird.

Gestaltung der Rückschleife

Der XODER-Operator hat hier bei der Einbindung der Rücksprungkante eine etwas andere innere Struktur als sonst, wo er zwei oder mehr sich ausschließende Alternativen erfasst. Hier wird im ersten Durchgang auf jeden Fall der Kontrollfluss „von oben her“ durchlaufen. Zum seitlichen „Einstieg“ kommt es nur im Falle eines Rücksprungs.

Rücksprung 1 ohne Kontrolle

In diesem Beispiel wurde darauf verzichtet, die Zahl der Rücksprünge zu kontrollieren. Dies ist auch sinnvoll, weil man hier – ganz pragmatisch – einen letztendlich positiven Ausgang annehmen kann.

Endlos?
Pragmatik!

Natürlich gibt es aber auch Situationen in Geschäftsprozessen, wo man nur eine bestimmte Anzahl von Wiederholungen zulassen möchte. Die folgende Abbildung zeigt eine EPK mit diesem Muster. In diesem Geschäftsprozess wird durch den Vertrieb eine Kalkulation durchgeführt. Ist diese erledigt, führt der Projektleiter eine Prüfung auf Korrektheit durch. Stellt er Fehler fest, wird die Kalkulation durch den Vertrieb überarbeitet. Danach kommt es wieder zur Prüfung durch den Projektleiter. Die Überarbeitung wird maximal zwei Mal angefordert. Ist dann die Kalkulation immer noch nicht korrekt, führt der Projektleiter selbst die Fertigstellung der Kalkulation durch.

Kontrollierte Wiederholung

Dies kann in einer Ereignisgesteuerten Prozesskette wie folgt gelöst werden: Nach dem inhaltlichen Teil der Wiederholung wird eine Funktion eingebaut, in der geprüft wird, wie oft schon zurückgegeben wurde. Wurde noch nicht oder erst ein Mal zurückgegeben, geht es in die Rückschleife, ansonsten in die Fortsetzung des Geschäftsprozesses mit der Funktion Fertigstellung der Kalkulation durch den Projektleiter. Vgl. die nächste Abbildung. Manchmal sieht man auch die Lösung, dass ein Zähler für die Rückgaben als Informationsobjekt angelegt wird. Dann wird bei der Entscheidung, ob nochmals zurückgegeben wird, dieser Zähler gelesen und entsprechend gehandelt.

Prüfung der Anzahl an Wiederholungen

Rücksprung 2 mit Kontrolle der Anzahl der Wiederholungen

Oftmals sieht man auch die folgende Lösung für das Muster Wiederholung. Dabei wird wiederum nach dem Scheitern der Prüfung auf Korrektheit die Überarbeitung der Kalkulation durch den Vertrieb angehängt – allerdings nur einmal. Damit ist in der EPK die u.U. auch mehrmalige Wiederholmöglichkeit angedeutet, auf die Ausgestaltung einer tieferen Semantik („wie oft kann wiederholt werden?“) wird aber verzichtet.

Rücksprung 3:
Wiederholung ohne Rückschleife

Syntaxhinweis

Die folgende EPK enthält zwei Leerzweige bei XODER-Verzweigungen. Dies ist durchaus möglich, muss allerdings bei der Abfolge von Funktionen und Ereignissen beachtet werden. Hier entstanden sie dadurch, dass die beiden Ergebnisereignisse in Kalkulation ist fertig zusammengefasst wurden.

15.4.9 Repetitive Handlungen

Ein anderes ganz ähnliches Muster wie im vorigen Abschnitt ist ebenfalls oft in Geschäftsprozessen anzutreffen: Sich mehrfach wiederholende (repetitive) Handlungen. Zum Beispiel bei der Durchführung von Kundenbefragungen in einem Call-Center. Nach einer Befragung (z.B. per Telefon) werden die Ergebnisse festgehalten. Danach wird geprüft, ob noch ein weiterer Kunde zu befragen ist. Falls nein, schreitet der Prozess voran, falls ja wird der nächste Kunde befragt.

Muster: Sich mehrfach wiederholende Handlungen.

Dies könnte wie in der folgenden Abbildung gezeigt durch eine Rückschleife modelliert werden. Die Punkte in der Mitte deuten weitere Funktionen an, die eventuell getätigt werden müssen, bevor geprüft wird, ob eine weitere Befragung durchzuführen ist. Ist noch eine weitere durchzuführen, kommt es zum Rücksprung und damit zu einer Schleifenkonstruktion. Wie im vorigen Abschnitt gilt auch hier, dass der Rücksprung von einem Ereignis aus startet und vor einer Funktion flussaufwärts wieder in den Kontrollfluss eingebunden wird.

Syntax: Rücksprung, Rückschleife

Kapseln in eine Funktion

Eine solche Schleife kann, wenn kein so hoher Detaillierungsgrad erforderlich ist, auch in eine Funktion gekapselt werden . Dazu wird die sich wiederholende Tätigkeit in eine Funktion gepackt. Vgl. die folgende Abbildung. Damit werden Ereignisgesteuerte Prozessketten natürlich wesentlich einfacher, allerdings geht Aussagekraft verloren. Die Entscheidung, welches Aggregationsniveauman wählt, hängt einfach vom Ziel der Modellierung ab.

Aggregieren
durch Kapseln

15.5 Basismuster in Geschäftsprozessen mit EPKs

----------

Vorbemerkung: Dieses Kapitel entspricht Kapitel 5 von

Staud, Josef: Ereignisgesteuerte Prozessketten. Das Werkzeug für die Modellierung von Geschäftsprozessen. Vilshofen 2014.

----------

15.5.1 Mögliche Anordnungen

In diesem Abschnitt wird betrachtet, wie bei der Verknüpfung durch Operatoren die Ereignisse (E) und Funktionen (F) aufeinander folgen können. Dazu wird erstens für jeden der drei Operatoren unterschieden, ob Ereignisse oder Funktionen verknüpft werden und zweitens, ob die Ereignisse im jeweiligen EPK-Fragment vorangehen oder nachfolgen. Dies ergibt dann die in der folgenden Abbildung angegebenen zwölf Varianten. Diese Abbildung zeigt die möglichen Verknüpfungen abstrahiert, d.h. mit Ereignisbenennungen wie E1, E2, … und Funktionsbenennungen wie F1, F2, … Außerdem sind bei Verknüpfungen immer nur zwei Ereignisse bzw. Funktionen angegeben. Inhaltliche Beispielsfragmente folgen in den anschließenden Abschnitten.

Alle möglichen Anordnungen von E und F im Kontrollfluss

Um die Übersichtlichkeit zu erhöhen wird der Kontrollfluss immer von oben nach unten angeordnet, sodass die eine Seite des Operatorkreises oben und die andere unten ist.

Für die Anordnung, bei der zuerst Ereignisse und dann Funktionen folgen, soll von auslösenden Ereignissen(aE) gesprochen werden. Vgl. die Zeilen 1 und 3 in der folgenden Abbildung. Die Bedeutung dieses Begriffs wird unten bei den Beispielen klarer, wenn deutlich wird, dass bei einer bestimmten Anordnung tatsächlich die Ereignisse so etwas wie Auslöser für die nachfolgenden Funktionen sind.

Definition: Auslösende Ereignisse

Im umgekehrten Fall, wenn Ereignisse nach Funktionen folgen, wird von erzeugten Ereignissen(eE) gesprochen. Dabei entstehen sozusagen die Ereignisse aus der Ausführung der Funktion heraus. Vgl. die Zeilen 2 und 4 in der folgenden Abbildung. Auch hier werden die entsprechenden Beispiele unten zur Verdeutlichung beitragen.

Definition: Erzeugte Ereignisse

Die durchgestrichenen Verknüpfungen sind nicht zulässig. Dazu unten mehr.

Hinweis: Die folgenden EPK-Fragmente sind typischerweise Auszüge aus größeren EPKs. Die Pfeilspitzen oben und am Ende deuten die Verbindungen zum "Umfeld" an.

Im Folgenden werden nun, entlang der obigen Tabelle, von oben nach unten und von links nach rechts, die einzelnen Anordnungen nacheinander mit mindestens einem inhaltlich aussagekräftigen Beispiel vorgestellt.

15.5.2 Ereignisverknüpfung mit auslösenden Ereignissen

Ereignisverknüpfung mit auslösenden Ereignissen bedeutet immer, dass Ereignisse so etwas wie Bedingungen für die nachfolgend auszuführende Funktion (es können auch mehrere sein) sind.

Ereignisse als Bedingungen

UND

Werden auslösende Ereignisse mit dem UND-Operator verknüpft, müssen alle eingetreten sein, bevor der Kontrollfluss über den Operator weiter geht. In einer solchen Situation haben die Ereignisse den Charakter von gemeinsamen Bedingungen für das Starten der Funktion: Die Funktion wird erst gestartet, wenn die Ereignisse eingetreten sind.

Gemeinsame Bedingungen

Im folgenden Beispiel geht es um eine Situation nach einem Auftragseingang. Hier wird mit der Produktionsplanung erst begonnen, wenn Kapazitäten frei sind und die notwendigen Rohstoffe usw. vorhanden sind.

Auf diese Weise lassen sich Regeln und Bestimmungen, die den jeweiligen Prozess betreffen, mit einbeziehen.

XODER

Bei der Verknüpfung von auslösenden Ereignissen durch ein exklusives ODER (vgl. die folgende Abbildung) handelt es sich um alternative Ereignisse für die gilt, dass genau eines eintreten muss, damit es im Kontrollfluss weiter geht, damit also die nachfolgende Funktion gestartet wird. Die auslösenden Ereignisse stellen hier somit Bedingungen dar, von denen genau eine eintreten muss (erfüllt sein muss) damit der Geschäftsprozess weiterschreiten kann.

Alternative Bedingungen

Im folgenden Beispiel geht es um Bestellungen. Angenommen wird, dass diese entweder per Brief, aus dem Portal, aus dem Laden, per Mail oder per Fax eingetroffen sind. Dies wird durch Startereignisse modelliert, die natürlich alternativ sind, was der Logik des exklusiven ODER entspricht. Somit gilt: Die Auftragsbearbeitung wird nur gestartet, falls eines der Ereignisse zuvor eingetreten ist.

ODER

Die Ereignisverknüpfung mit dem logischen ODER bedeutet, dass mindestens eines der parallel angeordneten Ereignisse eintreten muss, damit die nachfolgende Funktion gestartet werden kann. Wie die Formulierung aber bereits sagt, können auch mehrere oder alle Ereignisse eintreten.

Mindestens ein Ereignis muss eintreten

Im folgenden Beispiel geht es um die Frage, ob Eltern eine Ermäßigung gewährt werden kann, wenn ihr Kind eine Kindertagesstätte (KITA) besucht. Die Kriterien dafür wurden als Ereignisse formuliert. Die Möglichkeit einer Ermäßigung liegt vor …

• … wenn bereits ein Geschwister in der KITA ist (Geschwisterermäßigung).
• … das Einkommen der Erziehungsberechtigten unter 1000,-- Euro liegt.
• … der / die Erziehungsberechtigte alleinerziehend ist.
• … der / die Erziehungsberechtigte Sozialhilfeempfänger ist.

Wenn mindestens eines der Ereignisse eintritt, wenn also mindestens ein Kriterium erfüllt ist, dann kann die Ermäßigung gegeben werden. Somit kann der ODER-Operator eingesetzt werden.

Dieses Beispiel ist fiktiv. Das tatsächliche Regelwerk dürfte deutlich komplizierter sein.

Bei diesem Beispiel stellt sich die Frage, warum überhaupt die verschiedenen Ereignisse (Kriterien) angegeben werden. Genügt nicht auch einfach ein Ereignis Ermäßigungsgrund liegt vor nach einer Funktion, die dieses prüft? Dies wäre ohne weiteres möglich. Sehr oft möchte man aber die verschiedenen Möglichkeiten in der Ereignisgesteuerten Prozesskette dokumentieren. Dann ist die obige Ausgestaltung sinnvoll.

Mögliche Aggregation (Zusammenfassung)

Das folgende zweite Beispiel beschreibt eine ähnliche Situation bei einem Versicherungsunternehmen. Die Meldung über einen Schadensfall kann durch den Versicherten, den Geschädigten, die Servicestelle oder in seltenen Fällen auch durch die Polizei erfolgen. Sie kann aber auch durch mehrere dieser „Melder“ erfolgen, z.B. durch Versicherer und Geschädigten, usw. Damit ist auch hier das logische Oder der richtige Operator.

Auch hier ist damit das ODER erfüllt. Für den konkreten Geschäftsprozess bedeutet dies ganz praktisch, dass eine eventuelle „Mehrfachmeldung“ (derselbe Schadensfall wird mehrfach gemeldet) abgefangen werden muss.

Wie oben schon angemerkt, können durch ODER verknüpfte Ereignisse immer auch zusammengefasst werden, wie im folgenden Beispiel gezeigt. Spaltet man jedoch auf, will man die möglichen Alternativen und die Kombinationen dokumentieren. Vielleicht wird ja auch diese Information an einer anderen Stelle der Ereignisgesteuerten Prozesskette benötigt. So z.B. bei dem Fragment zur Gewährung der Beitragsermäßigung. Obwohl für den weiteren Ablauf nicht unbedingt nötig, könnte es in bestimmten Fällen sehr nützlich sein zu wissen, welche Kriterien der Grund für die Ermäßigung waren. Allerdings müsste diese Informationsspeicherung dann noch mithilfe von Informationsobjekten hinzu modelliert werden.

Aggregieren oder Detaillieren

15.5.3 Ereignisverknüpfung mit erzeugten Ereignissen

In dieser Anordnung signalisieren die Ereignisse die Durchführung einer Funktion (oder mehrerer), sie geben Teilaufgaben oder mögliche Ergebnisse an.

UND

Beim logischen UND bedeuten die nachfolgenden Ereignisse Teilaufgaben, die sich aus der Abarbeitung der Funktion ergeben. Es sind die Teilergebnisse, die für so wichtig erachtet werden, dass sie in der Modellierung auftauchen sollen. Formal gesprochen: alle nachfolgenden Ereignisse müssen eintreten (alle Teilaufgaben müssen erledigt sein), dann geht es im Geschäftsprozess weiter.

Teilaufgaben mit UND

Das folgende inhaltliche Beispiel stammt aus dem Krankenhausbereich und beschäftigt sich mit dem Vorgang der Entlassung von Patienten nach einem stationären Aufenthalt. Vereinfacht wurde angenommen, dass hierzu das Bezahlen der Telefonrechnung, das Führen eines Schlussgesprächs und die Erstellung der endgültigen Abrechnung gehört.

Der UND-Operator bedeutet hier nicht Parallelität (der Teilaufgaben), sondern nur, dass diese erledigt sein müssen, bevor die nächste Funktion gestartet werden kann. Teilaufgaben können auch auf andere Art modelliert werden. Auch das Anstoßen mehrerer Funktionen nach einem Ereignis, wie im einführenden Beispiel gezeigt, kann als Anstoßen von Teilaufgaben interpretiert werden. Siehe zu dieser ganzen Thematik Teilaufgaben Abschnitt 6.2.

Keine Parallelität im technischen Sinne

XODER

Beim exklusiven ODER bedeutet die Ereignisverknüpfung mit erzeugten Ereignissen, dass die Ereignisse die möglichen alternativen Ergebnisse der vorangehenden Funktion festhalten. Das heißt, genau eines der Ereignisse muss eintreten, dann es im Kontrollfluss weiter geht.

Festhalten alternativer Ergebnisse

Das folgende Beispiel beschreibt – in einem Verlag – den Ablauf, der zum Versenden der Bücher führt. Nachdem eine Buchsendung versandfertig gemacht wurde, wird sie mit einer der Transportgesellschaften versandt. Natürlich nur mit einer, da die Sendung ja nur einmal versandt werden kann. Die Ereignisse geben hier also mögliche alternative Ergebnisse an.

Ganz ähnlich die folgende Situation. Hier sei die Semantik so, dass bei Eingang eines Auftrags geprüft wird, ob dieselbe Anlage, eine ähnliche oder keine der gewünschten Art früher schon mal hergestellt wurde. Ziel ist, auf vorhandene Produktionsunterlagen zugreifen zu können. Zusammen mit der Semantikfestlegung ergibt sich eine Semantik, die mit einem XODER-Operator modelliert werden kann.

Festlegung:
Nur das "beste" der Ereignisse wird jeweils berücksichtigt

ODER

Die Syntax des ODER-Operators sagt in der Anordnung dieses Abschnitts, dass mindestens ein Ereignis eintreten muss, damit es im Kon­trollfluss weitergeht. Mit anderen Worten: Eine Teilmenge der Ereignisse muss eintreten – allerdings nicht die leere Menge.

In semantischer Hinsicht bedeutet dies, wie immer bei ausgelösten Ereignissen, dass die Ereignisse die Erledigung von Aufgaben signalisieren. Hier aber nicht von Teilaufgaben (wie beim UND) oder von alternativen Aufgaben/Ergebnissen (wie beim exklusiven ODER), sondern von Aufgaben/Ergebnissen, die einzeln oder auch zusammen (in beliebiger Kombination) anfallen können.

Erledigung von Aufgaben

Das folgende EPK-Fragment zeigt ein Beispiel. Bei einer Kundenabfrage wird geklärt, welche Leistungen ein Kunde in Anspruch nimmt. Da er bereits Kunde ist, liegt mindestens ein Ergebnis vor. Die Abfrage kann also zu einer beliebigen Anzahl von Ergebnissen führen. Diese Situation kann durch eine Funktion mit nachfolgendem ODER-Operator und entsprechenden Ergebnisereignissen modelliert werden, wie es die folgende Abbildung zeigt.

Bei erzeugten Ereignissen, die durch einen ODER-Operator verknüpft sind, stellt sich oft die Frage, ob die durch ein ODER verknüpften Ereignisse unabhängig voneinander sind, d.h. ob wirklich jedes unabhängig von den anderen in irgendeiner Kombination auftreten kann? Das kann man sich auch im obigen Beispiel vorstellen:

Unabhängigkeit

• Für Online-Banking braucht man entweder ein Girokonto oder ein Depot.
• Für eine EC-Karte braucht es ein Girokonto
• Ein Darlehen gibt es nur, wenn der Darlehensnehmer ein Konto hat.

Solche Bezüge gibt es u.U. viele. Mit dem ODER-Operator verzichtet man auf deren Klärung. Sollte diese innere Strukturierung ebenfalls modelliert werden, würde die EPK etwas komplizierter.

Das inhaltliche Beispiel der folgenden Abbildung zeigt eine ähnliche Situation. In diesem Unternehmen kann die Wareneingangsprüfung dazu führen, dass die Ware eingelagert werden muss, dass eine Umverpackung notwendig ist, dass die Qualitätskontrolle bemüht werden muss oder dass mehrere dieser Tätigkeiten in beliebiger Kombination anfallen. So weit so gut, dies entspricht der „reinen“ Logik des ODER-Operators. Nimmt man zu diesen möglichen Prüfungsergebnissen dasjenige hinzu, das signalisiert, dass keine der anderen Aktionen nötig ist (Keine Aktion notwendig), entsteht die in der folgenden Abbildung angegebene Ereignisgesteuerte Prozesskette. Dies liegt durchaus nahe und wird auch oft so gemacht. Damit ist aber der ODER-Operator nicht mehr in vollem Umfang erfüllt, denn das Ereignis „Keine Aktion notwendig“ kann nicht in Kombination mit den anderen auftreten. Die Ereignisse sind nicht mehr unabhängig voneinander.

Vgl. zur Problematik des ODER-Operators und zu den Fehlerquellen [Staud 2014, Abschnitt 7.3.]

Diese Syntax widerspricht also dem ODER-Operator, zumindest in der semantischen Auslegung, das heißt, wenn der Bedeutungsgehalt der Ereignisse (die Semantik) berücksichtigt wird. Rein syntaktisch, wenn es nur darum geht, dass mindestens ein Ereignis eintreten muss, ist das ODER allerdings auch hier erfüllt.

Syntax vs.
Semantik

Die Tatsache, dass mit ODER verknüpfte Ereignisse eigentlich beliebig kombinierbar sein sollten, dies aber in der praktischen Modellierung nicht immer gemacht wird (werden kann), kann mit Unabhängigkeit bzw. Nichtunabhängigkeit von Ereignissen voneinander bezeichnet werden.

Eine Gruppe von mit ODER verknüpften Ereignissen ist unabhängig voneinander, wenn die Semantik zulässt, dass die Ereignisse in beliebiger Kombination auftreten können.

Definition

Wie man eine solche im strengen Sinn des Operators unrichtige Struktur zu einer korrekten macht, wird in [Staud 2014, Abschnitt 7.3] gezeigt.

15.5.4 Funktionsverknüpfung mit auslösenden Ereignissen

Funktionsverknüpfung mit auslösenden Ereignissen bedeutet immer, dass das Eintreten eines Ereignisses nachfolgende Funktionen startet. Entweder genau eine von mehreren (XODER) (?), mehrere zusammen (UND) oder mindestens eine (ODER) (?). Die Fragezeichen deuten Probleme an, die es hier zu lösen gibt.

Ereignis startet Funktionen

UND

Dass ein Ereignis gleich eine von mehreren Funktionen startet, gilt in der Prozessmodellierung als unerwünscht, weil ein Ereignis keine Tätigkeit ist, in der entschieden wird, welche Funktion gestartet werden soll. Dies wird auch das Thema der nächsten beiden Abschnitte (XODER, ODER) sein. Beim UND gibt es allerdings keine Probleme. Ein Ereignis kann zum parallelen Start zweier oder mehrerer Funktionen führen [Anmerkung] .

Wohl bekannt:
ein Ereignis führt zu mehreren zu erledigenden Aufgaben.

Das folgende Beispiel möge dies verdeutlichen. Ist in einer Spedition ein Transportauftrag erteilt, muss der Fahrer benachrichtigt, die Auftragsbestätigung geschrieben und es müssen die Transportpapiere erstellt werden. Hier kann mit Sicherheit von einer Reihenfolge der Tätigkeiten ausgegangen werden, auf deren Modellierung aber bei Verwendung des UND verzichtet wird.

Keine Reihenfolge
bzw.
Verzicht auf Modellierung der Reihenfolge

Das folgende EPK-Fragment zeigt ein zweites Beispiel. Ein Text wird erstellt (zum Beispiel für ein Fachbuch), irgendwann ist er fertig und die Schlussarbeiten stehen an. Das Startereignis ist hier also eine Erkenntnis im Kopf des Autors. Dann ist einiges zu tun.

Die Ereignisgesteuerte Prozesskette zählt die Aufgaben auf. In diesen Aufgaben mit ihren Ergebnissen steckt sogar eine spezielle Semantik: Eine Reihenfolge (Indexerstellung nach Formatierung, usw.), evtl. auch Wiederholung, denn die Neuerstellung der Formatierung führt u.U. dazu, dass das bisherige Inhaltsverzeichnis nicht mehr stimmt und die Erstellung desselbigen wiederholt werden muss. Wählt man die in der folgenden Abbildung gewählte Syntax, verzichtet man auf diese speziellen Semantikaspekte.

Pragmatik. Verzicht auf zu viel Detaillierung.

Anmerkungen:

Semantik: Ereignis stößt mehrere fest bestimmte Tätigkeiten an.

Syntax: Ereignis mit nachfolgendem UND-Operator und zu erledigenden Funktionen.

Pragmatik: Verzicht auf die Modellierung eventueller Zusammenhänge zwischen den (Funktionen).

Wie immer beim logischen UND bedeutet die parallele Anordnung nicht, dass die Aufgaben tatsächlich parallel erledigt werden (schon gar nicht im technischen Sinn) , sondern nur, dass sie zusammen gestartet werden.

XODER – verboten

Die folgende Anordnung ist eine verbotene. Dabei geht es um Ereignisse, denen ein XODER-Operator nachfolgt, die also eine von mehreren mit dem exklusiven ODER verknüpften Funktionen auslösen.

Fehlende Entscheidungs­funktion

Betrachten wir das folgende Beispiel eines Auftragseingangs. Dem Ereignis des Auftragseingangs folgt entweder die Auftragsannahme, die Ablehnung oder die Notwendigkeit Rückfragen zu klären. Modelliert man dies so wie in der folgenden Abbildung übt die EPK aufgrund ihrer Schlichtheit eine gewisse Faszination aus. Schon kurzes Nachdenken macht aber deutlich, dass hier ein wichtiger Abschnitt des realen Geschäftsprozesses nicht modelliert wurde: die Entscheidungsfindung, die Analyse der Machbarkeit, usw. Die EPK „springt“ sozusagen gleich von dem Ereignis zur Ausführung einer der Funktionen.

XODER – verboten

Das ist der Grund, weshalb eine solche Struktur – sozusagen – verboten ist. Tritt sie auf, muss sie um eine Funktion ergänzt werden, die den Entscheidungsprozess modelliert und um Ereignisse, mit denen die möglichen Ergebnisse des Entscheidungsprozesses ausgedrückt werden. Obiger Ausschnitt ist dann wie in der folgenden Abbildung zu modellieren.

Richtige Lösung mit Entscheidungs-
funktion

Mit der Entscheidungsfunktion (hier: Machbarkeitsprüfung) kommen dann auch die Ereignisse in die EPK, mit denen die möglichen Ergebnisse des Entscheidungsprozesses angedeutet werden. Diese Ergebnisereignisse erhöhen dann auch die Aussagekraft der EPK.

ODER – verboten

Die folgende ODER-Verknüpfung ist wieder eine verbotene, ganz wie oben bei den durch XODER ausgelösten Funktionen. Das Beispiel zeigt die Situation bei einer Neuanlage eines Girokontos. Ist diese erfolgt, kann der Kunde verschiedene Leistungen anfordern, von EC-Karte bis Online-Banking. Modelliert man es so wie in der folgenden Abbildung, fehlt allerdings die Entscheidungsfunktion, die festlegt, welche Ereignisse bei einer konkreten Instanz des Geschäftsprozesses eintreten, bzw. welche Aufgaben zu tätigen sind.

Fehlende Entscheidungs-
funktion

Auch hier fehlt wieder der Entscheidungsprozess in Form einer Funktion. In der nächsten Abbildung ist er zusammen mit den erforderlichen Ereignissen eingefügt. Die Entscheidungsfunktion kann hier mit Entscheidung im Gespräch mit dem Kunden umschrieben werden. Eine vertiefte Darstellung dieser Problematik, „Unschärfen bei der ODER-Modellierung“ findet sich in [Staud 2014, Abschnitt 7.3].

Richtige Lösung mit Entscheidungs-
funktion

Eine Zusammenfassung aller wichtigen Syntaxregeln findet sich in [Staud 2014, Kapitel 9]. Die Regel zu den verbotenen Strukturen wird wegen ihrer großen Bedeutung auch gleich hier angeführt.

Syntaxregel

Nach einem Ereignis (oder nach mehreren) darf kein ODER- oder XODER-Operator für die dann ja notwendigerweise nachfolgenden Funktionen folgen. Mit anderen Worten: Auslösende Ereignisse mit XODER und ODER sind nicht erlaubt.

Im folgenden Beispiel wurden, damit sie nicht in Vergessenheit geraten, auch mal wieder Organisationseinheiten und Informationsobjekte angefügt.

Anmerkungen:

Semantik: Ereignis löst Teilmenge von Tätigkeiten aus.

Syntax: Ereignis, ODER-Entscheidungsfunktion mit Teilmengen von Ergebnisereignissen, dann für jedes Ergebnisereignis eine Funktion.

Abkürzungen:

DiKu: Digitale Kundenakte

AFKK: Antragsformular Kreditkarte

AFDP: Antragsformular Depot

AFOB: Antragsformular Online-Banking

15.5.5 Funktionsverknüpfung mit erzeugten Ereignissen

Von mehreren Funktionen erzeugte (nachfolgende) Ereignisse entstehen, wenn die Beendigung mehrerer Funktionen durch ein- und dasselbe Ereignis angegeben werden kann. Dabei geht es immer um das Zusammenführen von Kanten, die von Funktionen kommen. Im Falle des XODER waren dies alternativ auszuführende, im Falle des UND parallel zu erledigende und im Falle des ODER Funktionen, von denen mindestens eine getätigt werden musste.

Erledigung von Funktionen

UND

Das logische UND bedeutet in dieser Anordnung, dass mehrere Funktionen getätigt werden müssen, bevor das nachfolgende Ereignis eintritt. Die Funktionen müssen also „gleichzeitig“ erledigt werden, bevor es mit dem Geschäftsprozess weitergeht. Ob diese Tätigkeiten in der Realität wirklich auch parallel erledigt werden, ist modelltechnisch ohne Bedeutung. Sie können genauso gut auch hintereinander abgearbeitet werden.

Mehrere Funktionen erledigen, dann gemeinsames Ergebnis

Im folgenden Beispiel stellen wir uns vor, dass in einem Unternehmen bei Neueinstellungen jeder Bewerber an einem Assessment Center teilnimmt, dass mit ihm oder ihr ein Gespräch geführt wird und dass die eingesandten Unterlagen ausgewertet werden. Erst danach geht es mit dem Auswahlprozess weiter.

Anmerkungen:

Semantik: Mehrere Tätigkeiten sind durchgeführt, es geht im Geschäftsprozess einheitlich weiter.

Syntax: Mehrere Funktionen, Verknüpfung durch UND, nachfolgendes Ereignis.

Obiges Modell wird in der folgenden EPK noch etwas ausgebaut, um am Beispiel die Einbettung eines solchen EPK-Fragments in einen etwas größeren Zusammenhang aufzuzeigen. Der Geschäftsprozess startet durch den Wunsch, eine Stelle zu besetzen. Dies stößt eine Besprechung zur Vorgehensweise an, die von der Personalabteilung und der Fachabteilung getätigt wird und die den Stellenbesetzungsplan nutzt. Entschieden wird, ob die Stelle ausgeschrieben oder intern besetzt wird. Eine interne Besetzung läuft (hier) problemlos durch , für eine externe wird eine Bewerberakte angelegt und eine Ausschreibung durchgeführt, innerhalb derer dann die drei oben angeführten Aktivitäten

Stellenbesetzung – etwas umfangreicher

• Gespräch mit Bewerber führen
• Assessmentcenter durchführen
• Bewerberunterlagen getätigt

durchgeführt werden. Die Ergebnisse werden in der Bewerberakte festgehalten. Anschließend wird auf der Basis der gewonnenen Daten eine Person durch die Fachabteilung ausgewählt und eingestellt.

Die folgende EPK zeigt die Umsetzung dieser Prozessbeschreibung in ein Modell. Neben der Einbettung des obigen Fragments zeigt das Beispiel auch ein Muster, das hier Zeitfenster genannt wird (vgl. für eine tiefere Betrachtung Abschnitt 6.3): Die drei Aktivitäten werden nach dem ersten UND-Operator gestartet und vor dem zweiten UND-Operator erledigt, erst dann geht es im Prozess weiter.

Muster Zeitfenster

Anmerkungen:

Muster: Zeitfenster

Syntaxregel: Zusammenführen Kontrollflüsse

Hier ist auch eine Syntaxregel umgesetzt, die das Zusammenführen von Kon­trollflusszweigen betrifft (vgl. [Staud 2014, Abschnitt 7.2]): Werden Kontrollflüsse durch einen Operator aufgesplittet und sollen sie weiter unten (flussabwärts) wieder zusammengeführt werden, so wird dafür derselbe Operator wie bei der Aufsplittung verwendet.

Syntaxregel Zusammenführen Kontrollflusszweige

XODER

Im Falle des XODER muss und darf hier nur eine einzige der verknüpften Funktionen eintreten, dann tritt das gemeinsame ausgelöste Ereignis ein. Es handelt sich also um Alternativen bzgl. der zu erledigenden Aufgabe, die aber alle zum selben Ergebnis führen. Dies ist eine Struktur, die in der Realität sehr oft vorkommt. Natürlich könnten statt einem einzelnen Ereignis auch mehrere folgen. Im folgenden Beispiel wird ein Versand durchgeführt. Er erfolgt hier entweder mit der einen oder der anderen Transportgesellschaft. Welche auch immer gewählt wurde, danach tritt das Ereignis Versand erfolgt ein.

Alternative Tätigkeiten mit einem Ergebnisereignis:

ODER

Ausgelöste (also nachfolgende) Ereignisse nach einem ODER bedeuten, dass mindestens eine der Funktionen durchgeführt werden muss, damit das Ereignis eintritt. Im folgenden Beispiel tritt das Ereignis Kalkulation und Angebot erstellt ein, wenn die davor stehenden Funktionen im Sinne des ODER („mindestens eine“) durchgeführt wurden.

Mindestens eine Funktion muss realisiert werden

Um dieses EPK-Fragment verstehen zu können wurden in der Abbildung die den Funktionen vorgestellten Ereignisse und Funktionen mit angegeben. Dies macht auch deutlich, wie es zu einer solchen Anordnung kommen kann.

Für alle EPK-Strukturen dieses Abschnitts gilt:

• Es werden mehrere Kanten zusammengefasst. Dies geht nur mit einem Operator.
• Es handelt sich um den abschließenden Teil eines Abschnitts, der mit einem zu Verzweigungen führenden Operator beginnt und bei dem mit demselben Operator die Verzweigung wieder aufgehoben wird.

Vgl. zu dieser Thematik auch [Staud 2014, Abschnitt 7.3]. Eine Einbettung dieses Fragments in einen größeren Kontext zeigt [Staud 2014, Abbildung 7.3-4].

Soweit die Betrachtung der im Kontrollfluss grundsätzlich möglichen Verknüpfungen zwischen Ereignissen und Funktionen. Die folgende Abbildung fasst die obigen Ergebnisse zusammen und zeigt alle Varianten in einer einzigen Abbildung. Eine vergrößerte Version davon findet sich auf www.staud.info.

Alle auf einmal

Die Bedeutungen der einzelnen Verknüpfungen sind in der folgenden Abbildung zusammengefasst. In ihr ist für alle 12 Varianten die jeweilige Rolle der Ereignisse angegeben.