Auszüge aus dem Buch: Ereignisgesteuerte Prozessketten. Das Werkzeug für die Modellierung von Geschäftsprozessen. 3. Auflage

©2014, 2015, 2022 Josef L. Staud

Autor: Josef L. Staud

Stand: Februar 2022

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

Ereignisgesteuerte Prozessketten. Das Werkzeug für die Modellierung von Geschäftsprozessen
März 2014
ISBN: 978-3-00-045298-7
222 Seiten - 112 Abbildungen - Preis: 21,40 Euro

Die dritte Auflage soll 2022 erscheinen.

Aufbereitung für's Web

Diese HTML-Seiten wurden mithilfe eines von mir erstellten Programms erzeugt: WebGenerator (Version 2022-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@gmx.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 L. Staud

Vorwort, Inhalt, Abkürzungen

Vorwort

Es ist nicht mehr die Zeit, wie bei Erscheinen meines ersten Buches zu Geschäftsprozessen und Ereignisgesteuerten Prozessketten (vgl. [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.

Kaum mehr weiße Flecken in den Prozesslandschaften der Organisationen.

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.

Ständige Aufgabe

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.

Immer detaillierter, teilweise automatisiert, voll automatisiert

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.

Ebenen in der Prozessmodellierung

Bei den verwendeten Methoden haben sich in den letzten 10 Jahren auch wichtige Veränderungen ergeben. Hinzugekommen sind neue, wie die BPMN, weggefallen sind andere, die sich in der Prozessmodellierung nie so recht durchsetzen konnten, wie die Aktivitätsdiagramme der UML. Ereignisgesteuerte Prozessketten bleiben aber das ideale Instrument für die Modellierung von Prozessen im Rahmen der Istanalyse: Sie sind einfach, schnell zu erlernen und liefern trotzdem aussagekräftig Prozessmodelle, was hoffentlich in diesem Buch auch deutlich wird. Mehr kann man von einer Methode nicht verlangen. Strebt man im Rahmen des Requirement Engineering eine programmnahe Modellierung der Prozesse an, sollte man andere Instrumente wählen. Vgl. dazu Kapitel 13.

Ereignisgesteuerte Prozessketten: Ideal für Istanalysen

Josef L. Staud

Inhaltsverzeichnis (der Textversion)

1 Einleitung.. 1

1.1 Modelle, Modellierung. 1

1.2 Aufbau der Arbeit 2

1.3 Anmerkung zur Gestaltung der Grafiken. 3

1.4 Glossar 4

2 Geschäftsprozesse. 5

2.1 Definition. 5

2.2 Eigenschaften und Komponenten. 12

2.2.1 Detaillierungsgrad der Prozessmodellierung. 12

2.2.2 IT-Abdeckung. 12

2.2.3 Automatisierungsgrad. 13

2.2.4 Prozessintegration. 14

2.2.5 Datenintegration. 15

2.2.6 Komponenten. 16

2.3 Ziele der Prozessmodellierung. 17

2.4 Herausforderungen an die Prozessmodellierung. 19

2.4.1 Höhere Detaillierung. 19

2.4.2 Automatisierung - Möglichkeiten und Grenzen. 19

2.4.3 Problemstruktur und Automatisierung. 25

2.4.4 Vertikale Dimension der Prozessmodellierung. 27

2.4.5 Außenwelt und Cloud Computing. 27

3 Grundlagen von Ereignisgesteuerten
Prozessketten. 31

3.1 Einführung. 31

3.2 Elemente. 32

3.3 Funktionen. 32

3.4 Ereignisse. 33

3.5 Organisationseinheiten. 35

3.6 Informationsobjekte. 36

3.7 Kontrollfluss. 37

3.8 Operatoren und Kontrollfluss. 38

3.9 Zeitliche Dimension und Zeitverbrauch. 39

4 Aufbau Ereignisgesteuerter Prozessketten. 41

4.1 Anfrageprüfung Teil 1. 41

4.2 Anfrageprüfung Teil 2. 43

4.3 Anfrageprüfung Teil 3. 46

4.4 Anfrageprüfung Teil 4. 48

4.5 Instanzen. 51

5 Basismuster. 55

5.1 Mögliche Anordnungen. 55

5.2 Ereignisverknüpfung mit auslösenden Ereignissen. 57

5.2.1 UND.. 57

5.2.2 XODER.. 57

5.2.3 ODER.. 58

5.3 Ereignisverknüpfung mit erzeugten Ereignissen. 60

5.3.1 UND.. 60

5.3.2 XODER.. 61

5.3.3 ODER.. 62

5.4 Funktionsverknüpfung mit auslösenden Ereignissen. 64

5.4.1 UND.. 65

5.4.2 XODER - verboten. 66

5.4.3 ODER - verboten. 68

5.5 Funktionsverknüpfung mit erzeugten Ereignissen. 69

5.5.1 UND.. 70

5.5.2 XODER.. 72

5.5.3 ODER.. 72

6 Muster in Geschäftsprozessen. 77

6.1 Entscheidungsfindung. 77

6.2 Teilaufgaben und Tätigkeiten starten. 79

6.3 Zeitfenster 81

6.4 Zeitpunkte. 82

6.5 Bedingungen. 85

6.6 Kombinatorik. 86

6.7 Warten. 89

6.8 Rücksprünge. 91

6.9 Repetitive Handlungen. 96

7 Kontrollfluss bewältigen. 99

7.1 Informationstransport 99

7.2 Zusammenführen von Kontrollflusszweigen. 103

7.3 ODER-Detailanalyse. 107

7.4 Prozesswegweiser 116

7.5 Keine falschen Schlussereignisse. 120

7.6 Organisationseinheiten - unklar 123

7.7 Informationsobjekte - abstrahiert 124

7.8 Pragmatismus. 124

8 Beispiele. 127

8.1 Angebotserstellung. 127

8.2 Auftragsstart 136

8.3 Personalbeschaffung. 144

8.4 Zoo - Tieraufnahme. 148

8.5 WebShop. 153

8.6 Zahlungseingangsüberwachung. 158

9 Zusammenfassung der Syntaxregeln. 165

9.1 Syntaxregeln. 165

9.2 Empfehlungen zur Pragmatik. 167

9.3 Gestaltungsregeln. 168

10 Einschätzungen. 169

10.1 Möglichkeiten der Prozessmodellierung. 169

10.2 Grenzen der Prozessmodellierung. 172

10.3 Gefahren der Prozessmodellierung. 173

10.4 Möglichkeiten und Grenzen von EPKs. 173

11 Andere Methoden. 175

11.1 Geschäftsprozess Auftragsbearbeitung als EPK.. 175

11.2 Business Process Diagrams der BPML.. 177

11.3 Aktivitäten der UML.. 184

12 Vertiefung und Ausblick. 187

12.1 Basiselemente einer Methode zur Prozessmodellierung. 187

12.2 Vertikale Dimension der Prozessmodellierung. 191

12.3 Automatisierung - Systemanalyse und
Prozessmodellierung. 195

12.4 Kontrollfluss vertieft 197

12.5 Prozessmodellierung der Zukunft 198

13 Anhang.. 201

13.1 Das ARIS-Konzept 201

13.2 Glossar 207

13.3 Index. 213

14 Literatur. 219

Abkürzungsverzeichnis

Die Abkürzungen in den Ereignisgesteuerten Prozessketten 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.

Modellierung für Komplexitäts­reduzierung

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 für Programmierung

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 2010a] wo Zustandsautomaten der UML grundsätzlich aber auch in Hinblick auf ihre Eignung für die Prozessmodellierung betrachtet werden, sowie in diesem Buch die Abschnitte 12.3 und 12.4.

1.2 Aufbau der Arbeit

Das Buch soll den Leser Schritt um Schritt in die Modellierung von Geschäftsprozessen mit Ereignisgesteuerten Prozessketten einführen. Entsprechend ist der Aufbau.

• In Kapitel 2 wird das Konzept der Geschäftsprozesseerläutert, soweit es für dieses Buch notwendig ist.
• Kapitel 3 widmet sich den Grundlagen von Ereignisgesteuerten Prozessketten. Es werden alle Elemente erläutert, aus denen EPKs bestehen und das Konzept des Kontrollflusses erläutert.
• In Kapitel 4 wird anhand eines Beispielprozesses der Aufbau Ereignisgesteuerten Prozessketten beschrieben. Das Beispiel enthält die wichtigsten Elemente in typischer Anordnung.
• Die Einführung in den Aufbau von Ereignisgesteuerten Prozessketten wird in Kapitel 5 fortgesetzt mit der Darstellung syntaktischer Basismuster. Vorgestellt werden alle möglichen Verknüpfungen von Ereignissen und Funktionen im Kontrollfluss. Hier steht noch die Syntax im Vordergrund, es wird aber auch bereits auf die Semantik der Fragmente hingewiesen.
• Fragen der Semantik und ihrer Umsetzung in syntaktisch korrekte EPK-Fragmente ("Semantik sucht Syntax") stehen im Mittelpunkt von Kapitel 6. Dazu werden die wichtigsten semantischen Muster, die in Geschäftsprozessen vorkommen, und ihre Umsetzung in Ereignisgesteuerte Prozessketten gezeigt.
• Kapitel 7 geht auf zahlreiche Themen ein, die helfen, den Kontrollfluss besser zu bewältigen. Sie verweisen auf Probleme, die bei der praktischen Modellierungsarbeit auftreten.
• Zahlreiche Beispiele von Ereignisgesteuerten Prozessketten mit unterschiedlichen modellierungstechnischen Schwerpunkten bietet Kapitel 8. Meist wird unterschieden zwischen der ursprünglichen Beschreibung des Geschäftsprozesses und der daraus abgeleiteten Beschreibung der EPK. Hier werden auch Beispiele für die Umsetzung der in Kapitel 6 vorgestellten Muster sowie anderer Strukturmerkmale von Geschäftsprozessen vorgestellt.
• Kapitel 9 enthält eine Zusammenfassung aller syntaktischen und semantischen Regeln und pragmatischen Empfehlungen für die Erstellung von Ereignisgesteuerten Prozessketten.
• Eine grundsätzliche Einschätzung der Prozessorientierung und der Methode EPK enthält Kapitel 10.
• In Kapitel 11 erfolgt eine kurze Darstellung der zwei wichtigsten anderen Methoden zur Prozessmodellierung, der BPDs der Methode BPMN und der Aktivitäten der UML. Dazu wird auch ein kleiner Prozess in allen drei Methoden modelliert.
• Die Ausführungen in Kapitel 12 widmen sich vertiefenden und in die Zukunft weisenden Fragen rund um die Prozessmodellierung. Zu den vertiefenden gehört eine Darstellung der Basiselemente, die jede Methode zur Prozessmodellierung aufweisen muss und eine Betrachtung der vertikalen Dimension der Prozessmodellierung. Zum Ausblick gehören Überlegungen, wie eine Prozessmodellierung der Zukunft aussehen könnte.
• Wegen seiner großen Bedeutung für die Methode EPK wird im Anhang kurz das ARIS-Konzept von Scheer vorgestellt. Es ist trotz seines Alters immer noch ein elementares Grundmuster für die Gestaltung der IT, die Analyse von Geschäftsprozessen und die Erstellung von Ereignisgesteuerten Prozessketten.

1.3 Anmerkung zur Gestaltung der Grafiken

Folgende Regeln werden in diesem Buch bei der Gestaltung der EPKs und bei der Wiedergabe langer Abbildungen beachtet:

• Wenn die Organisationseinheiten bei einer nachfolgenden Funktion gleich bleiben wie bei der vorigen, werden sie nicht angegeben. Dies dient der Übersichtlichkeit. Falls also bei einer Funktion keine Organisationseinheiten angegeben sind, muss flussaufwärts bis zur ersten Funktion mit einer solchen Angabe geschaut werden. In vollem Umfang ist dies hier, um die Aussagekraft der entsprechenden EPK zu erhöhen, nicht realisiert. Falls also die Situation unübersichtlich ist oder falls die letzte mit einer Organisationseinheit versehene Funktion weit "oben" flussaufwärts liegt, werden trotzdem Organisationseinheiten angefügt.
• Bei Informationsobjekten, die nur transportiert und nicht erzeugt oder gelesen werden, sind in den Ereignisgesteuerten Prozessketten keine Pfeilspitzen angegeben. Dies ist eine Festlegung des Autors, die dazu dienen soll, Transportvorgänge von Informationen besser zu erkennen. Vgl. dazu auch Abschnitt 7.1.
• Einzelne Ereignisgesteuerte Prozessketten in diesem Kapitel erstrecken sich über mehrere Seiten. Dazu werden jeweils die Kontrollflusszweige am unteren Ende auf der folgenden Seite ohne spezielle Markierung weitergeführt. Um den Zusammenhang zu verdeutlichen, wird das letzte Element der vorangehenden EPK in der nachfolgenden wiederholt. Falls Rückschleifen auf eine vorangehende Seite zurückgeführt werden müssen, werden sie besonders gekennzeichnet.
• Es ist in vielen Unternehmen inzwischen üblich, bei einer einfachen (nichtverzweigten) Abfolge von Ereignissen und Funktionen, die Ereignisse wegzulassen. Dies wird hier - wo ja die Wissensvermittlung zur Methode EPK im Vordergrund steht und die Ereignisgesteuerten Prozessketten (EPKs) auch nicht so groß werden wie in Unternehmensprojekten, nicht umgesetzt. Ein Beispiel wird aber angegeben, es befindet findet sich in Abschnitt 6.3.

1.4 Glossar

Begriffe, die zwar verwendet werden, aber nicht zum eigentlichen Themenbereich des Buches gehören, werden im Glossarium (Abschnitt 13.2) erläutert. Die Kennzeichnung im Text erfolgt durch einen Pfeil (=>) vor dem entsprechenden Begriff.

2 Geschäftsprozesse

2.1 Definition

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.

Zielgerichtetes Handeln

Aufgaben

Tätigkeiten sind in der Regel als Aufgabendefiniert, die auf unterschiedlichen Ebenen betrachtet werden können. Sozusagen die unterste Ebene stellen die Elementaraufgabendar. 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]:

Elementaraufgaben,
Aufgaben

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

Definition

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 Aggregationgenannt. Damit wird deutlich, was dann bei der konkreten Modellierung von Geschäftsprozessen eine wichtige Rolle spielt:

Aggregation: Tätigkeiten zusammenfassen, u.U. in mehreren Schritten.

Die in Geschäftsprozessen zu leistenden Aufgaben können auf unterschiedlichen Aggregationsniveausbetrachtet werden. Man kann in der Prozessmodellierung Aufgaben also aufteilen 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, hierzu mehr in Abschnitt 12.2.

Subjektives Aggregationsniveau

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.

Subjektive Länge

Funktionen

In der Prozessdiskussion wie auch in der konkreten Prozessmodellierung wird mit Funktionein 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]

In den Ereignisgesteuerten Prozessketten werden die einzelnen Tätigkeiten als Funktionen bezeichnet, unabhängig vom Aggregationsniveau [Anmerkung] .

Mit Objekten sind hier betriebswirtschaftlich relevante Objekte bzw. Geschäftsobjektegemeint. 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.

Betriebswirtschaftlich
relevante Objekte

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

Sequenzielle
Aufgabenfolge

"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.
• 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 Vorgangwie folgt definiert:

[Bullinger und Fähnrich 1997, S. 19]

"Ein Vorgang ist ein zeitverbrauchendes Geschehen, das durch ein Start­ereignis 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 1998a, S. 20]

Definition

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:

Ein Geschäftsprozess besteht aus einer zusammenhängenden, abgeschlossenen Folge von Tätigkeiten, die zur Erfüllung eines Organisationsziels notwendig sind.

Definition

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 [Anmerkung] der Organisation.

Ergänzt wurde die Anwendungsprogramme als Aufgabenträger. Dies ist in einer Zeit zunehmender Automatisierung von Geschäftsprozessen unabdingbar (vgl. hierzu Abschnitt 12.3). 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.

Durch Anwendungs­
programme zur teilweisen oder ganzen Automatisierung

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

Elemente einer Modellierungstheorie

• Einzelne Tätigkeiten, aus denen der Geschäftsprozess zusammengesetzt ist.
• Der Zusammenhang zwischen diesen, er wird später Kontrollfluss 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]

Definition

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:

1. Geschäftsprozesse haben ein Ziel oder auch mehrere, abgeleitet aus den Organisationszielen.

2. Die Gesamtaufgabe eines Geschäftsprozesses kann in Teilaufgaben zerlegt werden (im Extremfall kann ein Geschäftsprozess auch aus nur einer Aufgabe bestehen).

3. 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.

4. Die Aufgaben werden entweder manuell, teilautomatisiert oder voll automatisiert erfüllt.

5. Ein Geschäftsprozess liegt in der Regel quer zur klassischen Aufbauorganisation, d.h. er tangiert meist mehrere Abteilungen.

6. Für die Erfüllung der Aufgaben werden die Unternehmensressourcen benötigt.

7. Geschäftsprozesse benötigen zu ihrer Realisierung Informationsträger aller Art.

Das gibt weitere Hinweise. 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.

Weitere Elemente einer Modellierungstheorie

Rump unterscheidet in [Rump 1999, S. 19f] zusätzlich Geschäftsprozess von Geschäftsprozessinstanz und Geschäftsprozessschema, wohl in Anlehnung an objektorientierte Modellierungskonzepte. Dabei steht dann Geschäftsprozessinstanz für eine konkrete Realisierung eines Geschäftsprozesses und Geschäftsprozessschema für ein Modell, das von einem Geschäftsprozess für alle seine denkbaren Realisierungen erstellt wurde (wie hier unten z.B. mit Ereignisgesteuerten Prozessketten) (vgl. [Rump 1999, S. 20], insbesondere Abbildung 2.1). Diese Unterscheidung macht deutlich, dass die Geschäftsprozessmodellierung tatsächlich beides erbringt (erbringen muss). Den Rahmen für alle denkbaren (vorgedachten) Kontrollflüsse und die Darstellung einzelner konkreter Durchgänge. Auch dies wurde hier übernommen.

Geschäftsprozess,
Instanz und Schema

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

Nicht nur in der Wirtschaft

Ü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 sinnvoll. 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, auch wenn dort meist [Anmerkung] nicht Wertschöpfung, sondern Einsparung bzw. möglichst effiziente Realisierung der Geschäftsprozesse das Thema ist.

Ort, an dem Geschäftsprozesse stattfinden

Deshalb ist hier von Organisationenund von Organisationszielen die Rede sein, wenn es um den Ort geht, wo Geschäftsprozesse realisiert werden. Geschäftsprozesse sind dann die zusammenhängenden Folgen von Tätigkeiten, die in Organisationen aller Art zur Erreichung der Organisationsziele erledigt werden.

Organisationsziele erreichen durch Geschäftsprozesse

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.

Von Stellen und ihren Aufgaben zu Prozessen

Beispiele

Hier nun noch einige Beispielefü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.2 Eigenschaften und Komponenten

Es gibt natürlich sehr viele betrachtenswerte Eigenschaften von Geschäftsprozessen und Prozessmodellen, vgl. dazu die einschlägige Literatur . Hier konzentrieren wir uns auf die wichtigsten, das sind auch diejenigen, die am meisten Bedeutung für die Prozessmodellierung haben.

2.2.1 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.

Umfassende, teilweise, gar keine Detaillierung"

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 oder auch bei Unternehmen, dass zumindest Komplexität keine Hindernis für eine detaillierte Modellierung und Umsetzung in Software ist.

Detaillierte Modellierung nur bei standardisierten Geschäftsprozessen

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 Handlungen nicht mehr darstellbar sind, ist der Detaillierungsgrad niedrig.

Erfassung des Detaillierungsgrades der Prozessmodellierung

2.2.2 IT-Abdeckung

Mit dieser Eigenschaft wird erfasst, welcher Anteil des Prozesses durch IT unterstützt wird. 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 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.

Unterstützung durch IT, meist durch eine prozessorientierte integrierte Standardsoftware
(ERP-Software)

Alles in allem ist die IT-Abdeckung heute, 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 Informationsobjekte erkannt werden. Bei IT-Abdeckung sind diese Teil des Datenbestandes einer Anwendungssoftware und (hoffentlich) als solche gekennzeichnet.

Erfassung der IT-Unterstützung in der Prozessmodellierung

Voraussetzung für eine IT-Abdeckung ist allerdings wie oben angemerkt eine 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(vgl. Abschnitt 12.1 und das Stichwortverzeichnis). Danach können dann diese elementaren Funktionen in einer noch detaillierteren Ebene in Programmkonstrukte abgebildet werden.

Voraussetzung: detaillierte Modellierung

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

2.2.3 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".

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 2010a, Kapitel 13]).

Unterstützung vs. Automatisierung

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.

Erfassung der Automatisierung in der Prozessmodellierung

Betrachtet man z.B. die Geschäftsprozesse eines typischen Internetunternehmens im B2C [Anmerkung] , 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 Prozessmodellierunggenannt. 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 sowie [Staud 2010a] für die dann einzusetzenden Methoden der UML.

Definition:
Programmnahe Prozessmodellierung

2.2.4 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, man spricht dann von Medienbrüchen , 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 Informationstransports. Vgl. dazu Abschnitt 7.1.

Medienbrüche

Weitere Beispiele für Medienbrüche:

• Ausgabe von Information in der einen Software, händische Eingabe bei der nächsten.
• Eingehende Information ("Auftragseingang") muss bearbeitet werden, um sie in die eigene Anwendungssoftware zu bringen.
• Für eine Prognoserechnung können Informationen 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 Informationsobjekte 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 Transportvorgang 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 musste z.B. die Rechnung neu eingegeben , gescannt, usw. werden. Dies stellt den Medienbruch dar, der ausdrücklich modelliert werden sollte.

Erhebung von Medienbrüchen

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

Semantische Prozessintegration

2.2.5 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 ...

"Reibungsverluste" durch Nichtintegration

• ... 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 sind 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.

Quelle

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] .

Erkennen nicht ausreichender Datenintegration

2.2.6 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] :

• 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, vor allem in den Daten, neu ergeben)
• 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
• Informationsobjekte

Dies sind dann auch die Elemente, mit denen die Methode EPK auskommt und die wir in den folgenden Kapiteln vorstellen. In Abschnitt 12.1 erfolgt diesbezüglich ein Abgleich mit Basiselementen einer jeden Prozessmodellierung.

Zustand? (siehe oben)

Diese Bezeichnung sorgt oft für Verwirrung in den Seminaren. Deshalb nochmals ganz klar: Es geht um die Zustände der Daten, die sich im Prozessablauf ständig verändern - im Prinzip nach jeder Funktion. Also nach einem Auftragseingang, nach Fertigstellung einer Kalkulation, usw.

2.3 Ziele der Prozessmodellierung

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:

Istanalyse

Eine Istanalyse ist die Bestandsaufnahmeeines bestehenden Prozesse mit all seinen Merkmalen und Defiziten.

Definition

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:

Schwachstellen beseitigen durch Optimierung

1. fehlende Datenintegration, d.h. Dateninseln

2. fehlende Prozessintegration, d.h. Organisationsbrüche

3. zu lange Transportzeiten von Prozessobjekten (Dokumente, Rechnungen, CAD-Zeichnungen, usw.; im Bürobereich ganz allgemein von Vorgängen),

4. zu lange Warte- und Liegezeiten von Prozessobjekten

5. zu lange Bearbeitungszeit

6. zu lange Rüst- und Durchlaufzeiten

7. redundante Tätigkeiten

8. zu hohe Komplexität (konkret: zu hoher Dispositions- und Verwaltungsaufwand)

9. unzureichendes Prozessdenken (konkret: unzureichendes Verständnis für vor- und nachgelagerte Prozessabschnitte bei den Beteiligten)

10. zu lange Kommunikations- und Entscheidungswege

11. zu hohe Gesamtkosten der Prozesse

12. zu wenig Transparenz, was u.U. auch die Veränderung von Geschäftsprozessen behindert

13. unzulängliche Prozessverantwortlichkeit

14. 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.

Prozessmodellierung mit speziellem Ziel

Beispiel Auftragsabwicklung in [Staud 2006]

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

Einsatzzwecke von Prozessmodellen

• 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].

2.4 Herausforderungen an die Prozessmodellierung

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

2.4.1 Höhere Detaillierung

Wir haben es schon oben bei den Eigenschaften von Geschäftsprozessen thematisiert. Es 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 (vgl. [Staud, 2006, Kapitel 2]). 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.

Immer detailliertere Prozessmodelle

Vgl. auch Abschnitt 2.2

Dieser Trend erfordert eine veränderte Prozessmodellierung. Die klassische Istanalyse muss ergänzt werden durch eine programmnahe Prozessmodellierung. Vgl. dazu Abschnitt 12.5.

2.4.2 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 durch Anwendungssoftware realisiert und darüber hinaus die nachfolgenden in Logistik und Finanzwesen.

Geschäftstätigkeit mit Hilfe des Internet ..

... mit voll automatisierten Geschäftsprozessen.

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, basierende auf einer sehr detaillierten Modellierung der Geschäftsprozesse, teilweise automatisiert, teilweise nicht. Deshalb konnte oben der Anteil automatisierter Abschnitte als Eigenschaft eingeführt werden.

Teils, Teils.

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 die Abschnitte 12.3 und 12.5.

Voraussetzungen

Automatisierungsmöglichkeiten

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"):

Welche Prozessabschnitte können automatisiert werden?

• Operative Systeme mit den Teilsystemen Administrationssystemeund 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.

Operative Systeme

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

Definition

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.

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

Definition

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

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

Definition

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 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".

Wertorientierte Abrechnungssysteme 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.

Wertorientierte Abrechnungssysteme

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

Definition

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).

Berichtssysteme

Das Automatisierungspotentialist 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 ...

Planungssysteme

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

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

Kontrollsystemedienen 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.

Kontrollsysteme

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. Abschnitt 2.4.3).

Ähnlich wie oben ist das Automatisierungspotentialhier 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.

Analysesysteme

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

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).

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

Definition

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.

Pyramidenaufbau

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.

Vertikale Prozesse

Abbildung 2.4-1: Das Automatisierungspotential in den Betrieblichen Anwendungssystemen

2.4.3 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.

Mehr oder weniger unstrukturiert

Probleme und Problemstrukturen

Problemlösung geschieht in folgenden Phasen:

Lösungswege

1. Problemerkennung

2. Alternativengenerierung

3. Alternativenauswahl

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 Problemempfunden, 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 geltenProbleme, 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 einProblemempfunden, 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.

Problemstruktur und Betriebliche Anwendungssysteme

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

2.4.4 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. Abschnitt 12.2 sowie - ausführlicher - [Staud 2010a, Kapitel 14 und 15]).

Mehr oder weniger aggregierte Einzelaktivitäten

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

2.4.5 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" wird, 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.

Informationelle Umwelt

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.

Mehrere IT-Träger und ihre Verknüpfung

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. Heutzutage ist dafür auch eine entsprechende Prozessmodellierung notwendig.

WebServices

Abbildung 2.4-2: 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 Informationsobjekte (Datenbestände) angeht.

Cloud Computing
Weitere Schnittstellen

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.

Desintegration

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 2.4-3: Neue Cloud-Schnittstellen und ihre Bewältigung durch die Prozessmodellierung

3 Grundlagen von Ereignisgesteuerten Prozessketten

3.1 Einführung

Ereignisgesteuerte Prozessketten (EPKs) beschreiben Geschäftsprozesse, ihre Tätigkeiten (Funktionen genannt), die sie steuernden Ereignisse, die Handelnden (Organisationseinheiten genannt) und die benutzten oder erzeugten Informationen (Informationsobjekte genannt). Sie beschreiben alle möglichen Realisierungen des Prozesses mit Hilfe von Verzweigungen und Zusammenführungen (Operatoren, Konnektoren) und geben damit den sog. Kontrollflussdes Geschäftsprozesses an.

Methode EPK

Sie sind das Werkzeug für die Analyse und Beschreibung von Geschäftsprozessen. Dies gilt v.a. für (à)Istanalysen von Geschäftsprozessen und für die Darstellung optimierter Prozesse (àSollmodellierung). Nur wenn die Modellierung auf eine Ebene mit höherem Detaillierungsgrad zielt, z.B. zu Vorbereitung der Programmierung einer prozessorientierten Software, sind andere Modellierungsmethoden besser geeignet (vgl. die Abschnitte 12.2 und 12.5).

Istanalysen und Sollmodellierung

Diese Methode und die zugehörige grafische Beschreibungstechnik (Notation) für Geschäftsprozesse wurde von Scheer und seinen Mitarbeitern im Rahmen ihres ARIS-Konzepts (vgl. für eine Kurzdarstellung Abschnitt 13.1) entwickelt (vgl. [Keller, Nüttgens und Scheer 1992], [Scheer 1997]).

ARIS
Architektur integrierter Informationssysteme

Ereignisgesteuerte Prozessketten sind eine semi-formale Methode. Sie genügen nicht den Ansprüchen (wie auch im Weiteren zu sehen sein wird), die an formale Methoden bzw. Sprachen gestellt werden müssen. So auch Rosemann in seinem Beitrag in [Mertens u.a. 1997, S. 334], wo er

informal
semi-formal
formal

• informale, z.B. textliche Beschreibungen,
• semi-formale, z.B. Ereignisgesteuerte Prozessketten,

und

• formale Methoden, wie z.B. die Prädikatenlogik

unterscheidet.

Auch die dort angeführten Forderungen an eine solche Methode, Darstellung des Kontrollflusses, Abbildung von Nebenläufigkeit [Anmerkung] , von bedingten Verzweigungen und von Schleifen, die Wiedergabe des Datenflusses sowie die Angabe der involvierten Organisationseinheiten und Informationssysteme erfüllen Ereignisgesteuerte Prozessketten ohne weiteres.

Einen Ansatz zur Formalisierung von Ereignisgesteuerten Prozessketten stellt Rump in [Rump 1999] vor. Dort finden sich auch Hinweise auf die Formalisierungsbemühungen von Chen und Scheer (vgl. [Chen und Scheer 1994]) sowie Langner, Schneider und Wehler (vgl. [Langner, Schneider und Wehler 1997a und 1997b]).

Formale Darstellung

Trotz des nicht voll formalen Charakters dieser Notation soll hier auch von Syntax gesprochen werden, wenn die Regeln für den korrekten Aufbau der Ereignisgesteuerten Prozessketten gemeint sind.

Syntax

3.2 Elemente

In Abschnitt 2.2.6 wurden die Elemente von Geschäftsprozessen genannt, die [Scheer 1997] bei der Herleitung des ARIS-Konzepts identifiziert. Diese fasst er bei der konkreten Ausformulierung des EPK-Ansatzes zu Folgenden zusammen:

4 Elemente + Kontrollfluss

• Funktionen
• Ereignisse
• Organisationseinheiten und
• Informationsobjekte

Außerdem werden der Kontrollfluss und - eingeschränkt - der Datenfluss berücksichtigt.

3.3 Funktionen

Alle Tätigkeiten, die in einem Geschäftsprozesse zu leisten sind, werden im Rahmen der Prozessmodellierung als Funktionen in einer EPK erfasst. D.h., die Gesamtaufgabe des Geschäftsprozesses (z.B. Kalkulation erstellen) wird in einzelne Teilaufgaben unterteilt, mehr oder weniger detailliert. Die Festlegung, welchen Umfang an elementaren Tätigkeiten die einzelne ausgewiesene Funktion hat, bleibt dem Modellierer überlassen. Der in Abschnitt 2.2.1 diesbezüglich diskutierte subjektive Faktor der Modellierung bleibt also erhalten.

Was wird geleistet?

Funktionen beschreiben bei Menschen deren operative Tätigkeit, bei einem Informationssystem so etwas wie eine Transaktion bzw. einen betriebswirtschaftlichen Funktionsbaustein.

Der Zeitverbrauchfür die Funktionen wird in diesem Modellierungsansatz nicht quantifiziert. Es wird also nicht angegeben, wie viel Zeit (höchstens/mindestens) benötigt wird, um die in der Funktion erfassten Tätigkeiten durchzuführen. Dagegen ist die zeitliche Dimension eines Geschäftsprozesses in vielfacher Form in diesen Modellierungsansatz integriert. Vgl. dazu die Abschnitte 6.3, 6.4.

Zeitverbrauch

Die grafische Darstellung von Funktionen geschieht durch ein Rechteck mit abgerundeten Ecken und einer Beschriftung in der Mitte des Rechtecks. Vgl. die folgende Abbildung.

Abbildung 3.3-1: Funktionen - grafische Darstellung

Die Benennung von Funktionensollte so erfolgen, dass die Tätigkeit klar erkennbar ist, am besten durch die Kombination von Substantiv und Verb. Also zum Beispiel:

• Machbarkeit prüfen oder Machbarkeitsprüfung
• Kalkulation erstellen
• Auftrag ablehnen

3.4 Ereignisse

Unter Ereignissen werden hier betriebswirtschaftlich relevante Ereignisse verstanden. Diese Ereignisse beeinflussen und steuern auf die eine oder andere Weise die Abläufe im Unternehmen. Einige Beispiele dafür sind:

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

Die Benennung von Ereignissensollte genau so wie in diesen Beispielen erfolgen, als aussagenlogischer Ausdruck. Das macht den Ereignischarakter klar.

Steuerung durch Ereignisse

Zur Definition von Ereignissen in der Prozessmodellierung können wir auf den umgangssprachlichen Ereignisbegriff zurückgreifen, allerdings mit der Ergänzung, dass es sich um betriebswirtschaftlich relevante Ereignisse handeln muss, die für den betrachteten Geschäftsprozess Bedeutung haben.

Etwas enger gefasst wird diese Definition dadurch, dass in der Prozessmodellierung eine enge Beziehung zwischen Funktionen und Ereignissen gesehen wird. Die Durchführung einer Funktion führt zum Beispiel immer zu einem Ereignis ("erledigt") oder zu mehreren.

Funktion - Ereignis - ...

Ereignisse sind auf einen bestimmten Zeitpunkt bezogen. Dieser wird allerdings in der Regel nicht spezifiziert. Er wird in den gängigen Darstellungen nur dadurch festgelegt, dass ein Ereignis in eine Kette von Handlungen (Funktionen) und Ereignissen (ein Zweig des Kontrollflusses) eingebettet wird. Mit anderen Worten: Ereignisse lösen Funktionen aus und sind deren Ergebnis. Dies ist der Grund, weshalb Scheer schreibt:

Auf Zeitpunkte bezogen

"Ein Ereignis kann als Auftreten eines Objekts oder Änderung einer bestimmten Attributsausprägung definiert werden." [Scheer 1998, S. 49]

Wobei er hier mit Objekten z.B. Produkte meint. Ereignisse in diesem Sinn können sich aus vorangegangenen Tätigkeiten sozusagen als Beschreibung der möglichen Ergebnisse ergeben, sie können aber auch auf die nächsten Arbeitsschritte verweisen oder - quasi aus heiterem Himmel - von außen kommen ("IT wurde gehackt", "Auftrag ist eingegangen").

Die Menge aller in einem Unternehmen und seinem Umfeld möglichen Ereignisse sollen als der Ereignisraumdes Unternehmens bezeichnet werden.

Ereignisraum

Ein Ereignis ist immer auch eine Feststellung, die irgendwie und von irgendjemandem getroffen werden muss. Ihm gehen Handlungen voraus und meistens folgen auch welche nach. Diese werden hier mit dem oben schon eingeführten Begriff der Funktionen erfasst.

Ereignisse können, wie Funktionen, zusammengefasst oder auch zerlegt werden.Nehmen wir das bewusst "hoch" angesiedelte Ereignis "Unternehmen hat keine Gewinne erwirtschaftet." Dies könnte genauso gut durch die "Ereignisse" "Absatz ging um x% zurück", "Kosten lagen bei y DM", usw. beschrieben werden. Grundsätzlich müssen sich die Ereignisse diesbezüglich an den Funktionen (an deren Aggregationsniveau) orientieren.

Aggregation:
Zusammenfassung von Funktionen

Zwei Ereignisse eines jeden Geschäftsprozesses verdienen hervorgeho­ben zu werden: das Startereignisund das Endereignis(oder Schlussereignis). Mit dem Startereignis beginnt ein Geschäftsprozess (davor liegen, bezogen auf den einzelnen Geschäftsprozess, keine Handlungen), mit dem Endereignis findet er seinen Abschluss. Grundsätzlich können auch mehrere Start- und mehrere Endereignisse vorliegen.

Anfang und Ende

Die grafische Darstellung von Ereignissen in Ereignisgesteuerten Prozessketten erfolgt als ein die Breite gezogenes Sechseck mit der Benennung des Ereignisses in der Mitte des Sechsecks.

Abbildung 3.4-1: Ereignisse - grafische Darstellung

3.5 Organisationseinheiten

Mithilfe der Organisationseinheitenwird festgehalten, wer die in einer Funktion erfasste Aufgabe tätigt. Dazu kann man die Abteilung usw. angeben (so ist die klassische Lösung) oder die Anwendungssoftware, die automatisiert die Funktion realisiert. Geht es um durch Menschen realisierte Funktionen wird man heute, v.a. wenn der Personalbestand schon sehr niedrig ist und/oder sich das Unternehmen von der klassischen Aufbauorganisation wegbewegt, die Organisationseinheiten sehr klein fassen, evtl. sogar auf Stellenebene gehen, um genügend Aussagekraft für die Analyse der Schwachstellen zu erhalten. Beispiele für (klassische) Organisationseinheiten in einem Industrieunternehmen sind Vertrieb, Personalwesen, Werk, Informationsvermittlungsstelle.

Wer erfüllt die Aufgabe?
In welcher Organisationseinheit wird die Aufgabe erfüllt?

Die grafische Darstellung von Organisationseinheiten in Ereignisgesteuerten Prozessketten erfolgte durch eine in der Mitte beschriftete Ellipse. Organisationseinheiten sind immer durch eine richtungslose Verbindungslinie mit der Funktion verbunden, die realisiert wird.

Abbildung 3.5-1: Organisationseinheiten und ihre Anbindung an Funktionen

Gestaltungsregel: Organisationseinheiten

Es hat sich eingebürgert, die Organisationseinheiten bei nachfolgenden Funktionen wegzulassen, wenn sie gleich sind wie bei der vorigen. Findet man also bei einer Funktion keine Organisationseinheit(en), muss man flussaufwärts bis zum letzten Vorkommen schauen.

In Abschnitt 7.6 wird auf einige Probleme bei der Festlegung der Organisationseinheiten eingegangen.

3.6 Informationsobjekte

Keine Organisation kommt ohne Datenbestände aus, die das Unternehmen selbst, seine Geschäftsobjekteund seine informationelle Umwelt ganz oder in Ausschnitten modellieren. Diese Datenbestände sind damit auch für die Abwicklung der Geschäftsprozesse von großer Bedeutung.

Welche Informationen werden bei einer Funktion benötigt? Welche entstehen?

In Ereignisgesteuerten Prozessketten schlägt sich dies so nieder, dass bei den Funktionen die jeweils geholten und benutzten bzw. entstehenden Informationen angegeben werden. Dies können Kundendaten, die Angaben des früher erstellten Angebots, aktuelle Marktpreise oder eine andere Information sein, die für irgendeinen Abschnitt des Geschäftsprozesses Bedeutung besitzt.

In der Methode EPK werden solche Daten als Informationsobjektebezeichnet und in Verbindung gesetzt mit der Funktion, für die sie benötigt werden. Dann werden z.B. einer Funktion Auftragsbearbeitung folgende Informationen zugeordnet:

Informationsobjekte zur Unterstützung der Geschäftsprozesse

• zu Kunden
• zum Angebot
• zu den Materialien
• zu den Konditionen
• zum Kundenauftrag
• zum Bedarf an Teilen, usw.

Die grafische Darstellung von Informationsobjekten erfolgt als Rechteck mit der Benennung in der Mitte. Jedes Informationsobjekt ist mit einer Funktion verbunden. Bei dieser Beziehung zwischen Informationsobjekten und Funktionen wird mittels einer Pfeilspitze unterschieden, ob die Informationen einfließen, d.h. im Rahmen der Aufgabenerledigung benötigt werden, oder ob sie dabei entstehen. Die Pfeilspitze drückt die Richtung des Informationsflusses aus.

Rechteck mit Pfeillinie

Abbildung 3.6-1: Informationsobjekte und ihre Anbindung an Funktionen

Wie im Folgenden zu sehen ist, werden damit Datenflüsse (im Sinne der Datenflussdiagramme) nur erfasst, wenn dieser Teil der Modellierung sehr sorgfältig geschieht, was in der Praxis oft nicht der Fall ist.

Informationsobjekte können nicht nur aus Daten von Datenbanken bestehen. Grundsätzlich kann jede Information auf jedem Informationsträgerberücksichtigt werden. Der Hinweis auf nicht elektronische Träger (bei einer Istanalyse) kann sogar ein erster Hinweis auf Möglichkeiten zur Optimierung des Geschäftsprozesses sein.

Informationsträger aller Art

Grundsätzlich geben die Informationsobjekte auch Hinweise auf den Automatisierungsgraddes betrachteten Geschäftsprozesses. In nicht oder nur teilweise automatisierten Abschnitten werden die Informationsobjekte oftmals (aber nicht immer!) nicht digital sein.

Informationsobjekte und Automatisierungsgrad

3.7 Kontrollfluss

In der Einleitung zu diesem Kapitel wurde schon das Konstrukt [Anmerkung] eines Kontrollflusseseingeführt. Jetzt kann es präzisiert werden. Die in einem Geschäftsprozess möglichen Abfolgen von Ereignissen und Funktionen, beginnend mit Startereignissen und endend mit Schlussereignissen, werden Kontrollflussgenannt.

Kontrollfluss: Die unsichtbare, ordnende Hand

Ein einzelner konkreter Durchgang durch den Prozess wird mit Instanzbezeichnet [Anmerkung] . Damit könnte man auch den Kon­trollfluss als die Gesamtheit aller möglichen Instanzen des Geschäftsprozesses bezeichnen. Mehr zu Instanzen und vor allem Beispiele finden sich in Abschnitt 4.5.

Instanzen eines Geschäftsprozesses

Gedacht ist mit Kontrollfluss also an alle möglichen Durchgänge durch den Geschäftsprozess, einschließlich aller Verzweigungen, so wie sie die Semantik des Geschäftsprozesses erfordert. Hier äußern sich die Geschäftsregeln(business rules), aber auch der "gesunde Menschenverstand" (ein Angebot muss erst geschrieben werden, bevor es verschickt werden kann).

Die im Kontrollfluss nacheinander folgenden Ereignisse und Funktionen werden durch Pfeillinien verbunden. Mehr dazu in den folgenden Kapiteln. Diese Pfeillinien werden oft auch Kantengenannt, in Anlehnung an die Begrifflichkeit der Graphentheorie. Mehrere solche Kanten mit ihren Ereignissen und Funktionen stellen einen Kontrollflusszweigdar. Dieser kann von einem Startereignis bis zu einem Endereignis reichen.

Kanten,
Kontrollflusszweige

Geschäftsprozesse und damit auch Ereignisgesteuerte Prozessketten haben eine Richtung, vom Startereignis zum Schlussereignis, weshalb auch von flussaufwärts(zurück Richtung Startereignis) und flussabwärts(Richtung Schlussereignis) gesprochen werden kann.

Weitere vertiefende Anmerkungen zum Kontrollfluss finden sich in Abschnitt 12.4.

3.8 Operatoren und Kontrollfluss

Der Kontrollfluss eines Geschäftsprozesses besteht nicht nur aus einfachen Abfolgen von Ereignissen und Funktionen, sondern auch aus Verzweigungenvon Kon­trollflusszweigen und aus Zusammenführungen. Zum Beispiel, wenn mehrere Tätigkeiten "parallel" erledigt werden müssen, um ein Ziel zu erreichen. Oder wenn es Alternativen gibt: Entweder die eine oder die andere Tätigkeit führt zum Ziel. Genauso mit Ereignissen. Manchmal können alternative Ereignisse dieselbe Tätigkeit auslösen oder mehrere Ereignisse zusammen die Bedingung sein für den Beginn einer Tätigkeit. Für dieses Strukturmerkmal von Geschäftsprozessen und Ereignisgesteuerten Prozessketten werden Operatoren(manchmal auch Konnektoren genannt) benötigt.

Operatoren, Konnektoren

Für die Modellierung von Geschäftsprozessen durch EPKs genügen drei solche Operatoren. Hier die Bezeichnungen mit den grafischen Symbolen:

• UND:
• ODER:
• exklusives ODER (auch XODER):

Es sind mehrstellige logische Operatoren, d.h. es werden immer mindestens zwei Elemente verknüpft. Dabei gilt: Entweder werden Ereignisse mit Ereignissen oder Funktionen mit Funktionen verknüpft.

Hinweis

Die Operatoren können nur Ereignisse mit Ereignissen und Funktionen mit Funktionen verknüpfen, nicht Ereignisse mit Funktionen.

Verknüpfte Ereignisse

Zahlreiche Beispiele mit elementaren Verknüpfungen folgen in Kapitel 5

Für Ereignisse haben die Verknüpfungen folgende Bedeutung:

• UND: alle verknüpften Ereignisse müssen eintreten, erst dann geht es im Kontrollfluss weiter
• ODER: mindestens eines der verknüpften Ereignisse muss eintreten, erst dann geht es im Kontrollfluss weiter
• XODER: genau eines der verknüpften Ereignisse muss eintreten, erst dann geht es im Kontrollfluss weiter

Verknüpfte Funktionen

Für Funktionen haben sie folgende Bedeutung:

• UND: alle verknüpften Funktionen müssen getätigt werden, erst dann geht es im Kontrollfluss weiter
• ODER: mindestens eine der verknüpften Funktionen muss getätigt werden, erst dann geht es im Kontrollfluss weiter
• XODER: genau eine der verknüpften Funktionen muss getätigt werden, erst dann geht es im Kontrollfluss weiter

Eine genauere Bestimmung der Bedeutung der Operatoren hängt von der Stellung im Kontrollfluss ab. Davon, ob z.B. die verknüpften Ereignisse vor oder nach einer Funktion stehen. Vgl. hierzu die Verknüpfungsbeispiele in Kapitel 5.

In den grafischen Darstellungen geht man bei Ereignisgesteuerten Prozessketten meist von der Festlegung aus, dass der Kontrollflussder Übersichtlichkeit halber von oben nach unten angeordnet wird. Deshalb werden die Operatoren in der grafischen Notation in einem zweigeteilten Kreis platziert, z.B. so:

Dort wo ein Operator ist, ist dann mehr als eine Kante, liegt kein Operator vor, geht es nur eine einzige Kante. Liegen oben und unten mehr als eine Kante vor, müssen auf beiden Seiten Operatoren vorhanden sein. Hier zwei Beispiele.

Die obere Hälfte gibt an, wie die durch die "ankommenden" Kontrollflüsse repräsentierten Ereignisse oder Funktionen verknüpft sind. Die untere Hälfte leistet dasselbe für die weggehenden Kanten.

Syntaxregel

Das Verzweigen und Zusammenführen von Kontrollflusszweigen kann nur über Operatoren erfolgen.

Zwei zusätzliche Begriffe sollen bezüglich der Operatoren noch unterschieden werden: Verteilerund Verknüpfer. Kommt ein Zweig an und gehen mehrere weg, wird der Operator als Verteiler bezeichnet. Fließen umgekehrt mehrere hinein und nur einer heraus, handelt es sich um einen Verknüpfer.

Verteiler und Verknüpfer

3.9 Zeitliche Dimension und Zeitverbrauch

In der Abfolge der Funktionen in einem Kontrollflusszweig drückt sich dann auch eine zeitliche Dimensionaus. Die Prüfung Lagerbestand kann erst dann aktiviert werden, wenn das Ereignis Anfrage eingetroffen eingetreten ist, die Funktion Kunde absagen nur, wenn vorher das Ereignis Lagerbestand reicht nicht eintrat, usw. Mit anderen Worten: Eine Funktion wird erst begonnen, wenn die vorherige abgeschlossen ist.

Zeitliche Dimension eines Geschäftsprozesses bzw. einer EPK

Somit erfolgt eine erste fundamentale zeitliche Festlegung bei jeder Ereignisgesteuerten Prozesskette dadurch, dass die Funktionen - getrennt durch Ereignisse - nacheinander angeordnet sind. Dadurch ist ihre Reihenfolge festgelegt. Diese Festlegung ist allerdings keine absolute, mit Angabe des Zeitverbrauchs, sondern nur eine relative (zu den anderen Funktionen).

Nicht absolut, nur relativ

In Ereignisgesteuerten Prozessketten wird der Zeitverbrauch, also eine Angabe wie, diese Funktion muss innerhalb eines Tages erledigt sein, im Regelfall nicht erfasst. Eine Ausnahme ergibt sich bei Funktionen, die das Warten auf die Reaktion eines anderen ausdrücken (Wartefunktionen). Da ist es durchaus denkbar, ein Ereignis, das die abgelaufene Zeit signalisiert, mit in die EPK einzubauen. Z.B. so, dass als ein Ergebnis der Wartefunktion ein Ereignis wie Zeit ist abgelaufen oder zwei Wochen sind vergangen eingefügt wird.

Zeitverbrauch

Wie "rettet" man Informationen über die Zeit

Die Prozessmodellierung mit Ereignisgesteuerten Prozessketten kennt keine Nachrichten, Informationskanäle, und ähnliche Elemente, die ein Kommunikationsnetz etablieren könnten. Hier werden Informationen bei ihrer Entstehung in die Unternehmensdatenbank geschrieben und später im Prozess bei Bedarf wieder gelesen. Dies entspricht auch der Philosophie moderner ERP-Software [Anmerkung] .

In die Datenbank schreiben und von dort lesen

Eher systemorientierte Modellierungsansätze wie die Dynamikkomponenten der UML (Sequenzen, Aktivitäten, Zustandsautomaten, Anwendungsfälle, ...) gehen teilweise andere Wege. Hier gibt es durchaus auch das Konzept des Nachrichtenaustausches zwischen den Elementen des Systems. Auch die Methode BPMN kennt den Nachrichtenaustausch zwischen handelnden Einheiten, sogar ein "Broadcastsignal", eine Nachricht an alle übrigen Komponenten.

4 Aufbau Ereignisgesteuerter Prozessketten

4.1 Anfrageprüfung Teil 1

Die im vorigen Kapitel beschriebenen Elemente von Ereignisgesteuerten Prozessketten werden in der Prozessmodellierung verknüpft, um aussagekräftige Beschreibungen von Geschäftsprozessen zu erhalten. Die meisten dafür gültigen Regeln werden in diesem Abschnitt vorgestellt. Vgl. auch die Regelsammlung in Kapitel 9. Um die Anschaulichkeit zu erhöhen, wird den Ausführungen ein einfacher Geschäftsprozessausschnitt zugrundegelegt. Dieser wird Stück für Stück (eingerückt) beschrieben, danach wird die Umsetzung in die EPK erläutert. Die entstehende EPK wird bei jedem Schritt fortgeschrieben, um den Gesamtzusammenhang jeweils deutlich zu machen.

Regeln für die Erstellung von Ereignisgesteuerten Prozessketten

Prozessausschnitt Anfrageprüfung - Teil 1

Prozessbeschreibung: immer eingerückt

Der folgende Geschäftsprozessausschnitt liegt hier zugrunde: Es geht - bei einem Industrieunternehmen mit Einzelfertigung - um die Prüfung, ob die Anfrage eines Kunden nach einem bestimmten Produkt erfüllt werden kann oder nicht.

Die Anfrage kann per Mail, per Brief eintreffen oder in einem Gespräch formuliert worden sein. Bei Briefanfragen wird ein Antwortbrief verfasst und versendet. Bei Mailanfragen wird der Maileingang bestätigt, bei im Gespräch formulierten Anfragen eine Auftragsfestlegung (AFL) formuliert und dem potentiellen Kunden geschickt. Alle diese Aktivitäten übernimmt das Zentralsekretariat.

Beginnen wir mit dem Wichtigsten, das ein Geschäftsprozess aufweist, den Arbeiten, die in ihm geleistet werden. Hier sind ohne weiteres drei Funktionen erkennbar:

Umsetzung in die EPK

• Antwortbrief verfassen und versenden
• Maileingang bestätigen
• AFL erstellen und dem potentiellen Kunden senden

Die folgende Abbildung zeigt die grafische Darstellung von Funktionen. Ergänzt sind noch drei weitere, die sich im Verlauf der Modellierung ergeben.

Abbildung 4.1-1: Grafische Darstellung von Funktionen

Die Startereignisse sind ja in der Prozessbeschreibung klar beschrieben:

Ereignisse

• Anfrage per Brief eingetroffen
• Anfrage per Mail eingetroffen
• Anfrage im Gespräch formuliert

Ansonsten gilt ja, dass sich Funktionen und Ereignisse im Kontrollfluss ablösen. Deshalb folgen den ersten drei Funktionen jeweils Ereignisse, die so beschrieben werden können:

• Antwortbrief verschickt
• Bestätigungsmail verschickt
• AFL verschickt (AFL: Auftragsfestlegung)

In dieser Konstellation (klar die Erledigung ausdrückend) können sie auch Ergebnisereignissegenannt werden. Alle diese sechs Ereignisse zeigt die folgende Abbildung.

Abbildung 4.1-2: Grafische Darstellung von Ereignissen

Doch nun zum Kontrollfluss dieser Anfangssequenz. Ganz grundsätzlich wird die Syntaxregel eingehalten, dass Funktionen und Ereignisse sich immer ablösen müssenund dass jeder Geschäftsprozess mit einem Ereignis endet und beginnt (die Ausnahme mit Prozesswegweisern wird in Abschnitt 7.4 betrachtet). Die drei Startereignisse stellen den Anfang von Kontrollflusszweigendar, der aus einzelnen Kanten besteht, wie es die folgende Abbildung zeigt. Diese stoßen jeweils eine Funktion an, nach dieser folgen die oben schon angeführten Ergebnisereignisse. Der Fluss wird also durch die Pfeillinien (Kanten) ausgedrückt. An den Funktionen ist die Organisationseinheit Zentralsekretariat angefügt - mit einer richtungslosen Linie.

Kontrollfluss:
Funktionen und Ereignisse immer schön nacheinander.

Die Informationsobjekte wurden entsprechend der Prozessbeschreibung angelegt: Die von außen kommende Anfrage (als Brief, als Mail) mit Pfeil zur Funktion, die entstehenden Informationsobjekte Auftragsfestlegung, Antwortbrief, Bestätigungsmail mit Pfeil zum Informationsobjekt. Die handelnde Organisationseinheit ist hier immer das Zentralsekretariat.

Informationsobjekte und Organisations-einheiten

Abbildung 4.1-3: Geschäftsprozess Anfrageprüfung - Startereignisse und erste Funktionen

4.2 Anfrageprüfung Teil 2

Prozessausschnitt Anfrageprüfung - Teil 2

Anschließend wird durch den Vertrieb die Anfrage in der ERP-Software angelegt.

Danach folgen zwei Prüfungen: die der zur Verfügung stehenden Fertigungskapazitäten (durch die Abteilung Produktion) und die des Lagerbestandes (durch die Abteilung Lager). Dabei werden Daten der Produktionsplanung bzw. die Lagerdatenbank genutzt. Beide Prüfungen können zu einem positiven oder zu einem negativen Ergebnis führen.

Die Prozessbeschreibung Text macht es klar: Unabhängig davon, welches Startereignis den Prozess startet, der Kontrollfluss geht in einem einzigen Zweig weiter. Für das Zusammenführen der Kontrollflusszweigemuss hier der XODER-Operator genommen werden, da die Startereignisse alternativ sind. Muss innerhalb einer EPK zusammengeführt werden gilt, dass mit demselben Operator zusammengeführt wird, mit dem aufgeteilt wurde (vgl. Abschnitt 7.2). Damit ergibt sich das folgende EPK-Fragment.

Zusammenführen von Kontrollflusszweigen

XODER

Abbildung 4.2-1: Geschäftsprozess Anfrageprüfung - Zusammenführung alternativer Startsequenzen

Danach kommt es zur Anlage der Anfrage im ERP-System, es entsteht ein neues Informationsobjekt: AnfrageERP, weshalb der Pfeil zum Informationsobjekt zeigt. Dieses Beispiel zeigt anschaulich den Umgang mit Informationsobjekten in Ereignisgesteuerten Prozessketten. Zuerst wird die Anfrage (B/M/AFL) [Anmerkung] gelesen, dann wird die AnfrageERP geschrieben. Diese Reihenfolge wird im Modell nicht ausgedrückt, sie muss aus der Prozessbeschreibung bzw. der Prozesssituation gefolgert werden.

1. Lesen
2. Schreiben

Etwas spannender wird der nächste Abschnitt des Geschäftsprozesses. Die Prozessbeschreibung gibt hier ein in Geschäftsprozessen oft anzutreffendes Muster vor: mehrere Funktionen (Tätigkeiten, Aktivitäten) werden gleichzeitig angestoßen. Dies kann, siehe auch Abschnitt 6.2, mithilfe eines UND-Operators umgesetzt werden, wie es die folgende Abbildung zeigt. Der UND-Operator erzwingt, dass beide Funktionen, Prüfung Fertigungskapazität und Prüfung Lagerbestand, angestoßen werden. Die in der Prozessbeschreibung genannten Organisationseinheiten sind angefügt. Das Informationsobjekt AnfrageERP dient bei beiden Funktionen als Input, ebenso die abgefragten Datenbestände (Produktionsplanung und Lagerdatenbank).

Muster Tätigkeiten starten

Zwei Funktionen anstoßen mit dem UND-Operator

Abbildung 4.2-2: Geschäftsprozess Anfrageprüfung.
Anstoßen zweier Funktionen mit dem UND-Operator und Muster Entscheidungsfindung.

Natürlich führt jede der beiden neuen Funktionen zu Ergebnissen, die als Ereignisse modelliert werden [Anmerkung] . Entsprechend der Prozessbeschreibung wird umgesetzt, dass es je ein positives und ein negatives gibt:

• Kapazität reicht und Kapazität reicht nicht für die Prüfung Fertigungskapazität
• Lagerbestand ausreichend und Lagerbestand reicht nicht für die Prüfung Lagerbestand.

Da diese jeweils alternativ sind, muss hier in den Kontrollfluss ein XODER-Operator eingefügt werden.

4.3 Anfrageprüfung Teil 3

Prozessausschnitt Anfrageprüfung - Teil 3

Im positiven Fall, wenn also die Prüfungskapazität reicht und der Lagerbestand ausreichend ist, wird dem Kunden durch den Vertrieb zugesagt. Dazu wird die AnfrageERP benötigt. In ihr wird auch die Zusage vermerkt. Aus der Kundendatei werden die benötigten Informationen gelesen und in ihr wird vermerkt, dass eine Anfrage positiv beantwortet wurde.

Anschließend wird der Geschäftsprozess Auftragsbearbeitung angestoßen.

Diese Semantik wird in einer Ereignisgesteuerten Prozesskette so umgesetzt, dass die Kontrollflüsse der beiden "positiven" Ereignisse zusammengeführt, mit einem UND-Operator verbunden und zur entsprechenden Funktion weitergeführt werden. Hier also zur Funktion Dem Kunden zusagen. Kurzes Nachdenken macht klar, dass diese EPK-Syntax tatsächlich die in der Prozessbeschreibung geforderte Semantik erfasst: Zum Weiterfluss kommt es nur, wenn beim UND-Operator beide Kontrollflusszweige von den Ereignissen her ankommen.

Semantik sucht Syntax

Bei der Funktion Dem Kunden zusagen werden dann noch die genannte Organisationseinheit und die beiden Informationsobjekte angefügt. Beide werden gelesen und beschrieben, weshalb die Pfeile der Verbindungslinien in beide Richtungen zeigen.

Doppelpfeil: Lesen UND schreiben

Anmerkung: Einige wichtige Semantikaspekte sind in Kapitel 6 ("Muster in Geschäfts-prozessen") dargestellt.

Semantik sucht Syntax

Es ist in jeder Modellierung eines Anwendungsbereichs so, dass es neben den simplen abzubildenden Strukturen komplexere Semantikaspekte gibt, die sich im Modell wiederfinden sollen. So auch in der Prozessmodellierung. Hier ist es dann tatsächlich so, dass für eine bestimmte Semantik (siehe das Beispiel oben) eine entsprechende Syntax der semi-formalen Sprache gesucht werden muss.

Abbildung 4.3-1: Geschäftsprozess Anfrageprüfung - Positives Ergebnis und Aufruf Auftragsabwicklung

Da in der Prozessbeschreibung an dieser Stelle gleich das positive Endergebnis, der Aufruf des anschließenden Geschäftsprozesses Auftragsabwicklung angeführt wird, kann hier durch einen Prozesswegweiserauf eine entsprechende EPK verwiesen werden. Nehmen wir das als erstes Beispiel für einen Prozesswegweiser, einen Verweis auf einen anderen Prozess. Ausführlich vorgestellt werden Prozesswegweiser in Abschnitt 7.4. Die obige Abbildung zeigt den damit erreichten Stand im Geschäftsprozess Anfrageprüfung, die folgende den Beginn des Geschäftsprozesses Auftragsabwicklung.

Verweis auf andere EPK durch Prozesswegweiser

Erstes Beispiel

Abbildung 4.3-2: Start des Geschäftsprozesses Auftragsabwicklung

Der hier nun schon mehrfach vorgekommene UND-Operator bedeutet, dass der Kontrollfluss über ihn nur weitergeht, wenn alle Kontrollflusszweige von flussaufwärts ankommen. In dieser Anordnung (Ereignisse durch UND verknüpft vor einer Funktion) stellen die Ereignisse immer Bedingungenfür die Ausführung der nachfolgenden Funktion dar.

Muster Bedingungen (vgl. Abschnitt 6.5)

4.4 Anfrageprüfung Teil 4

Prozessausschnitt Anfrageprüfung - Teil 4

Falls entweder die Kapazität oder der Lagerbestand nicht reicht wird dem Kunden durch den Vertrieb abgesagt. Dafür wird die AnfrageERP benötigt, in der auch die Absage vermerkt wird. Ebenso die Kundendatei, in der ebenfalls das Scheitern der Anfrage festgehalten wird.

Die Prozessbeschreibung macht es klar: Wenn eine der beiden Prüfungen negativ ausfällt, wird dem Kunden abgesagt. Diese Situation entspricht einer, die hier Muster Kombinatorik genannt wird. Der Grund ist, weil die Ergebnisereignisse der beiden Funktionen miteinander kombiniert werden müssen, um alle möglichen Fortführungen des Geschäftsprozesses zu erfassen:

Muster Kombinatorik (vgl. Abschnitt 6.6)

1. Kapazität reicht nicht - Lagerbestand ausreichend

2. Kapazität reicht nicht - Lagerbestand reicht nicht

3. Kapazität reicht - Lagerbestand ausreichend

4. Kapazität reicht - Lagerbestand reicht nicht

Die folgende Abbildung zeigt dieses grundsätzliche Vorgehen. Für alle vier Konstellationen gibt es eine Weiterführung und eine entsprechende Funktion. Der UND-Operator leistet hier - wiederum bei der Suche nach einer Syntax für diese Semantik- sehr gute Dienste. Da es über ihn nur weiter geht im Kontrollfluss, wenn alle wegführenden oder ankommenden Kanten aktiviert werden (nur die Kanten(!), nicht die nachfolgenden Funktionen), führt diese syntaktische Lösung zur gewollten Semantik.

Semantik sucht Syntax:

Kombinatorik mit Hilfe des UND-Operators

Abbildung 4.4-1: Kombinatorik - in vollem Umfang realisiert

In dem konkreten Geschäftsprozess hier wurde die positive Variante (der positive Fall) oben schon erledigt. Jetzt geht es um die drei Fälle, bei denen entweder die eine Prüfung oder die andere oder beide negativ ausfallen. Diese können hier zusammengefasst werden, da ja bei einem negativen Ergebnis bei einer der Prüfungen auf jeden Fall abgebrochen wird.

Aus 3 wird 1

Die Umsetzung dieser Semantik in die Syntax einer EPK zeigt die folgende Abbildung.Vor die Funktion Dem Kunden absagen wird ein ODER-Operatorgesetzt, der die Kontrollflusszweige der beiden negativen Ergebnisereignisse zusammenführt. Es muss ein ODER-Operator sein, da entweder das eine Ereignis oder das andere oder beide dazu führen sollen, dass der Kontrollfluss über ihn zur Funktion Dem Kunden absagen und zu dem nachfolgenden Ereignis Dem Kunden abgesagt weiterführt. Insgesamt hat der Geschäftsprozess damit zwei Schlussereignisse. Die folgende Abbildung zeigt das Endergebnis.

Semantik sucht Syntax: "Mindestens ein Ereignis"
mit ODER-Operator

In der Praxis kommt dies recht oft vor, dass die große Zahl von Kombinationen (man stelle sich nur auf der einen Seite 5 und auf der anderen Seite 4 Ergebnisereignisse vor) durch eine entsprechende Semantik verkleinert wird.

Abbildung 4.4-2: Geschäftsprozess Anfrageprüfung - Die finale EPK

4.5 Instanzen

Die oben erstellte Ereignisgesteuerte Prozesskette zeigt alle möglichen Durchgänge durch den Prozess, den gesamten Kontrollfluss also. Manchmal ist es aber sinnvoll, einen einzelnen konkreten Durchgang mit seinem konkreten Kontrollfluss zu betrachten. Eine solche EPK wird als Instanz der "allgemeinen" EPK bzw. der konkrete Geschäftsprozessdurchgang als Instanzdes "allgemeinen" Geschäftsprozesses bezeichnet.

Kontrollfluss:
einzelne Durchgänge

Die folgende Abbildung gibt obige EPK wider. Allerdings ist der Kontrollfluss für den positiven Fall (Auftrag kann angenommen, Folgeprozess kann gestartet werden) durch eine verdickte Linie hervorgehoben. Das Startereignis sei Anfrage per Mail eingetroffen. Es könnte auch jedes der beiden anderen Startereignisse sein. Der folgende Ablauf ist bis zum UND-Operator und den ihm nachfolgenden Funktionen für alle Instanzen gleich. D.h., der UND-Operator "sendet" immer alle von ihm wegführenden Kanten (Kontrollflusszweige) los.

Kontrollfluss für den positiven Fall

Danach beginnen die möglichen Unterschiede zwischen den Instanzen. Hier ("positiver Fall") ist es so, dass beide Prüfungen positiv ausfallen. Die anderen Kanten werden bei dieser Instanz nicht wirksam. Entsprechend sind die Kanten, die von den Funktionen zum positiven Ergebnis führen, dick gesetzt.

Von den beiden Ergebnisereignissen (Kapazität reicht, Lagerbestand ausreichend) führen die bei dieser Instanz wirksamen Kanten zum UND-Operator und kommen sogar - da ja beide eintreffen - über ihn hinweg zur Funktion Dem Kunden zusagen. Danach kommt nur noch der Prozesswegweiser, der zum nächsten Geschäftsprozess bzw. seiner EPK verweist.

Abbildung 4.5-1: Geschäftsprozess Anfrageprüfung.
Die Instanz für den positiven Ausgang

Die folgende Abbildung zeigt eine andere Instanz, einen der Kontrollflussdurchgänge, der zu einem negativen Ergebnis führt. Wiederum sind die entsprechenden Kontrollflusspfeile verdickt.

Kontrollfluss für einen der negativen Fälle

Als Startereignis wurde hier Anfrage im Gespräch formuliert gewählt. Es folgt die entsprechende Funktion und dann, nach dem XODER-Operator, die Anlage der Anfrage im ERP-System. Bis zum Aufruf der beiden Funktionen nach dem UND-Operator ist der Kontrollfluss dann gleich wie oben. Eine der anschließenden Funktionen (Prüfung Fertigungskapazität) führt dann aber zum negativen Ergebnis, weshalb der Kontrollfluss hier gleich zur Absage weitergeht.

Die Prüfung des Lagerbestandes mit ihrem positiven Ergebnis führt zwar noch zum nachfolgenden UND-Operator, da bleibt dieser Kontrollflusszweig aber "hängen", da es über den UND-Operator nur weiter geht, wenn beide Kontrollflusszweige oben ankommen. Die Stelle ist durch ein Ausrufungszeichen markiert. Insofern hat auch hier wieder die Semantik die treffende EPK-Syntax gefunden.

Semantik sucht Syntax

Abbildung 4.5-2: Geschäftsprozess Anfrageprüfung. Die Instanz für einen der negativen Fälle

5 Basismuster

5.1 Mögliche Anordnungen

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

Alle möglichen Anordnungen von E und F im Kontrollfluss

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

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

Definition: Auslösende Ereignisse

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

Definition: Erzeugte Ereignisse

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

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

Abbildung 5.1-1: Mögliche Verknüpfungen von Ereignissen und Funktionen durch Operatoren

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

5.2 Ereignisverknüpfung mit auslösenden Ereignissen

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

Ereignisse als Bedingungen

5.2.1 UND

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

Gemeinsame Bedingungen

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

Abbildung 5.2-1: Ereignisverknüpfung / Auslösende Ereignisse / UND

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

5.2.2 XODER

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

Alternative Bedingungen

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

Abbildung 5.2-2: Ereignisverknüpfung / Auslösende Ereignisse / XODER

5.2.3 ODER

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

Mindestens ein Ereignis muss eintreten

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

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

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

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

Abbildung 5.2-3: Ereignisverknüpfung / Auslösende Ereignisse / ODER - 1. Beispiel

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

Mögliche Aggregation (Zusammenfassung)

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

Abbildung 5.2-4: Ereignisverknüpfung / Auslösende Ereignisse / ODER - 2. Beispiel

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

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

Aggregieren oder Detaillieren

5.3 Ereignisverknüpfung mit erzeugten Ereignissen

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

5.3.1 UND

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

Teilaufgaben mit UND

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

Abbildung 5.3-1: Ereignisverknüpfung / Erzeugte Ereignisse / UND -
1. Beispiel

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

Keine Parallelität im technischen Sinne

5.3.2 XODER

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

Festhalten alternativer Ergebnisse

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

Abbildung 5.3-2: Ereignisverknüpfung / Erzeugte Ereignisse / XODER

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

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

Abbildung 5.3-3: Ereignisverknüpfung / Erzeugte Ereignisse / XODER

5.3.3 ODER

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

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

Erledigung von Aufgaben

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

Abbildung 5.3-4: Ereignisverknüpfung / erzeugte Ereignisse / ODER

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

Unabhängigkeit

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

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

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

Vgl. zur Problematik des ODER-Operators und zu den Fehlerquellen Abschnitt 7.3.

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

Syntax vs.
Semantik

Abbildung 5.3-5: Ereignisverknüpfung / erzeugte Ereignisse / ODER
Wareneingangsprüfung 1

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

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

Definition

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

5.4 Funktionsverknüpfung mit auslösenden Ereignissen

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

Ereignis startet Funktionen

5.4.1 UND

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

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

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

Keine Reihenfolge
bzw.
Verzicht auf Modellierung der Reihenfolge

Abbildung 5.4-1: UND / Funktionsverknüpfung / auslösendes Ereignis

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

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

Pragmatik. Verzicht auf zu viel Detaillierung.

Abbildung 5.4-2: Funktionsverknüpfung / auslösendes Ereignis / UND -
2. Beispiel

Anmerkungen:

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

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

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

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

5.4.2 XODER - verboten

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

Fehlende Entscheidungs­funktion

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

XODER - verboten

Abbildung 5.4-3: Funktionsverknüpfung / auslösendes Ereignis/ XODER ohne Entscheidungsfunktion

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

Richtige Lösung mit Entscheidungs-
funktion

Abbildung 5.4-4: Funktionsverknüpfung mit vorangestellten Ereignissen/ auslösendem Ereignis / XODER - mit Entscheidungsfunktion

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

5.4.3 ODER - verboten

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

Fehlende Entscheidungs-
funktion

Abbildung 5.4-5: Funktionsverknüpfung / auslösendes Ereignis/ ODER - ohne Entscheidungsfunktion

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

Richtige Lösung mit Entscheidungs-
funktion

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

Syntaxregel

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

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

Abbildung 5.4-6: Funktionsverknüpfung mit vorangestellten Ereignissen/ auslösendem Ereignis / ODER - mit Entscheidungsfunktion

Anmerkungen:

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

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

Abkürzungen:

DiKu: Digitale Kundenakte

AFKK: Antragsformular Kreditkarte

AFDP: Antragsformular Depot

AFOB: Antragsformular Online-Banking

5.5 Funktionsverknüpfung mit erzeugten Ereignissen

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

Erledigung von Funktionen

5.5.1 UND

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

Mehrere Funktionen erledigen, dann gemeinsames Ergebnis

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

Abbildung 5.5-1: UND / Funktionsverknüpfung / erzeugtes Ereignis

Anmerkungen:

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

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

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

Stellenbesetzung - etwas umfangreicher

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

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

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

Muster Zeitfenster

Abbildung 5.5-2: Stellenbesetzung - Mögliche Einbettung des EPK-Fragments von Abb. 5.5-1

Anmerkungen:

Muster: Zeitfenster

Syntaxregel: Zusammenführen Kontrollflüsse

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

Syntaxregel Zusammenführen Kontrollflusszweige

5.5.2 XODER

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

Alternative Tätigkeiten mit einem Ergebnisereignis:

Abbildung 5.5-3: Funktionsverknüpfung / erzeugtes Ereignis / XODER

5.5.3 ODER

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

Mindestens eine Funktion muss realisiert werden

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

Für alle EPK-Strukturen dieses Abschnitts gilt:

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

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

Abbildung 5.5-4: Funktionsverknüpfung / erzeugtes Ereignis / ODER

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

Alle auf einmal

Abbildung 5.5-5: Mögliche Verknüpfungen von Ereignissen und Funktionen im Kontrollfluss - Gesamtübersicht

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

Abbildung 5.5-6: Die Rolle der Ereignisse in den 12 Verknüpfungsvarianten

6 Muster in Geschäftsprozessen

6.1 Entscheidungsfindung

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

Entscheidung 1
Genau ein Ergebnis

Abbildung 6.1-1: Entscheidungsfindung in EPKs - Genau ein Ergebnis

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

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

Entscheidung 2
Mindestens ein Ergebnis

Abbildung 6.1-2: Entscheidungsfindung in EPKs - Mindestens eine Tätigkeit aus einer Menge von Tätigkeiten

Wenn wir Menschen Entscheidungen fällen, unterscheiden wir nicht, ob die Entscheidung nur zu einem oder zu mindestens einem Ergebnis führen soll. Das läuft auf einmal ab. Beispiele dazu finden sich bei der Thematik "ungenaue ODER-Modellierung und deren Lösung" in Abschnitt 7.3 (ODER-Detailanalyse). Auch im Beispiel der nachfolgenden Abbildung liegt eine solche Situation vor. Ware ist eingetroffen, die Wareneingangsprüfung findet statt. Im Rahmen dieser wird entschieden, ob außer der Annahme der Ware eine Aktion (Einlagern, Umverpacken, Qualitätskontrolle) notwendig ist und welche. Die linke Seite der folgenden Abbildung zeigt die syntaktisch korrekte Lösung. Zuerst muss die Prüfung "Aktion notwendig oder nicht" modelliert werden, dann die, welche Aktion(en) konkrete nötig sind.

Entscheidung 3

"Ein Ergebnis" und "mindestens ein Ergebnis" zusammen

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

Korrekt vs. verkürzt

XODER und ODER kompakt

Abbildung 6.1-3: Entscheidungsfindung in EPKs - XODER und ODER kompakt

6.2 Teilaufgaben und Tätigkeiten starten

Teilaufgaben

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

Diese Semantik kann durch eine Funktion, einen nachfolgenden UND-Operator und eine Gruppe von verknüpften Ereignissen modelliert werden. Die Ereignisse geben die Teilaufgaben an. Vgl. hierzu auch das in Abschnitt 5.3-1 beschriebene Syntaxmuster, das hier in vollem Umfang passt. Die folgende Abbildung zeigt das oben angeführte Beispiel.

Abbildung 6.2-1: Muster Teilaufgaben und seine Umsetzung

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

Tätigkeiten starten

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

Ereignis stößt mehrere Funktionen an.

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

Weiterführung

Abbildung 6.2-2: Muster Tätigkeiten anstoßen und seine Umsetzung

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

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

Keine Parallelität

6.3 Zeitfenster

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

Zeitfenster

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

Semantik findet Syntax

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

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

Gestaltungsregel:
Weglassen der Ereignisse in der einfachen sequentiellen Abfolge.

Abbildung 6.3-1: Zeitfenster zwischen zwei UND-Operatoren

Anmerkungen:

Semantik: Zeitfenster

Gestaltungsregel: Weglassen der Ereignisse bei einfacher sequentieller Abfolge.

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

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

6.4 Zeitpunkte

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

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

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

Muster Zeitpunkte

Abbildung 6.4-1: Zeitpunkte in den Kontrollfluss einbauen

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

Zeitspanne

Abbildung 6.4-2: Zeitpunkte in den Kontrollfluss einbauen

Abkürzungen:

PA: Personalabteilung

SchAbt: Schulungsabteilung

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

Start-Zeitpunkte -
aus dem Ereignisraum der Organisation

Abbildung 6.4-3: Zeitpunkte in den Kontrollfluss einbauen

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

Die passende EPK-Syntax besteht aus zwei entsprechenden Ereignissen

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

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

Abbildung 6.4-4: Zeitpunkte in den Kontrollfluss einbauen

Anmerkungen:

Muster: Start-Zeitpunkt mit zwei Startbedingungen.

Syntax: Zwei durch UND verknüpfte Startereignisse.

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

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

Warten

6.5 Bedingungen

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

Semantik: Bedingungen für Fortgang

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

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

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

Syntax: "Bedingungs"-Ereignisse" mit UND verknüpfen

Abbildung 6.5-1: Muster Bedingungen für den Fortgang - Urlaubsantrag

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

Abbildung 6.5-2: Muster Bedingungen für den Fortgang - Prüfungen

6.6 Kombinatorik

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

Kombinatorische Explosion

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

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

Abbildung 6.6-1: Kombinatorik 1 - Ergebnisse von Prüfungen

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

Volle Kombinatorik

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

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

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

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

Abbildung 6.6-2: Kombinatorik 2 - Bitte um Fristverlängerung

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

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

Semantik durch UND-Operator

Abbildung 6.6-3: Kombinatorik 3 - Anfrage annehmen

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

Abbildung 6.6-4: Kombinatorik 4 - Alle Ergebnisse

Abkürzungen:

GL: Geschäftsleitung

VU: Vertriebsingenieur

Ein weiteres ausführliches inhaltliches Beispiel hierzu findet sich im Geschäftsprozess Zoo in Abschnitt 8.4.

6.7 Warten

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

Zeitaspekt Warten

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

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

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

Warten auf Zu- oder Absage

Abbildung 6.7-1: Muster Warten - Bewerberantwort

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

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

Das logische UND als Schalter

Abbildung 6.7-2: Warten mit dem logischen UND

6.8 Rücksprünge

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

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

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

Beispiel Texterstellung

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

Gestaltung der Rückschleife

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

Rücksprung 1 ohne Kontrolle

Abbildung 6.8-1: Wiederholung eines Geschäftsprozessabschnitts

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

Endlos?

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

Kontrollierte Wiederholung

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

Prüfung der Anzahl an Wiederholungen

Rücksprung 2 mit Kontrolle der Anzahl der Wiederholungen

Abbildung 6.8-2: Mehrmalige Wiederholung eines Geschäftsprozessabschnitts mit Kontrolle

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

Rücksprung 3:
Wiederholung ohne Rückschleife

Syntaxhinweis

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

Abbildung 6.8-3: Einmalige Wiederholung eines Geschäftsprozessabschnitts

6.9 Repetitive Handlungen

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

Muster: Sich mehrfach wiederholende Handlungen.

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

Syntax: Rücksprung, Rückschleife

Abbildung 6.9-1: Wiederholung wegen "Abarbeitung"

Kapseln in eine Funktion

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

Aggregieren
durch Kapseln

Abbildung 6.9-2: Verzicht auf Rückschleife durch Kapselung

7 Kontrollfluss bewältigen

In diesem Abschnitt werden verschiedene Themen diskutiert, die sich bei der korrekten Modellierung des Kontrollflusses ergeben. Dies sind teilweise Vertiefungen und auch Präzisierungen der bisherigen Ausführungen, teilweise Hinweise auf die Bewältigung besonders schwieriger Modellierungsthemen.

7.1 Informationstransport

Sehr oft müssen in Geschäftsprozessen Informationsobjekte transportiert werden. Dabei geht es grundsätzlich um zwei Aspekte:

• Die Informationsobjekte an sich
• Den Transport der Informationsobjekte

Wie in Abschnitt 3.6 dargestellt, geben die Informationsobjekte einfach bei den Funktionen die genutzten, veränderten oder erzeugten Informationen an. In einer klassischen Istanalyse sind dies Informationsobjekte wie Rechnungen, Lieferscheine, usw. In einer programmnahen Geschäftsprozessmodellierung sind dies auch Attribute der zugehörigen Datenbank. In jedem Fall sollten die Informationsobjekte sorgfältig modelliert werden, um auch die benutzten Daten voll in die Analyse einbeziehen zu können.

Informationsobjekte und Datenbestände

Dasselbe gilt für den Informationstransport. Auch er sollte detailliert beschrieben werden, da er oft Hinweise auf Optimierungsmöglichkeiten gibt. Grundsätzlich gibt es zwei Möglichkeiten. Eine explizite Modellierung des Transports durch eine eigens dafür eingefügte Funktion oder eine implizite, bei der man den Transportvorgang nur daran erkennt, dass das Informationsobjekt einer Funktion bei einer nachfolgenden Funktion mit einer anderen Organisationseinheit ebenfalls angefügt ist.

Informationstransport - explizit oder implizit

Modelliert man den Informationstransport mittels einer eigenen Funktion findet weder ein (wirklicher [Anmerkung] ) Lesevorgang und schon gar kein Schreibvorgang statt. Deshalb werden hier in einem solchen Fall die Pfeilspitzen bei der Verbindungslinie zwischen Funktion und Informationsobjekt weggelassen.

Keine Pfeilspitze bei alleinigem Transportvorgang

Die folgende Abbildung zeigt - abstrakt - die Modellierung eines expliziten Informationstransports. In Funktion 1 erzeugt oder bearbeitet die Organisationseinheit 1 das Informationsobjekt. Es folgt eine Weiterleitungsfunktion, bei der auch durch Weglassen der Pfeilspitze der Transportvorgang klar gemacht wird, anschließend bearbeitetet die Organisationseinheit 2 im Rahmen der Funktion 2 das Informationsobjekt weiter.

Expliziter Informationstransport

Abbildung 7.1-1: Expliziter Informationstransport

Die folgende Abbildung zeigt den impliziten Transport von Information. Org 1 erzeugt oder bearbeitet das Informationsobjekt mittels der Funktion 1. Bei der nächsten ebenfalls verarbeitenden Funktion bearbeitet Org 2 das Informationsobjekt. D.h., es muss transportiert worden sein. Dieses implizite Festhalten des Transportvorgangs wird sehr oft gewählt.

Impliziter Informationstransport

Abbildung 7.1-2: Impliziter Informationstransport

Das folgende inhaltliche Beispiel ist abgeleitet von der Startsequenz des Geschäftsprozesses in Kapitel 4. Das EPK-Fragment wurde lediglich für diesen Abschnitt noch etwas angereichert. Demonstriert wird der Informationstransport am Beispiel des Informationsobjekts Anfrage (im EPK-Fragment mit verdickten Linien).

Das Zentralsekretariat nimmt die Anfrage entgegen. Danach folgen zwei explizite Transportvorgänge, die Weiterleitung an den Vertriebsbereichsleiter (Position 1) und an die Geschäftsleitung (Position 2). Danach folgen Funktionen, in denen die Anfrage benötigt wird. Der Vertriebsbereichsleiter sendet dann die Anfrage zum ausgewählten Vertriebsingenieur (Position 3). Bei dieser Funktion wäre das Anfügen der Organisationseinheit nicht nötig, es geschieht hier nur, um die Übersichtlichkeit zu erhöhen. In der letzten Funktion dieses Kontrollflusszweiges wird dann dieses Informationsobjekt vom Vertriebsingenieur als Input benötigt.

Abbildung 7.1-3: Explizite Weiterleitung des Informationsobjekts Anfrage

Die folgende Abbildung zeigt das Fragment ohne ausdrückliche Transportfunktionen. Hier muss man aus der Tatsache, dass die Anfrage bei einer Funktion flussabwärts durch eine andere Organisationseinheit bearbeitet wird schließen, dass ein Transportvorgang stattgefunden hat. Zuerst vom Zentralsekretariat zum Vertriebsbereichsleiter und zur Geschäftsleitung, dann vom Vertriebsbereichsleiter zum Vertriebsingenieur.

Das Informationsobjekt, um das es geht, ist fett gesetzt.

Abbildung 7.1-4: Implizite Weiterleitung der Anfrage

Wie die Abbildung deutlich zeigt, braucht man schon etwas Erfahrung, um die impliziten Transportvorgänge schnell zu erkennen. Insbesondere wenn bei der Prozessmodellierung auch die Vorgangsbearbeitung (der Workflow) betrachtet werden soll, ist die explizite Modellierung des Informationstransports vorzuziehen.

7.2 Zusammenführen von Kontrollflusszweigen

Der Begriff des Kontrollflusses beruht darauf, dass ein Geschäftsprozess sozusagen eine Richtung hat, die durch die Abfolge der Tätigkeiten gegeben ist. Entsprechend hat dies auch eine Ereignisgesteuerte Prozesskette. Dabei kommt es, wie auch die Beispiele oben zeigen, durch die Operatoren immer zu einer Aufspaltungdes Kontrollflusses in mehrere Zweige, die u.U. gleich oder später wieder aufgehoben werden muss.

Aufspaltung des Kontrollflusses

Diese Aufspaltung muss meist später - flussabwärts - wieder aufgehoben werden, da es im Prozess einheitlich, d.h. mit einem Kontrollflusszweig weitergeht. Dazu müssen die Kantenflüsse wieder zusammengeführt werden. Dies geschieht immer durch einen Operator und zwar durch den, mit dem sie aufgeteilt wurden.

Syntaxregel

Syntaxregel: Zusammenführen Kontrollflusszweige

Werden Kontrollflusszweige zusammengeführt, die flussaufwärts aufgeteilt wurden (die also nicht von verschiedenen Startereignissen herrühren), dann erfolgt die Zusammenführung (Verknüpfung) mit demselben Operator mit dem die Aufteilung erfolgte.

Die folgenden Abbildungen zeigen dies. Dabei handelt es sich immer um Beispiele aus Kapitel 5, die hier jetzt weitergeführt werden.

Zuerst die ODER-Verzweigung aus Abschnitt 5.4 (Abbildung 5.4-6). Bei jeder Instanz des Geschäftsprozesses kommt es zu einer Teilmenge der gewählten Leistungen. Sind diese getätigt, werden die Kanten zusammengeführt und es folgt das Ereignis Kundenwünsche realisiert. Die Zusammenführung erfolgt mit dem ODER-Operator, weil mit ihm auch aufgeteilt wurde. Dieser Prozessabschnitt wurde durch einen verdickten Strich gekennzeichnet.

Zusammenführen ODER

Hier liegt im Übrigen auch wieder eine pragmatische Entscheidung vor. Auf die Ergebnisereignisse der einzelnen Funktionen wird verzichtet, es wird ein gemeinsames Ergebnisereignis gewählt, das auch noch unabhängig von den bei einer Instanz eintretenden Ergebnissen ist.

Pragmatik

Abbildung 7.2-1: Zusammenführen Kontrollfluss - ODER

Die folgende Abbildung zeigt dies für den UND-Operator mit Funktionsverknüpfung. Die Aufsplittung des Kontrollflusses signalisiert hier Teilaufgaben (vgl. Abschnitt 6.2). Natürlich hätten hier auch noch Ereignisse nach jeder Funktion eingefügt werden können, dann wäre nach der Verknüpfung eine Funktion gekommen. Wie oben signalisiert hier die Zusammenführung, dass es in einem einzigen Kontrollflusszweig weitergeht und zwar nach der Erledigung der Teilaufgaben.

Zusammenführen UND

Abbildung 7.2-2: Aufteilen und Zusammenführen von Kontrollflusszweigen - UND

Beim XODER-Operator bedeutet die Aufspaltung, dass es alternative Wege gibt, eine Funktion zu realisieren. Die Zusammenführung macht dann klar, dass es im Geschäftsprozess in einem einzigen Zweig weitergeht.

Zusammenführen XODER

Abbildung 7.2-3: Aufteilen und Zusammenführen von Kontrollflusszweigen - XODER

7.3 ODER-Detailanalyse

In Abschnitt 5.3.3 wurde mehrfach auf die Situation hingewiesen, dass durch ODER verknüpfte Ereignisse oder Funktionen oftmals nicht gänzlich unabhängig voneinander sind, sondern eine innere Struktur aufweisen. Z.B. so, dass eines der Ereignisse nicht mit den anderen vorkommen kann oder dass einige der Ereignisse nur zusammen auftreten können. Ein Beispiel dafür findet sich in der folgenden Abbildung.

Verknüpfungs­semantik

Es geht um eine Wareneingangsprüfung. Sie ergibt hier mindestens eines der Ergebnisse:

Vgl. zu diesem Beispiel auch die Abschnitt 5.3.3 und 5.5.3

• Keine Aktion notwendig
• Einlagern notwendig
• Umverpackung notwendig
• Qualitätskontrolle notwendig

Es folgen die entsprechenden Funktionen, außer beim Ergebnis Keine Aktion notwendig. Anschließend wird der Wareneingang bestätigt.

Die oben erwähnte innere "innere Struktur" besteht darin, dass die Ereignisse nicht unabhängig voneinander sind. Wenn das Ereignis Keine Aktion notwendig eintritt, können die anderen Ereignisse nicht eintreten. Insofern ist die dem Operator innewohnende Logik, dass jede beliebige Teilmenge eintreten kann, nicht realisiert. In semantischer Hinsicht ist also diese Modellierung falsch. Sie ist jedoch in syntaktischer Hinsicht, wenn man die Semantik des Prozessabschnitts außer Acht lässt, völlig korrekt.

Syntaktische und semantische Ebene der Modellierung

Will man nun doch die aufwändigere semantisch korrekte Modellierung, muss man den Entscheidungsprozess in der EPK präzisieren. In dem Beispiel dieses Abschnitts geschieht dies so, dass zuerst die grundsätzliche Entscheidung, Aktion notwendig oder nicht, gefällt wird. Dies geschieht mit Hilfe eines XODER-Operators. Anschließend wird für den Fall, dass Aktionen notwendig sind, mit Hilfe einer weiteren Funktion modelliert, welche Aktivitäten dies konkret sind. Im Beispiel unten ist es der Abschnitt mit der Funktion Prüfen, welche Aktion, dem ODER-Operator und den drei Ergebnisereignissen.

Vgl. Abbildung 7.3-2

Die Kante von Keine Aktion notwendig zum Schluss des EPK-Fragments muss dann vom Ereignis bis vor die Funktion Wareneingang bestätigen geführt werden. Dies vor allem aus inhaltlichen Gründen, aber auch wegen der Regel, dass sich Ereignisse und Funktionen im Kon­trollfluss immer ablösen.

Abbildung 7.3-1: Wareneingangsprüfung -
Unscharfe Modellierung mit ODER

Das Beispiel der folgenden Abbildung zeigt auch, wie mit verschachtelten Kon­trollflussstrukturen umgegangen wird. Werden mehrere Verzweigungen geöffnet und sollen diese Kontrollflusszweige wieder vereinigt werden, muss zuerst die innerste, dann die nächste usw. und am Schluss die äußerste Verzweigung geschlossen werden, ganz wie in der prozeduralen Programmierung. In diesem Beispiel ist es naheliegend und ergibt sich einfach so, das ist aber in der konkreten praktischen Modellierung nicht immer der Fall. Deshalb ist es wichtig auf diese Regel zu achten, auch wenn die "öffnenden" Operatoren weit flussaufwärts im Kontrollfluss liegen.

Verschachtelte Kontrollfluss-
strukturen bewältigen

Syntaxregel

Werden mehrere Verzweigungen hintereinander angelegt und müssen sie wieder zusammengeführt werden, dann wird zuerst die innerste, dann die von innen nachfolgende, usw. und zum Schluss die äußerste Verzweigung wieder zusammengeführt.

Hier ist die erste Verzweigung die mit der grundsätzlichen Entscheidung, Aktion oder nicht, die innere dann die mit der Feststellung der konkret notwendigen Aktivitäten.

Zweifache Verschachtelung

Abbildung 7.3-2: Wareneingangsprüfung -
Genauere Modellierung mit XODER und ODER

Zum Schluss kommen wir bei diesem Beispiel noch auf die pragmatische Ebene der Prozessmodellierung. Oftmals wird in der konkreten Modellierung die Lösung der folgenden Abbildung gewählt. Dabei wird, im Vergleich mit der vorigen Lösung, auf die zweite Funktion verzichtet. Eine einzige Funktion (Wareneingangsprüfung) soll beide nachfolgenden Operatoren (XODER und ODER) - sozusagen - realisieren. D.h. in ihr sollen die Entscheidungen gefällt werden, die den Weiterfluss nach dem XODER- und nach dem ODER-Operator klären. Der entsprechende Abschnitt ist in der EPK durch Verdickung hervorgehoben.

Pragmatik: zwei unterschiedliche Entscheidungen in einer Funktion

Abbildung 7.3-3: Wareneingangsprüfung -
Eine Funktion für zwei Operatoren

Beispiel Anfragebearbeitung

Hier nun ein weiteres Beispiel. Es weist die oben eingeführte Unschärfe in der ODER-Modellierung auf. Zusätzlich noch eine weitere Besonderheit: Die beliebig zusammenkommenden durch ODER verknüpften Aktivitäten erfordern je nach Zusammenstellung der "Teilmenge" unterschiedliche Handlungen. Dazu unten mehr.

Es handelt sich um den Beginn eines größeren Geschäftsprozesses, bei dem es um Kundenanfragen nach Produkten geht, die in Einzelfertigung hergestellt werden. Da die Kalkulation und die Erstellung der CAD-Zeichnungen sehr aufwändig ist, erfolgt zuerst eine Prüfung, ob nicht früher schon mal etwas geliefert wurde, sodass auf die da erstellten Kalkulationsunterlagen und CAD-Zeichnungen zurückgegriffen werden könnte. Oben wurde diese Prozesssituation recht schlicht mit einem XODER-Operator gelöst. Hier nun die realistischere mit einem ODER-Operator, bei der angenommen wird, dass man eine gleiche und eine ähnliche Anlage, oder eine ähnliche Anlage und Komponenten oder sogar alles drei schon mal geliefert hat.

Prüfung

Zuerst die Lösung mit der ODER-Unschärfe. Die Prüfung wird in der Ereignisgesteuerten Prozesskette als Funktion modelliert (Prüfung, ob Unterlagen vorhanden), die zu vier Ergebnissen (modelliert als Ereignisse) führen kann:

Ungenaue ODER-Lösung

• Gleiche Anlage schon mal geliefert
• Ähnliche Anlage schon mal geliefert
• Komponente schon mal geliefert
• Nichts Ähnliches geliefert

Dabei können auch mehrere Ereignisse gleichzeitig eintreffen (z.B. die ersten drei), weshalb für die Verknüpfung der ODER-Operatorverwendet wurde. Nach den Ereignissen sind dann die entsprechenden Funktionen angeordnet. Danach werden die verschiedenen Kontrollflusszweige wieder zusammengeführt. Für eine beliebige Teilmenge der drei durch ODER verknüpften Funktionen folgt das Ergebnis Unterlagen zusammengestellt und nachfolgend eine Funktion, die den eigentlichen planerischen Aufwand für die Produkterstellung erfasst:

Beliebige Teilmenge

• Anlage konzipieren, kalkulieren, Skizze erstellen, ausgehend von den gefundenen Unterlagen

Eine ähnliche Funktion (Anlage konzipieren, kalkulieren, Skizze erstellen) folgt nach dem Ereignis Nichts ähnliches geliefert. Anschließend finden die beiden Kanten zusammen zum Schlussereignis.

Abbildung 7.3-4: Anfragebearbeitung
Ungenaue Modellierung mit ODER

Diese Modellierungweist nun wieder die oben angesprochene Ungenauigkeit in der ODER-Modellierung auf, die auf die bekannte Weise beseitig werden kann (vgl. die folgende Abbildung). Zuerst wird geprüft, ob überhaupt Unterlagen vorhanden sind. Falls dem so ist (Ähnliche Anlage oder Komponente schon mal geliefert), wird eine genauere Prüfung vorgenommen. Deren Ergebnisse und Aktivitäten stehen dann in einer ODER-Beziehung zueinander.

Stufenweise Prüfung

So weit so gut. Schwieriger ist das Problem zu lösen, dass je nach Zusammenstellung der mit ODER verknüpften Aktivitäten unterschiedliche Arbeiten für die letztendliche Erstellung der Produktionsunterlagen notwendig sind. Hat man nur eine ähnlich Anlage geliefert liegt eine andere Situation vor, als wenn zusätzlich noch eine Komponente früher geliefert wurde, usw. Eigentlich gibt es also bezüglich der durch ODER verknüpften Aktivitäten folgende Alternativen zu bedenken:

Pragmatik: einfachere Lösung durch Abstraktion

• Gleiche Anlage allein
• Ähnliche Anlage allein
• Komponente allein
• Gleiche Anlage / ähnliche Anlage
• Gleiche Anlage / Komponente
• Ähnliche Anlage / Komponente
• Gleiche Anlage / Ähnliche Anlage / Komponente

Für jedes dieser Ergebnisse ist u.U. unterschiedliches zu tun. Jede dieser Kombinationen müsste angelegt werden, um danach die jeweilige Funktion platzieren zu können. Diese Ergebnisse sind im Übrigen Alternativen, d.h. sie stehen in einer XODER-Beziehung.

In der Praxis werden aber diese Alternativen selten voll ausmodelliert. Hier wird in der Regel ganz pragmatisch zur Vereinfachung durch Abstraktiongegriffen. Dies ist meist sehr einfach möglich, indem die jeweilige Funktion allgemeiner formuliert wird. Also

Pragmatik:
Vereinfachung durch Abstraktion

• Anlage konzipieren, kalkulieren, Skizze erstellen, ausgehend von den gefundenen Unterlagen

anstatt:

• Unterlagen der Komponente ergänzen um Informationen aus ähnlicher Anlage
• Abgleichen der ähnlichen Anlage mit der bestellten, Abweichungen festhalten und Informationen für die veränderten Teile beschaffen

usw. Hier wurde in der folgenden Abbildung ebenfalls die pragmatische Lösung gewählt.

Abbildung 7.3-5: Anfragebearbeitung
Genauere Modellierung mit XODER und ODER

7.4 Prozesswegweiser

Prozesswegweiser sind ein Hilfsmittel, um Ereignisgesteuerte Prozessketten und damit auch die zugrundeliegenden Geschäftsprozesse zu verknüpfen. Vier Gründe gibt es dafür:

• Unübersichtlichkeit
• Teilprozesse
• Zusammenhang
• Prozessebenen

Große Geschäftsprozesse führen zu großen und eventuell unübersichtlichen Ereignisgesteuerten Prozessketten. Da kann es sinnvoll sein, die EPK in mehrere Teilprozesse aufzuteilen. Hier wird also ein zusammenhängender Geschäftsprozess in mehrere Abschnitte unterteilt. Natürlich muss dann der Gesamtzusammenhang trotzdem ausgedrückt werden.

Unübersichtlichkeit

Die Geschäftsprozesse eines Unternehmens sind nicht isoliert, sondern sie hängen in der Regel zusammen, schließlich sollen sie ja demselben Ziel zugeordnet werden. So kann zum Beispiel nach einer erfolgreichen Angebotsprüfung auf die nachfolgende Leistungserbringung verwiesen werden und nach deren Realisierung auf die Rechnungsstellung usw. Im Gegensatz zum ersten Punkt wird hier also nicht ein großer unübersichtlicher Prozess in Abschnitte zerlegt, sondern verschiedene Prozesse werden in Zusammenhang gebracht.

Zusammenhang

Oftmals werden bestimmte Prozessabschnitte an vielen Stellen in einem Prozess benötigt. Zum Beispiel eine Kalkulationsdurchführung in einem Prozess, der die Machbarketi einer Kundenanfrage prüft. Solche Prozesse können separat modelliert werden. Dann kann an allen benötigten Stellen im Gesamtprozess auf sie verwiesen werden, ohne sie jeweils zu modellieren.

Ausgelagerte Teilprozesse

Dieser Abschnitt führt uns wieder zum Thema Aggregation(von Funktionen), hier unter dem Blickwinkel der vertikalen Dimension der Prozessmodellierung. Vgl. hierzu Abschnitt 12.2 dieses Buches und - eingebettet in das Thema Unternehmensmodellierung - [Staud 2010a]. Auch für diese Aufgabe kann man - u.U. auf mehreren Ebenen - Prozesswegweiser verwenden [Anmerkung] .

Prozessebenen - Prozess in Funktion:

vertikale Dimension der Prozessmodellierung

Tut man dies mit EPKs, enthält ein Prozesswegweiser einer übergeordneten Ebene ganze Prozessabschnitte der untergeordneten. Dies ist auf mehreren Ebenen möglich und wird im Rahmen der Unternehmensmodellierung auch so gemacht [Anmerkung] .

Besonders deutlich wird dies, wenn in einer Geschäftsprozessbeschreibung zum einen der ganz normale Geschäftsprozess beschrieben wird, dann aber auch eine Funktion sehr detailliert. Wie z.B. im Geschäftsprozess Angebotserstellung von Abschnitt 8.1. Hier taucht in der Prozessbeschreibung plötzlich das genaue Regelwerk für die Kalkulation auf. D.h., es wird geklärt, wie die Funktion (Kalkulationsdurchführung intern genau abläuft). Es wird also in der Prozessbeschreibung eine Funktion erläutert. Dies kommt oft vor und sollte so gelöst werden, dass die Funktionsbeschreibung entweder ganz aufgegeben wird (wenn es möglich ist) oder ausgelagert wird. Dann nimmt man die Beschreibung der Funktion in einen eigenen Prozess und verweist auf ihn vom übergeordneten Prozess aus.

Funktion in Prozess:
Beschreibung einer Funktion in der Prozessbeschreibung

Die aufgerufenen Prozesse werden hier Subprozessegenannt, in Anspielung auf die sich hier abzeichnenden Prozessebenen.

Ein Prozess, der eine einzelne Funktion des aufrufenden Prozesses in höherer Detaillierung beschreibt oder der einen Abschnitt des Geschäftsprozesses kapselt, wird als Subprozess bezeichnet. Auf ihn wird dann vom aufrufenden Prozess mit einem Prozesswegweiser verwiesen.

Definition:
Subprozess

Prozesswegweiser

Diese Verknüpfungen von Geschäftsprozessen erfolgen mithilfe sog. Prozesswegweiser, die wie folgt grafisch dargestellt werden:

"Verknüpfen" von Geschäftsprozessen

Die grafische Darstellung setzt sich aus dem Funktionssymbol und dem darunter angeordneten Ereignissymbol zusammen.

Prozesswegweisersetzen somit immer zwei Geschäftsprozesse bzw. ihre Ereignisgesteuerten Prozessketten in Beziehung. Es gibt

Aufrufende
und
aufgerufene EPK

• einen aufrufenden Geschäftsprozess, bzw. eine aufrufende EPK), in der ein Prozesswegweiser den Aufruf eines anderen Geschäftsprozesses signalisiert und
• einen aufgerufenen Geschäftsprozess, bzw. eine aufgerufene EPK), wo ein Prozesswegweiser anzeigt, dass die jeweilige Ereignisgesteuerte Prozesskette aufgerufen wird.

Die Regeln für diese Verweistechniksind wie folgt (vgl. auch die folgende Abbildung):

• Der Prozesswegweiser in der aufrufenden Ereignisgesteuerten Prozesskette gibt a) die Verknüpfungsstelle an und b) welche Ereignisgesteuerte Prozesskette aufgerufen wird. Ersteres erfolgt durch seine Position im Kontrollfluss und durch das vor ihm angeordnete Ereignis. Dieses ist der Auslöser für den Prozesswegweiser und damit für den von ihm dann gestarteten Subprozess. Zweiteres erfolgt durch die Beschriftung des Prozesswegweisers. Sie gibt an, welcher Subprozess aufgerufen wird.
• Der Prozesswegweiser steht im Kontrollfluss der EPK anstelle einer Funktion. Vor ihm ist also ein Ereignis angesiedelt (oder mehrere), das den Prozess anstößt, auf den der Prozesswegweiser verweist. Nach ihm ist entweder wieder ein Ereignis anzutreffen, dann handelt es sich um einen eingebetteten aufgerufenen Prozess (vgl. unten) oder es liegt keines vor, dann findet der Kontrollflusszweig im aufgerufenen Prozess zu seinem Ende. Vgl. dazu die Erläuterungen unten.
• Der Prozesswegweiser in der aufgerufenen Ereignisgesteuerten Prozesskette gibt durch seine Bezeichnung an, von welcher anderen Ereignisgesteuerten Prozesskette der Aufruf erfolgt. Ihm nachgestellt ist das Ereignis, das im aufrufenden Prozess vor dem Prozesswegweiser steht. Im folgenden Beispiel ist dies das Ereignis Kalkulation ist durchzuführen. Waren es im aufrufenden Prozess mehrere Ereignisse, werden im aufgerufenen entsprechend alle wiederholt.
• Mithilfe dieses Ereignisses (dieser Ereignisse), es soll Verknüpfungsereignisgenannt werden, kann man sich das Zusammenführen von aufrufendem und aufgerufenem Prozess vorstellen. Man müsste sie nur bei diesem Ereignis überlappen.

Hier im Beispiel [Anmerkung] geht es um einen Geschäftsprozess Kundenanfragebearbeitung. Irgendwo in diesem Prozess ergibt sich nach dem Ereignis Kalkulation ist durchzuführen die Notwendigkeit, den Geschäftsprozess Kalkulationsdurchführung anzustoßen. Durch den Prozesswegweiser wird auf diesen verwiesen. Im Geschäftsprozess Kalkulationsdurchführung wird das Ereignis Kalkulation ist durchzuführen wiederholt und der Prozess fortgesetzt. Davor wird noch der aufrufende Geschäftsprozess angegeben.

Syntaxregeln für Prozessverknüpfungen durch Prozesswegweiser

Abbildung 7.4-1: Aufrufende und aufgerufene EPK mit Verknüpfungsereignis "Kalkulation ist durchzuführen" - nicht eingebettet

Ein Subprozess wie der obige, dessen Prozesswegweiser am Ende eines Kontrollflusszweiges steht, soll angehängter Prozessgenannt werden.

Ein Prozess, der aufgerufen wird und dessen Kontrollflusszweige im aufgerufenen Prozess enden (der also am Schluss nicht zurückführt in den aufrufenden Prozess), wird angehängter Prozess genannt.

Definition: Angehängter Prozess

Eingefügter Subprozess

Oftmals trifft man in Ereignisgesteuerten Prozessketten allerdings auch die Situation an, dass der aufrufende Prozesswegweiser mitten im Kontrollflusssteht (vgl. die folgende Abbildung) und dass nach seiner Abarbeitung der Geschäftsprozess im aufrufenden Prozess weiter geht. Dies wird wie folgt gelöst:

• Der Aufruf des Prozesses erfolgt genau gleich wie oben.
• Abweichend von oben wird aber, wenn der aufgerufene Prozess abgearbeitet ist, wieder "zurückgesprungen" in den aufrufenden.

Der Rücksprung wird wie folgt modelltechnisch ausgedrückt: Nach dem Schlussereignis im aufgerufenen Prozess wird ein Prozesswegweiser angehängt, der angibt, zu welchem Prozess der Rücksprung erfolgt (zum aufrufenden also). Das Schlussereignis wird auch im aufrufenden Prozess nach dem dortigen Prozesswegweiser wiederholt.

Im Beispiel der folgenden Abbildung ist der Geschäftsprozess Produktion der aufrufende Prozess. Er kommt irgendwann an die Stelle, wo die Beschaffung vorbereitet ist und realisiert werden soll. Hier ist nun die Beschaffung ausgelagert in einen eigenen Prozess (z.B., weil man sie an mehreren Stellen braucht). Modelltechnisch wird dies nun wie oben beschrieben gelöst: Im Prozess Produktion wird ein Prozesswegweiser eingefügt, der den Sprung zum Prozess Beschaffung ausdrückt (auch durch seine Beschriftung). Im Geschäftsprozess Beschaffung steht am Anfang ein Prozesswegweiser mit der Beschriftung Produktion, weil von dort der Aufruf kommt. Danach wird das Ereignis eingefügt, das im aufrufenden Prozess vor dem Prozesswegweiser stand, Beschaffung ist vorbereitet. Dies ist sozusagen im aufgerufenen Prozess das Startereignis.

Eingefügter Subprozess: Beispiel

Nun folgt der eigentliche Prozess Beschaffung, hier angedeutet durch Punkte. Irgendwann ist die Beschaffung durchgeführt, signalisiert durch das entsprechende Schlussereignis (Beschaffung ist durchgeführt). Nach diesem wird dann der Prozesswegweiser eingefügt, der den Rücksprung signalisiert. Er ist mit Produktion beschriftet, weil dorthin der Kontrollfluss zurückgeht. Dort, im aufrufenden Prozess, wird das Ereignis Beschaffung ist durchgeführt nach dem Prozesswegweiser eingefügt.

Abbildung 7.4-2: Prozesswegweiser im Kontrollfluss - Eingefügter Subprozess

Solche Subprozesse sollen eingefügte Subprozessegenannt werden.

Ein Prozess, der aufgerufen wird und dessen Kontrollfluss nach seiner Beendigung wieder in den aufrufenden Geschäftsprozess zurückführt, wird eingefügter Suprozess genannt.

Definition: Eingefügter Prozess

Ein weiteres Beispiel für den Einsatz von Prozesswegweisern liegt in Abschnitt 8.4 vor (Abbildung 8.4-3).

7.5 Keine falschen Schlussereignisse

Ein häufig anzutreffender Fehler in der EPK-Modellierung ist, dass bei einer ODER- bzw. XODER-Verzweigung vergessen wird, die einzelnen Zweige wieder korrekt zusammenzuführen. Oft wird dann nur mit einem Zweig der Kontrollflussweitergeführt. Die folgende Abbildung zeigt ein solches fehlerhaftes Beispiel.

Falsches Schlussereignis

Abbildung 7.5-1: Fehlerhafte Weiterführung des Kontrollflusses

Hier wird, nach dem Verschicken der Buchsendung, von einem der alternativen Ergebnisereignisse aus der Kontrollfluss weitergeführt. Die anderen Ereignisse werden syntaktisch zu Schlussereignissen. Dies ist natürlich nicht korrekt. Tritt bei einem Prozessdurchgang eines der anderen Ereignisse ein, sieht zumindest das Modell keinen Fortgang vor. Deshalb gilt folgende Regel:

Weiterführung?

Syntaxregel

Geht es im Kontrollfluss nach einer ODER- bzw. XODER-Verzweigung einheitlich (in einem Kontrollflusszweig) weiter, müssen alle Zweige zusammengefasst werden, bevor die weiteren Funktionen und Ereignisse angehängt werden.

Für obiges Beispiel sieht damit die korrekte Gestaltung der EPK wie in der folgenden Abbildung aus. Die drei Kanten werden mit dem XODER-Operator zusammengefasst, weil sie mit ihm auch aufgeteilt wurden. Natürlich sind normalerweise zwischen den beiden Operatoren (hier XODER, ansonsten auch ODER) noch Funktionen und Ereignisse angesiedelt. Dies wurde hier aus Platzgründen vermieden.

Korrekte Lösung

Abbildung 7.5-2: Korrekte Weiterführung des Kontrollflusses

Eine andere Situation liegt bei einem UND-Operator vor. Hier wird tatsächlich sehr oft der Kontrollflussnur bei einem Zweig fortgeführt. Dies ist möglich, da der UND-Operator ja sowieso verlangt, dass alle Zweige fortgesetzt werden (vgl. die folgende Abbildung).

Abbildung 7.5-3: Weiterführung nach UND-Verknüpfung

Im obigen Beispiel sei an die Situation am Ende der Erstellung eines Buchmanuskripts gedacht. Die Abschlusskontrolle wird - vereinfacht - modelliert als ein Vorgang bei dem die Seitenformatierung geprüft, die Kopfzeilen kontrolliert und der Index neu erstellt wird. Der UND-Operator signalisiert, dass alle drei Ereignisse eintreten müssen. Der weitere Verlauf ist dann klar, auch wenn nur ein einziger Kontrollflusszweig weitergeführt wird.

7.6 Organisationseinheiten - unklar

Liegen mehrere Organisationseinheiten bei einer Funktion vor, die gemeinsam die Aufgabe erledigen, so fügt man sie meist mit mehreren Symbolen an. Manchmal sieht man auch, dass mehrere "Zuständige" in ein Symbol geschrieben werden.

Mehrere gemeinsam

Abbildung 7.6-1: Angabe von Organisationseinheiten bei gemeinsamer Erledigung - Beispiel Zoo

Oftmals liest man in Prozessbeschreibungen oder hört bei der Erhebung von Prozessen, dass Abteilungen in unterschiedlichen Konstellationen eine Aufgabe bewältigen. Z.B. Abteilung A erledigt dies mit Abteilung C oder mit Abteilung D und E. Dies kann in EPKs nur so modelliert werden, dass diese Beschreibung in den Text der Organisationseinheit genommen wird:

Unklare Zusammenarbeit

Vgl. hierzu auch das Beispiel in Abbildung 8.1-4

Abbildung 7.6-2: Angabe von Organisationseinheiten bei nicht exakt feststehender Zusammenarbeit - Beispiel Zoo

Eine solche unklare Fixierung kann in einer Standardprozessmodellierung akzeptiert werden. Zielt die Prozessmodellierung aber in Richtung Workflow oder in Richtung Programmierung, muss die Situation exakter geklärt werden.

Ganz allgemein kann festgehalten werden: Es sind keine ODER- bzw. XODER-Verknüpfungen zwischen Organisationseinheiten einer Funktion vorgesehen [Anmerkung] . Will man eine solche Konstellation trotzdem ausdrücken, muss man a) durch eine "Funktion klären lassen" wer u.U. zusammenarbeitet und b) für jede Variante einen eigenen Kontrollflusszweig anlegen.

Kein ODER bzw. XODER zwischen Organisations­einheiten

Liegt ein automatisierter Prozessabschnitt vor, kann bei der Funktion die Anwendungssoftware angegeben werden, durch die die Aufgabe erfüllt wird. Ist der gesamte Prozess automatisiert, sollte dies nur einmal festgehalten werden.

Automatisierung durch Anwendungssoftware

7.7 Informationsobjekte - abstrahiert

Ähnlich wie bei Organisationseinheiten ergibt es sich manchmal, dass alternative Informationsobjekte vorliegen. Nicht so sehr aus den Notwendigkeiten des Geschäftsprozesses, sondern um das Prozessmodell übersichtlich zu halten. Z.B. so wie im Beispiel von Abschnitt 8.1, Abbildung 8.1-1. Hier liegen zahlreiche unterschiedliche Anfragen vor, für die man jeweils die nächsten Funktionen mit unterschiedlichen Informationsobjekten getrennt gestalten müsste. Dies kann man umgehen, indem man das Informationsobjekt "abstrahiert", so wie im genannten Beispiel oder auf andere Weise ausdrückt, dass in einem Informationsobjekt eigentlich mehrere andere stecken ("Anfrage (Brief, Mail)").

Alternative Informationsobjekte

7.8 Pragmatismus

Sehr oft wird in diesem Buch darauf verwiesen, dass auch pragmatische Überlegungen die Prozessmodellierung begleiten. Dies meint verschiedenes. Zum einen den Verzicht auf die Exaktheit einer formalen Sprache, was damit zu tun hat, dass Prozessmodellierung ja Vorgänge der realen Welt betrifft, die u.U. nicht in vollem Umfang formal gefasst werden können. Zum anderen das Ziel, die Prozessmodelle übersichtlich zu halten.

Pragmatik bei der Erstellung von EPKs

Bei Sprüngen nach flussaufwärts im Kontrollfluss (Rücksprünge) und den dabei entstehenden Schleifen kann man in der EPK die Zahl der Rücksprünge kontrollieren und z.B. nach einer bestimmten Anzahl abbrechen (vgl. Abbildung 6.8), wenn es dazu Geschäftsregeln gibt und wenn diese das verlangen. Oftmals wird dies aber nicht getan, sondern es wird einfach nur die Schleife ohne Kontrolle angelegt (vgl. Abbildung 6.8-1) oder es wird sogar der zu wiederholende Prozessabschnitt einfach ein weiteres Mal ins Modell eingefügt (Abbildung 6.8-2).

Schleifen ohne Rücksprungkontrolle

In beiden Fällen verzichtet man also darauf, die maximale Zahl der Wiederholungen im Modell zu verankern. Im ersten Fall könnte dies zu einer "Endlosschleife" führen, wie wir sie aus der Programmierung kennen. Im zweiten Fall könnte, bei enger Auslegung des Modells, nur einmal wiederholt werden. Beides ist natürlich nicht sinnvoll. Dieser Verzicht auf formale Präzisierung ist Ausdruck von Pragmatismus, denn es ist nun mal so, dass Menschen (zumindest im Rahmen von Geschäftsprozessen) nicht in Endlosschleifen verfallen oder maximal einmal die Chance zur Korrektur bekommen, weshalb solche Strukturmerkmale hier nicht unbedingt per Syntax abgesichert werden müssen.

Verzicht auf Fixierung der maximalen Anzahl an Wiederholungen

Die pragmatische Entscheidung bedeutet hier also den bewussten Verzicht auf Exaktheit im formalen Sinn.

Betrachten wir als zweites Beispiel das Konstrukt des Zeitfensters, wie in Abschnitt 6.3 und Abbildung 6.3-1 beschrieben. Hier liegen zwei UND-Operatoren vor. Mit dem ersten beginnt, mit dem zweiten endet der Prozessabschnitt, der hier Zeitfenster genannt wird. Zwischen den Operatoren liegen Aktivitäten, die alle gemeinsam starten und die alle beendigt sein müssen, bevor es über den zweiten UND-Operator in einem Kontrollflusszweig weiter geht.

Zeitfenster

Oftmals gibt es aber zwischen den Tätigkeiten einen Zusammenhang. Zum Beispiel eine bestimmte Reihenfolge, oder auch den Zwang nach einer bestimmten Funktion nochmals eine andere zu Tätigen. Die Modellierung dieser Semantik über das Zeitfenster bedeutet den Verzicht auf die Modellierung solcher Zusammenhänge zwischen den Tätigkeiten (Funktionen). Die Ereignisgesteuerte Prozesskette zählt die Aufgaben nur auf. Auch hier bedeutet also die pragmatische Entscheidung also den bewussten Verzicht auf formale Exaktheit.

Pragmatik:

Nicht beachtete Zusammenhänge

Es kommt vor, dass beim Zusammenfügen von Kontrollflusszweigen sehr viele Funktionen mit je einem nachfolgenden Ereignis (Ergebnisereignis) vorliegen. Dann hat man die Wahl: Lässt man tatsächlich für jede Funktion ein Ereignis stehen oder fasst man die Kanten gleich nach den Funktionen zusammen und fügt dann nach dem Operator ein einziges Ergebnisereignis für alle Funktionen ein. Dies kann dann nur ein abstrahiertes sein. Damit liegt dann wieder eine pragmatische Entscheidung vor. Auf die Ergebnisereignisse der einzelnen Funktionen wird verzichtet, es wird ein gemeinsames abstrahiertes Ergebnisereignis gewählt.

Verzicht auf Einzel-Ergebnisereignisse

Normalerweise wird in einer Funktion entweder nach der Logik des ODER-Operators oder nach der des XODER-Operators entschieden. Im Fall der in Abschnitt 7.3 angesprochenen Korrektur der ungenauen Modellierung mit dem ODER-Operator wird aber sehr oft die dort beschriebenen Lösung gewählt. In einer Funktion finden - sozusagen - beide Entscheidungen statt. Zuerst die mit dem Charakter einer Alternative, dann die nach dem OPDR-Operator. Auch hier bedeutet also die pragmatische Lösung einen Verzicht auf Genauigkeit.

"Operatoren-
verschmelzung"

Soweit einige Beispiele. Sie sollten klar machen, dass man in der Prozessmodellierung sehr oft pragmatische Lösungen finden kann und muss. Man sollte allerdings die Pragmatik nicht dazu verwenden, schlampig zu modellieren.

8 Beispiele

In diesem Kapitel werden Modellierungsbeispiele vorgestellt. Sie stellten ursprünglich reale Geschäftsprozesse dar (oder Teile davon), wurden aber für dieses Buch abstrahiert und in didaktischer Hinsicht verändert und ergänzt.

Einige der Ereignisgesteuerten Prozessketten erstrecken sich über mehrere Seiten. In einem solchen Fall wird das Ende der vorangehenden zu Beginn der nachfolgenden EPK wiederholt. Damit sollte der Zusammenhang zwischen den beiden Fragmenten klar sein.

EPKs über mehrere Seiten

8.1 Angebotserstellung

Für die folgende Ereignisgesteuerte Prozesskette liegt zum einen eine inhaltliche Beschreibung vor (die Semantik des Geschäftsprozesses), zum anderen ein Text, der die Erstellung der EPK beschreibt. Die inhaltliche Beschreibung ist eingerückt. Um die Bezüge zwischen der Beschreibung der Erstellung und den Abbildungen einfacher herstellen zu können, wurden in die Abbildungen Nummern eingefügt, auf die im Text verwiesen wird.

Angebotserstellung im Anlagenbau

Prozessbeschreibung

Gestartet wird der Geschäftsprozess aufgrund einer Kundenanfrage. Diese kann per Postbrief, per Telefax, per E-Mail oder telefonisch eingehen. Falls sie telefonisch eingeht, erstellt der Vertrieb ein schriftliches Dokument, das die Anfrage festhält (Anfragefixierung) Unabhängig von der Art des Eingangs nimmt das Zentralsekretariat die Anfrage entgegen, prüft sie auf formale Korrektheit und leitet sie dann an den zuständigen Vertriebsbereichsleiter und die Geschäftsleitung weiter.

Start

Umsetzung als EPK

Dieses Anfangsszenario wurde durch entsprechende Startereignisse modelliert, die durch einen XODER-Operator verknüpft sind. Nach dem Eingang der telefonischen Anfrage wird die geforderte textliche Fixierung als Funktion modelliert. Bei jeder Anfrageart entsteht ein Informationsobjekt, das bei der dem Operator nachfolgenden Funktion angeführt wird - lesend, da es ja wahrgenommen und interpretiert werden muss. Hier muss auch die erste Organisationseinheit angeführt werden.

Anfangsszenario

Im Anschluss wird in der Prozessbeschreibung gefordert, dass das Angebot an den zuständigen Vertriebsbereichsleiter (VBL) und die Geschäftsleitung (GL) weitergeleitet wird. Dies kann so wie hier realisiert werden: durch einen UND-Operator, dem die Tätigkeiten folgen (Position 2). Vgl. zu diesem Muster auch Abschnitt 6.2. Hier sind die Organisationseinheiten nicht angegeben, weil sie gleich sind wie in der vorangegangenen Funktion . Die Transportvorgänge selbst wurden explizit modelliert, also durch eine eigene Funktion (vgl. zum Thema Informationstransport Abschnitt 7.1).

Muster "Mehrere Tätigkeiten anstoßen"

Prozessbeschreibung - Fortsetzung

Der Vertriebsbereichsleiter gibt die Anfrage an einen seiner Vertriebsingenieure weiter, der die Angebotsrealisierbarkeit prüft. Dies betrifft zunächst das angefragte Leistungsspektrum. Liegt dieses nicht innerhalb des Leistungsspektrums des Unternehmens, erfolgt eine Absage. Können nur Teile der angefragten Leistungen erbracht werden, werden Partnerunternehmen um Unterstützung angefragt und entweder als Kooperationspartner oder Subunternehmer eingebunden. Finden sich keine geeigneten Partner, wird die Anfrage abgelehnt.

Umsetzung als EPK

Die Weiterleitung der Anfrage (ein Transportvorgang) wurde wiederum durch eine Funktion modelliert. Die Prüfung ebenso, mit drei möglichen Ergebnissen, die durch XODER verknüpft sind (Position (3)). Der Text deutet an, dass die Prüfung mehrstufig ist und dass es im ersten Schritt um das angefragte Leistungsspektrum geht. Dieses kann in vollem Umfang, teilweise oder gar nicht ("nicht realisierbar") mit dem Leistungsspektrum des Unternehmens übereinstimmen. Entsprechend sind die Ergebnisereignisse formuliert. Nach dem Ereignis Nicht realisierbar (Position 3) kann dann gleich eine Funktion folgen, in der die Absage formuliert wird. Daraus ergibt sich dann ein erstes Schlussereignis: Anfrage abgelehnt.

Prüfung und erstes Schlussereignis

Die in der Prozessbeschreibung beschriebene Anfrage bei Partnerunternehmen wurde einfach als Funktion modelliert, mit einem positiven und einem negativen Ergebnis. Im Falle des negativen Ergebnisses wird die Anfrage abgelehnt und ein weiteres Schlussereignis tritt ein. Dies ist eine eher oberflächliche Art der Modellierung. Eine detailliertere Modellierung könnte so aussehen, dass jede einzelne Anfrage bei einem potentiellen Partner als Funktion in einer Schleife erfasst würde. Die Schleife wäre erst dann fertig, wenn alle potentiellen Partner gefragt worden wären - mit einem positiven oder einem negativen Ergebnis.

Alternative:
Mehr Detaillierung

Abbildung 8.1-1: Angebotserstellung für Anlagen, Teil 1 - Klärung offener Fragen oder frühes Ende

Anmerkungen:

- Alternative Startereignisse

- Muster Teilaufgaben und Tätigkeiten starten

Im Geschäftsprozess bleiben somit aus den obigen Schritten zwei mögliche positive Ergebnisse, die beide den Fortgang zulassen. Im Kontrollfluss der EPK müssen diese Zweige zusammengeführt werden. Dies geschieht durch einen XODER-Operator, getreu der Regel, dass mit dem Operator zusammengeführt wird, mit dem flussaufwärts aufgeteilt wurde (vgl. Abschnitt 7.2).

Zusammenführung von Kontrollflusszweigen

Prozessbeschreibung - Fortsetzung

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

Umsetzung in die EPK - Fortsetzung

Die Prüfung der Angebotslegungsfrist (4) führt zu einer Funktion und zwei Ergebnisereignissen. Genauso die Prüfung der Kapazität der Ingenieurgruppe. Beide Funktionen werden durch ein logisches UND verknüpft, da sie gleichzeitig angestoßen werden. Hier liegt also wieder das Muster "Tätigkeiten starten" vor (siehe auch Abschnitt 6.2).

Die insgesamt vier möglichen Ergebnisse werden nun folgendermaßen in Beziehung gesetzt:

Semantik sucht Syntax

• Treten die Ereignisse Angebotslegungsfrist nicht realisierbar und Kapazitäten vorhanden ein, wird um eine Fristverlängerung gebeten. Dies wird in der Ereignisgesteuerten Prozesskette dadurch realisiert, dass die beiden von diesen Ereignissen kommenden Kontrollflüsse mit einem logischen UND verknüpft werden (6). Danach wird dann die entsprechende Funktion (Fristverlängerung erbitten) angefügt (vgl. Abbildung 8.1-2). Dies entspricht dem Muster "Bedingungen für eine nachfolgende Tätigkeit" (vgl. Abschnitt 6.2).
• Falls sich ergibt, dass die Kapazität der Ingenieurgruppe nicht reicht (Kapazität Ingenieure nicht vorhanden), wird die Anfrage abgelehnt, unabhängig davon, welches Ergebnis die Prüfung der Angebotslegungsfrist erbrachte.
• Wenn beide Prüfungen positiv ausfallen geht es weiter im Geschäftsprozess. Um diese Semantik in die EPK zu bringen, müssen die von diesen beiden Ereignissen kommenden Kontrollflusszweige durch UND verknüpft werden (5).

Abbildung 8.1-2: Angebotserstellung für Anlagen, Teil 2

Zum positiven Fortgang kommt es auch, wenn die Fristverlängerung gewährt wird. Auch für diese Semantik muss wieder ein UND-Operator eingefügt werden, der die beiden Ereignisse Angebotslegungsfrist realisierbar und Fristverlängerung gewährt verknüpft (Muster Bedingungen für Fortgang, vgl. Abschnitt 6.5).

Bleibt noch die Absage im Falle einer Nichtgewährung der Fristverlängerung. Diese wird einfach an das entsprechende Ereignis angehängt. Auch hier liegt dann wieder ein Schlussereignis vor. Die vielen Schlussereignisse legen den Gedanken nahe, die Absage in eine andere Ereignisgesteuerte Prozesskette zu verlegen und dorthin mit Hilfe von Prozesswegweisern zu verweisen (vgl. Abschnitt 7.4). Dies ist möglich. Sinnvoll wäre es hier aber nur, wenn das Absagen der Anfrage aufwändiger wäre, wenn also mehr Funktionen usw. vorlägen.

Viele Schlussereignisse

In obigem Abschnitt schimmert das Muster Kombinatorik durch. Vgl. dazu Abschnitt 6.5 und das Zoo-Beispiel in Abschnitt 8.4.

Prozessbeschreibung - Fortsetzung

Sind alle zu prüfenden Kriterien erfüllt, erfolgt die eigentliche Angebotserstellung. Dies geschieht in der Regel unter Einbeziehung der Mitarbeiter aus den relevanten Geschäftsbereichen oder der Geschäftsbereichsleiter, die z. B. bei der Stunden- und Kostenschätzung von angefragten Ingenieurstätigkeiten mitwirken und mögliche, verfügbare Ingenieure als Projektleiter und Ingenieure vorschlagen.

Die Angebotsdaten werden durch Vertriebsmitarbeiter in der Angebotsdatenbank erfasst, ein Programm (Report Generator Angebot; RepGenA) erzeugt dann die textliche Ausformulierung des Angebots für den anfragenden Kunden.

Abbildung 8.1-3: Angebotserstellung für Anlagen, Teil 3

Umsetzung in die EPK - Fortsetzung

Die Angebotserstellung wird als Funktion modelliert für die die Anfrage Informationen liefert und aus der das Informationsobjekt Angebot entsteht. Die Ausführungen zu Stunden- und Kostenschätzungen usw. sind Funktionsaspekte und nicht Prozessaspekte [Anmerkung] und können deshalb bei einer Istanalyse ignoriert werden.

Prozess- vs. Funktions-
modellierung

Die im Text etwas unklaren Angaben zu den zuständigen Personen werden mit einer Organisationseinheit entsprechend an die Funktion angefügt. Solche nicht ganz präzisen Angaben bei Zuständigkeiten kommen bei Istanalysen häufig vor. Hier lohnt sich eine Präzisierung in solchen Fällen oftmals nicht.

Informationsobjekte werden durch eine Linie mit Funktionen verknüpft. Lesend: Pfeilspitze zur Funktion. Schreibend: Pfeilspitze zum Informationsobjekt. Transport: ohne Pfeilspitze. Vgl. die Abschnitte 3.6 und 7.1.

Erinnerung

In der nachfolgenden Funktion Angebotsdaten erfassen wird dann das Informationsobjekt Angebot gelesen und ein weiteres geschrieben, ein Eintrag in eine Datenbank mit allen Angeboten, die im Unternehmen erstellt werden (Angebot in Datenbank). Aus diesem Datenbankeintrag heraus entsteht dann mit Hilfe des Reportgenerators Angebote (RepGenA) die textliche Fassung des Angebots (Angebot textlich). Diese Funktion wird also von einem Programm durchgeführt, aber natürlich von einem Menschen gestartet. Hier soll angenommen werden, dass die vorige Funktion nach Abschluss ihrer Aktivitäten diesen Startvorgang durchführt.

Lesen und Schreiben

Prozessbeschreibung - Fortsetzung

Zustellung und Warten

Das fertige Angebot wird durch den zuständigen Vertriebsingenieur dem Kunden zugeschickt. Danach muss die Entscheidung des Kunden abgewartet werden. Üblicherweise erteilt der Kunde den Auftrag entweder sofort aufgrund des Angebots oder er lädt zunächst zu einem oder mehreren Vergabegesprächen ein. Diese Angebotsverhandlungen werden in der Regel vom zuständigen Vertriebsingenieur oder Vertriebsbereichsleiter und dem im Angebot genannten Projektleiter geführt. Die Ergebnisse dieser Vergabegespräche dienen dann als Grundlage für die Entscheidung im anfragenden Unternehmen.

Trifft eine Absage ein, bestätigt dies der zuständige Vertriebsingenieur. Er ist außerdem verpflichtet, durch Nachfragen beim Kunden oder sonstigen Verbindungsleuten die Gründe für die Absage in Erfahrung zu bringen, falls dies nicht schon aus dem Absageschreiben hervorgeht. Dies dient dazu, die Informationsbasis für zukünftige Angebote bei diesem Kunden zu verbessern.

Umsetzung in die EPK - Fortsetzung

Obiger Text beschreibt zuerst den Transportvorgang, der das Angebot zum Kunden bringt. Hier wurde wieder das zu transportierende Informationsobjekt ohne Richtungspfeil an die Funktion angehängt.

Danach liegt eine Wartesituationvor (8), die ebenfalls durch eine Funktion modelliert wird. Das positive Ergebnis, Auftrag erteilt, ist gleichzeitig auch ein Schlussereignis dieses Geschäftsprozesses. Nach diesem ist der Prozesswegweiser zum Geschäftsprozess Auftragsstart angefügt, der im folgenden Abschnitt beschrieben wird.

Muster Warten

Die beiden anderen vorgedachten Ergebnisse sind Vergabegespräche und Absage. Die Vergabegespräche sind nach dem entsprechenden Ereignis eingefügt. Das textliche Angebot wird gelesen und beschrieben, deshalb der Doppelpfeil. Es kann angenommen werden, dass das Angebot in der Datenbank auch an die Verhandlungsergebnisse angepasst wird, deshalb wurde es hier auch an die Funktion angefügt. Die Organisationseinheit wurde entsprechend der Prozessbeschreibung gestaltet. Solche Angaben sind in Istanalysen durchaus üblich. Die Formulierung "eine oder mehrere" wird durch die Rückschleife in der EPK umgesetzt.

Gemäß der Prozessbeschreibung wird im Falle einer Absage nicht nur die Absage bestätigt, was einfach durch eine Funktion geschieht, sondern auch u.U. nachgefragt. Die diesbezügliche Formulierung

"...falls dies nicht schon aus dem Absageschreiben hervorgeht"

kann dadurch umgesetzt werden, dass einfach eine entsprechende Prüfung eingebaut wird.

Abbildung 8.1-4: Angebotserstellung für Anlagen, Teil 4

Soweit der Geschäftsprozess Angebotserstellung, der damit endet. Im positiven Fall stößt er den nachfolgend skizzierten Geschäftsprozess Auftragsstart an.

8.2 Auftragsstart

Die Beschreibung des Geschäftsprozesses beginnt mit dem Eingang des Auftrags. Der Auftrag des Kunden folgt meist einer vorangegangenen Angebotserstellung, wie im vorigen Abschnitt gezeigt. Hin und wieder kommt es vor, dass ohne einen solchen Prozess ein Auftrag eingeht. Zum Beispiel, wenn erst kurz zuvor ein vergleichbarer Auftrag ausgeführt wurde.

Auftragsstart im Anlagenbau

Prozessbeschreibung

Nach Eingang des Auftrags prüft der Vertriebsingenieur (VI), ob der Auftrag mit sämtlichen ausgehandelten Konditionen bzw. dem Angebot übereinstimmt.

Gibt es im Auftrag des Kunden Abweichungen vom Angebot werden diese in der Auftragsbestätigung durch für das Unternehmen akzeptable Konditionen ersetzt. Dies wird dem Kunden mitgeteilt und er wird gebeten, die Kenntnisnahme schriftlich zu bestätigen. Lehnt der Kunde ab, wird der Auftrag abgelehnt.

Umsetzung in die EPK

Damit ist die Anfangssequenz (vgl. die folgende Abbildung) mit einem Prozesswegweiser und einem Startereignis festgelegt. Die Auftragsklärung wird zu einer Funktion (Prüfung auf Konditionen usw.), die vom Vertriebsingenieur realisiert wird. Ergibt die Prüfung keine Abweichungen schreitet der Geschäftsprozess voran zum Start zweier Funktionen (nächste Abbildung).

Ergibt die Prüfung Abweichungen vom Angebot werden diese durch akzeptable Konditionen ersetzt. Dies führt zu einer entsprechenden Funktion mit dem Informationsobjekt Auftrag und der Organisationseinheit Vertriebsingenieur [Anmerkung] . Bei dieser Ersetzung wird das Informationsobjekt Auftrag verändert. Das Zusenden des Angebots, das dann nötig wird und das Warten auf die Kundenreaktion wurde als Funktion mit einem nachfolgenden XODER-Operator modelliert.

Falls der Kunde die Ersetzung der Konditionen akzeptiert, wird der Kontrollfluss wieder mit dem positiven Ergebnis der Prüfung zusammengeführt. Falls er ablehnt, kommt es zur Ablehnung des Auftrags und danach zu einem ersten Schlussereignis.

Abbildung 8.2-1: Auftragsstart im Anlagenbau, Teil 1 - Auftragseingang und Prüfung

Prozessbeschreibung - Fortsetzung

Der Vertriebsingenieur (VI) füllt dann im ERP-System ein Auftragsstammblatt aus, wobei im Vertrieb gleichzeitig zentral die Auftragsnummer vergeben wird, die auch ins Auftragsstammblatt eingetragen wird.

Das Controllingträgt die im Angebot bzw. im Auftrag festgelegte Kostenstruktur nach Honorar, Sachkosten, Reisekosten und Fremdleistungskosten auf dem Auftragsstammblatt ein und versieht es mit Vorgaben für Budget, Ressourcenplanung, Reisekosten und Zahlungsplan.

Prozess- vs. Funktions-
modellierung

Umsetzung in die EPK - Fortsetzung

Vorstehender Text signalisiert, dass im positiven Fortgang des Geschäftsprozesses zwei Tätigkeiten angestoßen werden. Entsprechend wurde dies mit einem UND-Operator und zwei Funktionen in der Ereignisgesteuerten Prozesskette modelliert. Die eine wird vom VI, die andere durch die Abteilung Vertrieb realisiert. Beide beschreiben das Informationsobjekt Auftragsstammblatt.

Nach den dann folgenden Ereignissen können die beiden Kontrollflusszweige wieder zusammengeführt werden. Anschließend folgt die im obigen Text angeführte "Vermerkung" der Kostenstruktur mit der Organisationseinheit Controlling. Hier ist im Text wiederum die konkrete Ausführung der Funktion angedeutet. Der Prozessanteil besteht hier nur aus einer Funktion, daneben ist ein Stück weit die Ausführung der Funktion beschrieben. Dies muss man erkennen, wenn man eine Prozessbeschreibung bekommt: Was ist Prozess, was ist Funktionsausführung. Vgl. hierzu auch Abschnitt 12.2 und ein deutlicheres Beispiel gleich hier unten.

Was ist Prozess, was ist Funktion?

Prozessbeschreibung - Fortsetzung

Das Controlling erstellt eine Stundenvorgabe für den Projektleiter, die sich folgendermaßen errechnet: Vom beauftragten Honorar werden zunächst die Fremdleistungen und die geplanten Sachkosten (Reisekosten, Kopierkosten etc.) abgezogen. Nach Abzug eines Gewinns und einer Sicherheitsmarge in Höhe von ca. 16% ergeben sich die verfügbaren Personalkosten. Diese werden durch den Kostensatz der jeweiligen Mitarbeitergruppe geteilt. So ergibt sich die Stundenvorgabe je Mitarbeitergruppe. Alle Ingenieure im Haus sind nach den Jahren ihrer Berufserfahrung unterschiedlichen Gruppen zugeordnet. Jede Gruppe wird zu einem bestimmten Erlösstundensatz abgerechnet bzw. Kostenstundensatz belastet. Ebenso werden Sekretärinnen, studentische Hilfskräfte, Übersetzer, Technische Zeichner usw. mit bestimmten Kostensätzen eingerechnet.

Dabei werden drei Stufen unterschieden. Der erste Kostensatz ergibt sich aus dem jeweiligen Gehalt des Mitarbeiters. Die Hinzurechnung der direkten bereichsspezifischen Gemeinkosten ergibt den zweiten Kostensatz. Die weitere Addition des unternehmensspezifischen Gemeinkostensatzes ergibt den endgültigen dritten Kostensatz.

Umsetzung in die EPK - Fortsetzung

In obigem Text ist zweierlei vermerkt. Zum einen ein betriebswirtschaftlicher Vorgang, die Erstellung der Stundenvorgabe, zum anderen ein Regelwerk zur Bestimmung der Stundenvorgabe. Dies ist nichts anderes als die Beschreibung der Funktion. Diese eignet sich nicht für die Prozessmodellierung in einer Ereignisgesteuerten Prozesskette, sondern gibt an, wie die Funktion realisiert werden sollte. Wir haben es hier also wieder und viel deutlicher als oben mit dem Gegensatz von Prozess- und Funktionsmodellierung zu tun.

Prozess- vs. Funktions-
modellierung

Prozessmodellierung vs. Funktionsmodellierung

Bei der Erhebung eines Geschäftsprozesses bekommt man nicht immer nur Hinweise auf den Prozessablauf, sondern auch auf die Realisierung einzelner Funktionen. Dies muss man erkennen und das festgelegte Beschreibungsniveau einhalten [Anmerkung] .

Unter Beachtung dieser Regel entsteht hier für die Erstellung der Stundenvorgabe eine einzige entsprechende Funktion mit einem Ereignis. Das Regelwerk (die Funktionsbeschreibung) wurde als Informationsobjekt modelliert, das in die Funktion einfließt.

Prozessbeschreibung - Fortsetzung

Das Controlling ermittelt die Rechnungsstellungstermine aufgrund der vertraglichen Vereinbarungen. Bei Honorar nach Aufwand wird nur der Abrechnungsmodus (wöchentlich, monatlich, vierteljährlich, usw.) vermerkt. Bei Pauschalaufträgen sind die Rechnungsstellungstermine in der Regel an den Projektfortschritt gekoppelt und fallen mit Meilensteinen der Projektabwicklung zusammen. Bei den Rechnungsstellungsterminen für diese Aufträge werden die abzurechnenden Beträge bzw. der Prozentanteil des Honorars vermerkt.

Nach Ermittlung der Rechnungsstellungstermine werden dem Kunden durch den Vertrieb die Zahlungstermine mitgeteilt. Parallel hierzu erfolgt die Anlage des Auftrags im Produktionsplanungssystem (PPS) durch das Controlling.

Umsetzung in die EPK - Fortsetzung

Obiger Text verlangt zuerst eine Funktion, in der die Klärung der Vertragsstruktur erfolgt. Die beiden Möglichkeiten der Honorargestaltung werden dann als alternative Ergebnisereignisse dieser Funktion modelliert: Honorar nach Aufwand oder Pauschalauftrag.

Nachfolgend dann die Funktionen, die der Text verlangt: die Vermerkung des Abrechnungsmodus auf der einen Seite und die Festlegung der Rechnungstermine einschließlich der Honoraranteile auf der anderen. Das Informationsobjekt bei diesen beiden Funktionen ist aus dem Text nicht ersichtlich, es wurde ergänzt. Im Anschluss daran kann der Kontrollfluss wieder zusammengeführt werden.

Ermittlung der Stundenvorgabe in einer einzigen Funktion

Abbildung 8.2-2: Auftragsstart im Anlagenbau, Teil 2 - Prüfungen

Der zweite obige Absatz führt wieder zu zwei "parallel" anzustoßenden Funktionen. Dies kann mit einem UND-Operator erfolgen, wie es die folgende Abbildung zeigt (unten).

Die beiden anzustoßenden Funktionen sind Zahlungstermine mitteilen und Anlage Auftrag im PPS. Geht es nach einer Aufteilung des Kontrollflusses durch einen UND-Operator in einem Fluss weiter, können die Kontrollflusszweige wieder zusammengeführt werden (müssen aber nicht). Hier wurde darauf verzichtet, sodass nur ein Zweig weiter führt, wodurch der andere aber nicht Schlussereignis wird (vgl. Abschnitt 7.5).

Kein Schlussereignis

Prozessbeschreibung - Fortsetzung

Das durch die Abteilung Auftragsabwicklung vervollständigte Auftragsstammblatt wird zur Erstellung der Auftragsmeldung an den Vertrieb zurückgegeben.

Die ausgedruckte Auftragsmeldung wird mit den entsprechenden Anlagen (Angebot, Vertrag und sonstige für die Vertragsausführung erforderlichen Dokumente) archiviert. Außerdem werden vom Controlling Kopien an den für die Bearbeitung zuständigen Technikbereich weitergeleitet.

Umsetzung in die EPK - Fortsetzung

Der erste Absatz oben erfordert drei Funktionen: die Vervollständigung des Auftragsstammblatts durch die Auftragsabwicklung, die Weiterleitung zum Vertrieb und die Erstellung der Auftragsmeldung durch den Vertrieb. Der Informationstransport wurde durch eine Linie ohne Pfeilspitze verdeutlicht. Bei der Funktion Erstellung Auftragsmeldung wurde ein entstehendes Informationsobjekt angefügt.

Transport von Informationsobjekten

Der zweite obige Absatz fordert zwei parallel [Anmerkung] anzustoßende Funktionen. Der Vertrieb realisiert Auftragsmeldung archivieren, das Controlling Kopien an Technikbereich weiterleiten. Mit den nachfolgenden Ereignissen kommen diese Zweige an ihr Ende, der Geschäftsprozess geht aber - begründet durch den aufteilenden UND-Operator - noch weiter.

Abbildung 8.2-3: Auftragsstart im Anlagenbau, Teil 3 - Anlegen und archivieren

Prozessbeschreibung - Fortsetzung

Parallel zur internen Meldung über die Vervollständigung des Auftragsstammblatts hat der Vertriebsingenieur die externe Auftragsbestätigung an den Kunden zu erstellen.

Erfolgte der Auftrag schriftlich und hat der Auftraggeber bereits eine Auftragsbestätigung mitgeschickt, wird diese unterschrieben zurückgesandt. Sonst wird eine kurze Auftragsbestätigung vom zuständigen Vertriebsingenieur erstellt. In dieser werden auch die zuständigen technischen Ansprechpartner und der Projektleiter vermerkt. Letzterer setzt sich dann mit dem Kunden in Verbindung, um die Arbeitsaufnahme zu besprechen.

Erfolgte die Beauftragung mündlich, wird ein Auftragsbe­stätigungsschreiben mit sämtlichen besprochenen Konditionen verfasst und um schriftliche Bestätigung des Kunden gebeten.

Umsetzung in die EPK - Fortsetzung

Obiger Text führt nun zurück zur vorigen Abbildung. Dort muss diese Erstellung der externen Meldung "parallel" zur Vervollständigung des Auftragsstammblatts eingefügt werden. Dies wurde mit einem UND-Operator realisiert. Danach wurde die Funktion Art der Auftragserteilung prüfen eingefügt. Sie wird vom Vertriebsingenieur realisiert.

Die folgende Abbildung zeigt den Fortgang. Obige Prüfung kann zu drei Ergebnissen führen, entsprechend wurden drei Ereignisse eingefügt:

Weiter mit Abbildung 8.2-4

• Schriftlich mit Auftragsbestätigung
• Schriftlich ohne Auftragsbestätigung
• Telefonisch

Es folgen die in der Prozessbeschreibung angeforderten Handlungen als Funktionen. Das Zusammenführen der Kontrollflusszweige erfolgt zweistufig. Zuerst werden die beiden linken Kontrollflusszweige zusammengefasst, indem ein abstrahiertes Ereignis "Erledigt" formuliert wird, danach folgt die Zusammenführung der nun nur noch zwei Kanten. Abschließend wird, wie in der Prozessbeschreibung gefordert, die Besprechung der Arbeitsaufnahme mit dem Kunden und ein Schlussereignis angefügt.

Verschachtelte Kontrollfluss-
strukturen

Auch in diesem Text liegt wieder ein Beispiel für eine Funktionsbeschreibung inmitten der Prozessbeschreibung vor:

Prozess- vs. Funktions-
modellierung

"... Sonst wird eine kurze Auftragsbestätigung vom zuständigen Vertriebsingenieur erstellt. In dieser werden auch die zuständigen technischen Ansprechpartner und der Projektleiter vermerkt. ...."

Diese wurde in der Prozessmodellierung weggelassen.

Abbildung 8.2-4: Auftragsstart im Anlagenbau, Teil 4 - Schluss

8.3 Personalbeschaffung

Hier nun ein kleinerer Prozess, der didaktisch motiviert ist und der als Modellierungsaufgabe nach einer einführenden Veranstaltung zur Geschäftsprozessmodellierung in einer Klausur dienen könnte. Er beschreibt eine Personalbeschaffungssituation.

Prozessbeschreibung

Die Schulungsabteilung (SchAbt) der Firma ERPL (Endlich Richtig Programmieren Lernen) stellt fest, dass sie einen weiteren Dozenten für die C++-Schulungen einstellen muss. Sie wendet sich deshalb an die Geschäftsleitung (GL) und an die Personalabteilung (PA), um einen neuen Mitarbeiter einstellen zu können. Der Einstellungsvorschlag geschieht auf Basis des PBB (Personalbeschaffungsbogen), den die Schulungsabteilung ausfüllen und mit dem Vorschlag mitgeben muss. Die Geschäftsleitung muss in Absprache mit der Personalabteilung dem Einstellungsvorschlag zustimmen. Die Zustimmung oder Ablehnung wird schriftlich formuliert.

Dozentenbedarf

Umsetzung in die EPK

Die EPK erhält zu Beginn das Startereignis Dozent ist einzustellen. Die erste Funktion ist das Ausfüllen des Personalbeschaffungsbogens (PBB), durchgeführt durch die Schulungsabteilung (SchAbt). Es entsteht das Informationsobjekt Personalbeschaffungsbogen (PBB). Dieselbe Abteilung (deswegen wurde die Organisationseinheit weggelassen) realisiert die nächste Funktion, PBB zur Geschäftsleitung (GL) geben und um Zustimmung bitten.

Informationsobjekt entsteht ...

und wird transportiert

Die Entscheidungsfindung der GL wird als Funktion mit zwei möglichen Ergebnisereignissen modelliert. Falls die GL nicht zustimmt, wird das entsprechende Ereignis zu einem der Schlussereignisse der EPK.

Muster Entscheidungsfindung

Prozessbeschreibung

Falls die GL zustimmt, entwerfen Schulungs- und Personalabteilung unter Berücksichtigung des Personalbeschaffungsbogens und früher verfassten Stellenanzeigen die Anzeige. Diese wird dann durch die PA in mehreren einschlägigen Computerzeitschriften inseriert. Es wird darauf geachtet, dass der Erscheinungstermin der Anzeige in den verschiedenen Zeitschriften in einem Zeitrahmen von maximal vier Wochen liegt.

Umsetzung in die EPK

Der Entwurf der Anzeige wird als Funktion modelliert. Die Zusammenarbeit von SchAbt und PA wird durch die zwei Elemente für Organisationseinheiten ausgedrückt. Bei den Informationsobjekten werden PBB und Frühere Anzeigen als "liefernd" eingefügt und die aktuell entstehende Anzeige als "entstehend".

Zusammenarbeit
(vgl. auch Abschnitt 7.6)

Abbildung 8.3-1: Personalbeschaffung - Teil 1

Abkürzungen:

PBB: Personalbeschaffungsbogen

SchAbt: Schulungsabteilung

GL: Geschäftsleitung

PA: Personalabteilung

Prozessbeschreibung

Vier Wochen, nachdem die letzte Anzeige erschienen ist, werden die eingegangenen Bewerbungen durch die SchAbt und PA durchgesehen. Liegen keine Bewerbungen vor, wird die Anzeige nochmals in den Zeitschriften geschaltet. Liegen zwar Bewerbungen vor, aber keine geeigneten, wird (parallel) den Bewerbern abgesagt und die Anzeige überarbeitet. Die Absagen übernimmt die Personalabteilung, die Überarbeitung der Anzeige leisten Personalabteilung und Schulungsabteilung zusammen. Dabei wird v.a. geprüft, ob man die Konditionen (Stellenvoraussetzungen, Gehalt, ...) verändern muss. Anschließend wird die Anzeige wieder veröffentlicht und derselbe Prozessabschnitt wie oben bis zur Sichtung der Bewerbungen nochmals durchlaufen.

Liegen geeignete Kandidaten vor, wählen Schulungsabteilung und Personalabteilung Kandidaten aus, die eingeladen werden sollen.

Umsetzung in die EPK

Obige Beschreibung verlangt als erstes eine Funktion, in der das Veröffentlichen der Anzeige ausgedrückt wird. Die durchführende Organisationseinheit wird nicht genannt, hier wurde die PA angenommen. In einem konkreten Projekt müsste nachgefragt werden. An die Funktion angefügt wurde auch die (aktuelle) Anzeige, als zu transportierendes Informationsobjekt.

Das 4-wöchige Warten kann durch ein zeitliches Ereignis mit UND-Anbindung in der EPK ausgedrückt werden. Damit wird hier ausgedrückt, dass der Geschäftsprozess bis vier Wochen nach Erscheinen der letzten Anzeige ruht. Das Sichten der Bewerbungseingänge kann wieder als Funktion mit den Bewerbungen als Informationsobjekt(e) ausgedrückt werden. Um die Semantik der Prozessbeschreibung auszudrücken erfordert die syntaktische Umsetzung im weiteren zwei Rückschleifen.

Muster Zeitpunktevgl. Abschnitt 6.4

Die erste startet vom Ereignis Keine Bewerbung liegt vor. Da in diesem Fall einfach dieselbe Anzeige nochmals geschaltet wird, erfolgt der Rücksprung vor die Funktion Anzeige veröffentlichen. In der Prozessbeschreibung wird nicht ausgedrückt, wie oft dies geschieht, deshalb baut die Syntax der EPK hier keine Sperre auf, was aber möglich wäre (vgl. Abschnitt 6.8). Ganz pragmatisch wird angenommen, dass in der konkreten Realisierung des Geschäftsprozesses die Handelnden eine Lösung finden. Dieses "Abstützen" der Modellierung auf die Pragmatik liegt sehr oft bei Istanalysen vor. Es bedeutet letztendlich einen Verzicht auf die Ausmodellierung der gesamten "tiefen" Semantik des Prozesses [Anmerkung] .

Rückschleifenmit Pragmatik (vgl. Abschnitt 6.8)

Die zweite Rückschleife ergibt sich aus dem Handeln nach dem Ergebnis Keine geeigneten Bewerber dabei. Hier wird die überarbeitete Anzeige zurückgereicht - an dieselbe Stelle flussaufwärts. Auch diese ist wieder - im obigen Sinn - pragmatisch fundiert.

Das "gleichzeitige Absagen" aus der Prozessbeschreibung kann in der EPK durch einen UND-Operator nach dem entsprechenden Ereignis ausgedrückt werden. Der eine vom UND startende Kontrollflusszweig führt zur oben beschriebenen zweiten Rückschleife, der andere zu einem Schlussereignis. Auch der dritte Zweig, der zur Auswahl der Einzuladenden führt, endet mit einem Schlussereignis.

Muster Tätigkeiten starten(vgl. Abschnitt 6.2)

Damit liegen in diesem Prozess insgesamt drei mögliche Schlussereignisse vor. Weitere wurden "pragmatisch" verhindert. Zur Verdeutlichung des Konzepts der Instanzen von Ereignisgesteuerten Prozessketten stelle man sich Prozessdurchgänge vor, die bei dem ersten Schlussereignis (ganz oben), beim zweiten (Bewerbern abgesagt) oder beim dritten (Einzuladende ausgewählt) enden. Damit wären die drei wichtigsten Instanzen dieses Geschäftsprozesses geklärt.

Instanzen

Muster Zeitpunkte

Abbildung 8.3-2: Personalbeschaffung - Teil 2

8.4 Zoo - Tieraufnahme

Die folgenden Geschäftsprozesse sind in einem Zoo angesiedelt. Sie sind fiktiv und didaktisch motiviert und natürlich stark vereinfacht. Konkret geht es um die Aufnahme eines neuen größeren Tieres (Säugetiere, Reptilien, ...) in einen Zoo.

Prozessbeschreibung

Der Prozess beginnt damit, dass ein neues Tier eintrifft (von einem anderen Zoo, von einem Tierhändler, usw.). Als erstes wird vom Tierarzt des Zoos (Zootierarzt) in der Datenbank des Zoos (ZooDB) eine sog. Tierakte für das neue Tier angelegt. Dabei werden auch einige Daten (Geburtstag, Geburtsort, Aufenthalte, ...) aus den Transportbegleitpapieren ("Begleitheft") des Tieres übernommen.

Danach wird das Tier gewogen, vom zukünftigen Pfleger, der auch den Eintrag des Gewichts in die Tierakte vornimmt - und es werden 20 zentrale Blutwerte festgestellt (Blutfettwerte, Eisengehalt, Mineralien, ...). Dies erledigt der Zootierarzt, der diese Ergebnisse in die Tierakte in der ZooDB einträgt.

Falls der Zootierarzt feststellt, dass es sich um ein gefährliches Tier handelt, wird das Tier vor den obigen Untersuchungen vom Zootierarzt betäubt.

Der weitere Fortgang hängt von den Ergebnissen obiger Untersuchungen ab. Dabei wird vereinfacht: Bezüglich des Gewichts ist nur wichtig, ob das Tier Übergewicht hat oder nicht. Bezüglich der Blutwerte wird nur unterschieden, ob alle Werte mindestens 70% des optimalen Werts erreichen ("Status 70"), ob alle Werte mindestens 50% des optimalen Werts erreichen ("Status 50") oder dies nicht erreicht wird, einzelne Werte also unter 50% des optimalen Werts liegen ("Blutwerte negativ").

• Falls die Blutwerte negativ sind, wird das Tier zurückgeschickt zur Herkunftsstelle.
• Falls das Tier kein Übergewicht hat und den Status 70 wird es durch den Zootierarzt offiziell in den Zoo aufgenommen. Dies wird in der Tierakte und in der Zoodatenbank vermerkt.
• Falls das Tier kein Übergewicht hat, aber nur den Status 50 erreicht, wird es auf den Aufnahmestatus Warten gesetzt. Danach wird es eine Woche isoliert. Wenn die Woche vergangen ist, wird die gesamte Untersuchung bzgl. Gewicht und Blutwerten wiederholt. Dies dient dazu, um festzustellen, ob die nicht so positiven Blutwerte vielleicht stressbedingt sind (durch den Transport). Fallen die Werte bei der zweiten Untersuchung wieder so aus ("Kein Übergewicht", "Status 50"), wird das Tier zurückgeschickt.
• Falls das Tier Übergewicht hat und den Status 70, wird es aufgenommen. Allerdings wird ein Diätplan erstellt (vom Zoodiätassistenten (DiätAss)), der in die Tierakte eingetragen wird.
• Falls das Tier Übergewicht hat und nur den Status 50 erreicht, wird es zurückgesandt. Dieser Sachverhalt wird in die Tierakte eingetragen.

Für die Rücksendung eines Tieres ist folgendes zu leisten:

• Die Tatsache der Rücksendung wird von der Zooleitung in den Begleitpapieren und in der Tierakte der ZooDB vermerkt.
• Parallel sendet die Zooleitung zusammen mit dem Zootierarzt eine Mail an die Herkunftsstelle. In ihr wird die Rückkehr des Tieres angekündigt und der Grund für die Rücksendung angegeben.
• Danach erfolgt eine Terminvereinbarung für den Rücktransport des Tieres mit dem (Tier-) Transportunternehmen. Dies erledigt die Zooleitung zusammen mit der "Rücksendestelle" und natürlich mit dem Transportunternehmen.

Abbildung 8.4-1: Geschäftsprozess Tieraufnahme ZOO - Teil 1

Anmerkungen zu den EPKs

Die Prüfung durch den Zootierarzt, ob es sich um ein gefährliches Tier handelt, kommt in der Prozessbeschreibung weiter unten, sie muss in der EPK vor den Betäubungsvorgang genommen werden. Dies kommt in Prozessbeschreibungen häufig vor, auch viel ausgeprägter als hier. Es lohnt sich immer, in den Prozessbeschreibungen ein Stück nach vorne zu schauen, bevor man an der jeweiligen Stelle weiter modelliert.

Vgl. Abbildung 8.4-1

Nach vorne schauen, flussaufwärts!

Der mittlere Teil stellt ein Beispiel für das Kombinatorikproblem der Prozessmodellierung dar (vgl. Abschnitt 6.6). Alle Ergebnisse der einen Funktion müssen mit allen der anderen kombiniert werden, falls es für jede Kombination einen eigenen weiteren Fortgang gibt.

Vgl. Abbildung 8.4-2

Muster Kombinatorik

Abbildung 8.4-2: Geschäftsprozess Tieraufnahme ZOO - Teil 2

Wie in Abschnitt 6.6 gezeigt kann für diese Semantik der UND-Operator eingesetzt werden. Nur Ereignisse, die alleine einen bestimmten Fortgang erzwingen - wie hier Blutwerte negativ - bedürfen keiner Kombination.

In den Ergebnissen "der Kombinatorik" wird nun mehrfach das Tier zurückgesandt. Deshalb lohnt es sich, den Geschäftsprozess Rücksendung als eigenen Prozess anzulegen und die Rücksendung jeweils durch einen Prozesswegweiser auszudrücken. Spätestens jetzt sollte der "sendende Prozess" auch einen Namen erhalten: Tieraufnahme. Die Verknüpfung durch Prozesswegweiser erfolgt dann wie in Abschnitt 7.4 beschrieben. Im sendenden Prozess kommt der Prozesswegweiser nach einem Ereignis, das unmittelbar vor den Aktivitäten des aufgerufenen Prozesses steht. Beschriftet wird er mit der Bezeichnung des aufgerufenen Prozesses (hier: Rücksendung). Beim aufgerufenen Prozess gibt es für jeden Verweis einen eigenen Startvorgang mit einem Prozesswegweiser (beschriftet mit der Bezeichnung des aufrufenden Prozesses) und nachfolgend dem Ereignis, das im aufrufenden Prozess vor dem Prozesswegweiser stand. Diese Ereignisse sind die eigentlichen Startereignisse des aufgerufenen Prozesses.

Vgl. die folgende Abbildung


Prozesswegweiser

Abbildung 8.4-3: Geschäftsprozess Rücksendung (eines Tieres)

8.5 WebShop

Prozessbeschreibung

Der folgende Text beschreibt den Anfang eines Geschäftsprozesses zur Auftragsabwicklung bei einem WebShop, die Verarbeitung der Bestellung. Der Geschäftsprozess wird weitgehend automatisiert realisiert, durch das Modul Auftragsbearbeitung einer entsprechenden Anwendungssoftware.

Weitgehend automatisiert

Betrachtet werden nur die Bestellungen über den WebShop, nicht die per Fax oder Brief. Wenn der Kunde nach seinen Einkaufsschritten die Einträge im letzten Web-Formular getätigt und die Bestellung abgeschickt hat, ist der Kaufvertrag zustande gekommen. Die Web-Software legt einen Auftrag, eine Liste der Fremdanbieterprodukte (LFAP) und eine Nachbe­stellliste (NBL) für die Bestellung an. Falls die zwei letzteren bei der Bestellverarbeitung nicht benötigt werden, werden sie am Schluss wieder gelöscht.

Bestellungen

Danach prüft das Programm, ob die gewünschten Produkte im Lager sind, nachbestellt werden müssen oder von einem Fremdanbieter stammen (einem Unternehmen, das auf den Webseiten des Unternehmens ebenfalls Produkte anbietet). Obige Prüfung geschieht Produkt für Produkt. Der Ablauf ist wie folgt:

Prüfung Produktherkunft mit einer Schleife

• Ist das Produkt von einem Fremdanbieter wird es in die LFAP (Liste Fremdanbieterprodukte) aufgenommen.

Ist das Produkt aus dem Sortiment des WebShops, wird zuerst geklärt, ob es im Lager vorrätig ist (Lagerprodukt) oder nicht.

• Falls es vorrätig ist, wird es in den Auftrag aufgenommen.
• Falls es nicht vorrätig ist, wird es zum Bestellprodukt und in die Nachbestellliste (NBL) aufgenommen.

Sind alle Produkte auf diese Weise geprüft, wird ...

• ... die LFAP - falls sie Einträge hat - an den oder die Fremdanbieter verschickt. Die weitere Bearbeitung erfolgt dann dort. Auch die Rechnung erhält der Kunde vom Fremdanbieter.
• ... die NBL - falls eine notwendig war - an die Abteilung Lager geschickt. Das Lager nimmt die Nachbestellung vor. Wenn die Produkte eintreffen, trägt das Lager dies mit der Anwendungssoftware in die Unternehmensdatenbank ein. Dabei werden die Produkte dieser Liste in den Auftrag aufgenommen.

Während der Nachbestellung (falls eine notwendig war) ruht der Geschäftsprozess. Erst wenn die nachbestellten Produkte eingetroffen sind, wird er fortgesetzt. Der Auftrag wird dann an das Lager geschickt. Dort werden die gewünschten Produkte zusammengestellt und verpackt.

Anschließend wird durch die Abteilung Versand das Ausdrucken der Rechnung veranlasst. Sie erhält dann in der Unternehmensdatenbank den Status Neu. Die Rechnung wird anschließend zur Warensendung getan und das Paket verschickt, wodurch die Rechnung den Status Offen erhält.

Rechnung

Umsetzung in eine EPK

Für diesen Geschäftsprozess wird die Existenz einer Anwendungssoftware mit einem Modul Auftragsbearbeitung und einer Unternehmensdatenbank angenommen. Die Software erledigt automatisiert die meisten Aufgaben, liest in der Datenbank und schreibt in sie. Auch die bei der ersten Funktion entstehenden Informationsobjekte NBL (Nachbestellliste), LFAP (Liste der Fremdanbieterprodukte (LFAP) und der Auftrag entstehen dort.

Automatisierte Abwicklung

Abbildung 8.5-1: WebShop - Teil 1

Die Auswahl des zu prüfenden Produkts wird in eine Funktion gelegt, die damit auch den Beginn des zu wiederholenden Abschnitts markiert (Position 1). Danach kommt die Prüfung, ob es sich um ein Lagerprodukt (2) handelt. Bei (3) werden alle Kontrollflusszweige der Auswahlfunktionen wieder zusammengeführt und es erfolgt die Prüfung, ob die Produkte schon abgearbeitet sind. Falls ja, gibt es den Sprung nach flussaufwärts. Es liegt hier also das Muster Repetitive Handlungen vor. Vgl. Abschnitt 6.9.

Abbildung 8.5-2

Muster Repetitive Handlungen

Abbildung 8.5-2: WebShop - Teil 2

Eine Formulierung wie "Ist das Produkt von einem Fremdanbieter ... " muss in eine Funktion, die den Sachverhalt klärt und nach der entsprechende Ereignisse folgen, umgesetzt werden. Vgl. Position (2) in Abbildung 8.5-3.

Auch die Prüfung, ob in der LFAP Einträge stehen, muss in eine Funktion gelegt werden (4). Der Versand der Liste (5) wird wieder durch eine Linie ohne Pfeilspitze verdeutlicht. Es ist ansonsten nicht üblich, in Ereignisgesteuerten Prozessketten das Löschen von Informationsobjekten auszudrücken. Hier wurde es, wegen der Systemnähe des Beispiels getan. Vgl. die durchgestrichenen Informa­tionsobjekte LFAP und NBL.

Abbildung 8.5-3: WebShop - Teil 3

Der Prozess ist von Anfang an automatisiert, das Modul Auftragsbearbeitung erledigt die Aufgaben. Erst ganz unten, ab Position (6), übernimmt eine Abteilung einige Aufgaben, aber bereits ab Position (8) handelt wieder die Software. Deshalb wechselt auch erst ab Position (6) die Organisationseinheit, getreu der Regel, dass die Organisationseinheiten bei einer Funktion weggelassen werden können, wenn sie gleich sind wie bei der vorangehenden.

Abbildung 8.5-4

Das Warten auf den Eingang der nachbestellten Produkte wird, wie an Position (7) gezeigt, durch ein Ereignis modelliert, dass mit UND in den Kontrollfluss eingebunden ist. Dies ist ein Beispiel für das Muster Warten. Vgl. Abschnitt 6.7.

Muster Warten

Abbildung 8.5-4: WebShop - automatisiert. Teil 4

Die letzte Abbildung unten zeigt den Schluss des Geschäftsprozesses. Das Verändern des Rechnungsstatus und das Ausdrucken der Rechnung wurde mit Hilfe eines UND-Operators "parallel" angestoßen.

Vgl. Abschnitt 5.4.1: Funktionsverknüpfung mit auslösendem UND-Ereignis

Abbildung 8.5-5: WebShop - automatisiert. Teil 5

8.6 Zahlungseingangsüberwachung

Die folgende EPK zeigt einen völlig durch Software getragenen und regelmäßig durchgeführten Geschäftsprozess, wieder bei einem WebShop. Diesmal geht es um die Überwachung der Zahlungseingänge.

Prozessbeschreibung

Im Geschäftsprozess Fälligkeitsprüfung geht es darum, Rechnungen, deren Zahlungsziel abgelaufen ist, zu identifizieren. Diese Prüfung erfolgt - natürlich automatisiert (d.h. durch ein Programm) - täglich ab 3.00 Uhr.

Dazu werden die entsprechenden Daten im Finanzwesen gelesen. Zuerst wird geprüft, ob überhaupt nicht bezahlte ("offene") Rechnungen vorliegen, was aber natürlich in der Regel der Fall ist. Sollten wider Erwarten keine nicht bezahlten Rechnungen vorliegen, beendet das Programm seine Aktivitäten.

Für nicht bezahlte Rechnungen gibt es drei Ursachen:

• ein laufendes Widerspruchsverfahren (Status der Rechnung "Widerspruch")
• das Zahlungsziel ist noch nicht erreicht (Status "Erinnerung", "Mahnung", ...)
• das Zahlungsziel ist überschritten

Liegen also nicht bezahlte Rechnungen vor, wird für jede geprüft, ob die Zahlungsfrist abgelaufen ist oder ob eine der zwei anderen möglichen Ursachen vorliegt. Handelt es sich tatsächlich um ein Ablaufen der Zahlungsfrist, erhält die Rechnung den Status "nicht bezahlt" und wird dem Mahnprozess übergeben.

Für das Controlling wird außerdem festgehalten, wie viele Rechnungen zu jedem Typ nicht bezahlter Rechnungen gehören. Bei wie vielen also ein Widerspruchsverfahren läuft, bei wie vielen das Zahlungsziel noch nicht erreicht ist und bei wie vielen das Zahlungsziel überschritten ist. Diese drei Werte werden, falls sie nicht Null sind, dem Controlling automatisiert durch eine E-Mail mitgeteilt.

Umsetzung in eine Ereignisgesteuerte Prozesskette

Der Prozess startet, wenn zwei Bedingungen erfüllt sind: falls überhaupt Fälligkeiten zu prüfen sind, was aber meist der Fall ist [Anmerkung] , und falls es 3.00 Uhr morgens ist. Dies wird durch zwei Startereignisse realisiert. Durch ein Startereignis wie 3.00 Uhr morgens kann man ein regelmäßiges Anwerfen eines Geschäftsprozesses zu einem bestimmten Zeitpunkt modellieren. Die programmtechnische Umsetzung fängt dann auch die Probleme ab, die entstehen könnten, wenn gerade um 3.00 Uhr die Leitung nicht zur Verfügung steht: Wiederholtes Starten, usw.

Jeden Morgen um 3.00

Muster Zeitpunkte

Als erstes wird geprüft, ob nicht bezahlte (nb) Rechnungen vorhanden sind. Dies geschieht durch eine Funktion, die auf Daten des Finanzwesens zugreift. Falls keine vorhanden sind, endet der Prozess gleich wieder (Position 1).

Abbildung 8.6-1: Zahlungseingangsüberwachung - Teil 1

Abkürzung:

nb: nicht bezahlt(e)

Im anderen Fall werden in der EPK die nicht bezahlten Rechnungen, die ja offene Posten darstellen, durch eine Funktion gelesen und ausgewertet. Dies erledigt das Modul LR (Lese Rechnung) im Datenbestand Offene Posten, so dass ein entsprechender Träger der Funktion und ein Informationsobjekt einzubauen sind. Drei Ergebnisse sind möglich:

• Zahlungsziel überschritten ("zü")
• Zahlungsziel noch nicht erreicht ("znn")
• Widerspruch läuft ("zwi")

Sie werden durch Ergebnisereignisse modelliert.

Dieser Abschnitt liegt in einer Schleife, da die offenen Posten einer nach dem anderen abgearbeitet werden. Da die Anzahl der jeweils auffälligen" Rechnungen von Bedeutung ist und später benötigt wird, werden hier entsprechende Informationsobjekte eingefügt (Zähler). In der Programmierung würden diese Informationsobjekte Variablen entsprechen. Beschrieben werden die Informationsobjekte durch entsprechende Funktionen. Im Falle der nicht bezahlten Rechnungen wird dann der Status auf Nicht bezahlt gesetzt. Auch dies wird durch eine Funktion modelliert, die auf die Rechnungsköpfe der Datenbank zugreift [Anmerkung] .

Schleife für repetitives Handeln

Es folgt das Anstoßen eines Mahnverfahrens und gleichzeitig die Weiterführung des Kontrollflusses zu dem XODER-Operator, der alle drei Verzweigungen zusammenführt (3). Das Zusammenführen der drei Kontrollflusszweige ist nötig, weil der Geschäftsprozess danach in einem Zweig weitergeht.

Abbildung 8.6-2: Zahlungseingangsüberwachung - Teil 2

Abkürzungen:

LR: Modul Lese Rechnung

zü: Zahlungsziel überschritten

znn: Zahlungsziel noch nicht erreicht

zwi: Widerspruch läuft

Auf das Mahnverfahren wird durch einen Prozesswegweiser verwiesen (vgl. Abschnitt 7.4). Der Prozesswegweiser folgt immer nach einem Ereignis, das im aufgerufenen Prozess wiederholt wird. Somit muss im aufgerufenen Prozess Mahnverfahren zuerst ein Prozesswegweiser kommen (mit der Beschriftung Zahlungseingangsüberwachung) und danach das Ereignis Status auf "Nicht bezahlt" gesetzt. Dieses Ereignis stellt dann sozusagen das Startereignis des aufgerufenen Prozesses dar.

Prozesswegweiser

In der EPK (oben) folgt dann eine Funktion mit der Prüfung, ob noch eine weitere nicht bezahlte Rechnung vorliegt. Falls ja, kommt es zu einem Rücksprung nach flussaufwärts, vor die Funktion Nicht bezahlte Rechnung lesen (2). Entsprechend den Syntaxregeln für Rücksprünge wird der Kontrollflusszweig mit einem XODER-Operator in den Hauptfluss eingebunden.

Rücksprung

Falls keine offenen Rechnungen mehr vorliegen, folgt die Klärung, wie viele Rechnungen mit Zahlungsziel überschritten (zü), Zahlungsziel noch nicht erreicht (znn) und Widerspruch läuft (zwi) festgestellt werden konnten. Dazu wird für jeden Rechnungstyp zuerst festgestellt, ob der jeweilige Zähler größer Null ist. Falls ja, wird der Wert ans Controlling gemeldet. Die Meldefunktion benötigt ein zu lesendes (Zähler x) und ein zu schreibendes (Mail bzgl. X) Informationsobjekt.

zü, znn und zwi

Prozessmodellierung kennt keine Variablen. Gäbe es sie, könnte man eine solche Situation in einer Schleife bewältigen, in der nacheinander die drei Rechnungstypen verarbeitet werden. Ohne Variablenkonzept muss dieser Abschnitt verdreifacht werden. Hier berühren wir mehrfach die Grenze zur Funktionsmodellierung, d.h. zur Modellierung für eine Programmierung:

Prozess- vs. Funktionsmodellierung

• Eine Standardprozessmodellierungbenötigt kein Variablenkonzept, weil sie die funktionale Ebene kapselt. Kommt man also im Rahmen eines Modellierungsvorhabens auf diese Ebene, sollte man das Modellierungsinstrument wechseln.
• Auch die weiter oben eingeführten Informationsobjekte als Zähler markieren so eine Grenze.

Abbildung 8.6-3: Zahlungseingangsüberwachung - Teil 3

9 Zusammenfassung der Syntaxregeln

9.1 Syntaxregeln

Regeln für die syntaktisch korrekte Erstellung von EPKs

Nicht nur zu formalen Sprachen, auch zu semi-formalen Sprachen gehören Regeln, mit denen die zulässigen Verknüpfungen der Elemente festgelegt werden. Diese wurden für Ereignisgesteuerte Prozessketten im Text schon angeführt und sollen hier zusammengefasst werden:

• (Start) Am Beginn eines jeden Kontrollflusszweiges befindet sich ein Ereignis (oder mehrere). Befindet sich dieses auch am Beginn der EPK, wird es Startereignis genannt.
• (Start) Bei aufgerufenen Prozessen kommt vor dem Startereignis noch der Prozesswegweiser mit der Bezeichnung des aufrufenden Prozesses.
• (Ende) Am Ende eines jeden Kontrollflusszweiges befindet sich ein Ereignis (oder mehrere). Dies wird Schlussereignis(e) genannt.
• (Kontrollfluss) Ereignisse werden nur im Kontrollfluss und da nur mit Funktionen verknüpft.
• (E - F - Abfolge) Bis auf das Start- und Schlussereignis gilt für den Kontrollfluss: auf ein Ereignis folgt eine Funktion, auf eine Funktion ein Ereignis. Ereignisse und Funktionen lösen sich ab.
• (OE) Organisationseinheiten werden Funktionen zugeordnet und zwar denen, bei denen sie mitwirken (genauer: bei denen Mitarbeiter aus der jeweiligen Organisationseinheit mitwirken). Die Zuordnung erfolgt durch eine richtungslose Linie.
• (IO 1) Informationsobjekte werden Funktionen zugeordnet und zwar denen, für deren Erfüllung sie benötigt werden. Die Zuordnung erfolgt durch eine Pfeillinie.
• (IO 2) Entsteht ein Informationsobjekt aus den Aktivitäten der Funktion heraus oder wird es verändert, zeigt der Pfeil zum Informationsobjekt.
• (IO 3) Wird das Informationsobjekt nur in der Funktion genutzt, zeigt der Pfeil zur Funktion
• (IO 4) Alleiniges Wahrnehmen des Informationsobjekts wird nicht durch einen Pfeil ausgedrückt. Sonst müsste bei jedem Zugriff auf ein Informationsobjekt auch ein Lesevorgang (Pfeilspitze zur Funktion) modelliert werden.
• (IO 5) Wird das Informationsobjekt im Rahmen einer Funktion nur transportiert, wird keine Pfeilspitze eingefügt.
• (Operatoren 1) Das Verzweigen und Zusammenführen von Kontrollflusszweigen kann nur über Operatoren erfolgen.
• (Operatoren 2) Die Operatoren verknüpfen jeweils entweder mehrere Ereignisse oder mehrere Funktionen.
• (Operatoren 3 - ODER-Operator (syntaktisch)): Falls Ereignisse verknüpft sind: Mindestens eines der verknüpften Ereignisse muss eintreten, dann geht es im Kontrollfluss weiter.
• (Operatoren 4 - ODER-Operator (syntaktisch)): Falls Funktionen verknüpft sind: Mindestens eine der verknüpften Funktionen muss eintreten, dann geht es im Kontrollfluss weiter.
• (Operatoren 5 - XODER-Operator (syntaktisch)): Falls Ereignisse verknüpft sind: Genau eines der verknüpften Ereignisse muss eintreten, dann geht es im Kontrollfluss weiter.
• (Operatoren 6 - XODER-Operator (syntaktisch)): Falls Funktionen verknüpft sind: Genau eine der verknüpften Funktionen muss eintreten, dann geht es im Kontrollfluss weiter.
• (Operatoren 7 - UND-Operator (syntaktisch)): Falls Ereignisse verknüpft sind: Alle verknüpften Ereignisse müssen eintreten, dann geht es im Kontrollfluss weiter.
• (Operatoren 8 - UND-Operator (syntaktisch)): Falls Funktionen verknüpft sind: Alle verknüpften Funktionen müssen eintreten, dann geht es im Kon­trollfluss weiter.
• (Kontrollfluss 1) Auslösende Ereignisse mit XODER und ODER sind nicht erlaubt. D.h.: nach einem Ereignis (oder nach mehreren) darf kein ODER- oder XODER-Operator für die dann ja notwendigerweise nachfolgenden Funktionen folgen.
• (Kontrollfluss 2 - Rücksprünge) Sprünge nach flussaufwärts bleiben im selben Kontrollflusszweig, starten aus einem Ereignis nach flussaufwärts und werden vor einer Funktion wieder in den Kontrollfluss geführt.
• (Kontrollfluss 3 - Kantenzusammenführung) Kanten werden mit dem Operator zusammengeführt (verknüpft), durch den sie flussaufwärts aufgeteilt wurden.
• (Kontrollfluss 4 - Kantenzusammenführung) Beim Zusammenführen von Kon­trollflusszweigen muss darauf geachtet werden, dass vor dem verknüpfenden Operator die Stimmigkeit der Ereignis - Funktion - Abfolge hergestellt ist.
• (Kontrollfluss 5 - Flussverschachtelung) Wurden mehrere verschachtelte Verzweigungen geöffnet und sollen diese geschlossen werden, wird zuerst die innerste, dann die nächste usw. und am Schluss die äußerste Verzweigung geschlossen (Genau gleich wie bei den Kontrollstrukturen der prozeduralen Programmierung).
• (Kontrollfluss 6) Geht es im Kontrollfluss nach einer ODER- bzw. XODER-Verzweigung einheitlich (in einem Kontrollflusszweig) weiter, müssen alle Zweige zusammengefasst werden, bevor die weiteren Funktionen und Ereignisse angehängt werden.
• (Prozesswegweiser 1) Im aufrufenden Prozess steht der Prozesswegweiser an Stelle einer Funktion. Er ist beschriftet mit der Bezeichnung des aufgerufenen Prozesses.
• (Prozesswegweiser 2) Der Prozesswegweiser in der aufgerufenen Ereignisgesteuerten Prozesskette steht am Anfang eines Kontrollflusszweiges. Er gibt durch seine Bezeichnung an, von welcher anderen EPK der Aufruf kommt. Ihm nachgestellt ist das Ereignis, das im aufrufenden Prozess vor dem Prozesswegweiser steht. Statt einem können dies auch mehrere Ereignisse sein.
• (Zeitaspekte 1) Die zeitliche Dimension des Geschäftsprozesses wird durch die Abfolge von Ereignissen und Funktionen ausgedrückt.
• (Zeitaspekte 2) Ein Zeitpunkt wird modelliert, indem ein entsprechendes zeitliche Ereignis angelegt und durch einen UND-Operator in den Kontrollfluss eingebunden wird.

9.2 Empfehlungen zur Pragmatik

Hinweise auf die Rolle der Pragmatik beim Entwurf von Ereignisgesteuerten Prozessketten werden an vielen Stellen im Text gegeben. Einige besonders wichtige Beispiele hierzu sind in Abschnitt 7.8 beschrieben. Hier nun die Zusammenfassung der wichtigsten diesbezüglichen Regeln.

Pragmatik - bei der Erstellung von EPKs

• (Abstraktion) Bei Verknüpfungen von Funktionen mit ODER bzw. XODER kann auf die einzelnen Ergebnisereignisse der Funktionen verzichtet und statt dessen ein abstrahiertes (gemeinsames) Ergebnisereignis ("erledigt") gewählt werden. Vor diesem müssen die Kontrollflusszweige zusammengeführt werden.
• (Rücksprünge) Verzicht auf Kontrolle der Anzahl der Rücksprünge (Abbildung 6.8-1).
• (Wiederholung) Verzicht auf Rücksprung bei Wiederholung (Abbildung 6.8-2)
• (Zusammenhänge im Zeitfenster) Verzicht auf Beachtung der Zusammenhänge zwischen den Funktionen eines Zeitfensters (Abbildung 6.3-1), bzw. nach einem UND-Operator (Abbildung 5.4-2)
• (Entscheidungen) "Verschmelzen" zweier Operatoren bzw. Entscheidungen (vgl. Abschnitt 7.3, Abbildung 7.3-3)
• (Kombinatorik) Vereinfachung durch Abstraktion bei Auffächerung durch Kombinatorik (vgl. Abschnitt 7.3)

Es wird deutlich, dass Pragmatik hier meist Verzicht auf zu große (nicht notwendige) Exaktheit bedeutet. Das ist aber grundsätzlich so in der Modellierung und auch in der Prozessmodellierung. Letztendlich modellieren wir hier nur Standardabläufe (Routineprozesse). Mehr ist nicht möglich, weil die Komplexität des wirklichen Lebens die der Modellierung immer überschreitet.

9.3 Gestaltungsregeln

Weitere Regeln, die zur endgültigen Form der Ereignisgesteuerten Prozessketten beitragen, sind die Gestaltungsregeln, die in Abschnitt 1.3 vorgestellt werden. Hier die wichtigsten:

• (Organisationseinheiten) Weglassen der Organisationseinheiten, falls sie gleich sind wie bei der vorigen Funktion.
• (Informationstransport) Darstellen Informationstransport ohne Pfeilrichtung.
• (Weglassen Ereignisse) Weglassen der Ereignisse bei unverzweigter Abfolge.

10 Einschätzungen

10.1 Möglichkeiten der Prozessmodellierung

Die Erfassung der Geschäftsprozesse durch die Prozessmodellierung gibt einen fundierten Einblick in das Prozessgeschehen.

Kontrollfluss

Durch die Erfassung des Kontrollflusses werden die Abläufe geklärt. Überflüssige Einzelaktivitäten und Abschnitte werden erkannt und können beseitigt werden. Unnötig komplizierte Prozessabschnitte können vereinfacht werden.

Informationsobjekte

Die Erfassung der Informationsobjekte erlaubt, Defizite in der Datenspeicherung zu erkennen. Klärung von Fragen wie:

• Ist der Datenbestand integriert oder liegen (die "guten alten") Dateninseln vor, die schon Scheer und Mertens in ihren ersten Publikationen zum Thema Wirtschaftsinformatik beschrieben haben. Vgl. beispielhaft [Scheer 1997].
• Erfolgt die Informationsweitergabe automatisiert oder liegen Medienbrüche vor, wie in Abschnitt 2.2.4 beschrieben.
• Wie ist der Umgang mit den Daten? Ist die unternehmensweite Datenbank (weitgehend) realisiert und ist damit der Datenaustausch realisiert (reinschreiben hier, lesen dort) oder funktioniert der Datenaustausch (teilweise) über Austauschvorgänge des Workflows und führen diese zu "privaten" Datenbeständen?

Relativ problemlos können Strukturen erkannt werden, in denen dieselbe Information nacheinander auf verschiedene Informationsträger gebracht wird. Dies bedeutet immer eine Hemmung des Informationsflusses und dadurch eine Senkung der Produktivität. Diese Medienbrücheschaffen Schnittstellen, deren Überwindung mit großem Arbeitsaufwand verbunden ist. Einige Beispiele mögen dies verdeutlichen:

Medienbrüche

• Mehrfacharbeit: Informationen, z.B. zu einem Angebot, werden zum einen in einer Datenbank erfasst, zum anderen für die Ausformulierung in einem Textsystem.
• Informationsverluste: Werden Informationen auf unterschiedlichen und evtl. zahlreichen Trägern erfasst und nicht in einer integrierten Datenbank ist ganz grundsätzlich die Gefahr des Verlustes erhöht mit der Konsequenz erhöhter Kosten für Wiederbeschaffung.
• Schnittstellen: Informationen müssen über verschiedene Hardwareplattformen und Softwarepakete hinweg transponiert werden (vgl. auch die Ausführungen zum "Leidensdruck" in Abschnitt 3.5), was einen immensen Aufwand an Arbeit und Material erfordert.

Träger der einzelnen Funktionen

Die Bestimmung der Träger der einzelnen Funktionen (Stellen, Organisationseinheiten, Anwendungssoftware) gibt u.a. Antworten auf folgende Fragen:

• Sind zusammenhängende Abschnitte des Geschäftsprozesses unter einer einzigen Zuständigkeit. Wird überflüssig oft der Träger gewechselt?
• Wie steht es um die Automatisierung des Geschäftsprozesses? Wo sind die Funktionen, die nicht automatisiert werden können (im Sinne von Abschnitt 2.4-2)? Wie viele von den übrigen sollen oder können noch automatisiert werden?
• Gibt es menschgestützte Rechnerkommunikation?Gemeint ist damit folgendes: Informationen können den Weg von einem Rechner A zu einem Rechner B nur bewältigen, indem sie am Bildschirm des Rechners A abgeschrieben und an Rechner B eingegeben werden.
• Gibt es menschgestützte Unterprogrammkommunikation? Gemeint ist: Informationen kön­nen den Weg von einem Unterprogramm A einer Software zu einem anderen Unterprogramm B derselben(!) Software nur bewältigen, indem sie von einer Ausgabemaske A abgeschrieben und in einer Eingabemaske B wieder eingegeben werden.

Die beiden letzten Fälle sind nicht so selten, wie man denkt. Selbst den eigentlich undenkbaren letzten Fall trifft der Verfasser immer wieder an. Ist diese menschgestützte Unterprogrammkommunikation [Anmerkung] nötig, handelt es sich natürlich um ein klares Defizit der Software, das eigentlich zwischen Ersteller und Abnehmer unstrittig sein und behoben werden sollte. Beides ist aber oft nicht der Fall.

Mensch hilft Programm

Organisationsbrüche

Die Erfassung der Organisationseinheiten in den Ereignisgesteuerten Prozessketten erlaubt in einem gewissen Umfang das Erkennen von Organisationsbrüchen. Damit ist gemeint, dass ein Geschäftsprozess unnötig oft die Organisationseinheit, bzw. die bearbeitende Person wechselt. Hier liegt ein großes Optimierungspotenzial. In der Ereignisgesteuerten Prozesskette ist dies wiederum nur erkennbar, wenn genügend genau modelliert wird. Sind wirklich nur die Organisationseinheiten angegeben und nicht die Stellen, können diese Defizite auch verborgen bleiben.

Oftmals ergibt sich hier ein Widerspruch zwischen Optimierung und Kontrolle. Der Wechsel der bearbeitenden Person oder der Abteilung erfolgt ja oft, um Kontrolle und Überwachung zu gewährleisten ("4-Augen-Prinzip"). Ein einfaches Beispiel ist, wenn Beschaffungen über einer gewissen Grenze von der Abteilungsleitung oder sogar von der Geschäftsführung gegengezeichnet werden müssen. Hier ist somit ein Abwägen erforderlich: Welche "Brüche" sind nötig, um die Sicherheitsstandards zu gewährleisten, welche sind überflüssig und können beseitigt werden.

Optimierung vs. Kontrolle

Verlagerung in die Cloud

Die mit der Prozessmodellierung verbundene Prozessbetrachtung sichert auch eventuelle Verlagerungen von Prozessabschnitten in die externen Rechenzentren der Cloud (vgl. Abschnitt 2.4.5) ab. Sie hilft bei Fragen wie: Gibt es Prozessabschnitte, die ausgelagert werden können? Wie ist es dann um die Schnittstellen bestellt? Wie um den integrierten Datenbestand?

Requirements Engineering

Die Prozessmodellierung ist auch Voraussetzung für die Umsetzung des Prozesses in Software, d.h. für die Erstellung eines Anwendungsprogramms, das den Geschäftsprozess in vollem Umfang unterstützt und einzelne Abschnitte auch automatisiert verwaltet. Damit ist sie heutzutage Bestandteil des Anforderungsmanagements (Requirements Engineering) von Softwareprojekten, bei denen Geschäftsprozesse in Software "gegossen" werden.

Vorbereitung der Programmierung

Gesamtüberblick

Vielleicht das wichtigste Ergebnis der Beschäftigung mit Geschäftsprozessen ist, dass ein Überblick über das Geschehen im Unternehmen gewonnen wird, der auf andere Weise kaum zu erreichen wäre. Dieses tiefere Verständnis für die Abläufe im Unternehmen öffnet dann auch den Blick für Optimierungsmaßnahmen.

Überblick über das Prozessgeschehen

Die einzelnen Geschäftsprozesse in einem Unternehmen stehen in Beziehung zu zahlreichen Funktionen und Tätigkeiten quer durch alle traditionellen Organisationsbereiche wie Produktion, Einkauf, Verkauf, Finanzbuchhaltung, usw. Somit macht die Erstellung der Prozessmodelle auch die Interaktionen zwischen den verschiedenen Bereichen deutlich.

Überblick über die Interaktionen

10.2 Grenzen der Prozessmodellierung

Prozessmodellierung im allgemeinen und Modellierung mit Ereignisgesteuerten Prozessketten im besonderen beruhen auf dem Prozessgedanken. Damit kümmert sie sich nur um die Abläufe als solche und nicht um die anderen Aspekte von Geschäftsprozessen.

Zum Beispiel nicht um die Effizienz des Ressourceneinsatzes. Also um die Frage, ob die benötigten Mittel für die Leistungserbringung effizient eingesetzt werden, ob der Personaleinsatz angemessen ist, usw.

Effizienz Ressourceneinsatz

Auch die Qualität, mit der die in den Funktionen modellierten Tätigkeiten umgesetzt werden, wird von Ereignisgesteuerten Prozessketten in keiner Weise thematisiert. Es wird also z.B. in einer Funktion an geeigneter Stelle Prognoserechnung, Kalkulation erstellen, Teile beschaffen, usw. als zu leistende Aufgabe angelegt, aber die Qualität der Funktionsumsetzung ist erst mal nicht im Fokus der Prozessmodellierer. Dies muss im Rahmen des Business Process Reengineering zusätzlich geleistet werden.

Qualität von Funktionen

Auch zu lange Durchlaufzeiten sind nicht direkt erkennbar, zumal ja der Zeitverbrauch für Funktionen nicht modelliert wird. Diese können nicht nur durch eine ineffiziente Erledigung von Tätigkeiten entstehen, sondern auch durch einen ineffizienten Kontrollfluss oder durch zu lange Transport- und Liegezeiten. Letztere sind auch nicht ohne weiteres in Ereignisgesteuerten Prozessketten zu erkennen, zumal sie meist sehr nachlässig modelliert werden.

Zu lange Durchlaufzeiten

Informelle Strukturen bleiben, auch wenn sie u.U. für einen Geschäftsprozess von großer Bedeutung sind, der Prozessmodellierungvöllig verborgen. Dies hat teilweise mit der Nutzung von im Unternehmen vorhandenen Wissen zu tun (z.B. in der Form: Bei Lieferungen nach Mittelamerika kann ich Frau X in der Abteilung ABC fragen, die kennt sich mit den dortigen Zollverhältnissen sehr gut aus), aber nicht nur.

Informelle Strukturen

Die Prozessmodellierung liefert, wenn die Informationsobjekte korrekt modelliert wurden, Hinweise auf fragmentierte Datenbestände, auf Dateninseln. Mehr aber auch nicht. Dafür ist die datenbanktechnische Analyse der Datenbestände nötig, nur damit ist die Überwindung von Insellösungen und die Realisierung einer integrierten Unternehmensdatenbank möglich.

Erkennen nicht ausreichender Datenintegration

10.3 Gefahren der Prozessmodellierung

Gemessen an den Möglichkeiten der Prozessorientierungerscheinen die Gefahren gering. Auf eine soll jedoch hingewiesen werden. Eine prozessorientierte Sicht hat immer das Ziel, einzelne Geschäftsprozesse zu identifizieren, in den Vordergrund zu stellen und organisatorisch zu verankern. Dabei werden dann u.U. bestimmte Funktionen zu sehr von einem einzelnen Geschäftsprozess geprägt. Daraus können, worauf Kieser hinweist, Probleme entstehen, da natürlich viele Funktionen in verschiedenen Geschäftsprozessen benötigt werden und eine Ausrichtung auf den einen Geschäftsprozess evtl. Nachteile in einem anderen bringt [Kieser 1996, S. 249].

10.4 Möglichkeiten und Grenzen von EPKs

Wie alle Methoden zur Prozessmodellierung eignen sich Ereignisgesteuerte Prozessketten sehr gut für die Beschreibung standardisierter Abläufe. Diese lassen sich problemlos, wenn einige Regeln beachtet werden, in die Strukturen von Ereignisgesteuerten Prozessketten abbilden.

Nur für standardisierte Abläufe

Sie sind nicht geeignet für Abläufe, die dem nicht entsprechen, deren mögliche "Wege" nur unzureichend vorherbestimmbar sind. Sie sind auch nicht geeignet für kreative oder auch nur komplexe Tätigkeiten. Um hier einsetzbar zu sein, müsste das Instrumentarium der "Methode EPK" gewaltig erweitert werden, was dann aber ihre Einsetzbarkeit für standardisierte Abläufe wiederum einschränken würde.

11 Andere Methoden

In diesem Kapitel soll kurz auf die anderen zwei wichtigen Methoden zur Prozessmodellierung eingegangen werden, die Aktivitätsdiagramme der UMLund die Business Process Diagrams (BPD) der BPMN. Diese und die Methode EPK werden auch anhand eines Geschäftsprozesses direkt verglichen. Dies ist allerdings ein einfacher Geschäftsprozess, ansonsten würde der Vergleich den Rahmen des Buches sprengen. Der Beispielsprozess ist als BPD und als Aktivitätsdiagramm in den einschlägigen Texten der OMG veröffentlicht. Er ist einfach, enthält aber doch so viele Elemente und einen rudimentären Kontrollfluss, dass er einen ersten Eindruck von den Methoden vermittelt.

11.1 Geschäftsprozess Auftragsbearbeitung als EPK

Der Geschäftsprozess beginnt damit, dass ein Auftrag eingeht. In einer EPK wird dies als Startereignis modelliert. Dieses Ereignis stößt die Bearbeitung des Auftragseingangs an. Realisiert wird dies durch die Abteilung Auftragsbearbeitung (AuftrBearb). Danach wird - durch Auswertung des Informationsobjekts Auftrag - entschieden, ob der Auftrag angenommen oder abgelehnt wird. Wird er abgelehnt geht es gleich nach flussabwärts vor die Funktion Auftrag schließen.

Auftragseingang

Wird er angenommen folgt die Auftragsbearbeitung. Ist sie durchgeführt, werden Lieferung und Rechnung senden angestoßen. Hier kommt ein UND-Operator zum Einsatz. Die Zahlung durch den Kunden und die Einbindung dieser Zahlung in den Kontrollfluss kann in einer EPK durch einen eigenen Zweig, startend mit Zahlung ist durchzuführen, und dem Einbinden dieses Zweiges mit Hilfe eines UND-Operators realisiert werden.

Auftragsbearbeitung
und mehr

Wenn dann das Finanzwesen die Zahlung akzeptiert hat und nach der Ausführung des Auftrags die Lieferung erfolgte werden die beiden Kontrollflusszweige wieder mit UND zusammengeführt. Vor der letzten Funktion folgt die Wiederverknüpfung der beiden alternativen Zweige und die Funktion Auftrag schließen wird angestoßen. Das nachfolgende Ereignis stellt das Schlussereignis dar.

Abspann

Diese EPK entspricht dem OMG-Beispiel (einer Aktivität), vgl. die Abbildungen unten.

Abbildung 11.1-1: Aktivität Auftragsbearbeitung als EPK
Übersetzt und modelliert durch den Verfasser nach dem Aktivitätsdiagramm in [OMG 2003, S. 290, Figure 203]

Abkürzung:

AuftrBearb: Auftragsbearbeitung

11.2 Business Process Diagrams der BPML

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].

BPMN: Business Process Model and Notation

Eine Abgrenzung nehmen sie 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".

Abgrenzung

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 die 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.

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 entsteht 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 zusammen an­spruchsvollere 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.

Geschäftsprozesse

Wie definieren die BPMN-Autoren Geschäftsprozesse? Im Text finden wir folgende Definitionsmerkmale [OMG 2011, S. 145]:

Definition

• Ein Geschäftsprozess ist eine Aktivität, die in einer Organisation oder zwischen mehreren ausgeführt wird.
• Das Ziel eines Prozesses ist eine Leistungserbringung.
• Ein Prozess besteht aus Aktivitäten, Ereignissen, Operatoren (hier Gateways genannt) und einem Sequenzfluss. Er wird dann dargestellt als ein Graph für die genannten Elemente.
• Prozesse gibt es auf mehreren Hierarchieebenen. Man kann sie unter­nehmens­weit definieren oder auch entlang der Aktivitäten einer Person.
• Prozesse auf einem niedrigen Aggregationsniveau (low-level processes), die zusammen eine Aufgabe erledigen, können gruppiert werden.
• Jeder Prozess kann seine eigenen Subprozesse haben und kann in einem Pool enthalten sein.
• Einzelne Prozesse können voneinander unabhängig sein, was den Sequenzfluss angeht, aber verbunden durch einen Nachrichtenfluss.

Wenn es um die Interaktion zwischen Prozessen und Prozessbestandteilen geht, sprechen sie von Orchestrierungund Choreographie[OMG 2011, S. 145], wie es sich ja auch in den Texten zur serviceorientierten Architektur (SOA) eingebürgert hat.

Damit sind einige Elemente zusammengestellt, die man für die Modellierung von Geschäftsprozessen benötigt (vgl. Abschnitt 12.1). Die Aktivitäten sind die kleinsten Einheiten (des Geschäftsprozesses, der Tätigkeitsfolge), aus denen man den Gesamtprozess zusammenstellt. Der Sequenzfluss erlaubt die Festlegung, wie die Aktivitäten aufeinander folgen, wie sie verzweigen und wieder zusammenkommen, ähnlich dem ansonsten üblichen Kontrollflusskonzept. Die Ereignisse trennen die elementaren Tätigkeiten und die Operatoren, hier mit Gateways bezeichnet, erlauben die Strukturierung des Kontrollflusses in der üblichen Art und Weise.

Basiselemente einer Prozessmodellierung

Aktivitäten
Sequenzfluss
Ereignisse
Gateways
...

Prozess vs. Geschäftsprozess

Bezüglich der Abgrenzung von Prozessen und Geschäftsprozessen führen die BPMN-Autoren aus, dass sie den Begriff Prozess spezifisch sehen und den des Geschäftsprozesses allgemeiner als eine Menge von Aktivitäten, die innerhalb einer Organisation oder über Organisationen hinweg realisiert werden. Somit kann ein Geschäftsprozess, wie er in ein Business Process Diagram integriert ist, mehr als einen separaten Prozess enthalten.

Im Rahmen ihrer Typisierung von Geschäftsprozessen sprechen sie von "end-to-end BPMN model” und unterscheiden drei Basistypen [OMG 2011, S. 22]:

• Interne nicht ausführbare Geschäftsprozesse (private non-executable (internal) business processes)
• Interne ausführbare Geschäftsprozesse (private executable (internal) business processes)
• Öffentliche Prozesse (public processes)

Mit Internen Geschäftsprozessen sind schlicht die gemeint, die innerhalb eines Unternehmens ablaufen. 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. [Staud 2010]), können die BPMN-Autoren auch definieren, dass die internen Prozesse in einem Becken (pool) ablaufen.

Interne Geschäftsprozesse

Kommt es zu einer Interaktion (i.d. Regel ist dies ein Informationsfluss, z.B. eine Rechnung) zwischen einem internen Geschäftsprozess und anderen Prozessen oder Partizipanten, sprechen die BPMN-Autoren von einem öffentlichen Geschäftsprozess. In diesen wird folgendes gepackt:

Öffentliche Geschäftsprozesse

• Die Aktivitäten, die benutzt werden, um mit der Umgebung des privaten Geschäftsprozesses zu kommunizieren.
• Die entsprechenden Sequenzflusselemente.

Alle anderen Aktivitäten des internen Prozesses werden nicht angegeben [OMG 2009, S. 13]. Somit zeigt der öffentliche Prozess der Außenwelt die Folge von Nachrichten, die notwendig sind, um mit diesem Geschäftsprozess zu interagieren.

Ein Globaler Prozess beschreibt das Zusammenwirken von zwei oder mehr Geschäftseinheiten (business entities). Die Interaktionen sind eine Folge von Aktivitäten, die den Nachrichtenaustausch zwischen den handelnden Einheiten darstellen.

Globale Prozesse

Diagrammtypen

Folgende Diagrammtypen sollen mit der BPMN modellierbar sein [OMG 2009, Seite 14f]:

• 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
• Einen globalen Prozess alleine ("e.g., ebXML BPSS or RosettaNet").
• 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.

Ganz nebenbei wird in obiger Liste bzgl. der vertikalen Dimension (Aggregationslevel, vgl. Abschnitt 12.2) noch die naheliegende Unterscheidung von

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

eingeführt. Somit haben wir insgesamt folgende Prozess- und Geschäftsprozesstypen in der BPMN:

Prozesstypen

• Hoch aggregierte Aktivitäten interner Prozesse
• Interne Geschäftsprozesse
• Detaillierte interne Geschäftsprozesse
• Öffentliche Geschäftsprozesse
• Globale Prozesse

Gruppierung der Elemente

Die BPMN-Autoren teilen die verwendeten Elemente 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 (Operatoren