Wie die Simulation Engine funktioniert
Die Simulations-Engine verstehen
ProcessMind verwendet eine Discrete Event Simulation (DES)-Engine zur Modellierung Ihrer Prozesse. Wenn Sie wissen, wie diese Engine arbeitet, können Sie Simulationen gezielt konfigurieren und Ergebnisse korrekt auswerten.
Was ist Discrete Event Simulation?
Bei Discrete Event Simulation ändert sich der Systemzustand nur bei bestimmten Events – die Uhr springt von Event zu Event, dazwischen passiert nichts. Diese Methode eignet sich ideal für Geschäftsprozesse, weil:
- Aktivitäten klare Start- und Endzeiten haben
- Ressourcen zu bestimmten Zeitpunkten zugewiesen und freigegeben werden
- Cases zu festgelegten Zeiten ein- und austreten
Warum diskrete Events?
Im Gegensatz zur kontinuierlichen Simulation (wie etwa in Physik oder Strömungslehre) benötigen Geschäftsprozesse kein laufendes Zeitmodell. Ein Kreditantrag wird nicht langsam von “eingereicht” zu “genehmigt” – er wechselt den Status bei bestimmten Events.
Der zentrale Event-Loop
Die Simulation arbeitet mit einer einfachen, aber wirkungsvollen Schleife:
1. Initialisieren: Startbedingungen setzen
2. Nächstes Event wählen: Frühestes geplantes Event aus der Prioritätswarteschlange entnehmen
3. Zeit fortschalten: Simulationsuhr auf die Zeit des Events setzen
4. Event bearbeiten: Event behandeln (Aktivität starten, abschließen usw.)
5. Neue Events planen: Abhängig vom Ergebnis neue Events hinzuplanen
6. Wiederholen: Bis Endzeit oder maximale Event-Anzahl (2.000.000) erreicht ist
7. Output: Das vollständige Event-Log erstellen
Event-Typen
Die Simulation erzeugt und verarbeitet verschiedene Event-Typen:
| Event-Typ | Beschreibung |
|---|---|
| Case Arrival | Ein neuer Case startet am Start Event im Prozess |
| Activity Start | Ein Case startet eine Aktivität (Ressourcen werden reserviert) |
| Activity Complete | Ein Case schließt eine Aktivität ab (Ressourcen werden freigegeben) |
| Gateway Evaluation | Entscheidungspunkt für die Wahl des nächsten Pfads |
| Case Complete | Ein Case erreicht ein End Event |
Case-Generierung und -Ankunft
Cases gelangen über Start Events in Ihr BPMN-Modell in die Simulation. Das Ankunftsmuster wird über die Case-Generierungsverteilung gesteuert.
Standard-Ankunftsmuster
Standardmäßig kommen Cases nach einer Poisson-Verteilung mit einer Rate von 1 Case pro Stunde. Das erzeugt realistische, zufällige Abstände, wie sie in modernen Geschäftsprozessen üblich sind.
Ankünfte anpassen
Sie können verschiedene Ankunftsmuster über die in der Distributions -Dokumentation beschriebenen Verteilungen einstellen.
Case-Fluss im Prozess
Sequence Flows
Schließt ein Case ein Element ab, folgt er direkt dem ausgehenden Sequence Flow. Gibt es nur einen Pfad, wird dieser automatisch genommen.
Gateway-Verhalten
Gateways steuern, wie Cases sich verzweigen und zusammengeführt werden:
| Gateway-Typ | Verhalten |
|---|---|
| XOR (Exclusive) | Genau ein ausgehender Pfad wird per gewichtetem Zufall gewählt. Wahrscheinlichkeiten werden als relative Gewichte behandelt und automatisch normalisiert. |
| AND (Parallel) | Alle ausgehenden Pfade werden parallel genommen. Der Case teilt sich in parallele Tokens auf. |
| OR (Inclusive) | Zufällige Auswahl von Pfaden – mindestens ein Pfad wird immer genommen. |
| Event-Based | Zufällige Auswahl unter den verfügbaren Events. |
Wahrscheinlichkeiten einstellen
Bei XOR-Gateways vergeben Sie für jeden Flow Wahrscheinlichkeiten – sie sind relative Gewichte:
- Flows mit 70, 20 und 10 werden als 70 %, 20 %, 10 % normalisiert
- Auch Werte wie 7, 2 und 1 ergeben dasselbe Verhältnis
- Jeder Flow braucht eine Wahrscheinlichkeit; nicht definierte Flows erhalten den Restwert
Aktivitätenausführung
Erreicht ein Case eine Task (Aktivität), folgt die Engine dieser Abfolge:
1. Ressourcenverfügbarkeit prüfen
Hat die benötigte Ressource Kapazität frei?
2. Falls nötig: Case einreihen
Ist keine Ressource verfügbar, kommt der Case in die Warteschlange. ProcessMind verwendet FIFO (First In, First Out) – die Bearbeitung erfolgt nach Eingangsreihenfolge.
3. Ressourcen zuweisen
Sind Ressourcen frei, werden die benötigten Einheiten für diesen Case reserviert.
4. Bearbeitungszeit bestimmen
Die Engine zieht einen Wert aus der eingestellten Bearbeitungszeit-Verteilung. Das legt fest, wie lange die Aktivität dauert.
5. Abschluss-Event planen
Ein Abschluss-Event wird der Event-Queue bei current_time + processing_time hinzugefügt.
6. Ressourcen freigeben
Wird das Abschluss-Event ausgelöst, stehen die Ressourcen wieder anderen Cases zur Verfügung.
Minimale Bearbeitungsdauer
Alle Aktivitäten haben zur Sicherstellung eindeutiger Timestamps und für realistisches Verhalten eine Mindestdauer von 1 Sekunde – selbst bei einer Verteilung mit 0 Sekunden.
Skip Chance
Aktivitäten können mit einer Skip Chance (0–100%) versehen werden. Wird eine Aktivität übersprungen:
- Der Case geht sofort zum nächsten Element
- Es werden keine Ressourcen belegt
- Es vergeht keine Zeit (außer der Mindestdauer von 1 Sekunde)
- Die Aktivität erscheint im Log mit minimaler Dauer
So können reale Szenarien abgebildet werden, in denen einzelne Schritte übersprungen werden.
Zeitmanagement
Simulationsuhr
Die Simulation führt eine virtuelle Uhr, die diskret von Event zu Event springt. Liegt das nächste Event zum Beispiel bei 10:35 Uhr und aktuell ist 10:30 Uhr, springt die Uhr direkt auf 10:35 Uhr.
Zeiteinheiten
Alle Zeitangaben werden intern in konsistente Einheiten umgerechnet. Sie können folgende Angaben machen:
- Sekunden
- Minuten
- Stunden
- Tage
- Wochen
- Monate
Periodizität und Zeitfenster
Parameter können je nach Simulationszeit variieren, z. B.:
- Unterschiedliche Ankunftsraten für Werktage und Wochenenden
- Unterschiedliche Bearbeitungszeiten für Früh- und Spätschichten
- Unterschiedliche Ressourcenkapazität zu Spitzenzeiten
Details zur Konfiguration finden Sie in der Periodicity -Dokumentation.
Ressourcenmanagement
Ressourcenpools
Jede Ressource besitzt eine definierte Kapazität – also wie viele Cases sie gleichzeitig übernehmen kann.
Warteschlangen-Management
Übersteigt die Nachfrage die Kapazität, warten Cases in einer Queue. ProcessMind verwendet das FIFO (First In, First Out)-Prinzip, sodass die Bearbeitung immer nach Reihenfolge des Eingangs erfolgt.
Event-Log-Erstellung
Während der Simulation wird jede Ausführung einer Aktivität im Output-Event-Log dokumentiert:
| Feld | Beschreibung |
|---|---|
| Case ID | Eindeutige Kennung für jeden Case (laufend erzeugt) |
| Activity | Name des BPMN-Elements |
| Start Timestamp | Startzeitpunkt der Aktivität |
| Complete Timestamp | Abschlusszeitpunkt der Aktivität |
| Resource | Ausführende Ressource der Aktivität |
| Attributes | Case-Attribute zum jeweiligen Zeitpunkt |
Dieses Log entspricht Standard-Event-Log-Formaten und kann mit allen ProcessMind-Tools analysiert werden.
Simulationsgrenzen
| Limit | Wert | Zweck |
|---|---|---|
| Max Events | 2.000.000 | Verhindert endlose Simulationen |
| Min Duration | 1 Sekunde | Stellt eindeutige Timestamps sicher |
Klein starten, dann skalieren
Beginnen Sie mit einer kurzen Simulationsdauer (einige Tage oder Wochen), um Ihre Einstellungen zu prüfen. Wenn das Modell korrekt läuft, verlängern Sie den Zeitraum.