Josef Ludwig Staud: Prozessmodellierung mit Ereignisgesteuerten Prozessketten (EPKs) und der Business Process Model and Notation (BPMN)

Prozessmodellierung mit Ereignisgesteuerten Prozessketten (EPKs) und der Business Process Model and Notation (BPMN)
Copyright 2014 - 2026 Josef L. Staud
Autor: Dr. Josef L. Staud
Stand: Mai 2025
Dieser Text enthält eine Zusammenfassung meiner Materialien zu Ereignisgesteuerten Prozessketten und Business Process Diagrams der BPMN, die ich in der Lehre an Hochschulen und in sonstigen Seminaren eingesetzt habe. Ich pflege sie weiter, weil das Thema und die Methoden weiterhin von Bedeutung sind.
Web und Buch
Dieser Text erscheint gleichzeitig als Printversion und als Text im Internet. Auf www.staud.info finden sich die bibliographischen Angaben. Die Version im Web ist leicht gekürzt, außerdem enthält die Printversion eine umfassende Indexierung.
Die Beschäftigung mit Ereignisgesteuerten Prozessketten führt zwangsläufig zu großen Abbildungen. Diese sind neben der Veröffentlichung im Text zusätzlich an anderer Stelle in größerem Format und höherer grafischer Qualität unter folgenden Adressen veröffentlicht:
https://www.staud.info/grafiken2020/GrafikenEPK.php und
https://www.staud.info/grafiken2020/GrafikenBPMN.php
Aufbereitung für's Web
Diese HTML-/PHP-Seiten wurden mithilfe eines von mir erstellten Programms erzeugt: WebGenerator (Version 2026). Es setzt Texte in HTML-/PHP-Seiten um und ist in ständiger Weiterentwicklung. 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 (hs@staud.info).
Urheberrecht
Dieser Text ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Textes oder von Teilen dieses Textes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.
Warenzeichen und Markenschutz
Alle in diesem Text genannten Gebrauchsnamen, Handelsnamen, Marken, Produktnamen, usw. unterliegen warenzeichen-, marken- oder patentrechtlichem Schutz bzw. sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Inhaber. Die Wiedergabe solcher Namen und Bezeichnungen in diesem Text berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Gesetzgebung zu Warenzeichen und Markenschutz als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
Prof. Dr. Josef L. Staud
staud@staud.info

1 Einleitung

1.1 Vorbemerkung

Das Thema Prozessgestaltung bzw. Prozessoptimierung ist von zentraler Bedeutung für alle Unternehmen und sonstigen Organisationen. Es ist eine ständige Aufgabe. Prozessoptimierung aber bedarf der Erfassung der Prozesse, ihrer Beschreibung durch Prozessmodelle. Erst nach dieser Erfassung können Schwachstellen erkannt und beseitigt und neue Angebote der Prozessgestaltung im Rahmen der Digitalisierung und Automatisierung eingebaut werden.

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äftige Prozessmodelle, was hoffentlich in diesem Text 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, z.B. die Methode BPMN.

Methoden

Für die Darstellung von Prozessbeispielen verwende ich die Begriffe inhaltliches Beispiel und abstraktes Beispiel. Inhaltliche Beispiele veranschaulichen einen Prozess(abachnitt) anhand konkreter, domänenspezifischer Situationen. Sie zeigen, wie ein Prozess in der Praxis funktioniert, indem sie sich auf realistische Aufgaben, Dokumente und Entscheidungen beziehen. Abstrakte Beispiele hingegen nutzen vereinfachte und allgemeine Konstrukte, die unabhängig von einem konkreten fachlichen Kontext sind. Ihr Zweck besteht darin, die zugrunde liegenden syntaktischen Modellierungsprinzipien hervorzuheben, ohne durch domänenspezifische Details abzulenken.

Prozessbeispiele

1.2 Abkürzungsverzeichnis

Die folgenden Abkürzungen werden im Text verwendet. Abkürzungen in den Ereignisgesteuerten Prozessketten und Business Process Diagrams werden beim jeweiligen Prozessmodell erläutert.

Kürzel

Langbezeichnung

AD

Aktivitätsdiagramm der UML

aE

Auslösende Ereignisse

ARIS

Architektur integrierter Informationssysteme

B2C

Business to Customer

BPD

Business Process Diagram

BPMN

Business Process Modeling Notation. Ab Version 2.0: Business Process Model and Notation

BPR

Business Process Reengineering

DV

Datenverarbeitung

EDV

Elektronische Datenverarbeitung

eE

Erzeugte Ereignisse

eEPK

erweiterte Ereignisgesteuerte Prozesskette

EPK

(einfache) Ereignisgesteuerte Prozesskette

ERP

Enterprise Resource Planning. Etablierte Bezeichnung für integrierte prozessorientierte Standardsoftware.

GP

Geschäftsprozess

IS

Informationssystem

IT

Eigentlich Informationstechnologie, bzw. information technology. Heute benutzt als Kurzbezeichnung für die gesamte EDV-Ausstattung einer Organisation.

ODER

Logischer Operator ODER

RE

Requirements Engineering (Anforderungsmanagement)

UND

Logischer Operator UND

vs.

versus (im Vergleich zu, im Gegensatz zu)

XODER

Logischer Operator EXKLUSIVES ODER

1.3 Aufbau der Arbeit

Dieser Text soll die Leserin und auch den Leser Schritt um Schritt in die Modellierung von Geschäftsprozessen mit Ereignisgesteuerten Prozessketten und Business Process Diagrams (der BPMN) einführen. Entsprechend ist der Aufbau.

Kapitel 2 stellt - ganz allgemein - vor, wie die Literatur Geschäftsprozesse und Prozessmodellierung definiert und sieht.

Ab Kapitel 3 werden Ereignisgesteuerten Prozessketten betrachtet.

Kapitel 3 stellt die Grundlagen vor, so wie die Urheber der Methode (Scheer und sein Team) sie definiert haben.

Kapitel 4 vertieft dies durch Darstellung der Basismuster, die in Ereignisgesteuerten Prozessketten auftreten können.

Kapitel 5 stellt mit Hilfe eines kommentierten Beispiels eine Einführung in die Prozessmodellierung mit EPKs dar.

Kapitel 6 enthält eine Zusammenfassung der Syntaxregeln, Empfehlungen zur Pragmatik der Prozessmodellierung und einige Gestaltungsregeln.

Weitere Ausführungen zu EPKs und ihrer Modellierung finden sich in [Staud 2025]. Darunter auch, in Kapitel 8, zahlreiche Beispiele von Ereignisgesteuerten Prozessketten mit unterschiedlichen modellierungstechnischen Schwerpunkten

Ab Kapitel 7 folgt die Kurzbeschreibung der BPMN (Business Process Model and Notation).

Kapitel 7 stellt dar, wie die BPMN-Autoren Geschäftsprozesse sehen.

Kapitel 8 zeigt einführende Beispiele, mit denen die wichtigsten Komponenten und Strukturmerkmale vorgestellt werden.

Kapitel 9 geht auf die Erfassung der einzelnen Prozessschritte ein.

Kapitel 10 zeigt, Informationen und ihre Verarbeitung in BPDs ausgedrückt werden.

Kapitel 11 stellt dar, wie Ereignisse mit der BPMN gesehen und erfasst werden.

Kapitel 12 widmet sich der Darstellung von Sequenzflüssen.

Kapitel 13 vertieft dann die schon vorher getätigten Ausführungen zu Gateways, den Operatoren der BPMN.

Eine umfassende Beschreibung der Business Process Diagrams, so heißen die Prozessmodelle der BPMN, findet sich in [Staud 2024].

2 Geschäftsprozesse und Prozessmodellierung

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

2.1 Definition

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

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

Elementar-
aufgaben,
Aufgaben

Eine Aufgabe ist eine betriebliche Funktion mit einem bestimmbaren Ergebnis. Sie wird von Menschen, Software 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 Aggregation genannt. Damit wird deutlich, was dann bei der konkreten Modellierung von Geschäftsprozessen eine wichtige Rolle spielt:

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

Subjektives Aggregationsniveau

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 [Staud 2025, Abschnitt 12.2].

Funktionen

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

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

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äftsobjekte gemeint. Dieser Objektbegriff stimmt weitgehend (bei den meisten Autoren allerdings unausgesprochen bzw. unbewusst) mit dem allgemeinen Objektbegriff der objektorientierten Theorie überein. Es handelt sich immer um Informationsträger (z.B. eine Rechnung) mit Eigenschaften (Attributen) und einem Verhalten (bzw. zulässigen Veränderungen). Z.B. um Rechnungen mit Attributen wie Rechnungsnummer, Rechnungsdatum, Rechnungsempfänger, usw., die bezahlt oder storniert werden können.

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 Vorgang wie folgt definiert:

"Ein Vorgang ist ein zeitverbrauchendes Geschehen, das durch ein Startereignis ausgelöst und durch ein Endereignis abgeschlossen wird. Einem Vorgang können in Abhängigkeit von Vorgangsergebnissen unterschiedliche Ablaufverzweigungen, auch Rücksprünge, folgen." [Scheer 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

Der Autor definiert Geschäftsprozesse in Organisationen - basierend auf der Analyse der Definitionen in der Literatur und den eigenen praktischen Erfahrungen - wie folgt:

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 der Organisation.

Ergänzt wurden die Anwendungsprogramme als Aufgabenträger. Dies ist in einer Zeit zunehmender Automatisierung von Geschäftsprozessen unabdingbar.

Geschäftsprozesse leisten somit die Transformation von beschafften Produktionsfaktoren in verkaufte Produkte bzw. Dienstleistungen. In ihrem Zusammenhang beschreiben die Geschäftsprozesse auch die Wertschöpfungskette des Unternehmens.

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

Einzelne Tätigkeiten, aus denen der Geschäftsprozess zusammengesetzt ist.

Der Zusammenhang zwischen diesen, er wird später Kontrollfluss 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.

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

Heute [Anmerkung] spielen allerdings die aktuellen KI-Techniken dabei eine wichtige Rolle. Welche Aufgaben können nun durch diese realisiert werden? Wie kann man diese in die Geschäftsprozesse integrieren?

Beispiele

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

Angebotserstellung (Erstellung eines Angebots, nachdem eine Anfrage einging)

Auftragsvergabe (Vergabe eines Auftrags an einen Lieferanten)

Beschaffung (z.B. von Teilen für die Produktion)

Mahnwesen (z.B. als regelmäßiger Abgleich von offenen Posten und Zahlungseingängen).

und, ein meist sehr langer Geschäftsprozess,

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

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

Kundenbefragung (z.B. im Rahmen des Customer Relationship Managements (CRM)).

Personaleinstellung

Zahlungsabwicklung

Genehmigung einer Investition oder

Fakturierung

2.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. [Staud 2025], 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 2019, Kapitel 13]).

Unterstützung vs. Automatisierung

Die Automatisierung wird seit einigen Jahren durch die Entwicklung der KI auf eine neue Ebene getrieben. Dies nicht nur durch den Einsatz von Programmen für die Text- und Sprachbeherrschung, sondern auch durch Softwareagenten zur Steuerung von Prozessen und zum verbesserten Process Mining, dem digitalen Aufzeichnen von Prozessabläufen.

KI für Geschäftsprozesse

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 Text programmnahe Prozessmodellierung genannt. Damit soll eine Prozessmodellierung bezeichnet werden, die - z.B. im Rahmen des Requirement Engineerings - unmittelbar der Vorbereitung der Programmierung dient. Vgl. dazu [Staud 2025, Abschnitt 12.5 sowie [Staud 2019] für die dann einzusetzenden Methoden der UML.

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 weiterhin 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 (z.B. zu einem 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 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.

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.

Erkennen nicht ausreichender Datenintegration

Wir erreichen hier eine der Grenzen der Prozessmodellierung (vgl. [Staud 2025, Abschnitt 10.2]). Die Datenintegration benötigt die datenbanktechnische Analyse der Datenbestände, um einen Schritt in Richtung integrierter Unternehmensdatenbank gehen zu können.

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 beinhaltet die umfassende Bestandsaufnahme eines bestehenden Prozesses 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:

Optimierung

Fehlende Datenintegration, d.h. Dateninseln

Fehlende Prozessintegration, d.h. Organisationsbrüche

Zu lange Transportzeiten von Prozessobjekten (Dokumente, Rechnungen, CAD-Zeichnungen, usw.)

Zu lange Warte- und Liegezeiten von Prozessobjekten

Zu lange Bearbeitungszeit

Zu lange Rüst- und Durchlaufzeiten

Redundante Tätigkeiten

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

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

Zu lange Kommunikations- und Entscheidungswege

Zu hohe Gesamtkosten der Prozesse

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

Unzulängliche Prozessverantwortlichkeit

Fragmentierte Verantwortlichkeiten.

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

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 Herausforderungen in der Prozessmodellierung? Die wichtigsten können mit den Schlagworten Detaillierungsgrad, Automatisierung und Nutzung von KI beschrieben werden.

2.4.1 Detaillierungsgrad

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

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

Der Begriff Detaillierungsgrad bezeichnet den Grad der Ausarbeitung, mit dem ein Geschäftsprozess in einem Modell dargestellt wird. Ein hoher Detaillierungsgrad bedeutet, dass alle einzelnen Tätigkeiten und Entscheidungspunkte explizit modelliert werden, während ein niedriger Detaillierungsgrad auf eine stärker aggregierte Darstellung von Aktivitäten hinweist.

Definition

Der angemessene Detaillierungsgrad hängt vom Modellierungsziel ab: Für Implementierung oder Automatisierung sind detaillierte Modelle erforderlich, während für Dokumentations- oder Übersichtszwecke weniger detaillierte Modelle ausreichend sein können.

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

2.4.3 Nutzung von KI

Dieser Text ist in Vorbereitung.

3 Grundlagen von Ereignisgesteuerten Prozessketten

Vorbemerkung: Für alle Verweise auf [Staud 2025] gilt: Eine Kurzfassung dieses Buches findet sich auf meinen WebSeiten: https://www.staud.info/epk2/ep_t_1.php

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. Kontrollfluss des 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 in [Staud 2025]).

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 entwickelt (vgl. [Keller, Nüttgens und Scheer 1992], [Scheer 1997]). Für eine Kurzdarstellung vgl. [Staud 2025, Abschnitt 13.1].

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 [Scheer 1997] wurden, bei der Herleitung des ARIS-Konzepts, die Elemente von Geschäftsprozessen genannt. Diese fasst er bei der konkreten Ausformulierung der Methode EPK 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 den Modellierern überlassen. Der in [Staud 2025, 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 Zeitverbrauch fü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 in [Staud 2025].

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 Funktionen sollte 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 Ereignissen sollte genau so wie in diesen Beispielen erfolgen, als aussagenlogischer Ausdruck. Das macht den Ereignischarakter klar.

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 Ereignisraum des 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 hervorgehoben zu werden: das Startereignis und 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 Organisationseinheiten wird festgehalten, wer die in einer Funktion erfasste Aufgabe tätigt. Dazu kann man eine klassische Organisationseinheit (Abteilung, Stelle, usw.) angeben oder die Anwendungssoftware, die automatisiert die Funktion realisiert. Die Anwendungssoftware kann konventionell programmiert sein, wie die typische ERP-Software, oder mit den modernen KI-Techniken.

Wer erfüllt die Aufgabe?

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.

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

In vielen Projekten ist es üblich, die Organisationseinheiten bei 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 [Staud 2025, 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äftsobjekte und seine informationelle Umwelt ganz oder in Ausschnitten modellieren. Diese Datenbestände sind damit auch für die Abwicklung der Geschäftsprozesse von großer Bedeutung. In Ereignisgesteuerten Prozessketten schlägt sich dies so nieder, dass bei den Funktionen die jeweils geholten (erhaltenen) 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.

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

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

IO 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äger berü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 Automatisierungsgrad des betrachteten Geschäftsprozesses. In nicht oder nur teilweise automatisierten Abschnitten werden die Informationsobjekte oftmals (aber nicht immer!) nicht digital sein.

IO und Automatisierung

3.7 Kontrollfluss

In der Einleitung zu diesem Kapitel wurde schon das Konstrukt eines Kontrollflusses eingefü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.

Die unsichtbare, ordnende Hand

Ein einzelner konkreter Durchgang durch den Prozess wird mit Instanz bezeichnet. Damit könnte man auch den Kontrollfluss als die Gesamtheit aller möglichen Instanzen des Geschäftsprozesses bezeichnen. Mehr zu Instanzen und vor allem Beispiele finden sich in Abschnitt 5.5.

Instanzen eines Geschäftsprozesses

Eine Anmerkung für die mit der objektorientierten Theorie vertrauten: Eine gewisse Parallele ist mit den Begriffen Geschäftsprozessmodell und Geschäftsprozessinstanz zu den Begriffen Klasse und Instanz gegeben. Ersteres bezeichnet das abstrahierte, allgemeine und gibt die Gesamtstruktur an, zweiteres bezeichnet eine konkrete Ausprägung. Damit ist der Vergleich aber schon am Ende.

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

Kontrollfluss hat auch etwas mit Weisungsbefugnis zu tun. Die unternehmensinternen Abläufe sind (natürlich) auch dadurch geprägt. An bestimmten Stelleln im Geschäftsprozess gibt es Entscheidungssituationen, die von den Prozessträgern bewältigt werden müssen. Eine solche Weisungsbefugnis gibt es normalerweise nicht gegenüber den Partnern des Unternehmens. Deshalb lassen die Urheber der Methode BPMN (vgl. unten sowie [Staud 2024]) für die Kontakte "nach außen" nur Nachrichtenflüsse, keine Kontroll-, oder wie es dort heißt, Sequenzflüsse, zu.

Weisungsbefugnis

Die im Kontrollfluss nacheinander folgenden Ereignisse und Funktionen werden durch Pfeillinien verbunden. Mehr dazu in den folgenden Kapiteln. Diese Pfeillinien werden oft auch Kanten genannt, in Anlehnung an die Begrifflichkeit der Graphentheorie. Mehrere solche Kanten mit ihren Ereignissen und Funktionen stellen einen Kontrollflusszweig dar. 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.

flussabwärts und -aufwärts

3.8 Operatoren und Kontrollfluss

Der Kontrollfluss eines Geschäftsprozesses besteht nicht nur aus einfachen Abfolgen von Ereignissen und Funktionen, sondern auch aus Verzweigungen von Kontrollflusszweigen 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 4

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

In den grafischen Darstellungen geht man bei Ereignisgesteuerten Prozessketten meist von der Festlegung aus, dass der Kontrollfluss der Ü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 um 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 die drei Operatoren UND, ODER, XODER erfolgen.

Zwei zusätzliche Begriffe sollen bezüglich der Operatoren noch unterschieden werden: Verteiler und 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 Dimension aus. Die Prüfung Lagerbestand kann erst dann gestartet 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 einer Funktion, 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 mit Speichermöglichkeiten etablieren könnten. Die Grundphilosophie ist wie folgt: Informationen werden bei ihrer Entstehung in die integrierte Unternehmensdatenbank geschrieben und später im Prozess bei Bedarf wieder gelesen. Dies entspricht auch der Umsetzung bei ERP-Software, wenn sie nicht Workflow-Komponenten haben, die natürlich auf einem direkten Informationsaustausch aufbauen.

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.

3.10 Anmerkung zur Gestaltung der Grafiken mit EPKs

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

Gleichbleibende Organisationseinheiten. 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.

Transport von Information. 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 [Staud 2025, Abschnitt 7.1].

Funktion - Funktion - Funktion - ... Es ist in vielen Unternehmen ü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.

4 Basismuster

4.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 4.1-1: Mögliche Verknüpfungen von Ereignissen und Funktionen durch Operatoren

E: Ereignis, F: Funktion

Eine größere und grafisch detailliertere Version dieser Grafik findet sich hier:
https://www.staud.info/grafiken2020/GrafikenEPK.php#unterpunkt211

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.

4.2 Ereignisverknüpfung mit auslösenden Ereignissen

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

Ereignisse als Bedingungen

4.2.1 UND

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

Gemeinsame Bedingungen

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

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

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

4.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 4.2-2: Ereignisverknüpfung / Auslösende Ereignisse / XODER

4.2.3 ODER

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

Mindestens ein Ereignis muss eintreten

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

... wenn bereits ein Geschwister in der KITA ist (Geschwisterermäßigung).

... das Einkommen der Erziehungsberechtigten unter 2000,-- Euro liegt.

... der/die Erziehungsberechtigte allein erziehend ist.

... der/die Erziehungsberechtigte Sozialleistungen bezieht.

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

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

4.3.1 UND

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

Teilaufgaben mit UND

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

Abbildung 4.3-1: Ereignisverknüpfung / Erzeugte Ereignisse / UND

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 [Staud 2025, Abschnitt 6.2].

Keine Parallelität im technischen Sinne

4.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 4.3-2: Ereignisverknüpfung / Erzeugte Ereignisse / XODER

Transportgesellschaften:
UPS (United Parcel Service, Inc.) - US-amerikanischer Paket- und Logistikdienstleister
DHL (DHL Express / DHL Group) - deutscher, weltweit tätiger Logistikdienstleister
DPD (Dynamic Parcel Distribution) - französischer, europaweit tätiger Paketdienst

4.3.3 ODER

Die Syntax des ODER-Operators sagt in der Anordnung dieses Abschnitts, dass mindestens ein Ereignis eintreten muss, damit es im Kontrollfluss 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 4.3-3: Ereignisverknüpfung / erzeugte Ereignisse / ODER

Kurze Erläuterung zu einigen Bankprodukten
Girokonto
Ein Girokonto ist ein Bankkonto für den täglichen Zahlungsverkehr. Es wird zum Empfangen von Gehalt, zum Bezahlen von Rechnungen und für Überweisungen genutzt.
Debitkarte (EC-Karte)
Eine Debitkarte ist direkt mit dem Girokonto verbunden. Zahlungen und Abhebungen werden sofort vom Kontoguthaben abgebucht.
Kreditkarte
Mit einer Kreditkarte kann der Kunde bezahlen, auch wenn das Geld nicht sofort vom Konto abgebucht wird. Die Ausgaben werden gesammelt und später abgerechnet.
Sparkonto (Sparbuch)
Ein Sparkonto dient dazu, Geld sicher aufzubewahren und zu sparen. Das Geld ist meist nicht für den täglichen Zahlungsverkehr gedacht.
Dispokredit (Überziehungskredit)
Ein Dispokredit erlaubt es, das Girokonto bis zu einem bestimmten Betrag zu überziehen. Dafür fallen in der Regel hohe Zinsen an.
Darlehen (Kredit)
Ein Darlehen ist ein größerer Geldbetrag, den die Bank dem Kunden für einen bestimmten Zweck leiht und der über einen längeren Zeitraum zurückgezahlt wird.
Depot (Wertpapierkonto)
Ein Depot ist ein Konto zur Verwahrung von Wertpapieren wie Aktien oder Fonds. Es wird für Geldanlagen genutzt.
Schließfach
Ein Schließfach ist ein sicherer Aufbewahrungsort in der Bank, z. B. für Schmuck oder wichtige Dokumente.

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 4.3-4: Ereignisverknüpfung / erzeugte Ereignisse / ODER
Wareneingangsprüfung

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

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

Definition

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

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

4.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 diesbezüglich keine Probleme. Ein Ereignis kann zum parallelen Start zweier oder mehrerer Funktionen führen.

Wohl bekannt:
ein Ereignis startet mehrere zu erledigende 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 4.4-1: UND / Funktionsverknüpfung / auslösendes Ereignis -
1. Beispiel

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

4.4.2 XODER - verboten

Die folgende Anordnung ist eine von den Urhebern der Methode EPK 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 4.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 4.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.

4.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 4.4-5: Funktionsverknüpfung / auslösendes Ereignis/ ODER - ohne Entscheidungsfunktion

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

Richtige Lösung mit Entscheidungs-
funktion

Eine Zusammenfassung aller wichtigen Syntaxregeln findet sich in Abschnitt 6.1. 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.

Das folgende Beispiel zeigt die korrekte Lösung der obigen Situation. Hier wurden, damit sie nicht in Vergessenheit geraten, auch mal wieder Organisationseinheiten und Informationsobjekte angefügt.

Abbildung 4.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

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

4.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 folgt ein gemeinsames Ergebnisereignis

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 4.5-1: UND / Funktionsverknüpfung / erzeugtes Ereignis

Anmerkungen:
Semantik: Mehrere Tätigkeiten sind durchgeführt, dann geht es im Geschäftsprozess in einem Kontrollflusszweig weiter.
Syntax: Mehrere Funktionen, Verknüpfung durch UND, nachfolgendes Ereignis.

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

Stellenbesetzung - etwas umfangreicher

Gespräch mit Bewerber führen

Assessmentcenter durchführen

Bewerberunterlagen getätigt

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

Die folgende EPK zeigt die Umsetzung dieser Prozessbeschreibung in ein Modell. Neben der Einbettung des obigen Fragments zeigt das Beispiel auch ein Muster, das hier Zeitfenster genannt wird (vgl. für eine tiefere Betrachtung [Staud 2025, 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 4.5-2: Stellenbesetzung - Mögliche Einbettung des EPK-Fragments von Abb. 4.5-1

Anmerkungen:
Muster: Zeitfenster
Syntaxregel: Zusammenführen Kontrollflüsse

Hier ist auch eine Syntaxregel umgesetzt, die das Zusammenführen von Kontrollflusszweigen betrifft (vgl. [Staud 2025, 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

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

Alternative Tätigkeiten mit einem Ergebnisereignis:
XODER

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.

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

4.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 Verfügbare Daten zusammengestellt ein, wenn die davor stehenden Funktionen im Sinne des ODER ("mindestens eine") durchgeführt wurden. Danach können dann Kalkulation und Angebot erstellt werden.

Mindestens eine Funktion muss realisiert werden

Um dieses EPK-Fragment besser 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.

Das EPK-Fragment zeigt die Schlussphase einer Kalkulation in einem Industriebetrieb. Abhängig davon, ob bereits eine identische Anlage, eine ähnliche Anlage oder einzelne Komponenten zuvor geliefert wurden, stehen unterschiedliche Informationsgrundlagen zur Verfügung.

Semantik

Mindestens eine dieser Voraussetzungen muss erfüllt sein, damit die verfügbaren Daten zusammengestellt werden können. Der ODER-Operator drückt aus, dass eine oder mehrere der dargestellten Funktionen ausgeführt wurden, bevor der Geschäftsprozess mit der Erstellung von Kalkulation und Angebot fortgesetzt wird.

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

4.6 Semantische Bedeutung

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.

Diese Tabelle gibt also einen Überblick über die möglichen Kombinationen von Ereignissen, Funktionen und Verknüpfungen im Kontrollfluss von EPKs. Sie ist entlang zweier Dimensionen aufgebaut.

Lesehilfe

Die Zeilen unterscheiden, ob Ereignisse oder Funktionen verknüpft werden und ob sich die Verknüpfung auf auslösende oder erzeugte Elemente bezieht.

Die Spalten zeigen die Semantik der drei logischen Operatoren UND, XODER und ODER.

Für jede Kombination ist angegeben, unter welchen Bedingungen Ereignisse eintreten oder Funktionen angestoßen werden und wie die Erledigung von Funktionen zu nachfolgenden Ereignissen führt. Als VERBOTENE STRUKTUR gekennzeichnete Anordnungen verstoßen gegen die Syntaxregeln von EPKs und dürfen in gültigen Modellen nicht verwendet werden.

Insgesamt dient die Tabelle als kompakte Referenz zum Verständnis der semantischen Bedeutung und der syntaktischen Einschränkungen von Verknüpfungen in EPKs.

Abbildung 4.6-1: Die Rolle der Ereignisse in den 12 Verknüpfungsvarianten

5 Ereignisgesteuerten Prozessketten - Ein kommentiertes Beispiel

Das folgende Beispiel erläutert die Basiselemente und die Struktur von Ereignisgesteuerten Prozessketten. Jede Komponente wird in ihrem Zusammenhang erläutert, so dass die Leser die Syntax und die zugrundeliegende Prozesslogik verstehen können.

5.1 Anfrageprüfung Teil 1

Die oben vorgestellten 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 6.

Regeln für die Erstellung von Ereignisgesteuerten Prozessketten

Um die Anschaulichkeit zu erhöhen, wird den Ausführungen ein einfacher Geschäftsprozessabschnitt 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.

Es folgt, Stück für Stück, eine Prozessbeschreibung. Die zugehörigen Texte sind immer eingerückt.

Prozessausschnitt Anfrageprüfung - Teil 1

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

Funktionen

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

Antwortbrief verfassen und versenden

Maileingang bestätigen

AFL erstellen und dem potentiellen Kunden senden

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

Abbildung 5.1-1: Grafische Darstellung von Funktionen

AFL: Auftragsfestlegung

Ereignisse

Die Startereignisse sind in der Prozessbeschreibung klar beschrieben:

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 Ergebnisereignisse genannt werden. Alle diese sechs Ereignisse zeigt die folgende Abbildung.

Abbildung 5.1-2: Grafische Darstellung von Ereignissen

AFL: Auftragsfestlegung

Kontrollfluss: Funktionen und Ereignisse immer schön nacheinander.

Doch nun zum Kontrollfluss dieser Anfangssequenz. Ganz grundsätzlich wird die Syntaxregel eingehalten, dass Funktionen und Ereignisse sich immer ablösen müssen und dass jeder Geschäftsprozess mit einem Ereignis endet und beginnt (die Ausnahme mit Prozesswegweisern wird in [Staud 2025, Abschnitt 7.4] betrachtet). Die drei Startereignisse stellen den Anfang von Kontrollflusszweigen dar, 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.

Informationsobjekte und Organisations-einheiten

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.

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

AFL: Auftragsfestlegung

5.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 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 Kontrollflusszweige muss 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 5.2-1: Geschäftsprozess Anfrageprüfung - Zusammenführung alternativer Startsequenzen (XODER)

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 [Staud 2025, 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 5.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 jeweils ein XODER-Operator eingefügt werden.

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

Semantik sucht Syntax

Es ist in jeder Modellierung eines Anwendungsbereichs so, dass es neben den simplen abzubildenden Strukturen komplexere semantische Aspekte 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 5.3-1: Geschäftsprozess Anfrageprüfung - Positives Ergebnis und Aufruf Auftragsabwicklung

Verweis auf andere EPK durch Prozesswegweiser

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 Prozesswegweiser auf 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.

Abbildung 5.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 Bedingungen für die Ausführung der nachfolgenden Funktion dar.

Muster Bedingungen

5.4 Anfrageprüfung Teil 4

Die Prozessbeschreibung kommt nun zu den negativen Ergebnissen.

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

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

Semantik sucht Syntax: Kombinatorik mit Hilfe des UND-Operators

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.

Abbildung 5.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

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

Die Umsetzung dieser Semantik in die Syntax einer EPK zeigt die folgende Abbildung. Vor die Funktion Dem Kunden absagen wird ein ODER-Operator gesetzt, 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.

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 5.4-2: Geschäftsprozess Anfrageprüfung - Die finale EPK

5.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 bezeichnet und der konkrete Geschäftsprozessdurchgang als Instanzdes "allgemeinen" Geschäftsprozesses.

Kontrollfluss:
einzelne Durchgänge

Die folgende Abbildung stellt eine Instanz der obigen EPK dar, den positiven Fall. Der Kontrollfluss für diesen (Auftrag kann angenommen, Folgeprozess kann gestartet werden) ist durch eine verdickte/gestrichelte 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 5.5-1: Geschäftsprozess Anfrageprüfung. Die Instanz für den positiven Ausgang

Kontrollfluss für einen der negativen Fälle

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

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 5.5-2: Geschäftsprozess Anfrageprüfung. Die Instanz für einen der negativen Fälle

6 Das Regelwerk für die Erstellung von EPKs

Es ist einer der großen Vorzüge der Ereignisgesteuerten Prozessketten, dass ihre Erstellung mit wenigen Regeln beschrieben werden kann. Der Grund liegt darin, dass sie eine klare Struktur haben und dass sie nicht, wie andere Methoden zur Prozessmodellierung, zahlreiche Varianten oder auch ungeklärte Bereiche aufweisen. Hier nun die wichtigsten Regeln zur Syntax, zur Pragmatik und zur grafischen Gestaltung.

6.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 in [Staud 2025] und in diesem Text detailliert angeführt und werden hier zusammengefasst:

(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 also 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 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 Kontrollfluss 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 Kontrollflusszweigen 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.

6.2 Empfehlungen zur Pragmatik

Pragmatik bei der Erstellung von EPKs

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 von [Staud 2025] beschrieben. Hier nun die Zusammenfassung der wichtigsten diesbezüglichen Regeln.

(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 [Staud 2025, Abbildung 6.8-1].

(Wiederholung) Verzicht auf Rücksprung bei Wiederholung [STaud 2025, Abbildung 6.8-2].

(Zusammenhänge im Zeitfenster) Verzicht auf Beachtung der Zusammenhänge zwischen den Funktionen eines Zeitfensters [Staud 2025, Abbildung 6.3-1], bzw. nach einem UND-Operator [Staud 2025, Abbildung 5.4-2].

(Entscheidungen) "Verschmelzen" zweier Operatoren bzw. Entscheidungen (vgl. [Staud 2025, Abschnitt 7.3]).

(Kombinatorik) Vereinfachung durch Abstraktion bei Auffächerung durch Kombinatorik (vgl. [Staud 2025, 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.

Anmerkung vom Januar 2026: Angesichts der aktuellen Entwicklungen in der KI ist die obige Anmerkung vielleicht schon (bald) überholt. KI-Agenten (bzw. ähnliche Softwareprodukte) könnten helfen, die komplexe Vielfalt von Geschäftsprozessen zu bewältigen. Allerdings sollten dann noch einige Geburtsfehler der aktuellen KI-Lösungen beseitigt werden, z.B. das "Halluzinieren", der Energiebedarf bei der Erstellung, die Manipulierbarkeit mittels der Datenbasis, usw.

6.3 Gestaltungsregeln

Weitere Regeln, die zur endgültigen Form der Ereignisgesteuerten Prozessketten beitragen, sind die Gestaltungsregeln, die in [Staud 2025, Abschnitt 1.2] und hier in Abschnitt 3.10 vorgestellt werden. Hier die wichtigsten:

(Organisationseinheiten) Weglassen der Organisationseinheiten, falls sie gleich sind wie bei der vorigen Funktion.

Werden zwei aufeinanderfolgende Funktionen beide vom Vertrieb ausgeführt, wird die Organisationseinheit nur einmal dargestellt. Bei der zweiten Funktion kann sie weggelassen werden.

(Informationstransport) Darstellen Informationstransport ohne Pfeilrichtung.

Wird ein Dokument lediglich von einer Funktion zur nächsten weitergegeben, ohne verändert zu werden, wird das Informationsobjekt ohne Pfeilrichtung dargestellt. Dies kennzeichnet reinen Transport.

(Weglassen Ereignisse) Weglassen der Ereignisse bei unverzweigter Abfolge.

In einer einfachen, unverzweigten Abfolge von Funktionen können Zwischenereignisse weggelassen werden. Der Prozess bleibt verständlich und wird übersichtlicher.

Das war's zu den Ereignisgesteuerten Prozessketten. Eine vertieftere Darstellung findet sich in [Staud 2025] und - natürlich - in den Büchern von Scheer et al., den Urhebern der Methode.
Nach Meinung des Verfassers sind Ereignisgesteuerte Prozessketten hervorragend geeignet für den Einstieg in das Thema Geschäftsprozesse und Prozessmodellierung. Mit ihnen kann der Prozessgedanke vermittelt und erste Methodenkompetenz erworben werden.
EPKs sind auch zum Beispiel für Ist-Analysen die Methode der Wahl.

Die folgenden Kapitel stellen die Grundlagen der Methode Business Process Model and Notation (BPMN) dar. Dabei erfolgt in dieser Kurzfassung eine Konzentration auf die wichtigsten Theorieelemente. Aber auch diese sollte deutlich machen, dass Business Process Diagramms (BPDs; so nennt man die Prozessmodelle der BPMN) wesentlich komplexer sind als EPKs und eine vertieftere Modellierung der Geschäftsprozesse erlauben und damit insbeonsere geeignet sind für eine Modellierung im Rahmen des Software Engineering, also zu Vorbereitung einer Umsetzung in eine Software.
Für die nähere Beschäftigung gibt es auch hier eine Arbeit des Verfassers [Staud 2024] und die Texte der Urheber der Methode, u.a. [OMG 2003], . [OMG 2009], [OMG 2011], [OMG 2013].

7 Geschäftsprozesse in der BPMN

Vorbemerkung: Für alle Verweise auf [Staud 2024] gilt: Eine Kurzfassung dieses Buches findet sich auf meinen WebSeiten: https://www.staud.info/bpmn2/bp_t_1.php

Beginnen wir mit zwei Zitaten der Urheber der Methode. Das erste zum Anspruch:

"Business Process Model and Notation has become the de-facto standard for business processes diagrams. It is intended to be used directly by the stakeholders who design, manage and realize business processes, but at the same time be precise enough to allow BPMN diagrams to be translated into software process components. BPMN has an easy-to-use flowchart-like notation that is independent of any particular implementation environment". [https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/, abgerufen am 11.11.2025]

Das zweite zur Umsetzung der Prozessmodellierung:

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

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

7.1 Definition

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

Ein Geschäftsprozess beschreibt eine zielgerichtete Folge von Aktivitäten in einer Organisation. Er besteht aus mehreren Aktivitäten und den Sequenzflussmechanismen, die sie strukturieren [OMG 2011, S. 145].

Es gibt drei Prozesstypen: Private Non-executable (internal) Business Processes, Private Executable (internal) Business Processes, Public Processes [ebenda, S. 149].

Prozesse gibt es auf mehreren Hierarchieebenen. Man kann sie unternehmensweit definieren oder auch entlang der Aktivitäten einer Person [ebenda, S. 32].

Prozesse auf einem niedrigen Aggregationsniveau (Low-Level Prozesse), die zusammen eine Aufgabe erledigen, können gruppiert werden.

Jeder Prozess kann seine eigenen Subprozesse haben und kann in einem Becken (pool) enthalten sein.

Einzelne Prozesse können - was den Sequenzfluss angeht - voneinander unabhängig sein, aber verbunden durch einen Nachrichtenfluss (oder mehrere).

Es gibt eine zentrale, den Geschäftsprozess steuernde Einheit (central controller, responsible entity or observer) [ebenda, S. 25].

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

7.2 Prozesstypen in der BPMN

Interne Geschäftsprozesse (Private Business Process)

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

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

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

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

Öffentliche Geschäftsprozesse (Public Processes)

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

Globale Prozesse (Global Processes)

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

7.3 Diagrammtypen

Folgende Diagrammtypen sollen mit der BPMN modellierbar sein:

Hoch aggregierte interne Prozesse

Detaillierte interne Geschäftsprozesse (Istprozesse, Sollprozesse)

Detaillierte interne Geschäftsprozesse mit Interaktionen zu einem externen Partner oder zu mehreren

Zwei oder mehr detaillierte interne Geschäftsprozesse, die miteinander interagieren

Detaillierte Geschäftsprozesse mit Beziehungen zu einem öffentlichen Prozess

Beziehungen eines detaillierten internen Geschäftsprozesses zu einem globalen Prozess

Zwei oder mehr öffentliche Prozesse

Beziehung(en) eines öffentlichen Prozesses zu einem globalen Prozess

Ein globaler Prozess alleine

Zwei oder mehr detaillierte interne Geschäftsprozesse, die durch einen öffentlichen Prozess interagieren

Zwei oder mehr detaillierte interne Geschäftsprozesse, die durch einen globalen Prozess interagieren.

Zwei oder mehr detaillierte interne Geschäftsprozesse, die durch ihre abstrakten Prozesse und einen Kollaborationsprozess interagieren.

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

Vertikale Dimension der Prozessmodellierung

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

hoch aggregierten Aktivitäten interner Prozesse und

detaillierten internen Geschäftsprozessen

eingeführt.

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

7.4 Gruppierung der Elemente

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

Flussobjekte (flow objects)

Verknüpfende Objekte (connecting objects)

Schwimmbahnen (swimlanes)

Artifakte (artifacts)

Die Flussobjekte werden noch unterteilt in:

Ereignisse

Aktivitäten

Gateways

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

Sequenzfluss

Nachrichtenfluss

Assoziationen

Schwimmbahnen dienen der Gruppierung der Basismodellelemente. Hier wird unterschieden in

Becken

Bahnen

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

Datenobjekte

Gruppen

Anmerkungen

7.5 Token

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

Knoten und Kanten

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

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

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

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

Token und Instanzen

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

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

Falls die Instanz durch ein instantiierendes Parallel Gateway erzeugt wurde, müssen alle nachfolgenden Ereignisse dieses Gateways eingetreten sein.

Es gibt keinen Token mehr in der Prozessinstanz.

Keine Aktivität des Prozess ist mehr aktiv.

Weitere Festlegungen zum Tokenfluss sind bei den Methodenkomponenten zu finden.

8 BPMN - Einführende Beispiele

8.1 Das erste Business Process Diagram

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

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

Der Sequenzfluss gibt die Abfolge der einzelnen Aktivitäten im Geschäftsprozess an. Er wird durch gerichtete Pfeile ausgedrückt, die die einzelnen Aktivitäten verbinden. Außerdem sieht die Methode Start- und Schlussereignisse (Kreis mit dünner bzw. dicker Linie) für den Anfang und das Endes eines Geschäftsprozesses vor. Damit kann man bereits ein erstes natürlich noch sehr schlichtes Business Process Diagram (BPD), so werden die Prozessmodelle hier genannt, erstellen: Eine Folge von Aktivitäten, die - einmal initiiert - nacheinander abgewickelt werden.

Abbildung 8.1-2: Auftragsabwicklung - Variante 1

Verwendete Elemente, von links nach rechts: Startereignis Top Level, vier Aktivitäten, Schlussereignis Terminate.

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

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

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

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

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

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

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

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

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

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

Für das Zusammenführen von Sequenzflüssen wird der Operator genommen, nach dem aufgeteilt wurde.

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

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

Enthaltene Elemente:
- Startereignis
- Exclusive Gateway mit Voreinstellung
- Aufgabe
- Parallel Gateway, verzweigend
- Parallel Gateway, verknüpfend
- Exclusive Gateway, verknüpfend
- Schlussereignis

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

8.2 Jetzt mit Daten

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

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

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

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

Enthaltene Elemente - zusätzlich zur vorigen Abbildung:
- Datenobjekt

Mehr zu Datenobjekten findet sich in [Staud 2024, Kapitel 8].

8.3 Handelnde - Träger der Aktivitäten

Für eine Basisausstattung einer Methode zur Prozessmodellierung fehlen jetzt nur noch die im Geschäftsprozess Handelnden, die Träger der Aktivitäten. Diese werden zuerst einmal für die einzelnen Aktivitäten bestimmt. Möglich sind hier Menschen oder auch Programme, mit oder ohne Maschinen [Anmerkung] .

Für die Zuordnung der Träger von Aktivitäten zu größeren Einheiten haben die BPMN-Autoren die bekannte Schwimmbahnentechnik gewählt. Bei ihr werden Becken (pools) und Bahnen (lanes) angelegt. Becken erfassen die übergeordneten Träger (z.B. ganze Unternehmen), Bahnen die untergeordenten (z.B. Abteilungen oder Personen auf Stellen). Die folgende Abbildung zeigt das erweiterte einführende Beispiel.

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

Wir nehmen ab dieser Stelle den Kunden mit dazu. Dies erlaubt, zwei ergänzende Theorieelemente zu verdeutlichen. Zum einen, dass unabhängige Teilnehmer am Prozess jeweils ein eigenes Becken erhalten und dass die Informationsweitergabe über die Grenzen von Becken in der Methode BPMN als Nachrichtenfluss zu modellieren ist. Deshalb gibt es in der folgenden Abbildung ein eigenes Becken Kunde.

Zwischen verschiedenen "handelnden Einheiten" [Anmerkung] gibt es - so der Vorschlag der BPMN-Autoren - keine Sequenzflüsse, sondern Nachrichtenflüsse. Deshalb wurde hier das Verschicken der Rechnung zum Kunden als Nachricht modelliert. Das Datenobjekt Rechnung kann bei dieser Anordnung an den Nachrichtenfluss angehängt werden.

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

Enthaltene Elemente - zusätzlich zur vorigen Abbildung:
- Becken
- Bahn
- Nachrichtenfluss

8.4 Ein öffentlicher Geschäftsprozess

Die BPMN-Autoren verstehen unter öffentlichen Geschäftsprozessen solche, die zwischen einem internen Geschäftsprozess und einem externen stattfinden.

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

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

Enthaltene Elemente:
- Becken
- Becken mit öffentlichem Prozess
- Startereignis
- Aufgaben
- Nachrichtenflüsse

8.5 Zusammenarbeit

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

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

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

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

Enthaltene Elemente:- Startereignis
- Aufgabe
- Schlussereignis
- Nachrichtenfluss
- öffentlicher Geschäftsprozess
- Nachrichten zwischen Prozessen

Zwischenbemerkung:
Obige Beispiele sollten das Potential der Methode BPMN deutlich gemacht haben, so dass jetzt detaillierte Erklärungen zu den Methodenelementen und zur Methodensyntax folgen können. Hier deshalb, auch wieder zusammengefasst, Ausführungen zu Tätigkeiten, Datenobjekten, Ereignissen, zum Kontrolfluss und zu Gateways. Detaillierte Beschreibungen finden sich in der Originalquelle [OMG 2013] und in [Staud 2024].

9 BPMN - Prozessschritte

9.1 Aktivitäten

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

Abbildung 9.1-1: Grafische Darstellung von Aktivitäten

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

Aufgaben(task)

Subprozesse(sub process)

Prozesse

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

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

9.2 Aufgaben

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

Definition Aufgabe (BPMN)

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

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

9.2.1 Varianten

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

Aufgaben mit Schleifencharakter durch eine Schleifenmarkierung (loop marker).

Aufgaben, die parallel mehrfach durchgeführt werden können (bei denen also gleichzeitig mehrere Instanzen gestartet werden können) durch eine Mehrfachinstanzmarkierung (multi instance marker).

Aufgaben, die als Ersatz für andere dienen ("zur Kompensation") durch eine Kompensationsmarkierung (compensation marker) .

Die folgende Abbildung zeigt die grafische Darstellung der Markierungselemente.

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

Mehrfachinstanzen

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

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

Abbildung 9.2-2: Grafische Darstellung von Aufgaben - Mehrfachinstanzmarkierungen

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

Kompensationen

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

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

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

Ein Beispiel ist die Durchführung einer Hotelbuchung über ein Internetportal. Scheitert diese, muss man ersatzweise per Telefon direkt buchen. Diese Ersatzbuchung ist die die Aufgabe mit Kompensationsmarkierung.

Aufgaben mit Schleifencharakter

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

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

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

Auch bei Subprozessen

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

9.2.2 Aufgabentypen

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

Anteil des Mitwirkens von Menschen

Anteil von Software an der Erledigung

Ausrichtung auf Nachrichtenverkehr

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

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

Handarbeit (manual task object)

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

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

Abbildung 9.2-3: Grafische Darstellung von Aufgaben - Handarbeit

Nutzer-Aufgabe (user task object)

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

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

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

Dienst (service task object)

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

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

Sender

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

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

Nach dem Versenden der Nachricht ist die Aufgabe abgearbeitet.

Empfänger-Aufgabe

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

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

Nach dem Empfangen der Nachricht ist die Aufgabe abgearbeitet.

Prozessstart-Aufgabe

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

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

Vgl. hierzu auch [Staud 2024, Abschnitt 12.1], wo das Muster Prozessstart diskutiert wird.

Geschäftsregel-Aufgabe

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

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

Skript-Aufgabe

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

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

Abbildung 9.2-10: Grafische Darstellung von Aufgaben - Skript

Globale Aufgabe

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

Globale Nutzer-Aufgabe (global user task)

Globale Handarbeit (global manual task)

Globales Skript (global script task)

Globale Geschäftsregel (global business rule task)

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

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

9.3 Subprozesse

9.3.1 Entfaltet oder verborgen

Subprozesse werden wie Aufgaben durch ein grafisches Symbol dargestellt. Sie beschreiben mehrere prozessmäßig zusammenhängende Arbeitsschritte. Werden diese grafisch dargestellt, wird von einem entfalteten, ansonsten von einem verborgenen Subprozess gesprochen. Die Unterscheidung entfaltet (expanded) / verborgen (collapsed) bezieht sich also nur auf die Darstellung.

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

Definition Subprozess

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

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

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

Abbildung 9.3-1: Darstellung eines verborgenen Subprozesses

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

Abbildung 9.3-2: Darstellung eines entfalteten Subprozesses

Motivation

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

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

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

Damit können auch mehrere Modellierungsebenen dargestellt werden, die von "oben nach unten" immer detaillierter werden. Solche Darstellungen erleichtern den Einstieg in ein komplexes Prozessmodell und den Überblick über seine gesamten Funktionalitäten.

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

9.3.2 Varianten

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

Subprozesse mit Schleife: durch eine unterbrochene schmale Linie in Kreisform mit Pfeilkopf.

Subprozesse mit Parallelverarbeitung: parallele oder sequentielle Mehrfachinstanzen mit drei senkrechten bzw. parallelen Linien.

Subprozesse für Ersatzaktivitäten (compensation): durch zwei nach links zeigende Dreiecke.

Ad hoc - Subprozesse: durch eine Tilde.

Es kann vorkommen, dass ein Subprozess mehrere dieser Merkmale und damit mehrere dieser Kennzeichen hat. In einem solchen Fall werden alle zu einem Subprozess gehörigen Kennzeichen zusammengestellt und zentriert am inneren unteren Rand des Subprozessrahmens angegeben.

Schleifen

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

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

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

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

Mehrfachinstanzen

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

Subprozesse mit Mehrfachinstanz - parallel (multi-instance, parallel)

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

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

Die Motivation für diese Methodenelemente ist wohl der Wunsch, komplexe Prozessabläufe beschreibbar zu machen.

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

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

Kompensationen

Ein Kompensations-Subprozess übernimmt eine Aufgabe als Ersatz für eine andere, falls diese scheitert. Betrachten wir folgende Situation: Eine Hotelbuchung per Internet/Portal ist als Subprozess modelliert. Im Gesamtprozess soll ausgedrückt werden, dass bei einem Scheitern desselbigen ersatzweise telefonisch bei einem Reisebüro gebucht wird. Dies ist dann ein Kompensations-Subprozess. Die Kennzeichnung von Kompensations-Subprozessen erfolgt durch zwei nach links zeigende Dreiecke.

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

Ad hoc - Verborgen

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

Kreative Tätigkeiten, z.B. der Entwurf einer Strategie für eine Produkteinführung, Tätigkeiten bei der Erstellung eines Kapitels für ein Fachbuch (Gegenstand erarbeiten, Grafiken erzeugen, Verweise klären, Text schreiben, Grafiken in Text einbinden, Text editieren, usw.)

Miteinbeziehung nicht standardisierter Prozesse in ein Prozessmodell (aus was für Gründen auch immer)

Solche Abläufe sind, wenn man nicht abstrahiert, durchaus nur sehr schwer durch einfache Sequenzflüsse modellierbar. "Abstrahieren" meint hier, dass zum Beispiel statt der einzelnen Aufgaben eines größeren Projekts das Gesamtprojekt als Aufgabe angelegt wird. Also "Fachbuch erstellen" statt Gegenstand erarbeiten, Grafiken erzeugen, Verweise klären, Text schreiben, Grafiken in Text einbinden, Text editieren, usw.

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

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

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

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

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

Ad hoc - Entfaltet

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

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

Enthaltene Elemente:
- Entfalteter Subprozess mit Mehrfachinstanz (parallel).
- Aufgabe, ohne Markierung
- Aufgabe mit Mehrfachinstanz, parallel
- Aufgabe mit Schleife

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

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

Vorhanden sein müssen: Aktivitäten.

Vorhanden sein können: Datenobjekte, Sequenzflüsse, Assoziationen, Gruppen, Nachrichtenflüsse (als Quelle oder Ziel), Gateways und Zwischenereignisse.

Nicht vorhanden sein dürfen u.a.: Startereignisse, Schlussereignisse, und Choreographie-Aktivitäten.

Die BPM-Autoren führen aus, dass es für eine "BPM engine" eine Herausforderung darstellt, den Status von Ad hoc-Prozessen zu beobachten. Diese Art von Prozessen wird üblicherweise durch Groupware (groupware applications) unterstützt.

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

Mehrere Kennzeichnungen

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

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

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

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

9.3.3 Wofür Subprozesse?

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

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

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

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

Vertiefung

In [Staud 2024] finden sich zu folgenden Themen Vertiefungen zu Subprozessen:

Eingebettete und referenzierte Subprozesse (embedded sub-process)

Wiederverwendbare Subprozesse (reusable sub processes; call activities)

Ereignis-Subprozesse (event sub processes)

Transaktionen

Call Activity

Ereignissubprozesse

Transaktionen

10 BPMN - Informationen und ihre Verarbeitung

10.1 Daten und Informationen

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

Datenobjekte

Datenobjekte liefern Informationen darüber, was der Prozess leistet, wie Dokumente, Daten und andere Objekte im Prozess genutzt und aktualisiert werden.

Sie liefern Informationen darüber, was Aktivitäten für ihre Umsetzung benötigen und/oder was sie erzeugen.

Sie haben keinen direkten Einfluss auf den Kontroll- oder Nachrichtenfluss [OMG 2009, Seite 19].

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

Datenobjekt (data object)

Dateninput (data input)

Datenoutput (data output)

Datenspeicher (data store)

Abbildung 10.1-1: Darstellung des Modellelements Datenobjekt

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

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

Datenspeicher

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

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

10.2 Assoziationen

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

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

Definition Assoziation

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

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

Abbildung 10.2-1: Darstellung einer gerichteten Assoziation

Assoziationen für Artefakte

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

Abbildung 10.2-2: Artefakt Textliche Anmerkung

10.3 Daten im Geschäftsprozess

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

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

Datentransport entlang eines Sequenzflusses.

Einfacher Datentransport, der sogar ohne Sequenzfluss vorhanden sein kann (d.h., dass er den Zusammenhalt des Prozesses modelliert).

Entstehende Information, d.h., in einer Aufgabe entsteht ein Datenobjekt.

Einfließende Information, d.h. das Datenobjekt wird in der Aufgabe benötigt.

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

Abbildung 10.3-1: Assoziation von Datenobjekt mit Sequenzflusskante

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

Die Bedeutung ist wie folgt:

In der sendenden Aktivität entsteht das Datenobjekt.

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

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

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

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

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

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

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

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

In der konkreten Praxis der BPMN-Modellierung wird auf die direkte Modellierung des Datentransports oft verzichtet. Das Datenobjekt taucht dann einfach an einer nachfolgenden flussabwärts gelegenen Aktivität wieder auf, meist mit einem veränderten Zustand. Wie im folgenden Beispiel, wo eine eingegangene Rechnung vor der Bezahlung gegengezeichnet werden muss.

Abbildung 10.3-5: Datentransport ohne expliziten Transport

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

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

Prozessfragment:
- Entfalteter Ad hoc - Subprozess mit Mehrfachinstanz (parallel). Die Modellvorstellung ist also, dass an mehreren Kapiteln gleichzeitig gearbeitet wird.
Enthaltene Elemente:
- Ad Hoc-Markierung
- Ad Hoc-Subprozess
- Aggregation
- Assoziation
- Assoziation, gerichtet
- Schleifen-Aufgabe
- Aufgaben
- Datenobjekt (Erzeugung)
- Datenobjekt (lesend))
- Datenobjekt (verändernd)
- Datenobjekt am Sequenzfluss
- Mehrfachinstanz-Aufgabe, parallel
- Mehrfachinstanz-Markierung

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

11 BPMN - Ereignisse

11.1 Konzept

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

Definition Ereignis

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

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

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

Erstens als Ereignisse, die im Geschäftsprozess erzeugt werden und dann dort oder nach außen Wirkung erzielen.

Zweitens als Ereignisse, die von außen auf den Geschäftsprozess einwirken.

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

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

Der Empfang von Ereignissen ist aus dem Anwendungsbereich, in dem der Prozess stattfindet, möglich.

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

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

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

Start einer Aktivität

Ende einer Aktivität

Veränderung eines Dokuments

Eintreffende Nachricht

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

Startereignisse (start events)

Zwischenereignisse (intermediate events)

Schlussereignisse (end events)

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

Grafische Darstellung

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

Abbildung 11.1-1: Darstellung eines Ereignisses - allgemeine Form

11.2 Ausdifferenzierung

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

Startereignisse werden mit einer einzelnen dünnen Linie gezeichnet

Zwischenereignisse erhalten zwei dünne Linien

Schlussereignisse werden mit einer dicken Linie gezeichnet

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

Empfangend (catching) und Abgebend (throwing)

Empfangend (catching) bedeutet, dass es ...

Definition

... im realen Geschäftsprozess ein Prozesselement gibt, das Ereignisse wahrnehmen kann.

... im Prozessmodell ein Prozesselement gibt, das dies ausdrückt.

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

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

Abgebend (throwing) bedeutet, dass es ...

... im realen Geschäftsprozess ein Prozesselement gibt, das Ereignisse erzeugt und dem Ereignisraum bekannt macht.

... im Prozessmodell ein Prozesselement gibt, das dies ausdrückt.

[OMG 2011, S. 275].

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

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

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

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

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

Startereignis / Ereignissubprozess, unterbrechend (event sub-process, interrupting)

Startereignis / Ereignissubprozess, nicht unterbrechend (event sub-process, none interrupting)

Zwischenereignis / Grenzlinie, unterbrechend(boundary, interrupting)

Zwischenereignis / Grenzlinie, nicht unterbrechend(boundary, non interrupting)

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

Ereignisauslöser

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

1. Kein bestimmter Auslöser (none).

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

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

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

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

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

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

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

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

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

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

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

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

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

In der folgenden Abbildung sind alle Ereignistypen mit ihren grafischen Darstellungen zusammengestellt. Für eine ausführliche Beschreibung der Auslöser, auch in Zusammenhang mit den Ereignistypen und der Art des Auslösers vgl. [Staud 2024, Abschnitt 9.2].

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

In der Abbildung ist auch zu erkennen, dass nicht alle Marker in allen Ereignistypen vorkommen. Dazu mehr in [Staud 2024, Kapitel 4].

12 BPMN - Kontrollfluss , Sequenzfluss

12.1 Einführung

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

Definition: Sequenzfluss (sequence flow)

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

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

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

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

Ein anderer Faktor kommt - unausgesprochen - dazu. Kontrollfluss meint vom Begriff her, dass eine Aktion eine andere anfordern kann. Wenn die Abteilunsleitung den zuständigen Mitarbeiter auffordert, ein Angebot für eine Kundenanfrage zu erstellen muss er oder sie dies tun. Dies ist innerhalb eines Unternehmens möglich, nicht aber zwischen unterschiedlichen Unternehmen. Wenn man einem Unternehmen einen Auftrag erteilt, muss es diesen nicht annehmen. Da die BPMN vom Ansatz her auch Abläufe zwischen Unternehmen bzw. Organisationen erfassen will, lag also die Begriffswahl Sequenzfluss nahe.

12.2 Flüsse

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

Normalen Sequenzfluss

Verknüpfungen

Ad hoc (kein Fluss)

Unkontrollierten Fluss

Fluss mit Bedingungen

Voreingestellten Fluss

Flüsse für Ausnahmen

Normaler Sequenzfluss (normal flow)

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

Abbildung 12.2-1: Darstellung einer Sequenzflusskante

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

Unkontrollierter Fluss (uncontrolled flow)

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

Fluss mit Bedingungen (conditional flow)

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

Abbildung 12.2-2: Darstellung eines Flusses mit Bedingung

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

Voreingestellter Fluss (default flow)

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

Abbildung 12.2-3: Darstellung eines voreingestellten Flusses

Flüsse für Ausnahmen (exception flow)

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

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

Abbildung 12.2-4: Darstellung eines Ausnahmeflusses

Enthaltenes Element:

- Fehler-Zwischenereignis / Grenzlinie, unterbrechend

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

Sind zwei Wochen vergangen (bei einer zeitlichen Abfrage)?

Ist ein Notfall eingetreten?

Ist eine Ersatzaktivität auszuführen?

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

IF

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

Ereignisraum

13 BPMN - Gateways

13.1 Grundlagen

Wie oben mehrfach dargestellt, muss zwischen dem Prozessmodell, das alle möglichen Durchgänge durch den Geschäftsprozess beschreibt, und einer Instanz des Modells, die einen konkreten Durchgang durch den Geschäftsprozess festhält, unterschieden werden. Diese Unterscheidung wird hier bei der Erläuterung der Gateways benötigt, weil auch für die Gateways gilt, dass im Prozessmodell alle möglichen Verzweigungen bzw. Verschmelzungen bedacht werden müssen, die bei den einzelnen Instanzen vorliegen können.

Instanzen

Wozu Gateways (Operatoren)?

In Geschäftsprozessen kommt es vor, dass sich an einer Stelle die Abläufe vervielfachen (verzweigen) oder auch, dass mehrere zusammenkommen (verschmelzen), weil es danach in einem Fluss weitergeht. Solche Stellen sind wichtig und müssen dargestellt werden.

Für diese Situationen wurden in der Prozessmodellierung Operatoren entwickelt, im wesentlichen der UND-, ODER- und XODER-Operator (vgl. Abschnitt 3.1), die verzweigend und verknüpfend eingesetzt werden. Auch die BPMN hat diese Operatoren, sie werden hier Gatewaysgenannt und um einige weiteren Varianten ergänzt. Durch die Gateways kann nun also geklärt werden, welche Situation vorliegt, ...

wenn mehrere Flüsse (Kontroll- bzw. Sequenzflüsse) zusammenfließen

wenn mehrere entstehen und fortgeführt werden

Dies ist die durch die Syntax geprägte Sichtweise, die inhaltliche ("Entscheidungen, Teilaufgaben, Bedingungen, ...") wird in Kapitel 12 betrachtet.

Es liegt also zum Beispiel die folgende Situation vor: Zu einem Gateway kommt eine Kante (hier: Sequenzflusszweig) und mehrere gehen weg. Dies ist eine Verzweigung .

Abbildung 13.1-1: Verzweigende Sequenzflusskanten

Oder es kommen mehrere Kanten an und eine geht weg (B), dies wird auch Verknüpfung oder Verschmelzung genannt.

Abbildung 13.1-2: Verschmelzende Sequenzflusskanten

Oder es kommen mehrere an, die verknüpft werden, und es gehen mehrere verzweigende weg.

Abbildung 13.1-3: Verknüpfende und verzweigende Sequenzflusskanten

In allen drei Fällen muss geklärt werden, welche Bedeutung (Semantik) hinter der Verzweigung bzw. Verschmelzung vorliegt.

Situation A

Betrachten wir nur die wegführenden Sequenzflusszweige (Kanten), ankommende (eine oder mehrere) sollen erst mal keine Rolle spielen. Eine solche Verzweigung kann unterschiedliche Ursachen haben:

Die 2 bis n nach dem Gateway angesiedelten Kanten werden beim jeweiligen Durchgang alle aktiv. In einem solchen Fall spricht man von einem UND-Operator, in der BPMN von einem Parallel Gateway (vgl. Abschnitt 11.4) oder von einem Parallel Event Based Gateway (vgl. Abschnitt 11.5) .

Genau eine der wegführenden Kanten wird beim jeweiligen Durchgang aktiv. In einem solchen Fall spricht man von einem exklusiven Oder-Operator (XODER), in der BPMN von einem Exclusive Gateway. Dieses kann in der BPMN datenbasiert (vgl. Abschnitt 11.2) oder ereignisbasiert (vgl. Abschnitt 11.3) sein.

Mindestens eine und ansonsten eine beliebige Teilmenge der wegführenden Kanten wird aktiv. In einem solchen Fall spricht man von einem ODER-Operator, in der BPMN von einem Inclusive Gateway (vgl. Abschnitt 11.6).

Der Typ des verzweigenden Gateways wird also durch die Semantik des jeweiligen Prozessabschnitts bestimmt. Ein Parallel Gateway bedeutet hier (verzweigend) zum Beispiel, dass an dieser Stelle des Geschäftsprozesses mehrere Aufgaben angestoßen werden. Dann wird auch von Teilaufgaben gesprochen.

Ein Exclusive Gateway bedeutet, dass Alternativen vorliegen. Oftmals liegen hier Entscheidungssituationen vor, deren Ergebnis durch die alternativen Kontrollflüsse modelliert wird. Dies ist ein in Geschäftsprozessen sehr häufig vorkommendes Muster.

Weniger vertraut ist meist das Inclusive Gateway. Es kommt aber in Regelungen, Vorschriften und Gesetzen durchaus vor. Hier werden Situationen des Geschäftsprozesses erfasst, bei denen mindestens einer der wegführenden Flüsse aktiv wird. Die Betonung liegt auf "mindestens", es kann also jede beliebige Teilmenge der Sequenzflüsse aktiv werden.

Eine Besonderheit der BPMN stellt das Complex Gateway dar. Es beschreibt Situationen, in denen die Verzweigung nicht mit den übrigen Operatoren abgebildet werden soll (vgl. Abschnitt 11.7).

Situation B

Situation B beschreibt sozusagen das Gegenstück: Mehrere Kanten werden zusammengeführt ("verschmolzen"). Die weiterführenden Sequenzflüsse (einer oder mehrere) spielen hier keine Rolle.

Hier wird durch das Gateway beschrieben, wie die "ankommenden" Kontrollflüsse strukturiert sein müssen, damit der Fluss über das Gateway weiter geht:

Es müssen alle (2 bis n) Kanten ankommen, erst dann geht es über das Gateway weiter. Dann liegt ein Parallel Gateway vor.

Genau eine Kante muss und darf nur ankommen, dann geht es weiter. Dann ist es ein Exclusive Gateway.

Mindestens eine und ansonsten eine beliebige Teilmenge mehrerer Kanten muss ankommen, dann geht es weiter. In einem solchen Fall spricht man von einem Inclusive Gateway.

Bei ankommenden Sequenzflüssen lassen die BPMN-Autoren in ihren Beispielen oftmals das Gateway weg. Sie schreiben dann von unkontrolliertem Fluss. Welches Gateway dann sozusagen implizit vorliegt, muss aus dem Prozesskontext geschlossen werden.

Nach vielen Jahren Lehre in Prozessmodellierung kann ich dazu sagen: Dies ist, v.a. zu Beginn des Erkenntnisprozesses, nicht empfehlenswert.

Situation C

Der Fall, dass gleichzeitig mehrere Kanten ankommen und wegführen, kann auf die obigen beiden Fälle zurückgeführt werden. Die Empfehlung der BPMN-Autoren ist, für diese Situation zwei Gateways zu nutzen, eines für das Verschmelzen (converge) und eines für das Verzweigen (diverge) [OMG 2011, S. 288].

Abbildung 13.1-4: Verzweigende und verschmelzende Sequenzflusskanten

Ereignisgesteuert oder nicht

Grundsätzlich gehen die BPMN-Autoren davon aus, dass der Kontrollfluss in den Gateways (das Verhalten der Token) durch die Daten des Geschäftsprozesses gesteuert wird. So ist auch die Methode angelegt. Damit sind mit dem "normalen" Elementevorrat der Methode die Situationen schwer modellierbar, bei denen der Prozessverlauf durch externe Ereignisse gesteuert wird. Z.B., wenn ein Angebot rausgeschickt wird und das Unternehmen auf die Reaktion des (potentiellen) Kunden wartet. Deshalb wurden zusätzlich Gateways eingeführt, die ereignisgesteuert sind [OMG 2011, S. 297], was zu folgender Unterscheidung führt:

Die eine Gruppe von Gateways wird aus dem Prozess heraus gesteuert, aus den bei ihm abgelegten Daten, d.h. der weitere Fortgang ergibt sich aus dem Prozessgeschehen. Wegen dem Ziel "Umsetzung in eine BP-Engine" kommt es dann zur Formulierung "evaluation of Expressions using Process data".

Die andere Gruppe wird durch Nachrichten externer Teilnehmer am Prozessgeschehen (oder durch zeitliche Aspekte) gesteuert (vgl. die Abschnitte 11.3 und 11.5).

Die Unterscheidung zielt also darauf, woher die steuernde Information für das Gateway kommt.

Grafische Darstellung von Gateways

Gegenüber der UML wollten die BPMN-Autoren wohl die grafische Darstellung von Operatoren / Gateways vereinfachen. Es gibt nur noch ein einziges grafisches Basiselement, mit dem alle dargestellt werden. Dieses besteht aus einer auf die Spitze gestellten Raute.

Abbildung 13.1-5: Darstellung eines Gateways

13.2 Exclusive Gateway - datenbasiert

Das Exclusive Gateway beschreibt Verzweigungen, die auf alternativen Entscheidungen beruhen. Bei jeder Instanz des Geschäftsprozesses (jedem Durchgang) wird nur einer der wegführenden Sequenzflusszweige aktiv. Es kann datenbasiert ("data-based") oder ereignisbasiert ("event-based") sein. Hier zuerst das datenbasierte Gateway, das ereignisbasierte wird im nächsten Abschnitt betrachtet.

Das Exclusive Gateway kann durch das Grundsymbol oder durch ein um ein X ergänztes Grundsymbol dargestellt werden.

Abbildung 13.2-1: Grafische Darstellung des Exclusive Gateway - datenbasiert

Natürlich sollte ein solches Gateway so definiert sein, dass bei jedem Durchgang durch den Prozess (jeder Instanz) immer auch ein Sequenzflusszweig aktiv wird, dass also immer eine der Alternativen eintritt. Sonst könnte es - sozusagen - im Prozess zu einem unerwünschten Stillstand kommen ("deadlock"). Um dies unter allen Umständen zu vermeiden kann in der BPMN ein Sequenzflusszweig als voreingestellt definiert werden ("Else-Zweig"). Der wird aktiv, wenn die anderen nicht eintreten, wenn deren Bedingungen nicht erfüllt sind.

13.2.1 Verzweigend

Im verzweigenden Fall liegt eine Aufgabe vor, nach der mehrere mögliche weiterführende Sequenzflüsse mit Aufgaben angeführt sind, von denen aber in jeder Instanz nur genau eine aktiv wird.

Abstraktes Beispiel

Zuerst ein abstraktes Beispiel, das obige Ausführungen illustriert. Nachdem die Aufgabe A1 erledigt ist, kommt es entweder zu Aufgabe A2 oder A3 oder A4. Weiterhin gilt: Falls A2 oder A3 nicht aktiv werden, wird Aufgabe A4 gestartet. Der Schrägstrich an einer der Sequenzflusskanten identifiziert den oben eingeführten "Else-Zweig".

Abbildung 13.2-2: Datenbasiertes Exclusive Gateway - abstrakt

A: Aktivität
Token
Auf der Basis des Tokenkonzepts kann das Exclusive-Gateway auch so beschrieben werden: Das ankommende Token wird auf genau einen der weiterführenden Sequenzflusszweige geschickt.

Inhaltliches Beispiel

Die folgende Abbildung zeigt ein einfaches inhaltliches Beispiel. Nach einem Auftragseingang wird geprüft, ob der Auftrag angenommen werden kann oder nicht. Der eine Zweig führt dann zur Aufgabe Auftrag annehmen, der andere zu Auftrag ablehnen, der dritte zu Kunde kontaktieren, falls Unklarheiten bestehen und nachgefragt werden muss.

Abbildung 13.2-3: Auftragseingang mit datenbasiertem Exclusive Gateway - verzweigend

13.2.2 Verschmelzend

Kommen alternative Sequenzflusszweige an und müssen verschmolzen werden (z.B., weil es danach in einem einzigen Sequenzfluss weiter geht), wird ebenfalls das Exclusive Gateway benutzt. Es liegt also flussaufwärts eine Entscheidungssituation vor und danach kommen Aufgaben, die für alle Alternativen Gültigkeit haben, weshalb die Sequenzflüsse wieder zusammengeführt werden.

Abstraktes Beispiel

Zuerst ein abstraktes Beispiel. Durch das Exclusive Gateway wird geklärt: A1, A2 und A3 sind alternativ, eine der Aufgaben muss gelöst werden, dann startet A4.

Abbildung 13.2-4: Datenbasiertes Exclusive Gateway - verschmelzend

A: Aktivität

Manchmal sieht man Business Process Diagrams, die an dieser Stelle auf das Gatewaysmbol verzichten. Dies schmälert die Aussagekraft des Prozessmodells und sollte daher vermieden werden.

Lesehinweis:
Dieses Fragment ist korrekt, ...
... falls die Aufgaben A1, A2 und A3 alternativ sind und
... falls es danach mit derselben Aufgabe (A4) weiter geht.
Im Umkehrschluss wird auch folgendes festgelegt:
- Es darf bei jeder Instanz nur genau ein Sequenzflusszweig aktiv werden.
- Es muss auch einer aktiv werden, sonst liegt ebenfalls ein Modellierungsfehler vor.

Inhaltliches Beispiel

Das folgende Beispiel beschreibt die Situation, dass ein Auftrag einging, der entweder abgelehnt oder angenommen wurde oder bei dem es zu Rückfragen beim Auftraggeber kam. Unabhängig davon, welcher Fall eintrat, wird danach die Geschäftsleitung informiert.

Abbildung 13.2-5: Auftragsannahme mit einem datenbasierten Exclusive Gateway - verschmelzend

Anmerkung:
GL = Geschäftsleitung
Token:
Genau ein Token kommt beim Exlusive Gateway an, das dann weitergeschickt wird.

13.3 Exclusive Gateway - ereignisbasiert

Mit dem ereignisbasierten Exclusive Gatewax (event-based Exclusive Gateway) wird eine Entscheidungssitutation beschrieben, die auf Alternativen basiert. Allerdings beruhen sie hier auf Ereignissen, die von außerhalb des Geschäftsprozesses auf den Geschäftsprozess wirken - im Prozess oder im Rahmen einer Choreographie (vgl. Kapitel 13). Diese Ereignisse basieren typischerweise auf Nachrichten und deren Eingang. Auch andere Ereignistypen sind möglich, z.B. Timer.

Es ist ein XODER-Operator, weshalb bei jeder Instanz nur einer der abgehenden Sequenzflüsse aktiv wird, die anderen sind dann nicht mehr gültig. Das Gateway kann mitten im Prozess oder am Prozessbeginn eingesetzt werden.

Das grafische Element ist wie folgt aufgebaut:

Grundlage ist wie immer das Gatewaysymbol, in das ein Ereignissymbol eingefügt ist.

Das Ereignissymbol hat entweder eine Doppellinie, was auf ein empfangendes Zwischenereignis deutet (unterbrechend) oder eine einfache Linie, was auf ein Startereignis deutet.

Abbildung 13.3-1: Grafische Darstellung eines ereignisbasierten Gateway - grundsätzlich und für den Prozessstart

Erinnerung (vgl. Kapitel 9):
Das Symbol in der Mitte deutet auf den Ereignistyp Mehrfach. Die doppelte Kreislinie auf ein Zwischenereignis / empfangend bzw. Grenzlinie, unterbrechend.
Damit ist festgelegt: An dieser Stelle wird auf entsprechende Zwischenereignisse (oder Startereignisse) gewartet, die dann die Sequenzflusszweige aktivieren.

Hier fällt also die Entscheidung durch ein Ereignis, das zum jeweiligen Zeitpunkt im Prozessumfeld auftritt, im informationellen Umfeld bzw. im Ereignisraum des Geschäftsprozesses. Normalerweise wird dies "dem Geschäftsprozess" durch den Empfang einer Nachricht mitgeteilt. Dieses Ereignis legt fest, welcher weiterführende Sequenzflusszweig aktiv wird. Die Entscheidung (die sich in der Nachricht artikuliert) wird somit durch einen anderen Prozessteilnehmer gefällt [OMG 2011, S. 297].

13.3.1 Verzweigend

Die Ereignissteuerung wird dann so modelliert, dass direkt nach dem Gateway die Ereignisse angegeben werden. Dabei sind drei Varianten möglich: Angabe des Ereignisses durch ...

... eine Empfänger-Nachricht

... ein Nachrichtenereignis (als Zwischenereignis)

... einen Zeitgeber (timer)

Syntax

Folgendes merken die BPMN-Autoren zur Syntax des ereignisbasierten Exclusive Gateways an [OMG 2011, 297f]:

Es muss mindestens zwei abgehende Sequenzflüsse haben

Die abgehenden Sequenzflüsse dürfen keine Bedingungen besitzen

Falls Nachrichten-Zwischenereignisse (message intermediate events) benutzt werden, dürfen keine Aufgaben des Typs Empfänger (receive tasks) verwendet werden - und umgekehrt. Dies hat einen syntaktischen Grund. Ein Gateway kann nicht alternativ zu einer Aufgabe mit Nachricht und zu einem Ereignis führen.

Hier benutzte Aufgaben des Typs Empfänger dürfen keine angehängten Zwischenereignisse besitzen.

Nur die folgenden Auslöser von Zwischenereignissen sind zulässig: Nachricht, Signal, Zeitgeber, Bedingung und Mehrfach.

Zielelemente des Gateway in einer solchen Konfiguration dürfen keine anderen ankommenden Sequenzflüsse besitzen, nur den vom Gateway.

Abstrakte Beispiele

Die folgenden abstrakten Beispiele entsprechen denen der Originalquelle. Sie machen deutlich, welche Möglichkeiten die BPMN-Autoren hier sehen. Das erste enthält bei den wegführenden Sequenzflusszweigen zwei Nachrichtenereignisse und ein Ereignis des Typs Zeitgeber.

Abbildung 13.3-2: Abstraktes Beispiel für ein ereignisbasiertes Gateway mit Nachrichtenereignissen und Zeitgeber
Quelle: Leicht modifiziert nach [OMG 2011, Fig. 10.116, S. 298]
Übersetzung durch den Verfasser.

Enthaltene Elemente (Auswahl):
- Exclusive Gateway / ereignisbasiert
- Nachrichten-Zwischenereignis, empfangend
- Zeitgeber-Zwischenereignis / empfangend

Das zweite Beispiel enthält neben dem Zeitgeber zwei Aufgaben des Typs Empfänger. Hier ist der steuernde Nachrichtenempfang durch die zeitliche Einschränkung und zwei Aufgaben definiert, die durch den Nachrichtenempfang aktiviert werden.

Abbildung 13.3-3: Abstraktes Beispiel für ein ereignisbasiertes Gateway mit Aufgaben des Typs Empfänger und Zeitgeber
Quelle: Leicht modifiziert nach [OMG 2011, Fig. 10.117, S. 298]
Übersetzung durch den Verfasser.

Enthaltene Elemente (Auswahl):
- Exclusive Gateway / ereignisbasiert
- Empfänger-Aufgaben
- Zeitgeber-Zwischenereignis / empfangend

Inhaltliche Beispiele

Das erste inhaltliche Beispiel beschreibt folgende Situation: Dem Kunden wurde ein Angebot geschickt, das Unternehmen wartet auf die Antwort. Diese besteht entweder aus einer zusagenden oder einer absagenden Nachricht. Die dritte mögliche "Antwort" ist, dass der Kunde nicht reagiert. Dann wird nach drei Wochen nachgefragt.

Abbildung 13.3-4: Ein Ereignisbasiertes Gateway auf der Basis von Nachrichtenereignissen und einem Zeitgeber.

Enthaltene Elemente (Auswahl):
- Exclusive Gateway / ereignisbasiert
- Nachrichten-Zwischenereignis, empfangend
- Zeitgeber-Zwischenereignis / empfangend
Token:
Ein Token kommt beim Gateway an, abhängig vom Nachrichteneingang bzw. dem zeitlichen Ereignis wird genau ein Token weitergeschickt.

Die Alternative mit Empfänger-Aufgaben zeigt die folgende Abbildung.

Abbildung 13.3-5: Ereignisbasiertes Gateway auf der Basis von Empfänger-Aufgaben und einem Zeitgeber.

Enthaltene Elemente (Auswahl):
- Exclusive Gateway / ereignisbasiert
- Empfänger-Aufgaben
- Zeitgeber-Zwischenereignis / empfangend

13.3.2 Verknüpfend

Für die Verknüpfung so entstandener Sequenzflusszweige kann einfach der im vorigen Abschnitt beschriebene Exclusive Gateway genommen werden. Die Bedeutung ist dann die übliche: Genau einer der Sequenzflüsse muss beim Gateway ankommen, dann geht es weiter.

Abbildung 13.3-6: Ereignisbasiertes Gateway mit anschließender Verknüpfung.

Enthaltene Elemente (Auswahl):
- Bedingungs-Zwischenereignis, empfangend
- Dienst-Aufgabe
- Exclusive Gateway / ereignisbasiert
- Exclusive Gateway / datenbasiert und verknüpfend
- Nachrichten-Zwischenereignis, empfangend
- Nutzer-Aufgabe

Zum Start

Falls diese Semantik für den Start eines Prozesses benötigt wird, ist eine einfache Lösung die folgende, bei der auf die ausdrückliche Darstellung des Gateways verzichtet wird. Die Ereignisse treten alternativ auf, es handelt sich sozusagen um ein exklusives Oder, so dass die geforderte Semantik realisiert ist.

Abbildung 13.3-7: "Exklusiver" Prozessstart durch Ereignisse.
Quelle: Abgeleitet von [OMG 2011, Figure 10.97, S. 275]

Enthaltene Elemente (Auswahl):
- Implizites Exclusiv Gateway
- Nachrichten-Startereignis

Nachteil dieser Lösung ist, dass das Gateway nicht grafisch ausgewiesen ist. Es ist also auf den ersten Blick nicht klar, dass es sich um alternativ auftretende Ereignisse handelt.

Die grafisch aussagekräftigere Lösung wird mit einem verknüpfenden ereignisbasierten Exclusive Gateways für den Prozessstart realisiert. Diesmal aber nicht, wie oben vorgestellt, in der Mitte der Sequenzflüsse, sondern am Anfang des Prozesses.

Das grafische Symbol für dieses Gateway ist das Gatewaysymbol, ergänzt um das Symbol für den Ereignistyp Mehrfach-Startereignis / oberste Ebene (Multiple Start Event). Vgl. die folgende Abbildung.

Abbildung 13.3-8: Darstellung eines ereignisbasierten Exclusive Gateways für den Prozessstart (multiple start event)

Gateway:
- Exclusive Gateway / ereignisbasiert, für den Prozessstart

Da Geschäftsprozesse sehr oft durch alternative Ereignisse gestartet werden, ist dieses Methodenelement auch sinnvoll. Bei dieser Variante des ereignisbasierten Exclusive Gateway darf es keine ankommenden Sequenzflüsse geben, was ansonsten bei Gateways nicht möglich ist. Die Syntax ist dann wie folgt: Das erste passende Ereignis startet den Prozess. Die anderen Ereignisse des Gateway sind dann hinfällig [OMG 2011, S. 426].

Abbildung 13.3-9: Darstellung eines ereignisbasierten Exclusive Gateways für den Prozessstart.
Quelle: Abgeleitet von [OMG 2011, Figure 10.98]

Enthaltene Elemente (Auswahl):
- Bedingungs-Zwischenereignis, empfangend
- Dienst-Aufgabe
- Exclusive Gateway / ereignisbasiert, für den Prozessstart
- Implizites Exclusive Gateway / datenbasiert und verknüpfend
- Nachrichten-Zwischenereignis, empfangend
- Nutzer-Aufgabe
- Signal-Zwischenereignis, empfangend

13.4 Parallel Gateway

Oftmals müssen in Geschäftsprozessen mehrere Aufgaben gelöst werden, um ein bestimmtes Ziel zu erreichen. Oder umgekehrt: Bevor es ab einem gewissen Punkt weiter geht, müssen einige Aufgaben abgearbeitet sein. Sind diese jeweils so gestaltet, dass sie unabhängig voneinander erledigt werden können, kann man sie parallel anordnen. Dies können z.B. Teilaufgabensein.

Man könnte sie modelltechnisch einfach hintereinander anordnen und sequentiell abarbeiten. Dies würde aber den Eindruck erzeugen, sie müssten hintereinander abgearbeitet werden. Deshalb die parallele Anordnung. Für die Prozessmodellierung wurde dafür der UND-Operator geschaffen, der in der BPMN als Parallel Gateway vorliegt.

Parallel meint hier also nur, dass die Aufgaben unabhängig voneinander gestartet und abgearbeitet werden können.

Für das Zusammenführen solcher Sequenzflüsse wird ebenfalls das Parallel Gateway verwendet. Modelltechnisch bedeutet dies:

Bei wegführenden Sequenzflüssen, dass alle nach dem Gateway geplanten Aufgaben bei jeder Instanz aktiv werden müssen.

Bei ankommenden Sequenzflüssen, dass alle vor dem Gateway angeführten Aufgaben bei jeder Instanz auch wirklich aktiv werden müssen.

Für die grafische Darstellung wird ein schwarz eingefärbtes Pluszeichen in das Gatewaysymbol genommen.

Abbildung 13.4-1: Darstellung eines Parallel Gateway

13.4.1 Verzweigend

Abstraktes Beispiel

Die folgende Abbildung zeigt ein abstraktes Beispiel. Nach dem Abschluss von A1 werden die Aufgaben A2 und A3 angestoßen.

Abbildung 13.4-2: Parallel Gateway, verzweigend - abstrakt

A: Aktivität
Gateway:
- Parallel Gateway, verzweigend
Token:
Wenn A1 erledigt ist, kommt ein Token zum Gateway. Dort findet eine Verdoppelung statt. In jedem der abgehenden Sequenzflüsse startet dann ein Token.

Inhaltliches Beispiel

Die folgende Abbildung zeigt ein inhaltliches Beispiel. Ein Auftrag ist eingegangen und wird angelegt. Danach müssen Eigenteile vom Lager angefordert, Fremdteile beschafft und die Produktionsplanung durchgeführt werden.

Abbildung 13.4-3: Parallel Gateway, verzweigend - am Beispiel Auftragseingang

Gateway:
- Parallel Gateway, verzweigend

In dieser Situation ist es nach Maßgabe der BPMN-Autoren auch möglich, auf das Operatorsymbol zu verzichten. Hier betonen die BPMN-Autoren allerdings das Unkontrollierte der Situation, den "unkontrollierten Fluss". Tatsächlich handelt es sich dann um einen impliziten UND-Operator.

Abbildung 13.4-4: Auftragseingang - Beispiel für den Einsatz eines verzweigenden Parallel Gateway ohne Gatewaysymbol

Ganz grundsätzlich gilt: Auf das Weglassen von "selbsterklärenden" Gateways sollte verzichtet werden, dies führt zu unübersichtlichen Prozessmodellen. Der Leser des Modells muss dann aus der Semantik der Prozessstelle auf die Gatewaysituation schließen.

Das zweite inhaltliche Beispiel zeigt eine Situation aus einem Geschäftsprozess zur Abwicklung von Transportaufträgen. Ein Transportauftrag ging ein und wurde erfasst. Danach werden drei Aufgaben angestoßen, die unabhängig voneinander erledigt werden können.

Abbildung 13.4-5: Transportauftrag starten mit Parallel Gateway (verzweigend)

Enthaltene Elemente (Auswahl):
- Nachrichten-Startereignis / oberste Ebene
- Parallel Gateway, verzweigend

13.4.2 Verknüpfend

Im verknüpfenden Fall werden ankommende parallele Sequenzflusszweige "synchronisiert" (so die BPMN-Autoren). Konkret möchte man damit folgende Situation modellieren: Alle ankommenden Kanten müssen "ankommen", erst dann geht es im Prozess über das Gateway weiter und erst dann wird die nächste Aufgabe angestoßen.

Abstraktes Beispiel

Erst wenn die beiden Aufgaben A1 und A2 erledigt sind, wird Aufgabe A3 angestoßen.

Abbildung 13.4-6: Abstraktes Parallel Gateway - verknüpfend

A: Aktivität
Gateway:
- Parallel Gateway, verknüpfend
Token
Beim Gateway ankommende Token warten, bis "alle" da sind, erst dann geht es mit einem einzigen Token weiter.

Inhaltliches Beispiel

Das folgende Prozessfragment beschreibt (vereinfacht) die Schlussphase einer Bucherstellung. Erst wenn der Buchtext, der Index und das aktuelle Inhaltsverzeichnis erstellt sind, kann das Buch zum Druck gegeben werden.

Abbildung 13.4-7: Schlussphase Bucherstellung mit Parallel Gateway - verknüpfend

Element:
- Parallel Gateway, verknüpfend

Ähnlich das folgende Beispiel zur Produktionsplanung. Wenn die Kapazität eingeplant und die Rohstoffe sowie Teile bereitgestellt sind, wird die Produktionsplanung durchgeführt.

Abbildung 13.4-8: Produktionsplanung mit Parallel Gateway - verknüpfend

Zeitfenster
Mit dem Parallel Gateway lässt sich ein Muster in Geschäftsprozessen modellieren, das Zeitfenster genannt wird. Vgl. [Staud 2024, Abschnitt 12.6] für weitergehende Informationen.

13.5 Parallel Gateway - ereignisbasiert

Das parallele ereignisbasierte Gateway (Parallel Event-Based Gateway) dient zum Start von Prozessen durch verknüpfte Ereignisse. Erst wenn alle Ereignisse eingetreten sind, startet der Prozess. Dies entspricht einer Verknüpfung mit dem logischen UND.

Das zugehörige Gatewaysymbol verknüpft das übliche Quadrat mit dem Ereignissymbol Parallel Mehrfach für Startereignisse.

Abbildung 13.5-1: Das Parallel Event-Based Gateway für den Prozessstart

Gateway:
- Parallel Event Based Gateway

Dieses Gateway gibt es nur verzweigend. Sollen Sequenzflüsse, die durch solch ein Gateway entstanden sind wieder verschmolzen werden, kann dies mit dem einfachen Parallel Gateway geschehen.

Inhaltliche Beispiele

Das erste inhaltliche Beispiel schildert folgende Situation: für die Planung der Produktion ist die Zusage der Lieferanten, die Zusage der Finanzierung durch die Hausbank und die endgültige Auftragserteilung durch den Kunden nötig. Da alle drei "extern" sind, kann die Kommunikation nur über Nachrichtenverkehr erfolgen (vgl. Kapitel 7). Erst wenn alle drei positiven Nachrichten vorliegen, startet die Produktionsplanung. Die Lösung der BPMN für diese Situation ist das ereignisbasierte verknüpfende Parallel Gateway für den Prozessstart.

Da es hier um Nachrichten geht, die alle ankommen müssen, wäre die Modellierung mit den übrigen Gateways nur über Hilfskonstruktionen möglich.

Abbildung 13.5-2: Prozessstart mit ereignisbasiertem Parallel Gateway - am Beispiel Produktionsplanung

Enthaltene Elemente (Auswahl):
- Implizites Parallel Gateway, verknüpfend
- Nachrichten-Zwischenereignisse, empfangend
- Paralleles ereignisbasiertes Gateway

Konkret gilt folgende Festlegung: Das erste eintretende Ereignis erzeugt eine neue Instanz des Prozesses, der Prozess wartet aber darauf, dass die anderen Ereignisse eintreten [OMG 2011, S. 426].

Hier noch ein zweites inhaltliches Beispiel: Für eine wissenschaftliche Tagung müssen alle eingehenden Vorträge durch drei Reviewer geprüft werden. Erst wenn alle drei eingetroffen sind, wird die Bewertung des Vortrags vorgenommen.

Abbildung 13.5-3: Prozessstart mit ereignisbasiertem Parallel Gateway - am Beispiel Bewertung von Vorträgen

13.6 Inclusive Gateway

Es gibt in Geschäftsprozessen die Situation, dass eine oder mehrere Aufgaben erfüllt sein müssen, damit es im Fluss weitergeht. Dieses Gateway entspricht dem logischen ODER. Modelltechnisch bedeutet es, dass von den verknüpften Sequenzflusszweigen (Kanten) bei jeder Instanz des Geschäftsprozesses eine beliebige Teilmenge und mindestens eine Kante aktiv werden. Für die Beschreibung dieser Situation liegt in der BPMN das Inclusive Gateway vor.

Dieses Gateway hat die in der folgenden Abbildung angegebene grafische Form. Im Gateway wird ein Kreis oder ein "O" platziert. Es gibt noch eine weitere Darstellungsmöglichkeit, vgl. dazu das abstrakte Beispiel unten.

Abbildung 13.6-1: Darstellung eines Inclusive Gateway

Die BPMN-Autoren beschreiben die Struktur dieses Gateway ohne Rückgriff auf die Definition des ODER-Operators der formalen Sprachen wie folgt: Bei weggehenden Sequenzflusszweigen unterliegt jeder einzelne einer unabhängigen binären Ja/Nein-Entscheidung [OMG 2011, S. 292]. Da jeder Pfad unabhängig ist, sind damit alle Kombinationen von Pfaden möglich, auch keiner oder alle. Mit Hilfe einer voreingestellten weiterführenden Kante wird dann noch sichergestellt, dass mindestens eine Kante aktiv wird [ebenda], da sonst u.U im Sequenzfluss Blockaden entstehen könnten.

Verzweigend, Abstraktes Beispiel

Die folgenden abstrakten Beispiele zeigen die Umsetzung, die hier in zwei Varianten möglich ist.

Abbildung 13.6-2: Inclusive Gateway, verzweigend - abstraktes Beispiel

A: Aktivität
Enthaltene Elemente (Auswahl):
- Inclusive Gateway, verzweigend
- Voreinstellung bzgl. Sequenzfluss
Token
Alle Sequenzflüsse, die bei den unabhängigen binären Ja/Nein Entscheidungen mit Ja bewertet werden, erhalten einen Token.

Die folgende alternative Darstellung des Gateway ist auch zugelassen. Sie nutzt mehrere Sequenzflusszweige, die jeweils mit einer kleinen Raute am Anfang gekennzeichnet sind. Ein zusätzlicher Zweig gibt auch hier die Voreinstellung bzgl. des Sequenzflusses an und sichert ab, dass mindestens ein Zweig aktiv wird.

Abbildung 13.6-3: Inclusive Gateway - abstraktes Beispiel (verzweigend) mit einzelnen Sequenzflusszweigen

A: Aktivität
Enthaltene Elemente (Auswahl):
- Inclusive Gateway, verzweigend - alternative Darstellung
- Voreinstellung bzgl. Sequenzfluss

Exkurs: Prozessmodell und Instanzen - an obigem Beispiel erläutert.

Im Falle des Inclusive Gateways ist die Zahl möglicher unterschiedlicher Instanzen groß. Bei drei weiterführenden Zweigen gibt es sieben Möglichkeiten, da die leere Menge (keine weiterführende Kante) nicht zulässig ist. Hier zur Veranschaulichung alle möglichen Varianten. Die jeweils aktiven Sequenzflusszweige sind verdickt gezeichnet.

Abbildung 13.6-4: Prozessmodell und mögliche Prozessinstanzen - am Beispiel des Inclusive Gateway mit drei Sequenzflusszweigen

A: Aktivität

Inhaltliche Beispiele

Das erste inhaltliche Beispiel stellt Aspekte einer Wareneingangsprüfung dar. Die Semantik ist wie folgt: Jede der Tätigkeiten kann einzeln oder in beliebiger Kombination mit den anderen vorkommen. Außerdem ist es auch möglich, dass keine Aktion nötig ist.

Abbildung 13.6-5: Inclusive Gateway - am Beispiel einer Wareneingangsprüfung

Enthaltene Elemente (Auswahl):
- Inclusive Gateway, verzweigend
- Voreinstellung bzgl. Sequenzfluss

Es ist leicht zu erkennen, dass die Aufgaben nicht gänzlich unabhängig voneinander sind. Wenn z.B. keine Aktion notwendig ist, können die anderen Aufgaben nicht auftreten. Dieses bei der praktischen Modellierung des ODER-Operators oft auftretende Problem wird in der BPMN nicht thematisiert. Vgl. dazu [Staud 2014, Abschnitt 7.3].

Als eine Einschränkung geben die BPMN-Autoren an, dass das Quellobjekt (also das dem Operator vorangehende Element) kein Ereignis sein darf. Vgl. hierzu das Konzept der "verbotenen Anordnungen" in Ereignisgesteuerten Prozessketten, das dasselbe Architekturmerkmal verlangt [Staud 2014, Abschnitte 5.4.2 und 5.4.3].

Die folgende Abbildung zeigt die ebenfalls zulässige alternative Darstellung.

Abbildung 13.6-6: Darstellung einer Inclusive Decision mit Sequenzflusszweigen

Enthaltene Elemente (Auswahl):
- Inclusive Gateway, verzweigend - alternative Darstellung
- Voreinstellung bzgl. Sequenzfluss

Verknüpfend

Das Inclusive Gateway wird auch für das Zusammenführen ("merge") von Sequenzflusszweigen benutzt. Für die ankommenden Sequenzflusszweige gilt dieselbe Struktur wie oben, nur dass sie hier von flussaufwärts angesiedelten Elementen realisiert wurde. D.h., bezüglich dieser Sequenzflusszweige gilt, dass sie bei einer Instanz in beliebiger Kombination auftreten können und dass immer mindestens ein Zweig ankommt.

Die BPMN-Autoren sehen es so, dass dieses Gateway benutzt wird, um eine Kombination von alternativen und parallelen Pfaden zu verschmelzen [OMG 2011, S. 292].

Im folgenden Beispiel geht es um Neukunden eines Kreditinstituts. Der Ausschnitt zeigt (vereinfacht), welche der angebotenen Leistungen der Neukunde in Anspruch nehmen möchte, formuliert z.B. in einem Gespräch zwischen dem Kundenberater und dem Kunden.

Abbildung 13.6-7: Kundenkontakt Sparkasse mit Inclusive Gateway- verknüpfend

Die Abbildung zeigt mehrere parallele Aktivitäten, die im Rahmen der Neukundenanlage bei einem Kreditinstitut durchgeführt werden können. Nach der initialen Kundenanlage lassen sich verschiedene Services einrichten - etwa ein Girokonto, eine Debitkarte, ein Dispokredit, Online-Banking oder ein Depot. Sobald alle ausgewählten Aktivitäten abgeschlossen sind, wird die Kundenakte formal geschlossen.

Verzweigend und verknüpfend

Das folgende Beispiel zeigt beides, die Verzweigung und die Verknüpfung, am Beispiel folgender vereinfachter Regelung: Eine Ermäßigung für den Besuch einer Kindertagesstätte kann gewährt werden, wenn mindestes eine der folgenden Bedingungen erfüllt ist: Kind ist Geschwisterkind, Eltern sind arbeitslos, Eltern sind alleinerziehend. Ist keine dieser Bedingungen erfüllt, wird eine Absage formuliert.

Abbildung 13.6-8: Prüfung KiTa-Ermäßigung mit Inclusive Gateway

Enthaltene Elemente (Auswahl):
- Inclusive Gateway, verknüpfend
- Inclusive Gateway, verzweigend

Weiterführung des Sequenzflusses

Bei einem Inclusive Gateway können ja mehrere weiterführende Sequenzflusszweige gemeinsam auftreten. Das macht die Weiterführung nicht einfach, sie muss auf der Basis der konkreten Prozesssemantik gestaltet werden. Betrachten wir das folgende Beispiel. In dem Gesamtprozess, aus dem dieses Fragment stammt (vgl. für die EPK-Fassung [Staud 2014, Abschnitt 7.3]) ist die Semantik wie folgt:

Es handelt sich um ein Unternehmen mit Einzelfertigung.

Bei einer Kundenanfrage wird geprüft, ob dieselbe Anlage, eine ähnliche Anlage oder Komponenten der gewünschten Anlage schon mal geliefert wurden, denn dann sind üblicherweise Konstruktions- und Kalkulationsunterlagen vorhanden.

Es kann sich auch herausstellen, dass nichts Ähnliches geliefert wurde, also weder eine Komponente, eine ähnliche oder gleiche Anlage.

Im Weiteren sind die Geschäftsregeln in diesem Unternehmen wie folgt:

Wurde dieselbe Anlage schon mal geliefert, mit oder ohne Komponentenlieferung und Lieferung einer ähnlichen Anlage, wird auf dem Material der gleichen Anlage aufgebaut und das eventuelle vorhandene andere Material ignoriert.

Wurde schon mal eine Komponente und/oder eine ähnliche Anlage geliefert, wird das nutzbare Material zusammengestellt und damit weitergemacht.

Wurde nichts ähnliches geliefert, sind semantisch die anderen Fälle nicht möglich.

Das folgende Modellfragment drückt diese Semantik aus.

Abbildung 13.6-9: Anfrageprüfung mit Inclusive Gateway- verzweigend und verknüpfend

Enthaltene Elemente (Auswahl):
- Inclusive Gateway, verknüpfend
- Inclusive Gateway, verzweigend

Unschärfe

Dieses Gateway drückt eine Prozesssituation aus, die oft auf einem (juristischen oder verwaltungsmäßigen) Regelwerk beruht (vgl. obiges Beispiel in Abbildung 11.6-8), oft aber auch auf einer entsprechenden Realweltsituation, wie in den übrigen Beispielen oben. Bei letzterem sind die Tätigkeiten aber ofmals nicht unabhängig voneinander. Z.B. kann man einen Dispokredit nur beantragen, wenn auch ein Girokonto eingerichtet wurde. Oder es ist eine Tätigkeit dabei, die alle anderen ausschließt ("Weitergeben" in Abb. 11.6-6). Meist wird, insbesondere bei Istanalysen, auf die Modellierung dieser Zusammenhänge verzichtet. Vgl. zu der damit akzeptierten Unschärfe [Staud 2014, Abschnitt 7.3].

13.7 Complex Gateway

Dieses Gateway gehört nicht zu denen, die auf logische Operatoren zurückgehen. Mit ihm sollen Situationen beherrschbar werden, die mit den anderen Gateways nicht bewältigt werden können [OMG 2011, Abschnitt 10.5.5]. Wörtlich schreiben die BPMN-Autoren, dass dieses Gateway helfen soll

"... to model complex synchronisation behavior, in particular race situations" [OMG 2011, S. 295, 437].

Rennsituationen (race situations)
Angenommen, im Rahmen einer Ausschreibung werden 10 Lieferanten angeschrieben und um Angebote gegeben. Dann könnte die Geschäftsregel so sein, dass nach Eingang der ersten 5 Antworten der Auswahlprozess beginnt und der Lieferant ausgewählt wird. Da hier sozusagen die Lieferanten in einer Rennsituation sind, sprechen die BPMN-Autoren hier von einer "race situation".

Dieses Gateway wird durch einen Stern dargestellt, der in der Mitte des Gateway-Symbols eingefügt ist, wie es die folgende Abbildung zeigt.

Abbildung 13.7-1: Darstellung eines Complex Gateway

Bei diesem Gateway ist zum Verständnis die Betrachtung der inneren Struktur unabdingbar. Zuerst die Attribute:

Die "Gates", an denen die Sequenzflüsse (Token) ankommen, haben ein Attribut (Datentyp Integer) mit der Bezeichnung activationCount. Der Wert dieses Attributs gibt an, wieviele Token aktuell auf den ankommenden Sequenzflüssen sind, d.h. wieviele Sequenzflüsse am Gateway anstehen.

Das Gateway selbst hat ein Attribut mit der Bezeichnung activationExpression (boolesch), das sich auf die Daten an dieser Prozessstelle und auf das Attribut activationCount bezieht. Zum Beispiel könnte bei m ankommenden Sequenzflüssen (x1 ... xm) der Ausdruck xl+x2+...+xm >= 3 sein, wenn man möchte, dass 3 von m ankommende Token notwendig sind, um zu einem weiterführenden Token zu kommen [OMG 2011, S. 437].

Die Variable activationCount soll nur in Ausdrücken der Form expr >= const verwendet werden mit einem arithmetischen Ausdruck für expr, der nur die Addition verwendet und mit const als Ausdruck, der im Prozessverlauf konstant bleibt.

Dann die Zustände. Ein Complex Gateway hat einen internen Zustand:

waitingForStart oder

waitingForReset (bedeutet: waitingForStart=falsch)

Das Gateway ist immer in einem dieser Zustände, zu Beginn in waitingForStart. Das Attribut activationExpression wird geprüft, wenn das erste Token auf einem ankommenden Sequenzfluss auftaucht. Wenn die Prüfung "wahr" ergibt, wird ein Token von jedem ankommenden Sequenzfluss (der dann ja ein Token aufweist) konsumiert.

Für die Weiterführung des Prozesses über das Gateway werden die Bedingungen aller abgehenden Sequenzflüsse geprüft.

Jeder abgehende Sequenzfluss unterliegt einer booleschen Bedingung, nach der der Sequenzfluss aktiv wird (ein Token erhält) oder nicht. Diese Bedingung kann den Zustand des Gateway nutzen. Diejenigen abgehenden Sequenzflüsse, deren Bedingungen erfüllt sind, erhalten einen Token. Falls keines wahr wird, wird der voreingestgellte Sequenzfluss genutzt. Falls ein solcher nicht vorliegt, wird ein Ausnahmeereignis ausgelöst.

Damit ist die erste Phase abgeschlossen. Das Gateway wechselt dann seinen Status in waiting for reset. Jetzt wartet es auf Token von all denjenigen Sequenzflüssen, auf denen in der ersten Phase kein Token ankam, es sei denn, es wird keines erwartet.

Kommt es zum Neustart (reset), verbraucht das Gateway von jedem ankommenden Sequenzfluss einen Token, wenn dieser einen Token hat (er also nicht in der ersten Phase konsumiert wurde). Es prüft dann alle Bedingungen auf den wegführenden Sequenzflüssen, um zu bestimmen, welches ein Token erhält. Nur genau die, deren Prüfung wahr ergibt, erhalten eines. Falls keine Prüfung wahr ergibt, erhält der voreingestellte Sequenzfluss einen Token. Danach wechselt das Gateway seinen Zustand wieder in waitingForStart.

Neustart

Mit obiger Beschreibung ist die Vorbereitung der Programmierung, bzw. die Umsetzung durch eine Business Process Engineschon ein Stück weit geklärt. Das Konzept zielt also auf die automatisierte Durchführung von Prozessen, nicht auf Istanalysen.

13.7.1 Verzweigend

Abstraktes Beispiel

Das folgende Beispiel dient auch zur Illustration der obigen Ausführungen. Am Gateway liegen m Sequenzflüsse an, die wie beschrieben ausgewertet werden und es gehen n Sequenzflüsse sowie ein voreingestellter Sequenzfluss ab. Welche abgehen, hängt von den Auswertungen beim Gateway ab.

Abbildung 13.7-2: Verschmelzen und Verzweigen von Sequenzflüssen mit einem Complex Gateway
Quelle: [OMG 2011, Figure 13.7, S. 437]
Übersetzung durch den Verfasser.

Enthaltene Elemente (Auswahl):
- Complex Gateway
- Verschmelzen und Verzweigen von Sequenzflüssen mit einem Complex Gateway

Inhaltliches Beispiel

Es gibt tatsächlich Situationen in Geschäftsprozessen, die sich mit den Standardoperatoren bzw. -gateways nicht oder nur sehr schwer und unter Inkaufnahme syntaktisch komplexer Konstruktionen abbilden lassen. Dafür wird in der BPMN das Complex Gateway genommen. Im folgenden Beispiel geht es um eine, z.B. regelmäßig automatisiert stattfindende, Prüfung des Lagerbestandes. Abhängig vom Ergebnis der Prüfung (hier vereinfacht) erfolgen die weiteren Tätigkeiten.

Abbildung 13.7-3: Lagerbestandsprüfung mit einem Complex Gateway

Gateway:
- Complex Gateway, verzweigend

13.7.2 Verknüpfend

Abstraktes Beispiel

Hier die abstrakte Darstellung einer solchen Prozesssituation: A1, A2 und A3 werden auf eine bestimmte Weise realisiert, dann geht es weiter zu A4.

Abbildung 13.7-4: Verknüpfendes Complex Gateway - abstrakt

Gateway:
- Complex Gateway, verknüpfend

Inhaltliches Beispiel

Das folgende Modellfragment beschreibt die Situation, dass zahlreiche Angebote von potentiellen Lieferanten angefordert werden. Die Geschäftsregel sei dann die, dass die Auswertung der Angebote beginnt, wenn drei eingetroffen sind.

Abbildung 13.7-5: Angebotsprüfung und Vergabe mit einem verknüpfenden Complex Gateway (Rennsituation)

Enthaltene Elemente (Auswahl):
- Complex Gateway, verknüpfend
- Parallel Gateway, verzweigend
- Rennsituation
- Attribute des Complex Gateway

Damit sind die Gateways der BPMN vorgestellt. Die folgende Abbildung gibt einen Überblick.

Gateways der BPMN

BPMN-Bezeichnung

Logischer Operator

Gatewaysymbol

Exclusive Gateway, datenbasiert (verzweigend und verknüpfend).
Erlaubt die Erfassung von Entscheidungssituationen "aus dem Prozess heraus". Ein Sequenzfluss wird aktiv / muss ankommen.

XODER

Exclusive Gateway,
ereignisbasiert (verzweigend)
Erlaubt die Erfassung von Entscheidungssituationen durch Ereignisse (Nachrichteneingang). Ein Sequenzfluss wird aktiv / muss ankommen.

XODER

Parallel Gateway
(verzweigend und verknüpfend)
Parallel bedeutet, dass die Aufgaben unabhängig voneinander gestartet und abgearbeitet werden. Alle müssen aber gestartet werden bzw. ankommen, damit "es weiter geht".

UND

Parallel Event-Based Gateway (verzweigend)
Dient zum Start von Prozessen durch Ereignisse, die mit dem logischen UND verknüpft sind. Alle müssen gestartet werden, damit es "los geht".

UND

Inclusive Gateway
(verzweigend und verknüpfend)
Dient zur Verzweigung und Verknüpfung gemäß dem logischen ODER ("beliebige Teilmenge")

ODER

Complex Gateway
(verzweigend und verknüpfend)
Geht nicht auf logische Operatoren zurück. Mit ihm sollen Situationen beherrschbar werden, die mit den anderen Gateways nicht bewältigt werden können ("... to model complex synchronisation behavior" [OMG 2011, S. 295]).

---

13.8 Kontrollfluss durch Kompensation

Das Theorieelement der Kompensation (vgl. auch Abschnitt 9.2.8) ist kein Gateway, zumindest nicht auf den ersten Blick. Die aus der Kompensation resultierenden Aktvitiäten (Compensation Handler, siehe unten) sind auch nicht Teil des normalen Flusses (vgl. unten) und dürfen daher nicht instantiiert werden, wenn der Prozess instantiiert wird. Aber da eine Kompensation eine Verzweigung darstellt zu einem Ablauf, der auch Tätigkeiten auslöst, wurde sie in dieses Kapitel genommen.

Kompensation beschreibt die Rücknahme von Arbeitsschritten, die bereits erfolgreich getätigt wurden, weil ihre Ergebnisse und eventuellen Seiteneffekte nicht mehr gewünscht sind. Dies ist erst möglich, wenn die Aktvitiät abgeschlossen ist. Ist eine Aktivität noch aktiv, kann sie nicht kompensiert sondern nur abgebrochen werden.

Wie oben gesehen, gibt es vier Varianten von Kompensationsereignissen: ein Startereignis, ein abgebendes und empfangendes Zwischenereignis und ein Endereignis.

Abbildung 13.8-1: Ereignisse für die Verzweigung zu Kompensationsaktvitäten

Vgl. Abbildung 13.8-3 sowie [Staud 2024, Abbildung 14.3-1] für zahlreiche Beispiele zu diesem Ereignistyp.

Das erste Element (von links) wird benutzt, wenn Subprozesse gestartet werden sollen. Es wird nur für eingebettete Kompensationssubprozesse genutzt und wird aktiv, wenn eine Kompensation ansteht.

Das zweite Element (Zwischenereignis / Grenzlinie unterbrechend) wird auf den Rand einer Aktivität gesetzt, die mitten im Prozess angesiedelt ist und Nachrichten zum Start der Kompensationsdurchführung empfangen kann. Es empfängt also das Kompensations-Ereignis, das in der Aktivität entsteht. Empfangende Kompensations-Zwischenereignisse dürfen grundsätzlich nur auf der Grenzlinie von Aktivitäten platziert sein und nicht im normalen Fluss.

Das dritte Element im normalen Fluss zeigt an, dass Kompensation notwendig ist. Es gibt also ein Kompensations-Ereignis ab. Der Ablauf ist dann wie folgt: Wenn eine Aktivität identifiziert und erfolgreich abgeschlossen ist, wird sie zurückgenommen. Natürlich muss die Aktvivität für das Kompensations-Zwischenereignis "sichtbar" sein (vgl. unten), d.h., sie muss das Ereignis wahrnehmen können.

Das vierte Element ist ein Schlussereignis. Es signalisiert, dass Kompensation bzgl. einer Aktivität nötig ist. Es kann in jedem Subprozess oder Prozess benutzt werden. Entweder im normalen Fluss auf derselben Ebene wie der Subprozess oder in einem Kompensations-Subprozess, der im Subprozess enthalten ist, der eine Aktivität enthält. Kann keine zugehörige Aktivität identifiziert werden, werden alle erfolgreich abgeschlossenen Aktivitäten in umgekehrter Reihenfolge kompensiert, die für das Kompensationsendereignis sichtbar sind.

Sichtbarkeit

Eine Aktivität ist für ein Kompensations(zwischen-/end-)ereignis sichtbar, wenn es im normalen Fluss auf derselben Subprozessebene enthalten ist oder wenn es sich in einem zugehörigen Ereignissubprozess befindet. [OMG 2011, S. 248]

Was gehört insgesamt zu einer Kompensation?

Eine Kompensation benötigt folgende Elemente:

Eine Aktivität (oder mehrere), die u.U. zurückgenommen werden muss.

Einen compensation handler, der gebenenfalls die notwendigen Schritte durchführt.

Eine Verbindung zwischen Aktivität und Kompensationsaktivitäten.

Der sog. Compensation Handler stellt eine Menge von Aktivitäten dar, die nicht mit anderen Teilen des BPMN-Modells verknüpft sind. Er startet durch ein empfangendes Kompensations-Ereignis. Dieses ist entweder grafisch auf der Grenzlinie der Aktivität angesiedelt ("boundary event") oder - im Falle eines Kompensationssubprozesses - das Startereignis des Compensation Handlers.

Eine Kompensation wird also durch ein abgegebenes Kompensations-Ereignis ausgelöst. Eine zweite Möglichkeit ist, dass sie rekusiv durch einen anderen Compensation Handler ausgelöst wird.

Grafische Realisierung der Verbindung zwischen Aktivität und Kompensationsaktivitäten

Falls die Verbindung durch ein Ereignis auf der Grenzlinie ("boundary event") erfolgt, wird sie wie in der folgenden Abbildung realisiert. Dazu gehört eine Kompensationsaktivität, die mittels einer Assoziation mit dem "Grenzlinienereignis" verbunden ist.

Abbildung 13.8-2: Kompensation mit Ereignisauslöser auf Grenzlinie

Enthaltene Elemente (Auswahl):
- Kompensations-Zwischenereignis / Grenzlinie, unterbrechend
- Kompensations-Aufgabe

Die Verbindung kann auch über einen Kompensations-Ereignissubprozess hergestellt werden. Dieser muss in einem Prozess oder Subprozess enthalten sein. Er ist wie die "Grenzlinienereignisse" auch außerhalb des normalen Flusses, kann aber auf die Daten des Elternprozesses zugreifen.

Die folgende Abbildung zeigt die grafische Umsetzung. Der Kompensationssubprozess wird durch eine gepunktete Linie hervorgehoben. Der übergeordnete Subprozess Buchungen umfasst die verschiedenen Buchungsvorgänge mit den Kompensations-Zwischenereignissen auf den Grenzlinien der eigentlichen Aktvitäten. Im Subprozess enthalten ist ein Kompensations-Subprozess.

Abbildung 13.8-3: Flug- und Hotelbuchung mit Kompensations-Subprozess.
Quelle: [OMG 2011, S. 303, Figure 10.122], Übersetzung durch den Verfasser.

Enthaltene Elemente (Auswahl):
- Kompensations-Aufgabe
- Kompensations-Startereignis / Ereignissubprozess, unterbrechend
- Kompensations-Ereignissubprozess(entfaltet))
- Kompensations-Zwischenereignis / abgebend
- Kompensations-Zwischenereignis / Grenzlinie, unterbrechend

Varianten dieses Geschäftsprozesses finden sich in [Staud 2024]:
Abbildung 10.8-1 (Variante 1), Abbildung 10.9-3 (Variante 2), Abbildung 11.8-3 (Variante 3), Abbildung 14.3-1 (Variante 4) und Abbildung 14.4-1 (Variante 5)

Ein Compensation Handler ist entweder nutzerdefiniert oder implizit. Der implizite Compensation Handler eines Subrozesses ruft alle Compensation Handler seiner eingeschlossenen Aktivitäten in der umgekehrten Abfolge (nach Sequenzfluss) auf [OMG 2011, S. 235].

Abschließend eine Anmerkung zur Unterscheidung von normalen und nicht-normalen Sequenzflüssen.

Normaler Fluss, nicht normaler Fluss

Die BPMN-Autoren unterscheiden den normalen und den nicht-normalen Fluss. Der normale Fluss ist der durch die Sequenzflüsse gestaltete. Alle anderen sind - sozusagen - die nicht-normalen. Dazu gehören die Flüsse rund um Kompensationen (vom "Grenzereignis" zur Kompensationsaktivität) oder der zum Kompensations-Subprozess. Entsprechend gibt es Modellelemente, die im nicht-normalen Fluss erlaubt sind, nicht aber im normalen Fluss. Zum Beispiele die Flüsse rund um Kompensationen. Ein weiterer Grund für diese Unterscheidung ist, dass nicht-normale Flüsse nicht aktiviert werden, wenn der Geschäftsprozess instantiiert wird.

14 Literatur

Eine umfassende Liste zu Veröffentlichungen zur Prozessmodellierung findet sich hier:

https://www.staud.info/litohneFr/li_t_1.php

Becker, Kugeler und Rosemann 2012 (Hrsg.)
Becker, Jörg; Kugeler, Martin; Rosemann, Michael (Hrsg.): Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung (7. Aufl.), Berlin u.a. 2012

Bullinger und Fähnrich 1997
Bullinger, Hans-Jörg; Fähnrich, Klaus-Peter: Betriebliche Informationssysteme. Grundlagen und Werkzeuge der methodischen Softwareentwicklung. Berlin u.a. 1997

Keller, Nüttgens und Scheer 1992
Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozessmodellierung auf der Grundlage Ereignisgesteuerter Prozessketten, Veröffentlichungen des Instituts für Wirtschaftsinformatik (Iwi), Universität des Saarlandes, Heft 89, Januar 1992

Mertens 2013
Mertens, Peter: Integrierte Informationsverarbeitung 1. Operative Systeme in der Industrie (18. Auflage), Wiesbaden 2013 (Springer Gabler)

Österle 1995
Österle, Hubert: Business Engineering. Prozess- und Systementwicklung. Band 1: Entwurfstechniken, Berlin u.a. 1995

OMG 2003 Object Management Group: UML 2.0 Superstructure Specification (Unified Modeling Language: Superstructure, version 2.0, final Adopted Specification, ptc/03-08-02), August 2003

OMG 2009 Object Management Group (OMG): Business Process Modeling Notation (BPMN). Version 1.2 January 2009 (OMG Document Number: formal/2009-01-03. Standard document URL: http://www.omg.org/spec/BPMN/1.2)

OMG 2011 Object Management Group (OMG): Business Process Modeling Notation (BPMN). Version 2.0 January 2011 (OMG Document Number: formal/2011-01-03. Standard document URL: http://www.omg.org/spec/BPMN/2.0)

OMG 2013 Object Management Group (OMG): Business Process Model and Notation (BPMN). Version 2.0.2 January 2011 (OMG Document Number: formal/2011-01-03. Standard document URL: https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/)

Scheer 1996
Scheer, August-Wilhelm: Business Process Engineering. Reference Models for Industrial Entreprises. (2. Auflage), Berlin u.a.1996

Scheer 1997
Scheer, August-Wilhelm: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse (7. Auflage), Berlin u.a. 1997

Scheer 1998
Scheer, August-Wilhelm: Wirtschaftsinformatik. Studienausgabe. Referenzmodelle für industrielle Geschäftsprozesse (2. Aufl.), Berlin u.a. 1998

Scheer 1998a
Scheer, August-Wilhelm: ARIS - vom Geschäftsprozess zum Anwendungssystem (3. Auflage), Berlin u.a.1998

Scheer 1998b
Scheer, August-Wilhelm: ARIS - Modellierungsmethoden, Metamodelle, Anwendungen (3. Auflage), Berlin u.a.1998

Scheer 1998c
Scheer, August-Wilhelm: Wirtschaftsinformatik. Studienausgabe. Referenzmodelle für industrielle Geschäftsprozesse (2. Auflage), Berlin u.a. 1998 (Springer)

Scheer 1999
Scheer, August-Wilhelm: ARIS, Business Process Frameworks. (3. Auflage), Berlin u.a.1999

Scheer 2000
Scheer, August-Wilhelm: ARIS, Business Process Modeling. (3. Aufl.), Berlin u.a. 2000

Scheer 2020
Scheer, August-Wilhelm: Unternehmung 4.0. Vom disruptiven Geschäftsmodell zur Automatisierung der Geschäftsprozesse, 3. Auflage, Wiesbaden 2020

Schmelzer und Sesselmann 2013
Schmelzer, Hermann J.; Sesselmann, Wolfgang: Geschäftsprozessmanagement in der Praxis. Kunden zufriedenstellen, Produktivität steigern, Wert erhöhen (8. Auflage). München 2013.

Staud 2006 Staud, Josef Ludwig: Geschäftsprozessanalyse. Ereignisgesteuerte Prozessketten und objektorientierte Geschäftsprozessmodellierung für Betriebswirtschaftliche Standardsoftware (3. Auflage). Berlin u.a. 2006

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

Staud 2019 Staud, Josef Ludwig: Unternehmensmodellierung - Objektorientierte Theorie und Praxis mit UML 2.5. (2. Auflage). Berlin u.a. 2019 (Springer Gabler)

Staud 2024 Staud, Josef Ludwig: Geschäftsprozesse und ihre Modellierung mit der Methode Business Procass Model and Notation (BPMN 2.0). (2. Auflage). Hamburg 2024 (tredition)

Staud 2025
Staud, Josef Ludwig: Ereignisgesteuerte Prozessketten. Das Werkzeug für die Modellierung von Geschäftsprozessen (2. Auflage). Hamburg 2025 (tredition)