Mit Hilfe von Prozessmodellen erhalten wir eine statische Sicht auf unsere Prozessdefinition. Wir wissen in welcher Reihenfolge welche Aktivitäten ausgeführt werden sollen, wodurch Prozesse gestartet werden und was die Ergebnisse sind. Auch Ausnahmebehandlungen oder die Kommunikation mit Partnern lassen sich mit der BPMN 2.0 komfortabel darstellen.

Was uns aber hier noch fehlt, ist eine Betrachtung des dynamischen Laufzeitverhaltens. Unsere bloßen Prozessdefinitionen sagen uns nichts über die tatsächliche Laufzeit von Prozessen, über die Auslastung von Ressourcen oder über kritische Rückkopplungen während der Ausführung.

Mit Hilfe der Simulationstechnik kann das Laufzeitverhalten von Prozessen analysiert werden. Es gibt einige Tools auf dem Markt, die sich die Simulation auf die Fahne geschrieben haben. Doch Vorsicht! Nicht überall wo Simulation draufsteht, ist auch Simulation drin. Desöfteren schon musste ich feststellen, dass eine bloße Animationsfunktion, bei der einzelne Prozesselemente aufblinken, wenn sie „an der Reihe sind“, als Simulation verkauft wird. Auch gibt es große Unterschiede, was für Funktionen eine Software bietet und wie brauchbar die SImulationskomponente für euren Einsatzbereich ist.

Bei einer „richtigen“ Simulation werden Statistiken erzeugt – es werden Prozesskennzahlen errechnet. Dafür wird eine Menge von Prozessinstanzen Schritt-für-Schritt durchgespielt. Ganz ähnlich wie bei einer Animation, jedoch viel schneller. Wir gucken bei einer Simulation auch gar nicht zu: Typischerweise berechnen wir das Prozessverhalten für ganze Geschäftsjahre in wenigen Minuten. Es können zahlreiche Prozesse parallel simuliert werden, die sich gar nicht parallel mit dem Auge verfolgen lassen. Das Ergebnis eins Simulationsexperimentes wird in einem Report dargestellt, aus dem wir die für uns interessanten Informationen heraussuchen müssen. Am komfortabelsten ist es, wenn uns die Ergebnisse grafisch aufbereitet in die Prozessdefinition hineingezeichnet werden oder wir uns die Ergebnisse direkt im Excel-Format exportieren können.

Was sind die relevanten Ergebnisse? Wie auch bei der Modellierung von Prozessen müssen wir uns auch bei der Simulaion klar vor Augen halten, welche Ziele wir verfolgen. Der Detailgrad bei der Modellierung ist ja davon abhängig, ob wir als Zielsetzung z.B. eine Kommunikationsgrundlage für die Schulung unserer Mitarbeiter, die Erfüllung bestimmter Normen und Auflagen  oder ausführbare Workflow Modelle vor Augen haben. Wenn wir uns die Simulation als Ziel nehmen, müssen wir zusätzlich festlegen, welche Fragestellung wir mit der Simulation untersuchen wollen! Hiervon abhängig müssen wir das passende Abstraktionsniveau für unsere Prozessmodelle wählen und die benötigten Daten in unserer Organisation zusammensuchen.

Ziele der Simulation aus Joschko (2014)
Ziele der Simulation aus Joschko (2014)

Die Fragestellungen die wir mit Simulation untersuchen können, sind vielfältig:

  • Ich habe mir eine Prozessalternative überlegt. Ist die wirklich besser als meine Ist-Prozesse?
  • Wie verhalten sich meine Prozesse unter einer geänderten Auftragslast? Vertragen meine Prozesse einen Stresstest?
  • Wie sind die Prozesslaufzeiten und Wartezeiten?
  • Welche Kennzahlen haben meine Prozesse? Z.B. Kosten und Effizienz?
  • Wie ist die Auslastung meiner Mitarbeiter, Maschinen und sonstigen Ressourcen? Kann ich Engpässe beseitigen? Kann ich Ressourcen irgendwie besser allokieren?
  • Gibt es kritische Bestandteile in meinen Prozessdefinitionen? Z.B. Deadlocksituationen im Nachrichtenaustausch?
  • Was kosten meine Prozesse? Wie kann ich leistungsmengeninduzierte und leistungsmengenneutrale Kosten aufwandsgerecht verteilen?

Abhängig von der Fragestellung sind natürlich die Daten die wir zusammentragen müssen. Grundsätzlich muss ich für eine Simulation mehr Daten zusammentragen, als für eine bloße Modellierung. Damit die Schritt-für-Schritt-Ausführung klappt, muss ich definieren, wie lange eine Aktivität dauert oder wie häufig ein Ereignis ausgelöst wird. Auch Wahrscheinlichkeiten oder komplexe Bedinungen an Gateways müssen definiert, damit die Simulation entscheiden kann, wo die jeweilige Prozessinstanz langläuft.

Um eine möglichst realistisches Abbild des Laufzeitverhaltens der realen Prozesse zu erreichen, nutzen wir stochastische Verteilungen. Ein Mitarbeiter braucht nämlich nicht immer gleich lange für die Bearbeitung einer Aufgabe, das hängt schon alleine von seiner persönlichen Tagesform ab. Auch wann und wie häufig eine Kundenanfrage reinkommt, können sie zwar im Durschnitt recht genau angebene, sie können jedoch die genau Uhrzeit nicht vorhersehen. Gerade in solchen Schwankungen können zum Beispiel kritische Rückkopplungen ihre Uhrsache haben. Je nachdem welche Daten uns zur Verfügung stehen, wählen wir daher zum Beispiel eine Normalverteilung (mit Mittelwert und Standardabweichung), eine Gleichverteilung (mit Unter- und Obergrenze) oder eine Dreiecksverteilung (mit Untergrenze, Obergrenze und Peak). Der Aufwand hierfür ist natürlich beträchtlich, aber schon die Erfassung dieser Parameter bietet uns einen zusätzlichen Erkenntnisgewinn über unsere Prozessse.

Da wir mit Stochastik arbeiten ist es notwendig lange Experimentläufe zu machen. Ein Experiment über einen Tag hat nahezu keine Aussagekraft – es bietet nur einen zufälligen Ausschnitt aus dem möglichen Ergebnisraum. Wenn wir jedoch über ganze Geschäftsjahre simulieren, wird so ziemlich jede Ausnahmesituation einmal auftreten – und wir können quantifizieren, wie häufig das geschieht!

Meine favorisierte Softare IYOPRO bietet eine fundierte Simulationstechnologie. Dafür wurde in IYOPRO die Simulationsbibliothek DESMO-J integriert, welche an der Universität Hamburg entwickelt wurde und weltweit in Forschung, Lehre und kommerziellen Produkten wie IYOPRO im Einsatz ist. Ich werde in Zukunft einige Artikel schreiben, die sich mit der Simulation mit Hilfe von IYOPRO beschäftigen.