BPMN-Tool mit Simulation: Was die Notation rechnen kann — und was nicht

Es gibt einen Satz, der in Werkzeugauswahlen regelmäßig zu falschen Entscheidungen führt: „Unser BPMN-Tool kann auch Simulation.“ Er ist meistens wahr und fast immer unbrauchbar, weil er von einer Plausibilitätsprüfung bis zu einem vollwertigen Ereignissimulator alles bedeuten kann.

Der Grund liegt in der Notation selbst.

Was BPMN beschreibt — und was nicht

BPMN 2.0 ist ein Standard der OMG für die Struktur eines Prozesses: Aufgaben, Ereignisse, Gateways, Bahnen, Nachrichtenflüsse. Es beantwortet die Frage „was passiert in welcher Reihenfolge, und wer macht es?“ vollständig und präzise.

Zum Rechnen fehlen ihm fünf Angaben, die in der Notation schlicht nicht vorgesehen sind:

1. Der Ankunftsprozess. Wie viele Vorgänge kommen an — und wie verteilt? Zwanzig Anträge pro Tag gleichmäßig verteilt ergeben ein völlig anderes Bild als zwanzig, die montags früh in einem Schwall eintreffen.
2. Die Streuung der Bearbeitungsdauern. Nicht „10 Minuten“, sondern „5 bis 20 Minuten, meistens 8“. Die Streuung ist der Treiber der Warteschlange, nicht der Mittelwert.
3. Kapazität je Ressource. Wie viele Personen mit welchem Stellenanteil, und welche Rollen teilen sich einen Pool?
4. Verzweigungswahrscheinlichkeiten. Ein XOR-Gateway zeigt, dass verzweigt wird. Wie oft welcher Weg genommen wird, steht nirgends im Diagramm.
5. Kalender. Acht Stunden am Tag, Feiertage, Schichten. Ein Vorgang, der freitags um 16:50 ankommt, wartet nicht zehn Minuten, sondern drei Tage.

Für genau dieses Problem wurde BPSim geschaffen — ein Standard der WfMC, der Simulationsparameter an ein BPMN-Modell hängt, ohne die Notation zu verändern. Dass es diesen Standard braucht, ist der beste Beleg dafür, dass BPMN allein nicht rechnen kann.

Was Simulationsmodule in BPMN-Werkzeugen typischerweise liefern

Die verbreiteten Modelliersuiten — Bizagi Modeler, SAP Signavio, ARIS und andere — bieten Simulation in gestuften Ausbaustufen an. Der übliche Aufbau, unabhängig vom Hersteller:

• Strukturprüfung. Läuft ein Token überhaupt durch das Modell, oder gibt es Sackgassen und nie erreichte Zweige? Nützlich, aber noch keine Simulation im engeren Sinn.
• Zeitanalyse. Dauern je Aufgabe, daraus Durchlaufzeit — zunächst ohne Kapazitätsgrenze, also ohne Warteschlangen.
• Ressourcenanalyse. Jetzt erst wird es interessant: Personen mit Kapazität, dadurch Warteschlangen und Auslastung.
• Kalenderanalyse. Arbeitszeiten und Schichten, wodurch Wartezeiten realistisch werden.

Camunda gehört bewusst nicht in diese Aufzählung: Es ist eine Ausführungsmaschine, keine Simulationsumgebung. Es lässt echte Vorgänge durch den Prozess laufen und misst sie. Das ist wertvoller als jede Simulation — aber erst, wenn der Prozess bereits automatisiert läuft. Vor der Entscheidung hilft es nicht.

Die fünf Fragen an Ihr Werkzeug

Öffnen Sie Ihr Modelliertool und prüfen Sie in zehn Minuten:

1. Kann ich eine Dauer als Bandbreite eingeben? Wenn das Feld nur eine Zahl annimmt, rechnet das Werkzeug mit Mittelwerten. Dann steht das Ergebnis systematisch zu günstig da — Warteschlangen entstehen aus Streuung, und ohne Streuung entsteht keine.

2. Bekomme ich ein Ergebnis mit Spanne? Eine Durchlaufzeit von „6,4 Tagen“ ist keine Aussage, sondern eine Zahl. „P10 4,1 — P90 11,8 Tage“ ist eine Aussage. Werkzeuge, die nur Punktwerte ausgeben, haben entweder deterministisch gerechnet oder die Spanne unterschlagen.

3. Teilen sich Rollen eine Kapazität? In der Praxis macht dieselbe Person drei verschiedene Schritte. Werkzeuge, die Kapazität pro Aufgabe statt pro Pool führen, rechnen jeden Schritt für sich entspannt — und die Person, die alle drei macht, in keinem.

4. Sehe ich den Spitzentag oder das Monatsmittel? Im Monatsmittel ist fast jede Rolle unter 80 % ausgelastet. Am Spitzentag ist genau dort der Prozess zusammengebrochen. Wenn die Auslastungszahl nicht dazusagt, worauf sie sich bezieht, ist sie wertlos.

5. Was kostet die Verbesserung — und was bringt sie? Fast kein Modelliertool beantwortet das, weil Kostensätze und Investitionen nicht Teil des Modells sind. Genau diese Zahl entscheidet aber über das Projekt.

Der Punkt, an dem auch gute Module aufhören

Angenommen, Ihr Werkzeug besteht alle fünf Prüfungen. Dann bleibt eine letzte Frage, an der die meisten Auswertungen scheitern — nicht aus technischem Unvermögen, sondern weil niemand sie stellt:

Wohin wandert der Engpass, wenn ich ihn löse?

Ein Beispiel, das jeder kennt: Die Prüfung dauert zu lange, also wird sie automatisiert. Die Simulation bestätigt: Prüfzeit sinkt um 80 %. Was sie oft nicht zeigt: Die Freigabe dahinter bekam bisher alle 26 Minuten einen Vorgang, weil die Prüfung nicht mehr durchließ. Jetzt bekommt sie alle 10 Minuten einen — und ist selbst überlastet. Der Durchsatz steigt nicht wie versprochen, und die eingesparte Zeit landet in einer neuen Warteschlange.

Das ist kein exotischer Sonderfall, sondern die Regel. Ein Engpass verschwindet nicht, er wandert. Ein Modell, mit dem man diese Bewegung nicht in Sekunden durchspielen kann, führt zu Business Cases, die im Betrieb nicht eintreten.

Praktische Empfehlung

• Sie haben bereits eine Modelliersuite mit Simulationsmodul? Nutzen Sie sie. Ein zweites Werkzeug lohnt sich erst, wenn Sie an einer der fünf Fragen scheitern.
• Sie modellieren gerade erst? Fangen Sie nicht mit BPMN an. Die Notation ist für Dokumentation gebaut; für die Frage „wo klemmt es und was bringt eine Änderung?“ ist sie ein Umweg über eine Sprache, die Sie erst lernen müssen.
• Sie müssen eine Investition begründen? Dann brauchen Sie Bandbreiten, den Spitzentag, geteilte Ressourcenpools und einen Vorher/Nachher-Fall in Euro. Prüfen Sie, welches Ihrer vorhandenen Werkzeuge das liefert, bevor Sie ein neues kaufen.

FlowVisual verzichtet bewusst auf BPMN: sechs Bausteine statt einer Notation, Dauern als Bandbreiten, Auslastung am Spitzentag, geteilte Pools — und am Ende ein Vorher/Nachher in Euro mit P10–P90-Spanne. Wer BPMN für die Dokumentation braucht, ersetzt sie damit nicht. Es beantwortet eine andere Frage.