Die Ausführungen in diesem Kapitel sind Auszüge aus dem Buch

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

Buch zu EPKs

einer umfassenden Einführung in die Ereignisgesteuerten Prozessketten (vgl. für nähere Informationen www.staud.info).

13.1 Einführung

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

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

Istanalysen und Sollmodellierung

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

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

Semi-formal

  • informale, z.B. textliche Beschreibungen,
  • semi-formale, z.B. Ereignisgesteuerte Prozessketten, und
  • formale Methoden, wie z.B. die Prädikatenlogik

unterscheidet.

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

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

ERP-Software

Modellelemente von Scheer

Eine immer noch tragfähige Auflistung notwendiger Modellelemente legte Scheer schon vor vielen Jahren vor. Er unterscheidet [Scheer 1997]:

  • Vorgänge (mit denen die notwendigen Tätigkeiten erfasst werden, wie oben gezeigt)
  • Ereignisse (die für den Geschäftsprozess Bedeutung besitzen, auch als betriebswirtschaftlich relevante Ereignisse definiert)
  • Zustände (die sich jeweils nach Abschluss einer Tätigkeit, vor allem in den Daten, neu ergeben).

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

  • Bearbeiter (und Bearbeiterinnen)
  • Organisationseinheiten sowie
  • Ressourcen der Informationstechnologie

Er fasst diese dann, nochmals abstrahierend, zu folgenden Elementen seiner formalen Beschreibungssprache Ereignisgesteuerte Prozessketten zusammen:

  • Ereignisse
  • Funktionen
  • Organisationseinheiten
  • Informationsobjekte

13.2 Elemente

13.2.1 Funktionen

Alle Tätigkeiten, die in einem Geschäftsprozess zu leisten sind, werden im Rahmen der Prozessmodellierung mit Ereignisgesteuerten Prozessketten als Funktionen erfasst. Die Gesamtaufgabe des Geschäftsprozesses (z.B. Kalkulation erstellen) wird also, mehr oder weniger detailliert, in einzelne Teilaufgaben unterteilt, die dann die Funktionen darstellen. Die Festlegung, welchen Umfang an elementaren Tätigkeiten die einzelne ausgewiesene Funktion hat, bleibt dem Modellierer überlassen. Der in [Staud 2014, S. 6f] diesbezüglich diskutierte subjektive Faktor der Modellierung bleibt also erhalten.

Subjektiver Faktor

Funktionen beschreiben bei Menschen deren operative Tätigkeit, bei einem IT-System ein Programm, z.B. eine Transaktion oder einen betriebswirtschaftlichen Funktionsbaustein.

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


Abbildung 13.2-1:

Grafische Darstellung von Funktionen

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

Benennung von Funktionen

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

13.2.2 Ereignisse

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

Steuerung durch Ereignisse

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

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

Benennung

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

Definition

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

Funktion – Ereignis – usw.

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

Auf Zeitpunkte bezogen

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

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

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

Ereignisraum

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

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

Anfang und Ende

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


Abbildung 13.2-2:

Grafische Darstellung von Ereignissen

13.2.3 Organisationseinheiten

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

Träger des Prozessgeschehens

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


Abbildung 13.2-3:

Grafische Darstellung von Organisationseinheiten und ihre Anbindung an Funktionen

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

Grafische Festlegung

13.2.4 Informationsobjekte

Keine Organisation kommt ohne Datenbestände und andere Informationen aus, die die Organisation selbst, ihre Geschäftsobjekte und ihre informationelle Umwelt ganz oder in Ausschnitten modellieren. Diese Informationen sind damit auch für die Abwicklung der Geschäftsprozesse von großer Bedeutung.

Datenbestände und Informationen

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

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

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

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


Abbildung 13.2-4:

Grafische Darstellung von Informationsobjekten und ihre Anbindung an Funktionen

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

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

Informationsträger aller Art

Grundsätzlich geben die Informationsobjekte auch Hinweise auf den Automatisierungsgrad des betrachteten Geschäftsprozesses. Vgl. zur Automatisierung die Kapitel 18 und 19. In nicht oder nur teilweise automatisierten Abschnitten werden die Informationsobjekte oftmals (aber nicht immer!) nicht digital sein.

Informationsobjekte und Automatisierungsgrad

Kontrollfluss: Die unsichtbare, ordnende Hand

Der oben schon eingeführte Begriff Kontrollfluss kann jetzt für Ereignisgesteuerte Prozessketten präzisiert werden. Die in einem Geschäftsprozess möglichen Abfolgen von Ereignissen und Funktionen, beginnend mit Startereignissen und endend mit Schlussereignissen, werden Kontrollfluss genannt.

Abfolgen strukturieren

Ausgehend von dem Begriff Instanz (vgl. Abschnitt 13.3.5) könnte man den Kontrollfluss auch als die Gesamtheit aller möglichen Instanzen des Geschäftsprozesses bezeichnen.

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

Kanten, Kontrollflusszweige

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

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

Richtung

13.2.5 Operatoren und Kontrollfluss

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

Verzweigungen und Zusammenführungen

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


Abbildung 13.2-5:

Logische Operatoren und ihre grafische Darstellung

Es gibt für jeden Operator jeweils zwei Seiten, ankommende Kontrollflusszweige und wegführende. Auf jeder Seite ist mindestens ein Kontrollflusszweig vorhanden, so dass der Weiterverlauf über den Operator gesichert ist. Mindestens auf einer Seite sind es mehrere Zweige, die dann durch den (mehrstelligen) Operator verknüpft sind. Dabei gilt: Entweder werden Ereignisse mit Ereignissen oder Funktionen mit Funktionen verknüpft.

„Operator-Syntax“

Die Operatoren können auf jeder Seite nur Ereignisse mit Ereignissen bzw. Funktionen mit Funktionen verknüpfen, nicht Ereignisse mit Funktionen.

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

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

Für Funktionen haben sie folgende Bedeutung:

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

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

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

Grafikfestlegung



Dort wo ein Operator ist, ist dann mehr als eine Kante. Liegt kein Operator vor, gibt es nur eine einzige Kante. Liegen oben und unten mehr als eine Kante vor, müssen auf beiden Seiten Operatoren vorhanden sein, z.B. so:



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

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

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

Verteiler und Verknüpfer

13.2.6 Zeitliche Dimension und Zeitverbrauch

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

Zeitliche Dimension

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

Nicht absolut, nur relativ

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

Zeitverbrauch

Kommunikation bzw. Wie „rettet“ man Informationen über die Zeit

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

In die Datenbank schreiben und von dort lesen

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

13.3 Aufbau Ereignisgesteuerter Prozessketten

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

13.3.1 Anfrageprüfung Teil 1

Prozessbeschreibung

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

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

Umsetzung in die EPK

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

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

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


Abbildung 13.3-1:

Die ersten Funktionen der Anfrageprüfung

Die Startereignisse sind in der Prozessbeschreibung klar beschrieben:

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

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

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

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

Ergebnisereignisse


Abbildung 13.3-2:

Die ersten Ereignisse der Anfrageprüfung

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

Syntaxregel E - F - E - …

Informationsobjekte und Organisationseinheiten

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

Richtung Informationsfluss

13.3.2 Anfrageprüfung Teil 2

Prozessbeschreibung

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

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

Prozessmodellierung

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

Zusammenführung, Verknüpfung


Abbildung 13.3-3:

Geschäftsprozess Anfrageprüfung - Zusammenführung alternativer Startsequenzen

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

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


Abbildung 13.3-4:

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

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

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

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

13.3.3 Anfrageprüfung Teil 3

Prozessbeschreibung

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

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

Prozessmodellierung

Diese Semantik wird in einer Ereignisgesteuerten Prozesskette so umgesetzt, dass die Kontrollflüsse der beiden „positiven“ Ereignisse zusammengeführt, mit einem UND-Operator verbunden und zur entsprechenden Funktion weitergeführt werden. Hier beschreibt die EPK-Syntax tatsächlich sehr genau die in der Prozessbeschreibung geforderte Semantik: Zum Weiterfluss kommt es nur, wenn beim UND-Operator beide Kontrollflusszweige von den Ereignissen her ankommen.

Verknüpfer mit UND

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


Abbildung 13.3-5:

Geschäftsprozess Anfrageprüfung - Positives Ergebnis und Aufruf Auftragsabwicklung

Da in der Prozessbeschreibung an dieser Stelle gleich das positive Endergebnis, der Aufruf des anschließenden Geschäftsprozesses Auftragsabwicklung angeführt wird, kann hier durch einen Prozesswegweiser auf eine entsprechende EPK verwiesen werden. Dieses Methodenelement dient als Verweis auf einen anderen Prozess. Die obige Abbildung zeigt den damit erreichten Stand im Geschäftsprozess Anfrageprüfung, die folgende den Beginn des Geschäftsprozesses Auftragsabwicklung.


Abbildung 13.3-6:

Start des Geschäftsprozesses Auftragsabwicklung

Muster Bedingungen

Der hier nun schon mehrfach vorgekommene UND-Operator bedeutet, dass der Kontrollfluss über ihn nur weitergeht, wenn alle Kontrollflusszweige von flussaufwärts ankommen. In dieser Anordnung (Ereignisse durch UND verknüpft vor einer Funktion) stellen die Ereignisse immer Bedingungen für die Ausführung der nachfolgenden Funktion dar. Vgl. für eine umfassende Darstellung solcher Muster in Geschäftsprozessen [Staud 2014a,b].

13.3.4 Anfrageprüfung Teil 4

Prozessbeschreibung

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

Prozessmodellierung

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

1. Kapazität reicht nicht – Lagerbestand ausreichend

2. Kapazität reicht nicht – Lagerbestand reicht nicht

3. Kapazität reicht – Lagerbestand ausreichend

4. Kapazität reicht – Lagerbestand reicht nicht

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

Semantik sucht Sntax


Abbildung 13.3-7:

Kombinatorik - in vollem Umfang realisiert

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

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

Semantik sucht Syntax: „mindestens“ mit ODER

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


Abbildung 13.3-8:

Geschäftsprozess Anfrageprüfung - Die finale EPK

13.3.5 Instanzen

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

Prozessmodell vs. Prozess-Instanz

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

Kontrollfluss für den positiven Fall

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

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


Abbildung 13.3-9:

Geschäftsprozess Anfrageprüfung. Die Instanz für den positiven Ausgang.

Kontrollfluss für einen der negativen Fälle

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

„negative“ Instanz

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

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

Semantik sucht Syntax


Abbildung 13.3-10:

Geschäftsprozess Anfrageprüfung. Die Instanz für einen der negativen Fälle.

Soviel für eine Einführung in die Methode der Ereignisgesteuerten Prozessketten. Sie sollte deutlich gemacht haben, dass mit dieser Methode Geschäftsprozesse effizient modelliert werden können. Dies gilt insbesondere für Istanalysen. Eine detaillierte Darstellung findet sich in [Staud 2014a,b].