Ereignisgesteuerte Prozesskette

Woher kommt die EPK?

Bis Anfang der 1990er Jahre wurden Datenflusspläne verwendet, um darzustellen, welche Daten zwischen Organisationseinheiten fließen; Prozessmodelle waren noch nicht üblich. Vor diesem Hintergrund wurde die EPK entwickelt, um den Prozess in den Vordergrund der Gestaltung von Informationssystemen zu stellen (Gadatsch 2025, S. 130). Sie ist ein zentraler Teil der von Scheer ausgearbeiteten Architektur integrierter Informationssysteme ARIS und wurde 1991 von Keller, Nüttgens und Scheer entwickelt.

Ihre Verbreitung verdankt die EPK vor allem SAP, das seine Referenzprozesse damit dokumentierte. Wer in den 1990er und 2000er Jahren Standardsoftware einführte, begegnete Prozessmodellen fast immer in dieser Form.

Wo liegen Stärken und Grenzen der EPK?

Gadatsch bewertet die Methode als fest verankert im deutschen Sprachraum, besonders dort, wo große Informationssysteme entwickelt und gewartet werden; wegen der wenigen Symbole ist sie schnell erlernbar, braucht aber viel Platz und deshalb Werkzeuge (Gadatsch 2025, S. 154). Als Nachteile nennt er den Schulungsbedarf, weil Notation und Regeln für Einsteiger nicht selbsterklärend sind, und die fehlende Standardisierung, sodass sich die Symbole je nach Werkzeug unterscheiden (Gadatsch 2025, S. 156).

Der letzte Punkt wiegt heute am schwersten. Ein EPK-Modell lässt sich nicht verlustfrei zwischen Werkzeugen austauschen, ein BPMN-Modell als XML schon.

Wie hängen EPK und BPMN zusammen?

Weske zählt die ereignisgesteuerten Prozessketten zu den Vorläufern von BPMN, deren beste Ansätze in die neue Sprache übernommen wurden (Weske 2024, S. 210). Die Konnektoren UND, XOR und ODER finden sich in BPMN als Gateways wieder, und Gadatsch nutzt genau diese Verwandtschaft, um Umsteigern die Gateways zu erklären (Gadatsch 2025, S. 162). Wer EPK lesen kann, versteht BPMN nach kurzer Einarbeitung. Der Umstieg lohnt sich vor allem für Unternehmen, die Modelle an Partner, Werkzeuge oder eine Workflow-Engine weitergeben wollen.