Geschäftsprozess modellieren: EPK oder BPMN – und wann nehme ich XOR, UND oder ODER?

Ja, dafür gibt es klare Regeln – und wenn du sie einmal hast, modelliert sich das fast von selbst.

Erst die EPK-Grundmechanik, weil daran die halbe Bewertung hängt: Eine EPK wechselt immer zwischen Ereignis und Funktion ab.

• Ereignis = ein Zustand, passiv formuliert, im Partizip: „Bestellung ist eingegangen“, „Bonität ist geprüft“. Ein Ereignis tut nichts, es ist etwas.
• Funktion = eine Tätigkeit, aktiv formuliert, Verb + Objekt: „Bonität prüfen“, „Ware kommissionieren“.

Zwei Funktionen dürfen nie direkt aufeinander folgen, zwei Ereignisse auch nicht. Die EPK beginnt und endet mit einem Ereignis. Allein damit sortierst du die meisten Anfängerfehler aus.

Jetzt die Konnektoren. Frag dich bei jeder Verzweigung nur eines: Wie viele der ausgehenden Pfade werden durchlaufen?

• XOR – genau einer. Das ist die echte Entscheidung: entweder Rechnung oder Lastschrift, entweder Kunde ist zahlungsfähig oder eben nicht. Die Pfade schließen sich gegenseitig aus.
• UND – alle, parallel. Ware packen und Rechnung schreiben passieren beide, nur eben unabhängig voneinander und zeitlich egal in welcher Reihenfolge.
• ODER – mindestens einer, es dürfen aber auch mehrere sein. Beispiel: Der Kunde wird per E-Mail und/oder per SMS benachrichtigt. Das ist der seltenste Fall und wird oft fälschlich statt XOR gesetzt.

Die wichtigste Regel, die fast jeder in der ersten Aufgabe verletzt: Ein Ereignis kann keine Entscheidung treffen. Nach einem Ereignis darf deshalb kein XOR-Split stehen – dort ist ja noch niemand tätig geworden, der entscheiden könnte. Ein XOR-Split gehört hinter eine Funktion („Bonität prüfen“ → XOR → „Bonität ist ausreichend“ / „Bonität ist nicht ausreichend“). Danach folgt auf jedem Pfad ein Ereignis, das das Ergebnis benennt.

Und: Was du aufmachst, musst du wieder zusammenführen – und zwar mit demselben Typ. XOR öffnen, XOR schließen. Ein UND-Split, der später als XOR zusammenläuft, ist ein logischer Fehler (die parallelen Zweige laufen beide an, der XOR-Join wartet aber nur auf einen).

Zur zweiten Frage – EPK und BPMN sind nicht dasselbe, aber verwandt genug, dass du das Gelernte übertragen kannst.

• EPK stammt aus der deutschen ARIS-Tradition und ist auf die fachliche Dokumentation ausgelegt: Wer will verstehen, wie ein Prozess abläuft? Sie ist bewusst schlicht und deshalb in Studienheften beliebt.
• BPMN 2.0 ist ein internationaler Standard (ISO/OMG) und deutlich reicher: Pools und Lanes für Zuständigkeiten, Nachrichtenflüsse über Unternehmensgrenzen hinweg, Fehler- und Zeit-Ereignisse – und BPMN-Modelle lassen sich in einer Process Engine sogar ausführen.

Faustregel: Interne Ablaufbeschreibung einer Abteilung → EPK reicht. Sobald mehrere Beteiligte, externe Partner oder eine technische Umsetzung im Spiel sind → BPMN.

Die Übersetzung ist fast eins zu eins:

• EPK-Funktion → BPMN-Task (abgerundetes Rechteck)
• EPK-Ereignis → BPMN-Event (Kreis) – hier der Unterschied: BPMN setzt Events nur, wo sie etwas bedeuten (Start, Ende, eingehende Nachricht, Timer), nicht nach jedem Schritt. BPMN-Modelle sind dadurch spürbar kürzer.
• XOR → exklusives Gateway (Raute mit X)
• UND → paralleles Gateway (Raute mit +)
• ODER → inklusives Gateway (Raute mit O)

Zwei Modellierungsgrundsätze gelten in beiden Sprachen und werden gern abgefragt: Gateways arbeiten nicht, Aufgaben entscheiden nicht. Ein Gateway verzweigt nur den Fluss – die eigentliche Prüfung ist eine Aufgabe davor. Und der Prozess braucht eine klar benannte Auslösung und ein definiertes Ende; ein Zweig, der im Nichts endet, ist ein Modellfehler, auch wenn inhaltlich „nichts weiter passiert“ (dann gehört ein Endereignis „Bestellung abgelehnt“ hin).

Für deinen Bestellprozess heißt das konkret: Bestellung geht ein (Ereignis) → Bestellung prüfen (Funktion) → XOR → zwei Ereignisse „Bestellung ist gültig“ / „Bestellung ist fehlerhaft“, und nur der gültige Pfad läuft weiter Richtung Zahlungsart, wo das nächste XOR sitzt. Ware packen und Rechnung schreiben hängst du an ein UND – die blockieren sich nicht gegenseitig.