Ereignisdiskrete Simulation für Geschäftsprozesse

Inhaltsverzeichnis+

Warum „diskret“ und warum „ereignisorientiert“

Es gibt zwei Wege, Zeit in einer Simulation zu behandeln.

Zeitschritt-orientiert: Die Uhr läuft in festen Schritten (jede Minute, jede Sekunde), und bei jedem Schritt wird geprüft, was passiert ist. Einfach zu programmieren, verschwenderisch im Betrieb: Zwischen zwei Ereignissen in einem Freigabeprozess liegen Stunden, in denen nichts passiert und trotzdem gerechnet wird.

Ereignisorientiert: Die Uhr springt zum Zeitpunkt des nächsten geplanten Ereignisses. Zwischen den Ereignissen ändert sich nichts, also muss auch nichts gerechnet werden.

Ereignisliste (nach Zeit sortiert):
  09:14  Ankunft Vorgang #418
  09:22  Bearbeitungsende #402 an Schritt "Prüfung"
  09:40  Schichtwechsel Freigabe
  ...
Uhr springt auf 09:14, verarbeitet, plant Folgeereignisse ein, springt weiter.

„Diskret“ heisst: Der Zustand ändert sich sprunghaft an einzelnen Zeitpunkten, nicht kontinuierlich. Das passt genau zu Geschäftsprozessen. Ein Antrag ist bearbeitet oder nicht, halb bearbeitet gibt es nicht.

Die vier Bausteine

Die wichtigste Eigenschaft: Warteschlangen werden nicht modelliert, sie entstehen. Wer eine Liegezeit von drei Tagen als festen Schritt einträgt, hat das Ergebnis vorausgesetzt statt es zu berechnen. Er kann anschliessend nicht zeigen, wie sich diese Zeit ändert, wenn Kapazität oder Streuung sich ändern.

Die drei Entscheidungen, an denen Modelle scheitern

1. Welche Verteilung?

Für Ankunftsabstände: exponentiell. Das ist die Standardannahme, wenn Vorgänge unabhängig voneinander eintreffen, etwa Rechnungen von verschiedenen Lieferanten oder Tickets von verschiedenen Nutzern. Sie erzeugt genau das Verhalten, das man im Postkorb beobachtet: lange ruhige Strecken, dann drei auf einmal.

Nicht exponentiell ist der Eingang, wenn er getaktet ist: ein Sammellauf am Monatsende, eine tägliche Übergabe um 8 Uhr. Dann brauchen Sie einen Kalender, keine Verteilung.

Für Bearbeitungsdauern: rechtsschief. Lognormal oder Gamma. Wenn Sie nur Schätzungen haben, dreiecksverteilt aus Minimum, wahrscheinlichstem Wert und Maximum. Der Grund: Bearbeitungszeiten haben eine harte Untergrenze und einen langen rechten Ausläufer. Eine Normalverteilung erzeugt negative Dauern und unterschätzt die Ausreisser, die die Warteschlange erzeugen.

Faustregel für die Praxis: Wenn Sie nur „5 bis 15 Minuten“ wissen, nehmen Sie eine Dreiecksverteilung mit Modus bei 8. Die Wahl zwischen Lognormal und Gamma bewegt das Ergebnis weniger als die Frage, ob Sie überhaupt streuen lassen.

2. Aufwärmphase

Eine Simulation startet mit leeren Warteschlangen. Das ist ein Zustand, den Ihr Prozess nie hat. Die ersten Modelltage sind deshalb systematisch zu gut.

Behandlung: Entweder die ersten Tage aus der Auswertung ausschliessen (Warm-up), oder mit einem realistischen Anfangsbestand starten. Für Prozesse mit Auslastung deutlich unter 85 % genügen wenige Tage; nahe an der Grenze kann die Einschwingzeit Wochen betragen.

Woran Sie es merken: Wenn der Durchschnitt der ersten Woche deutlich unter dem der zweiten liegt, war die Aufwärmphase zu kurz.

3. Wie viele Läufe?

Ein einzelner Lauf ist eine Stichprobe von eins. Er sagt über den Prozess so viel wie ein einzelner Arbeitstag. Wiederholt wird mit neuen Zufallszahlen, bis das Ergebnisband stabil ist.

Praktisches Kriterium: Verdoppeln Sie die Anzahl der Läufe. Wenn sich P50 und P90 dabei um weniger als ein paar Prozent bewegen, reicht die Zahl. Für Geschäftsprozesse liegt sie typischerweise bei mehreren hundert.

Wichtiger als die genaue Zahl: Dass überhaupt wiederholt wird und dass die Ausgabe ein Band ist. Eine Simulation, die eine einzelne Zahl ausgibt, hat den Zweck des Verfahrens verfehlt.

Der Vergleich der Sichtweisen

Für Geschäftsprozesse ist die prozessorientierte Sicht die natürlichere: Sie schreiben auf, was einem Vorgang passiert, und das entspricht genau der Art, wie ein Fachbereich seinen Ablauf beschreibt.

Validierung: drei Prüfungen

1. Little's Law. Bestand ÷ Durchsatz muss ungefähr die Durchlaufzeit ergeben, im Modell wie in der Wirklichkeit. Diese Prüfung gilt ohne Annahmen über Verteilungen und ist deshalb die stärkste, die es gibt.

2. Auslastung gegen Handrechnung. ρ = Bedarf ÷ Kapazität lässt sich je Schritt mit einem Taschenrechner nachrechnen. Weicht das Modell stark ab, ist eine Verzweigung oder ein Kalender falsch.

3. Extremwerttest. Setzen Sie die Kapazität eines Schritts auf das Doppelte. Wenn sich nichts ändert, war dieser Schritt nie der Engpass. Wenn Sie das nicht erwartet haben, stimmt Ihr Modell nicht mit Ihrer Vorstellung überein. Genau dann fängt die interessante Diskussion an.

Wo DES nicht das richtige Verfahren ist

• Beteiligte treffen eigene Entscheidungen, die den Ablauf verändern (Kunden brechen ab, Bearbeiter wählen sich Fälle aus) → agentenbasierte Simulation.
• Es geht um Bestände und Rückkopplungen über Jahre (Personalaufbau, Marktdynamik) → Systemdynamik.
• Es gibt keine Warteschlangen, weil Kapazität reichlich vorhanden ist → eine Addition genügt.
• Die Frage lautet, was tatsächlich passiert ist → Process Mining. DES rechnet eine Annahme, kein Protokoll.