Wie entwerfe ich eine Workflow-basierte Applikation?

In unseren Kundenprojekten setzen wir häufig Lösungen um, in denen Workflows enthalten sind. Dabei handelt es sich nicht zwingend um „große“ Abläufe unter Beteiligung vieler Abteilungen und zeitlich langlaufende Prozesse. Bei Informations- und Daten-basierten Anwendungen werden oft Freigabeprozesse benötigt, in denen über eine oder 2 Stufen Inhalte / Daten geprüft und genehmigt werden. Auch für solche Arten von „einfachen“ Workflows bietet es sich an, Frameworks für Prozessautomatisierung zu verwenden, mit denen schnell derartige Lösungen umgesetzt werden können.

Der nachfolgende Beitrag beschreibt die Herangehensweise – welche Schritte muss ich durchlaufen, um am Ende ein umsetzbares Modell des Workflows zu erhalten.

Im ersten Schritt wird das Datenmodell entworfen: Dazu müssen wir festlegen, um welche Geschäftsobjekte es geht (beispielsweise einem Leistungsnachweis) und welche Informationen zu diesen Geschäftsobjekten relevant sind. Wichtig dabei ist die Unterscheidung zwischen Informationen, die wir dauerhaft speichern wollen, und Informationen, die wir nur im Verlauf des Workflows benötigen. Die dauerhaft zu speichernden Informationen werden in einer Datenbank abgelegt, alle anderen existieren nur im Verlauf eines konkreten Workflows und werden nach dessen Ende verworfen.

Eine spannende Entscheidung steht später bei der technischen Umsetzung an: Werden die Daten des Geschäftsobjektes vollständig im Workflow abgelegt? Oder enthält der Workflow nur eine Referenz auf das Geschäftsobjekt in der Datenbank und jeder Workflow-Schritt besorgt sich von dort die Daten? Aber auf diese Diskussion möchte ich hier nicht weiter eingehen.

Damit haben wir den ersten Stand des Datenmodells entworfen. Dieser wird gewöhnlich weiter angepasst, wenn man bei der Modellierung der Workflows später feststellt, dass noch Informationen fehlen.

Der nächste Schritt beschäftigt sich mit den Gruppen und Rollen, die bei der Ausführung des Workflows relevant sind. Gedanklich kann man sich dies wie den Aufbau einer Organisationsstruktur vorstellen, in dem man Gruppen und Hierarchien festlegt und sich bei Bedarf noch zusätzliche Rollen überlegt, die unabhängig von der Zuordnung zur Organisationshierarchie sind. So kann es beispielsweise eine Hierarchie aus Geschäftsbereichen und Abteilungen geben, denen Mitarbeiter zugeordnet sind, die in Projekten unterschiedliche Rollen wie Projektmanager oder Qualitätssicherer einnehmen können. Zum Modellieren reicht der Entwurf der Organisationshierarchie und der Rollen, später müssen die Anwender entsprechend zugeordnet werden.

Wozu werden diese Überlegungen zur Organisationsstruktur benötigt? In Workflows gibt es verschiedene Bearbeitungsschritte und häufig zum Abschluss des Workflows eine Qualitätssicherung / Freigabe. Spätestens diese Freigabe wird gewöhnlich von Kollegen aus anderen Einheiten der Organisationsstruktur ausgeführt oder gegebenenfalls auch vom Vorgesetzten. D.h. mit Hilfe der Organisationsstruktur können leichter Verantwortlichkeiten für einzelne Aufgaben im Workflow definiert werden.

Schließlich wird der Workflow an sich modelliert. Dabei stellt sich zunächst die Frage, wer die steuernde Einheit des Workflows ist und wer gegebenenfalls für Teilbereiche verantwortlich ist. Übertragen auf eine Modellierung mittels BPMN (eine Einführung ist beispielsweise hier zu finden) ist dies die Frage, was der / die Pool(s) und was Lanes sind. Die Bedeutung der Frage hängt auch ein wenig vom Zweck der Modellierung ab. Dient die Modellierung zunächst „nur“ dazu, mit den Fachbereichen die Abläufe zu diskutieren, kann ein Ansatz gewählt werden, der dem Zweck dieses Austausches dient. Soll jedoch der modellierte Prozess später möglichst 1:1 technisch mit Hilfe einer BPMN Engine implementiert werden, empfiehlt es sich dies auch gleich zu berücksichtigen: Demnach wäre immer dann ein separater Pool zu modellieren, wenn dieser unabhängig gesteuert wird.

Ansonsten kann man zunächst den eigentlichen Prozess mit einem Pool und die verschiedenen Akteure als Lanes anlegen. Wenn wir den Freigabeprozess für Leistungsnachweise als Beispiel betrachten, wäre der Pool der Freigabeworkflow und die einzelnen Lanes die Teilnehmer, wie Dienstleister, Prüfer und Freigeber. Ein solcher Prozess könnte technisch auch durch einen Prozess mit einer Workflow Engine kontrolliert werden.

Schließlich werden die Abläufe als zeitlich logische Abfolge von Aufgaben modelliert. Es beginnt mit dem auslösenden Ereignis, das für den Start des Workflows sorgt. Ein solches Ereignis kann eine Aktivität eines Prozessteilnehmers sein oder eine eingehende Nachricht (beispielsweise eine Bestellung im System). Schließlich wird der Ablauf der verschiedenen Aufgaben modelliert, Verantwortlichkeiten für die Aufgaben festgelegt sowie Verzeigungen (Gateways) und deren Bedingungen definiert. Aufgaben können durch Personen ausgeführt werden (Prüfung der Inhalte des Leistungsnachweises) oder technische Services (Versand einer E-Mail) sein. Ein Prozess kann ein oder mehrere Endpunkte haben, wenn der Workflow in fachlich unterschiedlichen Endzuständen enden kann oder wenn beispielsweise auch verschiedene Fehlersituationen explizit modelliert werden.

In dem Schritt der Modellierung ergeben sich viele Fragestellung, wie Abläufe strukturiert (Teilprozesse) und im Modell abgebildet werden und was BPMN als Regelwerk zulässt. Hier möchte ich aber auf die einschlägige Literatur zu BPMN verweisen.

Mit der Abarbeitung der 3 Aspekte Geschäftsobjekte, Organisationsstruktur und Workflow entsteht am Ende ein komplettes Modell eines Prozesses, der sich mittels einer Workflow Engine umsetzen lässt.

Wie sich dieses Vorgehen sehr gut auf die Nutzung einer BPMN Engine anwenden lässt, erläutere ich in einem weiteren Blogpost, der eine Umsetzung mit der Open Source BPM Software Bonita von Bonitasoft (https://www.bonitasoft.com/) beschreibt.