Lesedauer 12 Min

Der Umstieg von der ereignisgesteuerten Prozesskette (EPK) zur Business Process Model and Notation (BPMN) 2.0 birgt so mache Herausforderung, und doch stehen zahlreiche Unternehmen genau vor dieser Aufgabe. Nachstehend erklären wir die Gemeinsamkeiten und Unterschiede und geben Hinweise zur erfolgreichen Umstellung.

Die ereignisgesteuerte Prozesskette (EPK)

Historie der EPK

Die Ursprünge von ereignisgesteuerten Prozesskette (EPK) gehen zurück auf das Jahr 1992 sie als Teil der Architektur von Integrierten Informationssystemen (ARIS) vorgestellt wurde. Die EPK ist eine der zentralen Komponenten von ARIS und stellt die dortige Steuerungs- und Prozesssicht dar. Im Bereich des industriellen Geschäftsprozessmanagements ist es im Kontext des SAP-Konzeptes zur Modellierung von Unternehmensstrukturen und -prozessen weit verbreitet.

Petrinetze dienten zunächst als Grundlage der EPK, sie wurde aber mehrfach erweitert, sodass heute meist von erweiterten ereignisgesteuerten Prozessketten (eEPK) gesprochen wird. Die Begriffe EPK und eEPK werden in der Praxis synonym verwendet.

EPK bzw. eEPK sind semi-formale Modellierungssprachen und dienen der Modellierung von Prozessen. Der Kern umfasst Funktionen, Ereignisse, Kontrollfluss (gerichtete Kanten) und Konnektoren.

Die wichtigsten Symbole der EPK

Die grundlegenden Notationssymbole sind:

Komponente	Symbol	Beschreibung
Ereignis		Ein Zustand, der eine Handlung (Funktion) auslöst. Ein Ereignis auch kann das Ergebnis einer Funktion sein.
Funktion		Beschreibt, was nach einem Ereignis gemacht werden soll. Gehen einher mit Ressourcen- und Zeitverbrauch.
Organisationseinheit		Als Element der Organisationsstruktur gibt es an, von wem eine bestimmte Funktion ausgeführt werden soll.
Konnektoren		Auch Operatoren genannt. Sind logische Verknüpfungen zwischen Ereignissen und Funktionen, wie UND, ODER und Exklusives ODER.
Prozesswegweiser		Verweist auf die Verbindung zu einem anderen Prozess (Unterprozess).
Kontroll- und Informationsfluss		Ein Pfeil beschreibt die Ablaufreihenfolge sowie Datenflüsse.

Beispiel eines EPK-Modells

Ein EPK-Modell-Beispiel zur Beschreibung eines Auftragsprüfungsprozesses:

Business Process Model and Notation

Historie der BPMN

Die Business Process Model and Notation (BPMN) wurde von IBM-Mitarbeiter Stephen A. White entwickelt und 2004 von der Business Process Management Initiative (BPMI) in der Version 1.0 veröffentlicht. Im folgenden Jahr wurde die BPMI von der OMG übernommen und diese veröffentlichte 2006 die BPMN als OMG-Standard. 2011 veröffentlichte die OMG die Version 2.0. Es gilt heute als ‚lingua franca‘ der Modellierung von Geschäftsprozessen und deren Automatisierung.

Ein Hauptziel der BPMN-Entwicklung war es, eine Notation bereitzustellen, die von allen Beteiligten leicht verstanden wird; von den technischen Entwicklern bis zu den Fachanwendern, die Prozesse verwalten und überwachen. BPMN kann die Kluft zwischen einzelnen Parteien überbrücken und Geschäftsprozesse so modellieren, dass jeder sie verstehen kann. Dieser Ansatz unterscheidet es stark von Modellierungssprachen wie UML, EPK u.a..

Die wichtigsten Symbole der BPMN

Komponente	Symbol	Beschreibung
Ereignis		Ereignisse beschreiben Zustände, die eintreten oder durch den Prozess selbst ausgelöst werden. Nachrichten, Zeit- und Bedingungsereignisse gehören zu den wichtigsten Ereignisarten.
Aktivitäten		Eine Aktivität beschreibt die Verrichtung von Arbeit. Sie gehen mit Ressourcen- und Zeitverbrauch einher. Es wird zwischen Aufgaben (unteilbare Tätigkeit), Teilprozessen, Aufrufaktivitäten und Transaktionen unterschieden.
Gateways		Gateways lenken den Tokenfluss und divergieren oder konvergieren den Verlauf des Prozesses. Es wird zwischen datenbasierten Gateways (OR, XOR), parallelisierenden Gateways und ereignisbasierten Gateways unterschieden.
Teilnehmer		Pools (Beteiligter) und Lanes repräsentieren Verantwortlichkeiten für Aktivitäten. Ein Pool oder eine Lane können eine Organisation, eine Rolle oder ein System sein.
Verbindende Objekte		Es wird unterschieden zwischen Sequenzflüssen, die den Ablauf des Prozesses bestimmen, Nachrichtenflüssen, die Austausche zu anderen Prozessen beschreiben, und Assoziationen, die Zusammenhänge zu anderen Informationsartefakten beschreiben.

Ein Beispiel eines BPMN-Modells

Unterschiede

Um die Unterschiede der Modellierungssprachen aufzuzeigen, bedienen wir uns nachstehend bei den Workflow-Mustern, die von Wil van der Aalst und Arthur ter Hofstede entwickelt wurden. Deren 20 Kontrollflussmuster sind nachstehend mit je einer Kurzbeschreibung aufgeführt, sowie eine Bewertung, inwieweit die EPK diese Workflow-Muster unterstützt.

Bezeichnung	Kurzbeschreibung	EPK	BPMN
Basic Control Flow
Sequence	Eine Aufgabe im Prozess wird erst aktiviert, wenn die vorhergehende Aufgabe abgeschlossen ist.	+	+
Parallel Split	Eine Aufspaltung des Kontrollflusses in zwei oder mehrere parallele Kontrollflüsse findet statt	+	+
Synchronisation	Es findet eine Zusammenführung von zwei oder mehreren Kontrollflüssen zu einem Kontrollfluss statt. Es muss auf alle eingehenden Kontrollflüsse gewartet werden.	+	+
Exclusive Choice	Aus mehreren Kontrollflussalternativen wird genau eine ausgewählt, um den Kontrollfluss fortzusetzen.	+	+
Simple Merge	Es findet eine Zusammenführung von zwei oder mehreren Kontrollflüssen zu einem Kontrollfluss statt	+	+
Advanced Synchronisation
Multiple Choice	Aus mehreren Alternativen werden maximal alle ausgewählt, um den Kontrollfluss fortzusetzen.	+	+
Synchronising merge	Es findet eine Zusammenführung von zwei oder mehreren Kontrollflüssen statt. Es muss auf alle eingehenden Kontrollflüsse gewartet werden. Das Muster bezieht sich auf einen eindeutig identifizierbaren vorausgegangen Punkt im Prozessablauf.	+	+/-
Multiple merge	Es findet eine Zusammenführung von zwei oder mehreren Kontrollflüssen zu einem Kontrollfluss statt.	–	+
Discriminator	Von mehreren konkurrierenden Alternativen wird genau die erste ankommende akzeptiert. Die Restlichen werden verworfen	–	+
Structural Patterns
Arbitrary Cycles	Fähigkeit zu Darstellung einer Schleife, welche über mehrere Punkte betreten und verlassen werden kann.	+	+
Implicit Termination	Ein Prozess (oder Sub-Prozess) wird beendet, wenn es keine weiteren Ausführungsoptionen mehr gibt.	+	+
Multi Instance Pattern
MI without Synchronisation	Von einer Aufgabe können mehrere, voneinander unabhängige Instanzen erzeugt werden. Es besteht keine Forderung zur abschließenden Synchronisation.	–	+
MI with a priori Design Time Knowledge	Von einer Aufgabe können mehrere, voneinander unabhängige Instanzen erzeugt werden. Die Anzahl der Instanzen ist zum Zeitpunkt der Erstellung bekannt und es ist eine abschließende Synchronisation erforderlich, bevor weitere Aufgaben begonnen werden können.	–	+
MI with a priori Run Time Knowledge	Von einer Aufgabe können mehrere, voneinander unabhängige Instanzen erzeugt werden. Die Anzahl der Instanzen ist abhängig von Faktoren, die erst während der Laufzeit des Prozesses bekannt werden. Es ist eine abschließende Synchronisation erforderlich, bevor weitere Aufgaben begonnen werden können.	–	+
MI without a priori Run Time Knowledge	Von einer Aufgabe können mehrere, voneinander unabhängige Instanzen erzeugt werden. Die Anzahl der Instanzen ist abhängig von Faktoren, die erst während der Laufzeit des Prozesses bekannt werden. Es können jederzeit weitere Instanzen erzeugt werden. Es ist eine abschließende Synchronisation erforderlich, bevor weitere Aufgaben begonnen werden können.	–	–
State-Based Patterns
Deferred Choice	Aus mehreren Alternativen wird eine abhängig von äußeren Faktoren gewählt.	–	+
Interleave Paralleled Routing	Die Aufgaben können in beliebiger Reihenfolge ausgeführt werden. Es muss jede Aufgabe ausgeführt werden und es kann je nur eine Aufgabe erledigt werden.	–	+/-
Milestone	Eine Aufgabe wird erst dann ausgeführt, wenn eine Prozess-Instanz einen bestimmten Status erreicht hat.	–	–
Cancellation Patterns
Cancel Activity	Eine Aufgabe wird vor ihrem natürlichen Ende abgebrochen.	–	+
Cancel Case	Eine Prozessinstanz wird vor ihrem natürlichen Ende abgebrochen. Dies beinhaltet alle laufenden Aufgaben sowie alle nachfolgenden.	–	+

Die Tabelle zeigt, dass bei Mehrfachinstanzierungen (Multi Instance Pattern), zustandsbasierter Muster (State-based Patterns) und Abbruch-Mustern (Cancellation Pattern) keine ausreichende Unterstützung durch die EPK angeboten wird. Die BPMN unterstützt fast alle Konzepte.

Auch unabhängig von dieser theoretisch-abstrakten Bewertung der beiden Modellierungssprachen, gibt es weitere Dinge, die in der Praxis von starker Bedeutung sind:

1. Vendor lock-In: Da es sich bei der EPK nicht um einen Standard, sondern um ein proprietäres Format handelt, ist man immer an einen Software-Anbieter gebunden, der sein eigenes Speicherformat für diese Modellierungssprache anbietet (häufig wird dies die Software ARIS der Software AG sein). Die BPMN hingegen liegt als öffentlicher Standard vor und sichert so eine Unabhängigkeit vom Software-Hersteller. Ist ein Prozessmodell ‚BPMN-compliant‘, kann es von jedem BPMN-Tool weiterbearbeitet werden.
2. Ausdrucksstärke: Die EPK bietet einen überschaubaren Symbolschatz. Dieser macht die Anwendung der EPK sehr leicht. Es ist jedoch festzustellen, dass der EPK Ausdrucksmittel fehlen, um eindeutige Interpretationsmöglichkeiten zu schaffen. Häufig kommt man in der Praxis nicht ohne begleitende textuelle Unterstützung aus. Die BPMN bietet eine differenzierte Ausdrucksmöglichkeit aufgrund ihres umfassenderes Symbolschatzes. Dies führt jedoch dazu, dass man sich anfangs mehr mit der Modellierungssprache beschäftigen muss.
3. Automatisierung: Seit der Version 2.0 ist die BPMN nicht mehr nur eine Visualisierung des Prozesses, sondern es wurden entsprechende Ausführungssemantiken ergänzt und integriert. Dies ermöglicht die Ausführung eines BPMN-Modells. Von dieser Möglichkeit wird heute in vielen Branchen Gebrauch gemacht, denn die Vorteile liegen auf der Hand: Eine visuelle Darstellung des Prozesses für Nicht-Techniker und zeitlich eine Ausführungsvorschrift, die hinreichend genau ist für die IT.

Die BPMN ist ein herausragendes Sprachmittel für die Prozessautomatisierung und Digitalisierung in der Organisation.

Im Zeitalter der Digitalisierung ist der letztgenannte Punkt ein gewichtiges Argument.

Übergang von EPK zur BPMN

In den Unternehmen wurde häufig über Jahre hinweg die EPK genutzt, um Prozesse in der Organisation darzustellen. Daher ist der Wunsch naheliegend (und zeitgemäß), den Übergang zur BPMN in Angriff zu nehmen. Doch wie kann dies gelingen?

Eine zunächst naheliegende Vorgehensweise ist eine einfache Konvertierung. D.h. es werden die korrespondierenden Konzepte in beiden Modellierungssprachen identifiziert und dann eins zu ein überführt. Wählt man diese Vorgehensweise, sehen die Modelle anschließend anders aus (jetzt wurden halt BPMN-Symbole verwendet), allerdings ergeben sich daraus beispielsweise die folgenden Probleme:

1. ‚False friends‘ – Manche Symbole heißen ähnlich und Anwender kommen zu dem Schluss kommen, dass diese Symbole das gleiche bedeuten. Dies ist aber häufig nicht so, sondern es verbirgt sich dahinter ein völlig abweichendes Konzept. Ereignisse oder Gateways zum Beispiel: In der BPMN sind Ereignisse ein viel ausdifferenziertes Konzept und unterscheidet diverse Typen sowie eintretende aus ausgelöste Ereignisse. Gateways hingeben funktionieren völlig anders als Konnektoren und unterscheiden datenbasierte und ereignisbasierte Verzweigungen.)
2. Erweitere Möglichkeiten bleiben ungenutzt – In der BPMN kann beispielsweise Kommunikation dargestellt werden. Dieses Konzept existiert in der EPK nicht, ist aber extrem sinnvoll (denn aus der Praxis wissen wir, dass Prozessprobleme häufig Kommunikationsprobleme sind. Da ist eine Darstellung der Kommunikation hilfreich).
3. Glaube an das Modell – Nur weil sich die Modellierungssprache ändert und daher die Modelle moderner werden, findet noch keine Prozessverbesserung statt. Die Umstellung von der EPK zur BPMN schafft aber die Gelegenheit, die laufenden Prozesse im Rahmen der Umstellung zu prüfen. Eine einfache Konvertierung lässt diese Chance vorbeiziehen.

Beispieltransformation von EPK zur BPMN

Nachstehend wollen wir verdeutlichen, wie eine sinnvolle Transformation von EPK zur BPMN aussehen kann. Zu diesem Zweck haben wir zunächst ein kleines Beispiel ausgewählt, in dem eine Mängelmeldung eines Fahrbetriebs bearbeitet wird.

Prozessdarstellung mittels Ereignisgesteuerter Prozesskette (EPK)

Prozessdarstellung mittels Business Process Model and Notation (BPMN)

Das abgeleitete Model sieht wie folgt aus:

Bewertung

Die oben vorgenommene Transformation zeigt, dass alle EPK-Elemente in ein Konzept der BPMN überführt werden konnte. Dies ist jedoch nicht eins zu eins erfolgt, sondern wir haben vielmehr die erweiterten Möglichkeiten der BPMN berücksichtigt und ein BPMN-Kollaborationsmodell erstellt.

Es ist zunächst zu erkennen, dass das eine (1) EPK-Modell in zwei (4) aufgeklappte Pools überführt wurde, da wir nun den Aspekt der Kommunikation darstellen können und somit eine gesteigerte Klarheit der Zusammenarbeit herbeiführen konnten. Außerdem finden sich im BPMN-Modell spezifische Ereignisse, die verschiedene (eintretende) Zustände des eigenen Prozesses ausdrücken.

Eine einfache Transformation hätte uns nicht die Chancen in Bezug auf Klarheit, Präzision sowie potenzielle Ausführbarkeit verschafft.

Vorgehen bei der Umstellung von EPK auf BPMN

Um die Potenziale der BPMN zu nutzen, ist eine einfache Transformation nicht empfehlenswert. Aus diesem Grund empfehlen wir eine andere Vorgehensweise, deren Argumentation jedoch auf einer strategisch-taktischen Hypothese beruht. Diese Hypothese lautet:

Wir modellieren Prozesse, um Transparenz zu schaffen, Verbesserungspotentiale zu erkennen und letztendlich Prozesse zu verbessern.

Wenn diese Hypothese auch bei Dir zutrifft (und wir glauben fest daran), dann empfehlen wir keine radikale Umstellung von EPK auf BPMN, sondern eine sukzessive. Es ist viel wichtiger, die richtigen Prozesse zu finden, die einen maßgeblichen Einfluss auf den Unternehmenserfolg haben und zu prüfen, ob diese Prozesse ihre Ziele erreichen. Hier empfehlen wir dann meist eine Neuerhebung. Die gewonnen Erkenntnisse werden dann in BPMN modelliert und dokumentiert; das alte EPK-Modell kann verworfen werden, denn nun liegt der Prozess in der neuen Notation vor. Dies darf nicht das Ende der Überarbeitung sein, denn nach wie vor müssen die Gründe für die Nichterreichung der Ziele analysiert werden, so dass Maßnahmen zur Verbesserung abgeleitet und Maßnahmen getroffen werden.

Nachstehend eine kleine Heuristik zur Vorgehensweise:

1. Identifiziere wichtige Prozesse
2. Prüfe die Zielerreichung der wichtigsten Prozesse
3. Erhebe den Prozesse neu, der seine Ziele nicht erreicht hat
4. Dokumentiere diesen Prozesse in BPMN
5. Analysiere den Prozess
6. Optimiere den Prozess

Diese Vorgehensweise hat somit nicht das Ziel, schlagartig alle Modelle von EPK auf BPMN umzustellen, sondern erfüllt die genannte Hypothese: Wir modellieren Prozesse, um Transparenz zu schaffen, Verbesserungspotentiale zu erkennen und letztendlich Prozesse zu verbessern.

Quellen

(1992) G. Keller, A.-W. Scheer und M. Nüttgens, Semantische Prozeßmodellierung auf der Grundlage“ Ereignisgesteuerter Prozeßketten (EPK). Inst. für Wirtschaftsinformatik, 1992.

(2004) S. A. White, „Introduction to BPMN. 2004“, IBM Corporation, 2004.

(2005) P. Wohed, van der Aalst, Wil MP, M. Dumas, A. H. M. ter Hofstede und N. Russell, „Patternbased Analysis of BPMN“, 2005.

(2006) J. L. Staud, Geschäftsprozessanalyse: ereignisgesteuerte Prozessketten und objektorientierte Geschäftsprozessmodellierung für betriebswirtschaftliche Standardsoftware, Springer, 2006.

(2008) Recker, Jan, BPMN Modeling – Who, Where, How and Why, BPTrends, March, 2008.

(2008) Recker, Jan, et al., An Exploratory Study of Process Modeling Practice with BPMN, 2008.

(2009) G. Decker, W. Tscheschner und J. Puchan, „Migration von EPK zu BPMN“ in Proceedings: EPK 2009 Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten 8. Workshop der Gesellschaft für Informatik e. V.(GI) und Treffen ihres Arbeitskreises Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten (WI-EPK), 2009, S. 91–117.

(2009) J. Becker, C. Mathas, A. Winkelmann und O. Günther, Geschäftsprozessmanagement. Berlin, Heidelberg: Springer-Verlag; Springer, 2009.

(2011) http://www.ariscommunity.com/users/sstein/2010-04-15-epc-vs-bpmn-perfect-flamewar,accessed 22 June 2011.

(2012) J. Freund und B. Rücker, Praxishandbuch BPMN 2.0. Carl Hanser Verlag GmbH Co KG, 2012.

(2013) J. Göpfert und H. Lindenbach, Geschäftsprozessmodellierung mit BPMN 2.0: Business Process Model and Notation. Walter de Gruyter GmbH & Co KG, 2013.

(2018) Partsch, Christopher, http://bauhaus.cs.uni-magdeburg.de:8080/miscms.nsf/FEA8C8150500AA14C1257449004F79A9/1D5137BD4330EFFAC12583DD0070A0C4/$FILE/Bachelorarbeit%20Christopher%20Partsch.pdf

(o.J. ) https://lexikon.clous.io/ereignisgesteuerte-prozesskette-epk-definition-regeln-beispiel

(o.J.) OMG-Website, OMG – We set the Standard – About OMG. [Online] Verfügbar unter: http://www.omg.org/gettingstarted/gettingstartedindex.htm.

(o.J.) Wikimedia – https://upload.wikimedia.org/wikipedia/commons/6/63/EPK_komplex.png