Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 3 Nächste Version anzeigen »

Inhaltsverzeichnis

Warum Rücksprünge schlecht darin sind die Wirklichkeit abzubilden

Das nebenstehende Prozessmodell wurde modelliert. Inhaltlich wird hier ein Dokument entgegengenommen, das überprüft und anschließend in ein EDV-System übernommen werden soll. Wenn die Prüfung nicht erfolgreich ist, wird das Dokument abgelehnt und der Sender muss das Dokument überarbeiten und erneut einreichen. Dies geschieht hier laut Modellierer in 80% der Prüfungen.

Gehen wir hier nun erstmal davon aus, dass der Modellierer verdeutlichen wollte, dass das Dokument in den seltensten Fällen sofort erfolgreich überprüft werden kann und daher in 4 von 5 Fällen zurück an den Sender geht. Im Anschluss daran kann das Dokument aber dann in der Regel erfolgreich überprüft werden. Es wird also von etwa 1-2 Schleifendurchgängen ausgegangen.

Schauen wir uns nun an, welche Aussage nun durch das Modell getroffen wird: In 4 von 5 Fällen geht das Dokument wie vom Modellierer vorgesehen zurück an den Sender. Nach der zweiten Prüfung gehen nun aber erneut 4 von 5 Fällen zurück an den Sender zur erneuten Überarbeitung. Dies wiederholt sich in der Theorie nun unendlich lange. Rein mathematisch ergeben sich dadurch im Durchschnitt 5 Schleifendurchgänge pro Prozessausführung. Dies sind vermutlich deutlich mehr als vorgesehen.

Welchen Fehler hat der Modellierer hier also gemacht? Das Problem bei der Modellierung von Rücksprungen ist, dass grundsätzlich nur eine einzelne Rücksprungwahrscheinlichkeit hinterlegt wird. In der Praxis handelt es sich jedoch meist um bedingte Wahrscheinlichkeiten - d.h. dass die Wahrscheinlichkeit für einen erneuten Rücksprung eigentlich mit jedem Schleifendurchgang sinken sollte. In unserem Beispiel sieht dies wie folgt aus: Das Dokument geht nach der Überprüfung zurück an den Sender und dieser muss das Dokument überarbeiten und erneut einreichen. Er wird die bekannten Fehler also korrigieren und ein Dokument einreichen, welches diese Fehler nicht mehr enthält. Außerdem wird er in der Regel noch sorgfältiger Arbeiten und sich beim nächsten Versuch “mehr Mühe geben”. Die Chance, dass die Prüfung erneut fehlschlägt (das also neue/unbekannte Fehler gefunden werden), sollte also deutlich geringer als 80 % ausfallen.

Wie wir bereits erkannt haben, hat dieser Unterschied zur Folge, dass die Aktivität gemäßt der Personalkapazitätsanalyse, deutlich mehr Kapazität binden würde, als erwartet. Dies kann zwar in manchen Fällen die gewünschte Aussage des Modellierers sein, häufig können die Folgen jedoch unbeabsichtigt sein. In unserem Beispiel würde die Prüfaktivität mit 3 Minuten Bearbeitungszeit pro Jahr mit 1.500 Minuten zu Buche schlagen, anstatt der erwarteten 600 Minuten (bei ca. 2 erwarteten Schleifendurchläufen).

Da eine mit jedem Schleifendurchgang reduzierende Wahrscheinlichkeit auf einen erneuten Schleifendurchgang nicht abbildbar ist, empfiehlt es sich in vielen Fällen zu alternativen Modellierungsweisen zu greifen. Zwei Alternativen finden Sie im folgenden Abschnitt. Sollten die Rücksprünge hingegen explizit gewünscht sein, finden Sie weiter unten Hinweise dazu, wie die Prozessplattform bei der Analyse mit diesen umgeht.

Alternativen zur Modellierung von Rücksprüngen

Um die oben beschriebe Problematik bei Rücksprüngen mit hohen Wahrscheinlichkeiten aufzulösen, empfiehlt es sich den Sachverhalt auf eine andere Art und Weise zu modellieren. Im nachfolgenden werden zwei Möglichkeiten aufgeführt:

Nutzung von Schleifen

Mithilfe des Schleifenkonzeptes der BPMN, kann direkt an der Aktivität eingestellt werden, dass diese mehrmals ausgeführt werden soll. Wenn wie in obigem Beispiel, die Anzahl der erwarteten Schleifendurchläufe eigentlich bekannt ist (ca. 2), kann mit BPMN-Schleifen gearbeitet werden. Das Ergebnis könnte zum Beispiel so, wie das nebenstehende Modell aussehen. Beim Teilprozess ist die Anzahl der Schleifenwiederholungen auf 2 gesetzt. Das Analyseergebnis der Prüfungsaktivität entspricht mit 600 Minuten unseren Erwartungen. (Anstatt die Schleife in einen Teilprozess zu modellieren, könnte auch an den Bausteinen jeweils eine Schleife konfiguriert werden)


Explizite Modellierung von mehreren Schleifendurchläufen

Anstatt einen Rücksprung zu modellieren, können die Schleifendurchläufe auch explizit aus modelliert werden. In diesem Fall würde das bedeuten, dass für Erst- und Zweiprüfung jeweils eigene Aktivitäten modelliert werden. Ob die Zweitprüfung stattfindet, entscheidet eine Verzweigung, die die 80% aus dem obigen Beispiel enthält. Es wäre nun möglich, weitere Durchläufe zu modellieren. Diese Variante hat natürlich Ihre Grenzen, gerade wenn es um viele Schleifendurchläufe geht, liegt aber häufig näher an der Realität als ein Rücksprung mit hoher Wahrscheinlichkeit. So modelliert binden die Prüfungen im Jahr durchschnittlich 540 Minuten Arbeitszeit. Dies Variante bildet die erwarteten 1-2 Schleifendurchläufe am genausten ab. Je nachdem wie viele Schleifendurchläufe auf diese Weise dargestellt werden, kann allerdings die Lesbarkeit und die Übersichtlichkeit des Modells sinken.

Wie geht die Prozessplattform mit Rücksprüngen bei der Analyse um?

Zur Ermittlung der Lastfaktoren einzelner Aktivitäten innerhalb eines BPMN-Modells werden verschiedene Prozessverläufe durch die Analyse simuliert. Dabei wird der Prozessfluss Schritt für Schritt von einem so genannten “Token” vom Start-Ereignis bis zum Endereignis durchlaufen. Das Token folgt dabei dem Sequenzfluss durch das Modell. Dabei werden Verzweigungen/Rücksprünge etc. beachtet, sodass bestimmte Aktivitäten öfter besucht werden können als andere.
Bei der Analyse kann es nun geschehen das ein Token durch einen Rücksprung innerhalb des Modells in einer theoretisch unbegrenzten Schleife landet. Mit unbegrenzten Ressourcen und Zeit, wäre es zwar möglich alle Rücksprünge mit < 100% mit beliebiger Genauigkeit zu berechnen (also alle die keine “echte” Endlosschleife sind), dies erfolgt an dieser Stelle aus Performanzgründen nicht, da die steigende Wartezeit in keinem guten Verhältnis zum Nutzen stehen würde. Erreicht die Prozessplattform bei der Analyse einen bestimmten Schwellwert für die Rücksprungwahrscheinlichkeit (~80%), dann wird die Analyse mit der Fehlermeldung “X ist Teil einer Endlosschleife” abgebrochen. Hier wurde versucht einen guten Kompromiss zwischen Geschwindigkeit und Genauigkeit zu finden.

  • Keine Stichwörter