Ausnahmen sind immer und überall. Im Rahmen des Prozessmanagements kann dies zu einem Fluch werden. Wer versucht, sämtliche Eventualitäten in seinen Geschäftsprozessen abzubilden oder gar im Zuge der Automatisierung zu standardisieren, wird zwangsläufig daran scheitern. (Gerhard Wohland nennt dies die „Blaue Falle“ – mehr dazu hier…). Prozessmodelle werden niemals fertig, da es immer noch irgendwelche Ausnahmesituationen gibt, die nicht berücksichtigt wurden, und ab einem gewissen Grad sind die Prozesse so überladen, dass sie nicht mehr verständlich und wartbar sind.
Doch wie geht man dann mit allen möglichen Ausnahmen um, insbesondere, wenn es darum geht, Geschäftsprozesse mit Hilfe einer Process Engine zu automatisieren? Abhilfe schafft hier ein Konzept, das wir in Kundenprojekten schon erfolgreich umgesetzt haben: das Konzept des Störprozesses. Dabei wird einem fachlichen Geschäftsprozess ein entsprechender Störprozess zur Seite gestellt. Treten im Verlauf des fachlichen Prozesses unvorhergesehene Störungen auf, die nicht im Fachprozess berücksichtigt sind und aufgrund derer der Fachprozess nicht sinnvoll fortgesetzt werden kann, so wird der dazugehörige Störprozess gestartet. Dies kann entweder manuell durch einen Benutzer geschehen oder auch automatisch beim Eintreten bestimmter Bedingungen.
Zu Beginn des Störprozesses muss zunächst die Instanz des gestörten Fachprozesses identifiziert werden, typischerweise durch die Angabe eines eindeutigen fachlichen Schlüsselwerts (wie z.B. einer Bestellnummer). Der Störprozess unterbricht dann als erstes die fachliche Prozessinstanz (die aktuelle Ausführung der Prozessinstanz wird also angehalten). Voraussetzung hierfür ist natürlich, dass die eingesetzte Process Engine ein solches Konzept unterstützt und eine entsprechende API dafür bereitstellt. Als nächstes kann ein Benutzer Informationen zur vorliegenden Störung erfassen und entscheiden, was als nächstes mit dem Fachprozess passieren soll. Diese Information und die möglichen Aktionen sind typischerweise spezifisch für den jeweiligen Fachprozess, d.h., ein Störprozess ist in der Regel immer auf einen konkreten Fachprozess abgestimmt. Prinzipiell gibt es aber drei grundlegende Möglichkeiten, wie mit dem Fachprozess jetzt umgegangen werden kann: a) nach Behebung der Störung wird die fachliche Prozessinstanz ab dem Punkt, an dem sie zuvor angehalten wurde, wieder fortgesetzt, b) die Prozessinstanz muss komplett gecancelt werden, oder c) die Prozessinstanz wird abgebrochen und auf Basis der bereits erwirtschafteten Fach- bzw. Prozessdaten neu aufgesetzt. Insbesondere in letzterem Fall ist in der Regel auch eine Bereinigung der Daten notwendig, damit die neu aufgesetzte Prozessinstanz auch auf einem konsistenten Datenbestand arbeiten kann.
Denkbar ist auch, dass ein Fachprozess an verschiedenen Stellen mit „Einsprungpunkten“ für das Wiederaufsetzen nach einer Störung versehen wird, sodass es möglich ist, den Prozess gezielt auf verschiedene Meilensteine in seinem Ablauf „zurückzurollen“. Dementsprechend erhöht sich dann natürlich auch die Logik des zugehörigen Störprozesses. Er muss herausfinden, in welchem Schritt die fachliche Prozessinstanz unterbrochen wurde, um abhängig davon die möglichen Aktionen für das Wiederaufsetzen abzuleiten und die Daten entsprechend aufzubereiten.
Doch nochmals zurück zu unserem Ausgangspunkt: Ausnahmen sind immer und überall. Wie entscheide ich, welche Ausnahmen ich im Fachprozess selbst abbilde und wann es Sinn macht, einen separaten Störprozess zu implementieren? Hier hilft die folgende Faustregel:
1. Fachliche Ausnahmen, die mit einer gewissen Wahrscheinlichkeit absehbar sind und die sich stets auf standardisierte Weise behandeln lassen, sollten durch den Fachprozess abgebildet werden.
2. Technische Fehler sollten nach Möglichkeit der Process Engine selbst überlassen werden. Dies bedingt natürlich, dass die Process Engine eine entsprechende Fehlerbehandlung unterstützen muss – dass die Engine z.B. an Transaktionen teilnehmen kann und vor allem, dass Prozessinstanzen beim Auftreten einer technischen Exception in einen kontrollierten Fehlerzustand laufen, aus dem ein Administrator den fehlgeschlagenen Prozess (nach Behebung des technischen Fehlers) wieder anstarten kann. In diesem Zusammenhang kann auch die Möglichkeit von automatischen Benachrichtigungen bei technischen Fehlern nicht schaden.
3. Alle sonstigen (fachlichen) Eventualitäten können über das hier beschriebene Konzept eines Störprozesses abgewickelt werden. Dabei sollte jedoch immer auf ein gesundes Kosten-Nutzen-Verhältnis geachtet werden. Es ist sicherlich wenig ökonomisch, einen komplexen Störprozess zu implementieren, der in Praxis fast nie gebraucht wird.
Im Zuge des kontinuierlichen Verbesserungsprozesses des Business Process Managements können die aufgetretenen Ausnahmesituationen dann über die Zeit analysiert werden und häufig wiederkehrende Muster (wo sinnvoll/standardisierbar) in den Fachprozess integriert werden.
