FACHWISSEN · AUTOMATISIERUNG & TRANSFORMATION

BPA modellieren: Warum ein paralleler Prüfpfad auf einen nie gestarteten Zweig warten kann

Ein automatisierter Geschäftsprozess kann ohne technische Fehlermeldung stehen bleiben. Eine mögliche Ursache liegt im Prozessmodell: Nach einer alternativen Entscheidung wird ein Zusammenführungspunkt verwendet, der auf mehrere parallele Ergebnisse wartet.

Alternative und Parallelität haben unterschiedliche Regeln

In BPMN beschreibt ein exklusives Gateway alternative Wege. Ein paralleles Gateway kann dagegen mehrere Pfade starten und beim Zusammenführen synchronisieren. Vereinfacht gesprochen wartet ein paralleler Join auf einen Token an jedem eingehenden Sequenzfluss. Ein Token steht dabei für den Fortschritt einer Prozessausführung und ist kein Datensatz oder Benutzerkonto.

Wird zuvor nur einer von zwei alternativen Pfaden gestartet, erreicht der andere Eingang niemals einen Token. Ein späterer paralleler Join kann deshalb dauerhaft warten. Das Diagramm wirkt auf den ersten Blick symmetrisch, seine Ausführungsregeln passen aber nicht zusammen.

Ein nachvollziehbares Prüfbeispiel

Ein fiktiver Beschaffungsprozess unterscheidet Standardmaterial und Sondermaterial. Standardmaterial benötigt eine normale Freigabe, Sondermaterial eine technische Bewertung. Es wird genau eine Alternative durchlaufen. Eine anschließende Zusammenführung darf daher nicht auf beide Bewertungen warten.

Anders ist der Fall, wenn für jeden Antrag sowohl eine technische als auch eine kaufmännische Prüfung erforderlich ist. Dann können beide Prüfpfade parallel starten und anschließend gemeinsam abgewartet werden. Für den Abbruch einer Prüfung und für Fristüberschreitungen werden zusätzliche, ausdrückliche Regeln benötigt.

Prozessmodelle mit Fällen durchspielen

Eine Prüfung sollte nicht nur fragen, ob alle Kästchen verbunden sind. Für jede Entscheidung werden repräsentative Eingaben gewählt und die tatsächlich gestarteten Pfade verfolgt. Besonders aufschlussreich sind Grenzwerte, fehlende Angaben, abgelehnte Prüfungen und Zeitabläufe.

Bei jedem Zusammenführungspunkt lässt sich konkret fragen: Welche Ergebnisse werden erwartet? Können sie bei diesem Fall überhaupt entstehen? Was passiert, wenn eine Aufgabe zurückgegeben oder ein Teilprozess abgebrochen wird? Diese Fragen machen fachliche Lücken früh sichtbar.

Technische Ausführung braucht fachliche Begriffe

Ein Gateway ersetzt keine verständliche Regel. „Prüfung erforderlich“ sollte auf nachvollziehbaren Kriterien beruhen. Zuständigkeit, Eingabedaten und erwartetes Ergebnis einer Aufgabe gehören ebenfalls zum Modell. Für wiederkehrende Bedingungen kann eine gesonderte Entscheidungstabelle übersichtlicher sein als eine lange Folge verschachtelter Verzweigungen.

Ein korrektes Ablaufmodell verhindert nicht jeden Betriebsfehler. Es schafft jedoch eine prüfbare Grundlage. Damit wird erkennbar, ob ein Vorgang wegen einer fachlichen Rückfrage, einer technischen Störung oder einer widersprüchlichen Ablaufregel wartet.

An automated business process can stop progressing without reporting a technical error. One possible cause is in the process model: an alternative decision is followed by a merge that waits for several parallel results.

Alternatives and parallel paths follow different rules

In BPMN, an exclusive gateway represents alternative routes. A parallel gateway can start several paths and synchronise them when they rejoin. In simplified terms, a parallel join waits for a token on every incoming sequence flow. A token represents the progress of a process execution; it is not a data record or user account.

If only one of two alternative paths started earlier, the other input will never receive a token. A later parallel join may therefore wait indefinitely. The diagram can look symmetrical even though its execution rules do not fit together.

A traceable review example

A fictional purchasing process distinguishes standard material from special material. Standard material requires a normal approval; special material needs a technical assessment. Exactly one alternative is followed. Their subsequent merge must therefore not wait for both assessments.

The situation differs when every request requires both a technical and a commercial review. Both paths can then start in parallel and be awaited together. Explicit additional rules are needed for cancelled reviews and expired deadlines.

Walk through process models with concrete cases

A review should ask more than whether all boxes are connected. Choose representative inputs for every decision and follow the paths that actually start. Boundary values, missing information, rejected reviews and timeouts are particularly revealing.

At each merge, ask which results are expected, whether this case can produce them at all and what happens when a task is returned or a subprocess is cancelled. These questions expose gaps in the business logic early.

Technical execution needs clear business terms

A gateway cannot replace an understandable rule. “Review required” should depend on traceable criteria. The model also needs each task’s responsibility, input data and expected result. A separate decision table may be clearer than a long chain of nested branches for recurring conditions.

A correct process model will not prevent every operational failure. It does create a verifiable basis for distinguishing a business query from a technical incident or a contradictory workflow rule.