Geschäftsprozesssimulation: Warum Ihre Prozesslandkarten nicht ausreichen

Sie haben das Diagramm. Es liegt in Lucidchart oder Visio oder auf einer Confluence-Seite von irgendjemandem, farbcodiert, geprüft, genehmigt von drei Personen, die nicht mehr im Unternehmen sind. Die Kästchen sind verbunden. Die Pfeile ergeben Sinn. Alle haben im Meeting genickt.

Dann führen Sie die Neugestaltung ein, und die Durchlaufzeit ist schlechter als zuvor. Der Engpass hat sich verlagert, er ist nicht verschwunden. Eine Warteschlange, mit der Sie nicht gerechnet haben, staut sich nun jeden Dienstagmorgen, und die für Schritt sieben zuständige Person ist zu 140 % ausgelastet, während die beiden Personen in Schritt vier nichts zu tun haben.

So sieht ein Diagramm ohne Simulationsdaten im produktiven Einsatz aus.

Die zentrale Aussage hier ist falsifizierbar: Ein Prozessdiagramm kann weder Durchlaufzeit noch Durchsatz oder Engpassverhalten vorhersagen. Es beschreibt die Abfolge, nicht das Verhalten. Teams, die vor Änderungen an Live-Operationen auf Simulation verzichten, treffen keine fundierten Entscheidungen. Sie raten – nur mit zusätzlichen Schritten und professionell formatierten Dokumentationen.

Die Simulation von Geschäftsprozessen schließt diese Lücke. Nicht durch zusätzliche Kästchen im Diagramm, sondern indem das Diagramm im Zeitverlauf als ausführbares Modell betrieben wird und Sie beobachten, was tatsächlich passiert.

Was Teams erst spät lernen

• Simulation führt ein Modell über die Zeit aus – sie ist kein Diagramm, sondern ein Test.
• Statische Prozesskarten beschreiben die Abfolge; Simulation zeigt das Verhalten unter realen Bedingungen.
• Sie benötigen quantitative Eingangsdaten, bevor eine Simulation etwas Nützliches liefern kann.
• Automatisierte Prozesse scheitern auch ohne Simulation nicht weniger oft – Edge Cases testen sich nicht selbst.
• Process Mining und Simulation ergänzen sich: Das eine zeigt, wo Sie stehen, das andere, wohin Sie gehen könnten.

Was Simulation von Geschäftsprozessen tatsächlich ist

Hier ist eine Definition, die tatsächlich Bestand hat: Die Simulation von Geschäftsprozessen führt ein Modell aus, das nachbildet, wie sich ein Prozess im Zeitverlauf verhält, um seine quantitativen Eigenschaften zu analysieren. Diese Einordnung stammt aus der wissenschaftlichen Forschung zu diesem Thema und ist präziser als die meisten Erklärungen aus der Praxis, weil sie zwei wichtige Wörter in den Satz zwingt: „führt aus“ und „im Zeitverlauf“.

Ein Diagramm führt nichts aus. Es ist einfach da. Sie lesen es von links nach rechts, verfolgen die Pfeile und stellen sich den Ablauf vor. Geschäftsprozessmodellierung in diesem Modus ist für Dokumentation und Kommunikation nützlich. Aber sie sagt Ihnen nicht, was passiert, wenn in der ersten Stunde des Tages 300 statt 100 Fälle eintreffen. Sie zeigt nicht, wo die Auslastung sprunghaft ansteigt oder wo die Warteschlangenlänge zum Problem wird. Das Diagramm sieht unabhängig davon gleich aus.

Prozesssimulationen führen das Modell aus. Fälle bewegen sich dadurch. Ressourcen werden verbraucht. Entscheidungen werden probabilistisch getroffen. Zeit vergeht. Das Modell erzeugt Daten darüber, was passiert – nicht darüber, was Sie beabsichtigt haben, sondern darüber, was tatsächlich aus den von Ihnen festgelegten Parametern entsteht.

Die praktischste Erklärung dafür ist aus meiner Sicht das Konzept des digitalen Zwillings: Ein Simulationsmodell ist eine virtuelle Umgebung, die den realen Prozess so genau widerspiegelt, dass Sie darin experimentieren können, ohne den tatsächlichen Betrieb zu beeinträchtigen. Sie ändern die Personalstärke, passen eine Routing-Regel an oder erhöhen die Eingangsrate stark und sehen die nachgelagerten Folgen, bevor jemand das Live-System anfasst. Fraunhofer IPK beschreibt digitale Zwillinge als genau diese Art virtueller Replik, die mit echten Prozessdaten aktualisiert wird – und genau das bildet ein gut konstruiertes Simulationsmodell näherungsweise ab.

Der Irrtum, mit dem die meisten Menschen starten, ist die Annahme, Prozesssimulationen seien lediglich animierte Diagramme. Das sind sie nicht. Die Animation ist ein Nebenprodukt. Das Produkt ist der quantitative Output.

Wie ein Simulationsmodell funktioniert: Prozessmodell, Eingaben und Ergebnisse

Ein Simulationsmodell ist kein einzelnes Element. Es ist eine Struktur aus mehreren Komponenten, die zusammenwirken. Zu verstehen, was jede einzelne Komponente leistet, entscheidet darüber, ob ein Modell nützliche Ergebnisse oder plausibel aussehenden Unsinn erzeugt.

Das Prozessmodell selbst wird meist in BPMN (Business Process Model and Notation) oder einer ähnlichen Notation ausgedrückt – also die Abfolge der Aufgaben, Gateways, parallelen Abläufe und Endpunkte. Diesen Teil haben die meisten bereits. Was meistens fehlt, sind die übrigen Eingaben.

Laut der ARIS BPM Community zeigt die Simulation, wie Prozess- und Ressourcenleistung auf Veränderungen oder Schwankungen von Parametern im Zeitverlauf reagieren. Das Schlüsselwort lautet „Parameter“. Das Modell muss wissen: Wie schnell treffen Fälle ein? Wie lange dauert jede Aufgabe – und wie stark variiert diese Dauer? Welche Ressourcen sind verfügbar und mit welcher Kapazität? Wie hoch sind die Routing-Wahrscheinlichkeiten an jedem Entscheidungspunkt?

Sobald diese Eingaben an das Prozessmodell angehängt sind, führt die Simulation verschiedene Workflow-Varianten aus. Die Engine bewegt Fälle über simulierte Zeit durch das Modell, weist Ressourcen zu, bildet Warteschlangen, wenn Ressourcen nicht verfügbar sind, und trifft Verzweigungsentscheidungen entsprechend den von Ihnen festgelegten Wahrscheinlichkeiten. Nach ausreichend vielen Simulationsläufen – manchmal Dutzenden von Iterationen – zeigen die Simulationsergebnisse die Verteilung der Ergebnisse und nicht nur einen vorhergesagten Ablauf.

Genau das kann eine Prozessanalyse mit einem statischen Diagramm nicht liefern. Ein Diagramm zeigt einen Pfad. Eine Simulation zeigt die Bandbreite der Pfade und wie häufig jeder davon unter den von Ihnen definierten Bedingungen auftritt.

Was Sie in ein Prozessmodell einbringen müssen, bevor Sie es simulieren können

Die Frage, die ich in unterschiedlichen Varianten am häufigsten höre: „Wir haben das BPMN-Flussdiagramm. Können wir darauf basierend simulieren?“ Die Antwort lautet: noch nicht. Und zwar aus folgendem Grund.

Ein Flussdiagramm sagt Ihnen, was in welcher Reihenfolge passiert. Um ein Modell zu erstellen, das tatsächlich ausgeführt werden kann, müssen Sie außerdem quantitative Daten daran anfügen. Konkret:

• Eingangsraten

  Wie viele Fälle treten pro Zeiteinheit in den Prozess ein, und wie sieht die Verteilung aus – konstant, schubweise oder abhängig von der Tageszeit?

• Bearbeitungszeiten pro Aufgabe

  Nicht nur Durchschnittswerte. Verteilungen. Eine Aufgabe, die „etwa 10 Minuten“ dauert, kann in der Hälfte der Fälle tatsächlich 4 Minuten und in der anderen Hälfte 40 Minuten dauern. Diese Varianz verändert das Verhalten von Warteschlangen drastisch.

• Ressourcenkapazität und Zeitpläne

  Wie viele Mitarbeitende, Maschinen oder Systeme stehen in jedem Schritt zur Verfügung? Wann sind sie verfügbar? Ändert sich die Verfügbarkeit im Laufe des Tages?

• Entscheidungswahrscheinlichkeiten (Geschäftsregeln)

  Welcher Prozentsatz der Fälle nimmt an jedem Gateway welchen Pfad? Diese Prozessschritte steuern die Routing-Logik, die bestimmt, wo sich Last ansammelt.

Der häufige Fehler, den ich immer wieder sehe: Teams versuchen, nur mit dem Diagramm und ohne angehängte zeitbezogene Daten zu simulieren. Das Modell läuft, erzeugt Zahlen, und diese Zahlen bedeuten nichts, weil sie auf Annahmen basieren, die das Tool selbst erfunden hat. Simulation ohne echte Eingangsdaten ist nur ein Diagramm, das sich bewegt.

Wie Sie Simulationsergebnisse lesen, ohne sich selbst zu täuschen

Die Ergebnisse der Simulation zeigen Ihnen Auslastungsraten, Durchlaufzeitverteilungen, Warteschlangenlängen, Durchsatz pro Zeitraum und Punkte mit Ressourcenkonkurrenz. Diese Outputs sind wirklich nützlich. Sie lassen sich auch wirklich leicht falsch interpretieren.

Die häufigste Fehlinterpretation: Den Durchschnitt als Vorhersage zu behandeln. Durchschnittswerte verbergen, worauf es ankommt. Wenn die Simulation sagt, die durchschnittliche Durchlaufzeit betrage 4 Stunden, kann das bedeuten, dass jeder Fall exakt 4 Stunden dauert. Es kann aber auch bedeuten, dass 80 % der Fälle 2 Stunden und 20 % der Fälle 12 Stunden benötigen. Die operativen Auswirkungen dieser beiden Situationen sind völlig unterschiedlich.

Wenn Sie Simulationsergebnisse analysieren, betrachten Sie zuerst die Verteilung. Wo liegen die Ausreißerbereiche? Wie sieht das 90. Perzentil aus? Dort treten SLA-Verstöße auf, und dort sehen Sie, was Auslastungsspitzen bei Spitzenlast mit Ihrem Prozess machen.

Die ARIS-Einordnung zu dynamischem Verhalten und Parameterschwankungen sollten Sie hier im Hinterkopf behalten: Prozesssimulationen sind dafür konzipiert, zu zeigen, wie Leistung auf Veränderungen reagiert – nicht, um eine einzelne Prognosezahl zu erzeugen. Wenn Sie eine Simulation mit nur einer Zahl verlassen, sind Sie zu früh ausgestiegen.

Wo die Simulation von Geschäftsprozessen im BPM-Lebenszyklus einzuordnen ist

Die meisten BPM-Frameworks beschreiben einen Zyklus: Einen Prozess entwerfen, implementieren, überwachen, optimieren und neu gestalten. Simulation gehört zwischen Entwurf und Implementierung, und genau diese Platzierung ist entscheidend.

Der BPM-Lebenszyklus ohne Simulation sieht in der Praxis so aus: Ein Team bildet den bestehenden Prozess ab, identifiziert Probleme, gestaltet ihn neu und führt die Neugestaltung ein. In der Überwachungsphase zeigt sich dann, ob die Neugestaltung funktioniert hat. Wenn nicht – und nach allem, was ich in Supportgesprächen erlebt habe, funktioniert sie oft zumindest nicht vollständig – iteriert das Team an einem Live-System. Das ist teuer. Es beeinträchtigt den realen Betrieb. Und die Feedbackschleife ist langsam.

Simulation ist die Validierungsebene zwischen Entwurf und Einführung. Sie ermöglicht Ihnen zu testen, ob sich der neu gestaltete Prozess tatsächlich wie erwartet verhält, bevor Sie sich verpflichten, den bestehenden Prozess zu ändern. Wie das Framework von Cardanit beschreibt, validieren Sie mit Simulation, dass ein neues Prozessdesign besser abschneiden wird als das aktuelle, statt einfach davon auszugehen.

An Verantwortliche für den operativen Bereich, die Simulation als optional betrachten: Sie sagen damit tatsächlich, dass Sie damit einverstanden sind, erst durch die Einführung herauszufinden, ob die Neugestaltung funktioniert hat. Geschäftsprozessmanagement ohne Validierungsebene ist kein BPM-Lebenszyklus. Es ist eine Reihe von Live-Experimenten mit realen Konsequenzen.

Die Phase des Prozessdesigns liefert Ihnen das Modell. Die Phase der Prozessausführung liefert Ihnen die realen Daten. Simulation ist der Schritt dazwischen, der beide Phasen verbindet, ohne dass Ihre Kunden die Kosten des Lernens tragen müssen.

📊 Zahlen und Fakten:
Stand Mai 2026 erfasst GetLatka ungefähr 20 SaaS-Unternehmen, die sich speziell auf Software zur Simulation von Geschäftsprozessen konzentrieren, mit einem gemeinsamen Jahresumsatz von rund 301 Mio. US-Dollar und etwa 2.700 Mitarbeitenden. Das ist ein kleiner, aber wirtschaftlich relevanter Markt – kein akademischer Sonderfall und keine Fähigkeit, die Enterprise-IT-Abteilungen mit Tool-Budgets im siebenstelligen Bereich vorbehalten ist.

Reale Situationen, in denen Teams Geschäftsprozesse tatsächlich simulieren

Die Theorie ist unkompliziert. Die nützlichere Frage lautet: Wie sieht es aus, wenn ein echtes Team Prozesssimulationen für ein konkretes Problem durchführt? Hier sind vier Situationen, in denen Teams dies tatsächlich nutzen, abgeleitet aus dokumentierten Anwendungsfällen in den Bereichen Gesundheitswesen, Lieferkette und Prozessverbesserung.

• Prozessverbesserung und Neugestaltung vor der Einführung

  Eine Operations Managerin eines mittelständischen Finanzdienstleistungsunternehmens möchte die Durchlaufzeit bei Kreditgenehmigungen verkürzen. Sie hat einen Vorschlag zur Neugestaltung, der zwei parallele Prüfpfade statt eines sequenziellen vorsieht. Bevor sie sich festlegt, bestätigt die Simulation, ob das parallele Modell den Durchsatz tatsächlich verbessert oder den Engpass lediglich auf einen anderen Schritt verlagert. Dies ist die häufigste Anwendung von Prozesssimulation: Prozessänderungen validieren, bevor sie den realen Betrieb berühren, statt erst nach dem Go-live aus dem Scheitern zu lernen.

• Kapazitäts- und Ressourcenplanung unter unterschiedlichen Bedingungen

  Eine radiologische Abteilung eines Krankenhauses, dokumentiert in der Forschung der Universität Hasselt zur datengetriebenen Prozesssimulation im Gesundheitswesen, nutzt Simulation, um unterschiedliche Bedingungen für Personalstärke und Planungsmuster zu testen. Die Simulation erzeugt quantitative Indikatoren – durchschnittliche Wartezeit pro Modalität, Ressourcenauslastung und Vorlaufzeit –, die Entscheidungen über Schichtmodelle unterstützen, ohne dass die Abteilung ein Personalexperiment mit echten Patienten durchführen muss. Entscheidungen über Ressourcenzuweisungen ohne diese Daten sind im Grunde Schätzungen zu Schichtmodellen, die als Planung verkleidet sind.

• Risiko- und Auswirkungsanalyse für Volumenspitzen und Richtlinienänderungen

  Eine Leiterin des Support-Betriebs möchte wissen, was mit Warteschlangentiefe und SLA-Einhaltung passiert, wenn das Volumen eingehender Tickets im nächsten Quartal aufgrund einer Produkteinführung um 40 % steigt. Sie kann unterschiedliche Bedingungen testen – zusätzliches Personal, geänderte Routing-Regeln, längere Abdeckungszeiten – und dies als risikofreie Methode nutzen, bevor sie Budget fest zusagt. Die Position des Engpasses verschiebt sich je nachdem, welche Variante sie ausführt, und die Simulation zeigt, dass die Änderung der Routing-Regel die Personalaufstockung bei zwei Dritteln der Kosten übertrifft. Das ist ein präskriptives Ergebnis eines What-if-Tests, keine Tabellenkalkulationsschätzung.

• Digitale Transformation und Process Mining zum Testen von Automatisierung und Routing-Regeln

  Ein Manager für Process Excellence verfügt über Event-Logs aus mehreren Monaten aus einem CRM- und Helpdesk-System. Wie die ScienceDirect-Forschung zu Frameworks für digitale Zwillinge zeigt, können Simulationsmodelle, die auf Live-Event-Log-Daten basieren, die kontinuierliche Optimierung von Auftragsrouting und Terminplanung unterstützen – nicht nur einmalige Neugestaltungen. Der Manager nutzt die Event-Logs, um ein Simulationsmodell aufzubauen, das das tatsächliche Prozessverhalten widerspiegelt, und testet und analysiert anschließend vorgeschlagene SLA-Änderungen vor der Einführung. Hier verbinden sich Process Mining und Simulation: Mining liefert Ihnen das Ist-Modell; Simulation ermöglicht Ihnen, mit der Soll-Version zu experimentieren und dabei reale Geschäftsprozesse als Eingabe zu verwenden.

  Ich habe dieses Setup auch im Kontext von Latenode funktionieren sehen. Ein Team, das die Automatisierungsebene von Latenode nutzt, um Event-Logs aus CRM- und Helpdesk-Systemen regelmäßig abzurufen und diese Daten anschließend an eine Simulationsebene weiterzugeben, um Änderungen an Routing-Regeln zu testen, eliminiert die 80 % der Zeit, die normalerweise für den Abgleich von Zeitstempeln und Feldformaten aus drei unterschiedlichen Tools aufgewendet werden. Genau diese Datenaufbereitung verhindert bei den meisten Teams überhaupt erst, dass sie simulieren – nicht die Simulation selbst. Die Workflow-Automatisierung macht die Schleife wiederholbar, statt sie zu einem einmaligen Projekt zu machen. Business-Automatisierung zur Versorgung des Simulationszyklus einzusetzen, ist der Teil, über den niemand spricht, wenn beschrieben wird, wie sich Workflows verbessern lassen. Doch genau dort entwickeln Teams entweder eine Gewohnheit für fundierte Entscheidungen oder bleiben bei einmaligen Experimenten stecken.

Drei Missverständnisse über die Simulation von Geschäftsprozessen, die die Einführung verzögern

Ich höre Varianten dieser drei Einwände in Support- und Onboarding-Gesprächen häufig genug, dass sie einen eigenen Abschnitt verdienen. Es sind keine Strohmann-Argumente. Es sind reale Gründe, warum Teams nicht starten.

Missverständnis 1: Simulation bedeutet lediglich, bessere Prozesskarten zu zeichnen. Hier liegt die Verwechslung zwischen Flussdiagrammen und Geschäftsprozessen vor. Simulation erfordert ausführbare Modelle mit angehängten zeitbezogenen Daten – Eingangsverteilungen, Varianzen von Bearbeitungszeiten, Verfügbarkeitspläne für Ressourcen und Routing-Wahrscheinlichkeiten. Ein Flussdiagramm ist ein nützlicher Ausgangspunkt. Es ist keine Simulation. Prozesssimulationen anhand eines Diagramms ohne quantitative Daten auszuführen, gleicht dem Testen einer Produktlaunch-Strategie mit einer PowerPoint-Folie. Visuell stimmig, operativ bedeutungslos.

Missverständnis 2: Simulation ist nur für große oder komplexe Organisationen gedacht. Dies kommt bei SMB-Inhabern und kleineren RevOps-Teams ständig zur Sprache. Moderne Simulationstools und der SaaS-Markt, der sie unterstützt, sind nicht für reine Enterprise-Probleme skaliert. Die GetLatka-Daten zu rund 20 SaaS-Unternehmen, die in diesem Bereich etwa 400 Kunden bedienen, deuten darauf hin, dass sich die tatsächlichen Käufer über Organisationsgrößen hinweg verteilen und nicht in der Enterprise-IT konzentrieren. Die bestehenden Geschäftsprozesse eines 30-köpfigen Operations-Teams mit einem echten Engpass sind genau die Art Problem, für die Simulationstools entwickelt wurden. Die eigentliche Hürde ist nicht die Unternehmensgröße. Es ist die Annahme, die Simulation von Prozessen erfordere ein Spezialistenteam und ein sechsmonatiges Projekt.

Missverständnis 3: Die Automatisierung eines Prozesses macht Simulation überflüssig. Das ist das gefährlichste Missverständnis. Die Überlegung lautet: Wenn der Prozess automatisiert ist, ist er dokumentiert und deterministisch – was gibt es dann noch zu testen? Die Antwort lautet: alles, was an den Rändern passiert. Automatisierte Prozesse treffen weiterhin auf Volumenspitzen, Routing-Logik, die nicht im großen Maßstab getestet wurde, zeitliche Kollisionen und reale Bedingungen, die im neuen Prozessdesign nicht auftauchten. Einen Prozess zu testen, verändert nur die Geschwindigkeit, mit der er läuft. Es testet nicht, was er unter Bedingungen tut, die das Automatisierungsteam nicht erwartet hat. Die Teams, die ich bei automatisierten Prozessen auf Simulation verzichten sah, entdecken ihre Edge Cases im produktiven Einsatz – meist zu einem besonders passenden Zeitpunkt wie einem Produktlaunch oder einer Spitze zum Quartalsende.

🤔 Moment.
Das Paradox automatisierter Prozesse besteht darin, dass Dokumentation und Automatisierung oft mehr Vertrauen schaffen, als die Situation rechtfertigt. Ein gut dokumentierter und reibungslos laufender Prozess wirkt bewiesen. Doch Dokumentation beschreibt die Absicht, und Automatisierung führt sie im großen Maßstab aus – keines von beiden testet Varianten, ohne den Live-Betrieb zu beeinträchtigen. Die vor dem Go-live nicht simulierten Edge Cases verschwinden nicht, weil der Workflow automatisiert ist. Sie warten darauf, dass die richtigen Bedingungen eintreten.

Software für Geschäftsprozesssimulation: So sieht der Markt 2026 aus

Das wichtigste Marktsignal zuerst: GetLatka erfasst mit Stand Mai 2026 ungefähr 20 SaaS-Unternehmen, die speziell in der Kategorie Software für Geschäftsprozesssimulation tätig sind, mit einem gemeinsamen Jahresumsatz von rund 301 Mio. US-Dollar. Das ist kein riesiger Markt. Aber es ist ein realer Markt mit ausreichend kommerzieller Aktivität, um darauf hinzuweisen, dass Prozessmodellierungssoftware sich vom Spezialtool für Wirtschaftsingenieure und akademische Forschende zu etwas entwickelt hat, das Operations-Teams tatsächlich kaufen und nutzen.

Was moderne Simulationstools von älteren Diagrammtools unterscheidet, ist nicht primär die visuelle Ebene. Die meisten BPM-Plattformen können einen Prozessablauf zeichnen. Das entscheidende Unterscheidungsmerkmal ist, was das Tool mit dem Diagramm macht, nachdem es erstellt wurde.

Software für Geschäftsprozesssimulation der ersten Generation erforderte den manuellen Aufbau von Modellen: Jemand nahm das Prozessdiagramm und fügte Verteilungen, Ressourcenparameter und Routing-Wahrscheinlichkeiten per Hand hinzu. Das war technisch korrekt, aber praktisch langsam und konnte mit Prozessen, die sich häufig änderten, nicht Schritt halten. Die Arbeit für Modellierung und Prozessabgleich dauerte länger als die Simulation selbst.

Die Funktion, die Tools der aktuellen Generation unterscheidet, ist automatisierte Erkennung: Die ScienceDirect-Forschung zu Frameworks für digitale Zwillinge zeigt, dass Simulationsmodelle heute automatisch aus Event-Logs erstellt werden können. Dabei werden tatsächliche Verteilungen von Bearbeitungszeiten und Eingangsmuster aus aufgezeichneten operativen Daten importiert, statt dass Analysten diese schätzen müssen. Diese Veränderung ist wichtig, weil sie den Simulator für iterative Entscheidungsfindung nutzbar macht, statt nur für einmalige Neugestaltungsprojekte.

Eine praktische Betrachtungsweise dafür, worauf Sie bei einer BPM-Plattform mit Simulationsfunktionen achten sollten:

Die Frage von Enterprise-Architekten, die in Beschaffungsgesprächen meist aufkommt, betrifft die Integration: Verbindet sich der Simulator mit operativen Datenquellen oder erfordert er manuellen Export und Import? Das ist 2026 die eigentliche Trennlinie zwischen Tools, die iterative Simulation unterstützen, und Tools, die nur einmalige Projekte ermöglichen.