Workflow-Modelle: Aufgaben, Entscheidungen und Übergänge strukturieren

Was ist ein Workflow-Modell?

Die Business Process Model and Notation (BPMN) definiert einen Prozess als Folge oder Fluss von Aktivitäten, mit denen Arbeit in einer Organisation ausgeführt wird. In BPMN wird dieser Ablauf als Graph aus Aktivitäten, Ereignissen, Gateways und Sequenzflüssen dargestellt. Die Spezifikation lässt ausdrücklich unterschiedliche Detaillierungsgrade zu: vom unternehmensweiten Prozess bis zum Ablauf einer einzelnen Person.^[1]

Der Begriff Workflow-Modell bezeichnet in diesem Beitrag nicht zwingend eine bestimmte Notation. Ein Ablauf kann auch in anderen formalen oder domänenspezifischen Modellen beschrieben werden. BPMN ist jedoch ein wichtiges Referenzmodell, weil es zentrale Bausteine und deren Beziehungen präzise unterscheidet.

Aus „bei Bedarf“ wird eine entscheidbare Bedingung

Ein fiktives Modell für die Wareneingangsprüfung enthält zunächst die Anweisung: „Bei Bedarf nachprüfen.“ Zwei Personen können daraus verschiedene Abläufe ableiten. Unklar bleiben Anlass, Zuständigkeit und das Verhalten bis zur Klärung.

Die Modellierungsaufgabe besteht darin, diese Lücke zu schließen. Eine mögliche betriebliche Festlegung lautet: Fehlt die eindeutige Zuordnung eines Prüfberichts zur gelieferten Charge, übergibt die Wareneingangsprüfung den Vorgang an die zuständige Qualitätsrolle. Bis deren Bewertung vorliegt, bleibt die Verwendung gesperrt. Die Qualitätsrolle kann die Zuordnung bestätigen, eine Ergänzung anfordern oder die Annahme ablehnen.

Damit sind drei Dinge getrennt: die Arbeit „Zuordnung prüfen“, das Ergebnis dieser Prüfung und der daran anschließende Weg. Ein Gateway stellt die Verzweigung dar; die fachliche Bewertung muss zuvor in einer Aufgabe erfolgen. Fehlt die Information für eine Entscheidung, braucht das Modell einen Wartezustand oder einen Klärungsweg statt eines geratenen Ergebnisses.

Ob die Vorgabe passt, lässt sich vor der Umsetzung anhand von drei Testfällen besprechen: Bericht eindeutig zugeordnet, Bericht nicht zuordenbar und Bewertung noch ausstehend. Für jeden Fall müssen die Beteiligten denselben nächsten Schritt und dieselbe Zuständigkeit benennen können. Diese Fallprüfung ist eine Arbeitshilfe, kein vollständiger Validierungsnachweis.

Die Bausteine eines Workflow-Modells

Die konkrete Modellierung hängt vom Anwendungsfall ab. Dennoch lassen sich wiederkehrende Elemente unterscheiden.

Bedingungen müssen fachlich entscheidbar sein

Ein Modell wird erst dann handlungsfähig, wenn seine Übergangsbedingungen in der realen Situation entschieden werden können. Formulierungen wie „bei Bedarf“, „gegebenenfalls prüfen“ oder „bei Auffälligkeit eskalieren“ mögen in einer textlichen Anweisung verständlich wirken. Für einen geführten Workflow bleiben sie unbestimmt, solange nicht klar ist, wer den Bedarf feststellt, welche Kriterien gelten und welcher nächste Schritt daraus folgt.

Eine belastbare Bedingung verbindet deshalb mindestens:

• den zu bewertenden Sachverhalt,
• die zulässigen Ergebnisse,
• die entscheidungsberechtigte Rolle,
• den daraus folgenden Pfad und
• die Information, die als Begründung oder Nachweis erforderlich ist.

Nicht jede Bedingung muss automatisch berechnet werden. Eine qualifizierte Person kann eine Beobachtung bewerten und das Ergebnis bestätigen. Wichtig ist, dass das Modell diese menschliche Entscheidung ausdrücklich vorsieht, statt sie hinter einem automatischen Statuswechsel zu verbergen.

Für Human in the Loop muss an diesem Entscheidungspunkt feststehen, welche Informationen die Person erhält, welche Handlungsoptionen sie hat und mit welchen Rechten sie eingreifen darf.

Ausnahmen gehören zum Ablauf

Viele Modelle bilden zunächst nur den erwünschten Normalweg ab. Reale Arbeit enthält jedoch fehlende Informationen, verspätete Ergebnisse, Grenzwertüberschreitungen, Geräteausfälle, Abweichungen und Nacharbeit. Werden solche Fälle im Modell nicht berücksichtigt, entstehen außerhalb des geführten Prozesses E-Mails, Notizen oder informelle Absprachen.

Ein robustes Workflow-Modell beschreibt daher nicht nur den Happy Path. Es legt fest, wie ein Vorgang pausiert wird, wer bei einer Abweichung übernimmt, ob Arbeit zurückgegeben werden kann und wie die ursprüngliche Ausführung mit Prüfung und Nacharbeit verbunden bleibt. Auch Abbruch und kontrollierter Abschluss benötigen eine eindeutige Bedeutung.

Dabei ist nicht jede denkbare Störung als eigener Ast vorwegzunehmen. Modelle werden unlesbar, wenn sie jede seltene Variante vollständig auszeichnen. Sinnvoller ist eine klare Grundstruktur mit definierten Ausnahme- und Eskalationsmechanismen, in denen der konkrete Sachverhalt erfasst und fachlich bewertet wird.

Modell und Ausführung sind verschiedene Ebenen

Ein Workflow-Modell beschreibt, was vorgesehen, zulässig oder erforderlich ist. Die tatsächliche Ausführung zeigt dagegen, was in einem konkreten Vorgang geschehen ist. Diese Unterscheidung ist grundlegend.

Ein Modell kann etwa vorsehen, dass nach einer Messung entweder eine Freigabe, eine erneute Prüfung oder eine Sperrung folgt. In einem konkreten Chargenprozess wurde jedoch nur einer dieser Wege ausgeführt. Das Modell enthält die möglichen Pfade; die Ausführung enthält die tatsächlich durchlaufenen Handlungen und Entscheidungen.

Das W3C-PROV-Datenmodell trennt diese Ebenen ebenfalls. Es definiert einen Plan als eine Entität, die eine Menge beabsichtigter Handlungen oder Schritte zur Erreichung eines Ziels repräsentiert. Eine Aktivität ist dagegen etwas, das über einen Zeitraum tatsächlich stattfindet und auf Entitäten einwirkt oder mit ihnen arbeitet. PROV kann eine Aktivität mit einem verantwortlichen Agenten und dem zugrunde liegenden Plan verbinden.^[2]

Für digitale Systeme folgt daraus: Ein freigegebenes Workflow-Modell darf nicht nachträglich so behandelt werden, als sei es bereits ausgeführt worden. Umgekehrt lässt sich aus einem Endstatus allein nicht sicher rekonstruieren, welcher vorgesehene Weg tatsächlich genommen wurde. Das Modell und seine Ausführungsdaten müssen miteinander verbunden, aber begrifflich getrennt bleiben.

Versionen und Geltung

Workflow-Modelle verändern sich. Aufgaben werden anders geordnet, Verantwortlichkeiten wechseln, Grenzwerte werden angepasst oder neue Prüfungen aufgenommen. Für laufende und abgeschlossene Vorgänge muss deshalb erkennbar bleiben, welche Modellversion galt.

Eine neue Version darf die historische Bedeutung bereits ausgeführter Prozesse nicht überschreiben. Wenn eine Charge im August nach Version 3 bearbeitet wurde, soll eine im September veröffentlichte Version 4 nicht den Eindruck erzeugen, der ältere Ablauf habe bereits den neuen Regeln entsprochen.

PROV behandelt einen Plan als eigene Entität. Weil Pläne sich entwickeln können, kann auch ihre Herkunft und Versionierung beschrieben werden. Die ausdrückliche Verbindung von Aktivität, Agent und verwendetem Plan hilft unter anderem dabei, Ausführungen zu validieren, Erwartungsabweichungen zu behandeln und Erklärungen bereitzustellen.^[2] Die Herkunft und Entwicklung solcher Informationen ist Gegenstand von Data Provenance.

Für den Betrieb sind daher mindestens Freigabestatus, Gültigkeitszeitraum, Version und ersetzte Vorversion relevant. Entwurf, Prüfung, Freigabe und Außerkraftsetzung des Modells sind selbst kontrollierte Vorgänge.

Vom Diagramm zum ausführbaren System

Ein verständliches Diagramm ist noch kein ausführbarer Workflow. Für die technische Ausführung müssen unter anderem Ereignissemantik, Datenanforderungen, Bedingungen, Rollen, Berechtigungen, Fehlerverhalten und Schnittstellen eindeutig genug beschrieben sein. BPMN unterscheidet deshalb zwischen nicht ausführbaren privaten Prozessen zur Dokumentation und ausführbaren Prozessen, die zusätzliche Ausführungsdetails enthalten.^[1]

Weske ordnet diesen Übergang als Schritt vom operativen Prozessmodell zum ausführbaren Workflow-Modell ein: Für die Ausführung werden technische Informationen ergänzt, die unter anderem die Ausführungsumgebung der Aktivitäten bestimmen. Das Workflow-Modell bleibt damit der Bauplan für die Laufzeit und nicht die Aufzeichnung einer konkreten Ausführung.^[3]

Auch ein formal ausführbares Modell ist nicht automatisch betrieblich geeignet. Ein System kann eine syntaktisch korrekte Folge von Schritten ausführen und dennoch den falschen fachlichen Zeitpunkt, unklare Verantwortungen oder unzureichende Nachweise abbilden. Die Modellierung muss deshalb gemeinsam mit den Menschen erfolgen, die den Prozess fachlich verantworten und tatsächlich ausführen.

Eine Workflow Engine führt eine freigegebene Definition als konkrete Instanz aus, persistiert ihren Zustand und setzt sie über menschliche sowie technische Schritte fort.

Ebenso wenig sollte jedes Detail des Arbeitsalltags in einem zentralen Diagramm liegen. Fachregeln, Formulare, Grenzwerte, Berechtigungsmatrizen oder Materialmodelle können eigenständige, versionierte Komponenten sein. Das Workflow-Modell verbindet sie an den Stellen, an denen sie für den Ablauf relevant werden.

Die Einführung von Workflow-Software überführt ein beschriebenes Modell gemeinsam mit den beteiligten Menschen in den Regelbetrieb – von der Pilotabgrenzung bis zur betrieblichen Übergabe.

Was Workflow-Modelle nicht leisten

• Formale Korrektheit garantiert keine fachliche Richtigkeit. Ein gültiges BPMN-Modell kann ungeeignete Rollen, Bedingungen oder Arbeitsschritte enthalten.
• Automatisierung beseitigt keine Verantwortung. Entscheidungen müssen dort menschlich bleiben, wo Fachwissen, Bewertung oder rechtliche Zuständigkeit dies verlangen.
• Mehr Detail bedeutet nicht automatisch mehr Kontrolle. Übermodellierung kann Abläufe unverständlich und Änderungen unnötig schwer machen.

Ein Modell ist bereit, wenn seine Wege erklärbar sind

Vor der technischen Umsetzung lohnt ein gemeinsamer Durchgang mit den späteren Anwendern: Was löst den Prozess aus? Welches Ergebnis entscheidet über den nächsten Weg? Wer übernimmt einen ungeklärten Fall? Ein Modell, das darauf widerspruchsfreie Antworten gibt, schafft eine prüfbare Grundlage für die Umsetzung.

Die geeignete Detailtiefe ergibt sich aus diesen Fragen. Ein zusätzlicher Kasten ist hilfreich, wenn er eine bislang verborgene Verantwortung oder Entscheidung sichtbar macht. Beschreibt er lediglich einen weiteren Mausklick, verbessert er den fachlichen Ablauf meist nicht.