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

© Prof. Dr. Josef L. Staud

Zum Text

Dieser Text ist die Vorab- und Webversion der 2. Auflage meines Buches:

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

Das Buch wird 2024 erscheinen.

Aufbereitung für's Web

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

Urheberrecht

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

Warenzeichen und Markenschutz

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

 

 

Prof. Dr. Josef Ludwig Staud

 

Vorwort, Inhalt, Abkürzungen

Vorwort

Das Thema Prozessoptimierung ist von zentraler Bedeutung für die Organisationswirklichkeit. Es ist wie so vieles eine ständige Aufgabe. Prozessoptimierung aber bedarf der Erfassung der Prozesse, ihrer Beschreibung durch Prozessmodelle. Erst nach dieser Erfassung können viele Schwachstellen erkannt und beseitigt werden.

Unter den Vorschlägen zur Prozessmodellierung hat die Methode Business Process Model and Notation (BPMN) seit ihrer Veröffentlichung 2011 eine herausragende Position erreicht. Sie ist, neben den Ereignisgesteuerten Prozessketten (EPK) die Methode der Wahl.

Dieser Text widmet sich der BPMN und stellt sie, basierend auf der Auswertung der Originalquellen, umfassend dar.

Josef L. Staud

 

Abkürzungsverzeichnis


Abkürzung

Langbezeichnung

AD

Aktivitätsdiagramm der UML

ARIS

Architektur integrierter Informationssysteme

 

 

B2B

Business to Business, Geschäftstätigkeit von Unternehmen miteinander im Internet.

B2C

Business to Customer, Geschäftstätigkeit im Internet, der direkt mit dem Endkunden zu tun hat.

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

EPK

Ereignisgesteuerte Prozesskette

GP

Geschäftsprozess

IT

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

ODER

Logischer Operator ODER

SPM

Standardprozessmodellierung

UND

Logischer Operator UND

vs.

versus (im Vergleich zu, im Gegensatz zu)

WSK

Wertschöpfungsketten

XODER

Logischer Operator Exklusives ODER


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

 

1 Einleitung

1.1 Organisation vs. Unternehmen

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

Überall Geschäftsprozesse

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

1.2 Aufbau der Arbeit

Der Aufbau des Textes wie folgt:

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

1.3 Methode BPMN

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

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

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

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

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

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

Vorgesehene Abdeckung

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

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

1.4 Ziel

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

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

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

 

2 Geschäftsprozesse

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

2.1 Definition(en)

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

Aufgaben

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

Definition Aufgabe

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

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

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

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

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

Funktionen

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

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

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

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

Vorgänge

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

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

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

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

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

Definition Vorgang

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

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

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

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

Definition Geschäftsprozesse

Daruf aufbauend können Geschäftsprozesse in Organisationen wie folgt definiert werden:

Definition Geschäftsprozess

Ein Geschäftsprozess besteht aus einer zusammenhängenden, abgeschlossenen Folge von Tätigkeiten, die zur Erfüllung eines Organisationsziels notwendig sind. Die Tätigkeiten werden von Aufgabenträgern in organisatorischen Einheiten oder von Programmen wahrgenommen. 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 bzw. Sequenzfluss (BPMN) genannt.
  • Einbettung des Geschäftsprozesses in die gesamte Geschäftstätigkeit des Unternehmens durch Angabe seines Zieles.
  • Aufgabenträger, d.h. die Antwort auf die Frage, "Wer erbringt die Leistung?"
  • Hinweis auf die Automatisierung von Geschäftsprozessen (Programme als Aufgabenträger).
  • Produktionsfaktoren und ihr Verbrauch im Rahmen der Prozessdurchführung.
  • Unterstützung der Prozessrealisierung durch die IT.

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

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

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

und gibt damit wiederum einen deutlichen Hinweis auf den Kontrollfluss.

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

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

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

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

Modell vs. Instanz

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

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

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

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

2.2 Konzept Geschäftsprozess

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

Beispiele

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

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

und, ein meist sehr langer Geschäftsprozess,

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

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

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

2.3 Eigenschaften und Komponenten

2.3.1 Eigenschaften

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

Detaillierungsgrad der Prozessmodellierung.

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

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

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

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

IT-Abdeckung

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

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

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

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

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

Automatisierungsgrad

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

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

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

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

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

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

Prozessintegration

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

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

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

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

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

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

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

Datenintegration

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

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

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

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

2.3.2 Komponenten

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

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

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

  • Ereignisse
  • Funktionen
  • Organisationseinheiten
  • Datenobjekte

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

 

3 Wo steht die Prozessmodellierung heute?

3.1 Basiselemente einer Methode zur Prozessmodellierung

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

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

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

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

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

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

(1) Elementare Tätigkeiten

(2) Zentraler Gegenstand des Geschäftsprozesses

(3) Träger der Tätigkeiten

(4) Informationen auf Trägern aller Art

(5) Informationsverarbeitung

(6) Nachrichten

(7) Ereignisse

(8) Kontrollfluss

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

(10) Ebenen - Kapselung

(11) Zeitliche Dimension

(12) Subprozesse

(1) Elementare Tätigkeiten

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

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

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

(2) Zentraler Gegenstand des Geschäftsprozesses

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

(3) Träger der Tätigkeiten

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

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

(4) Informationen auf Trägern aller Art

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

(5) Informationsverarbeitung

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

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

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

(6) Nachrichten

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

(7) Ereignisse

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

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

(8) Kontrollfluss

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

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

Ein Kontrollfluss hat Verzweigungen. Im einfachsten Fall sind dies:

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

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

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

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

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

(9) Andere Flüsse, Transporte

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

(10) Ebenen - Kapselung

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

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

(11) Zeitliche Dimension

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

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

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

(12) Subprozesse

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

Und danach ….

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

3.2 Ziele

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

Definition Istanalyse

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

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

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

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

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

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

Kundenorientierung als Ziel der Prozessmodellierung

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

3.3 Kontrollfluss

Ein Kontrollfluss kann durchaus verschiedene Realisierungen haben. Für eine Standardprozessmodellierung genügen folgende Festlegungen:

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

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

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

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

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

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

.

 

4 Geschäftsprozesse in der BPMN

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

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

4.1 Definition

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

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

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

4.2 Prozesstypen in der BPMN

Interne Geschäftsprozesse (Private Business Process)

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

Ein ausführbarer Prozess (Private Executable (internal) Business Process) ist einer, der darauf vorbereitet ist, in WS-BPEL abgebildet zu werden. Durch diese Tauglichkeit für die Business Process Execution 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 Istanalyse oder Überblicksgewinnung (auf einem hohen Aggregationsniveau).

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

Öffentliche Geschäftsprozesse (Public Processes)

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

Globale Prozesse (Global Processes)

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

4.3 Diagrammtypen

Folgende Diagrammtypen sollen mit der BPMN modellierbar sein:

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

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

4.4 Vertikale Dimension der Prozessmodellierung

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

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

eingeführt.

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

4.5 Gruppierung der Elemente

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

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

Die Flussobjekte werden noch unterteilt in:

  • Ereignisse
  • Aktivitäten
  • Gateways

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

  • Sequenzfluss
  • Nachrichtenfluss
  • Assoziationen

Schwimmbahnen dienen der Gruppierung der Basismodellelemente. Hier wird unterschieden in

  • Becken
  • Bahnen

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

  • Datenobjekte
  • Gruppen
  • Anmerkungen

4.6 Token

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

Knoten und Kanten

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

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

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

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

Token und Instanzen

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

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

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

Weitere Festlegungen zum Tokenfluss sind bei den Methodenkomponenten zu finden.

 

5 Einführende Beispiele

5.1 Das erste Business Process Diagram

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

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

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

Abbildung 5.1-2: Auftragsabwicklung - Variante 1

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

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

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

Die Operatoren werden von den BPMN-Autoren 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. Abschnitt 11.2 für eine Beschreibung). Die BPMN-Autoren nennen ihn Exclusive Gateway. Kurz kann er so beschrieben werden:

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

Der Schrägstrich bei "Akzeptiert" bedeutet in dieser Modellierungsmethode, dass der durch ihn markierte Pfad die 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 Kapitel 11.

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

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

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

Enthaltene Elemente:

- Startereignis

- Exclusive Gateway mit Voreinstellung

- Aufgabe

- Parallel Gateway, verzweigend

- Parallel Gateway, verknüpfend

- Exclusive Gateway, verknüpfend

- Schlussereignis

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

5.2 Jetzt mit Daten

Datenobjekte (data objects) sind alle Geschä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 5.2-1: Auftragsabwicklung - Variante 3.
Quelle: In Anlehnung an [OMG 2009a, S. 104, Figure 10.12], [OMG 2011, S. 269, Figure 10.85]. Übersetzung durch den Verfasser

Enthaltene Elemente - zusätzlich zur vorigen Abbildung:

- Datenobjekt

Mehr zu Datenobjekten findet sich in Kapitel 8.

5.3 Handelnde - Träger der Aktivitäten

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

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

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

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

Enthaltene Elemente - zusätzlich zur vorigen Abbildung:

- Becken

- Bahn

- Nachrichtenfluss

5.4 Ein öffentlicher Geschäftsprozess

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

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

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

Enthaltene Elemente:

- Becken

- Becken mit öffentlichem Prozess

- Startereignis

- Aufgaben

- Nachrichtenflüsse

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

5.5 Zusammenarbeit

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

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

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

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

Enthaltene Elemente:

- Startereignis

- Aufgabe

- Schlussereignis

- Nachrichtenfluss

- öffentlicher Geschäftsprozess

- Nachrichten zwischen Prozessen

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

6 Tätigkeiten

6.1 Aktivitäten

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

Abbildung 6.1-1: Grafische Darstellung von Aktivitäten

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

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

Aktivitäten sind also die ausführbaren 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. Kapitel 11).

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

6.2 Aufgaben

Auf der untersten Ebene sind die Aufgaben angesiedelt, die als "atomar" (atomic) bezeichnet werden. Es sind also elementare Tätigkeiten, die im jeweiligen Kontext nicht weiter unterteilt werden. Die Wortwahl macht die Subjektivität deutlich, die 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. 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.

6.2.1 Varianten

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

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

Die folgende Abbildung zeigt die grafische Darstellung der Markierungselemente.

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

Mehrfachinstanzen

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

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

Abbildung 6.2-2: Grafische Darstellung von Aufgaben - Mehrfachinstanzmarkierungen

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

Kompensationen

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

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

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

Ein Beispiel ist die Durchführung einer 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.

6.2.2 Aufgabentypen

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

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

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

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

Handarbeit (manual task object)

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

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

Abbildung 6.2-3: Grafische Darstellung von Aufgaben - Handarbeit

Nutzer-Aufgabe (user task object)

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

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

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

Dienst (service task object)

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

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

Sender

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

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

Nach dem Versenden der Nachricht ist die Aufgabe abgearbeitet.

Empfänger-Aufgabe

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

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

Nach dem Empfangen der Nachricht ist die Aufgabe abgearbeitet.

Prozessstart-Aufgabe

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

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

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

Geschäftsregel-Aufgabe

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

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

Skript-Aufgabe

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

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

Abbildung 6.2-10: Grafische Darstellung von Aufgaben - Skript

Globale Aufgabe

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

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

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

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

6.2.3 Zusammenfassung

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

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

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

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

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

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

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

Abbildung 6.2-12: Aufgaben der Methode BPMN mit grafischer Darstellung und Kurzbeschreibung

6.3 Subprozesse

6.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 6.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 6.3-2: Darstellung eines entfalteten Subprozesses

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

Motivation

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

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

Ein eher 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.

6.3.2 Varianten

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

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

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

Schleifen

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

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

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

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

Mehrfachinstanzen

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

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

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

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 6.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 Abä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 6.3-6: Darstellung eines verborgenen Ad hoc - Subprozesses

Ad hoc - Entfaltet

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

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

Enthaltene Elemente:

- Entfalteter Subprozess mit Mehrfachinstanz (parallel).

- Aufgabe, ohne Markierung

- Aufgabe mit Mehrfachinstanz, parallel

- Aufgabe mit Schleife

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

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

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

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

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

Mehrere Kennzeichnungen

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

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

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

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

6.3.3 Typen

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

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

Eingebettet und referenziert

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

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

Call Activity

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

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

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

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

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

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

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

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

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

Ereignissubprozesse

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

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

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

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

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

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

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

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

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

Beispiele:

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

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

Transaktionen

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

Abbildung 6.3-15: Grafische Darstellung einer Transaktion

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

6.3.4 Zusammenfassung - Arten von Subprozessen

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

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

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

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

Die folgenden Tabellen stellen die wichtigsten Subprozesse mit ihrer grafischen Repräsentation, Beispielen und einer Kurzbeschreibung zusammen.

Grundsymbole


 

 

bpmn058 collapsed subprocess Subprozess.bmp

Verborgener Subprozess (collapsed sub process), z.B. Bestellung verschicken.

bpmn057a expanded subprocess Subprozess.bmp

Entfalteter Subprozess (expanded sub process), z.B. Bestellung verschicken.


 

Innere Struktur


 

 

bpmn055 Subprozess mit compensation.bmp

Kompensations-Subprozess

Subprozess, der als Ersatz für andere dienen kann ("zur Kompensation"). Z.B. Daten zurücksetzen nach einer abgebrochenen Bestellung.

bpmn219 Mehrachinstanz parallel Bestellung abschicken.bmp

Mehrfachinstanz-Subprozess, parallel

Subprozess, der parallel mehrfach aktiv werden kann. Z.B. Artikel versenden mit mehreren Akteuren.

bpmn200 subprozess multi-instance verpacken.bmp

Mehrfachinstanz-Subprozess, sequentiell

Subprozess, der sequentiell mehrfach aktiv werden kann. Z.B. Artikel versenden mit einem Akteur.

bpmn100 Subprozess mit Schleife.bmp

Subprozess mit Schleifencharakter

Beschreibt sich wiederholende Tätigkeiten. Z.B. „Mail-Stapel“ abarbeiten.

bpmn054 Subprozess Ad-hoc collapsed.bmp

Ad Hoc – Subprozess

Beschreibt Aktivitäten, die nicht in einen Sequenzfluss gebracht werden können (oder sollen). Z.B. die verschiedenen Aufgaben, die bei einer Fachbucherstellung zu leisten sind.

bpmn204 Subprozess mehrere Kennzeichen.bmp

Ad Hoc – Subprozess mit Schleifencharakter

Beschreibt Aktivitäten, die nicht in einen Sequenzfluss gebracht werden können (oder sollen) und die Schleifencharakter haben. Z.B. das wiederholte Angehen von Aufgaben, die bei einer Fachbucherstellung zu leisten sind.


 

Innere Struktur – Fortsetzung


 

 

bpmn135 Event Subprozess expanded.bmp

Ereignissubprozess, entfaltet (event sub-process, expanded). Z.B. Anfragebearbeitung.

bpmn224 Transaktion.bmp

Transaktion. Z.B. Geldüberweisung.


 

Typen


 

 

bpmn125 Call Activitiy object calling a Process (Collapsed).bmp

Call Activity, die einen verborgenen Prozess aufruft. Z.B. Rechnung bezahlen.

bpmn126 Call Activitiy object calling a Process (Expanded).bmp

Call Activity, die einen entfalteten Prozess aufruft. Z.B. Rechnung bezahlen.

bpmn134 Event Subprozess collapsed.bmp

Ereignissubprozess, verborgen (event sub-process, collapsed). Z.B. Anfragebearbeitung.

bpmn135 Event Subprozess expanded.bmp

Ereignissubprozess, entfaltet (event sub-process, expanded). Z.B. Anfragebearbeitung.

bpmn224 Transaktion.bmp

Transaktion. Z.B. Geldüberweisung.


 

6.3.5 Wofür Subprozesse?

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

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

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

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

 

7 Akteure und Nachrichten

Wer tut es?

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

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

7.1 Becken, Bahnen, Nachrichten

Becken

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

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

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

Abbildung 7.1-1: Grafische Darstellung eines Beckens

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

Bahnen

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

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

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

Nachrichten

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

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

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

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

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

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

Beispiel Geschäftsprozess Bonitätsprüfung

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

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

Enthaltene Elemente:

- Aufgaben

- Bahnen

- Becken

- Empfänger-Aufgabe

- Exclusive Gateway, datenbasiert

- Nachrichtenfluss

- Schlussereignis

- Sender-Aufgabe

- Startereignis

- Subprozess, verborgen

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

Abbildung 7.1-5: Nachrichtenverkehr vom und zum Beckenrand

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

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

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

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

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

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

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

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

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

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

Die Nachrichtenflüsse modellieren hier also:

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

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

Enthaltene Elemente:

- Bahnen

- Becken

- Nachrichtenflüsse

- Nachrichtenverkehr zum Beckenrand

- Nachrichten-Zwischenereignis / empfangend

- Parallel Gateway, verzweigend

- Schlussereignis

- Startereignis

7.2 Zusammenarbeit

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

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

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

Entaltene Elemente (u.a.):

- Gruppe (group)

- Nachrichten zwischen Aufgaben

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

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

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

Entaltene Elemente (u.a.):

- Empfänger-Aufgaben

- Gruppe (group)

- Sender-Aufgaben

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

Vor- und Nachteile

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

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

8 Informationen und ihre Verarbeitung

8.1 Daten und Informationen

In jedem Geschäftsprozess werden Informationen 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 Daten­objekte (data objects)). Sie sehen sie wie folgt:

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

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

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

Abbildung 8.1-1: Darstellung des Modellelements Datenobjekt

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

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

Datenspeicher

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

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

8.2 Assoziationen

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

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

Definition Assoziation

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

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

Abbildung 8.2-1: Darstellung einer gerichteten Assoziation

Assoziationen für Artefakte

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

Abbildung 8.2-2: Artefakt Textliche Anmerkung

8.3 Daten im Geschäftsprozess

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

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

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

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

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

Abbildung 8.3-1: Assoziation von Datenobjekt mit Sequenzflusskante

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

Die Bedeutung ist wie folgt:

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

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

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

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

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

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

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

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

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

Abbildung 8.3-5: Datentransport ohne expliziten Transport

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

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

Prozessfragment:

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

Enthaltene Elemente:

- Ad Hoc-Markierung

- Ad Hoc-Subprozess

- Aggregation

- Assoziation

- Assoziation, gerichtet

- Schleifen-Aufgabe

- Aufgaben

- Datenobjekt (Erzeugung)

- Datenobjekt (lesend))

- Datenobjekt (verändernd)

- Datenobjekt am Sequenzfluss

- Mehrfachinstanz-Aufgabe, parallel

- Mehrfachinstanz-Markierung

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

 

9 Ereignisse

9.1 Einführung

9.1.1 Konzept

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

Definition Ereignis

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

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

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

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

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

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

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

Man merkt den Ausführungen der BPMN-Autoren an, dass dieser Teil der Methode große Bedeutung hat. In einer Standardprozessmodellierung wäre dies in diesem Umfang nicht nötig, geht es aber um die Umsetzung des Prozessmodells in ausführbare Software, ist 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 9.1-1: Darstellung eines Ereignisses - allgemeine Form

9.1.2 Ausdifferenzierung

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

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

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

Empfangend (catching) und Abgebend (throwing)

Empfangend (catching) bedeutet, dass es …

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, interrup­ting)
  • Startereignis / Ereignissubprozess, nicht unterbrechend (event sub-process, none interrupting)
  • Zwischenereignis / Grenzlinie, unterbrechend(boundary, interrupting)
  • Zwischenereignis / Grenzlinie, nicht unterbrechend(boundary, non interrupting)

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

 

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

Ereignisauslöser

1. Kein bestimmter Auslöser (none).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.1.3 Startereignisse - allgemein

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

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

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

Implizite Startereignisse

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

Ohne explizites Startereignis

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

Token

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

Mehrere Startereignisse

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

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

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

Im Subprozess

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

9.1.4 Zwischenereignisse - allgemein

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

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

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

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

Abbildung 9.1-3: Zwischenereignis mit Zeitgeber

Enthaltene Elemente:

- Zeitgeber-Zwischenereignis / Grenzlinie, unterbrechend

- Aufgaben

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

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

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

Verknüpfung im Sequenzfluss

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

Folgende Regeln gelten hier:

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

Token bei Zwischenereignissen

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

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

9.1.5 Schlussereignisse - allgemein

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

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

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

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

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

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

Token

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

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

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

9.2 Ereignistypen

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

9.2.1 Kein Auslöser

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

 

Abbildung 9.2-1: Ereignisse ohne Kennzeichen

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

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

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

9.2.2 Nachricht

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

 

Abbildung 9.2-2: Ereignistyp und Marker Nachrichten

Die Bedeutung ist wie folgt:

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

9.2.3 Fehler

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

Abbildung 9.2-3: Ereignistyp und Marker Fehler

Bedeutung des Kennzeichens bzw. der Ereignistypen:

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

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

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

9.2.4 Zeitgeber

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

Abbildung 9.2-4: Ereignistyp und Marker Zeitgeber

Bedeutung des Kennzeichens bzw. der Ereignistypen:

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

9.2.5 Eskalation

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

Abbildung 9.2-5: Ereignistyp und Marker Eskalation

Es liegt für folgende Situationen vor:

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

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

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

9.2.6 Signal

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

Abbildung 9.2-6: Ereignistyp und Marker Signal

Bedeutung des Kennzeichens bzw. der Ereignistypen:

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

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

9.2.7 Abbruch

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

Abbildung 9.2-7: Ereignistyp und Marker Abbruch

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

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

9.2.8 Kompensation

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

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

Abbildung 9.2-8: Ereignistyp und Marker Kompensation

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

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

9.2.9 Bedingung

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

Abbildung 9.2-9: Ereignistyp und Marker Bedingung

Bedeutung des Kennzeichens bzw. der Ereignistypen:

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

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

9.2.10 Verknüpfung

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

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

Abbildung 9.2-10: Ereignistyp und MarkerVerknüpfung

9.2.11 Beenden

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

Abbildung 9.2-11: Ereignistyp und Marker Beenden

9.2.12 Mehrfach

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

Abbildung 9.2-12: Ereignistyp und Marker Mehrfach

Bedeutung des Kennzeichens bzw. der Ereignistypen:

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

9.2.13 Parallel mehrfach

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

 

Abbildung 9.2-13: Ereignistyp und Marker Parallel mehrfach

Bedeutung des Kennzeichens bzw. der Ereignistypen:

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

 

10 Kontrollfluss - Sequenzfluss

10.1 Einführung

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

Definition Sequenzfluss (sequence flow)

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

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

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

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

10.2 Flüsse

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

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

Normaler Sequenzfluss (normal flow)

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

Abbildung 10.2-1: Darstellung einer Sequenzflusskante

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

Unkontrollierter Fluss (uncontrolled flow)

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

Fluss mit Bedingungen (conditional flow)

Ein Sequenzfluss kann Bedingungen haben, die zur Laufzeit des Prozesses (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 10.2-2: Darstellung eines Flusses mit Bedingung

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

Voreingestellter Fluss (default flow)

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

Abbildung 10.2-3: Darstellung eines voreingestellten Flusses

Flüsse für Ausnahmen (exception flow)

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

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

Abbildung 10.2-4: Darstellung eines Ausnahmeflusses

Enthaltene Elemente (Auswahl):

- Fehler-Zwischenereignis / Grenzlinie, unterbrechend

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

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

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

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

10.3 Sequenzflüsse mit Subprozessen

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

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

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

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

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

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

10.4 Nachrichtenflüsse

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

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

Abbildung 10.4-1: Darstellung eines Nachrichtenflusses

Nur zwischen Becken

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

Nachrichten zu Subprozessen

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

10.5 Schleifen

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

Schleife in einer Aktivität - Standardsituation

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

Die BPMN-Autoren nennen dies activity loopingund haben dafür ein eigenes Symbol vorgesehen, einen geöffneten Kreis mit Pfeilspitze, der innen und zentriert am unteren Rand des Aktivitätsdiagramms angefügt wird. Die folgende Abbildung zeigt dies und ein Beispiel. Ansonsten ist die Spezifikation der Schleife in den Attributen der Aktivität festgehalten.

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

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

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

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

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

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

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

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

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

Schleife im Sequenzfluss

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

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

Abbildung 10.5-3: Rücksprung per Schleife im Sequenzfluss. Unten die in den Quellen übliche Darstellung, oben die syntaktisch korrekte.

10.6 Kompensationen

Kompensationsassoziation

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

Abbildung 10.6-1: Darstellung einer Kompensationsassoziation

Enthaltene Elemente (Auswahl):

- Kompensations-Zwischenereignis / Grenzlinie, unterbrechend

10.7 Prozessunterbrechung

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

Abbildung 10.7-1: Darstellung einer Prozessunterbrechung

Enthaltene Elemente (Asuwahl):

- Nachrichten-Zwischenereignis, empfangend

10.8 Handlung durch Ereignisse

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

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

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

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

Das empfangende Nachrichten-Zwischenereignis / Grenzlinie, nicht unterbrechend am Subprozess Buchung tritt ein, falls während des Buchungsvorgangs die Notwendigkeit entsteht, die Kreditkartendaten zu aktualisieren.

Das empfangende Kompensations-Zwischenereignis / Grenzlinie, unterbrechend am Subprozess tritt ein, wenn sich herausstellt, dass die Buchung rückgängig gemacht werden muss.

.Das empfangende Fehler-Zwischenereignis / Grenzlinie, unterbrechend "Buchungsfehler 2“ führt zu einem Exclusive Gateway das entweder an den Beginn der Transaktion verzweigt oder zu einer Aktivität, mit der der Kunde über den Fehlschlag informiert wird. Letzteres falls die maximale Anzahl an Wiederholungen erreicht ist.

An der Aktivität Belaste Kreditkarte:

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

 

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

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

Varianten dieses Geschäftsprozesses finden sich in:

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

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

10.9 Transaktionen

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

Definition Transaktion

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

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

Abbildung 10.9-1: Subprozess als Transaktion

Enthaltene Elemente (Auswahl):

- Startereignis

- Schlussereignis

- Transaktion

Eine Transaktion wird typischerweise auf drei Arten beendet:

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

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

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

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

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

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

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

Enthaltene Elemente (Auswahl):

- Abbruch-Zwischenereignis / Grenzlinie, unterbrechend

- Fehler-Zwischenereignis / Grenzlinie, unterbrechend

- Transaktion

Betrachten wir dieselbe Transaktion in entfalteter Fassung (expanded). Dies könnte wie in der folgenden Abbildung aussehen.

Abbildung 10.9-3: Flug- und Hotelbuchung - Variante 2. Als Subprozess mit Transaktion (entfaltet).
Quelle: [OMG 2011, Figure 10.33, S. 179]. Übersetzung durch den Verfasser.

Enthaltene Elemente (Auswahl):

- Abbruch-Zwischenereignis / Grenzlinie, unterbrechend

- Aufgabe mit Kompensations-Ereignis

- Fehler-Zwischenereignis / Grenzlinie, unterbrechend

- Kompensations-Aufgabe

- Kompensations-Zwischenereignis / Grenzlinie, unterbrechend

- Schlussereignis

- Sequenzfluss von Transaktion zu Aktivität ("Erfolgreiche Buchungen")

- Startereignis

- Transaktion

Varianten dieses Geschäftsprozesses finden sich in:

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

Kommt es dann zum Abbruch, werden die Aktivitäten von innerhalb der Transaktion den Abbruchaktionen unterworfen, die eine Rückabwicklung des Prozesses und einen Ersatz (compensation) für bestimmte Aktivitäten enthalten können.

Grundsätzlich gibt es zwei Mechanismen, die den Abbruch einer Transaktion signalisieren:

  • Ein Abbruch-Schlussereignis wird im Transaktions-Subprozess erreicht. Ein Abbruch-Schlussereignis kann nur in einem Subprozess genutzt werden, der eine Transaktion ist.
  • Eine Abbruchnachricht kann über das Transaktionsprotokoll erhalten werden, das die Ausführung des Subprozesses unterstützt.

Erfolgreiche Beendigung

Das Verhalten am Ende eines erfolgreichen Transaktions-Subprozesses ist etwas anders als das eines normalen Subprozesses. Wenn jeder Pfad eines Transaktions-Subprozesses ein Endereignis erreicht, das keinen Abbruch darstellt (non-Cancel End Event), geht der Fluss nicht sofort zum übergeordneten Elternprozess zurück, wie ein normaler Subprozess. Zuerst muss das Transaktionsprotokoll sicherstellen, dass alle Teilnehmer erfolgreich ihr Ende der Transaktion erreicht haben. Meistens wird dies wahr sein und der Fluss wird dann "nach oben" gehen zum übergeordneten Prozess. Aber es kann sein, dass einer der Partizipanten mit einem Problem endet, das einen Abbruch oder ein Risiko mit sich bringt. In diesem Fall geht der Fluss zum entsprechenden Zwischenereignis, selbst wenn er scheinbar erfolgreich beendet wurde.

 

11 Gateways

11.1 Grundlagen

Instanzen. Wie in Abschnitt 2.1 ("Modell und Instanz") 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.

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 11.1-1: Verzweigende Sequenzflusskanten

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

Abbildung 11.1-2: Verschmelzende Sequenzflusskanten

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

Abbildung 11.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" Kon­trollflü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.

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 11.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 11.1-5: Darstellung eines Gateways

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

11.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 11.2-2: Datenbasiertes Exclusive Gateway - abstrakt

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 11.2-3: Auftragseingang mit datenbasiertem Exclusive Gateway - verzweigend

11.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 11.2-4: Datenbasiertes Exclusive Gateway - verschmelzend

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

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

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

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

11.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 im Modell geplanten bei jeder Instanz aktiv werden müssen.
  • Bei ankommenden, dass alle im Modell geplanten bei jeder Instanz auch wirklich ankommen.

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

Abbildung 11.4-1: Darstellung eines Parallel Gateway

11.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 11.4-2: Parallel Gateway, verzweigend - abstrakt

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 11.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 11.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 11.4-5: Transportauftrag starten mit Parallel Gateway (verzweigend)

Enthaltene Elemente (Auswahl):

- Nachrichten-Startereignis / oberste Ebene

- Parallel Gateway, verzweigend

11.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 11.4-6: Abstraktes Parallel Gateway - verknüpfend

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 11.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 11.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. dazu Abschnitt 12.6.

11.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 11.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 11.5-2: Prozessstart Produktionsplanung mit verknüpfendem Parallel Gateway (ereignisbasiert) für den Prozessstart (Parallel Event-Based Gateway)

Enthaltene Elemente (Auswahl):

- Implizites Parallel Gateway, verknüpfend

- Nachrichten-Zwischenereignis, 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 11.5-3: Prozessstartmit ereignisbasiertem Parallel Gateway - am Beispiel Bewertung von Vorträgen

11.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 11.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 11.6-2: Inclusive Gateway, verzweigend - abstraktes Beispiel

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 11.6-3: Inclusive Gateway - abstraktes Beispiel (verzweigend) mit einzelnen Sequenzflusszweigen

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 11.6-4: Prozessmodell und mögliche Prozessinstanzen - am Beispiel des Inclusive Gateway mit drei Sequenzflusszweigen

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 11.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 (vgl. auch Abbildung 11.6-3).

Abbildung 11.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 11.6-7: Kundenkontakt Sparkasse mit Inclusive Gateway- verknüpfend

Enthaltenes Element (Auswahl):

- Inclusive Gateway, verknüpfend

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 11.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 Komponenten­lieferung 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 11.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].

11.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 11.7-1: Darstellung eines Complex Gateway

Bei diesem Gateway ist zum Verständnis die Betrachtung der inneren Struktur unabdingbar. Vgl. auch die Abbildung 11.7-2. 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 activation­Expression (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 waiting­ForStart. 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.

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

Inhaltliche Beispiele

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. Im ersten 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 11.7-3: Lagerbestandsprüfung mit einem Complex Gateway

Gateway:

- Complex Gateway, verzweigend

Das folgende Beispiel beschreibt die Situation rund um einen Auftragsstart. Ein Auftrag geht ein, die Prüfung der Fertigungskapazität und des Lagerbestandes wird gestartet. Folgende Ergebnisse können sich ergeben:

  • Prüfung Fertigungskapazität: Kapazität reicht, Kapazität reicht nicht
  • Prüfung Lagerbestand: ausreichend, nicht ausreichend

Im Complex Gateway könnten nun die in der Abbildung angegebenen weiterführenden Sequenzflüsse geprüft werden. Da hier alle semantisch möglichen Kombinationen bedacht wurden, wird auf einen voreingestellten Sequenzfluss verzichtet.

"Kombinatorikproblem"

Hier wird ein sog. Kombinatorikproblem durch das Complex Gateway gelöst. Vgl. für eine Lösung mit Ereignisgesteuerten Prozessketten und logischen Operatoren [Staud 2014, Abschnitt 8.4].

Abbildung 11.7-4: Prüfung von Bedingungen mit einem Complex Gateway

Enthaltene Elemente (Auswahl):

- Complex Gateway, verzweigend

- Complex Gateway, verknüpfend

- Parallel Gateway, verzweigend

11.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 11.7-5: 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 11.7-6: 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

 

Zusammenfassung

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

Gateway Exclusive databased ohne X.bmpGateway Exclusive mit X.bmp

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

XODER

Gateway event-based START.bmpGateway ereignisbasiert.bmp

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

Gateway Parallel.bmp

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

Gateway Parallel Event-Based.bmp

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

ODER

Gateway Inclusive.bmp

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

---

Gateway Complex.bmp

11.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 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 in 9.2.8 gesehen, gibt es vier Varianten von Kompensationsereignissen: ein Startereignis, ein abgebendes und empfangendes Zwischenereignis und ein Endereignis.

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

Vgl. das Stichwortverzeichnis und 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 11.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 11.8-3: Flug- und Hotelbuchung - Variante 3. 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:

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

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.

 

12 Muster in Geschäftsprozessen

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

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

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

12.1 Geschäftsprozess / Tätigkeit starten

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

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

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

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

Abbildung 12.1-1: Alle möglichen Startereignisse - Auszug aus Abbildung 9.1.-2

12.1.1 Start von Geschäftsprozessen


Semantik sucht Syntax

 

Semantik:

Ein Geschäftsprozess soll gestartet werden. Eine getrennt modellierte Teilaufgabe soll gestartet werden.

Passende Syntax:

Startereignisse für die "oberste Ebene"

Prozessstart-Aufgabe


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

Abbildung 12.1-2: Start durch ein None-Startereignis / oberste Ebene [Auszug aus Abbildung 9.1.-2]

Enthaltene Elemente:

- None-Startereignis / oberste Ebene

- Empfänger-Aufgabe

- Dienst-Aufgabe

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

Abbildung 12.1-3: Start durch ein Nachrichten-Startereignis / oberste Ebene [Auszug aus Abbildung 9.1.-2]

Enthaltene Elemente:

- Nachrichten-Startereignis

- Aufgabe, abstrakte

Durch eine Aufgabe des Typs Prozessstart

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

Abbildung 12.1-4: Prozessstart-Aufgabe

Verknüpfendes ereignisbasiertes Exclusive Gateway für den Prozessstart

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

Verknüpfendes ereignisbasierte Parallel Gateway für den Prozessstart

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

12.1.2 Start von Subprozessen


Semantik sucht Syntax

 

Semantik:

Ein Subprozess soll, angestoßen vom Sequenzfluss, gestartet werden.

Ein Subprozess soll aufgrund von Ereignissen, die "von außen" stammen, gestartet werden.

Passende Syntax:

Startereignisse für die "oberste Ebene"

Startereignisse für Ereignissubprozesse, unterbrechend oder nicht.


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

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

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

Betrachten wir die hier angebotenen Möglichkeiten.

(1) Subprozess im Sequenzfluss.

Erlaubt die Semantik, dass der Subprozess einfach an einer bestimmten Stelle in den Sequenzfluss eingebunden wird, sind die "ganz normalen" Subprozesse die richtige Wahl. Vgl. Abschnitt 6.3.

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

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

(2) Transaktionen


Semantik sucht Syntax

 

Semantik:

Ein Prozessabschnitt soll abgegrenzt und als Ganzes oder gar nicht realisiert werden.

Passende Syntax:

Transaktion


Der wesentliche Unterschied zu den Subprozessen oben besteht darin, dass eine Transaktion nach ihrem Start entweder ganz durchgeführt oder rückabgewickelt wird. Ein beliebtes Beispiel ist eine Überweisung. In Abschnitt 10.9 ist ein Beispiel aus den Originalunterlagen angegeben. Vgl. auch die Beschreibung dort.

(3) Start von Ereignissubprozessen, unterbrechend

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

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

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

Abbildung 12.1-5: Start eines Ereignissubprozesses mit Abbruch Elternprozess - Beispiel. [Auszug aus Abbildung 14.3-1]

Enthaltene Elemente:

- Ereignissubprozess

- Fehler-Schlussereignis

- Fehler-Startereignis / Ereignissubprozess, unterbrechend

- Kompensations-Zwischenereignis / abgebend

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

Hier nimmt der Geschäftsprozess also folgenden Weg (vgl. auch Abschnitt 14.3):

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

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

(4) Start von Ereignissubprozessen, nicht unterbrechend

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

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

Abbildung 12.1-6: Start eines Ereignissubprozesses ohne Abbruch Elternprozess - Beispiel. [Auszug aus Abbildung 14.3-1]

Enthaltene Elemente:

- Ereignissubprozess

- Nachrichten-Startereignis / Ereignissubprozess, nicht unterbrechend

- Schlussereignis

Insgesamt können (vgl. Abbildung 12.1-1) folgende Ereignistypen hier als Startereignisse dienen: Nachricht, Zeitgeber, Eskalation, Signal, Bedingung, Mehrfach und Parallel Mehrfach.

(5) Wiederverwendbare Subprozesse


Semantik sucht Syntax

 

Semantik:

Ein (meist kleiner) Geschäftsprozesses soll abgegrenzt und an vielen Stellen im Prozessgeschehen eingesetzt werden. Er soll außerdem unabhängig vom aufrufenden Prozess sein.

Passende Syntax:

Call Activity


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

12.2 Wiederholung, Rückschleife


Semantik sucht Syntax

 

Semantik:

Ein Prozessabschnitt muss wiederholt werden, einmal oder mehrmals.

Passende Syntax:

"Rücksprung", Aktivität mit Schleifenmarkierung, Subprozess mit Kennzeichen Schleife.


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

  • Aufgabe mit Schleifenmarkierung (loop marker) . Dies ist eher geeignet für Wiederholung "im Kleinen", im Rahmen einer Aufgabe. Z.B. "Maileingang abarbeiten".
  • Subprozess mit Kennzeichen Schleife . Eher geeignet für längere Prozessabschnitte, solche, die typischerweise in einen Subprozess passen. Z.B. "Teilebeschaffung".
  • Schleife im Prozess . Für "echte" Rücksprünge im Geschäftsprozess. Wo also grafisch ausgewiesene Prozessabschnitte wiederholt werden. Dies sind dann prozessindividuelle Situationen, wo nicht der Abschnitt ausgelagert und evtl. an verschiedenen Stellen genutzt werden kann. Beispiele finden sich u.a. in den Abbildungen 10.5-3, 14.1-1, 14.7-1 und14.7-7.

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

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

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

12.3 Entscheidungsfindung


Semantik sucht Syntax

 

Semantik:

Eine Entscheidung ist zu fällen.

Passende Syntax:

- Aufgabe mit verzweigendem Exclusive Gateway oder Inclusive Gateway

- Ereignisbasiertes Exclusive Gateway für den Prozessstart

- Complex Gateway

- Methodenelement Gruppe

- Ereignisse auf der Grenzlinie von Aufgaben


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

Der einfachste Fall

Entscheidungsfindung wird im einfachsten Fall durch eine Aufgabe modelliert, der ein Exclusive Gateway folgt. Wie in vielen Beispielen und insbesondere in Abschnitt 11.3 gezeigt, werden die möglichen alternativen Ergebnisse an die Kanten geschrieben.

Abbildung 12.3-1: Entscheidungsfindung (alternative Entscheidung) mit Hilfe eines datenbasierten Exclusive Gateway

Gateway:

- Exclusive Gateway, verzweigend (datenbasiert)

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

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

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

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

Abbildung 12.3-2: Entscheidungsfindung mit Hilfe eines ereignisbasierten Exclusive Gateway.
Quelle: Auszug aus Abbildung 14.1-1 ("Buchausleihe")

Enthaltene Elemente:

- Sender-Aufgabe

- Exclusive Gateway / ereignisbasiert

- Nachrichten-Zwischenereignis, empfangend

- Zeitgeber-Zwischenereignis / empfangend

- Zwischenereignis / empfangend

Prozessstart

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

Abbildung 12.3-3: Entscheidungsfindung mit Hilfe eines ereignisbasierten Exclusive Gateway für den Prozessstart.
Quelle: Auszug aus Abbildung 14.1-1 ("Buchausleihe")

Enthaltene Elemente (Auswahl):

- Bedingungs-Zwischenereignis, empfangend

- Dienst-Aufgabe

- Exclusive Gateway / ereignisbasiert, für den Prozessstart

- Nachrichten-Zwischenereignis, empfangend

- Nutzer-Aufgabe

- Signal-Zwischenereignis, empfangend

Komplexe Entscheidungen

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

Verdeckte Entscheidungen

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

Abbildung 12.3-4: Entscheidungsfindung mit Hilfe eines Grenzlinienereignisses

Ereignis:

- Zeitgeber-Zwischenereignis / Grenzlinie, unterbrechend

Auch Kompensationen entsprechend diesem Muster (vgl. Abschnitt 9.2.8).

Mehrere zusammen

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

Abbildung 12.3-5: Element Gruppe (group) zur Modellierung von gemeinschaftlicher Entscheidungsfindung.
Quelle: Auszug aus Abbildung 7.2-1

Enthaltene Elemente (Auswahl):

- Gruppe

- Nachrichtenfluss

12.4 Teilaufgaben


Semantik sucht Syntax

 

Semantik:

Teilaufgaben einer umfassenderen Aufgabe sollen gemeinsam "angestoßen" werden.

Passende Syntax:

Ein verzweigendes Parallel Gateway


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

Abbildung 12.4-1: Muster Teilaufgaben

Enthaltene Elemente:

- Nachrichten-Zwischenereignis, empfangend

- Parallel Gateway, verzweigend

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

12.5 Bedingungen


Semantik sucht Syntax

 

Semantik

Bedingungen müssen erfüllt sein, bevor es im Prozess weiter geht.

Passende Syntax:

Aufgabe mit den Ergebnissen "erfüllt" und "nicht erfüllt"

Mehrere Aufgaben mit nachfolgendem Parallel Gateway


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

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

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

Abbildung 12.5-1: Muster Bedingungen - aggregiert und vereinfacht

Erläuterung

„Nicht alles in Ordnung:“ Z.B. Urlaubstage nicht ausreichend, Geschäftslage nicht geeignet, Verretung nicht geklärt.

Enthaltene Elemente (Auswahl) und Konzepte:

- Exclusive Gateway / datenbasiert und verzweigend

- Aggregation

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

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

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

Abbildung 12.5-2: Muster Bedingungen für den Fortgang - am Beispiel Urlaubsantrag

Enthaltene Elemente (Auswahl):

- Exclusive Gateway / datenbasiert und verzweigend

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

- Inclusive Gateway, verknüpfend

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

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

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

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

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

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

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

Abbildung 12.5-3: Muster Bedingungen

Enthaltene Elemente (Auswahl) und Muster:

- Exclusive Gateway / datenbasiert und verzweigend

- Muster Kombinatorik

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

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

12.6 Zeitaspekte

Zeitpunkte

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

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

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

Zeitfenster


Semantik sucht Syntax

 

Semantik:

Teilaufgaben einer umfassenderen Aufgabe sollen gemeinsam erledigt werden. Der Prozess wird erst fortgesetzt, wenn dies geschehen ist.

Passende Syntax:

Ein verzweigendes und ein verknüpfendes Parallel Gateway, zwischen denen die Aktivitäten eingefügt sind.


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

Abbildung 12.6-1: Muster Zeitfenster - abstrakt

 

Abbildung 12.6-1: Muster Zeitfenster – mit Inhalten

Enthaltene Elemente (Auswahl) und Muster:

- Muster Zeitfenster

- Nachrichten-Zwischenereignis

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

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

Warten, Zeitraum

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

Abbildung 12.6-2: Muster Warten.
Quelle: Auszug aus Abbildung 14.1-1.

Enthaltene Elemente (Auswahl) und Muster:

- Dienst-Aufgabe

- Empfänger-Aufgabe

- Exclusive Gateway / datenbasiert und verzweigend

- Exclusive Gateway / ereignisbasiert

- Muster Rücksprung

- Nachrichten-Zwischenereignis / empfangend

- Zeitgeber-Zwischenereignis

13 Choreographie

13.1 Das Konzept

Die BPMN-Autoren nutzen den Begriff Prozess für "a set of flow elements" ("Standard BPMN Process"), für die Interaktionen zwischen Prozessen nutzen sie die Begriffe Collaboration (Kollaboration) und Choreography (Choreographie) [OMG 2011, S. 145]. In diesem Kapitel werfen wir einen Blick auf das Konzept der Choreographie.

Eine Choreographie besteht, ähnlich wie ein Geschäftsprozess, aus einem Netzwerk von Aktivitäten, Ereignissen und Gateways. Allerdings sind die Aktivitäten hier Interaktionen, die einen Nachrichtenaustausch zwischen zwei oder mehr Prozessteilnehmern darstellen. Außerdem gibt es, anders als in einem normalen Prozess, keine zentrale kontrollierende Einheit ("central controller, responsible entity or observer of the Process") des Prozesses [OMG 2011, S. 25] . Im Mittelpunkt steht der Nachrichtenaustausch zwischen den Teilnehmern an den Prozessen.

Anmerkung:

Hier machen die BPMN-Autoren indirekt deutlich, dass Sie bei einem "normalen" Geschäftsprozess vom Vorhandensein einer zentralen koordinierenden Einheit ausgehen.

Eine selbstständige / isolierte Choreographie (ohne Becken oder Orchestrierung) zeigt also das erwartete Verhalten zwischen interagierenden Prozessteilnehmern. Sie existiert nicht in einem Becken, sondern zwischen Becken (oder Prozessteilnehmern).

13.2 Die Elemente

Eine Choreographie kann folgende Elemente enthalten:

  • Nachrichten
  • Choreographie-Aufgaben (Choreography Tasks)
  • Globale Choreographie-Aufgaben (Global Choreography Tasks)
  • Sub-Choreographien, verborgen und entfaltet (Sub-Choreography, expanded and collapsed). Sie erlauben die Zerlegung bzw. Zusammenstellung von Choreographien.
  • Startereignisse, z.B. Kein Auslöser (None), Zeitgeber (Timer), Bedingung (Conditional), Signal und Mehrfach (multiple).
  • Zwischenereignisse, z.B. Kein Auslöser, Nachricht auf der Grenzlinie einer Aktivität, normaler Zeitgeber, Zeitgeber auf der Grenzlinie, Zeitgeber in ereignisbasierten Gateways, Abbruch auf einer Grenzlinie, Bedingung, Signal, Mehrfach und Verknüpfung.
  • Schlussereignisse: Kein Auslöser und Beenden
  • Gateways

Kernelemente und kleinste Einheiten ("atomic units") von Choreographien sind die Message Exchange Patterns (MEPs) [OMG 2011, S. 315]. Sie werden als Rechteck mit abgerundeten Ecken dargestellt. Jedes MEP repräsentiert eine Aktivität und den Nachrichtenaustausch zwischen mindestens zwei Partizipanten. Das grafische Element ist dreigeteilt:

  • Im mittleren Teil die zu lösende Aufgabe, die Choreographie-Aufgabe
  • Im oberen abgegrenzten Streifen der initierende Partizipant (ohne Einfärbung)
  • Im unteren abgegrenzten Streifen der reagierende Partizipant (grau eingefärbt)

Es können auch mehr als jeweils nur ein Partipant sein, vgl. [OMG 2011, S. 315f]. Entsprechend dem Konzept sind den Partizipanten Nachrichten zugeordnet. Dem initiierenden Partizipanten eine empfangende (d.h., das MEP empfängt durch ihn die auslösende Nachricht), dem reagierenden Partizipant eine abgebende.

Im folgenden Beispiel eines MEPs gilt also: Der Patient sendet eine Nachricht. Diese wird bearbeitet, d.h. eine Terminvereinbarung findet statt. Dies führt zu einer Antwort, modelltechnisch zu einer Nachricht, die von der Arztpraxis verschickt wird.

Abbildung 13.2-1: Ein Message Exchange Pattern (MEP).
Quelle: Abgeleitet von [OMG 2011, S. 317, Figure 11.2].

Dies ist nur die Grundstruktur. MEPs können auch nur eine oder mehr als zwei zugeordnete Nachrichten aufweisen.

13.3 Beispiel

Eine Choreographie hat einen Anfang und ein Ende, zwischen den MEPs gibt es einen Sequenzfluss. Nachfolgend ein einfaches Beispiel, anknüpfend an die Beispiele zum Kontakt zwischen Arztpraxis und Patient oben. Im Gegensatz zu den obigen Beispielen steht hier die Interaktion im Vordergrund, der Ablauf wird als eine Folge von Interaktionen gesehen.

Abbildung 13.3-1: Eine Choreographie am Beispiel "Arztpraxis und Patient" - Version 5.
Quelle: [OMG 2011, S. 25, Figure 7.4]. Übersetzung durch den Verfasser.

Enthaltene Elemente (Auswahl):

- Message Exchange Pattern

- Nachrichten, empfangend (bei MEPs)

- Nachrichten, abgebend (bei MEPs)

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

Um Choreographie auch innerhalb von Kollaborationen zu ermöglichen, werden hier ebenfalls Becken (Pools) und Nachrichtenflüsse (Message Flows) unterstützt. Die Choreographien selbst existieren dann außerhalb der Becken.

Dies ist die Grundstruktur einer Choreographie. Vgl. für eine umfassende Darstellung [OMG 2011, Kapitel 11].

14 Prozessmodelle

In diesem Kapitel werden Modellierungsbeispiele vorgestellt. Kleine Fragmente und ganze Geschäftsprozesse. Einige stammen aus den Originalunterlagen, sie wurden lediglich übersetzt und grafisch aufbereitet.

Die Business Process Diagrams werden, wie es in der BPMN meist getan wird, waagrecht angeordnet. Wenn sich Beispiele über mehrere Seiten erstrecken, ist die Anbindung ist so gelöst, dass der rechte Rand der vorangehenden Abbildung genau zum linken Rand der folgenden passt. Meist wird der Zusammenhang auch noch durch Verknüpfungs-Zwischenereignisse verdeutlicht.

14.1 Buchausleihe

In diesem Beispiel geht es um einen Geschäftsprozess Buchausleihe. Es ist von den BPMN-Autoren dafür gedacht, den Einsatz der verschiedenen Aufgabentypen zu demonstrieren. Er enthält aber noch andere wichtige Methodenelemente bzw. Prozessstrukturen.

Das Eingehen der Anfrage wird durch eine Aufgabe des Typs Empfänger (Empfänger-Aufgabe) modelliert. Die nachfolgende Klärung des Ausleihstatus durch eine Aufgabe des Typs Dienst (Dienst-Aufgabe). Diese Klärung führt entweder zu einer Sender-Aufgabe („Mitteilung ausgeliehen“) oder zu einer Aufgabe des Typs Programmnutzung („Ausleihe verbuchen“).

Nach dem Senden der Mitteilung Ausgeliehen (verbal, per Mail, …) liegt die Situation vor, für die ein ereignisbasiertes Exclusive Gateway (vgl. Abschnitt 11.3) benötigt wird. Die Entscheidung über den Fortgang des Prozesses fällt von außen und dies wird durch die Ereignisse vermittelt. Dies sind zwei empfangende Nachrichten-Zwischenereignisse („Anfrage beibehalten“, „Ausleihwunsch stornieren“) und ein Zeitgeber-Zwischenereignis („Eine Woche vergangen“).

Falls der Zeitgeber zur Wirkung kommt, also eine Woche ohne Nachricht vergangen ist, oder falls der Ausleihwunsch storniert wird, wird eine Aufgabe des Typs Sender angestoßen („Rücknahme mitteilen“). Der hier erfolgte Verzicht auf ein verknüpfendes Gateway ist nicht empfehlenswert, wird aber von den BPMN-Autoren in ihren Beispielen öfters gemacht.

Falls der Ausleihwunsch bestätigt wird ("Anfrage beibehalten") wird eine Aufgabe des Typs Dienst angestoßen, die das programmgestützte Vermerken der Vorbestellung modelliert („Vorbestellung vermerken“).

Nach dem Vermerken der Vorbestellung wird dies dem Ausleiher mitgeteilt. Danach ist durch ein empfangendes Zeitgeber-Zwischenereignis eine feste Zeitspanne modelliert. Zwei Wochen wird gewartet, dann erfolgt wieder eine Prüfung des Ausleihstatus, modelliert durch eine Dienst-Aufgabe (Service Task Object).

Hierdurch entsteht eine Schleife im Geschäftsprozess, der Prozess wird ab dieser Aufgabe wieder neu durchlaufen. Diese Schleife wird abgebrochen, falls der Ausleiher seinen Ausleihwunsch storniert oder falls das Buch verfügbar ist.

Der Geschäftsprozess wird beendet, indem entweder der Ausleihversuch scheitert oder das Buch zur Ausleihe bereitsteht und dies dem Ausleiher mitgeteilt wird.

Abbildung 14.1-1: Buchausleihe.
In Anlehung an [OMG 2011, S. 145, Figure 10.1]. Übersetzung durch den Verfasser.

Enthaltene Elemente (Auswahl) und Muster:

- Dienst-Aufgabe

- Empfänger-Aufgabe

- Exclusive Gateway / datenbasiert und verzweigend

- Exclusive Gateway / ereignisbasiert

- Implizites verknüpfendes Exclusive Gateway

- Muster Rücksprung

- Muster Warten

- Nachrichten-Zwischenereignis / empfangend

- Nutzer-Aufgabe

- Schlussereignis

- Sender-Aufgabe

- Startereignis

- Zeitgeber-Zwischenereignis

14.2 Auftragsabwicklung - hoch aggregiert

Im folgenden Beispiel geht es um einen Beschaffungsprozess aus Käufersicht [OMG 2011, S. 170f]. Der Prozess startet mit der Überprüfung der Preisangaben und dann des Auftrags (z.B. durch den "Regionalmanager"). Dies wird durch eine Nutzer-Aufgabe modelliert. Die Prüfung wird durch ein datenbasiertes verzweigendes Exclusive Gateway modelliert. Sie führt entweder zur Akzeptanz des Auftrags oder nicht, letzteres modelliert durch ein Beenden-Schlussereignis.

Falls der Auftrag akzeptiert wird kommt es zu einem Zeitfenster: Das erste Parallel Gateway stößt zwei Aufgaben an, über das zweite geht es nur weiter, falls die Aufgaben Auftrag bearbeiten und Versenden realisiert sind. Vgl. hierzu Abschnitt 14.2. Danach kommt es zur Schlussprüfung des Auftrags, wieder modelliert als Nutzer-Aufgabe.

Abbildung 14.2-1: Beschaffung aus Käufersicht - hoch aggregiert.
Quelle: [OMG 2011, S. 170, Figure 10.24]. Übersetzung durch den Verfasser.

Enthaltene Elemente (Auswahl):

- Becken

- Beenden-Schlussereignis

- Exclusive Gateway / datenbasiert und verzweigend

- Nutzer-Aufgabe

- Parallel Gateway, verzweigend

- Parallel Gateway, verknüpfend

14.3 Flug- und Hotelbuchung

Das folgende Beispiel zeigt wiederum einen Ausschnitt aus einem Prozess für das Buchen von Flügen und Reisen. Es ist der umfassendste aus der Serie der Prozesse zu diesem Anwendungsbereich (vgl. die Liste unten). Bei diesem Beispiel liegt der Schwerpunkt darauf, die Einbettung und Modellierung mit Hilfe eines Subprozesses und darin eingebetteter Ereignissubprozesse zu demonstrieren.

Ereignissubprozesse werden durch Ereignisse aufgerufen (vgl. Abschnitt 6.3.3). Folgende liegen hier vor:

  • Ein entfalteter Nachrichten-Ereignissubprozess Aktualisierung Kreditkarteninformation. Ausgelöst wird er durch ein Nachrichten-Startereignis vom Typ Startereignis / Ereignissubprozess, nicht unterbrechend. Es unterbricht also nicht den Elternprozess und kann mehrfach auftreten.
  • Ein Kompensations-Ereignissubprozess Durchführung Kompensation. Ausgelöst durch ein Kompensations-Startereignis vom Typ Startereignis / Ereignissubprozess, nicht unterbrechend.
  • Ein Fehler-Ereignissubprozess Bearbeitung Buchungsfehler. Ausgelöst durch ein Fehler-Startereignis vom Typ Startereignis/empfangend/unterbrechend. Geht mit Fehlern um, die auftreten, solange der Subprozess aktiv ist. Bricht den Elternprozess ab.

Prozessbeschreibung

Das Prozessfragment beginnt mit der Beschaffung von Kreditkarteninformationen. Danach wird der Subprozess Buchung angestoßen. Die zwei auf der linken Seite eingefügten Exclusive Gateways dienen dem Einbinden von Rücksprüngen. Einmal um die Beschaffung der Kreditkarteninformationen zu wiederholen, falls die mögliche Anzahl Buchungen (links oben) überschritten worden war. Zum anderen zum Neustart des Subprozesses, nachdem ein Buchungsfehler auftrat.

Der Subprozess wird gestartet, indem sein Startereignis ausgelöst wird. Dies führt zum parallelen "Anwerfen" der Flug- und Hotelbuchung. Wenn alles gut geht, kommt es zum Schlussereignis und der Subprozess ist abgearbeitet. Der Sequenzfluss geht dann weiter zur Aufgabe Belaste Kreditkarte. Geht diese in Ordnung, kommt es zum Schlussereignis des gesamten Fragments. Soweit der positive Ablauf, der ja recht übersichtlich ist.

Gibt es bei der Aufgabe Belaste Kreditkarte Probleme, empfängt dies das unterbrechende auf der Genzlinie befindliche Zwischenereignis. Danach wird ein abgebendes Kompensations-Zwischenereignis bzgl. des gesamten Subprozesses Buchung ausgelöst. Gleichzeitig erfolgt die Prüfung, ob die maximale Anzahl an Wiederholungen erreicht ist oder nicht. Falls nicht, kommt es zum Rücksprung an den Anfang und die Aufgabe Kreditkarteninformation beschaffen wird nochmals angestoßen. Falls sie erreicht ist wird der Kunde über den Misserfolg informiert und der Prozess beendet.

In dieses Beispiel haben die BPMN-Autoren noch einige weitere mögliche Schwierigkeiten und die Reaktionen darauf eingebaut. Beginnen wir mit den Kompensationen. Geht bei der Aufgabe Flug buchen etwas schief, wird ein Kompensations-Ereignis ausgelöst, das von dem unterbrechenden Zwischenereignis auf der Grenzlinie empfangen wird. Dieses löst dann die Kompensations-Aufgabe Flug stornieren aus. Genau gleich ist der Ablauf, falls die Hotelbuchung schief geht.

Tritt ein solcher Buchungsfehler im Subprozess auf, wird der Ereignissubprozess Bearbeitung Buchungsfehler ausgelöst. Starteereignis ist entsprechend ein Fehler-Startereignis vom Typ Ereignissubprozess, unterbrechend. Dieses stößt mit Hilfe eines Parallel Gateway zwei abgebende Kompensations-Zwischenereignisse bzgl. der Flug- und der Hotelbuchung an. Abschließend wird in diesem Ereignissubprozess ein Fehler-Schlussereignis (Buchungsfehler 2) ausgelöst. Dieses wird vom gleichnamigen Fehler-Zwischenereignis / Grenzlinie unterbrechend (auf der Grenzlinie des Subprozesses) empfangen und stößt eine Überprüfung bzgl. der maximalen Anzahl von Wiederholungen an. Ist diese noch nicht erreicht, kommt es zum Neustart des Subprozesses (Rücksprung), ist diese erreicht wird der Kunde über den Misserfolg informiert und der Prozess endet.

Die beiden abgebenden Kompensations-Zwischenereignisse im Ereignissubprozess Bearbeitung Buchungsfehler führen zum Start des Ereignissubprozeses Durchführung Kompensation durch dessen Kompensations-Startereignis. Sie signalieren dem Empfänger den Kompensationsbedarf.

Abbildung 14.3-1: Flug- und Hotelbuchung - Variante 4. Mit Ereignissubprozessen.
Quelle: [OMG 2011, Figure 10.100, S. 278]. Übersetzung durch den Verfasser.

Dieser Prozess kann auch mit Hilfe von empfangenden Zwischenereignissen auf der Grenzlinie des Subprozesses modelliert werden. Vgl. dazu Abbildung 10.8-1.

Enthaltene Elemente (Auswahl):

- Exclusive Gateway / datenbasiert und verknüpfend

- Exclusive Gateway / datenbasiert und verzweigend

- Fehler-Ereignissubprozess (entfaltet)

- Fehler-Schlussereignis

- Fehler-Startereignis / Ereignissubprozess, unterbrechend

- Fehler-Zwischenereignis / Grenzlinie, unterbrechend

- Kompensations-Aufgabe

- Kompensations-Ereignissubprozess(entfaltet))

- Kompensations-Startereignis / Ereignissubprozess, unterbrechend

- Kompensations-Zwischenereignis / abgebend

- Kompensations-Zwischenereignis / Grenzlinie, unterbrechend

- Muster Rücksprung

- Nachrichten-Ereignissubprozess (entfaltet))

- Nachrichten-Startereignis / Ereignissubprozess, nicht unterbrechend

- None-Schlussereignis

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

- Subprozess, entfaltet

Varianten dieses Geschäftsprozesses finden sich in:

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

14.4 Flug- und Hotelbuchung aggregiert

Das folgende Prozessmodell zeigt, wie das vorige, die Abläufe für eine Flug- und Hotelbuchung, allerdings weniger detailliert. Es ist die fünfte Variante dieses Geschäftsprozesses. Die BPMN-Autoren demonstrieren damit die Nutzung des Verknüpfungsereignisses. In der ersten Abbildung ist das abgebende Verknüpfungs-Zwischenereignis am weiterführenden Ende des Prozessfragments eingefügt. Es wird beschriftet und signalisiert, dass es in einem anderen Fragment ein gleichnamiges empfangendes Zwischenereignis gibt. So wie hier im zweiten Prozessfragment. Die Beschriftung ist jeweils "A". Dies ist also in dieser Methode der Prozesswegweiser bzw. Prozessverknüpfer.

Von Interesse ist dieses Prozessmodell aber vor allem als weitere Variante des Beispiels zu Flug- und Hotelbuchungen. Diese ist gegenüber oben wesentlich weniger detailliert und aggregierter. Der Prozess wird durch ein Nachrichten-Startereignis / oberste Ebene gestartet. Dieses stößt einen entfalteten Subprozess an, in dem zwei Aufgaben mit Schleifencharakter eingefügt sind. Der Subprozess ist erst fertig, wenn beide Aufgaben abgearbeitet sind, auf das Modellieren des Scheiterns der Buchungsversuche wird in dieser Variante also verzichtet (Verzicht auf Detaillierung). Danach wird ein verborgener Subprozess („Reisevorschläge erarbeiten, zusenden) angestoßen, in dem alle Arbeiten zu den Reisevorschlägen gepackt sind (Aggregation). Anschließend folgt eine Aufgabe, die das Warten auf die Zustimmung des Reisewilligen ausdrückt. Hier ist neben dem positiven Ergebnis (von dem die Modellierer ausgehen) auch mit Hilfe eines Zeitgebers (Zeitgeber-Zwischenereignis / Grenzlinie, unterbrechend) der Fall modelliert, dass 2 Tage lang keine Reaktion erfolgt. Dies führt zum Abbruch der Anfrage, was dem Reisewilligen mitgeteilt wird.

Das sendende Verknüpfungsereignis führt zum zweiten Prozessfragment mit dem positiven Fortgang. Dort startet das empfangende Verknüpfungs-Zwischenereignis den Prozess. Zuerst wird ein Subprozess angestoßen (Aggregation) mit dem Buchen der Reservierungen. Es folgt die Aufgabe Käufer belasten und dann das Senden der Erledigungsnachricht. Auch hier wird auf das Modellieren eventueller Schwierigkeiten verzichtet (Verzicht auf Detaillierung). Im Vergleich zum obigen Prozessmodell wird hier im Wesentlichen der positive Ablauf der Reservierungswünsche und der Buchung modelliert.

Abbildung 14.4-1: Flug- und Hotelbuchung - Variante 5. Aggregiert und mit Verknüpfungen.
Quelle: [OMG 2011, S. 268, Figure 10.84]. Übersetzung durch den Verfasser.

Anmerkung:

Die Rahmen um die Teilprozesse haben keine methodische Bedeutung

Enthaltene Elemente (Auswahl):

- Nachrichten-Startereignis / oberste Ebene

- Schleifen-Aufgabe

- Subprozess, entfaltet

- Subprozess, verborgen

- Verknüpfungs-Zwischenereignis / abgebend

- Verknüpfungs-Zwischenereignis / empfangend

- Zeitgeber-Zwischenereignis / Grenzlinie, unterbrechend

Besondere Theorieaspekte:

- Aggregation

Varianten dieses Geschäftsprozesses finden sich in:

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

14.5 Kreditunterlagen prüfen

Dieser Prozess aus [OMG 2009, S. 61] dient als Beispiel für einen Prozess, der als Call Activity (vgl. Abschnitt 6.3.3) oder als Top-Level - Prozess verwendet werden kann. Er stellt inhaltlich eine Kreditanfrage dar. Am Anfang des Prozesses finden sich ein Startereignis ohne spezifischen Auslöser (None-Startereignis) und ein Nachrichten-Startereignis (oberste Ebene). Eines von beiden muss eintreten, damit der Prozess startet.

Die erste Aufgabe prüft die Kreditunterlagen, in der nächsten ist die Entscheidung erfasst, ob der Kreditanfrage zugestimmt werden kann oder nicht. Die Entscheidung wird durch ein verzweigendes Exclusive Gateway mit einer Voreinstellung bzgl. des Fortgangs der Sequenzflüsse modelliert. Für jeden der Fälle folgt anschließend die Prüfung, ob eine interne Nachfrage nötig ist. Für den Fall, dass dies nicht nötig ist, drückt ein abgebendes Nachrichten-Schlussereignis aus, dass das Ergebnis der Prüfung weitergeleitet wird. Für den Fall, dass eine interne Nachfrage nötig ist (Voreinstellung bzgl. Sequenzfluss) kommt es zu einem Schlussereignis ohne Auslöser (None-Schlussereignis).

Abbildung 14.5-1: Ein Prozess, der als Call Activity und als Top-Level - Prozess genutzt werden kann.
Quelle: Leicht verändert nach [OMG 2009, S. 61], Übersetzung durch den Verfasser.

Enthaltene Elemente (Auswahl):

- Aufgaben

- Nachrichten-Schlussereignis

- Nachrichten-Startereignis

- Schlussereignis

- Startereignis

- Exclusive Gateway / datenbasiert und verknüpfend

- Exclusive Gateway / datenbasiert und verzweigend

- Voreinstellung (bzgl. Sequenzfluss)

14.6 Angebotserstellung im Anlagenbau

Vorbemerkung: Die hier zugrundeliegende Prozessbeschreibung entspricht weitgehend einer realen ersten Prozessaufnahme. Sie wurde gekürzt und anonymisiert, aber nicht "geglättet", wie dies meist der Fall ist. Deshalb enthält sie Ablaufbeschreibungen auf unterschiedlichen Ebenen, für die Prozessmodellierung überflüssige Anmerkungen und unvollständige Angaben, v.a. bzgl. der Datenobjekte. Damit soll genau auf diese Probleme hingewiesen werden. Prozessbeschreibungen sind oft sehr unscharf bzw. lückenhaft. In einer realen Modellierungssituation würde dies bei der nächsten Projektbesprechung mit den Prozessverantwortlichen geklärt.

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

Zu Beginn eines solchen BPMN-Modellierungsvorhabens sollten die insgesamt beteiligten Akteure (Mitarbeiter, Abteilungen und externe Partner) geklärt werden. Hier ergibt sich:

  • Der Kunde
  • Das Unternehmen mit dem Vertriebsingenieur (VI), dem Vertriebsbereichsleiter (VBL), dem Vertrieb (als Abteilung) und dem Zentralsekretariat

Entsprechend werden die Becken und Bahnen angelegt.

Prozessbeschreibung

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

Umsetzung als Business Process Diagram (BPD)

Obige Beschreibung ist unternehmenszentriert. In der BPMN wird aber meist der Gesamtkontext eines Geschäftsprozesses modelliert. Deshalb startet im BPD der Prozess beim Kunden. Dort wird die Aufgabe Anfrage formulieren angestoßen. Danach wird entschieden, auf welche Weise die Anfrage verschickt wird. Dies wird durch ein Exclusive Gateway und drei nachfolgende Aufgaben modelliert. Von diesen geht jeweils ein Nachrichtenfluss in das Becken Unternehmen. Ansonsten wird der Geschäftsprozess beim Kunden beendet.

Die oben beschriebene Prozesssituation ("eine der Anfragen kann eingehen") kann nun durch ein ereignisbasiertes Exclusive Gateway für den Prozessstart modelliert werden.

Es weist die drei empfangenden Nachrichten-Zwischenereignisse Anfrage per Brief, Anfrage per Telefax und Telefonische Anfrage auf. Platziert ist dieser Prozessabschnitt im Zentralsekretariat, wie es die Prozessbeschreibung angibt. Die Kundenanfragen per Brief, per Telefax oder per Telefon werden mit den entsprechenden Zwischenereignissen verbunden.

Bei einer telefonischen Anfrage folgt die Aufgabe Anfragefixierung mit einem entsprechenden Datenobjekt. Da der Sequenzfluss für alle drei Varianten einheitlich weitergeht, werden die drei Sequenzflüsse dann zusammengeführt (Position 1). Hierzu dient ein verknüpfendes Exclusive Gateway. Es folgt die Aufgabe Formale Korrektheit prüfen. Da in der Prozessbeschreibung nicht darauf eingegangen wird, was bei fehlerhafter formaler Korrektheit geschieht, wird es hier auch nicht modelliert. Die Prüfung erfolgt auf der Basis des Datenobjekts Anfrage.

Im Anschluss wird die in der Prozessbeschreibung geforderte Weiterleitung des Angebots an den zuständigen Vertriebsbereichsleiter (VBL) und die Geschäftsleitung (GL) modelliert. Dies kann so wie hier realisiert werden: durch ein Parallel Gateway, dem die Tätigkeiten folgen). Wie in der Prozessebeschreibung gefordert wird dann noch die die Weiterleitung zum VI (Vertriebsingenieur) durch den VBL modelliert.

Damit sind hier die Transportvorgänge jeweils durch eine eigene Aufgabe ausdrücklich modelliert.

Die folgende Abbildung zeigt die bisherigen Modellierungsschritte. Es werden alle Bahnen angegeben, auch die ohne Aktivitäten. Dies erleichtert den Gesamtüberblick. Bei sehr großen Business Process Diagramms werden im weiteren oftmals die im jeweiligen Abschnitt nicht "bestückten" Becken und Bahnen weggelassen.

Abbildung 14.6-1: Angebotserstellung für Anlagen, Teil 1 - Prozessstart

Enthaltene Elemente (Auswahl):

- Bahnen

- Becken

- Datenobjekt (Erzeugung)

- Datenobjekt (lesend))

- Datenobjekt am Sequenzfluss

- Exclusive Gateway / ereignisbasiert, für den Prozessstart

- Exclusive Gateway, verknüpfend

- Informationstransport durch Aufgabe

- Muster Teilaufgaben

- Nachrichtenfluss

- Nachrichten-Zwischenereignis, empfangend

- Parallel Gateway, verzweigend

- Verknüpfungs-Zwischenereignis / abgebend

Alternative

Möglich wäre hier z.B. eine Abstrahierung (von der konkreten Form der Nachricht) gewesen. Dies ist eine gängige Methode in der Prozessmodellierung. Dann liegt beim Kunden eine einzige Aktivität vor, die eine Nachricht übermittelt. Im Zentralsekretariet müsste dann die Aktivität Klären Anfrageart eingefügt werden, da ja für telefonische Anfragen eine Anfragefixierung erfolgt (und nur für diese). Vgl. die folgende Abbildung.

Abbildung 14.6-2: Angebotserstellung für Anlagen - alternativer Start (Abgeleitet von Abbildung 14.6-1).

Enthaltene Elemente (Auswahl):

- Datenobjekt (lesend)

- Exclusive Gateway / datenbasiert und verknüpfend

- Exclusive Gateway / datenbasiert und verzweigend

- Nachrichtenfluss

Prozessbeschreibung - Fortsetzung

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

Umsetzung als BPD

Die Weiterleitung der Anfrage, ein Informationstransport, wurde wiederum durch eine Aktivität modelliert (obige Abbildung). Der Text deutet an, dass die Prüfung mehrstufig ist und dass es im ersten Schritt um das angefragte Leistungsspektrum geht. Dieses kann in vollem Umfang ("Passend"), teilweise ("Nur Teile") oder gar nicht ("nicht realisierbar") mit dem Leistungsspektrum des Unternehmens übereinstimmen. Die Modellierung erfolgt mit einem datenbasierten verzweigenden Exclusive Gateway (Pos. 2).

Nach dem Ergebnis Nicht realisierbar kann dann gleich eine Aktivitität folgen, in der die Absage formuliert wird. Daraus ergibt sich dann ein Schlussereignis.

Die in der Prozessbeschreibung beschriebene Anfrage bei Partnerunternehmen als Kooperationspartner (KP) oder als Subunternehmer (SubU) wurde einfach als eine Aktivität modelliert, mit einem positiven und einem negativen Gesamtergebnis. Dies könnte, wenn es für die Prozessanalyse wichtig wäre, auch viel detaillierter realisiert werden. Zum Beispiel so, dass jede einzelne Anfrage bei einem potentiellen Partner als Funktion in einer Schleife erfasst würde. Die Schleife wäre erst dann fertig, wenn alle potentiellen Partner gefragt worden wären - mit einem positiven oder einem negativen Ergebnis.

Im Falle eines negativen Gesamtergebnisses wird die Anfrage wiederum abgelehnt und ein weiteres Schlussereignis tritt ein.

Abbildung 14.6-3: Angebotserstellung für Anlagen, Teil 2 - Prüfen Leistungsspektrum

Abkürzungen:

KP: Kooperationspartner

SubU: Subunternehmer

Enthaltene Elemente (Auswahl):

- Exclusive Gateway / datenbasiert und verknüpfend

- Exclusive Gateway / datenbasiert und verzweigend

- Schlussereignis

- Verknüpfungs-Zwischenereignis / abgebend

- Verknüpfungs-Zwischenereignis / empfangend

Im Geschäftsprozess bleiben somit aus den obigen Schritten zwei mögliche positive Ergebnisse, die beide den Fortgang zulassen. Im Sequenzfluss des BPDs müssen diese Zweige zusammengeführt werden. Dies geschieht durch ein verknüpfendes Exclusive Gateway (Pos. 3), getreu der Regel aus der allgemeinen Prozessmodellierung, dass Sequenzflüsse mit dem Operator zusammengeführt werden, mit dem flussaufwärts aufgeteilt wurde.

Die Verknüpfungs-Zwischenereignisse dienen der Klärung des Zusammenhangs zwischen den einzelnen Prozessfragmenten.

Prozessbeschreibung - Fortsetzung

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

Umsetzung in das BPD - Fortsetzung

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

  • Wenn beide Prüfungen positiv ausfallen geht es weiter im Geschäftsprozess, die Anfrage wird angenommen.
  • Ist die Kapazität der Ingenieurgruppe nicht ausreichend (Kapazität Ingenieure nicht vorhanden), wird die Anfrage abgelehnt, unabhängig davon, welches Ergebnis die Prüfung der Angebotslegungsfrist erbrachte.
  • Ist die Angebotslegungsfrist (ALF) nicht realisierbar und sind Kapazitäten vorhanden, wird um eine Fristverlängerung gebeten.

Es bleiben also drei mögliche Fortgänge übrig. Dies wird hier durch ein Complex Gateway modelliert (Pos. 4). Möglich wäre auch eine konventionelle Lösung mit parallelen Gateways nach dem Kombinatorikmuster (vgl. Abschnitt 12.5, eine ausführlichere Darstellung ist in [Staud 2014, Abschnitt 6.6]), aber für solche Situationen ist in der BPM das Complex Gateway geschaffen worden.

Anschließend werden die o.g. Aufgaben Anfrage annehmen, Absage und Bitte um Fristverlängerung eingefügt. Zum positiven Fortgang kommt es bei Annahme der Anfrage und auch, wenn die Fristverlängerung gewährt wird. Diese beiden Sequenzflüsse werden durch ein Exclusive Gateway verschmolzen.

Bleibt noch die Absage im Falle einer Nichtgewährung der Fristverlängerung und ein Schlussereignis.

Abbildung 14.6-4: Angebotserstellung für Anlagen, Teil 3 - Kapazitätsprüfung

Abkürzungen:

ALF: Angebotslegungsfrist

Enthaltene Elemente (Auswahl):

- Complex Gateway, verknüpfend

- Complex Gateway, verzweigend

- Datenobjekte am Sequenzfluss

- Exclusive Gateway / datenbasiert und verknüpfend

- None-Schlussereignis

- Parallel Gateway, verzweigend

- Verknüpfungs-Zwischenereignis / abgebend

- Verknüpfungs-Zwischenereignis / empfangend

Prozessbeschreibung - Fortsetzung

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

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

Das fertige Angebot wird durch den zuständigen Vertriebsingenieur dem Kunden zugeschickt.

Umsetzung in das BPD - Fortsetzung

Die Angebotserstellung ist im Text detailliert beschrieben mit all ihren Funktionalitäten. Ausführungen zu Stunden- und Kostenschätzungen usw. sind aber Funktionsaspekte und nicht Prozessaspekte und können deshalb bei einer Istanalyse des Prozesses ignoriert werden. Ihr Ausmodellieren würde die Beschreibung des Prozessflusses stören. Deshalb wird diese Beschreibung der Einzelfunktionen in einen (verborgenen) Subprozess gepackt. Die für die Angebotserstellung notwendigen Textdokumente werden an den zum Subprozess führenden Sequenzfluss angefügt (vorige Abbildung).

Die im Text etwas unklaren Angaben zu den zuständigen Personen werden durch eine textliche Anmerkung gelöst. Solche nicht ganz präzisen Angaben bei Zuständigkeiten kommen bei Istanalysen häufig vor.

Die nachfolgende Aktivität Angebotsdaten erfassen wird durch den Vertrieb realisiert. Dort werden die Angebotsdaten in eine Datenbank mit allen Angeboten, die im Unternehmen erstellt werden, eingetragen. Es entsteht das Datenobjekt Angebot in Datenbank. Aus diesem Datenbankeintrag heraus entsteht dann - automatisch - mit Hilfe eines Reportgenerators die textliche Fassung des Angebots (Textliches Angebot). Diese Aufgabe wird also von einem Programm durchgeführt, weshalb im Business Process Diagram (BPD) eine Aufgabe des Typs Dienst (Dienst-Aufgabe) gewählt wurde. Die Zusendung des fertigen Angebots wird durch eine Sender-Aufgabe und einen Nachrichtenfluss modelliert.

Abbildung 14.6-5: Angebotserstellung für Anlagen, Teil 4 - Angebot zum Kunden

Enthaltene Elemente (Auswahl):

- Datenobjekt (Erzeugung)

- Datenobjekt (lesend)

- Datenobjekt am Sequenzfluss

- Dienst-Aufgabe

- Nachrichtenfluss

- Sender-Aufgabe

- verborgener Subprozess

- Verknüpfungs-Zwischenereignis / abgebend

- Verknüpfungs-Zwischenereignis / empfangend

Prozessbeschreibung - Fortsetzung

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

Kommt es, entweder gleich oder nach den Vergabegesprächen, zu einer Ablehnung des Auftrags, bestätigt dies der zuständige Vertriebsingenieur. Er ist außerdem verpflichtet, durch Nachfragen beim Kunden oder sonstigen Verbindungsleuten die Gründe für die Absage in Erfahrung zu bringen, falls dies nicht schon aus dem Absageschreiben hervorgeht. Dies dient dazu, die Informationsbasis für zukünftige Angebote bei diesem Kunden zu verbessern.

Umsetzung in das BPD - Fortsetzung

Obiger Text beschreibt zuerst den Informationstransport (durch eine Aufgabe), der das Angebot zum Kunden bringt. Beim Kunden löst dies einen Entscheidungsprozess aus, der in seiner Grundform modelliert wurde, da eine nähere Beschreibung nicht vorliegt. Er ist im Becken des Kunden zu finden. Zu beachten ist hier die eventuelle Forderung nach Vergabegesprächen. Falls es zu diesen kommt, müssen nach der obigen Prozessbeschreibung der VBL und der VI miteinbezogen werden. Dies wurde durch jeweils eine Nachricht modelliert. Das gemeinsam geführte Gespräch wird - über die entsprechenden Bahnen hinweg - durch eine Gruppe (group) modelliert.

Falls die Prüfung beim Kunden gleich positiv verlief oder falls die Vergabegespräche einen positiven Abschluss fanden, kommt es zur Erteilung des Auftrags und zu einem Prozessende. Die beiden Sequenzflusszweige werden mit Hilfe eines Exclusive Gateway zusammengeführt.

Da das Unternehmen ja von der Auftragserteilung erfahren sollte, dies aber in der Prozessbeschreibung nicht näher ausgeführt wird, wurde eine entsprechende Nachricht zum Becken des Unternehmens eingefügt (mit einer Sender-Aufgabe).

Zu einer Absage durch den Kunden kommt es entweder gleich oder ebenfalls nach den Vergabegesprächen. Deshalb werden auch hier die entsprechenden Sequenzflusszweige mit einem Exclusive Gateway zusammengeführt und danach die Sender -Aufgabe Auftrag ablehnen eingefügt. Hier ist der Adressat der Nachricht in der Prozessbeschreibung angeführt, weshalb der Nachrichtenfluss zum Vertriebsingenieur geführt wird. Gemäß der Prozessbeschreibung wird im Falle einer Absage nicht nur die Absage bestätigt, was einfach durch eine Funktion geschieht, sondern auch u.U. nachgefragt. Die diesbezügliche Formulierung

"…falls dies nicht schon aus dem Absageschreiben hervorgeht"

kann dadurch umgesetzt werden, dass einfach eine entsprechende Prüfung ("Prüfen, ob Absage begründet"; Pos. 7) eingebaut wird.

Abbildung 14.6-6: Angebotserstellung für Anlagen, Teil 5 - Schluss

Enthaltene Elemente (Auswahl):

- Exclusive Gateway / datenbasiert und verknüpfend

- Exclusive Gateway / datenbasiert und verzweigend

- Gruppe

- Nachrichtenfluss

- None-Schlussereignis

- Sender-Aufgabe

- Verknüpfungs-Zwischenereignis / empfangend

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

Der Geschäftsprozess als Ganzes ("an einem Stück") ist auf meiner WebSite veröffentlicht: www.staud.info/grafiken2020/Grafiken.html.

14.7 Auftragsstart im Anlagenbau

Vorbemerkung: Die hier zugrundeliegende Prozessbeschreibung entspricht weitgehend einer realen ersten Prozessaufnahme. Sie wurde gekürzt und anonymisiert, aber nicht "geglättet", wie dies meist der Fall ist. Deshalb enthält sie Ablaufbeschreibungen auf unterschiedlichen Ebenen, für die Prozessmodellierung überflüssige Anmerkungen und unvollständige Angaben, v.a. bzgl. der Datenobjekte. Damit soll genau auf diese Probleme hingewiesen werden. Prozessbeschreibungen sind oft sehr unscharf bzw. lückenhaft. In einer realen Modellierungssituation würde dies bei der nächsten Projektbesprechung mit den Prozessverantwortlichen geklärt.

14.7.1 Der Prozess

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

Folgende handelnde Einheiten sind in diesem Geschäftsprozess präsent: Der Kunde, im Unternehmen der Vertriebsingenieur (VI), der Vertrieb, das Controlling, die Auftragsabwicklung und der Projektleiter. Entsprechend werden die Becken und Bahnen angelegt.

Um die Abbildung übersichtlich zu halten, werden folgende Abkürzungen verwendet:

  • AM für Auftragsmeldung
  • ASB für Auftragsstammblatt
  • ABS für Auftragsbestätigung

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

Prozessbeschreibung

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

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

Hat der Kunde nach drei Wochen noch nicht geantwortet, wird nachgefragt.

Umsetzung in das BPD

Um die Anzahl Bahnen übersichtlich zu halten, wird auf die Modellierung der Weiterleitung vom Zentralsekretariat zum Vertriebsingenieur (VI) verzichtet. Es wäre die einzige Stelle, an der das Zentralsekretariat (vgl. vorigen Abschnitt) gebraucht würde.

Die Anfangssequenz (vgl. die folgende Abbildung) besteht damit aus dem Nachrichten-Startereignis Auftrag. Die Übereinstimmungsprüfung (Prüfung auf Konditionen usw.; Position 1) wird zu einer Aufgabe, die vom Vertriebsingenieur realisiert wird. Für sie werden die zwei Datenobjekte Auftrag und Angebot benötigt. Die Entscheidungsfindung (In Ordnung, Abweichung) wird durch ein verzweigendes Exclusive Gateway (datenbasiert) modelliert. Ergibt die Prüfung keine Abweichungen wird die Auftragsbestätigung erstellt und der Geschäftsprozess schreitet voran zur Auftragsbearbeitung (Pos. 3).

Ergibt die Prüfung des Auftrags Abweichungen vom Angebot werden diese durch akzeptable Konditionen ersetzt. Dies führt zu einer entsprechenden Aufgabe des Vertriebsingenieurs mit dem Datenobjekt Auftrag, das verändert wird. Das Senden des veränderten Auftrags zum Kunden wird durch einen Nachrichtenverkehr ins Kundenbecken modelliert, wo dann der entsprechende Entscheidungsprozess stattfindet.

Für den Vertriebsingenieur (VI) ergibt sich eine Wartesituation, die durch ein ereignisbasiertes Exclusive Gateway modelliert wird (Pos. 2). Zwei Nachrichtenereignisse können zur Fortsetzung des Flusses führen: Eingang der Absage oder Eingang der Zusage (dass die Änderungen akzeptiert werden). Beide kommen vom Kunden, modelliert als empfangende Zwischenereignisse.

Kam eine Absage, wird die Auftragsannahme abgelehnt. Dies wird dem Kunden mitgeteilt, weshalb der Prozess indiesem Fall durch ein abgebendes Nachrichten-Schlussereignis endet.

Falls der Kunde die Ersetzung der Konditionen akzeptiert, wird der Sequenzfluss mit dem positiven Ergebnis der Prüfung zusammengeführt (Pos. 3). Das Verschmelzen der beiden Sequenzflüsse wird mit Hilfe eines Exclusive Gateway modelliert, da die Verzweigung flussaufwärts durch einen ebensolchen verursacht war.

Falls der Kunde nach drei Wochen noch nicht geantwortet hat, wird nachgefragt und wieder um Bestätigung gebeten. Dies wird durch einen Zeitgeber beim ereignisbasierten exklusiven Gateway, durch eine Aktivität Nachfragen und durch einen Rücksprung vor die Aktivität Kunde um Bestätigung bitten modelliert.

. Hier wurde auf das Einfügen des verknüpfenden datenbasierten Exclusive Gateways, das den ursprünglichen Sequenzfluss mit dem des Rücksprungs veknüpft, verzichtet. Zur Anschauung und zur Abschreckung. Diese "implizite" Realisierung von Gateways ist allerdings verbreitet, nicht nur in den Originalunterlagen der BPMN-Autoren.

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

Abkürzungen:

AM: Auftragsmeldung, ASB: Auftragsstsammblatt, ABS: Auftragsbestätigung

VI: Vertriebsingenieur, VBL: Vertriebsbereichsleiter

Enthaltene Elemente (Auswahl):

- Bahnen

- Becken

- Datenobjekt (lesend))

- Datenobjekt (verändernd))

- Exclusive Gateway / datenbasiert und verknüpfend

- Exclusive Gateway / datenbasiert und verzweigend

- Exclusive Gateway / ereignisbasiert und verzweigend

- Implizites verknüpfendes Exclusive Gateway

- Muster Rücksprung

- Nachrichtenfluss

- Nachrichten-Schlussereignis, abgebend

- Nachrichten-Startereignis

- Nachrichten-Zwischenereignis, empfangend

- Verknüpfungs-Zwischenereignis / abgebend

- Verknüpfungs-Zwischenereignis / empfangend

- Zeitgeber

Prozessbeschreibung - Fortsetzung

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

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

Umsetzung in das BPD - Fortsetzung

Vorstehender Text signalisiert, dass im positiven Fortgang des Geschäftsprozesses zwei Aktivitäten angestoßen werden. Entsprechend wurde dies mit einem Parallel Gateway modelliert (Pos. 4). Die erste wird vom VI, die zweite durch die Abteilung Vertrieb realisiert. Beide beschreiben das Datenobjekt Auftragsstammblatt (ASB). Für dieses wird hier angenommen, dass es von zwei verschiedenen Personen gleichzeitig bearbeitet werden kann.

Danach können die beiden Sequenzflusszweige wieder zusammengeführt werden (verknüpfendes Parallel Gateway). Dies ist ein anschauliches Beispiel für das Muster Zeitfenster. Anschließend folgt die im obigen Text angeführte Erfassung der Kostenstruktur durch die Organisationseinheit Controlling. Hier ist im Text wiederum auch die konkrete (innere, funktionale) Realisierung der Aktivität angedeutet. Der Prozessanteil besteht hier nur aus einem verborgenen Subprozess (Kostenstruktur eintragen). Genauer werden dann die Tätigkeiten im zugehörigen entfalteten Subprozess beschrieben (vgl. unten).

Ein solches Muster muss man erkennen, wenn man eine Prozessbeschreibung bekommt: Was ist Prozess-, was ist Funktionsbeschreibung? Vgl. hierzu auch Abschnitt 12.2 und ein weiteres Beispiel gleich hier im nächsten Abschnitt der Prozessbeschreibung.

Prozessbeschreibung - Fortsetzung

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

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

Umsetzung in das BPD - Fortsetzung

In obigem Text ist wiederum zweierlei vermerkt. Zum einen ein betriebswirtschaftlicher Vorgang, die Erstellung der Stundenvorgabe, zum anderen ein Regelwerk zur Bestimmung der Stundenvorgabe. Dies ist nichts anderes als die Beschreibung der inneren Abläufe der Aufgabe. Wir haben es hier also wieder und viel deutlicher als oben mit dem Gegensatz von Prozess- und Funktionsmodellierung zu tun.

Prozessmodellierung vs. Funktionsmodellierung

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

Unter Beachtung dieser Regel entsteht hier für die Erstellung der Stundenvorgabe ein einziger verborgener Subprozess. Das Regelwerk (die Funktionsbeschreibung) kann in einem entfalteten Subprozess dargestellt werden. Vgl. dazu unten.

Prozessbeschreibung - Fortsetzung

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

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

Umsetzung in das BPD - Fortsetzung

Die konkrete Ermittlung der Rechnungsstellungstermine wird in den Subprozess verlagert. Im übergeordneten Prozess geht es weiter mit zwei "parallel" anzustoßenden Aktivitäten, Zahlungstermine mitteilen (als Sender-Aufgabe) durch den Vertrieb und Anlage Auftrag im PPS (als Nutzer-Aufgabe) durch das Controlling. Hierfür wird wieder ein Parallel Gateway verwendet (Pos. 5).

Abbildung 14.7-2: Auftragsstart im Anlagenbau, Teil 2 - Planen und Erfassen

Enthaltene Elemente (Auswahl) und Muster:

- Datenobjekt (lesend))

- Datenobjekt (verändernd))

- Exclusive Gateway / datenbasiert und verzweigend

- Muster Teilaufgaben

- Muster Zeitfenster

- Nutzer-Aufgabe

- Parallel Gateway, verknüpfend

- Parallel Gateway, verzweigend

- Sender-Aufgabe

- Subprozess, verborgen

- Verknüpfungs-Zwischenereignis / abgebend

- Verknüpfungs-Zwischenereignis / empfangend

Besondere Theorieaspekte:

- Prozess- vs. Funktionsmodellierung

- Start paralleler Teilaufgaben

Zu den Subprozessen vgl. Abschnitt 14.7.2.

Prozessbeschreibung - Fortsetzung

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

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

Umsetzung in das BPD - Fortsetzung

Der erste Absatz oben erfordert drei Aktivitäten: die Vervollständigung des Auftragsstammblatts (ASB) durch die Auftragsabwicklung, die Weiterleitung zum Vertrieb und die Erstellung der Auftragsmeldung durch den Vertrieb. Transportvorgänge können in der Prozessmodellierung ausdrücklich eingefügt, weggelassen oder mit der "benachbarten" Aktivität zusammengefast werden (Aggregation). Hier wurde diesmal Letzteres gewählt. Aus der Aktivität Vervollständigung ASB wurde Vervollständigung ASB und Weiterleitung. Die Datenobjekte wurden entsprechend (erzeugend; lesend; am Sequenzfluss) eingefügt.

Der zweite obige Absatz fordert zwei parallel [Anmerkung] anzustoßende Funktionen. Der Vertrieb realisiert Auftragsmeldung (AM) mit Anlagen archivieren, das Controlling Kopien zumTechnikbereich geben. Mit den nachfolgenden Schlussereignissen kommen diese Zweige an ihr Ende, der Geschäftsprozess geht aber - begründet durch das aufteilende Parallel Gateway - noch weiter.

Prozessbeschreibung - Fortsetzung

Parallel zur internen Meldung über die Vervollständigung des Auftragsstammblatts hat der Vertriebsingenieur die externe Auftragsbestätigung an den Kunden zu erstellen. In dieser werden auch die zuständigen technischen Ansprechpartner und der Projektleiter vermerkt.

Erfolgte der Auftrag schriftlich und hat der Auftraggeber bereits eine Auftragsbestätigung mitgeschickt, wird diese unterschrieben zurückgesandt.

Erfolgte die Beauftragung mündlich, wird die externe Auftragsbestätig um sämtliche besprochenen Konditionen ergänzt, dem Kunden zugesandt und um schriftliche Bestätigung gebeten. Die Reaktion des Kunden wird in der Kundendatenbank (Kunden-DB) vermerkt.

Ansonsten wird die externe Auftragsbestätigung zugeschickt.

Umsetzung in das BPD - Fortsetzung

Obiger Text führt nun zurück zur Position 6. Dort muss diese Erstellung der externen Meldung "parallel" zur Vervollständigung des Auftragsstammblatts eingefügt werden. Dies wurde mit einem Parallel Gateway realisiert. Danach wurde die Aktivität Klärung Auftragsvergabe eingefügt (Pos. 7). Sie wird vom Vertriebsingenieur realisiert. Diese Prüfung kann zu drei Ergebnissen führen, entsprechend wurden drei Aktivitäten eingefügt:

  • Schriftlich mit Auftragsbestätigung, d.h. der Kunde hat gleich bei der Auftragsvergabe die Auftragsbestätigung mitgeschickt. In diesem Fall wird einfach die ABS zum Kunden geschickt, modelliert durch eine Sender-Aufgabe.
  • Mündlich. Danach wird die Ergänzung der Auftragsbestätigung als Aufgabe eingefügt.
  • Sonstige ("auf andere Weise"). Dies soll auch die Voreinstellung sein. Die nachfolgende Sender-Aufgabe erfasst das finale Erstellen und Versenden der externen ABS.

Alle drei Sequenzflüsse führen weiter zur nächsten Abbildung. Für die Verbindung der beiden Prozessfragmente wurden wieder abgebende Verknüpfungs-Zwischenereignisse genutzt.

Abbildung 14.7-3: Auftragsstart im Anlagenbau, Teil 3 - Bearbeiten Auftragsdaten

Enthaltene Elemente (Auswahl):

- Datenobjekt (Erzeugung)

- Datenobjekt (lesend))

- Datenobjekt (verändernd)

- Datenobjekt am Sequenzfluss

- Exclusive Gateway / datenbasiert und verzweigend

- Nachrichtenfluss

- None-Schlussereignis

- Parallel Gateway, verzweigend

- Sender-Aufgabe

- Verknüpfungs-Zwischenereignis / abgebend

- Verknüpfungs-Zwischenereignis / empfangend

- Voreinstellung bzgl Sequenzfluss

Besondere Theorieaspekte:

- Aggregation

Prozessbeschreibung - Fortsetzung

Der Projektleiter setzt sich dann mit dem Kunden in Verbindung, um die Arbeitsaufnahme zu besprechen.

Die folgende Abbildung zeigt die Fortsetzung der Sequenzflüsse. Im Falle der mündlichen Vereinbarung erfolgt die Zusendung der Externen ABS zum Kunden. Danach werden alle drei Sequenzflüsse (D, C, E) mit Hilfe eines verknüpfenden datenbasierten Exclusive Gateways wieder zusammengeführt.

Beim Kunden wurde der Empfang der Externen ABS durch eine Empfänger-Nachricht modelliert. Der Prozessablauf kann durch einen Entscheidungsprozess (Änderungen prüfen; Pos. 8) und zwei Sender-Aufgaben (Zustimmen, Ablehnen) modelliert werden. Da hier die textliche Beschreibung lückenhaft ist, wurde die Zustimmung als Nachricht an den Vertrieb und die Ablehnung als Nachricht an den VI modelliert. An Pos. 9 kommen dann alle "positiven" Sequenzflüsse zusammen: von ABS unterschrieben zurücksenden, Externe ABS zusenden (vgl. die vorangehende Abbildung) und der zustimmenden Nachricht durch den Kunden. Im Falle der Ablehnung durch den Kunden wird nach der Entgegennahme der Ablehnung ein Schlussereignis modelliert (Pos. 10).

Abschließend wird, wie in der Prozessbeschreibung gefordert, die Besprechung der Arbeitsaufnahme mit dem Kunden (durch den Projektleiter) und ein Schlussereignis angefügt.

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

Abkürzungen:

Ext. ABS: Externe Auftragsbestätigung

Enthaltene Elemente (Auswahl):

- Empfänger-Aufgabe

- Exclusive Gateway / datenbasiert und verknüpfend

- Exclusive Gateway / datenbasiert und verzweigend

- Nachrichtenfluss

- None-Schlussereignis

- Sender-Aufgabe

- Startereignis

- Verknüpfungs-Zwischenereignis / empfangend

14.7.2 Die Subprozesse

In Abbildung 14.7-2 sind die verborgenen Subprozesse

  • Kostenstruktur eintragen
  • Stundenvorgabe erstellen und
  • Rechnungsstellungstermine ermitteln

in den Prozess eingefügt. Sie erfassen jeweils Aufgaben, die durch Beschreibung ihrer inneren Struktur näher spezifiziert werden. Aus dem Subprozess Stundenvorgabe erstellen werden noch die Subprozesse Kostensätze bestimmen und Stundenvorgabe berechnen aufgerufen. Damit ergibt sich die in der folgenden Abbildung angegebene Aufrufstruktur.

Abbildung 14.7-5: Alle verborgenen Subprozesse des Geschäftsprozesses und ihre Aufrufstruktur

Diese Aufteilung in Subprozesse folgt teilweise didaktischen Anforderungen. Durch sie soll die Trennung der Modellierung von Funktionen und Prozessen deutlich gemacht werden.

(1) Kostenstruktur eintragen

Die folgende Abbildung zeigt die entfaltete Fassung des Subprozesses Kostenstruktur eintragen. Das Startereignis des Subprozesses wird ausgelöst, wenn der zum Subprozess führende Sequenzfluss aktiv wird ("das Token ankommt").

Auszug aus der oben angeführten Prozessbeschreibung:

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

Die folgende Abbildung zeigt den entfalteten Subprozess.

Abbildung 14.7-6: Prozess Auftragsstart im Anlagenbau, Subprozess Kostenstruktur eintragen

Methodenelemente (Auswahl):

- Datenobjekt (lesend))

- Datenobjekt (verändernd)

- Schlussereignis

- Startereignis

- Subprozess, entfaltet

(2) Stundenvorgabe erstellen

Die Erstellung der Stundenvorgabe wurde im Prozess oben als verborgener Subprozess modelliert. Hier nun der entfaltete Subprozess. Die textliche Beschreibung ist hier um Anmerkungen ergänzt:

Das Controlling erstellt eine Stundenvorgabe für den Projektleiter, die sich folgendermaßen errechnet: Vom beauftragten Honorar [1. Aufgabe] werden zunächst die Fremdleistungen und die geplanten Sachkosten (Reisekosten, Kopierkosten etc.) abgezogen [2. Aufgabe]. Nach Abzug eines Gewinns und einer Sicherheitsmarge in Höhe von ca. 15% ergeben sich die verfügbaren Personalkosten [3. Aufgabe]. Diese werden durch den Kostensatz der jeweiligen Mitarbeitergruppe geteilt [4. Aufgabe]. So ergibt sich die Stundenvorgabe je Mitarbeitergruppe [5. Aufgabe].

Der erste Satz gibt sozusagen die verborgene Variante des Subprozesses wieder, der Text danach die entfaltete. Die Ausführungen wurden in Aufgaben und beteiligte Datenobjekte abgebildet.

Abbildung 14.7-7: Prozess Auftragsstart im Anlagenbau, Subprozess Stundenvorgabe für Projektleiter erstellen

Methodenelemente (Auswahl):

- Datenobjekt (lesend))

- Datenobjekt (verändernd)

- Schlussereignis

- Startereignis

- Subprozess, entfaltet

- Subprozess, verborgen

Für die Bestimmung der Kostensätze, die ja sehr detailliert beschrieben wird, wurde ein weiterer Subprozess Kostenstundensätze bestimmen angelegt.

Prozessbeschreibung:

Alle Ingenieure im Haus sind nach den Jahren ihrer Berufserfahrung unterschiedlichen Gruppen zugeordnet. Jede Gruppe wird zu einem bestimmten Erlösstundensatz abgerechnet bzw. Kostenstundensatz belastet. Ebenso werden Sekretärinnen, studentische Hilfskräfte, Übersetzer, Technische Zeichner usw. mit bestimmten Kostensätzen eingerechnet.

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

Es wurde angenommen, dass diese Bestimmung der Kostenstundensätze schrittweise nacheinander für die Beschäftigten erfolgt, deshalb die Rückschleife und am Ende die Prüfung, ob schon alle bearbeitet sind.

Die erste Aufgabe klärt, ob nach einem Erlösstundensatz abgerechnet wird oder mit einem Kostenstundensatz belastet wird. Es wird angenommen, dass dies jeweils in einem Dokument (hier als Datenobjekt modelliert) festgehalten wird. Falls es um einen Erlösstundensatz geht, wird die Aufgabe Erlösstundensatz klären ausgeführt. Geht es um Kostenstundensätze werden nacheinander die drei Kostensatz-Stufen bestimmt. Danach werden die beiden Sequenzflüsse wieder mit einem Exclusive Gateway zusammengeführt. Die nachfolgende Prüfung führt entweder zum Schluss des Subprozesses und damit zum Rücksprung in den aufrufenden Prozess oder zurück an den Anfang (Rücksprung), um die nächste Person einzuarbeiten.

Die Datenobjekte sind in der Prozessbeschreibung nicht präzise ausgeführt. Sie wurden hier, soweit es möglich war, eingefügt. Zum einen als Datenobjekte, die gelesen werden (Gehaltsangaben, Gemeinkosten, …), zum anderen als zu beschreibende (Kalkulation). In einer realen Modellierungssituation müsste dies durch Nachfragen geklärt werden.

(3) Kostenstundensätze bestimmen

Abbildung 14.7-8: Prozess Auftragsstart im Anlagenbau, Subprozess Kostenstundensätze bestimmen

Enthaltene Elemente (Auswahl):

- Datenobjekt (lesend))

- Datenobjekt (verändernd)

- Exclusive Gateway / datenbasiert und verknüpfend

- Exclusive Gateway / datenbasiert und verzweigend

- Muster Rücksprung

- Schlussereignis

- Startereignis

- Subprozess, entfaltet

(4) Rechnungsstellungstermine ermitteln

Bleibt noch der vierte Subprozess, der die Ermittlung der Rechnungsstellungstermine beschreibt. Zuerst wieder die Prozessbeschreibung von oben:

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

Hier muss auch wieder an den Beginn eine Entscheidung gesetzt werden, die per Exclusive Gateway entweder zur Berechnung des Honorars nach Aufwand oder zu den Pauschalaufträgen führt. Im ersten Fall wird dann der Abrechnungsmodus vermerkt, im zweiten Fall werden zuerst die Projektmeilensteine geklärt und dann die abzurechnenden Beträge bzw. Prozentanteile vermerkt. In beiden Fällen folgt anschließend ein Schlussereignis, das den Sequenzfluss zurück in den aufrufenden Prozess führt. Die Beschreibung der Datentransfers ist auch wieder lückenhaft, sie müsste in einer realen Modellierungssituation nachgefragt werden.

Abbildung 14.7-9: Prozess Auftragsstart im Anlagenbau, Subprozess Rechnungsstellungstermine ermitteln

Enthaltene Elemente (Auswahl):

- Datenobjekt (lesend))

- Datenobjekt (verändernd)

- Exclusive Gateway / datenbasiert und verzweigend

- Schlussereignis

- Startereignis

- Subprozess, entfaltet

 

Der Geschäftsprozess als Ganzes ("an einem Stück") ist hier veröffentlicht: http://www.staud.info/grafiken2020/Grafiken.html

 

15 Glossar

AAA

Ablauforganisation

„Unter Ablauforganisation versteht man die Gestaltung von Arbeitsprozessen. ... Man unterscheidet

(1) die Ordnung des Arbeitsinhalts,

(2) die Ordnung der Arbeitszeit,

(3) die Ordnung des Arbeitsraumes,

(4) die Arbeitszuordnung“ [Wöhe 1993, S. 196].

Aufbauorganisation

Mit Aufbauorganisation ist die Zerlegung der Gesamtaufgabe einer Organisation in Teilaufgaben angesprochen. Die Zerlegung muss so erfolgen, dass ein effektives Zusammenwirken bei der Abwicklung konkreter Geschäftsprozesse möglich ist. Mit diesem Begriff bezeichnet man die entstehende Organisationsstruktur als solche wie auch die Tätigkeit des Organisierens selbst:

„Erste Aufgabe der Aufbauorganisation (wenn wir sie als Tätigkeit des Organisierens verstehen) ist also die Analyse und Zerlegung der Gesamtaufgabe des Betriebes (Aufgabenanalyse). Die zweite Aufgabe besteht dann darin, die Einzelaufgaben zusammenzufassen, indem „Stellen“ gebildet werden (Aufgabensynthese), wobei sich aus der Aufgabenstellung Beziehungszusammenhänge zwischen diesen Stellen ergeben“ [Wöhe 1993, S. 183].

BBB

Bewegungsdaten

„Die Bewegungsdaten lassen sich in Transferdaten, die Vormerkdaten und die Archivdaten untergliedern. ... Transferdatenbestände enthalten solche Daten, die von einem Programm generiert oder bearbeitet wurden und nun einem anderen geliefert werden. ..." [Mertens 2013, S. 40]

„Bewegungsdaten sind Daten mit einem zeitlichen Bezug. Sie dienen der chronologischen Speicherung aller Vorgänge und entstehen im Verlauf der Geschäftsprozesse. Typische Bewegungsdaten sind die Kundenaufträge, die Bestellungen oder die Fertigungsaufträge. Inhalte von Bewegungsdaten können Plan- oder Istdaten sein.“ [Hohmann 1999, S. 92f]

Siehe auch: Stammdaten

Business Process Engine

Eine Business Process Engineist eine Anwendung, die Geschäftsprozesse ausführt. Dazu gehört, dass die Prozesse ausreichend exakt in einer formalen Sprache modelliert sind, so dass dem Programm die Ausführung möglich ist. Sie funktioniert also typischerweis ewie ein Interpreter.

Beispiele sind "web service-based XML execution languages for Business Process Management (BPM) systems" mit Sprachen wie BPEL4WS. Die Lücke zwischen dem Format der ersten Entwürfe von Geschäftsprozessen und dem Format von solchen formalen Sprachen soll mit der BPMN überbrückt werden. Sie erlaubt eine "geeignete Visualisierung der Prozesse" auf ein geeignetes "execution format" (eine "BPM execution language") abzubilden [OMG 2009, S. 11] (siehe auch Abschnitt 1.3).

CCC

Computer Integrated Manufacturing (CIM)

CIM bezeichnet eine sehr enge Abstimmung von betriebswirtschaftlicher und technischer Informationsverarbeitung im Fertigungssektor, berücksichtigt aber auch Produkt- und Prozessentwicklung, Vertrieb, Versand und Rechnungswesen. Ziel ist die Integration aller fertigungstechnischen Arbeitsabläufe sowie aller betriebswirtschaftlich-organisatorischen Dispositions- und Steuerungsaufgaben.

Customer Relationship Management (CRM)

Customer Relationship Management (Kundenbeziehungsmanagement, CRM). CRM betrifft Informations- und Kommunikationssysteme (IKS) für die Pflege und Durchführung von Kundenkontakten sowie die Frage der Integration dieser Software in das sonstige IKS des Unternehmens. Ausgangspunkt für diese Überlegungen ist somit der Kunde bzw. der Kontakt mit ihm.

EEE

Ereignisraum, informationelle Umwelt

Bei einer Methode, die so stark auf Ereignisse setzt, wie die BPMN, ist es wichtig genau zu klären, durch wen eintretende Ereignisse empfangen werden können.

Bei allen empfangenden und abgebenden Ereignissen ist die Vorstellung die, dass etwas im Prozessablauf passiert, was die Ereignisse auslöst.

Signale: Eine besondere Rolle haben Signale. Sie sind Auslöser (trigger), die in dem Pool erzeugt wurden, in dem sie publiziert werden. Typischerweise wirken sie in einem Prozess, über Prozesse hinweg, zwischen Becken und zwischen Prozessdiagrammen [OMG 2011, S. 234].

Fehler: Die grundsätzliche Vorstellung der BPMN-Autoren ist diesbezüglich so, dass die Fehlermeldung von demjenigen Fehler-Zwischenereignis empfangen wird, das auf der Grenzlinie der am nahesten liegenden umfassenden Elternaktivität liegt.

Eskalationen: Die Eskalation wird von dem empfangenden Eskalations-Zwischenereignis erkannt und verarbeitet, das auf der Grenzlinie der nahesten Elternaktivität liegt.

ERP-Software

ERP steht für Enterprise Resource Planning. Mit ERP-Software ist integrierte prozessorientierte Standardsoftware gemeint, die meist auf einer integrierten Hardware (mit Client-Server-Architektur) betrieben wird. Sie deckt in der Regel den gesamten Bereich der kaufmännischen Anwendungen ab (also z.B. Personal, Finanzen, Rechnungswesen, Logistik, Transport, Produktionsplanung usw.) und in diesen auch die Anforderungen der unteren und mittleren Managementebenen.

Eine ERP-Software ist somit eine umfassende betriebliche Anwendungssoftware. Sie ist prozessorientiert, d.h. sie unterstützt ganze Geschäftsprozesse, nicht nur einzelne Funktionen. Sie ist Standardsoftware, d.h. für den Einsatz in vielen Unternehmen (auch unterschiedlicher Branchen) geeignet, da sie betriebliche Funktionen sowie die Abwicklung und Unterstützung von Geschäftsprozessen standardisiert.

GGG

Geschäftsobjekte

In Zusammenhang mit Geschäftsprozessen spricht man auch von Geschäftsobjekten (Business Objects). Damit sind betriebswirtschaftlich relevante Objekte gemeint. Es handelt sich immer um Informationsträger mit Eigenschaften (Attributen) und einem Verhalten (bzw. zulässigen Veränderungen), beispielsweise um Rechnungen mit Attributen, wie Rechnungsnummer, Rechnungsdatum, Rechnungsempfänger usw., die bezahlt oder storniert werden können.

Graph, Graphentheorie

Für die Beschreibung im Rahmen des Kontrollflusses benutzen auch die UML-Autoren Begriffe der Graphentheorie. Hier vor allem zwei:

  • Kanten / edges
  • Knoten / nodes

Ein Graph besteht aus Knoten, die durch Kanten verknüpft sind (vgl. zur Graphentheorie [Kastens und Büning 2008, Kapitel 5]). In der BPM sind die Kanten entlang der Kontrollflüsse gerichtet, so dass es sich um gerichtete Graphen handelt.

III

Istanalyse

Detaillierte Bestandsaufnahme der bestehenden Prozesse für unterschiedliche Zwecke (Optimierung, Qualitätsmanagement, Vorbereitung der Einführung einer ERP-Software, …).

KKK

Kernkompetenz

Der Begriff Kernkompetenz ist verbunden mit dem der (->)Kerngeschäftsprozesse. Damit sind die besonderen Fähigkeiten gemeint, durch die Kernprozesse realisiert werden. Kernkompetenzen liegen bei den einzelnen Mitarbeitern vor und entstehen durch das Zusammenwirken von Mitarbeitern (in Abteilungen, Projekten oder sonst wie).

Die Kernkompetenzen eines Unternehmens sind seine gesamten, als wettbewerbsentscheidend erachteten Fähigkeiten.

Kern(geschäfts)prozesse, Supportprozesse

Einige Geschäftsprozesse spielen eine besondere Rolle im Unternehmen. Es sind zentrale Prozesse, mit denen die Hauptleistung erbracht wird, in die die meisten Ressourcen einfließen und mithilfe derer die eigentliche (->)Wertschöpfung erfolgt. Sie werden Kernprozesse genannt. Alle übrigen werden als unterstützende Prozesse bzw. (->)Supportprozesse bezeichnet. Sie sind nicht direkt wertschöpfend, aber notwendig, um die Kernprozesse ausführen zu können. Die Bezeichnung ist nicht abwertend gemeint. Ohne Supportprozesse gibt es keine Kernprozesse.

Definitionen

Für das Thema Prozessmodellierung ist diese Unterscheidung wichtig, weil man Kernprozesse mit mehr Aufwand pflegt, optimiert und auch modelliert.

Einige Beispiele für Kernprozesse:

  • Für Dienstleistungsunternehmen im Transportbereich ist die eigentliche Transportleistung von Menschen und Gütern ein Kernprozess.
  • Für eine Messegesellschaft gehört die Organisation von Messeveranstaltungen, der technische Betrieb eines Messezentrums, der Einkauf von Dienstleistungen und u.U. der Verkauf von Messestandflächen an Aussteller zu den Kernprozessen. Ein unterstützender Prozess ist die Abrechnung von Messeveranstaltungen.
  • In einem Steuerbüro gehört die Erstellung der Finanzbuchhaltungen, der Jahresabschlüsse, der Steuererklärungen und Lohnabrechnungen zu den Kernprozessen (je nach Ausrichtung der Geschäftstätigkeit). Ein Beispiel für einen unterstützenden Prozess ist die Neumandantenwerbung.
  • In einem Handelshaus gehören die Auftragsabwicklung und die Einkaufsabwicklung (Qualität, Preis, ...) zu den Kernkompetenzen. Unterstützende Prozesse sind hier z.B. die Qualitätskontrolle, der Kundenservice, das Personalwesen, das Mahnwesen und die Kundenaquisition.
  • In einem Softwarehaus gehört die Entwicklung (Systemanalyse, Systemdesign, Programmierung) und der adäquate Einsatz von Methoden und Werkzeugen zu den Kernkompetenzen.
  • Bei einem Hersteller „einfacher“ Produkte, die auch von anderen leicht hergestellt werden können, gehören unter Umständen die Geschäftsprozesse des Marketing zu den Kernprozessen.

Wenn etwas mehr die Ausrichtung zum Kunden betont werden soll, kommt man zu folgender Definition [Steinbuch 1998, S. 33]: Kernprozesse sind kundennahe und/oder wertschöpfungsintensive Geschäftsprozesse.

LLL

Lifecycle Management , Product Lifecycle Management (LCM, PLM)

Lifecycle Management (LCM). „Lifecycle“ meint hier den Produktlebenszyklus, also alle Phasen, die ein Produkt im Lauf seiner Existenz erlebt (deshalb auch häufig: Product Lifecycle Management, PLM). Ausgangspunkt für LCM ist die Vorstellung, alle diese Phasen integriert durch entsprechende Informationssysteme zu begleiten, d.h. alle im Produktlebenszyklus anfallenden Arbeits- bzw. Prozessschritte zu integrieren:

  • erste Anfrage durch den Kunden,
  • Angebotserstellung,
  • Produktentwicklung,
  • Produktion,
  • Betriebsphase beim Kunden,
  • Entsorgung.

Integriert werden sollen vor allem die Informationskreisläufe bzw. die Informationsbestände.

MMM

Modelle, Modellierung

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

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

Der dritte Grund für Modellbildung sei hier nicht thematisiert. Er betrifft die grundsätzliche Struktur der menschlichen Wahrnehmung, die ohne Modellbildung im elementaren Sinn gar nicht auskommt.

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

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

NNN

Nebenläufigkeit

„Haben zwei Aufgaben weder eine direkte noch eine indirekte Verbindung, so sind sie nebenläufig, d.h., sie können nacheinander oder nebeneinander ablaufen.“ [Österle 1995, S. 95]

„Die Ablauffolge beschreibt, ob eine Aufgabe nach einer anderen Aufgabe (Präzedenz), gleichzeitig mit ihr (Parallelität) oder unabhängig von ihr (Nebenläufigkeit) ablaufen soll.“ [Österle 1995, S. 51]

OOO

Organisationseinheit

Eine Organisationseinheit ist eine Zusammenfassung von einer oder mehreren Stellen zu einem selbständigen Teil der Organisationsstruktur eines Unternehmens.

PPP

Porter

Das Denken in Geschäftsprozessen hat viele Urheber, schließlich basiert es letztlich auf den Konzepten, die bei der Analyse der Ablauforganisation entwickelt wurden. Einer zählt mit Sicherheit dazu, Porter mit seinem Wertkettenmodell:

„Als eine wesentliche theoretische Basis des Prozessdenkens gilt das von Porter entwickelte Wertkettenmodell, welches aufgrund der Segmentierung der Unternehmensaktivitäten in primäre, direkt wertschöpfende und sekundäre, unterstützende Aktivitäten die These erlaubt, dass Unternehmen durch die geschickte Kombination und Gestaltung der Prozesse auf allen Unternehmensebenen Wettbewerbsvorteile gegenüber ihren Konkurrenten erwerben können“ [Franz 1996, S. 210].

Proprietäre Systeme

Damit sind Systeme der IT gemeint, bei denen die herstellenden Unternehmen die Architektur ihrer Hardware und/oder Software geheim halten. Auch die der Schnittstellen. Dies macht die Integration der einzelnen Aufgaben in Richtung Prozessfluss sehr schwierig. Mehr noch gilt dies für die Verknüpfung der Geschäftsprozesse verschiedener Unternehmen. Proprietäre Systeme sind heute ein Relikt der IT-Vergangenheit. Heute liegen in der Regel offene Schnittstellen und Architekturen vor.

RRR

Referenzmodelle

Im Bereich der Betriebswirtschaftlichen Standardsoftware oder ERP-Software ist damit ein abstraktes (nicht auf ein bestimmtes Unternehmen bezogenes) Modell der Unternehmensrealität gemeint. Dabei werden heute, in Anlehnung an Scheer’s Arbeiten, Modelle bzgl. der Datenbanken, der Organisationsstrukturen, der Funktionen (Tätigkeiten) und der Geschäftsprozesse unterschieden. Hier ist dann auch von Unternehmensmodellierung die Rede.

Eine Diskussion des Begriffs auf dem allgemeinen Hintergrund der Gestaltung Integrierter Informationssysteme mit weiteren Literaturhinweisen findet sich bei [Hohmann 1999, S. 56ff].

SSS

Sollmodellierung, Sollprozesse

Aufbauend auf der Istmodellierung und den dabei entdeckten Schwachstellen (und weiterer Schwachstellenanalysen) kann die Erstellung von Prozessmodellen erfolgen, in denen die Schwachstellen beseitigt sind. Dies wird Sollmodellierung genannt, die dabei entstehenden Geschäftsprozesse heißen Sollprozesse.

Stammdaten

Stammdaten sind Teil der Datenbestände (betriebswirtschaftliche und technische), die ein Unternehmen zur informationellen Absicherung benötigt, und zwar der Teil, der nur in Ausnahmefällen verändert wird.

„Die wichtigsten Stammdaten einer integrierten IV sind: Kunden, Lieferanten von Erzeugnissen und Dienstleistungen ..., Teile - unter dieser Bezeichnung sollen Roh-, Hilfs- und Betriebsstoffe sowie Halb- und Fertigfabrikate zusammengefaßt werden -, Stücklisten ..., Arbeitspläne ...., Betriebsmittel, Kostenstellen und Personal.“ [Mertens 2013, S. 40]

„Stammdaten unterliegen selten Veränderungen und bilden die Basis von Integrierten Systemen. Stammdaten sind zustandsorientierte Daten, die der Identifizierung, Klassifizierung und Charakterisierung von Objekten (Sachverhalten) dienen und die über einen längeren Zeitraum hinweg unverändert zur Verfügung stehen. Typische Stammdaten sind Kundenstamm, Lieferantenstamm, Preis- und Konditionenstamm, Artikelstamm, Stücklisten, Arbeitspläne, Kostenstellen usw.“ [Hohmann 1999, S. 92]

s.a. Bewegungsdaten

Stellen

Stellen sind die kleinsten organisatorischen Einheiten im Unternehmen.

Supply Chain Management (SCM)

Supply Chain Management (SCM). SCM betrifft die Informationssysteme, mit deren Hilfe die logistischen Versorgungsketten über Unternehmensgrenzen hinweg erfasst und integriert werden sollen. Ausgangspunkt ist hier die Leistungserbringung.

Supportprozesse

siehe Kern(geschäfts)prozesse

VVV

Vorgehensmodelle

[Bullinger und Fähnrich 1997, S. 11] definieren wie folgt: „Vorgehensmodelle legen für die Aktivitäten, die im Rahmen der Tätigkeit softwareproduzierender Einheiten (SPEs) notwendig sind, deren wechselseitige Beziehungen fest und geben vorgeschriebene Reihenfolgen an.“ Sie bringen auch gleich ein Beispiel: „Das Wasserfallmodell ist das bekannteste Modell zur Softwareentwicklung; es bildet den gesamten Lebenszyklus einer Software durch sequentielle Unterteilung in Phasen ab.“

Im Umfeld von ERP-Software wird ebenfalls von Vorgehensmodellen gesprochen, im Sinne von Vorschlag für das Vorgehen bei der Einführung. Bekanntestes Beispiel ist das Vorgehensmodell der SAP für die Einführung ihrer jeweiligen prozessorientierten integrierten Software.

WWW

Wertschöpfung

Eigentlich bedeutet Wertschöpfung: „Beitrag, den ein Unternehmen zum Bruttoinlandsprodukt beiträgt“ [Schneck 1998, S. 779].

Die Betriebswirtschaftslehre versteht unter Wertschöpfung das Betriebsergebnis abzüglich externer Vorleistungen [Stahlknecht 1995, S. 235]. Steinbuch definiert wie folgt: „Wertschöpfung wird üblicherweise als Differenz von Betriebsertrag und Vorleistungen definiert.“ Er führt die Definition des Verband Deutscher Maschinenbauanstalten (VDMA) an: Wertschöpfung = Betriebsertrag - Vorleistungen [Steinbuch 1998, S. 33]. Im Zusammenhang dieser Arbeit ist der Begriff von Bedeutung für das Konzept der Wertschöpfungskette.

Wertschöpfungskette

Der Begriff Wertkette oder Wertschöpfungskette (value chain) geht auf Porter zurück (vgl. [Porter 1985], [Porter 1998]). Die Wertschöpfungskette besteht aus neun Firmenaktivitäten, die zur Herstellung und Wertsteigerung eines Produkts beitragen (einschließlich der Realisierung einer Gewinnspanne). Grob sind die Firmenaktivitäten unterteilt in ausführende Aktivitäten (auch primäre genannt), die direkt mit Herstellung, Vertrieb, usw. verbunden sind (z.B. Beschaffung, Vertrieb, Produktion) und sekundäre, mit denen die ausführenden unterstützt werden (Finanzwesen, Controlling, Personalwesen, usw.). Es versteht sich, dass Wertschöpfungsketten auch Geschäftsprozesse sind (vgl. auch [Keller und Teufel 1997, S. 43], [Stahlknecht 1995, S. 235] sowie für eine Kurzdarstellung [Schneck 1998, S. 779]).

 

16 Literatur

Allweyer 2013
Allweyer, T.: BPMN 2.0 - Business Process Model and Notation: Einführung in den Standard für die Geschäftsprozessmodellierung. Books on Demand, 2013.

Alpar, Grob, Weimann u.a. 2008
Alpar, Paul; Grob, Heinz Lothar; Weimann, Peter; Winter, Robert: Anwendungs­orientierte Wirtschaftsinformatik. Strategische Planung, Entwicklung und Nutzung von Informations- und Kommunikationssystemen. (5. Auflage). Wiesbaden 2008

Vossen und Becker 1996
Vossen, Gottfried; Becker, Jörg (Hrsg.): Geschäftsprozessmodellierung und Workflow-Management. Modelle, Methoden, Werkzeuge. Bonn u.a. 1996 (Thomson)

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

Franz 1996
Franz, Klaus-Peter: Prozesskostenmanagement für ein strategisches Aktivitätencontrolling, in [Perlitz, Offinger, Reinhardt u.a. (Hrsg.) 1996, S. 210 - 220]

Freund und Rücker 2014
Freund, J. und Ruecker, B.: Praxishandbuch BPMN 2.0. München 2014

Herrmann 2016
Herrmann, Wolfgang: Digitalisierung bringt die IT in Zugzwang. In: Computerwoche 2016, 11-13, 14. März 2016, S. 22 - 27

Hess 1996
Hess, Thomas: Entwurf betrieblicher Prozesse. Grundlagen – Bestehende Methoden – Neue Ansätze, Wiesbaden 1996

Hohmann 1999
Hohmann, Peter: Geschäftsprozesse und integrierte Anwendungssysteme. Prozessorientierung als Erfolgskonzept. Köln u.a. 1999

Kastens und Büning 2008
Kastens, Uwe und Büning, Hans Kleine Büning: Modellierung. Grundlagen und formale Methoden (2. Auflage). Bonn 2008 (Hanser)

Keller und Teufel 1997
Keller, Gerhard; Teufel, Thomas: SAP R/3 prozessorientiert anwenden. Iteratives Prozess-Prototyping zur Bildung von Wertschöpfungsketten. Bonn u.a. 1997

Kossak, Illibauer, Geist et al. 2015
Kossak, Felix; Illibauer, Christa; Geist, Verena et al.: A Rigorous Semantics for BPMN 2.0 Process Diagrams. München 2015 (Beck)

Mertens 2001
Mertens, Peter: Integrierte Informationsverarbeitung 1. Operative Systeme in der Industrie (13. Auflage), Wiesbaden 2001 (Gabler)

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)

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

Perlitz, Offinger, Reinhardt u.a. (Hrsg.) 1996
Perlitz, Manfred; Offinger, Andreas; Reinhardt, Michael; Schug, Klaus (Hrsg.): Reengineering zwischen Anspruch und Wirklichkeit. Ein Managementansatz auf dem Prüfstand. Wiesbaden 1996

Porter 1985
Porter, Michael E.: Competitive Advantage – Creating and Sustaining Superior Performance. New York 1985

Porter 1998
Porter, Michael E.: On Competition. Harvard Business Review Book 1998

Rump 1999
Rump, Frank J.: Geschäftsprozessmanagement auf der Basis ereignisgesteuerter Prozessketten. Formalisierung, Analyse und Ausführung von EPKs, Stuttgart und Leipzig 1999

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

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

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.

Schneck 1998
Schneck, Ottmar: Lexikon der Betriebswirtschaft (3. Auflage). München 1998

Stahlknecht 1995
Stahlknecht, Peter: Einführung in die Wirtschaftsinformatik (siebte, vollständig überarbeitete und erweiterte Auflage)

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

Staud 2010
Staud, Josef: Unternehmensmodellierung - Objektorientierte Theorie und Praxis mit UML 2.0. Berlin u.a. 2010 (Springer-Verlag)

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

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

Steinbuch 1998
Steinbuch, Pitter A. (Hrsg.): Prozessorganisation - Business Reengineering – Beispiel R/3, Ludwigshafen (Rhein) 1998

Wöhe 1993
Wöhe, Günter: Einführung in die Allgemeine Betriebswirtschaftslehre (unter Mitarbeit von Ulrich Döring), München 1993

17 Anhang

Übersetzung wichtiger Begriffe (Auswahl)

Die Methode BPMN ist sehr umfangreich und benötigt deshalb viele Begriffe. Die meisten wurden übersetzt, einige auch in ihrer englischen Fassung gelassen, weil sie sich so bereits durchgesetzt haben. Die folgende Tabelle gibt für die wichtigsten hier verwendeten Begriffe die englische Originalversion an.

 


Begriffe in diesem Text

Begriffe aus [OMG 2011]

 

 

Abbruch-Schlussereignis

terminate end event

abgebend (bei Ereignissen)

throwing

Akteur

actor

Aktivität

activity

Artefakt

artifact

Assoziation

association

Aufgabe

task object

ausführbarer Prozess

private executable (internal) business process

Auslöser von Zwischenereignissen

intermediate event triggers

B

Bahn

lane

Becken

pool

Beenden-Schlussereignis

terminate end event

C

Call Activity

call activity

D

Dateninput

data input

Datenobjekt

data object

Datenoutput

data output

Datenspeicher

data store

Dienst-Aufgabe

service task object

E

eingebetteter Subprozess

embedded sub-process

Elternprozess

parent process

empfangend (bei Ereignissen)

catching

Empfänger-Aufgabe

receive task object

Ereignis, abgebend

event, throwing

Ereignis, empfangend

event, catching

ereignisbasiertes Gateway

event-based gateway

Ereignissubprozess

event sub process

Ereignissubprozess, nicht unterbrechend

event sub process, none interrupting

Ereignissubprozess, unterbrechend

event sub process, interrupting

Eskalation

escalation

Exclusive Gateway

exclusive gateway

Exclusive Gateway, datenbasiert

gateway, data-based

Exclusive Gateway, verknüpfend

gateway, exclusive merging

Exclusive Gateway, verzweigend

gateway, exclusive forking

F

 

Fehler-Ereignissubprozess

error event sub-process

Fehler-Zwischenereignis

error intermediate event

Flussobjekt

flow objects

G

Gateway

gateway

Geschäftsregel

business rule task object

globale Aufgabe

global task

globale Geschäftsregel

global business rule task

globaler Prozess

global process

globales Skript

global script task

Grenzlinie, unterbrechend

boundary, interrupting

Gruppe

group

Handarbeit

manual task

I

Interne Geschäftsprozess

private business process

interner Prozess

internal process

K

Kante

edge

Kennzeichen

marker

Knoten

Kanten

Kollaborationsdiagramm

collaboration diagram

Kompensation

compensation

Kompensationsaktivität

compensation activity

Kompensationsassoziation

compensation association

Kompensations-Endereignis

compensation end event

Kompensations-Ereignis

compensation event

Kompensationsereignis-Subprozess

compensation event sub-Process

Kompensations-Markierung

compensation marker

Kompensations-Startereignis

Compensation Start Event

Konversation

Conversations

Konversationsverknüpfung

conversation link

M

Mehrfachinstanz-Markierung

multi instance marker

Mehrfach-Startereignis

multiple start event

N

Nachricht

message

Nachricht, empfangend

message, catching

Nachrichtenfluss

message flow

Nachrichten-Schlussereignis

message end event

Nachrichten-Zwischenereignis

message intermediate events

Nicht ausführbarer Geschäftsprozess

private non-executable (internal) business processes

Nutzer-Aufgabe

user task

O

Öffentlicher Geschäftsprozess

public process

P

Parallel Gateway

parallel gateway

Parallel Gateway, verknüpfend

parallel gateway, joining (auch: merging)

Parallel Gateway, verzweigend

parallel gateway, forking

paralleles ereignisbasiertes Gateway

parallel event-based gateway

S

Schleifen-Markierung

loop marker

Schlussereignis

end event

Schwimmbahnen

swimlanes

Sender-Aufgabe

send task object

Sequenzfluss

sequence flow

Signal

Signal

Signal-Schlussereignis

Signal End Event

Skript

script task object

Startereignis

start event

Subprozess

sub process

Subprozess, Ad Hoc

sub process, ad hoc

Subprozess, eingebetteter

sub process, embedded

Subprozess, entfalteter

sub process, expanded

Subprozess; Ereignissubprozess

sub process, event

Subprozess, Kompensation

sub process, compensation

Subprozess, Mehrfachinstanz (parallel)

sub process, multi instance (parallel)

Subprozess, Mehrfachinstanz (sequentiell)

sub process, multi instance (sequential)

Subprozess, verborgener

sub process, collapsed

Subprozess, wiederverwendbarer

sub process, reusable (auch: call activity)

T

textliche Anmerkung

text annotation

Top Level - Prozess

top level process

Transaktion

transaction

Transaktions-Markierung

transaction marker

V

Verknüpfende Objekte

connecting objects

Verknüpfung

link

voreingestellter Sequenzfluss

default sequence flow

Z

Zeitgeber

timer

Zusammenarbeit

collaboration

Zwischenereignis

intermediate event

Zwischenereignis, Grenzlinie /nicht unterbrechend

intermediate event, boundary non interrupting

Zwischenereignis, Grenzlinie / unterbrechend

intermediate event, boundary interrupting