Auszüge aus dem Buch: Geschäftsprozesse und ihre Modellierung mit der Methode Business Process Model and Notation (BPMN 2.0)

© Prof. Dr. Josef L. Staud

Dieser Text enthält Auszüge aus meinem Buch:

Geschäftsprozesse und ihre Modellierung mit der Methode Business Process Model and Notation (BPMN 2.0)

Februar 2017, 234 Seiten, 177 Abbildungen

Paperback: ISBN 978-3-7345-9228-7 Verlag tredition (19,99 Euro)
Hardcover: ISBN 978-3-7345-9229-4 Verlag tredition (24,99 Euro)
Standard E-Book: ISBN 978-3-7345-9309-3 Verlag tredition (4,99 Euro)
Amazon TEXTBOOK: ASIN B01MUGTM76 (4,99 Euro)

Aufbereitung für's Web

Diese HTML-Seiten wurden mithilfe eines von mir erstellten Programms erzeugt: WebGenerator (Version 2017-1). Es setzt Texte in HTML-Seiten um und ist noch in der Entwicklung. Die "maschinelle" Erstellung erlaubt es, nach jeder Änderung des Textes diesen unmittelbar neu in HTML-Seiten umzusetzen. Da es nicht möglich ist, nach jeder Neuerstellung alle Seiten zu prüfen, ist es durchaus möglich, dass irgendwo auf einer "abgelegenen" Seite Fehler auftreten. Ich bitte dafür um Verzeihung und um Hinweise (staud@staud.info).

Urheberrecht

Dieser Text ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Textes oder von Teilen dieses Textes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.

Warenzeichen und Markenschutz

Alle in diesem Text genannten Gebrauchsnamen, Handelsnamen, Marken, Produktnamen, usw. unterliegen warenzeichen-, marken- oder patentrechtlichem Schutz bzw. sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Inhaber. Die Wiedergabe solcher Namen und Bezeichnungen in diesem Text berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Gesetzgebung zu Warenzeichen und Markenschutz als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Prof. Dr. Josef Ludwig Staud

Vorwort, Inhalt, Abkürzungen

Vorwort

Es ist nicht mehr die Zeit, wie bei Erscheinen meines ersten Buches zu Geschäftsprozessen und Ereignisgesteuerten Prozessketten ([Staud 2006]), in der Organisationen ihre Prozesse nicht kennen und Prozessanalysen durchführen, um wenigstens ein Stück weit diesbezügliche Kenntnis zu erlangen. Nein, die Phase, in der die Prozesslandschaft weiße Flecken aufwies, ist vorbei - oder sollte zumindest vorbei sein.

Nicht vorbei ist dagegen das Thema Prozessoptimierung. Es ist so bedeutsam, dass man kaum eine Beilage zur Tageszeitung aufschlagen kann, ohne in einem Interview von einem Geschäftsführer zu hören, dass viele Aufgaben gelöst sind, Prozessoptimierung aber bleibt. Es ist wohl wie so vieles eine ständige Aufgabe. Prozessoptimierung aber bedarf der Erfassung der Prozesse, ihrer Beschreibung durch Prozessmodelle. Erst nach dieser Erfassung können viele Schwachstellen erkannt und beseitigt werden.

Befeuert wird diese Entwicklung durch den starken Trend zu einer immer detaillierteren Abbildung der Geschäftsprozesse in „die Software“, zu immer mehr Automatisierung und schließlich zur Vollautomatisierung, wie es uns die Internetunternehmen vorleben. Zum ersten Mal in der Geschichte des kaufmännischen Miteinander gehen wir Menschen in wichtigen Bereichen mit weitgehend vollständig in Software gegossenen Geschäftsprozessen um.

Dass diese Thematik von hoher Aktualität ist, zeigen auch aktuelle Erhebungen. So nannten in der Studie IT-Kompass 2016 [Anmerkung] 59% der Befragten an erster Stelle die Optimierung der Geschäftsprozesse als ein Thema, das sie beschäftigt [Herrmann 2016, S. 24].

Das hat unter anderem die Konsequenz, dass die Prozessmodellierung auf verschiedenen Ebenen stattfinden muss. Früher geschah dies der Übersichtlichkeit wegen, vor allem in der Unternehmensmodellierung, heute aus der Notwendigkeit heraus, denn eine Prozessmodellierung zur Vorbereitung der Programmierung einer Anwendungssoftware muss wesentlich detaillierter sein als eine Prozessmodellierung für eine Istanalyse.

Josef L. Staud

Inhaltsverzeichnis des Buches mit Seitenzahlen

Vorwort, Inhalt, Abkürzungen II

1 Einleitung 1

1.1 Modelle, Modellierung 1

1.2 Aufbau der Arbeit 2

1.3 Methode BPMN 2

1.4 Ziel 3

2 Geschäftsprozesse 5

2.1 Definition(en) 5

2.2 Konzept Geschäftsprozess 9

2.3 Eigenschaften und Komponenten 9

2.3.1 Eigenschaften 9

2.3.2 Komponenten 13

3 Wo steht die Prozessmodellierung heute? 15

3.1 Basiselemente einer Methode zur Prozessmodellierung 15

3.2 Ziele 19

3.3 Herausforderungen 20

3.4 Automatisierung - Möglichkeiten und Grenzen 22

3.4.1 Automatisierungsmöglichkeiten 22

3.4.2 Problemstruktur und Automatisierung 26

3.5 Kontrollfluss vertieft 28

3.6 Prozessmodellierung - heute und morgen 29

4 Geschäftsprozesse in der BPMN 31

4.1 Definition 31

4.2 Prozesstypen in der BPMN 31

4.3 Diagrammtypen 32

4.4 Vertikale Dimension der Prozessmodellierung 33

4.5 Gruppierung der Elemente 33

4.6 Token 34

5 Einführende Beispiele 35

5.1 Das erste Business Process Diagram 35

5.2 Jetzt mit Daten 37

5.3 Handelnde - Träger der Aktivitäten 38

5.4 Ein öffentlicher Geschäftsprozess 39

5.5 Zusammenarbeit 40

6 Tätigkeiten 43

6.1 Aktivitäten 43

6.2 Aufgaben 43

6.2.1 Varianten 44

6.2.2 Aufgabentypen 45

6.2.3 Zusammenfassung 48

6.3 Subprozesse 51

6.3.1 Entfaltet oder verborgen 51

6.3.2 Varianten 52

6.3.3 Typen 56

6.3.4 Zusammenfassung - Arten von Subprozessen 59

6.3.5 Wofür Subprozesse? 62

7 Akteure und Nachrichten 63

7.1 Becken, Bahnen, Nachrichten 63

7.2 Zusammenarbeit 67

8 Informationen und ihre Verarbeitung 71

8.1 Daten und Informationen 71

8.2 Assoziationen 72

8.3 Daten im Geschäftsprozess 72

9 Ereignisse 77

9.1 Einführung 77

9.1.1 Konzept 77

9.1.2 Ausdifferenzierung 78

9.1.3 Startereignisse - allgemein 83

9.1.4 Zwischenereignisse - allgemein 84

9.1.5 Schlussereignisse - allgemein 85

9.2 Ereignistypen 86

9.2.1 Kein Auslöser 86

9.2.2 Nachricht 87

9.2.3 Fehler 88

9.2.4 Zeitgeber 88

9.2.5 Eskalation 89

9.2.6 Signal 90

9.2.7 Abbruch 91

9.2.8 Kompensation 91

9.2.9 Bedingung 92

9.2.10 Verknüpfung 93

9.2.11 Beenden 93

9.2.12 Mehrfach 94

9.2.13 Parallel mehrfach 94

10 Kontrollfluss - Sequenzfluss 96

10.1 Einführung 96

10.2 Flüsse 96

10.3 Sequenzflüsse mit Subprozessen 98

10.4 Nachrichtenflüsse 99

10.5 Schleifen 99

10.6 Kompensationen 101

10.7 Prozessunterbrechung 101

10.8 Handlung durch Ereignisse 101

10.9 Transaktionen 103

11 Gateways 109

11.1 Grundlagen 109

11.2 Exclusive Gateway - datenbasiert 112

11.2.1 Verzweigend 112

11.2.2 Verschmelzend 113

11.3 Exclusive Gateway - ereignisbasiert 114

11.3.1 Verzweigend 115

11.3.2 Verknüpfend 117

11.4 Parallel Gateway 119

11.4.1 Verzweigend 120

11.4.2 Verknüpfend 121

11.5 Parallel Gateway - ereignisbasiert 122

11.6 Inclusive Gateway 124

11.7 Complex Gateway 129

11.7.1 Verzweigend 131

11.7.2 Verknüpfend 132

11.8 Kontrollfluss durch Kompensation 134

12 Muster in Geschäftsprozessen 139

13 Choreographie 141

14 Prozessmodelle 143

14.1 Buchausleihe 143

14.2 Auftragsabwicklung - hoch aggregiert 144

14.3 Flug- und Hotelbuchung 145

14.4 Flug- und Hotelbuchung aggregiert 148

14.5 Kreditunterlagen prüfen 149

14.6 Angebotserstellung im Anlagenbau 150

14.7 Auftragsstart im Anlagenbau 162

15 Glossar 163

15.1 A 163

15.2 B 163

15.3 C 164

15.4 E 164

15.5 G 164

15.6 I 165

15.7 K 165

15.8 L 166

15.9 N 166

15.10 O 166

15.11 P 166

15.12 R 167

15.13 V 167

15.14 W 168

16 Index 169

17 Literatur 171

18 Anhang 175

Abkürzungsverzeichnis

Die Abkürzungen in den Business Process Diagrams (BPDs) werden beim jeweiligen Prozessmodell erläutert.

1 Einleitung

1.1 Modelle, Modellierung

Es gibt zwei Gründe für die Modellbildung in dem hier betrachteten Bereich, für die Wahrnehmung der Organisationsrealität über modellhafte Vorstellungen [Anmerkung] . Der erste liegt in der immer mehr gestiegenen Komplexität der Unternehmensrealität. Diese führte dazu, dass sie gar nicht mehr beherrschbar ist ohne systematische Wahrnehmung, ohne Durchdringung mit einem Wahrnehmungswerkzeug.

Der zweite entsteht durch die Notwendigkeit der Softwareerstellung. Software basiert immer auf einem Modell der Realität, auf verschiedenen Ebenen. D.h., vor der Programmierung ist die Modellierungsarbeit zu leisten. Angefangen bei der elementaren Systemanalyse für die eingesetzten Systeme über die Geschäftsprozessmodellierung bis hin zur Unternehmensmodellierung, wo das Unternehmen als Ganzes (mit seiner Umwelt) ins Auge gefasst wird.

Modellierung bedeutet immer Abstraktion, d.h. Konzentration auf das, was zum jeweiligen Zeitpunkt als wesentlich erachtet wird. Insofern ist (natürlich) die Modellierung der Unternehmensrealität zeitbezogen. Derzeit ist es so, dass Geschäftsprozesse im Mittelpunkt dieser Anstrengungen stehen, ergänzt um das eingeführte ältere Instrumentarium aus der Organisationslehre.

Modellierung an sich hat natürlich noch viele weitere Aspekte, die hier nicht betrachtet werden können. Auf einen soll aber hingewiesen werden, weil er gerade Bedeutung gewinnt für die Prozessmodellierung. Er hat mit „Modellierung“ zu tun, wie sie die Informatik sieht. Hier finden sich (beispielhaft: [Kastens und Büning 2008]) nicht nur Algorithmen, Logik, Petri-Netze usw., sondern auch die für unser Thema wichtigeren Abschnitte Modellierung mit Graphen und Modellierung von Abläufen, wobei hierbei Automaten genannt werden. Mit Automaten kommen Geschäftsprozesse inzwischen sehr eng in Kontakt, weil in Anwendungsprogramme gefasste Geschäftsprozesse so etwas wie (softwaretechnische) Automaten darstellen. Vgl. dazu Kapitel 13 und 14 in [Staud 2010] wo Zustandsautomaten der UML grundsätzlich aber auch in Hinblick auf ihre Eignung für die Prozessmodellierung betrachtet werden.

Organisation vs. Unternehmen

Üblicherweise denkt man, wenn man von Geschäftsprozessen spricht, an Unternehmen und an die Wertschöpfung, die mit ihrer Hilfe erzielt werden soll. Dies ist aber nicht ausreichend. Auch andere Organisationen aller Art und in allen Bereichen der Gesellschaft (Öffentliche Verwaltung, Hochschulen, (öffentliches) Gesundheitswesen, politische Institutionen, usw.) erbringen ihre Leistung durch Geschäftsprozesse.

Da aber nun mal Wertschöpfung normalerweise nur in wirtschaftlich handelnden Organisationen - sprich Unternehmen - stattfindet, wird hier von Unternehmen die Rede sein, wenn es um den Ort geht, wo versucht wird, Wertschöpfung zu realisieren. Bei all den anderen Organisationen muss dieses Ziel ersetzt werden durch das, die zu erbringenden Aufgaben mit einem möglichst effektiven und effizienten Einsatz von Mitteln zu erreichen.

1.2 Aufbau der Arbeit

Der Aufbau des Textes wie folgt:

• Nach der Einleitung folgt eine zusammenfassende Darstellung zum Gegenstand der Arbeit, Geschäftsprozesse. Dabei werden die Definition(en), die Eigenschaften und Komponenten vorgestellt.
• In Kapitel 3 wird der aktuelle Stand der Geschäftsprozessmodellierung dargestellt und auf die erwartete zukünftige Entwicklung eingegangen.
• Mit dem vierten Kapitel erfolgt der Übergang zur Methode BPMN, indem betrachtet wird, wie die Urheber der Methode Geschäftsprozesse sehen.
• Das fünfte Kapitel bringt anhand einführender Beispiele eine erste Annäherung an die Methode.
• Mit Kapitel 6 beginnt die Abbarbeitung der Methodenelemente. Dazu wird betrachtet, wie die BPMN-Autoren die Tätigkeiten erfassen, aus denen jeder Geschäftsprozess besteht.
• Die den Prozess realisierenden Akteure werden in Kapitel 7 betrachtet.
• Informationen und ihre Verarbeitung in Kapitel 8.
• Geschäftsprozesse werden wesentlich durch Ereignisse gesteuert. Diese sind Gegenstand von Kapitel 9.
• Eine gegenüber der Einführung in Kapitel 5 vertiefte Betrachtung des Kontrollflusskonzepts folgt in Kapitel 10.
• Geschäftsprozesse benötigen zu ihrer Darstellung Verzweigungen und Verschmelzungen des Kontrollflusses. Die Elemente zu deren Darstellung werden in der BPMN Gateways genannt und in Kapitel 11 vorgestellt.
• Ähnlich wie in vielen anderen irgendwie strukturierten Bereichen (Daten, Programme, menschliches Verhalten, ...) gibt es auch hier Muster. In Geschäftsprozessen und - entsprechend - in den Prozessmodellen. Einige davon werden in Kapitel 12 betrachtet.
• Ein kurzer Blick auf das Thema Choreographie wird in Kapitel 13 geworfen.
• Aus inzwischen schon jahrzehntelanger Erfahrung mit Modellierungsmethoden weiß ich, dass Beispiele sehr hilfreich sind beim Kennlernen der Methode. Deshalb werden in Kapitel 14 zahlreiche Beispiele von Prozessmodellen vorgestellt.
• Begriffe, die zwar verwendet werden, aber nicht zum eigentlichen Themenbereich des Buches gehören, werden im Glossarium erläutert. Die Kennzeichnung im Text erfolgt durch einen Pfeil (à) vor dem entsprechenden Begriff.

1.3 Methode BPMN

Die Business Process Modeling Notation (BPMN) wird von ihren Autoren als DIE Methode zur Prozessmodellierung gesehen. Sie soll die Lücke zwischen einfachen "Business-Anwendern" und Programmnähe schließen. Überraschenderweise scheinen sie anzunehmen, dass "einfache Anwender" Flussdiagramme verwenden [OMG 2009, S. 11]. Dies ist schon erstaunlich. Die Methoden von außerhalb der USA scheinen die Autoren nicht zu kennen, nicht mal die doch in Deutschland und Europa weit verbreiteten Ereignisgesteuerten Prozessketten (EPK).

Bezeichnungen: BPMN: Business Process Modeling Notation. Ab Version 2.0: Business Process Model and Notation. BPD: Business Process Diagram

Eine Abgrenzung nehmen sie nur vor gegen "web service-based XML execution languages for Business Process Management (BPM) systems". Sprachen wie BPEL4WS, die sie als zu formal ansehen für "business people".

Ihr Standpunkt ist folgender: "Business people" sind sehr vertraut damit, Geschäftsprozesse in einem "flow-chart format" zu visualisieren - und - es gibt Tausende von "business analysts", die mit Hilfe der "flow charts" untersuchen, wie Unternehmen arbeiten und die damit auch Geschäftsprozesse definieren [OMG 2009, S. 11].

Dadurch sehen sie eine Lücke und die Motivation für BPMN. Denn obiges führt ihrer Ansicht nach zu einer technologischen Lücke ("technical gap") zwischen dem Format der ersten Entwürfe von Geschäftsprozessen und dem Format von Sprachen wie BPEL4WS, die diese Geschäftsprozesse ausführen. Und genau diese Lücke wollen sie überbrücken mit einer formalen Sprache, die die geeignete Visualisierung der Prozesse ("a notation") auf ein geeignetes "execution format" (eine "BPM execution language") abbildet [OMG 2009, S. 11].

Das mit der BPMN verfolgte Ziel ist somit, eine Standardvisualisierungsmethode für Geschäftsprozesse zu liefern, die in einer für die "execution" optimierten "business process language" definiert ist.

Vorgesehene Abdeckung

Die Business Process Modeling Notation soll sich auf Modellierungskonstrukte konzentrieren, die für Geschäftsprozesse geeignet sind [OMG 2009, S. 12]. Nicht betrachtet werden sollen insbesondere:

• Organisationsstrukturen
• Funktionen und ihr Aufbau
• Datenmodelle
• Strategiebetrachtungen
• Geschäftsregeln

1.4 Ziel

Ein Ziel der BPMN-Autoren war Einfachheit, die es aber trotzdem erlauben sollte, die Komplexität, die Geschäftsprozesse nun mal aufweisen, zu beherrschen [OMG 2009, S. 17]. Dabei ensteht für die Autoren ein Konflikt. Einerseits soll die Methode ermöglichen, komplexe Geschäftsprozesse zu modellieren, andererseits soll sie die Abbildung auf "BPM execution languages" erlauben. Die Lösung sehen sie wie folgt:

• Erstens durch die Definition einer Menge von "Kernelementen", die den Anforderungen an eine einfache Darstellungstechnik genügen. Damit sollen die meisten Situationen in Geschäftsprozessen bewältigt werden können.
• Zweitens durch zusätzliche Elemente, mit denen anspruchsvollere Modellierungssituationen bewältigbar sein sollen.
• Drittens durch nicht-grafische Elemente. Diese sollen zusätzliche Informationen liefern, die notwendig sind für eine "execution language" oder andere Modellierungsvorhaben.

Dem Ziel, auch die Grundlagen einer Ausführungssemantik zu ermöglichen, dient, dass nun zusätzlich zur Notation auch ein formales Metamodell definiert wurde.

2 Geschäftsprozesse

Was sind das für "Abläufe" die wir Geschäftsprozesse nennen und die wir mit Ereignisgesteuerten Prozessketten modellieren? Wie sind sie definiert? Was haben sie für Merkmale? Wie ist ihr Aufbau? Welche Herausforderungen bringen Gegenwart und Zukunft für die Prozessmodellierung? Diese Fragen werden hier beantwortet, damit wir den Gegenstand, den wir anschließend modellieren, besser verstehen und damit besser modellieren können.

2.1 Definition(en)

Geschäftsprozesse bestehen - sehr vereinfacht ausgedrückt - aus zielgerichteten aneinandergereihten Tätigkeiten, aus Tätigkeitsfolgen also. Bei solchen Tätigkeiten, die Menschen oder Anwendungsprogramme realisieren, um in Organisationen die gesetzten Ziele zu erreichen, werden in der Fachliteratur die Begriffe Aufgabe und Vorgang verwendet.

Aufgaben

Tätigkeiten sind in der Regel als Aufgaben definiert, die auf unterschiedlichen Ebenen betrachtet werden können. Sozusagen die unterste Ebene stellen die Elementaraufgaben dar. Dies sind nicht weiter zerlegbare oder auf der betreffenden Beschreibungsebene nicht weiter zerlegte Aufgaben. Mehrere solche Elementaraufgaben werden dann in einer Aufgabe zusammengefasst. Wir übernehmen folgende Definition, die auch auf die selbstverständliche Erwartung eines Ergebnisses und auf die Durchführbarkeit durch Menschen oder Maschinen hinweist [Österle 1995, S. 45]:

Definition Aufgabe

Eine Aufgabe ist eine betriebliche Funktion mit einem bestimmbaren Ergebnis. Sie wird von Menschen und/oder Maschinen ausgeführt.

So definierte Aufgaben können ebenfalls zusammengefasst werden und dies auf mehreren Stufen, u.U. bis zu der Ebene, wo sich der gesamte Unternehmenszweck in einer einzigen Aufgabe findet (z.B. „Gewinn erzielen“). Dies wird auch Aggregation genannt. Damit wird deutlich, was dann bei der konkreten Modellierung von Geschäftsprozessen eine wichtige Rolle spielt:

Die in Geschäftsprozessen zu leistenden Aufgaben können auf unterschiedlichen Aggregationsniveaus betrachtet werden. Man kann in der Prozessmodellierung Aufgaben also aufteilen [Anmerkung] oder zusammenfassen.

Für die Prozessmodellierung hat dies die Konsequenz, dass die Aggregationsebene, auf der die Aufgaben betrachtet werden, ein subjektiver Faktor ist, der durch die Modellierer oder auch durch den Zweck der Modellierung festgelegt werden kann. Meist wird eine Prozessmodellierung an den Stellen detaillierter, an denen Optimierungsbedarf vermutet wird und da weniger detailliert, wo man nur modelliert, um den Prozess als Gesamtheit modellieren zu können (vgl. hier das Beispiel in [Staud 2006, Abschnitt 6.2]). Oftmals werden aber auch ganz bewusst mehrere unterschiedliche Aggregationsniveaus modelliert, z.B. um Übersichtsdarstellungen zu erhalten. Dies führt zur (à)vertikalen Dimension der Prozessmodellierung.

Dieselbe Subjektivität liegt im Übrigen bezüglich der Länge von Geschäftsprozessen vor. Man kann z.B. eine Auftragsabwicklung als Ganzes, als einen Geschäftsprozess betrachten oder die einzelnen Abschnitte jeweils getrennt, also z.B. die Angebotserstellung, die Auftragsbearbeitung, die Materialbeschaffung, die Produktion, die Kalkulation, die Auslieferung, usw. Auch hier erfolgt die Festlegung nur durch die Modellierer oder den Zweck der Modellierung. Durch diesen subjektiven Faktor kommt man zu sehr unterschiedlichen Ergebnissen bezüglich der Zahl der Geschäftsprozesse, wenn man vergleichbare Unternehmensprozessmodelle betrachtet.

Funktionen

In der Prozessdiskussion wie auch in der konkreten Prozessmodellierung wird mit Funktion ein weiterer Begriff benutzt, der weitgehend mit dem Aufgabenbegriff übereinstimmt, der aber stärker auf die Modellierungsumgebung Bezug nimmt. Mertens versteht unter einer Funktion eine Tätigkeit

"..., die auf die Zustands- oder Lageveränderung eines Objektes ohne Raum- und Zeitbezug abzielt. Eine Funktionsbezeichnung besteht aus zwei Komponenten, einem Verb (Verrichtung) und einem Substantiv (Objekt), auf das sich dieses Verb bezieht (z.B. „Bestellgrenze ermitteln“)." [Mertens 2013, S. 41]

Solche Aufgaben bzw. Funktionen werden in allen Methoden zur Prozessmodellierung benötigt. Wer sich etwas tiefer mit der Prozessmodellierung beschäftigt, muss allerdings damit leben, dass sie unterschiedlich benannt werden: Funktionen in Ereignisgesteuerten Prozessketten (EPKn) Aktionen (actions) bei den Aktivitätsdiagrammen (der UML) und Aufgaben (task) in der Methode Business Process Model and Notation (BPMN).

Mit Objekten sind hier betriebswirtschaftlich relevante Objekte bzw. Geschäftsobjekte gemeint. Dieser Objektbegriff stimmt weitgehend (bei den meisten Autoren allerdings unausgesprochen bzw. unbewusst) mit dem allgemeinen Objektbegriff der objektorientierten Theorie überein. Es handelt sich immer um Informationsträger (z.B. eine Rechnung) mit Eigenschaften (Attributen) und einem Verhalten (bzw. zulässigen Veränderungen). Z.B. um Rechnungen mit Attributen wie Rechnungsnummer, Rechnungsdatum, Rechnungsempfänger, usw., die bezahlt oder storniert werden können.

Vorgänge

Der erste Schritt von einzelnen Aufgaben zu einer sequenziellen Folge von Aufgaben wird mit der Definition von Vorgängen gemacht. Mit Bullinger/Fähnrich sind Vorgänge

"Abfolgen von Tätigkeiten, die zur Realisierung von Aufgaben ausgeführt werden." [Bullinger und Fähnrich 1997, S. 19]

Sie beziehen organisatorische Dimensionen (z.B. Stellen) in die Bearbeitung ein. Standardisierbare Vorgänge in Unternehmen werden auch als „Workflow“ bezeichnet. Sie lassen sich auf der Basis von vier Kategorien beschreiben:

• Ereignisflüsse steuern die Aktivierung von Aufgaben in Abhängigkeit von auftretenden Ereignissen. Sie bewirken damit Zustandsänderungen des Systems [ebenda].
• Daten- bzw. Objektflüsse modellieren Eingangsinformationen oder -objekte, die zur Aufgabenausführung benötigt werden. Weiterhin modellieren sie die Verwendung der Resultate in nachfolgenden Aufgaben.
• Aufgabenträger repräsentieren Stellen einer Organisation und bearbeiten Aufgaben.
• Ressourcen sind Materialien oder Betriebsmittel, die zur Aufgabenausführung benötigt werden. Dies können auch Aufgabenträger sein.

Ganz ähnlich Scheer, der einen betriebswirtschaftlichen Vorgang wie folgt definiert:

Definition Vorgang

"Ein Vorgang ist ein zeitverbrauchendes Geschehen, das durch ein Startereignis ausgelöst und durch ein Endereignis abgeschlossen wird. Einem Vorgang können in Abhängigkeit von Vorgangsergebnissen unterschiedliche Ablaufverzweigungen, auch Rücksprünge, folgen." [Scheer 1998, S. 20]

Vorgänge wiederum bilden Geschäftsprozesse. Damit ist schon recht viel von dem angeführt, was bei einer Modellierung von Geschäftsprozessen berücksichtigt werden muss:

• Der Kontrollfluss, denn dieser stellt die oben angeführten Ereignisflüsse dar. Ohne das Wissen um die korrekten Abläufe der einzelnen Vorgänge bzw. ohne Geschäftsregeln, die sie festlegen, gibt es keine Geschäftsprozesse.
• Die verwendeten Daten bzw. Datenbanken. Denn die Zustandsänderungen des Systems sind die Änderungen des Datenbestandes, die sich aus der Leistungserbringung ergeben.
• Datenflüsse entlang der Geschäftsprozesse aber auch in den einzelnen Tätigkeiten. Vor allem auch unternehmensübergreifend - heute auf der Basis von Internet und XML.
• Objektflüsse, Gegenstände der Leistungserbringung. Auch Geschäftsobjekte, mit denen wir auch wieder die Daten und Datenbanken berühren, denn natürlich werden heute Geschäftsobjekte üblicherweise in der Unternehmensdatenbank abgespeichert.
• Einzelne Tätigkeiten, basierend auf Aufgaben.
• Leistungserbringer als Aufgabenträger. Hier finden wir heute sehr oft auch Anwendungsprogramme.
• Die Organisationsstruktur durch das Stellenkonzept.
• Die für die Leistungserbringung benötigten Materialien und Ressourcen.

Dies und noch ein wenig mehr muss in der Prozessmodellierung berücksichtigt werden, will sie denn aussagefähig sein.

Definition Geschäftsprozesse

In [Staud 2006, S.9] wurden Geschäftsprozesse in Organisationen - basierend auf der Analyse der Definitionen in der Literatur und den eigenen praktischen Erfahrungen - wie folgt definiert:

Definition Geschäftsprozess

Ein Geschäftsprozess besteht aus einer zusammenhängenden, abgeschlossenen Folge von Tätigkeiten, die zur Erfüllung eines Organisationsziels notwendig sind. Die Tätigkeiten werden von Aufgabenträgern in organisatorischen Einheiten oder Programmen unter Nutzung der benötigten Produktionsfaktoren geleistet. Unterstützt wird die Abwicklung der Geschäftsprozesse durch die IT der Organisation.

Ergänzt wurden die Anwendungsprogramme als Aufgabenträger. Dies ist in einer Zeit zunehmender Automatisierung von Geschäftsprozessen unabdingbar (vgl. hierzu Abschnitt 12.3 in [Staud 2014]). Geschäftsprozesse leisten somit die Transformation von beschafften Produktionsfaktoren in verkaufte Produkte bzw. Dienstleistungen. In ihrem Zusammenhang beschreiben die Geschäftsprozesse auch die (à)Wertschöpfungskette des Unternehmens.

Damit liegen wichtige Elemente für die Modellierung von Geschäftsprozessen vor:

• Einzelne Tätigkeiten, aus denen der Geschäftsprozess zusammengesetzt ist.
• Der Zusammenhang zwischen diesen, er wird später Kontrollfluss bzw. Sequenzfluss (BPMN) genannt.
• Einbettung des Geschäftsprozesses in die gesamte Geschäftstätigkeit des Unternehmens durch Angabe seines Zieles.
• Aufgabenträger, d.h. die Antwort auf die Frage, "Wer erbringt die Leistung?"
• Hinweis auf die Automatisierung von Geschäftsprozessen (Programme als Aufgabenträger).
• Produktionsfaktoren und ihr Verbrauch im Rahmen der Prozessdurchführung.
• Unterstützung der Prozessrealisierung durch die IT.

Alles dies muss eine Methode zur Modellierung von Geschäftsprozessen berücksichtigen.

Hier noch einige weitere Ergebnisse des Literaturstudiums. Hess definiert, ausgehend von einer systemorientierten Organisationslehre und der Zerlegung einer Organisation in die Subsysteme (à)Aufbauorganisation, (à)Ablauforganisation und Informationssystem einen Prozess

"… als ein Subsystem der Ablauforganisation, dessen Elemente Aufgaben, Aufgabenträger und Sachmittel und dessen Beziehungen die Ablaufbeziehungen zwischen diesen Elementen sind." [Hess 1996, S. 13]

und gibt damit wiederum einen deutlichen Hinweis auf den Kontrollfluss.

Das Gemeinsame zahlreicher anderer Definitionen zu Geschäftsprozessen (z.B. in [Keller und Teufel 1997], [Hess 1996], [Becker und Vossen 1996], [Rump 1999]) kann so zusammengefasst werden:

• Geschäftsprozesse haben ein Ziel oder auch mehrere, abgeleitet aus den OrganisationszieleDie Gesamtaufgabe eines Geschäftsprozesses kann in Teilaufgaben zerlegt werden (im Extremfall kann ein Geschäftsprozess auch aus nur einer Aufgabe bestehen).
• Die Aufgaben werden von Aufgabenträgern wahrgenommen, die Inhaber von (à)Stellen sind, die wiederum in Organisationseinheiten gruppiert sind. In den letzten Jahren wurden immer öfter Programme zu Aufgabenträgern.
• Die Aufgaben werden entweder manuell, teilautomatisiert oder voll automatisiert erfüllt.
• Ein Geschäftsprozess liegt in der Regel quer zur klassischen Aufbauorganisation, d.h. er tangiert meist mehrere Abteilungen.
• Für die Erfüllung der Aufgaben werden die Unternehmensressourcen benötigt.
• Geschäftsprozesse benötigen zu ihrer Realisierung Informationsträger aller Art.

Das gibt Hinweise auf weitere Elemente einer Modellierungstheorie. Zum einen den auf eine Strukturierung des Automatisierungsgeschehens in manuell, teilautomatisiert und vollautomatisiert, die hier im weiteren auch übernommen wird. Zum anderen den Hinweis auf die notwendigen Informationsträger.

Soweit die Literaturlese und die für die Modellierungsmethode gewonnenen Erkenntnisse. Nun noch einige Abklärungen.

Modell vs. Instanz

Ähnlich wie in der objektorientierten Theorie wird auch hier zwischen dem allgemeinen/abstrakten Modell und der konkreten Realisierung unterschieden: Das allgemeine Prozessmodell mit allen denkbaren Durchgängen auf der einen Seite und die konkrete Realisierung eines Durchgangs (Instanz) auf der anderen Seite (so auch [Rump 1999, S. 19f]).

Ein Prozessmodell (auch Schema genannt) gibt sämtliche möglichen Durchgänge, sämtliche vorgedachten Realisierungen eines Geschäftsprozesses an. Eine Instanz eines Geschäftsprozesses ist eine konkrete Realisierung, ein bestimmter Durchgang durch den Prozess.

Wenn also im Prozessmodell eine Entscheidungssituation dargestellt ist, mit allen möglichen Entscheidungen, wird bei einer Instanz des Geschäftsprozesses genau eine der Alternativen aktiv.

Vgl. zur Thematik Token und Instanzen Abschnitt 4.6 und Abschnitt 11.6 mit Instanzenbeispielen zum Inclusive Gateway.

2.2 Konzept Geschäftsprozess

In den Anfangsjahren der Organisationslehre und bis in die 1960-er Jahre hinein konzentrierte man sich bei Optimierungsbemühungen auf einzelne Tätigkeiten, ihre Stelleninhaber (àStellen) und die Einbettung der Tätigkeiten in die Abläufe. Danach kam der Geschäftsprozessgedanke auf. Mit dem Konzept des Geschäftsprozesses verändert sich die Perspektive. Jetzt standen längere zusammenhängende Folgen von Tätigkeiten, die zur Erledigung einer größeren Aufgabe nötig sind, im Mittelpunkt der Betrachtungen. Unter Umständen sogar eine Folge von Tätigkeiten, die in Bezug auf das betrachtetet Unternehmen abgeschlossen ist. Das ist auch heute noch der Stand der Technik. Die meisten Bemühungen, die Abläufe in den Unternehmen effektiver und effizienter zu gestalten, starten mit einer Analyse der Geschäftsprozesse und deren Optimierung.

Beispiele

Hier nun noch einige Beispiele für Geschäftsprozesse, angelehnt an die typische Struktur in Industrieunternehmen:

• Angebotserstellung (Erstellung eines Angebots, nachdem eine Anfrage einging)
• Auftragsvergabe (Vergabe eines Auftrags an einen Lieferanten)
• Beschaffung (z.B. von Teilen für die Produktion)
• Mahnwesen (z.B. als regelmäßiger Abgleich von offenen Posten und Zahlungseingängen).

und, ein meist sehr langer Geschäftsprozess,

• die Auftragsabwicklung bzw. Leistungserbringung (vom Eintreffen des Auftrags beim Unternehmen bis zur Auslieferung der Ware beim Kunden).

Selbstverständlich gibt es auch kurze Geschäftsprozesse in dem Sinn, dass sie nicht viele Einzeltätigkeiten umfassen, z.B.

• Kundenbefragung (z.B. im Rahmen des Customer Relationship Managements (CRM)).
• Personaleinstellung
• Zahlungsabwicklung
• Genehmigung einer Investition oder
• Fakturierung

2.3 Eigenschaften und Komponenten

2.3.1 Eigenschaften

Es gibt natürlich sehr viele betrachtenswerte Eigenschaften von Geschäftsprozessen und Prozessmodellen, vgl. dazu die einschlägige Literatur (z.B. [Schmelzer und Sesselmann 2013] oder [Becker, Kugeler und Rosemann 2012]). Hier konzentrieren wir uns auf die wichtigsten, das sind auch diejenigen, die am meisten Bedeutung für die Prozessmodellierung haben.

Detaillierungsgrad der Prozessmodellierung.

Mit diesem Merkmal erfasst man, wie detailliert ein Geschäftsprozess modelliert ist. Wurden, wie in den Anfangsjahren der Prozessmodellierung (den 1970er-Jahren), nur einige Meilensteine des Prozesses erfasst? Oder alle wichtigen Abschnitte in grober Detaillierung? Oder ist der Gesamtprozess detailliert modelliert? Letzteres bedeutet, dass alle von den Beteiligten zu lösenden Aufgaben detailliert erfasst und modelliert sind.

Eine detaillierte Modellierung ist Voraussetzung für die Umsetzung in Software, denn nur dann können die Modelle im Anforderungsmanagement für die Softwareerstellung dienen. Sie ist natürlich auch Voraussetzung für die vollständige Umsetzung in Software und damit die Automatisierung.

Sie ist aber nicht immer möglich. Detaillierung ist umso leichter realisierbar, je standardisierter die entsprechenden Prozessabschnitte sind, weil man dann die einzelnen Abschnitte kennt. Je weniger Standardisierung, z.B. im Bereich kreativer Vorgänge (Strategien entwickeln, Forschung, Entwicklung), desto weniger detailliert kann die Prozessmodellierung sein. Wir sehen aber alle täglich bei unseren Kontakten mit gegenüber den Kunden (fast) voll automatisierten Geschäftsprozessen im Internet, dass zumindest Komplexität kein Hindernis für eine detaillierte Modellierung und Umsetzung in Software ist.

Im Prozessmodell sichtbar wird der Detaillierungsgrad ganz einfach durch die Aufteilung der Tätigkeiten. Stellen diese Elementartätigkeiten dar, ist die Detaillierung hoch. Wurde oft aggregiert, u.U. so, dass konkrete einzelne Handlungen nicht mehr darstellbar sind, ist der Detaillierungsgrad niedrig.

IT-Abdeckung

Mit dieser Eigenschaft wird erfasst, welcher Anteil des Prozesses durch IT unterstützt wird, d.h. durch Computerprogramme und die zugehörige Hardware. Die Betonung liegt hier auf Unterstützung, in Abgrenzung zu Automatisierung, d.h. vollständiger Realisierung des Geschäftsprozesses durch Software. Unterstützung der Abwicklung der Geschäftsprozesse durch Anwendungssoftware ist heute Standard, nur das Ausmaß ist unterschiedlich. Sind wirklich nur noch die Funktionen im Geschäftsprozess nicht IT-gestützt realisiert, die Entscheidungen darstellen, oder gibt es Abschnitte, die trotz der Möglichkeit der IT-Unterstützung diese nicht bekommen haben.

Alles in allem ist die IT-Abdeckung inzwischen, v.a. seit der Etablierung prozessorientierter integrierter Standardsoftware (ERP-Software), sehr hoch. Heute werden meist fast alle Abschnitte der Geschäftsprozesse IT-gestützt realisiert.

In einer Prozessmodellierung kann die IT-Unterstützung erfasst werden, indem bei den einzelnen Tätigkeiten vermerkt wird, ob sie mit Softwareunterstützung realisiert werden oder nicht. Indem also bei einer Tätigkeit nicht nur angegeben wird, wer sie realisiert, sondern auch mit Hilfe welcher Anwendungssoftware. Sie kann auch durch die modellierten Datenobjekte erkannt werden. Bei IT-Abdeckung sind diese Teil des Datenbestandes einer Anwendungssoftware und (hoffentlich) als solche gekennzeichnet.

Voraussetzung für eine IT-Abdeckung ist allerdings die oben angemerkte detaillierte Modellierung, also im Rahmen einer Beschaffung nicht Teile beschaffen, sondern zulässige Lieferanten bestimmen, Lieferanten anfragen, Konditionen klären, Bestellung formulieren, Bestellung versenden, usw. Etwa so wie in einer Standardprozessmodellierung (SPM) (vgl. Abschnitt 3.1 und das Stichwortverzeichnis). Danach können dann diese elementaren Funktionen in einer noch detaillierteren Ebene in Programmkonstrukte abgebildet werden.

Erfolgt eine solche Prozessmodellierung zur Vorbereitung der Programmierung einer integrierten prozessorientierten Software ist sie Teil des Anforderungsmanagements (Requirements Engineering) im Entwicklungsprojekt.

Automatisierungsgrad

Eine weitere wichtige Eigenschaft von Prozessen oder Prozessabschnitten ist der Automatisierungsgrad. Damit ist der Anteil an der Aufgabenerfüllung gemeint, der ohne menschliches Zutun allein durch die Informationstechnologien erledigt wird. In vielen Bereichen strebt man nach einem möglichst hohen Automatisierungsgrad. Dort, wo es sich um stark standardisierte Abläufe mit einfachen Entscheidungsprozessen handelt, hat man dieses Ziel weitgehend erreicht. Ein einfaches Schema ist "voll automatisiert, teilweise automatisiert, nicht automatisiert".

Bei Internetunternehmen liegen inzwischen gegenüber den Kunden solche voll automatisierten Geschäftsprozesse vor. Auf andere Weise wäre auch das Geschäftsmodell nicht denkbar.

Voraussetzung für eine Automatisierung ist die oben angesprochene detaillierte Modellierung der Geschäftsprozesse, d.h., sie ist (natürlich) nur möglich bei standardisierbaren Prozessen. Der Unterschied zur Unterstützung im obigen Sinn liegt darin, dass jetzt auch die Entscheidungsvorgänge "in Software gegossen" sind. D.h., um einige einfache Beispiele zu bringen, die Nachbestellung für das Lager wird automatisch durchgeführt, die Kaufempfehlung automatisch generiert (weshalb sie uns oft zum Schmunzeln bringt) und auch der Umgang mit anscheinend zahlungsunwilligen Kunden wird ein ganzes Stück weit durch die Software gesteuert (vgl. hierzu das "Prozessbeispiel" Rechnung in [Staud 2010, Kapitel 13]).

Die Erfassung der durch Software realisierten Geschäftsprozessabschnitte geschieht über die Angabe der Träger der durchgeführten Tätigkeiten. Dort wo üblicherweise eine Organisationseinheit steht, wird dann die Anwendungssoftware vermerkt - ohne (direktes) menschliches Mitwirken.

Betrachtet man z.B. die Geschäftsprozesse eines typischen Internetunternehmens im B2C, ist in wichtigen Abschnitten neben dem Kunden nur noch Software aktiv (Ware anbieten, Vorschläge machen, Auftrag festhalten, (virtuellen) Warenkorb befüllen, usw.). Dieser Bereich reicht weit in die automatisierbaren Abschnitte des Finanzwesens und die Logistik hinein und wird ständig ausgedehnt.

Beim Anforderungsmanagement für die entsprechende Software muss nach einer Standardprozessmodellierung die nächste "tiefere" Modellierungsebene programmnah gewählt werden. Sie wird in diesem Buch programmnahe Prozessmodellierung genannt. Damit soll eine Prozessmodellierung bezeichnet werden, die - z.B. im Rahmen des Requirement Engineerings - unmittelbar der Vorbereitung der Programmierung dient. Vgl. dazu Abschnitt 12.5 in [Staud 2014] sowie [Staud 2010] für die dann einzusetzenden Methoden der UML.

Prozessintegration

Eine weitere wichtige Eigenschaft von Geschäftsprozessen stellt das Ausmaß der Prozessintegration dar. Mit ihr ist die Durchgängigkeit des Geschäftsprozesses über verschiedene traditionelle Organisationsbereiche, wie z.B. Beschaffung, Einkauf, Produktion, Verkauf, Rechnungs- und Personalwesen gemeint. Daneben natürlich, wenn auch erst seit einigen Jahren, die Durchgängigkeit über Unternehmensgrenzen hinweg. Diese Durchgängigkeit ist i.d.R. unternehmensintern inzwischen gegeben, an der unternehmensübergreifenden wird noch gearbeitet.

Ein Beispiel für eine nicht vorhandene Durchgängigkeit ist, wenn ein Geschäftsobjekt von einem Prozessabschnitt zum nächsten nicht einfach weitergegeben werden kann, sondern neu erfasst werden muss. Die Bruchstellen nennt man Medienbrüche. Sie werden in der Prozessmodellierung nicht unbedingt deutlich, weil da einfach dasselbe Geschäftsobjekt im nächsten Prozessabschnitt auftaucht. Es muss deutlich gemacht werden, u.a. durch eine Modellierung des Datentransports.

Hier noch einige weitere Beispiele für Medienbrüche:

• Ausgabe von Information in der einen Software, händische Eingabe bei der nächsten (kein Scherz, dies hat der Verfasser wirklich erlebt).
• Eingehende Information ("Auftragseingang") muss bearbeitet werden, um sie in die eigene Anwendungssoftware zu bringen.
• Für eine Anwendung (z.B. Prognoserechnung) können Informationen aus den operativen Daten nicht in der Form bereitgestellt werden, in der sie benötigt werden

Im Kern ist es so: Muss dieselbe bereits erfasste Information nochmals erfasst werden, liegt ein Defizit in der Prozessintegration vor.

Dieses Merkmal kann in der Prozessmodellierung durch die exakte Erhebung der Datenobjekte bei den einzelnen Tätigkeiten erfasst werden. Zum Beispiel, bei einem Rechnungseingang, zuerst Rechnung beim Zentralsekretariat, das den Posteingang abwickelt. Dann Rechnung beim Finanzwesen. Hier war dann ein Informationstransport nötig. Im Idealfall wurde die Rechnung bei der ersten Tätigkeit in der unternehmensweiten integrierten Datenbank abgespeichert und bei der zweiten wurde darauf zugegriffen. Bei Medienbrüchen klappt das aber nicht. Da muss z.B. die Rechnung neu eingegeben, gescannt, usw. werden. Dies stellt den Medienbruch dar, der ausdrücklich modelliert werden sollte.

Geht es um den Austausch von Datenobjekten zwischen verschiedenen Organisationen spricht man von semantischer Prozessintegration, wenn bei der Weitergabe nicht nur keine Medienbrüche auftreten, sondern wenn die Semantik des Datenobjekts (Rechnung, Lieferschein, Koordinierungsinformation, …) beim Empfänger erkannt wird. Daran wird zur Zeit in vielen Unternehmen im Rahmen des B2B gearbeitet.

Datenintegration

Eine andere wichtige Eigenschaft ist das Ausmaß der Datenintegration, d.h. der Integration der Datenbestände, die für die einzelnen Tätigkeiten des Geschäftsprozesses benötigt werden. Auch sie ist von großer Bedeutung, da nicht-integrierte Datenbestände Reibungsverluste bedeuten. Konkret kann dies folgendes bedeuten: Daten zu einem Bereich, zu einer Aufgabe, für einen Geschäftsprozess …

• …liegen in verschiedenen digitalen oder auch nicht-digitalen Datenbeständen vor, sind also zersplittert.
• …liegen in verschiedenen Datenbeständen vor und sind nicht übereinstimmend (abweichende Artikeldaten, Adressen, usw.)

Eine Quelle für solche Defizite ist neben Datenbankinkompetenz und Schlamperei oftmals der Zusammenschluss von Organisationen. Dieser bewirkt ja auch den Zusammenschluss der IT und damit der Datenbanken. Beides ist eine komplexe Aufgabe und wird oft nicht umfassend gelöst oder erst mit Verspätung. So entstehen dann Beiträge zur Stammdatenkrise.

Wie erkennt man nun in der Prozessmodellierung solche Defizite in der Datenintegration? Durch eine exakte Erfassung der Informationen, die bei den einzelnen Tätigkeiten erzeugt oder benutzt werden. Hier sollte, wenn genügend detailliert und genau modelliert wird, diese Zersplitterung aufgedeckt werden. Widersprüchliche Datenbestände allerdings können im Rahmen der Prozessmodellierung nicht geklärt werden. Dazu bedarf es weiterer Anstrengungen, zu denen ein intensiver Blick in die Datenbankstrukturen gehört [Anmerkung] .

2.3.2 Komponenten

Komponenten von Geschäftsprozessen wurden oben schon von der Definition abgeleitet. Eine immer noch tragfähige Auflistung, die mit obigem weitgehend übereinstimmt, legte Scheer schon vor vielen Jahren vor. Er unterscheidet folgende Komponenten bei computergestützten Geschäftsprozessen [Scheer 1997] (vgl. auch die komprimierte Darstellung seines ARIS-Konzepts in Abschnitt 13.1 von [Staud 2014]):

• Vorgänge (mit denen die notwendigen Tätigkeiten erfasst werden, wie oben gezeigt)
• Ereignisse (die für den Geschäftsprozess Bedeutung besitzen, auch als betriebswirtschaftlich relevante Ereignisse definiert)
• Zustände (die sich jeweils nach Abschluss einer Tätigkeit in den Daten neu ergeben). Sie ändern sich im Prozessablauf ständig - im Prinzip nach jeder Funktion/Aufgabe.
• Bearbeiter (und Bearbeiterinnen)
• Organisationseinheiten sowie
• Ressourcen der Informationstechnologie

die er dann, nochmals abstrahierend, zu folgenden Elementen seiner formalen Beschreibungssprache Ereignisgesteuerte Prozessketten zusammenfasst:

• Ereignisse
• Funktionen
• Organisationseinheiten
• Datenobjekte

Dies sind dann auch die Elemente, mit denen im Kern jede Methode zur Prozessmodellierung arbeitet, auch die BPMN.

3 Wo steht die Prozessmodellierung heute?

3.1 Basiselemente einer Methode zur Prozessmodellierung

Hinweis: Hier wird wieder der Begriff Tätigkeit verwendet, wenn es um die einzelnen zu lösenden Aufgaben in einem Geschäftsprozess geht, und Tätigkeitsfolge, wenn Prozesse oder Prozessabschnitte gemeint sind. Der Grund ist einfach der, dass die Begriffe Aktion, Aktivität und auch Funktion durch die Methoden (Ereignisgesteuerte Prozessketten, Aktivitäten, Business Process Model and Notation) besetzt sind.

Die Basiselemente hängen natürlich davon ab, auf welcher Ebene die Modellierung erfolgt. Modelliert man sehr hoch aggregiert, bleiben nur wenige Elemente übrig, die ganze Unternehmensbereiche erfassen und die Erfassung der Beziehungen zwischen ihnen reduziert sich auf einfache Ablaufzusammenhänge. Modelliert man sehr detailliert, evtl. systemnah zur Vorbereitung der Programmierung, landet man bei einzelnen Workflows mit ihrer komplexen programmnahen inneren Struktur.

Hier soll von einer Ebene der Prozessmodellierung ausgegangen werden, bei der eine Handlung eines Prozessteilnehmers („Kalkulation erstellen“, „Brief schreiben“, „an Sitzung teilnehmen“) in ein Basistheorieelement (eine Tätigkeit, Aktivität, Funktion) findet. Auf dieser Detaillierungsebene bleiben auch die Geschäftsobjekte (Rechnung, Lieferschein, usw.) als Ganzes erhalten, verschwinden also nicht, wie auf höheren Aggregationsniveaus oder werden zerlegt wie in der programmnahen Prozessmodellierung. Dies soll Standardprozessmodellierung (SPM) genannt werden.

Hier nun also die Frage, welche Elemente eine Methode zur Modellierung von Geschäftsprozessen im Sinne einer Standardprozessmodellierung haben muss. Eine solche Betrachtung ermöglicht eine fundierte Einschätzung der Methoden, auch bzgl. Ihrer Tauglichkeit für bestimmte Anwendungen. Außerdem wird damit ein Vergleich der Methoden möglich.

Sozusagen die Grundannahme ist, dass jede Modellierung von Tätigkeitsfolgen einen Kontrollfluss hat und dass dieser von einer Abfolge von Ereignissen und Tätigkeiten geprägt ist, wobei die Ereignisse das Anstoßen der nachfolgenden Funktion und die Erledigung der vorangehenden signalisieren. Ebenso wird vorausgesetzt, dass der Geschäftsprozess eine Aufgabe zu erfüllen hat und dabei Ressourcen aller Art benötigt.

Hier nun die Theorieelemente, sie sind von (1) bis (12) durchnummeriert:

(1) Elementare Tätigkeiten

(2) Zentraler Gegenstand des Geschäftsprozesses

(3) Träger der Tätigkeiten

(4) Informationen auf Trägern aller Art

(5) Informationsverarbeitung

(6) Nachrichten

(7) Ereignisse

(8) Kontrollfluss

(9) Andere Flüsse (Materialflüsse, Nachrichtenflüsse)

(10) Ebenen - Kapselung

(11) Zeitliche Dimension

(12) Subprozesse

(1) Elementare Tätigkeiten

Es muss ein Theorieelement vorliegen für die Teilaufgaben, in die man die Gesamtaufgabe zerlegt. Bzgl. der unvermeidlichen Subjektivität dieser Zerlegung vgl. die Ausführungen oben sowie zur Abrenzung von Funktionsmodellierung und Prozessmodellierung das Stichwortverzeichnis (Prozess- vs. Funktionsmodellierung).

Liegt eine vertikale Modellierung vor, wird die Standardprozessmodellierung nach "oben" und "unten" erweitert, werden die Tätigkeiten entweder zusammengefasst oder zerlegt. Eine einzelne Tätigkeit auf hoher Ebene, nahe den Wertschöpfungsketten, umfasst sehr viel mehr Tätigkeiten als eine auf der Ebene von Istanalysen. Eine in Systemnähe sehr viel weniger.

In der Standardprozessmodellierung sind Tätigkeiten solche, die einmal ange­toßen, dann ausgeführt und zuletzt beendet werden. Es sind also keine impliziten Schleifen („bleibt aktiv“) vorgesehen, wie bei einigen Theorieelementen der UML (vgl. [Staud 2010, Kapitel 12]).

(2) Zentraler Gegenstand des Geschäftsprozesses

Hier geht es um die Frage, welche Leistung der Geschäftsprozess erbringen soll. Was wird im Geschäftsprozess bearbeitet? Geht es um ein Produkt oder um eine sonstige Leistung. Diese Leistungserbringung ist oft mit Geschäftsobjekten verbunden.

(3) Träger der Tätigkeiten

Dieses Element benennt, wer die jeweiligen Tätigkeiten realisiert: Organisationseinheiten, Stellen, Personen, Programme (z.B. auch WebServices), Maschinen oder auch Programme. Diese „Zuständigen“ werden den elementaren Tätigkeiten zugeordnet. Es sollte möglich sein, mehrere Träger darzustellen, auch Beziehungen zwischen den Trägern („Dies erledigt der Verkauf entweder mit der Produktion oder mit dem Controling“).

Je weitgehender ein Geschäftsprozess automatisiert ist, desto mehr liegen Programme als Aufgabenträger vor. Man stelle sich dazu einen Geschäftsprozess in einem Internetunternehmen vor, der den Umgang mit den Kunden beschreibt. Hier wären neben den Kunden fast nur Programmkomponenen als Träger der Tätigkeiten anzutreffen.

(4) Informationen auf Trägern aller Art

Dieses Element erfasst jede irgendwie genutzte Information auf allen Trägern. Information die einfach nur genutzt wird. Information, die erzeugt und solche, die nur transportiert wird. Dies ist grundsätzlich notwendig, weil dadurch die Datenflüsse deutlich werden, die ja oft Hinweise auf Optimierungspotential liefern. Außerdem stellt es die Verbindung zu den Datenbanken her.

(5) Informationsverarbeitung

Unabdingbar für eine Standardprozessmodellierung ist, die Informationsverarbeitung während der Realisierung der elementaren Tätigkeiten zu erfassen. Der Grund ist, dass in jedem Geschäftsprozess zahlreiche und umfangreiche Informationen verwaltet werden, wozu in der Regel auch Bearbeitung gehört. Schließlich stellt ja auch jedes Geschäftsobjekt Information dar.

Dieses Erzeugen, Bearbeiten, Löschen und Transportieren von Information ist den oben eingeführten elementaren Tätigkeiten zuzuordnen. Die dort angegebenen Träger sind dann die informationsverarbeitende Einheit.

Die Erfassung der Informationsverarbeitung stellt den Zusammenhang zwischen der Prozess- und Funktionsmodellierung her.

(6) Nachrichten

Dabei geht es um Nachrichten zwischen den Teilnehmern am Geschäftsprozess, z.B. zur Koordinierung ihrer Tätigkeiten. Die Partner des Nachrichtenaustausches können Menschen oder Programme sein.

(7) Ereignisse

Gedacht ist hier an die für den Geschäftsprozess wichtigen Ereignisse. Ereignisse in diesem Sinne sind ein Bestandteil des Kontrollflusses. In der Ablaufmodellierung werden schon lange Ereignisse und Aktionen miteinander verknüpft. Die einfache Tatsache, dass eine Tätigkeit startet, ist ein Ereignis bzw. bedingt ein Ereignis (die Ursache für die Tätigkeit). Die Tatsache, dass eine Tätigkeitsfolge endet, stellt wiederum ein Ereignis dar, bzw. führt zu einem Ereignis - oder auch zu mehreren, entsprechend der Operatoren (Konnektoren). Dieses Konzept, Tätigkeitsfolgen und Ereignisse miteinander zu verknüpfen, ist elementar und aus der Standardprozessmodellierung nicht wegzudenken.

Die Ereignisse kommen aus der Ereignisraum des Unternehmens. Zu dieser gehört das Unternehmen selbst, seine Geschäftspartner, staatliche Einrichtungen, das politische System ("Energiewende jetzt") und die Gesellschaft als solche ("Wir wollen keine Stromtrassen").

(8) Kontrollfluss

Der Kontrollfluss regelt die Abfolge der elementaren Tätigkeiten, ihre sequenzielle Anordnung (hintereinander) und die Verzweigungen. Beides wird von der Semantik des jeweiligen Geschäftsprozesses bestimmt. Er beruht auf Regeln allgemeiner Natur und auf Geschäftsregeln.

Es gibt durchaus verschiedene Vorstellungen von Kontrollfluss in der Prozessmodellierung. Der einfachste Fall: Geschäftsprozesse und elementare Tätigkeiten werden angestoßen, abgearbeitet und beendet. Ein Geschäftsprozess wird erst wieder gestartet, wenn die vorige Instanz beendet ist. Die erweiterte Variante ist, dass mehrere Instanzen parallel gestartet werden können.

Ein Kontrollfluss hat Verzweigungen. Im einfachsten Fall sind dies:

• Ein exklusives ODER: Genau einer der verknüpften Kontrollflusszweige wird aktiv, dann geht es weiter.
• Ein ODER (nicht-exklusives ODER): Eine beliebige Teilmenge der verknüpften Kontrollflusszweige wird aktiv, dann geht es weiter.
• Ein UND: Alle verknüpften Kontrollflusszweige müssen aktiv werden, dann geht es weiter.

Es müssen elementare Tägigkeiten, aber auch Ereignisse mit diesen Operatoren verknüpft werden können.

Dies betrifft nicht nur das Aufteilen des Kontrollflusses in mehrere Zweige, sondern auch das Zusammenführen mehrerer zuvor getrennter Kontrollflusszweige. Sinnvoll ist es, das Zusammenführen auch durch einen Operator zu realisieren und zwar durch den, der für die Aufteilung verantwortlich war.

In einem Kontrollflusskonzept sollte auch ein Element für den Start und die Beendigung des Geschäftsprozesses vorhanden sein. Damit ist dann auch die oft vorkommende Realweltsituation mehrerer alternativer Start- oder Schlusspunkte problemlos modellierbar.

Das Element zur Beendigung einer Tätigkeitsfolge sollte die gesamte Tätigkeitsfolge beenden. Die Beendigung einzelner Zweige ohne Beendigung des Gesamtprozesses (vgl. die Methode Aktivitäten, beschrieben in [Staud 2010, Kapitel 10, insbesondere Abschnitte 10.11]) ist in der Standardprozessmodellierung nicht nötig, wird aber in einer systemnahen Prozessmodellierung zum Thema.

(9) Andere Flüsse, Transporte

Es ergibt sich sehr oft, dass zum Gesamtbild eines Geschäftsprozesses auch Flüsse von Materialien, Produkten und Unterlagen gehören, v.a., wenn sich bei diesen Optimierungsbedarf manifestiert. In [Staud 2006, Abschnitt 6.2] findet sich dazu ein aussagekräftiges Beispiel. Diese "anderen Flüsse" sollten in einer Standardprozessmodellierung auch erfasst und dargestellt werden können.

(10) Ebenen - Kapselung

Eine Standardprozessmodellierung muss Detaillierungsebenen ermöglichen. Dies kann im einfachsten Fall so realisiert werden, dass einfach in den Elementen, die elementare Tätigkeitsfolgen erfassen, mehr oder weniger vom jeweiligen Abschnitt der Tätigkeitsfolge reingepackt wird.

Geht man über die Standardprozessmodellierung hinaus in die vertikale Dimension der Prozessmodellierung, sollte man zwischen den in den einzelnen Ebenen gekapselten Tätigkeitsfolgen Beziehungen anlegen können, so dass klar ist, wie die Beziehungen zwischen den Tätigkeitsfolgen "oben" und "unten" aussehen (Aufruf, Rückkehr, Weitergabe und Rückgabe von Information, usw.). Zum Beispiel mit exakten Verweisen zwischen den Ebenen, so wie bei den Strukturierten Aktivitätsknoten oder den Subautomaten in Zustandsautomaten (vgl. Kapitel 13 in [Staud 2010]).

(11) Zeitliche Dimension

Für eine Standardprozessmodellierung genügt es, wenn bzgl. der zeitlichen Dimension folgendes erfasst ist bzw. werden kann:

• die zeitliche Abfolge durch die sequentielle Anordnung im Geschäftsprozess
• Zeitpunkte
• Zeitverbrauch (vorgesehener), zumindest bei ausgewählten Tätigkeiten

Mehr ist hier möglich und evtl. notwendig, z.B. bei einer Umsetzung des Geschäftsprozesses in Workflows oder Programme.

(12) Subprozesse

Eher aus der Praxis der Modellierung kommt diese Theorieelement. Hier ist man oft genötigt, lange Tätigkeitsfolgen aufzuteilen. Zum einen, weil dadurch oft genutzte Prozessabschnitte an verschiedenen Stellen einfach per Verweis eingebaut werden können, zum anderen schlicht wegen der Übersichtlichkeit der entstehenden Grafik. Meist handelt es sich um Prozessabschnitte, die separat, unabhängig vom Gesamtprozess, betrachtet und aufgerufen werden können.

Und danach ….

Soweit, kurz und knapp, die Grundanforderungen an eine Standardprozessmodellierung. Geht man weiter, insbesondere in Hinblick auf eine programmnahe Prozessmodellierung, dann müssen diese Konzepte in vielerlei Hinsicht ergänzt werden, wobei dabei die Betrachtung der „Verhaltens-Kapitel“ der objektorientierten Theorie sehr hilfreich ist (vgl. dazu die Kapitel 10 bis 13 in [Staud 2010]).

3.2 Ziele

Erstes Ziel jeder Geschäftsprozessmodellierung ist die Bestandsaufnahme, also die Feststellung, welche Geschäftsprozesse in welcher Form ablaufen. Sie kann direkt zu einer Dokumentation (z.B. im Rahmen einer ISO 9000-Zertifizierung) führen oder zu einer Beschreibung, die man zur Vorbereitung der Einführung einer ERP-Software benötigt. In diesem Fall vergleicht man im Rahmen von Ist-Analysen die vorgedachten Geschäftsprozesse der ERP-Software mit den eigenen beschriebenen betrieblichen Abläufen:

Definition Istanalyse

Eine Istanalyse ist die Bestandsaufnahme eines bestehenden Prozesses mit all seinen Merkmalen und Defiziten.

Das zweite große Ziel ist das der Geschäftsprozessoptimierung, also der Beseitigung von Schwachstellen, die bei der Erhebung der Prozesse erkannt wurden. Beispiele für solche Schwachstellen:

• fehlende Datenintegration, d.h. Dateninseln
• fehlende Prozessintegration, d.h. Organisationsbrüche
• zu lange Transportzeiten von Prozessobjekten (Dokumente, Rechnungen, CAD-Zeichnungen, usw.; im Bürobereich ganz allgemein von Vorgängen),
• zu lange Warte- und Liegezeiten von Prozessobjekten
• zu lange Bearbeitungszeit
• zu lange Rüst- und Durchlaufzeiten
• redundante Tätigkeiten
• zu hohe Komplexität (konkret: zu hoher Dispositions- und Verwaltungsaufwand)
• unzureichendes Prozessdenken (konkret: unzureichendes Verständnis für vor- und nachgelagerte Prozessabschnitte bei den Beteiligten)
• zu lange Kommunikations- und Entscheidungswege
• zu hohe Gesamtkosten der Prozesse
• zu wenig Transparenz, was u.U. auch die Veränderung von Geschäftsprozessen behindert
• unzulängliche Prozessverantwortlichkeit
• fragmentierte Verantwortlichkeiten.

Manche Defizite treten bei der Prozessmodellierung gleich zutage. Andere nur bei entsprechender Schwerpunktsetzung, entsprechend den Zielen. Diese Ziele prägen die konkrete Ausgestaltung der Prozessmodellierung sehr stark. Je nach vermutetem Defizit wird sie unterschiedliche Schwerpunkte haben. In [Staud 2006, Abschnitt 6.2] wird ein Geschäftsprozess vorgestellt, in dem dies sehr deutlich wird. Modelliert wird eine ganze Auftragsabwicklung. Der Schwerpunkt lag aber auf der Frage, inwieweit die Erstellung der notwendigen CAD-Unterlagen verbessert werden könnte. Deshalb wird in Prozessabschnitten, die dies thematisieren, die Modellierung sehr detailliert, während sie an anderen Stellen, wo es eigentlich nur darum ging, die Lücke zu schließen, um den Prozess als Ganzes modellieren zu können, höher aggregiert, ja sogar oberflächlich wird.

Weitere Ziele werden, unter dem Stichwort „Einsatzzwecke von Prozessmodellen“ in [Becker, Kugeler und Rosemann 2012, S. 199f] genannt:

• Organisationsdokumentation. Z.B. für aktuelle Beschreibungen der Geschäftsprozesse.
• Prozessorientierte Reorganisation. Revolutionär oder evolutionär
• Kontinuierliches Prozessmanagement. Auf Dauerhaftigkeit ausgerichtete Planung, Durchführung und Kontrolle der Prozesse.
• Zertifizierung nach DIN ISO 9000ff. Nur mit Dokumentation der Modelle.
• Benchmarking. Die eigenen Geschäftsprozesse mit denen anderer Unternehmen vergleichen.
• Wissensmanagement. Um Transparenz zu schaffen über die Unternehmensressource Wissen.
• Auswahl von ERP-Software. Vergleich des eigenen Prozessmodells mit dem des ERP-Anbieters.
• Modellbasiertes Customizing. Parametrisierung der Software.
• Softwareentwicklung. Als Teil der Anforderungsbeschreibung.
• Workflowmanagement. Prozessmodelle als Grundlage für die Erstellung von Workflowmodellen.
• Simulation. Untersuchung des Systemverhaltens im Zeitablaufmit dem Ziel der Prozessoptimierung.

Kundenorientierung als Ziel der Prozessmodellierung

Natürlich ist das zentrale Ziel jeder Prozessoptimierung die Förderung der Wertschöpfung. Der Weg dorthin geht aber, da ist sich die Literatur einig, über eine möglichst ausgeprägte Kundenorientierung. Vgl. dazu [Schmelzer und Sesselmann 2013, Abschnitt 2.2].

3.3 Herausforderungen

Welches sind die aktuellen Herausforderungen an die Prozessmodellierung? Die wichtigsten können mit den Schlagworten Höhere Detaillierung, Automatisierung (vgl. nächsten Abschnitt), Vertikale Dimension der Prozessmodellierung, Schnittstellen zur Außenwelt und Cloud Computing beschrieben werden.

Höhere Detaillierung

Es wurde schon oben bei den Eigenschaften von Geschäftsprozessen thematisiert, ist aber auch ein Trend mit direkten Wirkungen auf die Prozessmodellierung - die zunehmend detailliertere Unterstützung der Geschäftsprozesse durch die IT. Seit Beginn des DV-Zeitalters gibt es in den Organisationen den Trend, die Unterstützung durch die IT immer mehr auszudehnen und zu vertiefen. Heute gibt es kaum eine Aufgabe in den Unternehmen, die nicht von Anwendungssystemen unterstützt wird. Dies war nur möglich durch eine immer detailliertere Prozessmodellierung, die heute, wie wir ja wissen, fast jeden Arbeitsschritt umfasst.

Dieser Trend erfordert eine veränderte Prozessmodellierung. Die klassische Istanalyse muss ergänzt werden durch eine programmnahe Prozessmodellierung. Vgl. dazu auch [Staud 2014, Abschnitt 12.5].

Vertikale Dimension der Prozessmodellierung

Zur Prozessmodellierung gehört, insbesondere im Kontext der Unternehmensmodellierung, dass Geschäftsprozesse auf unterschiedlichen Ebenen betrachtet werden. Ganz oben 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(vgl. [Staud 2014, Abschnitt 12.2] sowie - ausführlicher - [Staud 2010, Kapitel 14 und 15]).

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

Außenwelt und Cloud Computing

Ganz grundsätzlich ist jede Organisation heute in eine dichte informationelle Umwelt eingebettet. Dies bedeutet, dass Geschäftsprozesse des Unternehmens mit anderen aus der Außenwelt in Kontakt treten müssen. Sei es, dass einem Prozess von außen "zugeliefert" oder dass er von außen angestoßen wird ("Auftragseingang"), sei es, dass er Richtung Kunde weiter geht. Gelingt hier die Anbindung, wird dies Integration genannt in dem Sinne, dass die Geschäftsprozesse ohne Brüche miteinander gekoppelt werden. In der folgenden Abbildung steht die gestrichelte Linie für einen solchen Geschäftsprozess. Es könnte die Leistungserbringung sein, da diese in der Regel eine solche Struktur aufweist: Sie benötigt Vorleistungen von außen und sie wirkt nach draußen weiter in Richtung Kunden, Wartung, usw. Diese Schnittstellen werden seit einigen Jahren schon intensiv beackert und der teilweisen Automatisierung näher gebracht. Stichworte sind hier semantische Prozessintegration und Portallösungen. Hier muss die Prozessmodellierung Klarheit schaffen und die Grundlagen für die Automatisierungsbemühungen liefern.

In der Abbildung ist auch angedeutet, dass die Gesamtleistung eines Geschäftsprozesses u.U. von mehreren Anwendungssystemen und WebServices erbracht wird, zusammen mit einem ERP-System. Dies ist heute durchaus Realität. Auch dann gibt es vielfältige Schnittstellen, die zu bewältigen sind. Diese Schnittstellen sind durch ein grafisches Symbol angedeutet. Sie müssen geklärt und durch eine effektive Prozessmodellierung bewältigt werden.

Das gleiche gilt für die unter Umständen eingefügten WebServices. Unabhängig davon, ob sie im normalen IT-Umfeld eingefügt sind oder ob sie in die Leistungen der ERP-Software eingebettet sind, es ergeben sich Schnittstellen und diese müssen bewältigt werden.

Abbildung 3.3-1: Schnittstellen in die Außenwelt und ihre Bewältigung durch die Prozessmodellierung

Genau dasselbe gilt für die moderne Form des Outsourcing, die Verlagerung von Teilen der IT in irgendwo auf dem Globus eingerichtete Servicerechenzentren [Anmerkung] . Dieses Cloud Computing wird inzwischen von vielen Unternehmen genutzt. Konkret bedeutete es, dass ganze Geschäftsprozesse oder Teile von Geschäftsprozessen in die Cloud verlegt werden (vgl. den Punkt Cloud-AS in der folgenden Abbildung). Geschieht dies, müssen die Schnittstellen zwischen den Geschäftsprozessen in der eigenen Organisation und den ausgelagerten geklärt werden. Insbesondere auch, welche Informationen hin und welche zurückfließen. Auch dafür ist eine umfassende Prozessmodellierung unabdingbar, insbesondere auch was die Datenobjekte (Datenbestände) angeht.

Dabei ist meist zuerst Desintegration zu leisten. Bezieht man nicht die gesamte IT-Leistung auf diesem Weg, muss man Bereiche bestimmen, die man auf diese Weise auslagern möchte. Beispielsweise die wöchentlichen Versandaktionen, die gesamte Buchhaltung, die vierteljährliche Prognoserechnung oder auch gleich das gesamte Finanzwesen. Egal wie, anschließend muss diese Leistung in die übrigen Anwendungssysteme integriert werden. Welche Informationen werden hin gesandt, welche Aktionen werden von dort erwartet, welche Informationen und Koordinierungsinformationen sollen zurückkommen, usw. Auch dies muss die IT eines Unternehmens gegebenenfalls leisten.

Die folgende Abbildung soll dies illustrieren. Der Geschäftsprozess verlässt an einer Stelle die Organisations-IT und setzt seinen Weg "in der Cloud" fort. Die erste durch Prozessmodellierung zu klärende Schnittstelle ist gegeben. Später, wenn der Geschäftsprozess in die Organisation "zurückkehrt", ganz oder teilweise, gibt es wieder eine zu klärende Schnittstelle.

Abbildung 3.3-2: Neue Cloud-Schnittstellen und ihre Bewältigung durch die Prozessmodellierung

3.4 Automatisierung - Möglichkeiten und Grenzen

Auch die oben angesprochene Eigenschaft Automatisierungsgrad ist Ausdruck eines Trends in der Entwicklung der IT im allgemeinen und der Prozessmodellierung im Besonderen. Ein automatisierter Geschäftsprozess ist einer, der ohne direktes menschliches Mitwirken durch Software realisiert wird. Dies ist im technischen Bereich nichts Neues, in jedem technischen System (Geldautomat usw.) laufen automatisierte Prozesse ab. Bei der Umsetzung von Geschäftsprozessen in Software war dies bis vor einiger Zeit nicht so. So richtig umfassend realisiert haben dies die im Internet und mit Hilfe des Internet tätigen Unternehmen. Alle Geschäftsprozesse, die mit den Kunden zu tun haben, werden hier durch Anwendungssoftware realisiert und darüber hinaus die nachfolgenden in Logistik und Finanzwesen.

Dort allerdings nicht umfassend, sondern zum Teil menschgestützt. Denken wir nur an das Inkassobüro oder an wichtige unternehmensseitige Entscheidungen, die durch Menschen gefällt werden müssen. Auch die Arbeit in den großen Lagern der Internethändler erfolgt (noch) teilweise menschgestützt.

Ähnlich sieht es in den übrigen Organisationen aus, die nicht hauptsächlich im Internet tätig sind. Die dort eingesetzte Anwendungssoftware ist, basierend auf einer sehr detaillierten Modellierung der Geschäftsprozesse, teilweise automatisiert, teilweise nicht. Deshalb konnte oben der Anteil automatisierter Abschnitte als Eigenschaft eingeführt werden.

Es dürfte schon klar sein, sei aber nochmals angemerkt: Automatisierung verlangt eine programmnahe Prozessmodellierung, in Ergänzung zur Istanalyse. Damit ist Prozessmodellierung endgültig in den Bereich des Requirements Engineering für die Softwareentwicklung geraten. Vgl. hierzu [Staud 2014, Abschnitte 12.3 und 12.5].

3.4.1 Automatisierungsmöglichkeiten

Anmerkung: Die Ausführungen hier bauen auf [Staud 2010b, Kapitel 2.2] auf.

Bei der Frage, welche Abschnitte in Geschäftsprozessen grundsätzlich automatisiert abgewickelt werden können, hilft ein Blick "auf die Klassiker", die Ausführungen von Scheer und Mertens im Rahmen ihrer Texte zu Betrieblichen Anwendungssystemen (beispielhaft [Scheer 1997], [Mertens 2013]). Im Rahmen ihrer Analysen zu den in Unternehmen zu lösenden Aufgaben kamen sie zu der bekannten Einteilung nach der Art der betriebswirtschaftlichen Aufgabe, die sie für eine hierarchische Einteilung der betrieblichen Anwendungssysteme nutzten. Folgende Teilsysteme haben Scheer und Mertens schon früh in ihren Arbeiten unterschieden (vgl. auch die folgende Abbildung, die ebenfalls sehr bekannte "Managementpyramide"):

• Operative Systeme mit den Teilsystemen Administrationssysteme und Dispositionssysteme
• Wertorientierte Abrechnungssysteme
• Berichts- und Kontrollsysteme
• Analyse- und Informationssysteme
• Langfristige Planungs- und Entscheidungssysteme
• Führungssysteme

Grob orientiert sich diese Hierarchie an den verschiedenen Managementebenen in einem Unternehmen. Betrachten wir, was darunter verstanden wird und welche Hinweise uns die Ausführungen für die Automatisierungsmöglichkeiten geben.

Unter dem Begriff der „operativen Systeme“ fasst man die Administrations- und Dispositionssysteme von Unternehmen zusammen. Gemeint sind dabei Systeme, die mengenorientierte Prozesse [Anmerkung] , die eng mit der Leistungserstellung [Anmerkung] verbunden sind, unterstützen, z.B. in Produktion, Technik, Beschaffung, Vertrieb und Personaleinsatz.

Definition Operative Systeme

Operative oder operationale Systeme unterstützen die alltäglichen betrieblichen Leistungsprozesse

Die Administrationssysteme leisten die Verwaltung und Verarbeitung von Massen­daten, z.B. die …

• Berechnung der Entlohnung im Personalwesen
• Buchführungsarbeiten in der Finanzbuchhaltung
• Berechnung der Monats- und Jahresabschlüsse in der Finanzbuchhaltung
• Kontoführung bei Kreditinstituten
• Lagerbestandsführung im Handel

Hauptziel bei ihrem Einsatz ist die Rationalisierung der Massendatenverarbeitung und damit die Erzielung eines Rationalisierungsnutzens bei vorhandenen Abläufen.

Definition Administrationssysteme

Administrationssysteme haben die Aufgabe, vorhandene Abläufe und die Massendatenverarbeitung zu rationalisieren sowie Routineaufgaben zu bewältigen.

Das Automatisierungspotential ist hier, da es sich um Routineabläufe handelt, sehr hoch.

Die Dispositionssysteme dienen der Steuerung kurzfristiger, gut strukturierter Abläufe innerhalb des Betriebs und damit der Vorbereitung kurzfristiger dispositiver Entscheidungen, vor allem auf der unteren und mittleren Führungsebene. Unter Umständen leisten sie auch die automatische Entscheidungsfindung und machen die menschliche dispositive Entscheidung damit überflüssig. Beispiele für damit zu erledigende Aufgaben sind die …

• (Plan-)Kalkulation in der Kostenrechnung
• Außendienststeuerung im Vertrieb
• Tourenplanung im Vertrieb
• Materialbeschaffung in der Fertigung
• Werkstattsteuerung in der Fertigung
• Bestellwesen im Handel

Definition Dispositionssysteme

Dispositionssysteme sollen menschliche Entscheidungen vorbereiten und einfache Entscheidungen automatisch durchführen.

Das Automatisierungspotential ist hier, da es sich um Routineabläufe handelt, hoch. "Außen vor" bleiben die Entscheidungsprozesse.

Die Unterscheidung in Administrations- und Dispositionssysteme hat heute nur noch den Sinn, dass sie die jeweilige Aufgabenstellung klärt. Sie deutet nicht auf unterschiedliche Software hin. Die hier unterschiedenen Aufgaben sind heute meist in ein und derselben Software verschmolzen.

Aber eine andere Unterteilung hat heute Bedeutung: in Systeme, die unmittelbar mit der betrieblichen Realität zu tun haben, und in Systeme, die der Auswertung dieser Daten dienen. Zur ersten Kategorie gehören z.B. Anwendungssysteme zur Betriebsdatenerfassung, zur Fertigungssteuerung, zur automatisierten Lagerverwaltung, zur Überwachung der Versorgungskette im Lieferkettenmanagement (Supply Chain Management). Zur zweiten gehören dann die Systeme, die Daten daraus erhalten und verarbeiten. Das sind die wertorientierten Abrechnungssysteme.

Diese begleiten die oben dargestellten mengenorientierten Prozesse. Sie machen die betriebswirtschaftlichen Konsequenzen sichtbar. Am Beispiel der Anwendungsprogramme im Personalwesen kann man dies gut erläutern: Die operativen Systeme liefern die Daten zum täglichen Einsatz eines jeden Beschäftigten: Arbeitsbeginn, Arbeitsende, Überstunden usw. Die wertorientierten Abrechnungssysteme errechnen daraus z.B. das Monatsgehalt.

Definition Wertorientierte Abrechnungssysteme

Wertorientierte Abrechnungssysteme nehmen eine betriebswirtschaftliche Auswertung der mengenorientierten Daten aus den operativen Systemen vor.

Das Automatisierungspotential ist hier, da es sich meist um stark durchstrukturierte Abläufe handelt, sehr hoch.

Berichts-, Planungs- und Kontrollsysteme

Die nächste Ebene in der Hierarchie der betrieblichen Anwendungssysteme wird von Scheer „Berichts- und Kontrollsysteme“, von Mertens „Planungs- und Kon­trollsysteme“ genannt. Diese Anwendungssysteme erhalten ihre Informationen aus den mengen- und wertorientierten Systemen und verarbeiten sie für unterschiedliche Fragestellungen.

Berichtssysteme decken den Informationsbedarf für operative Entscheidungen. Sie liefern z.B. periodische Berichte oder Signalberichte, die durch Soll-Ist-Abweichungen automatisch ausgelöst werden. Diese Funktionalität ist in modernen integrierten Softwarepaketen enthalten. Dazu erlauben die Berichtssysteme einfache Auswertungen von Dateien und Datenbanken sowie die Präsentation der Ergebnisse. Initiativ wird entweder der Nutzer oder das System (bei regelmäßig erzeugten Berichten).

Das Automatisierungspotential ist hier, nach der Festlegung der Art der Berichte, sehr hoch.

Planungssysteme unterstützen die betriebliche Leitungsebene bei Planungsaufgaben und -entscheidungen, insbesondere bei schlecht strukturierten Problemen. Sie stellen die Fortsetzung der Dispositionsmodelle dar. Ein Beispiel ist das Berechnen von Planalternativen und -varianten mit Hilfe von Modellrechnungen. In Betracht kommen dabei die …

• Planung einzelner Unternehmensbereiche (z.B. Absatzplanung)
• integrierte, bereichsübergreifende Planung (z.B. Produktionsprogrammplanung als Integration von Produktion und Vertrieb)
• globale Unternehmensplanung

Das Automatisierungspotential ist hier niedrig. Planungsvorgänge können nur unterstützt werden (Informationserhebung, -verarbeitung), die eigentliche Planung ist Sache der beteiligten Menschen [Anmerkung] .

Kontrollsysteme dienen zur Überwachung der Einhaltung der Pläne, z.B. durch Soll-Ist-Vergleiche und Hinweise auf notwendige Korrekturmaßnahmen. Sie sind das Gegenstück zu den Planungssystemen. Kontrollsysteme zeigen auf, wo spezielle Analysen und Abhilfemaßnahmen notwendig sind, z.B. bei der Kontrolle des Risikoportfolios in einer Versicherung.

Typisch für diese Ebene ist, dass die zu fällenden Entscheidungen langfristige, in der Regel schlecht strukturierte Aufgaben betreffen. „Schlecht strukturiert“ bedeutet, dass nicht für alle Lösungsschritte konkrete Lösungsverfahren vorliegen (vgl. unten).

Ähnlich wie oben ist das Automatisierungspotential hier niedrig. Nur eingerichtete Kontrollprozesse können automatisiert ablaufen. Die eigentlichen Entscheidungen müssen Menschen fällen.

Die Hierarchie geht weiter. Als nächstes folgen die Analysesysteme. Diese verdichten die Daten aus den operativen und den Abrechnungssystemen, verwalten sie und werten sie aus. Auch Daten aus externen Quellen werden einbezogen. Beispiele hierfür sind Marketing- oder Beschaffungsinformationssysteme.

Die Spitze der Hierarchie stellen „langfristige Planungs- und Entscheidungssysteme“ (bei Mertens: „Anwendungssysteme zur Unternehmensgesamtplanung“) dar. Hier erreichen die Daten, die von „unten“ (in dieser Hierarchie) geliefert werden, die höchste Verdichtungsstufe. Diese Anwendungssysteme sollen die langfristige Planung und diesbezügliche Entscheidungen unterstützen. Sie dienen also der Entscheidungsvorbereitung für die oberen Führungsebenen.

Langfristige Planungs- und Entscheidungssysteme müssen deshalb einfach bedienbar sein, ein grafisch orientiertes Abfrage- und Berichtssystem haben und auf Knopfdruck Ergebnisse liefern. Oft bieten sie auch Entscheidungsunterstützungsfunktionen auf Basis einer Modell- und Methodendatenbank. Schwerpunkte sind jedoch eine umfassende kompakte Darstellung der Bedingungslage (betriebliche Situation und Umfeld) sowie das Controlling (Schlüsselkennzahlen und kritische Erfolgsfaktoren).

Definition Langfristige Planungs- und Entscheidungssysteme

Langfristige Planungs- und Entscheidungssysteme Langfristige Planungs- und Entscheidungssysteme haben die Aufgabe, unternehmerische Planungen und Entscheidungen zu unterstützen.

Obige zwei Bereiche sind nicht automatisierbar, hier dominieren Entscheidungen (auch kreativer Natur), die von Menschen gefällt werden müssen. Z.T. aufgrund weitgehender Erfahrungen und tiefer Kenntnis des Marktgeschehens, der Unternehmensabläufe, usw.

In der (von Mertens und Scheer formulierten) hierarchischen Einteilung von betrieblichen Anwendungssystemen ändert sich mit jeder Ebene das Abgrenzungskriterium. In den oberen Ebenen unterscheidet man nach der Art der anstehenden Entscheidungsprozesse (vgl. hierzu auch den nächsten Abschnitt), in den unteren Ebenen nach Art der Datenverarbeitung. Man kann die Hierarchie wie in der folgenden Abbildung darstellen. Dort ist auch das Automatisierungspotential vermerkt.

Abbildung 3.4-1: Das Automatisierungspotential in den Betrieblichen Anwendungssystemen

Mertens und Scheer haben die Form der Pyramide gewählt, weil von unten nach oben eine ständige Datenverdichtung stattfindet. Die Datenflüsse sind in der Abbildung angedeutet. Die Unmenge an Daten, die bei den operativen Systemen entsteht (z.B. bei einer Betriebsdatenerfassung), erfährt eine erste Verdichtung bei den wertorientierten Abrechnungssystemen (geleistete Stunden, Gehalt), eine weitere bei den Berichts- und Kontrollsystemen und dann bei den Analysesystemen. Der zuständige Prozess der Datenverdichtung "von unten nach oben", z.B. für ein Data Warehouse, ist in der Abbildung auch durch eine Pfeillinie angedeutet.

3.4.2 Problemstruktur und Automatisierung

Die oben beschriebene Einteilung betrieblicher Anwendungssysteme ist schon recht hilfreich. Allerdings fehlt der direkte Hinweis auf das entscheidende Kriterium, das die Automatisierungsmöglichkeiten bestimmt und damit die Gestaltung und Auswahl von Software prägt, die Problemstruktur [Anmerkung] der Aufgabe, deren Lösung durch die Software unterstützt werden soll. Problemstrukturen können schwach, stark oder gar unstrukturiert sein, entsprechend unterschiedlich fällt die Softwareunterstützung aus. [Alpar, Grob, Weimann u.a. 2008] berücksichtigen diese Dimension und kombinieren sie mit einem zweiten Kriterium, den Planungsebenen, wie sie ihre Einteilung der im Unternehmen zu treffenden Entscheidungen nennen. Damit kommen sie zu einer vertiefteren, weil zweidimensionalen Analyse der Anforderungen an ein Informations- und Kommunikationssystem. Die Planungsebenen entsprechen weitgehend den hier oben angeführten Einteilungen betrieblicher Anwendungssysteme. Doch nun zu den Problemstrukturen.

Probleme und Problemstrukturen

Problemlösung geschieht in folgenden Phasen:

• 1. Problemerkennung
• 2. Alternativengenerierung
• 3. Alternativenauswahl

Vgl. [Alpar, Grob, Weimann u.a. 2008].

In der ersten Phase geht es darum zu erkennen, dass es ein zu lösendes Problem gibt und welcher Art es ist. In der zweiten Phase werden Lösungsalternativen entwickelt. In der dritten Phase wird eine der Lösungen gewählt. Je nach Problemstruktur kann die eine oder andere Phase durch Informations- und Kommunikationssysteme unterstützt oder sogar automatisiert werden.

In der Praxis (von Informations- und Kommunikationssystemen) muss dann eine getroffene Entscheidung auch umgesetzt (implementiert) werden. Danach wird geprüft, ob die mit der Entscheidung verfolgten Ziele auch erreicht werden. Es folgen also:

4. Implementierung und

5. Kontrolle.

Diese Phasen können mehrfach durchlaufen werden. Aufbauend auf diesem Phasenmodell kann man nun Probleme danach unterscheiden, zu welchen Phasen die Aufgabenträger ein geeignetes (Lösungs-)Vorgehen kennen.

• Als wohlstrukturiert wird ein Problem empfunden, wenn ein Entscheidungsträger zu jeder der Phasen ein geeignetes Vorgehen kennt. In einem solchen Fall ist es oft möglich, die Problemlösung zu automatisieren. Dies bedeutet, dass man eine Lösungsvorschrift festlegt, die auch von anderen (Menschen, Programmen, Maschinen) befolgt werden kann.
• Als semistrukturiert gelten Probleme, bei denen für einige Phasen Lösungsansätze bekannt sind, für andere nicht. Solche Probleme können auf jeden Fall durch IT unterstützt werden, aber höchstens in einzelnen Prozessabschnitten automatisiert.
• Als unstrukturiert wird ein Problem empfunden, wenn zu keiner der Phasen ein geeignetes Vorgehen bekannt ist. Solche Probleme entziehen sich der Automatisierung vollkommen. Unterstützung durch IT ist denkbar (vgl. unten).

Dies erklärt tatsächlich die Ergebnisse des vorigen Abschnitts. Überall dort, wo ein sehr hohes Automatisierungspotential festgestellt werden kann, liegen Geschäftsprozesse mit wohlstrukturierten Problemen vor. Bei einem aufgrund der Beschreibung vermuteten hohen Potential sind semistrukturierte Probleme vorhanden. Die Problemphasen ohne "bekannte Lösungsansätze" stellen die Entscheidungen dar, deren Komplexität von der Vielzahl an Variablen herrührt, die bedacht werden müssen. Die Bereiche ohne Automatisierungspotential sind welche mit unstrukturierten Problemen. Hier sind Entscheidungen von strategischer Bedeutung zu fällen [Anmerkung] , für die es keine Lösungsvorschläge gibt.

Abschließend zu diesen Ausführungen zum Automatisierungspotential in verschiedenen Bereichen kann noch angemerkt werden, dass der Bereich der automatisierbaren Prozessabschnitte durch die theoretischen und praktischen Entwicklungen in der Informatik ständig ausgedehnt wird.

3.5 Kontrollfluss vertieft

Ein Kontrollfluss, wie er oben eingeführt wurde, kann durchaus verschiedene Realisierungen haben. Für eine Standardprozessmodellierung genügen folgende Festlegungen:

• Geschäftsprozesse werden angestoßen, abgearbeitet und beendet. Eine neue Instanz kann erst wieder gestartet werden, wenn die vorige beendet ist.
• Elementare Tätigkeiten werden angestoßen, abgearbeitet und beendet. Die Aktivitäten „im Inneren“ der Funktion sind verborgen. Dies kann durchaus Probleme bereiten (vgl. [Staud 2006, Abschnitt 7.1] für ein Beispiel), weshalb auch diesbezüglich eine kompetente Modellierung nötig ist. Eine elementare Tätigkeit kann also insbesondere nicht aktiv bleiben, wenn der Geschäftsprozess weiter schreitet.
• Echte Parallelität muss es nicht geben, das gemeinsame Anstoßen mehrerer Aktivitäten aber schon, weil es einem Muster der Realwelt entspricht.
• Wird das erste Schlussereignis erreicht, endete der Gesamtprozess. Es kann (braucht) nicht Kontrollflusszweige geben, die beendet werden können, ohne dass der Rest des Geschäftsprozesses auch endet (vgl. das Element Flussende in Aktivitäten, beschrieben in [Staud 2010, Kapitel 10, insbesondere S. 164]).

Eine Ursache für diese recht einfache Struktur ist, dass man in der Prozessmodellierung einen einzelnen Prozess für sich betrachtet und die Thematik, dass vielleicht ein Prozess von mehreren Nutzern parallel gestartet wird, nicht im Fokus ist.

Stellt man sich nun aber eine Software vor, die Geschäftsprozesse abbildet, sieht die Situation anders aus:

• Natürlich kann eine neue Instanz eines Prozesses gestartet werden, auch wenn die vorige noch nicht abgeschlossen ist. Konkret: ein Prozess der Software startet mit möglichst vielen Kunden, gleichzeitig oder hintereinander.
• Elementare Tätigkeiten können weiter aktiv sein, auch wenn der Prozess weiter geht. Eine detaillierte Darstellung hierzu bzgl. Aktivitäten findet sich in [Staud 2010, Kapitel 10].
• Es gibt echte Nebenläufigkeiten (echte, technische Parallelität)
• Einzelne Kontrollflusszweige können beendet werden, ohne dass der Gesamtprozess endet.

Dies zu modellieren ermöglichen die Methoden der UML, die Dynamik-Aspekte zum Gegenstand haben. Die Aktivitäten zum Beispiel in Hinblick auf die Gesamtsicht (vgl. Kapitel 11, insbesondere Abschnitt 10.11.3 in [Staud 2010]), die Zustandsautomaten bezüglich der Verschachtelung von Tätigkeiten und auch für die Gesamtsicht. Sind dann Geschäftsprozesse als Automaten erkannt, sind die Techniken der Zustandsautomaten auch dafür sehr hilfreich.

In [Staud 2010] ist für die wichtigsten Methoden der UML zur Beschreibung von Abläufen / Tätigkeiten (Aktivitäten, Sequenzen, Anwendungsfälle, Zustandsautomaten) jeweils betrachtet, welchen Beitrag sie zur Unternehmensmodellierung und dabei insbesondere zur Prozessmodellierung leisten können. Ein generelles Ergebnis ist die Eignung für die programmnahe Prozessmodellierung (vgl. auch den nächsten Abschnitt).

3.6 Prozessmodellierung - heute und morgen

Wie sieht nun - nach Meinung des Verfassers - die Modellierung von Prozessen in der Zukunft aus? Die erste Prozessmodellierung muss eine Standardprozessmodellierung sein. Das ist die Ebene auf der Geschäftsobjekte sichtbar sind und konkretes Prozesshandeln erfasst werden kann, so dass die Modellierung des Kontrollflusses ohne Schwierigkeit möglich ist. Hierfür sind die Ereignisgesteuerten Prozessketten aufgrund ihrer „wohltuenden Abgehobenheit“ und ihrer für die Prozessmodellierung geeigneten Theorieelemente die Methode der Wahl. Auch die BPMN eignet sich dafür, wenn man den Elementevorrat einschränkt.

„Darunter“ sollte eine programmnahe Prozessmodellierungstattfinden - zur direkten Vorbereitung der Systemanalyse und des Software Engineering, also als 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.

Für die Ebenen "über" der Standardprozessmodellierung (Grobmodellierungen) können die üblichen Übersichtsnotationen erstellt werden. Z.B. mit aggregierten Funktionen in EPKs oder BPDs. Etwa so wie in der früheren Unternehmensmodellierung der SAP durch Szenarios (vgl. Kapitel 8 in [Staud 2006] für eine Kurzdarstellung).

Auf der obersten Eben bleiben die klassischen Wertschöpfungskettenein sinnvolles Instrument. Hier sind dann meist ganze Abteilungen mit ihren Tätigkeiten in einem Element zusammengepackt und der Kontrollfluss drückt da lediglich die Abfolge dieser hochaggregierten Handlungseinheiten aus. Auch hierzu findet sich eine Kurzdarstellung in oben genannter Quelle [Staud 2006, Abschnitt 8.2.3].

Damit ergeben sich die oben eingefügten sinnvollen Ebenen für die vertikale Dimension der Prozessmodellierung.

4 Geschäftsprozesse in der BPMN

"BPMN depicts the end to end flow of a business process. The notation has been specifically designed to coordinate the sequence of processes and the messages that flow between different process participants in a related set of activities." [http://www.bpmn.org/, abgerufen am 02.07.2016]

Mithilfe der BPMN lassen sich Geschäftsprozesse systematisch analysieren und simulieren. Sie bietet die Grundlage für eine Process Engine, d.h. eine Software, die Prozesse steuert.Für die Zeichnung von Prozessdiagramen werden Symbole verwendet. Die Methode BPMN verfügt in der aktuellen Version BPMN 2.0 über mehr als 100 Elemente.

4.1 Definition

Wie definieren die BPMN-Autoren Geschäftsprozesse? Im Originaltext finden wir dazu folgende Ausführungen:

• Ein Geschäftsprozess beschreibt eine zielgerichtete Folge von Aktivitäten in einer Organisation. Er besteht aus mehreren Aktivitäten und den Sequenzfluss­mechanismen, die sie strukturieren [OMG 2011, S. 145].
• Es gibt drei Prozesstypen: Private Non-executable (internal) Business Processes, Private Executable (internal) Business Processes, Public Processes [ebenda, S. 149].
• Prozesse gibt es auf mehreren Hierarchieebenen. Man kann sie unternehmens­weit definieren oder auch entlang der Aktivitäten einer Person [ebenda, S. 32].
• Prozesse auf einem niedrigen Aggregationsniveau (Low-Level Prozesse), die zusammen eine Aufgabe erledigen, können gruppiert werden.
• Jeder Prozess kann seine eigenen Subprozesse haben und kann in einem Becken (pool) enthalten sein.
• Einzelne Prozesse können - was den Sequenzfluss angeht - voneinander unabhängig sein, aber verbunden durch einen Nachrichtenfluss (oder mehrere).
• Es gibt eine zentrale, den Geschäftsprozess steuernde Einheit (central controller, responsible entity or observer) [ebenda, S. 25].

Auf folgende Unterscheidung legen die BPMN-Autoren in diesem Zusammenhang wert: Der Begriff Prozess wird für "a set of flow elements" genutzt, für die Interaktion zwischen Prozessen die Begriffe Kollaboration und Choreographie.

4.2 Prozesstypen in der BPMN

Interne Geschäftsprozesse (Private Business Process)

Mit der Bezeichnung Private Business Processes sind diejenigen gemeint, die innerhalb eines Unternehmens (einer Organisation) realisiert werden. Sie sollen in diesem Text Interne Geschäftsprozesse genannt werden. Unterschieden werden dabei zwei Typen: ausführbare und nicht ausführbare.

Ein ausführbarer Prozess (Private Executable (internal) Business Process) ist einer, der darauf vorbereitet ist, in WS-BPEL abgebildet zu werden. Durch diese Tauglichkeit für die Business Process Execution Languagewird er ausführbar.

Ein nicht ausführbarer Prozess (Private Non-executable (internal) Business Process) ist einer, der innerhalb einer Organisation realisiert wird. Die Modellierung solcher Prozesse zielt nicht auf die Umsetzung des Prozesses in Software, sie dient anderen Zielen, z.B. der Dokumentation, der Istanalyse oder Überblicksgewinnung (auf einem hohen Aggregationsniveau).

Da die Zuordnung von Trägern der einzelnen Tätigkeiten zu den Geschäftsprozessen in der BPMN über die Schwimmbahnentechnik mit Becken und Bahnen erfolgt (vgl. Abschnitt 7.1), können die BPMN-Autoren auch ausführen, dass die internen Prozesse in einem (einzigen) Becken ablaufen. Der Sequenzfluss kann das Becken nicht verlassen. Über die "Grenzen" hinweg wird in der BPMN mit Nachrichten gearbeitet, mit denen wird die u.U. notwendige Interaktion zwischen verschiedenen Organisationen erfasst (vgl. Abschnitt 7.2).

Öffentliche Geschäftsprozesse (Public Processes)

Mit der Bezeichnung Public Process sind die Vorgänge gemeint, die zwischen einem internen Geschäftsprozess und einem anderen Prozess stattfinden. Sie werden hier öffentliche Geschäftsprozesse genannt. Ein öffentlicher Prozess beinhaltet somit die Aktivitäten, die zur Kommunikation mit Partnern dienen und die Anordnung dieser Aktivitäten [OMG 2011, S. 150]. Alle anderen internen Aktivitäten des (anderen) internen Prozesses werden in Öffentlichen Prozessen nicht angegeben. Sie werden eigenständig modelliert oder in einer Kollaboration.

Globale Prozesse (Global Processes)

Geschäftsprozesse, die von den Call Activities anderer Prozesse aufgerufen werden können, werden von den BPMN-Autoren Globale Prozesse (global processes) genannt. Sie gehören zu den Subprozessen, sind wiederverwendbar und können mehrere Startereignisse haben.

4.3 Diagrammtypen

Folgende Diagrammtypen sollen mit der BPMN modellierbar sein:

• Hoch aggregierte interne Prozesse
• Detaillierte interne Geschäftsprozesse (Istprozesse, Sollprozesse)
• Detaillierte interne Geschäftsprozesse mit Interaktionen zu einem externen Partner oder zu mehreren
• Zwei oder mehr detaillierte interne Geschäftsprozesse, die miteinander interagieren
• Detaillierte Geschäftsprozesse mit Beziehungen zu einem öffentlichen Prozess
• Beziehungen eines detaillierten internen Geschäftsprozesses zu einem globalen Prozess
• Zwei oder mehr öffentliche Prozesse
• Beziehung(en) eines öffentlichen Prozesses zu einem globalen Prozess
• Ein globaler Prozess alleine
• Zwei oder mehr detaillierte interne Geschäftsprozesse, die durch einen öffentlichen Prozess interagieren
• Zwei oder mehr detaillierte interne Geschäftsprozesse, die durch einen globalen Prozess interagieren.
• Zwei oder mehr detaillierte interne Geschäftsprozesse, die durch ihre abstrakten Prozesse und einen Kollaborationsprozess interagieren.

[OMG 2009, Seite 14f]. In [OMG 2011] wird dies nicht mehr so detailliert ausgeführt, sondern über die Anmerkung erledigt, dass Prozesse auf allen möglichen Ebenen modelliert werden können [OMG 2011, S. 145].

4.4 Vertikale Dimension der Prozessmodellierung

Ganz nebenbei wird in obiger Liste bzgl. der vertikalen Dimension der Prozessmodellierung noch die naheliegende Unterscheidung von

• hoch aggregierten Aktivitäten interner Prozesse und
• detaillierten internen Geschäftsprozessen

eingeführt.

In den Ausführungen der BPMN-Autoren spielen die Geschäftsprozesse der obersten Ebene - die Top-Level - Prozesse - im jeweiligen Modellierungskontext eine besondere Rolle, für sie gelten besondere methodische Festlegungen, auf die im Weiteren immer wieder hingewiesen wird.

4.5 Gruppierung der Elemente

Die BPMN-Autoren teilen die verwendeten Methodenelemente in vier Gruppen ein:

• Flussobjekte (flow objects)
• Verknüpfende Objekte (connecting objects)
• Schwimmbahnen (swimlanes)
• Artifakte (artifacts)

Die Flussobjekte werden noch unterteilt in:

• Ereignisse
• Aktivitäten
• Gateways

Als verknüpfende Objekte werden die bezeichnet, mit denen die Flussobjekte miteinander verknüpft werden können:

• Sequenzfluss
• Nachrichtenfluss
• Assoziationen

Schwimmbahnen dienen der Gruppierung der Basismodellelemente. Hier wird unterschieden in

• Becken
• Bahnen

Artifakte liefern zusätzliche Informationen über den Prozess. Drei werden vorgegeben, andere können - so die BPMN-Autoren - hinzugefügt werden:

• Datenobjekte
• Gruppen
• Anmerkungen

4.6 Token

Ebenso wie die UML-Autoren nutzen auch die BPMN-Autoren das Token-Konzept zur Beschreibung des Prozessverhaltens. Wie in [Staud 2010] ausgeführt, dient es dort zur Verdeutlichung des Kontrollflusses, hier also des Sequenzflusses. Ein Token durchquert sozusagen die einzelnen Sequenzflüsse und passiert dabei die sonstigen Prozesselemente (z.B. Operatoren/Gateways). Die Rolle der einzelnen Prozesselemente im Prozessablauf kann dann über das Geschehen rund um das Verhalten der Token bei den Prozesselementen beschrieben werden, was im Folgenden hier auch immer wieder geschieht. Die Token entstehen bei Startelementen und werden bei Schlusselemenen verbraucht.

Knoten und Kanten

Im Zusammenhang mit Token ist von Knoten und Kanten die Rede. Diese beiden Begriffe entstammen der Graphentheorie (àGraph). Ein Knoten steht hier in der BPMN für eine Aktivität oder einen Subprozess, eine Kante für eine Verbindung zwischen zwei Knoten, also z.B. einen Sequenz- oder Nachrichtenfluss. Während Kanten in der Graphentheorie gerichtet (mit einer Richtung versehen) oder ungerichtet sein können, sind sie in der Prozessmodellierung immer gerichtet.

Knoten und Kanten haben Regeln für den Tokenfluss. Zum Beispiel legen Knoten fest, wann Token sie betreten (sozusagen) oder verlassen dürfen (können). Kanten haben Regeln, die festlegen, wann ein Token vom Quellknoten angenommen und zum Zielknoten befördert werden kann. Ein Token durchquert eine Kante nur genau dann, wenn er alle Regeln für den Zielknoten, die Kante und den Quellknoten erfüllt.

Kontrollknoten (Gateways bzw. Operatoren) dienen als Wegbereiter für die Token. Sie weisen, entsprechende ihrer Semantik, den Token "den Weg". Dazu kann, wie bei UND-Operatoren, auch gehören, dass sie vervielfältigt werden.

Ein Token durchläuft also die Ablauffolge und die Flussobjekte des Prozesses. Das Verhalten des Prozesses kann beschrieben werden, indem die einzelnen Pfade des Tokens durch den Prozess festgehalten werden. Betrachtet man den Tokenfluss eines konkreten Durchgangs, entsteht eine Instanz des Geschäftsprozesses (vgl. Abschnitt 2.1) .

Token und Instanzen

Eine Instanz wird initiert durch die Ankunft eines Token. Damit eine Prozessinstanz fertig wird, müssen alle Token in der Instanz einen Endknoten erreichen, d.h. einen Knoten ohne abgehende Sequenzflüsse. Ein Knoten, der ein Endereignis erreicht, löst das mit dem Ereignistyp verknüpfte Verhalten aus. Z.B. eine verknüpfte Nachricht bei einem Nachrichtenschlussereignis (Message End Event) oder ein verknüpftes Signal bei einem Signalschlussereignis (Signal End Event). Falls der Token ein Abbruchschlussereignis (Terminate End Event) erreicht, wird der gesamte Prozess abgebrochen.

Eine Prozessinstanz ist abgeschlossen, falls folgende drei Bedingungen erfüllt sind:

• Falls die Instanz durch ein instantiierendes Parallel Gateway erzeugt wurde, müssen alle nachfolgenden Ereignisse dieses Gateways eingetreten sein.
• Es gibt keinen Token mehr in der Prozessinstanz.
• Keine Aktivität des Prozess ist mehr aktiv.

Weitere Festlegungen zum Tokenfluss sind bei den Methodenkomponenten zu finden.

5 Einführende Beispiele

5.1 Das erste Business Process Diagram

Es sieht am Anfang ganz vertraut aus, wenn man die UML-Methoden (insbesondere Aktivitätsdiagramme) und Ereignisgesteuerte Prozessketten kennt. Es gibt ein grafisches Element, das Tätigkeiten erfasst, ein Rechteck mit abgerundeten Ecken. Mit ihm wird beschrieben, was im Geschäftsprozess konkret getan wird, genauer: in welche einzelnen "elementaren" Tätigkeiten der Geschäftsprozess zerlegt wurde. Dieses Element wird hier Aktivität (activity) genannt. Mehr dazu in Kapitel 6.

Abbildung 5.1-1: Darstellung einer Aktivität (Subprozess, Aufgabe)

Es gibt auch ein Methodenelement, das den Kontrollfluss(hier sequence flow, übersetzt mit Sequenzfluss) ausdrückt, gerichtete Pfeile, die die einzelnen Aktivitäten verbinden. Außerdem sieht die Methode Start- und Schlussereignisse (Kreis mit dünner bzw. dicker Linie) für den Anfang und das Endes eines Geschäftsprozesses vor. Damit kann man bereits ein erstes natürlich noch sehr schlichtes Business Process Diagram (BPD), so werden die Prozessmodelle hier genannt, erstellen: Eine Folge von Aktivitäten, die - einmal initiiert - nacheinander abgewickelt werden.

Abbildung 5.1-2: Auftragsabwicklung - Variante 1

Natürlich ist das wirkliche "Prozessleben" nicht so schlicht und es fehlt hier auch noch vieles, was man in der Prozessmodellierung erwartet, dazu später mehr. Am meisten vermisst man in obigem Beispiel sicherlich die Entscheidung, ob der Auftrag überhaupt angenommen wird und das Auffächern der Tätigkeiten in parallele Pfade, Auftragsabwicklung auf der einen und Zahlungsabwicklung auf der anderen Seite. Dies ist natürlich möglich, die dafür notwendigen Operatoren (hier Gateways genannt) liegen in der Methode vor.

Betrachten wir dazu die folgende Abbildung. In ihr ist obiges Business Process Diagram (BPD) etwas ausgebaut. Es ist außerdem mit Nummern in Kreisen versehen. Diese sind nicht Teil der Methode BPMN, sondern dienen nur der Kennzeichnung für die folgenden Ausführungen.

Wie in der vorigen Abbildung liegt ein Startereignis vor (1), das die Aktivität Auftragseingang (2) anstößt. Nach diesem folgt eine erste Verzweigung mit einem Operator (3). Konkret bedeutet dies hier, dass aus einem Sequenzfluss mehrere werden. Es geht entweder mit dem Sequenzflusszweig Auftrag abgelehnt (4) oder mit dem Zweig Auftrag akzeptiert (5) weiter.

Die Operatoren werden von den BPMN-Autoren Gatewaysgenannt. Das grafische Symbol ist ein auf die Spitze gestelltes Quadrat. Die Abbildung unten enthält mehrere. Der erste (3) stellt einen Operator des Typs exklusives Oder dar (XODER, vgl. Abschnitt 11.2 sowie [Staud 2015] für eine Beschreibung). Die BPMN-Autoren nennen ihn Exclusive Gateway. Kurz kann er so beschrieben werden:

Es gibt nach dem Gateway mehrere weiterführende Pfade, nur einer davon kann aktiv werden.

Der Schrägstrich bei "Akzeptiert" bedeutet in dieser Modellierungsmethode, dass der durch ihn markierte Pfad die Voreinstellungist, was hier nur bedeuten kann, dass er meistens aktiv wird.

Der Pfad, der die Zurückweisung des Auftrags ausdrückt, führt direkt an das Ende des Geschäftsprozesses, zu einem Gateway (8), das mehrere Zweige zusammenfasst. Dazu gleich unten mehr.

Im positiven Fall ("Akzeptiert") wird die Aktivität Auftrag ausführen durchgeführt. Ist dies geschehen, werden zwei Aktivitäten angestoßen, zum einen die Lieferung, zum anderen das Versenden der Rechnung (Rechnung senden). Für eine solche Situation (quasi paralleles Anstoßen zweier Aktivitäten) wird ein UND-Operator verwendet, der hier Parallel Gatewaygenannt wird. Es gibt ihn in allen Methoden zur Prozessmodellierung, hier wird er durch ein Pluszeichen dargestellt. Dieses UND-Gateway bei (6) ist ein verzweigendes, weiter flussabwärts (7) folgt noch ein verknüpfendes.

Oftmals wird in den Beispielen der BPMN-Autoren an einer solchen Stelle auf ein Operatorsymbol verzichtet und die Sequenzflüsse ohne Operatorsymbol hin- oder weggeführt. Nach den Erfahrungen des Verfassers führt eine solche Modellierung zu Unübersichtlichkeit und sollte deshalb vermieden werden. Mehr zu den Gateways findet sich in Kapitel 11.

Die Parallelität durch das Gateway (6) bedeutet hier, dass beide weiterführenden Pfade angestoßen werden und dass die Aktivitäten der beiden Pfade durchlaufen werden. "Parallel" bedeutet hier also nur gleichzeitiges Anstoßen, nicht echte Parallelität der Abläufe. Die beiden Sequenzflüsse werden dann, da es in nur einem Sequenzfluss weitergeht, zusammengefasst. Hierfür wird wieder das Parallel Gateway genommen (7), da beide Sequenzflusszweige ja durch ein solches entstanden sind. Dies ist eine übergeordnete Regel der Prozessmodellierung: Für das Zusammenführen von Sequenzflüssen wird der Operator genommen, nach dem aufgeteilt wurde.

Am Schluss des Geschäftsprozesses, am rechten Rand der Abbildung, folgt dann die Zusammenführung der durch ein Exclusive Gateway getrennten Flüsse (8). Hierfür wird wiederum das Exclusive Gateway genommen. Die BPMN-Autoren nennen dieses Gateway exclusive merging. Dies ist hier die Variante "data based", neben der es noch die Variante "event based" gibt. Dazu mehr in Kapitel 11. Am Schluss folgt noch das Schlussereignis (9).

Abbildung 5.1-3: Auftragsabwicklung - Variante 2.
Quelle: In Anlehnung an [OMG 2009a, S. 104, Figure 10.12], [OMG 2011, S. 269, Figure 10.85] Übersetzung durch den Verfasser.

Enthaltene Elemente:

- Startereignis

- Exclusive Gateway mit Voreinstellung

- Aufgabe

- Parallel Gateway, verzweigend

- Parallel Gateway, verknüpfend

- Exclusive Gateway, verknüpfend

- Schlussereignis

Soweit der erste "vorzeigbare" Geschäftsprozess als BPD. Es fehlen ihm allerdings noch einige wichtige Komponenten, z.B. die Datenobjekte, mit denen er umgeht und die Angabe der Zuständigkeiten.

5.2 Jetzt mit Daten

Datenobjekte (data objects) sind alle Geschäftsobjektewie Rechnungen, Lieferscheine, usw., jegliche Koordinierungsinformation (Anfragen, Angebot, Liefermitteilungen) und natürlich die ganz normale Datenbank der Organisation mit all ihren Datenbeständen. Diese sind von großer Bedeutung für jeden Geschäftsprozess, weshalb jede Methode zur Modellierung von Geschäftsprozessen vorsehen muss, sie zu erfassen.

Eigentlich wäre Informationsobjektder passendere Begriff, da in Geschäftsobjekten und ihren Repräsentanten in Prozessmodellen auch Semantik eine Rolle spielt und diese eher zu Informationen als zu Daten gehört. Der Einfachheit halber wurde hier aber die direkte Übersetzung von data objects gewählt.

In der BPMN können Datenobjekte einer Aktivität oder einem Sequenzfluss zugeordnet werden. Außerdem können sie in einem eigenen Fluss neben dem Sequenzfluss dargestellt werden. In der folgenden Abbildung sind zwei Datenobjekte eingebaut. Zuerst der Auftrag, der ins Unternehmen kommt und damit den Geschäftsprozess ja erst auslöst. Er wird ganz einfach der Aktivität Auftragseingang zugewiesen. Durch die Pfeilspitze wird der Informationsfluss ausgedrückt. Das zweite Datenobjekt in diesem Beispiel ist die Rechnung. Sie ist der Aktivität Rechnung senden zugeordnet.

Abbildung 5.2-1: Auftragsabwicklung - Variante 3.
Quelle: In Anlehnung an [OMG 2009a, S. 104, Figure 10.12], [OMG 2011, S. 269, Figure 10.85]. Übersetzung durch den Verfasser

Enthaltene Elemente - zusätzlich zur vorigen Abbildung:

- Datenobjekt

Mehr zu Datenobjekten findet sich in Kapitel 8.

5.3 Handelnde - Träger der Aktivitäten

Für eine Basisausstattung einer Methode zur Prozessmodellierung fehlen jetzt nur noch die im Geschäftsprozess Handelnden. Diese werden zuerst einmal für die einzelnen Aktivitäten bestimmt. Möglich sind hier Menschen oder auch Programme, mit oder ohne Maschinen [Anmerkung] . Für die Zuordnung der Träger von Aktivitäten haben die BPMN-Autoren die bekannte Schwimmbahnentechnik gewählt. Bei ihr werden Becken (pools) und Bahnen (lanes) angelegt. Becken erfassen die übergeordneten Träger (z.B. ganze Unternehmen), Bahnen die untergeordenten (z.B. Abteilungen oder Personen auf Stellen). Die folgende Abbildung zeigt das erweiterte einführende Beispiel.

Das obere Becken enthält alle Aktivitäten, die durch das hier betrachtete Unternehmen realisiert werden. Es ist weiter unterteilt in zwei Bahnen, eine für die Abteilung Auftragsbearbeitung, eine für die Abteilung Finanzwesen. Die Aktivitäten sind in der Bahn der Abteilung, die sie realisiert. Der Sequenzfluss geht dann entsprechend zwischen den Bahnen hin und her.

Der Kunde ist eine eigene handelnde Einheit und wird deshalb in der BPMN durch ein eigenes Becken dargestellt. Zwischen verschiedenen "handelnden Einheiten" [Anmerkung] gibt es - so der Vorschlag der BPMN-Autoren - keine Sequenzflüsse, sondern nur Nachrichtenflüsse. Deshalb wurde hier das Verschicken der Rechnung zum Kunden als Nachricht modelliert, ebenso die umgekehrte Information ("Zahlungseingang").

Abbildung 5.3-1: Auftragsabwicklung - Variante 4.
Quelle: In Anlehnung an [OMG 2009a, S. 104, Figure 10.12], [OMG 2011, S. 269, Figure 10.85] Übersetzung durch den Verfasser

Enthaltene Elemente - zusätzlich zur vorigen Abbildung:

- Becken

- Bahn

- Nachrichtenfluss

5.4 Ein öffentlicher Geschäftsprozess

Öffentliche Geschäftsprozessewurden oben schon kurz vorgestellt. Die BPMN-Autoren verstehen darunter die Vorgänge, die zwischen einem internen Geschäftsprozess und einem anderen Prozess stattfinden.

Wie oben schon ausgeführt, wird die Kommunikation mit externen Partnern in der BPMN nicht als Kontrollfluss, sondern durch Austausch von Nachrichten modelliert. So wie im folgenden Beispiel. Dort ist der Patient als Becken ohne Aktivitäten dargestellt. Dies ist in der BPMN möglich. Die Nachrichtenflüsse zu einem solchen Teilnehmer am Geschäftsprozess enden und starten dann an der Grenzlinie des Beckens. Ansonsten dürfte das Beispiel selbsterklärend sein.

Abbildung 5.4-1: Kontakt zwischen Arztpraxis und Patient - Version 1.
Quelle: [OMG 2011, S. 24, Figure 7.2]. Übersetzung durch den Verfasser

Enthaltene Elemente:

- Becken

- Becken mit öffentlichem Prozess

- Startereignis

- Aufgaben

- Nachrichtenflüsse

Insgesamt werden Varianten dieses Geschäftsprozesses in den Abbildungen 5.4-1, 5.5-1, 5.6-1, 7.2-1, 7.2-2 und 13.1-1 betrachtet.

5.5 Zusammenarbeit

Eine Zusammenarbeit (collaboration) beschreibt die Interaktionen zwischen zwei oder mehr Teilnehmern am Prozessgeschehen, die normalerweise durch je ein Becken erfasst werden. Zwischen diesen kann es ja nur Nachrichtenverkehr geben, der die Becken oder die Objekte im Becken verknüpft.

Liegen öffentliche Prozesse vor, können die Aktivitäten für die Kollaboration als die Berührungspunkte zwischen den Teilnehmern aufgefasst werden. Die zugehörigen internen Prozesse können viel mehr Innenleben haben, als mit dem öffentlichen Prozess gezeigt wird. Ein Becken kann auch als "black box" leer bleiben, wie oben gezeigt.

Die folgende Abbildung zeigt, in Anlehnung an das Beispiel oben, diesen ausgestalteten Prozess beim Patienten und den Nachrichtenverkehr zwischen einzelnen Aktivitäten. Wenn dann - wie hier - zwei oder mehr öffentliche Prozesse miteinander kommunizieren, sprechen die BPMN-Autoren von einem globalen Prozess. Bei diesem verlaufen die Nachrichtenflüsse zwischen je zwei Aktivitäten der Geschäftsprozesse. [OMG 2011, S. 24f].

Abbildung 5.5-1: Kontakt zwischen Arztpraxis und Patient - Version 2.
Quelle: [OMG 2011, S. 25, Figure 7.3]. Übersetzung durch den Verfasser.

Enthaltene Elemente:

- Startereignis

- Aufgabe

- Schlussereignis

- Nachrichtenfluss

- öffentlicher Geschäftsprozess

- Nachrichten zwischen Prozessen

Insgesamt werden Varianten dieses Geschäftsprozesses in den Abbildungen 5.4-1, 5.5-1, 5.6-1, 7.2-1, 7.2-2 und 13.1-1 betrachtet.

6 Tätigkeiten

6.1 Aktivitäten

Die einzelnen Tätigkeiten, in die der Gesamtprozess im Rahmen einer Prozessmodellierung zerlegt wird, werden in der BPMN mit Aktivität(activity) bezeichnet. Dies hat mit dem gleichnamigen Begriff aus der UML direkt nichts zu tun. Er entspricht dem, was bei den Ereignisgesteuerten Prozessketten Funktion und bei den UML-Aktivitätsdiagrammen Aktion genannt wird. Wie auch schon oben angegeben, wird eine BPMN-Aktivität in den Abbildungen durch ein Rechteck mit abgerundeten Ecken dargestellt.

Abbildung 6.1-1: Grafische Darstellung von Aktivitäten

Die BPMN-Autoren definieren Aktivitäten als Arbeit, die in einem Geschäftsprozess erledigt wird. Diese etwas unscharfe Definition wird ein wenig präzisiert durch die Festlegung, dass eine Aktivität elementar ("atomic") oder auch nicht ("non-atomic") sein kann und durch die Festlegungen der Ebenen, auf denen Aktivitäten angesiedelt sein können. Dies sind drei ([OMG 2011, S. 151]):

• Aufgaben(task)
• Subprozesse(sub process)
• Prozesse

Aktivitäten sind also die ausführbaren Elementeeines BPMN-Prozesses. Zu einer Aktivität führen damit Sequenzflüsse hin und weg. Sind es mehrere hin- oder wegführende kann deren innere Struktur durch einen Operator(hier: Gateway) geklärt werden, so wie allgemein in der Prozessmodellierung üblich (vgl. Kapitel 11).

Werden mehrere Sequenzflüsse ohne Gateway zu einer Aktivität geführt, bezeichnen dies die BPMN-Autoren als unkontrollierten Fluss. Dann gilt: Kommt ein Token an, wird die Aktivität gestartet. Kommt ein weiteres Token an, wird eine neue Instanz der Aktivität gestartet.

6.2 Aufgaben

Auf der untersten Ebene sind die Aufgaben angesiedelt, die als "atomar" (atomic) bezeichnet werden. Es sind also elementare Tätigkeiten, die im jeweiligen Kontext nicht weiter unterteilt werden. Die Wortwahl macht die Subjektivität deutlich, die natürlich erhalten bleibt. Hier die Definition:

Definition Aufgabe (BPMN)

Eine Aufgabe ist eine atomare Aktivität in einem Prozessfluss. Sie wird benutzt, wenn die Tätigkeit nicht weiter detailliert werden kann. ([OMG 2011, S. 156], Übersetzung durch den Verfasser)

Ausgeführt werden die Aufgaben durch "Enduser" (Handelnde im Prozess) oder Anwendungsprogramme. Konkret bedeutet dies keine tayloristische Ebene, aber doch eine, die an elementaren Aufgaben orientiert ist. Eher also Kalkulation durchführen als Angebot erstellen. Die teilweise Beliebigkeit einer solchen Festlegung (vgl. dazu auch [Staud 2010] und [Staud 2014]) wird dadurch allerdings auch nicht überwunden.

6.2.1 Varianten

Drei Varianten bzgl. der inneren Struktur von Aufgaben können durch grafische Zeichen (marker) gekennzeichnet werden:

• Aufgaben mit Schleifencharakter durch eine Schleifenmarkierung (loop marker).
• Aufgaben, die parallel mehrfach durchgeführt werden können (bei denen also gleichzeitig mehrere Instanzen gestartet werden können) durch eine Mehrfachinstanzmarkierung (multi instance marker).
• Aufgaben, die als Ersatz für andere dienen ("zur Kompensation") durch eine Kompensationsmarkierung (compensation marker) .

Die folgende Abbildung zeigt die grafische Darstellung der Markierungselemente.

Abbildung 6.2-1: Drei Varianten von Aufgaben - Mehrfachinstanz, Kompensation, Schleife

Mehrfachinstanzen

Es gibt Aufgaben, die - ohne dass auf die Erledigung vorheriger Aufgaben gewartet wird - neu gestartet werden können (sozusagen parallel). Nehmen wir zum Beispiel das Versenden von Paketen bei einem Internethändler. Eine solche Aufgabe wird als Mehrfachinstanz / parallel gekennzeichnet. Diese Markierung besteht, wie oben gezeigt, aus drei senkrecht angeordneten Linien.

Handelt es sich um eine Aufgabe, bei der zwar auch mehrere Instanzen gestartet werden können, aber nur nacheinander (sequentiell), wird die Aufgabe als Mehrfachinstanz / sequentiell markiert. Diese Markierung besteht aus drei waagrecht angeordneten Linien.

Abbildung 6.2-2: Grafische Darstellung von Aufgaben - Mehrfachinstanzmarkierungen

Die Mehrfachinstanzmarkierung kann zusammen mit der Kompensationsmarkierung verwendet werden. Die Anzahl der Instanzen kann berechnet werden oder sich aus den Daten ergeben. Wesentlich ist, dass eine weitere Instanz gestartet werden kann, ohne dass eine andere abgearbeitet sein muss.

Kompensationen

Es gibt Aufgaben, für die man bei der Modellierung gleich angibt, was geschehen soll, falls die Durchführung scheitert. D.h., die Aufgabe verweist auf eine andere Aufgabe, die im Fall des Scheiterns ausgeführt werden soll. Diese erhält die Kompensationsmarkierung.

Eine solche Situation könnte man natürlich auch über ein nachfolgendes Exclusive Gateway mit "gescheitert" als einer Option realisieren, eleganter (auch vom Modellumfang her) ist aber der Verweis auf eine Kompensations-Aufgabe.

Insgesamt sind bei einer Kompensation zwei Aufgaben im Spiel: Eine, bei der durch ein Kompensations-Ereignis der Fall des Scheiterns erfasst wird und eine mit der Kompensations-Aufgabe. Zwischen diesen beiden besteht ein grafisch nicht ausgewiesener Sequenzfluss. Für ein grafisches Beispiel vgl. Abschnitt 10.6.

Ein Beispiel ist die Durchführung einer Überweisung. Scheitert diese, muss man die Daten zurücksetzen. Diese eventuelle Zurücksetzung der Daten ist die Aufgabe mit Kompensationsmarkierung.

Aufgaben mit Schleifencharakter

Oftmals gibt es in Geschäftsprozessen Aufgaben, die wiederholt ausgeführt werden müssen. Dabei geht es um Aufgaben, die hintereinander erledigt werden. D.h., wenn eine erledigt ist, startet die nächste. Z.B. beim Abtelefonieren der Lieferanten zwecks einer gewünschten Lieferung oder beim morgendlichen Abarbeiten der Mailzugänge. Aufgaben dieser Art erhalten die Schleifenmarkierung, so dass beim Betrachten des Modells gleich der Schleifencharakter der Aufgabe deutlich wird.

Die Schleife wird durch einen booleschen Ausdruck festgelegt und solange durchlaufen, wie dessen Prüfung ja ergibt. Zum Beispiel: Alle Mails bearbeitet (J/N)?

Für diese Situation könnte auch eine ausdrückliche Schleife im Sequenzfluss (vgl. Abschnitt 10.5) modelliert werden (falls die Aufgabe zerlegbar ist). Für elementare Aufgaben ist aber die hier vorgestellte Lösung auf jeden Fall die geeignetere, weil sie einen nicht zwingt, u.U. künstlich zu zerlegen (bei doch sehr elementaren Aufgaben) und weil sie platzsparend ist.

Auch bei Subprozessen

Obige Kennzeichen gibt es auch bei Subprozessen (vgl. den nächsten Abschnitt). Dort bedeuten sie im Prinzip dasselbe, nur dass in diesem Abschnitt einzelne Aufgaben gemeint sind und bei den Subprozessen kurze Prozessabschnitte. Am Beispiel der Schleifenmarkierung: Eine Aufgabe könnte die Abarbeitung des Maileingangs, ein Subprozess die Auslieferung von Paketsendungen sein. Dieser besteht (bei einem entsprechenden Aggregationsniveau) aus mehreren Tätigkeiten, die ständig wiederholt werden müssen.

6.2.2 Aufgabentypen

In der BPMN werden verschiedene Typen von Aufgaben unterschieden. Bei dieser Typisierung und der damit einhergehenden Kennzeichnung der Aufgaben geht es um folgende Aspekte:

• Anteil des Mitwirkens von Menschen
• Anteil von Software an der Erledigung
• Ausrichtung auf Nachrichtenverkehr

Die ersten zwei Punkte dienen der Erfassung des Automatisierungsgrades. Wobei Automatisierung hier automatische Erledigung durch Programme und Maschinen meint.

Alle Aufgabentypen werden wie oben gezeigt durch ein Rechteck mit abgerundeten Ecken und einer einzigen dünnen durchgezogenen Linie dargestellt. Hinzu kommt jeweils für den Aufgabentyp ein grafisches Symbol in der linken oberen Ecke des Rechtecks. Eine Aufgabe ohne Typ wird als abstrakte Aufgabe bezeichnet.

Handarbeit (manual task object)

Trotz aller Automatisierung gibt es in Geschäftsprozessen Aufgaben, die von Menschen erledigt werden müssen, und das gilt nicht nur für Entscheidungsprozesse. Die BPMN stellt dafür zwei Aufgabentypen bereit, die Erledigung durch einen Menschen ohne Softwareunterstützung (Handarbeit; manual task) und die Erledigung durch einen Menschen mit Hilfe eines Anwendungsprogramms (Programmnutzung; user task). Ganz aktuell macht die Entwicklung bei Robotern einen Sprung vorwärts, auch Techniken zur kompletten Einzelfertigung sind in der Entwicklung. Dies wird, wenn dann diese neuen Möglichkeiten in den typischen Geschäftsprozessen angekommen sind, neue Methodenelemente nötig machen.

Handarbeit meint eine Aufgabe, die nicht von einer Business Process Engine oder einem Anwendungsprogramm ausgeführt wird. Zum Beispiel die Tätigkeiten eines Telefontechnikers auf der Basis einer papiergestützten Anweisung [OMG 2011, S. 163]. Als Kennzeichnung dient die Skizze einer Hand.

Abbildung 6.2-3: Grafische Darstellung von Aufgaben - Handarbeit

Nutzer-Aufgabe (user task object)

Eine Aufgabe des Typs Nutzer-Aufgabe (user task object) wird von Menschen mit Hilfe von Anwendungsprogrammen durchgeführt. Die Aufgabenerledigung wird durch einen Task List Manager gesteuert. Die Kennzeichnung erfolgt durch ein Symbol, das die obere Hälfte eines Menschen andeutet.

Eine solche Aufgabe kann auf unterschiedliche Weise implementiert werden, z.B. auch durch WebService - Technologien.

Abbildung 6.2-4: Grafische Darstellung von Aufgaben - Nutzer-Aufgabe

Dienst (service task object)

Bei einer Aufgabe des Typs Dienst (service task object) wird bei der Erledigung ein Dienst verwendet, zum Beispiel ein WebService oder ein automatisch ablaufendes Anwendungsprogramm. Die Kennzeichnung erfolgt durch ein Symbol, das zwei versetzt hintereinander liegende Zahnräder darstellt.

Abbildung 6.2-5: Grafische Darstellung von Aufgaben - Dienst-Aufgabe

Sender

Eine Aufgabe, die dem Versenden einer Nachricht gewidmet ist, wird Sender-Aufgabe (send task object) genannt. Dabei geht es um Nachrichten an einen externen Prozessteilnehmer. Die Kennzeichnung erfolgt durch einen schwarz eingefärbten Briefumschlag, was der Kennzeichnung eines Ereignisses vom Typ Nachricht / abgebend entspricht (vgl. Kapitel 9.2.2).

Abbildung 6.2-6: Grafische Darstellung von Aufgaben - Sender-Aufgabe

Nach dem Versenden der Nachricht ist die Aufgabe abgearbeitet.

Empfänger-Aufgabe

Eine Empfänger-Aufgabe (receive task object) ist gedacht für Aufgaben, bei denen auf eine Nachricht von einem externen Prozessteilnehmer gewartet wird. Es wird auch genutzt, um einen Prozess zu starten, falls also ein Prozess durch eine Nachricht gestartet wird. Die Kennzeichnung erfolgt durch einen nicht eingefärbten Briefumschlag, entsprechend den Ereignissen vom Typ Nachrichten / empfangend (vgl. Kapitel 9.2.2).

Abbildung 6.2-7: Grafische Darstellung von Aufgaben - Empfänger

Nach dem Empfangen der Nachricht ist die Aufgabe abgearbeitet.

Prozessstart-Aufgabe

Will man ausdrücken, dass ein Prozess durch eine Nachricht eines externen Teilnehmers am Prozessgeschehen gestartet wird, kann dies durch den Aufgabentyp Prozessstart (receive task object mit Ereignissymbol) ausgedrückt werden. Das Ereignis ist vom Typ Nachricht / Startereignis / empfangend (vgl. Kapitel 9.2.2).

Abbildung 6.2-8: Grafische Darstellung von Aufgaben - Aufgabe Prozessstart

Vgl. hierzu auch Abschnitt 12.1, wo das Muster Prozessstart diskutiert wird.

Geschäftsregel-Aufgabe

Eine Geschäftsregel-Aufgabe (Aufgabe des Typs Geschäftsregel; business rule task) dient dazu, Input an eine Business Rules Engine zu liefern und die dort erzielten Ergebnisse zu empfangen. Es werden also Daten gesendet und empfangen. Die Kennzeichnung in Form einer abstrahierten Tabelle (links oben) zeigt die folgende Abbildung.

Abbildung 6.2-9: Grafische Darstellung von Aufgaben - Geschäftsregel

Skript-Aufgabe

Eine Aufgabe des Typs Skript (script task object) wird durch eine Business Process Engine ausgeführt. Der Modellierer oder Entwickler schreibt ein Skript in einer Sprache, die die Business Process Engine interpretieren kann. Sobald die Aufgabe startbereit ist, wird sie ausgeführt. Wenn das Skript abgearbeitet ist, ist auch die Aufgabe abgeschlossen.

Die grafische Kennzeichnung erfolgt durch ein Symbol, das ein gewelltes Blatt mit Beschriftung darstellen soll.

Abbildung 6.2-10: Grafische Darstellung von Aufgaben - Skript

Globale Aufgabe

Globale Aufgaben (global tasks) enthalten eine wiederverwendbare elementare Aufgabe(ndefinition), die von jedem Prozess durch eine Call Activity(vgl. Abschnitt 6.2) aufgerufen werden kann. Folgende der oben eingeführten Aufgabentypen sind hier möglich:

• Globale Nutzer-Aufgabe (global user task)
• Globale Handarbeit (global manual task)
• Globales Skript (global script task)
• Globale Geschäftsregel (global business rule task)

Die grafische Gestaltung ist wie oben, nur dass die Randlinie des Symbols verdickt ist.

Abbildung 6.2-11: Grafische Darstellung von Aufgaben - Globale Nutzer-Aufgabe

6.2.3 Zusammenfassung

In den folgenden Abbildungen sind alle Aufgaben zusammengestellt. Zuerst gruppiert nach den von den BPMN-Autoren gewählten Unterscheidungskriterien.

Da ist zum einen der Automatisierungsgrad der Aufgabenerledigung und die Art der Automatisierung (Dienst, Skript, Geschäftsregel). Ersteres gibt u.U. Hinweise auf Optimierungspotential, wenn durch weitere Automatisierungsschritte der Prozess effizienter gestaltet werden kann, zweiteres zielt auf die Umsetzung des Prozessmodells in softwaregestützte Lösungen.

Dann findet sich eine Gruppe von Aufgaben für den Nachrichtenverkehr. Mit ihnen wird also die Nachricht nicht nur einfach in den Sequenzfluss eingefügt, sondern mit einer Aufgabe verbunden. D.h. Nachricht und damit zusammenhängende Tätigkeit sind verknüpft.

Die nachfolgenden Call Activities betreffen globale Aufgaben. Das sind meist solche, die an vielen verschiedenen Stellen im Prozess benötigt werden. Das dargestellte Symbol steht für den Aufruf der globalen Aufgabe im Ausgangsprozess.

Die nächste Gruppe enthält Aufgaben mit spezifischen inneren Strukturen, wie sie in jeder Geschäftsprozessmodellierung vorkommen, die schleifenförmige Anordnung der Tätigkeiten, das parallele oder sequentielle Starten mehrerer Prozessdurchgänge (Instanzen) und das Korrigieren bei Fehlschlag.

Abbildung 6.2-12: Die Aufgaben der Methode BPMN im Überblick

Die Abbildung der nächsten Seite stellt die Aufgaben mit ihrer grafischen Repräsentation und einer Kurzbeschreibung zusammen.

Aufgaben in der BPMN und ihre grafische Darstellung

6.3 Subprozesse

6.3.1 Entfaltet oder verborgen

Subprozesse werden wie Aufgaben durch ein grafisches Symbol dargestellt. Die Unterscheidung entfaltet (expanded) / verborgen (collapsed) bezieht sich nur auf die Darstellung. Werden die im Subprozess enthaltenen einzelnen Arbeitsschritte dargestellt, wird von einem entfalteten, ansonsten von einem verborgenen Subprozess gesprochen.

Ein Subprozess ist eine aus Aktivitäten, Gateways, Ereignissen und Sequenzflüssen zusammengesetzte Tätigkeitsfolge, die in einem übergeordneten Prozess enthalten ist. Letzterer wird auch als Elternprozess bezeichnet. Die Definition ist wie folgt:

Definition Subprozess

Ein Subprozess ist eine zusammengesetzte, zerlegbare Tätigkeit, die in einem Prozess enthalten ist ([OMG 2011, S. 173], Übersetzung durch den Verfasser).

Wesentlich ist, dass Subprozesse als Ganzes aufgerufen werden und nicht einzelne ihrer Aktivitäten.

Ein Subprozess kann grafisch durch ein einzelnes beschriftetes Symbol dargestellt werden (verborgen) oder aber als Prozess in einem Rahmen (entfaltet). Die grafische Ausgestaltung eines verborgenen Subprozesses (collapsed sub process) ist wie bei Aufgaben, allerdings ergänzt durch ein in ein Quadrat gepacktes Pluszeichen. Dies signalisiert, dass es sich um einen Subprozess handelt und nicht um eine Aufgabe. Die folgende Abbildung zeigt ein Beispiel.

Abbildung 6.3-1: Darstellung eines verborgenen Subprozesses

Vgl. zu Beispielen den Eintrag Subprozess (verborgen) im Stichwortverzeichnis.

Ein Subprozess kann auch mit allen Methodenelementen in einem Rahmen dargestellt werden. Dann wird er entfalteter Subprozess (expanded sub process) genannt. Genauso wie die verborgenen Subprozesse sind auch die entfalteten über Sequenzflüsse mit dem übrigen Prozess verbunden. In der folgenden Abbildung ist dies durch die seitlichen Pfeile angedeutet.

Abbildung 6.3-2: Darstellung eines entfalteten Subprozesses

Vgl. zu Beispielen den Eintrag Subprozess (entfaltet) im Stichwortverzeichnis.

Motivation

Ein Subprozess enthält also zusammenhängende abgrenzbare Tätigkeitsfolgen. Eine Besonderheit ist, dass diese Tätigkeitsfolgen nur als Ganzes vom übrigen Prozess aufgerufen werden können (auf unterschiedliche Weise, wie unten gezeigt wird). Dieses Element ist in allen Methoden zur Prozessmodellierung auf die eine oder andere Weise vorhanden.

Oftmals ist es dadurch motiviert, dass in einer Prozessbeschreibung verschiedene Modellierungsebenen sichtbar werden. Zum einen die der Prozessebene (im Sinne einer Standardprozessmodellierung), zum anderen eine, auf der einzelne Aufgaben detailliert näher beschrieben werden. Dann ist es sinnvoll, diese detaillierteren Beschreibungen zu kapseln, z.B. in einen Subprozess. Beispiele finden sich im Prozess Anfrageprüfung und Angebotserstellung in Abschnitt 14.6 (Subprozess Angebotserstellung) und im Geschäftsprozess Auftragsstart im Anlagenbau (Kostenstruktur eintragen, Stundenvorgabe erstellen, Rechnungsstellungstermine ermitteln) in Abschnitt 14.7.

Ein eher darstellungstechnische Motiv speziell für verborgene Subprozesse ist der Wunsch, Prozessabschnitte, die oftmals vorkommen, in einen verborgenen Subprozess zu packen und nur einmal im Rahmen des Gesamtmodells (der Prozesslandschaft) ausführlich darzustellen. Dies macht das Prozessmodell übersichtlicher. Damit liegt dann das vor, was im allgemeinen Kapselunggenannt wird.

Dies kann auch so weit getrieben werden, dass mehrere Modellierungsebenen dargestellt werden, die von "oben nach unten" immer detaillierter werden. Solche Darstellungen erleichtern den Einstieg in ein komplexes Prozessmodell und den Überblick über seine gesamten Funktionalitäten.

Weitere modellierungstechnische Motive speziell bei der BPMN ergeben sich durch die Art des Aufrufs. Z.B., wenn man ausdrücken will, dass ein Prozessfragment durch Ereignisse ausgelöst werden kann. Hierfür sehen die BPMN-Autoren die sog. Ereignissubprozesse (event sub process) vor.

6.3.2 Varianten

Ähnlich wie bei den Aufgaben gibt es auch hier Varianten, die durch ein grafisches Symbol gekennzeichnet werden.

• Subprozesse mit Schleife: durch eine unterbrochene schmale Linie in Kreisform mit Pfeilkopf.
• Subprozesse mit Parallelverarbeitung: parallele oder sequentielle Mehrfachinstanzen mit drei senkrechten bzw. parallelen Linien.
• Subprozesse für Ersatzaktivitäten(compensation): durch zwei nach links zeigende Dreiecke.
• Ad hoc - Subprozesse: durch eine Tilde.

Es kann vorkommen, dass ein Subprozess mehrere dieser Merkmale und damit mehrere dieser Kennzeichen hat. In einem solchen Fall werden alle zu einem Subprozess gehörigen Kennzeichen zusammengestellt und zentriert am inneren unteren Rand des Subprozessrahmens angegeben. Welche Merkmale tatsächlich in Kombination auftreten können, wird unten betrachtet.

Schleifen

Bei einem verborgenen Subprozess mit Schleifenkennzeichnung deutet man an, dass die Tätigkeiten Schleifencharakter haben, sie werden öfters nacheinander ausgeführt. Eine solche Situation ergibt sich in der Prozessmodellierung tatsächlich sehr oft. Geeignet sind alle repetitiven Tätigkeiten, bei denen man darauf verzichtet, die "innere Schleife" ausdrücklich im Geschäftsprozess zu modellieren. Z.B. Befragung durchführen oder E-Mail - Eingang bearbeiten.

Hier wird die Kennzeichnung als Subprozess ergänzt um das Symbol für den Schleifencharakter.

Abbildung 6.3-3: Darstellung eines verborgenen Subprozesses mit Schleifencharakter (loop)

Dieser Schleifentyp darf nicht verwechselt werden mit einer Schleife im Geschäftsprozess, die man in den Sequenzfluss einbaut ("Rücksprung nach flussaufwärts"). In einem solchen Fall wird die Schleife explizit im Prozessmodell ausgewiesen. Vgl. hierzu Abschnitt 10.5.

Mehrfachinstanzen

Bei einem verborgenen Subprozess mit dem Kennzeichen Mehrfachinstanz wird deutlich gemacht, dass der Subprozess mehrere Instanzen haben kann, die parallel oder sequentiell gestartet werden können. Somit entstehen zwei Subprozesstypen:

• Subprozesse mit Mehrfachinstanz - parallel (multi-instance, parallel)
• Subprozesse mit Mehrfachinstanz - sequentiell (multi-instance, sequential)

Abbildung 6.3-4: Darstellung eines verborgenen Subprozesses mit Mehrfachinstanz - parallel oder sequentiell

Hintergrund: Prozessablauf

Die einfachste Vorstellung für den Prozessablauf ist, dass eine Instanz gestartet und durchlaufen wird und erst dann die nächste gestartet wird, falls dies nötig ist. In der Wirklichkeit ist es aber so, dass die meisten Prozesse es zulassen, dass mehrere Instanzen gleichzeitig ("parallel") oder nacheinander ("sequentiell") gestartet werden. Dies gilt für nicht-automatisierte Prozessabschnitte, falls die Kapazitäten vorhanden sind, genauso wie für die automatisierten.

Beispiele sind Auftragseingänge, wenn viele parallel angenommen und bearbeitet werden können (parallel), oder Auslieferungen, wenn aufgrund der Stellen- und Personalausstattung nur jeweils eine Auslieferung stattfinden kann, im Tagesverlauf aber viele hintereinander. Dies könnte natürlich auch auf andere Weise modelliert werden, z.B. durch jeweiligen Neustart des Prozesses oder durch eine explizite Prozessschleife (vgl. Abschnitt 10.5).

Kompensationen

Nehmen wir folgende Situation an: Ein Suprozess (z.B. eine Hotelbuchung mit Hilfe des Internet) soll im Rahmen des Geschäftsprozesses durchgeführt werden. Für den Fall, dass er scheitert, ist ein Subprozess vorgesehen, der die Aufgabe (z.B. die Buchung) auf andere Weise erledigt (z.B. telefonisch). Als ein weiteres Beispiel stellen wir uns vor, dass eine Überweisung durchzuführen ist und dass im Falle eines Scheiterns die Daten zurückgesetzt werden müssen.

Die Kennzeichnung von Kompensations-Subprozessen erfolgt durch zwei nach links zeigende Dreiecke.

Abbildung 6.3-5: Darstellung eines verborgenen Subprozesses mit Kompensation (compensation)

Ad hoc

"Ad hoc" ist bei den BPMN-Autoren der Begriff für Abläufe, die nicht in einen Sequenzfluss gebracht werden können oder sollen. Solche Situationen gibt es durchaus in Geschäftsprozessen:

• Kreative Tätigkeiten, z.B. der Entwurf einer Strategie für eine Produkteinführung, Tätigkeiten bei der Erstellung eines Kapitels für ein Fachbuch (Gegenstand erarbeiten, Grafiken erzeugen, Verweise klären, Text schreiben, Grafiken in Text einbinden, Text editieren, usw.)
• Miteinbeziehung nicht standardisierter Prozesse in ein Prozessmodell (aus was für Gründen auch immer)

Solche Abäufe sind, wenn man nicht abstrahiert, durchaus nur sehr schwer durch einfache Sequenzflüsse modellierbar.

Für einen Ad hoc-Subprozess im Sinne der BPMN gilt also, dass es zwar eine klar definierte Menge von Aktivitäten gibt, für diese aber keinen definierten Sequenzfluss [OMG 2011, S. 180]. Sei es, dass dieser nicht bekannt ist oder dass er nicht erhoben werden kann bzw. soll. Wobei die BPMN-Autoren das "nicht können" betonen: "… and cannot be defined beforehand" [OMG 2009, S. 128].

In der konkreten Geschäftsprozessrealisierung werden die Aktivitäten dann spontan (in einer spontan realisierten Reihenfolge) abgearbeitet.

Aktivitäten in einem solchen Prozess sind im Business Process Diagram voneinander getrennt. Während der Prozessausführung können die Aktivitäten beliebig aktiv sein und in beinahe beliebiger Reihenfolge und Häufigkeit ausgeführt werden. Dann gilt, dass ein Attribut hinzugefügt wird (AdHocOrdering attribute), das angibt, ob die Aktivitäten parallel oder sequentiell ausgeführt werden müssen. Die Voreinstellung ist parallel. Außerdem gilt, dass dann ein weiteres Attribut angelegt werden muss, die AdHocCompletionCondition. Dieses gibt an, unter welchen Bedingungen der Prozess endet.

Die Kennzeichnung von Ad hoc-Subprozessen erfolgt durch eine Tilde.

Abbildung 6.3-6: Darstellung eines verborgenen Ad hoc - Subprozesses

Ad hoc - Entfaltet

Handelt es sich um einen entfalteten Ad hoc-Prozess werden die beteiligten Aktivitäten innerhalb eines Rechtecks mit gerundeten Ecken platziert. Die folgende Abbildung zeigt ein Beispiel. Es wird kein Sequenzfluss ausgewiesen. Dass die BPMN-Autoren hier aber trotzdem Informationsflüsse und einzelne Sequenzflüsse für modellierbar halten, zeigt die diesbezügliche Fortsetzung dieses Beispiel in Abbildung 8.3-6.

Abbildung 6.3-7: Entfalteter Ad hoc - Subprozess Buchkapitel schreiben.
Quelle: [OMG 2011, S. 182, Figure 10.37], Übersetzung durch den Verfasser.

Enthaltene Elemente:

- Entfalteter Subprozess mit Mehrfachinstanz (parallel).

- Aufgabe, ohne Markierung

- Aufgabe mit Mehrfachinstanz, parallel

- Aufgabe mit Schleife

Als Beispiele für Ad hoc-Prozesse nennen die BPMN-Autoren auch die Programmentwicklung (auf einer niedrigeren Ebene) und Verkaufsunterstützung.

Folgende Einschränkungen gelten für den Gebrauch von Theorieelementen in AdHoc-Subprozessen:

• Vorhanden sein müssen: Aktivitäten
• Vorhanden sein können: Datenobjekte, Sequenzflüsse, Assoziationen, Gruppen, Nachrichtenflüsse (als Quelle oder Ziel), Gateways und Zwischenereignisse.
• Nicht vorhanden sein dürfen u.a.: Startereignisse, Schlussereignisse, und Choreographie-Aktivitäten.

Die BPM-Autoren führen aus, dass es für eine "BPM engine" eine Herausforderung darstellt, den Status von Ad hoc-Prozessen zu beobachten. Diese Art von Prozessen wird üblicherweise durch Groupware (groupware applications) unterstützt (die BPMN-Autoren erwähnen E-Mail(!)), was die Situation erschwert. Aber - so die Autoren - BPMN erlaubt auch das Modellieren von Prozessen, die nicht unbedingt ausführbar sind und sollte die Mechanismen für die "BPM engines" liefern, die einem Ad hoc-Prozess folgen können.

Irgendwann ist dann auch ein solcher Prozess abgeschlossen. Dies wird durch die Prüfung einer Schlussbedingung festgestellt, die Prozessattribute abfragt, die durch eine Aktivität des Prozesses aktualisiert wurden.

Mehrere Kennzeichnungen

Obige Abbildung zeigt einen Subprozess mit mehr als zwei Kennzeichen. Der Ad hoc-Prozess (Tilde) ist gleichzeitig einer mit parallellen Mehrfachinstanzen. D.h., das Schreiben des Buchkapitels erfolgt parallel mit mehreren anderen Kapiteln. Eine solche Zuordnung mehrerer Kennzeichen ist auf verschiedene Art und Weise möglich. Grundsätzlich gilt: Ein verborgener Subprozess kann neben seiner Kennzeichnung als "versteckt" nicht nur eine, sondern bis zu drei weitere Kennzeichnungen haben. Dabei sind alle Kombinationen möglich mit der Ausnahme, dass die gleichzeitige Kennzeichnung als Schleife und als parallelverarbeitender Subprozess (parallele Mehrfachinstanzen / multiple instance) nicht möglich ist. Die folgende Abbildung zeigt alle möglichen Kombinationen.

Abbildung 6.3-8: Mögliche Kombinationen von Suprozess-Markierungen

Das folgende Beispiel stellt einen Subprozess mit mehreren Markierungen dar. Im Rahmen einer Fachbucherstellung, deren innerer Zusammenhang nicht in Sequenzflüsse abgebildet werden soll, wird auch noch das "immer wieder rangehen" durch die Schleifenmarkierung angedeutet.

Abbildung 6.3-9: Kombinationen von Suprozesskennzeichnungen - Schleife und Ad hoc-Struktur

6.3.3 Typen

In der BPMN kann im Prozessmodell auch ausgedrückt werden, auf welche Art und Weise ein Subprozess in den Prozess eingebettet ist, von dem er ausgelöst wird. Die BPMN-Autoren unterscheiden diesbezüglich folgende Typen:

• Eingebettete und referenzierte Subprozesse (embedded sub-process)
• Wiederverwendbare Subprozesse (reusable sub processes; call activities)
• Ereignis-Subprozesse (event sub processes)
• Transaktionen

Eingebettet und referenziert

Ein Subprozess, der in einen anderen (den Elternprozess) Prozess eingefügt ist, wird eingebettet (embedded/nested) genannt. Er wird auf die eine oder andere Weise vom übergeordneten Prozess initiiert und kann auf dessen globale Daten zugreifen. Zu ihm ist also kein Datentransfer nötig. Für ihn stehen die meisten Theorieelemente zur Verfügung. Er darf keine Becken und Bahnen enthalten, aber Flussobjekte, Verknüpfungselemente und Artifakte [OMG 2009, S. 58]. Solche Subprozesse existieren somit innerhalb des Elternprozesses.

Es gibt auch Subprozesse, die unabhängig von einem bestimmten Elternprozess existieren. Auf sie kann von verschiedenen anderen Prozessen verwiesen werden. Ein solcher Subprozess hat nicht, wie der eingebette Subprozess, Zugriff auf die Daten des aufrufenden Prozesses, zu ihm müssen diese, falls notwendig, weitergeleitet werden. Sie werden referenzierte Subprozesse genannt.

Call Activity

Eine Call Activity ist eine Aktivität in einem Prozess, die einen globalen Prozess oder eine globale Aufgabe (global task) aufruft. Wird ein solcher Subprozess aufgerufen, geht die Kontrolle über den Prozess an den aufgerufenen globalen Prozess oder die globale Aufgabe über.

Eine Call Activity wird ebenfalls durch ein Rechteck mit gerundeten Ecken dargestellt, die weitere Gestaltung wird durch das Ziel des Aufrufs bestimmt. Wird eine globale Aufgabe aufgerufen, ist die Randlinie verdickt und die Call Activity enthält die Kennzeichnung der globalen Aufgabe.

Abbildung 6.3-10: Call Activity, die eine globale Aufgabe aufruft.
Quelle: Nach [OMG 2011, S. 194, Abb. 10.39], Übersetzung durch den Verfasser

Wird ein globaler Prozess aufgerufen, gibt es zwei Möglichkeiten: Bei einem verborgenen Prozess ist die Gestaltung der Call Activity wie bei einem eingebetteten Subprozess, die Grenzlinie ist verdickt.

Abbildung 6.3-11: Call Activity, die einen verborgenen globalen Prozess aufruft.
Quelle: Nach [OMG 2011, S. 194, Abb. 10.40], Übersetzung durch den Verfasser.

Werden die Details des aufgerufenen Prozesses dargestellt, ist die Gestaltung der Call Activity wie bei einem entfalteten Subprozess, wiederum mit verdickter Grenzlinie.

Abbildung 6.3-12: Call Activity, die einen entfalteten globalen Prozess aufruft.
Quelle: [OMG 2011, S. 194, Abb. 10.41], Übersetzung durch den Verfasser.

Die verdickte Außenlinie deutet in einem Prozessmodell also an, dass eine wiederverwendbare globale Aktivität (Aufgabe, Subprozess) verwendet wird.

Voraussetzung für den Aufruf ist, dass der aufgerufene Prozess mindestens ein Ereignis hat, das nicht Startereignis ist. Dieses wird benötigt, um den Prozess durch die Call Activity aufzurufen. Alle anderen Typen von Startereignissen kommen nur zum Einsatz, wenn der Prozess zusätzlich auch als Top-Level - Prozess genutzt wird. Dies ist möglich, vgl. für ein Beispiel Abbildung 14.5-1.

Ereignissubprozesse

Ereignissubprozesse (event sub-processes) sind Subprozesse, die durch ein Ereignis gestartet werden können. Ein solcher Subprozess ist nicht Teil des normalen Flusses ims Elternprozess - es gibt also keine ankommenden und ausgehenden Sequenzflüsse. Er kann, während der Elternprozess aktiv ist, aktiv werden oder auch nicht. Möglich ist auch, dass er mehrfach aktiv wird.

Während ein Standardsubprozess den Fluss des Elternprozesses als Auslöser nutzt, hat ein Ereignissubprozess ein Startereignis mit einem Trigger. Solange der Elternprozess aktiv ist, gilt dann: Der Ereignissubprozess startet jedesmal, wenn das Startereignis ausgelöst wird. Er darf nur genau ein Startereignis haben.

Der Auslöser (start-event-trigger) kann von folgenden Typen sein: Nachricht (message), Fehler (error), Eskalation (escalation), Kompensation (compensation), Bedingung (conditional), Signal (signal) und Mehrfach (multiple).

Das grafische Symbol weicht vom Standard dahingehend ab, dass die Grenzline gepunktet sein muss.

Abbildung 6.3-13: Ereignissubprozess, verborgen.
Quelle: Nach [OMG 2011, S. 177, Abb. 10.30]

Ein Beispiel ist ein Ereignissubprozess, der durch ein Eskalationsstartereignis ausgelöst wird. Z.B. wenn ein kritisches Zeitlimit nicht eingehalten wird. Der Ereignissubprozess klärt dann, was in einem solchen Fall zu tun ist.

Dieses Theorieelement ist modellierungstechnisch hilfreich. Wann immer einer der oben angeführten Auslöser auftritt, kann auf grafisch einfache Weise, z.B. durch ein Randereignis, von der Aktivität aus der entsprechende Subprozess aufgerufen werden. Die Alternative wäre, an der entsprechenden Stelle eine Abfrage einzubauen, ob die entsprechende Situation vorliegt, und dann zu verzweigen.

Auch entfaltete Ereignissubprozesse sind vorgesehen. Die folgende Abbildung zeigt die grafische Darstellung.

Abbildung 6.3-14: Ereignissubprozess, entfaltet.
Quelle: In Anlehnung an [OMG 2011, S. 177, Abb. 10.31]

Beispiele:

Abbildung 14.3-1 enthält einen Subprozess mit drei entfalteten Ereignissubprozessen.

Abhängig vom Startereignis kann der Ereignissubprozess den Elternprozess unterbrechen oder auch nicht. In Abbildung 14.3-1 findet sich ein Startereignis, das den Elternprozess nicht unterbricht (Ereignissubprozess Aktualisierung Kreditkarteninformation) und zwei andere, die den Elternprozess unterbrechen (Ereignissubprozesse Durchführung Kompensation und Bearbeitung Buchungsfehler).

Transaktionen

Eine Transaktion ist ein spezialisierter Subprozess, der ein spezifisches, durch ein Transaktionsprotokoll fixiertes Verhalten hat. Er kann in der grafischen Darstellung entfaltet (expanded) oder verborgen (collapsed) sein. Die Grenzlinie eines Transaktionssymbols hat eine Doppellinie.

Abbildung 6.3-15: Grafische Darstellung einerTransaktion

Transaktionen werden ausführlich in Abschnitt 10.9 erläutert.

6.3.4 Zusammenfassung - Arten von Subprozessen

Die folgende Abbildung zeigt die Vielfalt an Subprozessvarianten, die in der BPMN zur Verfügung stehen. Da sind zuerst die mit einer spezifischen inneren Struktur:

• Ad hoc: Ohne die Möglichkeit (oder ohne den Wunsch), den Ablauf festzulegen.
• Kompensation: Dienen als Ersatz für einen Prozessabschnitt, der gescheitert ist.
• Mehrfachinstanzen: Starten mehrere Instanzen, parallel oder sequentiell.
• Schleife: Weisen im Prozessablauf eine Schleife auf.

Dann die Call Activities, die globale Aufgaben oder Subprozesse aufrufen. Gedacht für Aktivitäten, die an verschiedenen und vielen Stellen benötigt werden. Die Transaktionen werden gewählt (eher im technischen Bereich), wenn ein Prozessablauf sehr genau dahingehend kontrolliert werden muss, ob er erfolgreich abgeschlossen wurde. Schließlich noch die Ereignissubprozesse. Sie werden gewählt, wenn der Subprozess nicht direkt in den Sequenzfluss eingebunden ist, sondern durch Ereignisse gestartet werden soll.

Abbildung 6.3-16: Die Subprozesse der Methode BPMN im Überblick

Die Abbildung der nächsten Seite stellt die Subprozesse mit ihrer grafischen Repräsentation und einer Kurzbeschreibung zusammen.

6.3.5 Wofür Subprozesse?

Was sind, ganz allgemein, die Motive für Subprozesse:

(1) Subprozesse eignen sich dazu, oft vorkommende gleiche Prozessabschnitte nur einmal detailliert darzustellen, ansonsten im Prozessmodell darauf zu verweisen. Dies macht Prozessmodelle übersichtlicher. In der BPMN geschieht dies mit Hilfe der verborgenen Subprozesse.

(2) Sie erlauben, Prozessabschnitte mit größerer Detaillierung in das ganz normale Prozessmodell einzubinden. Etwa so, wie hier und noch ausführlicher in [Staud 2014] unter dem Stichwort "Prozess- vs. Funktionsmodellierung" beschrieben. Normalerweise ist das Aggregationsniveau einer Prozessmodellierung im gesamten Prozess auf derselben Ebene. Mit einem Subprozess kann dann neben der Modellierung des eigentlichen Geschäftsprozesses (Leistungserstellung ab Kundenanfrage) auch die Modellierung einzelner Aufgaben (Kalkulation der Angebotspositionen) modelliert werden.

(3) Realisierung der vertikalen Modellierung, bei der ja verschiedene Aggregationsebenen modelliert werden. Dabei kann durch Subprozesse eine Verbindung zwischen zwei (oder mehr) Modellierungsebenen hergestellt werden. Ein Prozessabschnitt der unteren kann mit einer Aufgabe der höheren Ebene (die dadurch zum eingebetteten Subprozess wird) verknüpft werden.

7 Akteure und Nachrichten

Wer tut es?

In jeder Methode zur Prozessmodellierung ist vorgesehen, in den grafischen Darstellungen der Geschäftsprozesse die Träger der einzelnen Tätigkeiten anzugeben, diejenigen, die die Aktivitäten ausführen. Sie werden hier Akteure genannt.

Dies sind, je nach Modellierungsebene, Abteilungen, Stellen oder auch ganze Unternehmen. In der BPMN wird dafür die in Kapitel 5 schon kurz vorgestellte Schwimmbahnentechnik genutzt. Dabei werden alle Aktivitäten eines Akteurs entlang des Geschäftsprozesses in ein Rechteck gepackt. Dies geschieht für jeden, so dass typischerweise mehrere langgezogene übereinanderliegende Rechtecke entstehen, die an Schwimmbahnen in einem Becken erinnern. Entsprechend werden in der BPMN die Rechtecke als Becken (pools) bezeichnet, die noch in Bahnen (lanes) unterteilt werden können.

7.1 Becken, Bahnen, Nachrichten

Becken

Hier nun die Festlegungen der BPMN-Autoren für ihre Schwimmbahnentechnik:

• Jedes Becken (pool) repräsentiert einen Teilnehmer am Prozess (so die Sichtweise), bzw. jeder Teilnehmer am Geschäftsprozess bekommt in der grafischen Darstellung ein Becken.
• Ein Becken geht über die gesamte Länge des Geschäftsprozesses.
• Ein Becken unterteilt sich in Bahnen (lanes).

Die graphische Darstellung erfolgt als Rechteck, mit abgetrennter Kennzeichnung an der linken Seite. Vgl. die Abbildung unten sowie die Beispiele im einführenden Kapitel 5 und in Kapitel 14. Die grafischen Darstellungen der Geschäftsprozesse werden von den BPMN-Autoren immer waagrecht angeordnet, so dass diese Becken in den meisten Abbildungen auch waagrecht anzufinden sind.

Abbildung 7.1-1: Grafische Darstellung eines Beckens

Die Schwimmbahnentechnik geht immer (allerdings meist unausgesprochen) davon aus, dass es wenige Träger von Tätigkeiten gibt und dass diese nicht ständig wechseln. Denn nur dann sind Schwimmbahnen sinnvoll einsetzbar. Falls viele verschiedene Träger vorliegen, die in unterschiedlicher Zusammensetzung den Gesamtprozess abwickeln, ist die Schwimmbahntechnik nicht sehr geeignet.

Bahnen

Falls bei einem Akteur eine für den Geschäftsprozess wichtige Untergliederung vorliegt (z.B. in Abteilungen) kann ein Becken noch weiter unterteilt werden in Bahnen (lanes). Solche Bahnen gehen über die gesamte Länge des Beckens.

Im Zusammenhang mit Bahnen ist folgende Festlegung bzgl. des Sequenzflusses in Business Program Diagrams wichtig:

Der Sequenzfluss eines Geschäftsprozesses kann die Grenze von Bahnen überwinden, nicht aber die von Becken. Hat man ein Zusammenspiel mehrerer Partizipanten aus verschiedenen Becken(z.B. das eigene Unternehmen einerseits und "den Kunden" andererseits) muss dieses durch Nachrichtenverkehr gelöst werden.

Nachrichten

Damit hat der Nachrichtenfluss hier, in der Methode BPMN, eine größere Bedeutung als in anderen Methoden zur Prozessmodellierung.

Das Symbol zur Darstellung einer Nachricht ist ein Kuvert, wie es die folgende Abbildung zeigt. Dieses Symbol kommt in sehr vielen Modellelementen (Ereignissen, Aufgaben, Gateways, …) vor. Es stellt den Inhalt einer Kommunikation zwischen zwei Prozessteilnehmern dar. Oftmals ist es noch mit einem Text beschriftet, der den Inhalt der Nachricht spezifiziert.

Bei Ereignissen wird das Symbol für den Ereignistyp Nachricht verwendet (vgl. Abschnitt 9.2.2), bei Aufgaben für die Aufgabentypen Empfänger, Sender (schwarz eingefärbt) und Prozessstart (vgl. Abschnitt 6.2.2), bei Gateways im Fall Exclusive Gateway / ereignisbasiert im Rahmen von Zwischenereignissen. Falls es im jeweiligen Umfeld Sinn macht, wird durch Einfärbung des Symbols zwischen dem Empfangen und dem Senden von Nachrichten unterschieden: Weiß für empfangend, schwarz für sendend.

Abbildung 7.1-2: Kuvert als Symbol für eine Nachricht

Dieses Nachrichtensymbol wird allerdings nicht bei jeder Nachricht angegeben. Will man nur den Nachrichtenverkehr in der Abbildung ausdrücken ohne Betonung der Nachricht, wählt man das Pfeilsymbol der nächsten Abbildung. Dieses drückt aus, dass ein Nachrichtenverkehr nötig ist für das Zusammenspiel von Akteuren aus verschiedenen Becken.

Abbildung 7.1-3: Pfeil als Symbol für einen Nachrichtenfluss

Geschäftsprozess Bonitätsprüfung

Die folgende Abbildung zeigt ein hoch aggregiertes Beispiel mit Becken, Bahnen und mit Nachrichtenverkehr. Das Unternehmen hat einen Auftrag erhalten und möchte nun prüfen, ob dieser ausgeführt werden kann. Dazu wird die Bonität des potentiellen Kunden geprüft und eine entsprechende Anfrage an eine Auskunftei geschickt. Diese ist in der Abbildung als Nachricht modelliert. In der Auskunftei erfolgt die Prüfung. Sind die Daten erhoben, wird ein Bericht erstellt und dem Unternehmen mitgeteilt ("Ergebnis mitteilen"; Aufgabe Sender). Im auftraggebenden Unternehmen wird das Ergebnis empfangen und ausgewertet ("Ergebnis auswerten"; Aufgabe Empfänger). Dies führt dazu, dass der Auftrag entweder abgelehnt oder ausgeführt wird.

Abbildung 7.1-4: Nachrichtenverkehr zwischen Aktivitäten verschiedener Becken am Beispiel eines Geschäftsprozesses Bonitätsprüfung

Enthaltene Elemente:

- Aufgaben

- Bahnen

- Becken

- Empfänger-Aufgabe

- Exclusive Gateway, datenbasiert

- Nachrichtenfluss

- Schlussereignis

- Sender-Aufgabe

- Startereignis

- Subprozess, verborgen

Es ist in der BPMN auch möglich, den Nachrichtenfluss nur an den Rand des "empfangenden" Beckens zu führen oder von dort zu starten. Bei einem solchen Vorgehen modelliert man bewusst unscharf, man drückt lediglich aus, dass eine Nachricht an den anderen Akteur geht und präzisiert nicht die konkrete Aktivität, in der die Nachricht benötigt wird.

Abbildung 7.1-5: Nachrichtenverkehr vom und zum Beckenrand

Jede einzelne Aktivität benötigt also einen Akteur (Träger der Aktivität), der sie durchführt. Dies können bestimmte Unternehmenseinheiten (Abteilung, Hauptabteilung, Stelle) wie Finanzwesen, Beschaffung, Vertrieb, usw. sein, aber auch abstrakte Rollen wie Käufer, Verkäufer oder Hersteller. Bei der Erläuterung von Bahnen zielen die BPMN-Autoren dagegen auf kleinere Einheiten. Hier, so führen sie aus, spielen "internal roles" (Manager, Associate), Systeme (z.B. Anwendungsprogramme) und auch interne Abteilungen (z.B. Vertrieb, Finanzwesen, usw.) eine Rolle.

Akteure und damit auch Bahnen können verschachtelt sein. Zum Beispiel können übergeordnete Bahnen für die Abteilungen eingerichtet werden und innere Bahnen für die Rollen (Stellen) in jeder Abteilung. Oben (auch im einführenden Beispiel) war solch eine Struktur bereits vorhanden.

Die folgende Abbildung zeigt ein weiteres Beispiel für die Verschachtelung von Akteuren. Es soll um die Entwicklung von Individualsoftware gehen, um deren Verkauf an Kunden, eventuelle Fehlermeldungen von Kunden und die Reaktionen darauf, alles sehr abgehoben.

Der Kunde ist als eigenes Becken angelegt, ohne Ausdifferenzierung seiner Geschäftsprozesse, weshalb die Nachrichten am Beckenrand enden. Der Lieferant ist durch ein Becken repräsentiert, das auf der ersten Ebene in die Bahnen Entwicklung, Kundendienst, Marketing und Verkauf unterteilt ist. Alles Abteilungen also. Die Abteilung Marketing ist dann noch unterteilt in Nach Verkauf und Vor Verkauf, was wiederum durch Bahnen ausgedrückt wird.

Entsprechend den obigen Ausführungen haben die BPMN-Autoren die Kontakte zwischen Lieferant und Kunde (zwischen zwei verschiedenen Becken also) als Nachrichtenfluss dargestellt.

Nach dem Start des Prozesses sammelt die Abteilung Marketing (Vor Verkauf) die Anforderungen der Kunden. Danach wird in der Abteilung Entwicklung das Produkt entwickelt. Der Verkauf liefert das Produkt an den Kunden aus. Dies wurde hier als Nachricht modelliert (!).

Nach dem Verkauf werden im Unternehmen zwei Aktivitäten angestoßen: die Prüfung der Anforderungen und - aber nur, falls eine Fehlerliste eintrifft - eine Beratung bzgl. dieser vom Kunden genannten Fehler (zu diesem Gateway vgl. Abschnitt 11.4). Hier sind nun Nachrichtenflüsse im Spiel:

• Vom Kunden zum Kundendienst. Dies allerdings nur, falls Fehler aufgetreten sind; aus denen eine Fehlerliste erstellt wurde. Die Fehlerliste (festgestellte Fehler der ausgelieferten Software) wird als Nachricht (Zwischenereignis / empfangend / normaler Fluss, vgl. Abschnitt 9.2.2) modelliert.

Falls eine solche eintrifft kommt es zur Beratung (durch die Abteilung Kundendienst), zur Fehlerdiagnose und dann in der Entwicklung zur Erstellung eines Patch, der dann dem Kunden geschickt wird (wieder als Nachricht modelliert).

• Von "Anforderungen prüfen" in der Abteilung Marketing (Nach Verkauf) zum Kunden. Diese zwei Nachrichtenflüsse beschreiben den Kontakt zum Kunden zur Klärung, ob die zu Beginn formulierten Anforderungen erfüllt sind.

Die Nachrichtenflüsse modellieren hier also:

• Lieferung von Software (auch eines Patch)
• Übersenden einer Fehlerliste
• abstimmende Kommunikation bzgl. der Übereinstimmung von Anforderungen

Abbildung 7.1-6: Verschachtelte Bahnen
Quelle: In Ahnlehnung an [OMG 2009, S. 307, Figure 10.125]

Enthaltene Elemente:

- Bahnen

- Becken

- Nachrichtenflüsse

- Nachrichtenverkehr zum Beckenrand

- Nachrichten-Zwischenereignis / empfangend

- Parallel Gateway, verzweigend

- Schlussereignis

- Startereignis

7.2 Zusammenarbeit

Es kommt in Geschäftsprozessen oft vor, dass bei einer Aufgabe mehrere Akteure zusammenarbeiten. In der BPMN bedeutet dies, wegen der Schwimmbahnentechnik, dass "Zusammenarbeit" zwischen Bahnen und Becken ausgedrückt werden muss. Dies geschieht, indem die beteiligten Aktivitäten durch ein Rechteck mit spezieller Liniengestaltung umgeben werden. Das Rechteck kann auch beschriftet werden. Diese Theorieelement wird Gruppe (group) genannt.Vgl. die folgende Abbildung und das Beispiel in Abbildung 14.6-6.

Es wird auch ganz allgemein für Aktvitäten verwendet, die "zusammengehören" ("that are within the same Category"), mit denen eine bestimmte Aufgabe gelöst wird. Im folgenden Beispiel ist damit ausgedrückt, dass die Klärung und Erfüllung der Medikamentenwünsche des Patienten in Zusammenarbeit von Patient und Arztpraxis erfolgen.

Abbildung 7.2-1: Element Gruppe (group) zur Modellierung von Zusammenarbeit und Zusammengehörigkeit. Beispiel Kontakt zwischen Arztpraxis und Patient - Version 3
Quelle: Übersetzt und leicht verändert nach [OMG 2011, S. 69]

Entaltene Elemente (u.a.):

- Gruppe (group)

- Nachrichten zwischen Aufgaben

Insgesamt werden Varianten dieses Geschäftsprozesses in den Abbildungen 5.4-1, 5.5-1, 5.6-1, 7.2-1, 7.2-2 und 13.1-1 betrachtet.

Eine gekürzte (sozusagen höher aggregierte) Variante hiervon mit den Aufgabentypen Empfänger und Sender zeigt die folgende Abbildung. Hier sind die Aufgaben zusätzlich als Empfänger oder Sender gekennzeichnet.

Abbildung 7.2-2: Element Gruppe (group) zur Modellierung von Zusammenarbeit und Zusammengehörigkeit
Beispiel Kontakt zwischen Arztpraxis und Patient - Version 4
Quelle: Übersetzt und leicht verändert nach [OMG 2011, S. 69, Figure 8.14]
Übersetzung durch den Verfasser.

Entaltene Elemente (u.a.):

- Empfänger-Aufgaben

- Gruppe (group)

- Sender-Aufgaben

Insgesamt werden Varianten dieses Geschäftsprozesses in den Abbildungen 5.4-1, 5.5-1, 5.6-1, 7.2-1, 7.2-2 und 13.1-1 betrachtet.

Vor- und Nachteile

Es gibt andere Möglichkeiten zur Darstellung der Akteure von Prozessen. Vgl. für die Varianten UML und Ereignisgesteuerte Prozessketten [Staud 2010, Abschnitt 10.8] bzw. [Staud 2014]. Der große Vorteil der Schwimmbahnentechnik ist, dass klar erkennbar ist, an welchen Stellen im Geschäftsprozess ein bestimmter Akteur mitwirkt.

Ein Nachteil ist, dass die Darstellung unübersichtlich wird, wenn zahlreiche und öfters wechselnde Akteure am Prozess beteiligt sind. Fügt man tatsächlich alle Bahnen über den gesamten Prozess in das Prozessmodell ein, gibt es zahlreiche Abschnitte, in denen bestimmte Bahnen leer sind. Schlecht darstellbar ist auch die Zusammenarbeit ("Gruppe") von Akteuren. Man stelle sich nur vor, dass die Zusammensetzung komplexer wäre als in den obigen Beispielen.

8 Informationen und ihre Verarbeitung

8.1 Daten und Informationen

In jedem Geschäftsprozess werden Informationen [Anmerkung] benötigt, erzeugt, verarbeitet und evtl. gelöscht, weshalb sie auch in der Methode BPMNthematisiert sein müssen. Die BPMN-Autoren bezeichnen die im Geschäftsprozess eine Rolle spielenden Informationen als Datenobjekte (data objects)). Sie sehen sie wie folgt:

• Datenobjekte liefern Informationen darüber, was der Prozess leistet, wie Dokumente, Daten und andere Objekte im Prozess genutzt und aktualisiert werden.
• Sie liefern Informationen darüber, was Aktivitäten für ihre Umsetzung benötigen und/oder was sie erzeugen.
• Sie haben keinen direkten Einfluss auf den Kontroll- oder Nachrichtenfluss [OMG 2009, Seite 19].

Datenobjekte werden in Business Process Diagramms durch vier Elemente repräsentiert [OMG 2011, S. 27]:

• Datenobjekt (data object)
• Dateninput (data input)
• Datenoutput (data output)
• Datenspeicher (data store)

Abbildung 8.1-1: Darstellung des Modellelements Datenobjekt

Mit diesem Methodenelement Datenobjekt werden also Informationen beschrieben, die von Aktivitäten benötigt oder erzeugt werden. Dateninputund Datenoutputleisten dasselbe für Prozesse.

Bei Datenobjekten kann auch angegeben werden, in welchem Zustand sie sich befinden: geprüft, abgelehnt, usw. Dies erfolgt in eckigen Klammern unterhalb des grafischen Symbols. Vgl. dazu die Beispiel unten und in Kapitel 14.

Datenspeicher

Der Datenspeicher (data store) wird für Informationen gewählt, die über eine Instanz hinaus erhalten bleiben sollen. Mit ihm können also Datenbanken und Dateien aller Art dargestellt werden.

Abbildung 8.1-2: Darstellung des Modellelements Datenspeicher (data store)

8.2 Assoziationen

Ganz allgemein wird die Verknüpfung von Text und Nicht-Fluss-Elementen mit Flussobjekten Assoziation genannt. Dies gilt dann auch für die Verknüpfung von Datenobjekten mit Flussobjekten. Solche Assoziationen werden als gepunktete Linie dargestellt, gerichtet oder ungerichtet, d.h. mit oder ohne offener Pfeilspitze. Vgl. die Beispiele unten und in Kapitel 14.

Die Verknüpfung ist notwendig, weil üblicherweise mit Daten Handlungen verbunden sind. Sie entstehen, werden bearbeitet oder auch gelöscht im Rahmen von Aktivitäten. Deshalb müssen Datenobjekte mit der jeweiligen Handlung durch Assoziationen in Verbindung gebracht werden. Zur grafischen Darstellung vgl. die folgende Abbildung.

Definition Assoziation

Eine Assoziation ist eine Verknüpfung zwischen einem Flussobjekt und einem Datenobjekt.

Die konkrete Ausgestaltung der Einbindung von Datenobjekten in Prozessmodelle wird im nächsten Abschnitt beschrieben.

Abbildung 8.2-1: Darstellung einer gerichteten Assoziation

Assoziationen für Artefakte

Assoziationen werden auch benutzt, um Artefakte mit dem Geschäftsprozess zu verknüpfen, z.B. textliche Anmerkungen (text annotations). Sie bestehen aus einer ungerichteten Assoziation und der textlichen Anmerkung, in der grafischen Form wie unten gezeigt. Es gibt tatsächlich immer wieder einen Bedarf an textlichen Ergänzungen in einem Prozessmodell. Dabei kann es sich um inhaltliche Ergänzungen handeln oder um Prozesselemente, die mit der Methode nicht abbildbar sind, z.B. spezifische organisationelle Zuweisungen (wie in der folgenden Abbildung).

Abbildung 8.2-2: Artefakt Textliche Anmerkung

8.3 Daten im Geschäftsprozess

In jedem Geschäftsprozess werden Daten bzw. Informationen transportiert. Dies kann direkt oder indirekt modelliert werden. Direkt, indem der Informationstransport ausdrücklich modelliert wird. Dann gibt es z.B. ein Modellelement, das mit "CAD-Unterlagen ins Archiv transportieren" beschriftet ist. Indirekt ganz einfach so, dass die Information bei der nächsten Aktivität, bei der sie benötigt wird, wieder erscheint.

Damit kann auch die typische Vorgehensweise bei moderner Software (insbesondere ERP-Software) modelliert werden: Schreiben in die zentrale Datenbank, später lesen aus dieser und nach Bearbeitung wieder speichern.

Hier soll es im Weiteren um den direkten Transport gehen. Folgendes ist in der BPMN dabei möglich:

• Datentransport entlang eines Sequenzflusses.
• Einfacher Datentransport, der sogar ohne Sequenzfluss vorhanden sein kann (d.h., dass er den Zusammenhalt des Prozesses modelliert).
• Entstehende Information, d.h., in einer Aufgabe entsteht ein Datenobjekt.
• Einfließende Information, d.h. das Datenobjekt wird in der Aufgabe benötigt.

Die folgende Abbildung zeigt ein Beispiel einer ungerichteten Assoziation, die ein Datenobjekt mit einer Sequenzflusskante verbindet.

Abbildung 8.3-1: Assoziation von Datenobjekt mit Sequenzflusskante

Mit dem Datentransport mittels Assoziation soll der einfache Datentransport modelliert werden. Die Situation ist wie folgt: Informationen entstehen in einer Aktivität und werden zur nächsten geschickt und dort verarbeitet. In der grafischen Darstellung wird dafür eine gerichtete Assoziation verwendet, wie es die folgende Abbildung zeigt.

Die Bedeutung ist wie folgt:

• In der sendenden Aktivität entsteht das Datenobjekt.
• In der empfangenden Aufgabe fließt das Datenobjekt in die Arbeit ein, es wird dort benötigt.

Wie das Beispiel zeigt, können auch mehrere Empfänger vorliegen. Diese Art der grafischen Gestaltung drückt also nicht nur die Erzeugung und den Transport aus, sondern auch die Nutzung in der Zielaktivität.

Abbildung 8.3-2: Datentransport mittels Assoziation
Quelle: 2 Fragmente aus Abbildung 8.3-6

Es ist auch möglich, den Datentransport parallel zum Sequenzfluss zu modellieren. Hier wird dann, siehe auch das Beispiel in obiger Abbildung, explizit ausgedrückt, dass die eine Aktivität vor der anderen stattzufinden hat.

Die Erzeugung eines Datenobjekts oder die Bearbeitung (ohne Transportabsicht) kann auch so grafisch ausgedrückt werden, wie es die folgende Abbildung zeigt. Von der Aktivität liegt dann eine gerichtete Assoziation zum Datenobjekt vor.

Abbildung 8.3-3: Datentransport mittels Assoziation
Quelle: Fragment aus Abbildung 8.3-6

Die BPMN-Autoren sehen auch vor, dass ein Geschäftsprozess durch ein Datenobjekt gestartet wird. In diesem Fall wird eine Assoziation vom Datenobjekt zur Aktivität geführt. Dabei können auch mehrere Aktivitäten angestoßen werden, es kann also ein impliziter UND-Operator vorliegen.

Abbildung 8.3-4: Start eines Geschäftsprozesses durch ein Datenobjekt
Quelle: Fragment aus Abbildung 8.3-6

In der konkreten Praxis der BPMN-Modellierung wird auf die Modellierung des Datentransports oft verzichtet. Das Datenobjekt taucht dann einfach an einer nachfolgenden flussabwärts gelegenen Aktivität wieder auf, meist mit einem veränderten Zustand.

Abbildung 8.3-5: Datentransport ohne expliziten Transport

Hier nun das Beispiel als Ganzes. Es zeigt eine Mischung aus Informations- und Sequenzflüssen, mit deutlichem Übergewicht der Ersteren. Vgl. für eine Beschreibung der Modellelemente den Kasten nach der Abbildung.

Abbildung 8.3-6: Entfalteter Ad hoc - Subprozess Buchkapitel schreiben mit Daten- und Sequenzflüssen.
Quelle: [OMG 2011, S. 183, Figure 10.38]. Übersetzung durch den Verfasser.

Prozessfragment:

- Entfalteter Ad hoc - Subprozess mit Mehrfachinstanz (parallel). Die Modellvorstellung ist also, dass an mehreren Kapiteln gleichzeitig gearbeitet wird.

Enthaltene Elemente:

- Ad Hoc-Markierung

- Ad Hoc-Subprozess

- Aggregation

- Assoziation

- Assoziation, gerichtet

- Schleifen-Aufgabe

- Aufgaben

- Datenobjekt (Erzeugung)

- Datenobjekt (lesend))

- Datenobjekt (verändernd)

- Datenobjekt am Sequenzfluss

- Mehrfachinstanz-Aufgabe, parallel

- Mehrfachinstanz-Markierung

Das Beispiel macht nochmals deutlich, dass der Fluss von Datenobjekten auch parallel zum Sequenzfluss erfolgen kann. Außerdem zeigt er, dass Ad Hoc - Prozesse durch die Angabe von Datenflüssen präzisiert werden können.

9 Ereignisse

9.1 Einführung

9.1.1 Konzept

In der BPMN spielen Ereignisse eine wichtige Rolle. Definiert sind sie wie folgt:

Definition Ereignis

"Ein Ereignis ist etwas, was während des Ablaufs eines Geschäftsprozesses geschieht. Ereignisse beeinflussen den Prozessablauf und haben typischerweise eine Ursache oder eine Wirkung. ... Allerdings wird die Nutzung von Ereignissen eingeschränkt auf solche, die die Abfolge oder zeitliche Aspekte von Aktivitäten betreffen" [OMG 2011, S. 83], Übersetzung durch den Verfasser.

Die Definition greift auf den allgemeinen Eigenschaftsbegriff zurück, was nachvollziehbar ist. Die Einschränkung auf Ereignisse, die den Prozessfluss betreffen, ist sinnvoll.

Es ist wie im "wirklichen Leben". Manche Ereignisse erzeugen wir ("Ich habe gekündigt"), manche wirken von außen auf uns ein ("Man hat mir gekündigt"). Dementsprechend werden in der BPMN Ereignisse auf zweierlei Weise betrachtet:

• Erstens als Ereignisse, die im Geschäftsprozess erzeugt werden und dann dort oder nach außen Wirkung erzielen ("
• Zweitens als Ereignisse, die von außen auf den Geschäftsprozess einwirken.

Modelliert werden die Stellen im Geschäftsprozess, die solche Ereignisse empfangen (catch) oder abgeben (throw) können. Dazu unten mehr. Ein in das Prozessmodell eingefügtes diesbezügliches Methodenelement kann nur das eine oder das andere darstellen. Wir müssen also das eigentliche Ereignis ("Lagerbestand unter Nachbestellmarke gesunken", "Kalkulation ist fertig") von dem Methodenelement Ereignis trennen. Bei der Modellierung müssen wir dann entscheiden, ob das Methodenelement Ereignisse von der Prozessumwelt empfangen oder an sie abgeben soll.

Es geht somit um den Wirkungsbereich der Ereignisse. Dieser soll hier Ereignisraum genannt werden. Dazu haben die BPMN-Autoren festgelegt:

• Der Empfang von Ereignissen ist aus dem Anwendungsbereich, in dem der Prozess stattfindet, möglich.
• Das Abgeben von Ereignissen ist möglich in denselben Prozess oder Subprozess, bei Subprozessen auch in die übergeordneten Prozesse, die BPMN-Autoren sprechen diesbezüglich von Elternprozessen. Darauf wird unten bei den einzelnen Ereignisstypen eingegangen.

Man merkt den Ausführungen der BPMN-Autoren an, dass dieser Teil der Methode große Bedeutung hat. In einer Standardprozessmodellierung wäre dies in diesem Umfang nicht nötig, geht es aber um die Umsetzung des Prozessmodells in ausführbare Software, ist dies unabdingbar.

Folgende abstrakten Beispiele für Ereignisse führen die BPMN-Autoren an [OMG 2011, S. 83]:

• Start einer Aktivität
• Ende einer Aktivität
• Veränderung eines Dokuments
• Eintreffende Nachricht

Obiges entspricht dem Standard bei der Definition von Ereignissen. Weiter geht dagegen die folgende Unterscheidung dreier Ereignistypen, die danach erfolgt, in welchem Prozessabschnitt die Ereignisse auftreten:

• Startereignisse (start events)
• Zwischenereignisse (intermediate events)
• Schlussereignisse (end events)

Start- und Zwischenereignisse haben Auslöser (trigger). Schlussereignisse können Ergebnisse haben, die sich aus dem Geschäftsprozess ergeben.

Grafische Darstellung

Die grundsätzliche grafische Darstellung ist die eines leeren Kreises, in den man Kennzeichnungen (marker) des konkreten Ereignisses platzieren kann. Dazu gleich unten mehr.

Abbildung 9.1-1: Darstellung eines Ereignisses - allgemeine Form

9.1.2 Ausdifferenzierung

Die Ereignisse werden von den BPMN-Autoren auf vielfältige Weise unterschieden und alle diese Unterscheidungen werden auch in der grafischen Darstellung ausgedrückt. Der Ausgangspunkt der Differenzierung ist die oben schon eingeführte Unterscheidung von Start-, Zwischen- und Schlussereignissen. Ihre grafische Gestaltung erfolgt mit schwarzen Linien und ist ansonsten wie folgt:

• Startereignisse werden mit einer einzelnen dünnen Linie gezeichnet
• Zwischenereignisse erhalten zwei dünne Linien
• Schlussereignisse werden mit einer dicken Linie gezeichnet

Dann wird danach unterschieden, ob der Auslöser des Ereignisses empfangend (catching) oder abgebend (throwing) ist. Zusammen mit der Festlegung, dass Startereignisse nur empfangende Auslöser, Schlussereignisse nur abgebende Auslöser und Zwischenereignisse beide haben, ergibt sich die Kopfzeile der folgenden Abbildung. Als Beispiel für einen Ereignistyp wurde Nachricht (Message) gewählt (vgl. Abschnitt 9.2.2).

Empfangend (catching) und Abgebend (throwing)

Empfangend (catching) bedeutet, dass es …

• … im realen Geschäftsprozess ein Prozesselement gibt, das Ereignisse wahrnehmen kann.
• … im Prozessmodell ein Prozesselement gibt, das dies ausdrückt.

Das Wahrnehmen bezieht sich auf einen bestimmten Kontext des Prozessmodells. Dieser Ereignisraumist durch den Geschäftsprozess, durch Subprozesse oder andere Einteilungen gegeben.

Methodentechnisch wird die Fähigkeit, einen Trigger (der das Ereignis kommuniziert) zu empfangen, durch die sog. EventDefinition realisiert. Nur mit dieser kann der Trigger empfangen (das Ereignis wahrgenommen) werden. Sind an einer Stelle mehrere empfangende Ereignisse vorhanden, muss es auch mehrere EventDefinitions geben.

Abgebend (throwing) bedeutet, dass es …

• … im realen Geschäftsprozess ein Prozesselement gibt, das Ereignisse erzeugt und dem Ereignisraum bekannt macht.
• … im Prozessmodell ein Prozesselement gibt, das dies ausdrückt.

[OMG 2011, S. 275].

Wie dies im realen Prozess umgesetzt wird (bzw. wie es dort vorliegt) hängt von den Umständen ab. Ist der Prozess bereits in Software umgesetzt, muss für das Empfangen und Senden von Ereignissen eine softwaretechnische Lösung realisiert werden. Wird der Prozess an der jeweiligen Stelle von Menschen realisiert, müssen dazu passende Strukturen eingerichtet sein, z.B. Kommunikationssysteme.

Für die grafische Gestaltung gilt: Bei Ereignissen, die empfangen, sind die Kennzeichen nicht eingefärbt. Bei Ereignissen, die abgeben, sind sie schwarz eingefärbt.

Das dritte Kriterium erfasst Sondersituationen für Subprozesse oder Aufgaben, die durch Ereignisse ausgelöst werden. Diese Ereignisse starten entweder einen Ereignissubprozess (event sub process) oder sie stoßen von einer Aufgabe aus andere Aufgaben an. Grafisch sind sie dann auf der Grenzline der auslösenden Aufgabe angesiedelt.

Diese Ereignisse im Subprozess oder bei einer Aufgabe unterbrechen entweder den übergeordneten Prozess (von dem der Aufruf kam) bzw. die übergeordnete Aufgabe oder nicht. Dies kann auch grafisch ausgedrückt werden. Eine gestrichelte Randline bedeutet nicht unterbrechend, eine durchgezogene unterbrechend.

Es gibt sie als Start- und als Zwischenereignisse. Bei den Startereignissen sind dies "Ereignissubprozess, unterbrechend" und "Ereignissubprozess, nicht unterbrechend". Bei den Zwischenereignissen die Varianten "Grenzlinie, unterbrechend" und "Grenzlinie, nicht unterbrechend". Insgesamt also:

• Startereignis / Ereignissubprozess, unterbrechend (event sub-process, interrup­ting)
• Startereignis / Ereignissubprozess, nicht unterbrechend (event sub-process, none interrupting)
• Zwischenereignis / Grenzlinie, unterbrechend(boundary, interrupting)
• Zwischenereignis / Grenzlinie, nicht unterbrechend(boundary, non interrupting)

Die Sperrigkeit der Bezeichnung rührt von der Komplexität des Gegenstandes. Damit ergibt sich, wiederum am Beispiel Nachrichten (message), die folgende endgültige Fassung der Kopfzeile der nachfolgenden Tabelle.

Die vierte Ausdifferenzierung erfolgt nach den Auslösern der Ereignisse. Hier gibt es insgesamt die folgenden (die Nummern beziehen sich auf die Abbildung unten):

1. Kein bestimmter Auslöser (none).

2. Nachricht (message) mit einer MessageEventDefinition: Dies bedeutet, dass von einem Teilnehmer am Prozess eine Nachricht erwartet oder versendet wird. Grafisches Symbol: Briefumschlag.

3. Fehler (error) mit einer ErrorEventDefinition: Dieses Symbol gibt an, dass eine benannte Fehlermeldung erzeugt wird. Grafisches Symbol: Blitz.

4. Zeitgeber (timer) mit einer TimerEventDefinition: Mit diesem Kennzeichen kann zum Ausdruck gebracht werden, dass das Ereignis Zeitaspekte erfasst. Grafisches Symbol: Uhr.

5. Eskalation (escalation) mit einer EscalationEventDefinition: Damit wird beschrieben, dass sich eine Prozesssituation zugespitzt hat und besondere Maßnahmen zu ergreifen sind. Grafisches Symbol: nach oben gerichtete Pfeilspitze.

6. Signal mit einer SignalEventDefinition: Gibt an, dass Signale gesendet oder empfangen werden. Grafisches Symbol: Dreieck.

7. Abbruch (cancel) mit einer CancelEventDefinition: Durch diese Kennzeichnung entsteht ein Ereignistyp, der den Geschäftsprozess bzw. den jeweiligen Fluss abbricht. Grafisches Symbol: schräg gestelltes Kreuz.

8. Kompensation (compensation) mit einer CompensationEventDefinition: Erhält ein Ereignis das Kennzeichen Kompensation (compensation) und wird dieses Ereignis an die Grenzlinie einer Aktivität angefügt, muss es auch einen Sequenzflusspfeil zu einer anderen Aktivität geben. Diese andere Aktivität ist dann im Krisenfall Ersatz für die Ausgangsaktivität (die mit dem Kompensations-Ereignis). Grafisches Symbol: "Rücklauftaste", wie früher bei Kassettenrekordern.

9. Bedingung (conditional) mit einer ConditionalEventDefinition: Für Ereignisse, die durch Bedingungen beschrieben werden können, z.B. "Lagerbestand ist unter die Nachbestellmarke gefallen". Grafisches Symbol: beschriebenes Blatt Papier.

10. Verknüpfung (link) mit einer LinkEventDefinition: Ein Ereignis mit dem Kennzeichen Verknüpfung (link) zeigt an, dass zwei Abschnitte eines Prozesses verknüpft werden. Grafisches Symbol: nach rechts gerichteter Pfeil.

11. Beenden (terminate) mit einer TerminateEventDefinition: Ein Ereignis mit diesem Kennzeichen signalisiert die Beendigung des Prozesses. Grafisches Symbol: gefüllter Kreis.

12. Mehrfach (multiple) mit einer multiple EventDefintion:Dies bedeutet, dass dem Ereignis mehrere Auslöser zugewiesen sind. Grafisches Symbol: Fünfeck.

13. Parallel mehrfach (parallel multiple). Wie "Mehrfach", nur dass alle Auslöser aktiv werden müssen. Grafisches Symbol: waagrecht stehendes Kreuz.

Für jeden Auslöser außer der Fehlanzeige ("Keiner") gibt es in der grafischen Darstellung das oben erwähnte Kennzeichen (marker). Dieses wird im Ereignissymbol platziert. Alle Kennzeichen sind grafisch so gestaltet, dass eine nicht geschwärzte und eine schwarz eingefärbte Fassung möglich ist (siehe Kriterium 2 oben).

In der folgenden Abbildung sind alle Ereignistypen mit ihren grafischen Darstellungen zusammengestellt. Eine ausführliche Beschreibung der Auslöser, auch in Zusammenhang mit den Ereignistypen und der Art des Auslösers, folgt in Abschnitt 9.2.

Abbildung 9.1-2: Alle Ereignistypen mit ihren Kennzeichen
Quelle: Nach [OMG 2011, Kapitel 10.4]
Übersetzung durch den Verfasser

In der Abbildung ist auch zu erkennen, dass nicht alle Marker in allen Ereignistypen vorkommen. Dazu unten mehr.

9.1.3 Startereignisse - allgemein

Vgl. zu den möglichen Situationen für Startereignisse und deren Kennzeichen Abbildung 9.1-2. Die graphische Darstellung erfolgt mit einer einfachen Linie, unterbrochen oder nicht.

Ein Startereignis startet den Geschäftsprozess. Es kann auch mehrere geben, dazu unten mehr. Folgende Eigenschaften und Regeln legen die BPMN-Autoren für Startereignisse im Allgemeinen fest:

• Ein Startereignis hat keinen ankommenden Sequenzfluss, nur einen oder mehrere abgehende.
• Nicht auf jeder Modellierungsebene muss ein Startereignis vorhanden sein, z.B. nicht bei einem Top-Level - Prozess und nicht bei einem entfalteten Subprozess. Deshalb können die BPMN-Autoren schreiben, dass Startereignisse optional sind.
• Wenn das Prozessmodell mehrere Ebenen hat, sind die Startereignisse der Ebenen unabhängig voneinander.
• Falls ein Prozess komplex ist oder falls die Startbedingungen nicht offensichtlich sind, empfehlen die BPMN-Autoren, ein Startereignis zu nutzen.
• Falls ein Schlussereignis vorliegt, muss mindestens ein Startereignis vorliegen.
• Falls ein Startereignis genutzt wird, müssen alle anderen Flusselemente (mindestens) einen ankommenden Sequenzfluss haben. Ausnahmen hierzu sind die sog. Kompensationsaktivitäten (vgl. Abschnitt 6.2). Eine weitere Ausnahme sind Zwischenereignisse, die mit einer Aktivität verknüpft sind. Sie haben keinen ankommenden Sequenzfluss.

Implizite Startereignisse

Falls kein Startereignis vorliegt, werden beim Start des Prozesses alle Flussobjekte ohne ankommenden Sequenzfluss gestartet. Dabei wird angenommen, dass es nur ein einziges implizites Startereignis gibt, was bedeutet, dass alle startenden Flussobjekte zur selben Zeit starten. Eine Ausnahme sind wiederum die Kompensationsaktivitäten. Sie werden nicht beim Start eines solchen Prozesses automatisch auch gestartet, sondern nur, falls die von Ihnen erfasste Situation eintritt.

Außerdem ist festgelegt, dass das implizite Startereignis keinen Trigger haben sollte und dass alle Flussobjekte, die keinen ankommenden Sequenzfluss haben, Startpunkt für jeweils einen parallelen Pfad sind.

Token

Tritt ein Startereignis ein, wird ein neuer Prozess instanziiert und für jeden Sequenzfluss, der von diesem Startereignis herkommt, wird ein neuer Token erzeugt.

Mehrere Startereignisse

Die BPMN-Autoren sehen vor, dass ein Geschäftsprozess auch mehrere Startereignisse haben kann. Dabei wird für jeden weiteren Fluss ein neuer paralleler Pfad geschaffen. Zwei Fälle sind zu unterscheiden:

• Falls mehrere Ereignisse eintreten müssen, bevor ein Prozess startet, müssen diese Startereignisse zur selben Aktivität führen. Die Attribute der Aktivität legen fest, wann die Aktivität starten kann. Die Startereignisse müssen also sozusagen alle gemeinsam eintreten. Dem entspricht eine UND-Verknüpfung zwischen den Startereignissen.
• Die Startereignisse sind unabhängig voneinander. Dies tritt v.a. bei umfangreicheren Geschäftsprozessen auf.

Selbstverständlich können von einem Startereignis auch mehrere Flüsse abgehen.

Im Subprozess

Oben wurde ja schon angemerkt dass bei der Realierung der Grafiken ein Startereignis nicht Ziel eines Sequenzflussablaufs sein darf. Eine Ausnahme ergibt sich, wenn das Startereignis in einem entfalteten (expanded) Subprozess benutzt wird und mit der Grenzlinie dieses Subprozesselements verbunden wird. In einem solchen Fall kann ein Sequenzfluss vom übergeordneten Prozess mit diesem Startereignis verbunden sein, statt mit der aktuellen grafischen Grenze des Subprozesses.

9.1.4 Zwischenereignisse - allgemein

Vgl. zu den möglichen Situationen für Zwischenereignisse und deren Kennzeichen Abbildung 9.1-2. Die graphische Darstellung erfolgt mit zwei Randlinien, durchgezogen oder unterbrochen.

Zwischenereignisse treten im Sequenzfluss zwischen dem Start- und dem Schlussereignis auf, geben also Ereignisse an, die dazwischen eintreten und prozessrelevant sind. Sie können …

• … zeigen, wo in einem Prozess Nachrichten erwartet oder versandt werden.
• … zeigen, wo in einem Prozess Verzögerungen erwartet werden.
• … den normalen Fluss durch Ausnahmebehandlung (exception handling) unterbrechen.
• … zeigen, wo Ersatzaktivitäten (Kompensationen) benötigt werden.

Die BPMN-Autoren sehen also ein Einsatzgebiet für Zwischenereignisse darin, bestimmte Prozesssituationen (Ausnahmen, Kompensationen, Zeitaspekte, ...) zu bewältigen. Dies geschieht in der grafischen Gestaltung, indem das Zwischenereignis auf die Grenzlinie der Aufgabe oder des Subprozesses gesetzt wird. Die folgende Abbildung zeigt ein Beispiel. Hier wird zum einen eine E-Mail-Diskussion moderiert. Zum anderen wird regelmäßig eine Zusammenfassung der Diskussion erstellt. In der Abbildung wird dafür ein Zwischenergebnis mit dem Kennzeichen Zeitgeber (vgl. unten) gesetzt. Dieses gibt an, dass nach 7 Tagen ein Bericht über die Diskussion erstellt wird.

Abbildung 9.1-3: Zwischenereignis mit Zeitgeber

Enthaltene Elemente:

- Zeitgeber-Zwischenereignis / Grenzlinie, unterbrechend

- Aufgaben

Zwischenereignisse können also an die Grenzlinie von Aktivitäten angefügt werden (Typen Grenzlinie, unterbrechend und Grenzlinie, nicht unterbrechend). Dafür gelten folgende Regeln:

• Es können alle Auslöser vorliegen, mit Ausnahme von Kein Auslöser und Verknüpfung.
• Das Kennzeichen Abbruch darf nur dann an die Grenze eines Subprozesses gesetzt werden, falls der Subprozess eine Transaktion ist (vgl. unten).
• Das Zwischenereignis darf nicht Ziel eines Sequenzflusses sein.
• Das Zwischenereignis muss Quelle genau eines Sequenzflusses sein.

Zum letztgenannten Punkt gibt es eine Ausnahme: Ein Zwischenereignis mit einem Kompensationsauslöser darf keinen wegführenden Sequenzfluss haben. Es kann aber eine wegführende Assoziation haben. Einige solche Zwischenereignisse finden sich in Abbildung 14.3-1.

Verknüpfung im Sequenzfluss

Zwischenereignisse können auch im normalen Fluss eingesetzt werden. Dabei dürfen alle Kennzeichen bis auf Fehler, Abbruch und Mehrfach verwendet werden (Typen Empfangend und Abgebend).

Folgende Regeln gelten hier:

• Zwischenereignisse der Typen Kein Auslöser und Kompensation müssen das Ziel eines Sequenzflusses sein. Sie müssen genau einen ankommenden Fluss haben.
• Zwischenereignisse der folgenden Typen dürfen Ziel eines Flusses sein: Nachricht, Zeitgeber, Bedingung, Verknüpfung und Signal. Sie dürfen genau einen ankommenden Fluss haben. Diese Zwischenereignistypen sind immer bereit, die Ereignisauslöser zu akzeptieren (einmal), solange der Prozess, in dem sie enthalten sind, aktiv ist. Sie sind nicht optional, sie sollten während der Ausführung des Prozesses ausgelöst werden.
• Ein Zwischenereignis muss Quelle eines Sequenzflusses sein; es muss einen (und genau einen) abgehenden Sequenzfluss haben.
• Ein Zwischenereignis mit dem Kennzeichen Nachricht kann das Ziel oder die Quelle eines Nachrichtenflusses sein, allerdings nicht beides gleichzeitig.

Token bei Zwischenereignissen

Kommt ein Token bei einem Zwischenereignis an, das im normalen Fluss eingeordnet ist, geschieht folgendes: Wird das Ereignis genutzt, um den Ereignisauslöser abzugeben, dann erfolgt die Auslösung unmittelbar (z.B. indem die Nachricht verschickt wird) und der Token geht weiter im Fluss. Wird das Ereignis genutzt, um den Ereignisauslöser zu empfangen, dann bleibt der Token bis der Auslöser erscheint (z.B. die Nachricht angekommen ist). Danach bewegt sich der Token weiter.

Damit stellt ein solches Zwischenereignis im "empfangenden Fall" eine Warteposition dar. Der Geschäftsprozess steht solange, bis das Ereignis eintritt.

9.1.5 Schlussereignisse - allgemein

Vgl. zu den möglichen Situationen für Schlussereignisse und deren Kennzeichen Abbildung 9.1-2. Die graphische Darstellung erfolgt mit einer dicken schwarzen Linie. Sie sind immer abgebend, d.h. das jeweilige grafische Symbol ist schwarz eingefärbt.

Schlussereignisse signalisieren die Beendigung des Prozesses/des Teilprozesses, an den sie angefügt sind. Sie sind immer vom Typ Abgebend. Folgende Regeln gelten für sie:

• Ein Schlussereignis muss das Ziel eines Sequenzflusses sein.
• Ein Schlussereignis kann mehrere ankommende Sequenzflüsse haben.
• Die Flüsse können von alternativen oder parallelen Pfaden stammen.
• Als Modellierungskonvention wird empfohlen, dass jeder Pfad zu einem eigenen Schlussereignis führt.
• Auf einer Prozessebene kann es mehrere Schlussereignisse eines Prozesses geben.
• Der Einsatz von Schlussereignissen ist optional. Eine bestimmte Prozessebene - ein Top-Level - Prozess oder ein entfalteter (expanded) Subprozess muss keines haben.
• Falls keines genutzt wird, sollte das implizite Schlussereignis für den Prozess kein Ergebnis haben.

Falls ein Schlussereignis genutzt wird, darf es keine anderen Flusselemente ohne abgehende Flüsse geben, d.h., alle anderen Flussobjekte müssen Quelle mindestens eines Sequenzflusses sein. Ausnahmen stellen wieder die Kompensationsaktivitäten dar. Diese dürfen keinen abgehenden Sequenzfluss haben.

Ein Schlussereignis darf nicht Ziel oder Quelle eines Nachrichtenflusses sein. Eine Ausnahme ergibt sich, falls das Schlussereignis in einem entfalteten Subprozess genutzt und an die Grenze dieses Subprozesses angefügt wird. In diesem Fall kann der Sequenzfluss von diesem Schlussereignis zu einem Sequenzfluss des übergeordneten Prozesses führen, anstatt dass dieser mit der aktuellen Grenze des Subprozesses verbunden ist.

Falls in einem BPD kein Schlussereignis genutzt wird, dann markieren alle Flussobjekte, die keinen abgehenden Sequenzfluss haben, das Ende eines Pfades in dem Prozess. Jedoch darf der Prozess erst enden, wenn alle parallelen Pfade vollständig realisiert wurden. Ausnahmen hierzu sind wieder Kompensationsaktivitäten.

Token

Token, die nach ihrer "Wanderung" durch den Geschäftsprozess bei einem Schlussereignis ankommen, gelten als verbraucht. Solange nicht alle im Prozess erzeugten Token auf diese Weise verbraucht wurden, ist der Prozess noch aktiv.

Obiges gibt einen wichtigen Hinweis auf das Prozessverständnis der BPMN-Autoren. Ein Geschäftsprozess hat u.U. mehrere aktive Bereiche, die eine gewisse Unabhängigkeit voneinander haben. In einer Standardprozessmodellierung, bei der typischerweise nicht an die Umsetzung in ein Programm oder System gedacht wird, hat ein Geschäftsprozess einen einzigen (u.U. tief verzweigenden) Sequenzfluss, der startet und irgendwann später endet.

Bei Prozessen ohne Schlussereignis wird ein Token, das ein Flussobjekt am Ende eines Flusses erreicht, verbraucht, wenn der Pfad abgearbeitet ist. Falls die ankommenden Flüsse parallel sind, werden sie verbraucht, wenn sie ankommen. Ist der Prozess ein Subprozess, kann er auch durch ein "unterbrechendes" (interrupting) Zwischenereigniss vor dem normalen Abschluss beendet werden. In einem solchen Fall werden die Token durch das Zwischenereignis verbraucht.

9.2 Ereignistypen

Oben wurden die Kennzeichen (marker) schon vorgestellt, hier nun eine Beschreibung im Gesamtzusammenhang, also mit Berücksichtigung der drei möglichen Positionen im Sequenzfluss (Start-, Zwischen-, Schlussereignis) und der Eigenschaft "empfangend, abgebend". Durch die Zuweisung von Kennzeichen zu Ereignissen entstehen Ereignistypen, so die Wortwahl der BPMN-Autoren.

9.2.1 Kein Auslöser

Falls man kein Kennzeichen angibt, wählt man das Ereignissymbol ohne Inhalt. Dies bedeutet, dass die nach dem Ereignis folgende Tätigkeit gestartet wird, ohne dass ein spezifischer Grund angegeben wird. Ein solches Startereignis ohne Kennzeichen wird auch für Subprozesse verwendet, die starten, wenn sie durch den übergeordneten Prozess angestoßen werden.

Abbildung 9.2-1: Ereignisse ohne Kennzeichen

Diesen Ereignistyp gibt es in allen drei Typen. Die Bedeutung ist wie folgt:

• Bei Startereignissen: Start des Geschäftsprozesses ohne explizite Angabe des Grundes.
• Bei abgebenden Zwischenereignissen: Eine weitere Initiierung ist an dieser Stelle notwendig.
• Bei Schlussereignissen: Beendigung des jeweiligen Sequenzflusszweiges. Es wird auch benutzt, um das Ende eines Subprozesses anzuzeigen, durch den der Fluss zurück zum übergeordneten Prozess geht.

Beispiele mit diesem Ereignistyp finden sich in zahlreichen Prozessmodellen dieses Textes, vgl. insbesondere Kapitel 14.

9.2.2 Nachricht

Die Kennzeichnung Nachricht (message) bedeutet, dass von einem Teilnehmer am Prozess eine Nachricht erwartet oder dass zu einem Teilnehmer eine Nachricht versendet wird.

Abbildung 9.2-2: Ereignistyp und Marker Nachrichten

Die Bedeutung ist wie folgt:

• Bei Startereignissen der obersten Ebene, dass durch die Nachricht der Prozess gestartet wird. Z.B. durch Kunde hat Rückfrage bestätigt.
• Bei Startereignissen des Typs Ereignissubprozess, unterbrechend, dass der Subprozess gestartet und der übergeordnete Prozess angehalten wird. Dann ist das Attribut isInterrupting der MessageEventDefinitionauf true gesetzt.
• Bei Startereignissen des Typs Ereignissubprozess, nicht unterbrechend, dass der Subprozess gestartet und der übergeordnete Prozess nicht angehalten wird.
• Bei empfangenden Zwischenereignissen, dass eine Nachricht eintreffen soll. Typischerweise ist der Prozess also angehalten und wartet auf eine Nachricht.
• Bei Zwischenereignissen des Typs Grenzlinie, unterbrechend: die Aktivität wird angehalten, bis die Nachricht eintrifft.
• Bei Zwischenereignissen des Typs Grenzlinie, nicht unterbrechend: die Aktivität wartet auf eine Nachricht, ohne unterbrochen zu werden.
• Bei abgebenden Zwischenereignissen, dass eine Nachricht zu einem Prozessteilnehmer geschickt wird.
• Bei einem Schlussereignis, dass bei der Beendigung des Sequenzflusszweiges eine Nachricht an einen Prozessteilnehmer geschickt wird.

9.2.3 Fehler

Dieses Symbol gibt an, dass eine benannte Fehlermeldung erzeugt wird. Es darf nur für Startereignisse von Subprozessen (unterbrechend), Zwischenereignisse des Typs Grenzlinie, unterbrechend und Schlussereignisse genutzt werden.

Abbildung 9.2-3: Ereignistyp und Marker Fehler

Bedeutung des Kennzeichens bzw. der Ereignistypen:

• Bei empfangenden Startereignissen eines Ereignissubprozesses startet es den Subprozess, der z.B. eine Fehlerbehandlung enthält.
• Bei Zwischenereignissen des Typs Grenzlinie, unterbrechend wird es benutzt, um eine Fehlermeldung einer Aktivität zu empfangen. In der Grafik kann es nur mit dem Rand der Aktivität (Aufgabe oder Subprozess) verbunden werden.
• Bei Schlussereignissen bedeutet dieses Kennzeichen, dass am Prozessende ein benannter Fehler erzeugt und abgegeben werden soll.

Zu allen dreien findet sich ein Beispiel in Abbildung 14.3-1.

Die grundsätzliche Vorstellung der BPMN-Autoren ist diesbezüglich wie folgt: Die Fehlermeldung wird von demjenigen Fehler-Zwischenereignis empfangen, das auf der Grenzlinie der am nahesten liegenden umfassenden Elternaktivität liegt. Im Beispiel von Abbildung 14.3-1 wird also das Fehler-Schlussereignis von Bearbeitung Buchungsfehler vom Fehler-Zwischenereignis des Subprozesses Buchung empfangen (Buchungsfehler 2).

9.2.4 Zeitgeber

Mit diesem Kennzeichen kann zum Ausdruck gebracht werden, dass das Ereignis Zeitaspekte erfasst. Dabei sind feste Zeit- und Datumsangaben möglich ("nach sieben Tagen") sowie auch Zyklen ("Monatsende"). Diese "Kennzeichnung" gibt es nur für empfangende Ereignisse, d.h., es ist nur vorgesehen, dass an der jeweiligen Stelle eine zeitliche Information empfangen wird, die dann andere Aktivitäten anstößt.

Abbildung 9.2-4: Ereignistyp und Marker Zeitgeber

Bedeutung des Kennzeichens bzw. der Ereignistypen:

• Bei Startereignissen für die Klärung der Zeitaspekte zum Start des Prozesses: Zeitgeber bedeutet, dass zeitliche Aspekte das Ereignis auslösen. Z.B., dass jede Nacht ab 2.00 Uhr automatisch die Zahlungseingänge mit den offenene Posten abgeglichen werden.
• Bei Startereignissen des Typs Ereignissubprozess, unterbrechend: Start des Ereignissubprozesses mit Unterbrechung des übergeordneten Prozesses.
• Bei Startereignissen des Typs Ereignissubprozess, nicht unterbrechend: Start des Ereignissubprozesses ohne Unterbrechung des übergeordneten Prozesses.
• Bei empfangenden Zwischenereignissen: Für die Klärung von Zeitaspekten. Falls es im Hauptfluss benutzt wird, kann es als Verzögerungsmechanismus genutzt werden. Falls es benutzt wird, um Ausnahmesituationen zu beschreiben, ändert es den normalen Fluss in einen Ausnahmefluss.
• Bei Zwischenereignissen des Typs Grenzlinie, unterbrechend: Abbruch der Aktivität und Weiterleitung zu einer anderen.
• Bei Zwischenereignissen des Typs Grenzlinie, nicht unterbrechend: Weiterleitung zu einer anderen Aktivität.

9.2.5 Eskalation

Dieses Ereignis signalisiert, dass eine Situation vorliegt, auf die der Geschäftsprozess reagieren muss, weil ein Prozessabschnitt nicht ordnungsgemäß beendet werden konnte und dass verstärkte Anstrengungen nötig sind. Z.B. weil ein Zeitlimit überschritten wurde. Dafür wird ein Subprozess aufgerufen. Der Marker ist eine nach oben gerichtete Pfeilspitze.

Abbildung 9.2-5: Ereignistyp und Marker Eskalation

Es liegt für folgende Situationen vor:

• Startereignis / Ereignissubprozess, unterbrechend: Zum Anstoßen eines eingebetteten Ereignissubprozesses mit unterbrechender Wirkung auf den aufrufenden Prozess.
• Startereignis / Ereignissubprozess, nicht unterbrechend: Zum Anstoßen eines eingebetteten Ereignissubprozesses ohne unterbrechende Wirkung auf den aufrufenden Prozess.
• Zwischenereignis / Grenzlinie, unterbrechend: Für eine benannte/identifizierte Eskalation, die den Prozess unterbricht.
• Zwischenereignis / Grenzlinie, nicht unterbrechend: Für eine benannte/identifizierte Eskalation, die den Prozess nicht unterbricht.
• Schlussereignis: Bei Beendigung des Geschäftsprozesses wird eine Eskalation ausgelöst.

Andere aktive Prozessstränge ("threads") sind dadurch nicht betroffen und werden weiter ausgeführt.

Wer empfängt die Eskalation? Das empfangende Eskalationszwischenereignis (mit demselben Eskalationscode oder ohne einen solchen), das auf der Grenzlinie der nahesten Elternaktivität liegt.

9.2.6 Signal

Dieser Ereignistyp wird verwendet, um Signale zu senden oder zu empfangen. Es gibt ihn für alle Ereignistypen. Signale können von allen empfangen werden ("broadcast communication"), die sich im selben Ereignisraumbefinden: in einem Prozess, über den Prozess hinaus, über mehrere Becken und zwischen Prozessdiagrammen. Beispiele finden sich am leichtesten in der technischen Systemwelt. Stellen wir uns einen Geldautomaten vor, dessen Sensoren einen Einbruch melden und der danach an alle Komponenten das Signal "Abschalten und sichern" sendet, usw. In kaufmännischen Geschäftsprozessen ist ein solches Ereignis üblicherweise nicht in Verwendung, weil Ereignissse wie Feueralarm oder Hochwasser typischerweise in Geschäftsprozessen nicht modelliert werden.

Abbildung 9.2-6: Ereignistyp und Marker Signal

Bedeutung des Kennzeichens bzw. der Ereignistypen:

• Startereignis / Ereignissubprozess, unterbrechend: Zum Anstoßen eines eingebetteten Ereignissubprozesses mit unterbrechender Wirkung auf den aufrufenden Prozess.
• Startereignis / Ereignissubprozess, nicht unterbrechend: Zum Anstoßen eines eingebetteten Ereignissubprozesses ohne unterbrechende Wirkung auf den aufrufenden Prozess.
• Zwischenereignis / Grenzlinie, unterbrechend: Für eine benannte/identifizierte Eskalation, die den Prozess unterbricht.
• Zwischenereignis / Grenzlinie, nicht unterbrechend: Für eine benannte/identifizierte Eskalation, die den Prozess nicht unterbricht.
• Schlussereignis: Bei Beendigung des Geschäftsprozesses wird eine Eskalation ausgelöst.

Obiges zeigt, dass ein Signal zur Kommunikation verwendet werden kann, innerhalb einer Prozessebene und über Prozessebenen hinweg. Wenn es ausgelöst wird, ist es "für alle" erkennbar. Es gibt also eine Quelle, aber kein bestimmtes Ziel. Dies unterscheidet Signale von Nachrichten, die eine spezifische Quelle und ein bestimmtes Ziel haben.

9.2.7 Abbruch

Durch diese Kennzeichnung entsteht ein Ereignistyp, der den Geschäftsprozess bzw. den jeweiligen Fluss abbricht. Er wird nur in besonderen Situationen eingesetzt (vgl. unten). Diese "Kennzeichnung" gibt es für Zwischenereignisse des Typs Grenzlinie, unterbrechend und für Schlussereignisse.

Abbildung 9.2-7: Ereignistyp und Marker Abbruch

Bei empfangenden Zwischenereignissen des Typs Grenzlinie, unterbrechend wird dieser Ereignistyp für Transaktionssubprozessegenutzt. Das Ereignis wird an die Grenzlinie des Subprozesses angefügt. Es wird ausgelöst, wenn ein Abbruchschlussereignisim Transaktionssubprozess erreicht wird. Es soll außerdem auch ausgelöst werden, wenn während der Ausführung der Transaktion eine Abbruchnachricht im Transaktionsprotokoll erreicht wurde, d.h., wenn sozusagen der Transaktionssubprozess signalisiert, dass keine vollständige Abarbeitung (kein korrektes Ende) erreicht wurde.

Bei Schlussereignissen wird das Ereignis ebenfalls in Transaktionssubprozessen benutzt. Es zeigt an, dass die Transaktion abgebrochen werden soll und löst ein Fehler-Zwischenereignis aus, das an der Grenzlinie des Subprozesses angefügt ist. Zusätzlich zeigt es an, dass eine Abbruchnachricht des Transaktionsprotokolls an alle Entities (so die Wortwahl der BPMN-Autoren) geschickt werden soll, die an der Transaktion beteiligt sind.

9.2.8 Kompensation

Ereignisse mit dem Kennzeichen Kompensation (compensation) signalisieren die Notwendigkeit, eine bestimmte Handlung durch eine andere zu ersetzen. Z.B. eine schief gehende Online-Buchung durch eine telefonische. Es gibt sie als Startereignisse von Ereignissubprozessen, als Zwischenereignisse des Typs Grenzlinie, unterbrechend und Abgebend sowie als Schlussereignisse.

Ist es vom Typ Zwischenereignis / Grenzlinie, unterbrechend wird das grafische Symbol also an die Grenzlinie einer Aktivität angefügt, muss es auch einen Sequenzflusspfeil zu einer anderen Aktivität geben, der sogenannten Kompensationsaktivität. Diese ist dann im Krisenfall Ersatz für die Ausgangsaktivität (die mit dem Kompensations-Ereignis). Kompensationsaktivitäten dürfen keinen ankommenden Sequenzfluss haben. D.h., der Pfeil von der Aktivität mit dem Ereignis zur Kompensationsaktivität wird von den BPMN-Autoren nicht als Sequenzfluss gesehen.

Abbildung 9.2-8: Ereignistyp und Marker Kompensation

Die Bedeutung des Kennzeichens bzw. der Ereignistypen ist wie folgt:

• Startereignis / Ereignissubprozess, unterbrechend: Der Ereignissubprozess wird gestartet. Vgl. die Beispiele in Abbildung 14.3-1.
• Zwischenereignis / Grenzlinie, unterbrechend: In dieser Konstellation (empfangendes Zwischenereigniss) wird dieser Ereignistyp für Ersatzaktivitäten (Kompensationen) benutzt, zur Aktivierung und zur Ausführung. D.h., das Ereignis empfängt von der Aktivität die Information, dass die Ersatzaktivität angestoßen werden soll.
• Zwischenereignis / abgebend: An dieser Stelle eines Sequenzflusses löst es ein Ereignis aus. Vgl. Abbildung 14.3-1.
• Bei Schlussereignissen bedeutet dieses Kennzeichen, dass am Ende eine Kompensation notwendig ist. Falls eine Aktivität identifiziert wird, ist das die zu kompensierende Aktivität. Ist keine Aktivität identifiziert, werden alle Aktivitäten, die im Prozess durchgeführt wurden, beginnend mit der obersten Ebene, und alle Subprozesse umfassend kompensiert - in umgekehrter Reihenfolge.

9.2.9 Bedingung

Dieser Ereignistyp wird ausgelöst, falls eine bestimmte Bedingung erfüllt ist, z.B. "Lagerbestand ist unter die Nachbestellmarke gefallen". Die Bedingung für das Ereignis muss falsch und dann wieder wahr werden, bevor das Ereignis wieder ausgelöst werden kann. Diese Kennzeichnung gibt es nur bei empfangenden Ereignissen.

Abbildung 9.2-9: Ereignistyp und Marker Bedingung

Bedeutung des Kennzeichens bzw. der Ereignistypen:

• Startereignis / oberste Ebene: Der Prozess wird gestartet, wenn die Bedingung erfüllt ist. Z.B. "DAX um mehr als 5 Punkte verändert" oder "Temperatur über 300 Grad Celsius".
• Startereignis / Ereignissubprozess, unterbrechend: Subprozess wird gestartet und der übergeordnete Prozess wird angehalten, wenn die Bedingung eintritt.
• Startereignis / Ereignissubprozess, nicht unterbrechend: Subprozess wird gestartet und der übergeordnete Prozess wird nicht angehalten, wenn die Bedingung eintritt.
• Zwischenereignis / Empfangend: Der Prozess ist angehalten und wartet auf ein Ereignis, z.B. eine Nachricht.
• Zwischenereignis / Grenzlinie, unterbrechend: Die Aktivität wird angehalten, falls die Bedingung eintritt.
• Zwischenereignis / Grenzlinie, nicht unterbrechend: Die Aktivität wird nicht angehalten, falls die Bedingung eintritt.

Einen Hinweis auf die methodische Umsetzung geben folgende Anmerkungen der BPMN-Autoren für den Start durch ein Ereignis mit Bedingung: Da es noch keine Prozessinstanzengibt, wenn das Ereignis eintreten kann, darf die Bedingung (Condition Expression) eines solchen Startereignisses (Conditional Start Event) nicht auf den Datenkontextoder auf Prozessattributeverweisen. Dagegen darf es auf statische Prozessattribute und den Zustand von Entities verweisen, bzw. von dort ausgelöst werden.

9.2.10 Verknüpfung

Ein Ereignis mit dem Kennzeichen Verknüpfung (link) zeigt an, dass zwei Abschnitte eines Prozesses verknüpft werden. Z.B. für Schleifen oder um sehr lange Sequenzflusslinien zu vermeiden. Sie dürfen nicht ebenenübergreifend verwendet werden, sondern jeweils nur auf einer Modellierungsebene. Mit jeweils zwei solchen Zwischenereignissen können somit auch Prozessfragmente verknüpft werden, die über mehrere Seiten gedruckt werden müssen.

Es kann mehrere Quell-Verknüpfungsereignisse geben, aber nur ein Ziel-Verknüpfungsereignis. Wird das Kennzeichen benutzt, um zu empfangen (von den Quell-Verknüpfern), bleibt das Kennzeichen unbefüllt. Wird es benutzt, um zum Zielverknüpfer abzugeben, wird das Kennzeichen gefüllt. Diese Kennzeichnung gibt es nur für Zwischenereignisse.

Abbildung 9.2-10: Ereignistyp und MarkerVerknüpfung

9.2.11 Beenden

Ein Ereignis mit dem Kennzeichen Beenden beendet den Prozess. Dabei werden alle Aktivitäten im Prozess unmittelbar beendet. Dies umfasst auch alle Instanzen von Mehrfachinstanzen. Der Prozess wird ohne Kompensation oder Handlungen durch Ereignisse beeendet. Diese Kennzeichnung gibt es nur für Schlussereignisse.

Abbildung 9.2-11: Ereignistyp und Marker Beenden

9.2.12 Mehrfach

Das Kennzeichen Mehrfach (multiple) bedeutet, dass dem Ereignis mehrere Auslöser zugewiesen sind. Es ist in allen Konstellationen einsetzbar.

Abbildung 9.2-12: Ereignistyp und Marker Mehrfach

Bedeutung des Kennzeichens bzw. der Ereignistypen:

• Bei Startereignissen der obersten Ebene, dass es mehrere Wege gibt, den Prozess zu starten. Nur einer ist nötig.
• Bei Startereignissen des Typs Ereignissubprozess, unterbrechend, dass der Subprozess auf einem der Wege gestartet und der übergeordnete Prozess angehalten wird.
• Bei Startereignissen des Typs Ereignissubprozess, nicht unterbrechend, dass der Subprozess auf einem der Wege gestartet und der übergeordnete Prozess nicht angehalten wird.
• Bei empfangenden Zwischenereignissen, dass eine Nachricht eintreffen soll. Typischerweise ist der Prozess also angehalten und wartet auf eine Nachricht.
• Bei Zwischenereignissen des Typs Grenzlinie, unterbrechend: Die Aktivität wird angehalten, bis die Nachricht eintrifft.
• Bei Zwischenereignissen des Typs Grenzlinie, nicht unterbrechend: Die Aktivität wartet auf eine Nachricht, ohne unterbrochen zu werden.
• Bei abgebenden Zwischenereignissen, dass eine Nachricht zu einem Prozessteilnehmer geschickt wird.
• Bei einem Schlussereignis, dass die Beendigung des Prozesses mehrere Konsequenzen hat. Alle werden deutlich, z.B., wenn mehrere Nachrichten zu senden sind.

9.2.13 Parallel mehrfach

Dieser Marker wird eingesetzt, wenn es mehrere Auslöser (mehr als eine EventDefinition) für das Ereignis gibt und wenn alle Auslöser aktiv werden müssen, um das Ereignis auszulösen.

Abbildung 9.2-13: Ereignistyp und Marker Parallel mehrfach

Bedeutung des Kennzeichens bzw. der Ereignistypen:

• Bei Startereignissen der obersten Ebene geht es - so die Wortwahl der BPMN-Autoren - um eine Synchronisation von Ereignissen. Wenn mehrere voneinander unabhängige Startereignisse eintreten müssen, damit eine Prozessinstanz startet, muss dieses Ereignis vor der ersten Aktivität platziert werden. Vgl. auch Abschnitt 12.1. Es liegt dann mehr als eine Ereignisdefinition vor. Allgemein gesprochen muss also eine UND-Verknüpfung zwischen den Ereignissen vorliegen.
• Bei Startereignissen des Typs Ereignissubprozess, unterbrechend, dass der Subprozess durch die Auslöser gestartet und der übergeordnete Prozess angehalten wird.
• Bei Startereignissen des Typs Ereignissubprozess, nicht unterbrechend, dass der Subprozess durch die Auslöser gestartet und der übergeordnete Prozess nicht angehalten wird.
• Bei empfangenden Zwischenereignissen, das es mehrere dem Ereignis zugeordnete Auslöser gibt.
• Bei Zwischenereignissen des Typs Grenzlinie, unterbrechend, dass mehrere dem Ereignis zugeordnete Auslöser eintreten müssen und dass die Aktivität unterbrochen wird.
• Bei Zwischenereignissen des Typs Grenzlinie, nicht unterbrechend, dass mehrere dem Ereignis zugeordnete Auslöser eintrreten müssen und dass die Aktivität nicht unterbrochen wird.

10 Kontrollfluss - Sequenzfluss

10.1 Einführung

Geschäftsprozesse haben einen Kontrollfluss. Er gibt die Ablaufstruktur an und ohne ihn gibt es keine Erfassung, Durchdringung und Modellierung. Die Autoren von [OMG 2009] bevorzugen allerdings den Begriff sequence flow (hier mit Sequenzfluss übersetzt) gegenüber control flow und definieren wie folgt:

Definition Sequenzfluss (sequence flow)

Der Sequenzfluss zeigt die Abfolge, in der Aktivitäten in einem Prozess oder einer Choreographie abgearbeitet werden [OMG 2011, S. 34], Übersetzung durch den Verfasser).

Folgende Begründung geben die BPMN-Autoren dafür, dass sie nicht den Begriff Kontrollfluss verwenden:

BPMN does not use the term "Control Flow" when referring to the lines represented by Sequence Flow or Message Flow. The start of an activity is "controlled" not only by Sequence Flow (the order of activities), but also by Message Flow (a message arriving), as well as other process factors, such as scheduled resources. Artifacts can be associated with activities to show some of these other factors. Thus, we are using a more specific term, "Sequence Flow," since these lines mainly illustrate the sequence that activities will be performed [OMG 2009, S. 98].

Es ist also die Bedeutung des Nachrichtenflusses und anderer "steuernder Elemente", die zu dieser Festlegung führten.

10.2 Flüsse

Die BPMN-Autoren unterscheiden verschiedene Arten von Flüssen:

• Normalen Sequenzfluss
• Verknüpfungen
• Ad hoc (kein Fluss)
• Unkontrollierten Fluss
• Fluss mit Bedingungen
• Voreingestellten Fluss
• Flüsse für Ausnahmen

Normaler Sequenzfluss (normal flow)

Damit ist der ganz normale Sequenzfluss gemeint, vom Startereignis über die Aktivitäten hin zu einem Schlussereignis. Er wird grafisch, wie oben schon gezeigt, durch eine Linie mit gefülltem Pfeilkopf dargestellt.

Abbildung 10.2-1: Darstellung einer Sequenzflusskante

Ausgenommen sind Abschnitte des Sequenzflusses, die von einem Zwischenereignis der Typen Grenzlinie unterbrechend/nicht unterbrechend stammen [OMG 2011, S. 34].

Unkontrollierter Fluss (uncontrolled flow)

Als unkontrollierten Fluss bezeichnen die BPMN-Autoren eine Sequenzflusskante, die keinen Bedingungen unterliegt und keinen Operator passiert. Der einfachste Fall ist eine Sequenzflusskante, die schlicht zwei Aktiväten verbindet, wie in der obigen Abbildung. Damit ist aber auch die Situation gemeint, wenn mehrere Sequenzflusskanten ohne Gateway zu einer Aktivität hinkommen oder wegführen. Dabei gilt die Festlegung, dass für jeden dieser unkontrollierten Flüsse ein Token freigesetzt wird [OMG 2011, S. 34f]. Damit entspricht dies einer impliziten UND-Verknüpfung. Die grafische Darstellung ist wie oben gezeigt.

Fluss mit Bedingungen (conditional flow)

Ein Sequenzfluss kann Bedingungen haben, die zur Laufzeit(!) (des Prozesses) überprüft werden, um zu bestimmen, ob der Zweig aktiv wird/genutzt wird. Kommt der Zweig von einer Aktivität, erhält er eine kleine Raute am Anfang der Linie. Vgl. die folgende Abbildung.

Abbildung 10.2-2: Darstellung eines Flusses mit Bedingung

Kommt der Zweig von einem Operator (Gateway, vgl. unten), erhält er keine Raute. Dann wird also die ganz normale Pfeildarstellung genommen, wie oben gezeigt.

Voreingestellter Fluss (default flow)

Für datenbasierte Exklusiv-Oder-Entscheidungen oder für inklusive Entscheidungen (mehr dazu unten) gibt es einen weiteren Sequenzflusstyp, den voreingestellten Fluss. Dieser wird nur benutzt, wenn die anderen zur Laufzeit (wörtlich!) keine Gültigkeit erlangen. Bei diesen Sequenzflusskanten wird ein umgekehrter Schrägstrich am Beginn der Linie eingefügt.

Abbildung 10.2-3: Darstellung eines voreingestellten Flusses

Flüsse für Ausnahmen (exception flow)

Bei diesem Flusstyp geht es darum, Ausnahmen zu verarbeiten. Er beruht immer auf einem Zwischenereignis der Typen Grenzlinie unterbrechend / nicht unterbrechend. Somit tritt er außerhalb des normalen Flusses auf. Die grafische Darstellung erfolgt durch ein Zwischenereignis, das bei einer Aktivität platziert wird. Tritt dieses Ereignis ein, gibt eine Pfeillinie an, welche Aktivität dann angestoßen wird.

Die folgende Abbildung zeigt ein Beispiel: Die Aktivität sei ein Rechenzentrumsbetrieb. Die Ausnahmesituation sei Hochwasser. Ausgelöst wird dann das Notfallmanagement.

Abbildung 10.2-4: Darstellung eines Ausnahmeflusses

Enthaltene Elemente (Auswahl):

- Fehler-Zwischenereignis / Grenzlinie, unterbrechend

Was bedeutet obiges, wenn also ein Ereignis auf der Grenzline einer Aktivität platziert wird? Es entspricht einer "IF-Abfrage" an die Aktivität. Etwa so:

• Sind zwei Wochen vergangen (bei einer zeitlichen Abfrage)?
• Ist ein Notfall eingetreten?
• Ist eine Ersatzaktivität auszuführen?

Die IF-Abfrage hat zwei Ausprägungen: Bejahung oder Verneinung. Im Falle der Bejahung tritt das Ereignis ein und der Sequenzfluss geht über das Ereignis weiter. Im Falle der Verneinung setzt die Aktivität ihre sonstige Arbeit fort (den "normalen Fluss").

Ohne diese prozesstechnische Interpretation kann dies auch so gesehen werden: Die Platzierung auf der Grenzlinie nimmt Bezug zum Konzept des Ereignisraumsder Aktvität (des Prozesses). In diesem können alle möglichen Ereignisse auftreten, auf die dann unterschiedlich geantwortet wird.

10.3 Sequenzflüsse mit Subprozessen

Zu einem Subprozess kann ein Sequenzfluss hinführen. Ein Sequenzflusszweig oder mehrere, alternativ oder parallel. Dann gibt es im übergeordneten Prozess ein Element, das auf den Subprozess verweist und im Subprozess gibt es ein Startereignis. Falls es mehrere Aufrufe gibt, wird die Beziehung durch ein Attribut (TargetRef) hergestellt.

Falls ein Subprozess mehrere ankommende Sequenzflüsse hat, liegt die Situation vor, die von den BPMN-Autoren als unkontrollierter Fluss bezeichnet wird. Dies bedeutet: Kommt ein Token auf einer der Kanten an, wird der Subprozess instantiiert. Es wird nicht auf eventuelle Token der anderen Kanten gewartet. Kommt dann ein weiterer Token an, auf derselben Kante oder einer anderen, wird der Subprozess erneut instantiiert.

Muss der Fluss kontrolliert werden, dann sollten die einzelnen Flüsse zu einem Gateway (Operatoren, vgl. Kapitel 11) zusammengeführt werden, das vor dem Subprozess angesiedelt ist. Hat ein Subprozess keinen ankommenden Sequenzfluss und auch kein Startereignis, dann muss der Subprozess instantiiert werden, wenn der Prozess instantiiert wird.

Ausnahmen hierzu sind Subprozesse, die als Kompensationsaktivitäten (compensation activities) deklariert sind, die also einen CompensationMarker haben. Kompensationssubprozesse sind nicht Teil des normalen Flusses und werden nicht instantiiert, wenn der Prozess instantiiert wird.

Von einem Subprozess können Sequenzflüsse weggehen. Für jeden erzeugt der Subprozess einen Token. Die TokenId(identifizierende Information des Token) wird so angelegt, dass deutlich wird, dass alle diese Token von derselben parallelen Gabelung stammen und auch so, dass die Anzahl der parallel existierenden Token deutlich wird.

Hat der Subprozess keinen abgehenden Sequenzfluss und gibt es kein Schlussereignis, dann stellt der Subprozess das Ende eines Pfades oder mehrerer im Prozess dar. Endet der Subprozess, ohne dass andere parallele Pfade aktiv sind, dann muss der Prozess abgeschlossen werden. Ausnahmen hiervon sind wiederum Subprozesse, die als Kompensationsaktivitäten festgelegt sind.

10.4 Nachrichtenflüsse

Nachrichten wurden schon in Kapitel 7 betrachtet. Dieses Konzept des Nachrichtenflusses (Message Flow) wurde von den BPMN-Autoren intensiv in ihre Methode eingebaut. Nachrichtenflüsse finden zwischen zwei Teilnehmern am Geschäftsprozess statt. Für diese verwenden die BPMN-Autoren an einigen Stellen den Begriff entity. Nicht zulässig sind Nachrichtenflüsse zwischen Elementen im selben Becken.

Grafisch werden sie durch eine Pfeillinie ausgedrückt, die am Anfang einen kleinen Kreis und am Ende eine leere geschlossene Pfeilspitze hat. Vgl. die folgende Abbildung.

Abbildung 10.4-1: Darstellung eines Nachrichtenflusses

Nur zwischen Becken

Nochmals zur Erinnerung: Nachrichtenflüsse sind nur zwischen verschiedenen Becken erlaubt. Sie können zu den Grenzen der Becken führen oder zu Flussobjekten innerhalb der Beckengrenzen. Sie können nicht zwei Elemente im selben Becken verbinden.

Nachrichten zu Subprozessen

Ein Subprozess kann Ziel eines Nachrichtenflusses sein; er kann keinen, einen oder mehrere ankommende Nachrichtenflüsse haben. Ein Subprozess kann auch Quelle eines Nachrichtenflusses sein. Er kann keinen, einen oder mehrere abgehende Nachrichtenflüsse haben.

10.5 Schleifen

In Prozessen im allgemeinen und Geschäftsprozessen im besonderen gibt es Bedarf an der Wiederholung von Prozessabschnitten durch Rücksprünge auf eine flussaufwärts gelegene Stelle des Prozesses. Da diese Wiederholung oft mehrfach nötig ist, entstehen Schleifen. Die BPMN-Autoren haben zwei Schleifenkonstrukte in ihre Methode eingebaut, activity looping und sequence flow looping [OMG 2011, S. 38f].

Schleife in einer Aktivität - Standardsituation

Es kommt in der Prozessmodellierung oft vor, dass eine Tätigkeit von vorneherein wiederholend angelegt ist. Eine solche modelliert man u.U. in ein Basiselement des Modellierungsansatzes, hier also in Aktivitäten. Dann enthält das Basiselement (die Aktivität) eine implizite Schleife.

Die BPMN-Autoren nennen diesen Vorgang activity loopingund haben dafür ein eigenes Symbol vorgesehen, einen geöffneten Kreis mit Pfeilspitze, der innen und zentriert am unteren Rand des Aktivitätsdiagramms angefügt wird. Die folgende Abbildung zeigt dies und ein Beispiel.

Ansonsten ist die Spezifikation der Schleife in den Attributen der Aktivität festgehalten.

Abbildung 10.5-1: Darstellung einer Aktivität mit Schleifencharakter (vgl. auch Kapitel 6)

Einen Schritt in Richtung Programmierung machen die BPMN-Autoren mit der Unterscheidung von While- und Until-Schleifen, wie es in der prozeduralen Programmierung üblich ist. Dabei gilt:

• Eine While-Schleife prüft die Bedingung, bevor die Aktivität ausgeführt wird, was bedeutet, dass die Aktivität u.U. gar nicht ausgeführt wird (wenn die Bedingung von vorneherein nicht erfüllt ist).
• Eine Until-Schleife prüft den Ausdruck, nachdem die Aktivität ausgeführt wurde, d.h., die Aktivität wird mindestens einmal ausgeführt.

Schleife in einer Aktivität - Multiple Instances / Mehrere Instanzen eines Subprozesses

Hierbei handelt es sich um eine Schleife, in der mehrere Instanzen eines Subprozesses aktiviert werden. In den Attributen der Aufgaben bzw. Subprozesse ist festgehalten, ob sie wiederholt oder nur einfach ausgeführt werden. Ein grafisches Symbol (drei senkrechte Linien) am unteren Rand (zentriert) gibt diesen Schleifentyp an.

Abbildung 10.5-2: Schleifen durch Multiple Instance (vgl. auch Kapitel 6)

Die Instanzen können seriell (nacheinander) oder parallel angeordnet sein. Sind sie seriell angeordnet, wird dies zu einer While-Schleife mit einer bestimmten Anzahl von Durchgängen.

Sind sie parallel angeordnet sehen dies die BPMN-Autoren so, dass mehre Instanzen der Aktivität vorliegen. Etwa so wie beim Schreiben eines Buches, wo das Schreiben eines Kapitels ein Subprozess wäre und dann für jedes Kapitel eine Kopie dieses Subprozesses angelegt würde [OMG 2009, S. 118].

Die Markierung für Mehrfachinstanzen(multiple instance marker) kann in Kombination mit jedem anderen Marker, mit Ausnahme der Markierung für Scheifen (loop Marker) verwendet werden. Vgl. auch Kapitel 6.

Schleife im Sequenzfluss

Dieses Konzept entspricht dem in der Prozessmodellierung üblichen Rücksprung- bzw. Schleifenkonstrukt. Dabei wird - von einem exklusiven Oder-Operator ausgehend - zu einer Stelle im Sequenzfluss gesprungen, die "weiter oben" (flussaufwärts) liegt. Dies kann auch als ein regelmäßig auftretendes Muster in Geschäftsprozessen betrachtet werden (Muster Rücksprung). Vgl. zu einigen Mustern Kapitel 12.

Die syntaktische Umsetzung ist wie folgt: Der Rücksprung kommt von einem Exclusive Gateway und geht zurück vor eine Aktivität (Aufgabe, Subprozess). Dort wird sie ohne Gateway oder mit einem Exclusive Gateway eingebunden.

Abbildung 10.5-3: Rücksprung per Schleife im Sequenzfluss

10.6 Kompensationen

Kompensationsassoziation

Eine Kompensationsassoziationtritt außerhalb des normalen Flusses auf und basiert auf einem Kompensations-Zwischenereignis, das durch den Fehlschlag einer Transaktion oder ein Kompensations-Ereignis ausgelöst wird. Das Ziel der Assoziation muss als Kompensationsaktivität deutlich gemacht werden.

Abbildung 10.6-1: Darstellung einer Kompensationsassoziation

Enthaltene Elemente (Auswahl):

- Kompensations-Zwischenereignis / Grenzlinie, unterbrechend

10.7 Prozessunterbrechung

Mit Hilfe von empfangenden Zwischenereignissen des Typs Nachricht (vgl. Kapitel 9) können Prozessunterbrechungen eingebaut werden. Im nachfolgenden Fragment geht es im Sequenzfluss erst weiter, wenn das Angebot eingetroffen ist.

Abbildung 10.7-1: Darstellung einer Prozessunterbrechung

Enthaltene Elemente (Asuwahl):

- Nachrichten-Zwischenereignis, empfangend

10.8 Handlung durch Ereignisse

Als Prozessmodellierer kennt man Kontroll- oder Sequenzflüsse als Pfeillinien (Kanten), mit denen Aktivitäten verbunden sind. Prozessablauf durch sequentiell angeordnete meist verzweigte Kontroll- oder Sequenzflüsse also. Daneben gibt es aber auch einen Kontrollfluss mit Hilfe von Ereignissen. Dazu dienen folgende Methodenelemente:

• Startereignis vom Typ Ereignissubprozess, unterbrechend
• Startereignis vom Typ Ereignissubprozess, nicht unterbrechend
• Zwischenereignisse aller Typen

Hilfreich bei den folgenden Betrachtungen ist wiederum das Konzept des Ereignisraums. Jedes Ereignis, das abgegeben wird, ist in diesem präsent. Der Ereignisraum aller Subprozesse, Aktivitäten, usw. ist der Elternprozess, der Prozess, in dem die Subprozesse und Aktivitäten eingebettet sind (vgl. für Alternativen und Beispiele das Stichwort Ereignisraum). Das Beispiel der nächsten Abbildung mit zahlreichen empfangenden und abgebenden Zwischenereignissen möge dies verdeutlichen.

Für alle empfangenden Zwischenereignisse auf Grenzlinien gilt: Wenn "innerhalb" des Rahmens (der Aufgabe, des Subprozesses, der Transaktion) etwas passiert, was zu den "Grenzlinienereignissen" passt, tritt das Ereignis ein. Dabei wird dann auch ein Sequenzfluss realisiert, der aber grafisch nicht direkt ausgewiesen wird. Im Subprozess Flug- und Hotelbuchung der folgenden Abbildung liegen dazu folgende Beispiele vor:

• Das empfangende Nachrichten-Zwischenereignis / Grenzlinie, nicht unterbrechend am Subprozess Buchung tritt ein, falls während des Buchungsvorgangs die Notwendigkeit entsteht, die Kreditkartendaten zu aktualisieren.
• Das empfangende Kompensations-Zwischenereignis / Grenzlinie, unterbrechend am Subprozess tritt ein, wenn sich herausstellt, dass die Buchung rückgängig gemacht werden muss.
• Das empfangende Fehler-Zwischenereignis / Grenzlinie, unterbrechend "Buchungsfehler 2 führt zu einem Exclusive Gateway das entweder an den Beginn der Transaktion verzweigt oder zu einer Aktivität, mit der der Kunde über den Fehlschlag informiert wird. ""

An der Aktivität Belaste Kreditkarte:

• Das empfangende Fehler-Zwischenereignis / Grenzlinie, unterbrechend führt zu einem Kompensations-Zwischenereignis / abgebend. Dies soll die Rücknahme der gesamten Buchung anfordern.

Abbildung 10.8-1: Flug- und Hotelbuchung - Variante 1. Als Subprozess mit "Grenzereignissen".
Quelle: [OMG 2011, S. 270, Figure 10.87, 10.101]. Übersetzung durch den Verfasser.

Vgl. für eine Darstellung des Prozesses anhand einer detaillierteren Modellierung Abbildung 14.3-1.

Varianten dieses Geschäftsprozesses finden sich in:

Abbildung 10.8-1 (Variante 1), Abbildung 10.9-3 (Variante 2), Abbildung 11.8-3 (Variante 3), Abbildung 14.3-1 (Variante 4) und Abbildung 14.4-1 (Variante 5)

Es ist also - sozusagen - ziemlich viel los im Ereignisraum. Empfangende Zwischenereignisse bedeuten immer, dass aus dem Ereignisraum etwas empfangen, ein dort auftretendes Ereignis wahrgenommen werden kann. Abgebende Zwischenereignisse, dass in denselben abgegeben wird.

10.9 Transaktionen

Das ganz übliche Transaktionenkonzept wurde von den BPMN-Autoren ebenfalls in ihren Modellierungsvorschlag eingebaut. Sie definieren wie folgt:

Definition Transaktion

Eine Transaktion ist ein Subprozess bei dem alle "Beteiligten" ("all parties involved" [OMG 2011, S. 39]) übereinstimmen, dass der Prozess entweder ganz abgeschlossen oder abgebrochen wird.

Festgelegt wird die Eigenschaft, Transaktion zu sein, in den Attributen. Die grafische Darstellung erfolgt durch eine doppelte Grenzlinie für den Subprozess.

Abbildung 10.9-1: Subprozess als Transaktion

Enthaltene Elemente (Auswahl):

- Startereignis

- Schlussereignis

- Transaktion

Eine Transaktion wird typischerweise auf drei Arten beendet:

• Durch erfolgreichen Abschluss
• Durch einen Fehlschlag
• Durch zufällige, die Transaktion beeinträchtigende Ereignisse, die mit Begriffen wie "Zufall / Gefahr / Wagnis / Risiko" assoziiert werden können.

Der erfolgreiche Abschluss der Transaktion wird als Sequenzfluss angezeigt, der vom Rand des Transaktionssymbols wegführt (siehe Abbildung oben). Grundsätzlich kommt es zum erfolgreichen Abschluss, wenn alle Aktivitäten erfolgreich realisiert wurden und der Sequenzfluss des eingebetteten Prozesses zum Schlussereignis kam.

Wenn eine Transaktion abgebrochen wird, dann muss auf die eine oder andere Weise der eingebettete Prozess gescheitert sein, d.h. es wurde ein entsprechendes Zwischenereigniss der Transaktion (im Beispiel unten ein Fehler-Zwischenereignis oder ein Abbruch-Zwischenereignis, vgl. den unteren Rand) angesprochen. Dies führt zu Abbruchaktivitäten, evtl. auch zu einem Rollback. Die Platzierung dieser Ereignisse auf dem Rand bedeutet also, dass im Falle eines Fehlers oder im Falle eines Abbruchs dieses Ereignis eintritt und vom ihm der Sequenzfluss weitergeht zu den Aktivitäten, die für diese Fälle vorgesehen sind.

Im Falle einer "Katastrophe" ging also etwas sehr schief und ein normaler Abschluss oder Abbruch ist nicht mehr möglich. Die Aktivität wird unterbrochen und der Fluss geht vom Fehler-Zwischenereignis aus weiter. Im Beispiel von Abbildung 10.9-3 bedeutet dies konkret, dass dann, wenn eines der Kompensations-Zwischenereignisse eintritt (bei Flug buchen oder bei Hotel buchen) das Abbruch-Zwischenereignis der Transaktion angesprochen wird. Dieses Cancel Intermediate Event, angelegt an der Grenzlinie der Aktivität, steuert den Fluss, wenn die Transaktion rückabgewickelt wurde und alle Kompensationen getätigt wurden. Das Abbruch-Zwischenereignis kann nur an der Grenzlinie einer Transaktionsaktivität genutzt werden, nicht im normalen Fluss und nicht bei einer Aktivität, die nicht Transaktion ist.

Das Fehler-Zwischenereignis der Transaktion, das die Bearbeitung durch den Kundendienst aktiviert, soll wohl weitere "von außen" kommende Ereignisse ansprechen, wie z.B. einen Stromausfall, einen Zusammenbruch der Datenleitung, usw. Tritt ein solches ein, geht es weiter zur Bearbeitung durch den Kundendienst.

Hier wird eines der Grundkonzepte der BPMN-Autoren deutlich. Die Beeinflussung von Aktivitäten in einem Prozess wird auch über Ereignisse realisiert, es gibt einen Ereignisraumdes Prozesses, in dem Ereignisse eintreten, die bestimmte Aktivitäten auslösen, stoppen, usw.

Abbildung 10.9-2: Subprozess als Transaktion - verborgen (collapsed)
Quelle: [OMG 2011, Figure 10.34, S. 179]
Übersetzung durch den Verfasser

Enthaltene Elemente (Auswahl):

- Abbruch-Zwischenereignis / Grenzlinie, unterbrechend

- Fehler-Zwischenereignis / Grenzlinie, unterbrechend