Komplexe Prozesse vereinfachen und orchestrieren

Zur Automatisierung dieser Prozesse kommen typischerweise Orchestration Tools oder Workflow Engines zum Einsatz. Doch bei der Modellierung und Ausführung komplexer Prozesse stoßen viele Modellierungssprachen an ihre Grenzen. Erweiterte Workflow-Muster sind notwendig, um einen Prozess einfach und übersichtlich von Ende zu Ende zu orchestrieren – ohne komplizierte Workarounds.

In den seltensten Fällen sind Unternehmensprozesse eine streng lineare Abfolge von Aufgaben, bei der ein Abschluss die nächste Tätigkeit anstößt. Selbst die Bestellung in einem Online-Shop ist nicht so linear, wie sie klingt: Was, wenn sich der Kunde kurzerhand doch für das eine statt für das andere Produkt entscheidet?

Im Einzelhandel kann der Kaufprozess an jeder Stelle durch den Kunden unterbrochen und damit alle weiteren Schritte verändert werden, auch wenn eigentlich die gleichen Schritte passieren: Bedürfnis ermitteln, Ware zusammenstellen, zur Kasse gehen und bezahlen. Fällt jemanden beim Zücken der Kreditkarte ein, dass er noch etwas zusätzlich möchte, können Menschen in solchen Fällen recht spontan reagieren und ihr Handeln an die neuen Gegebenheiten anpassen – wenn der Prozess automatisiert abläuft, kann so ein Ereignis das System aber schnell durcheinander bringen.

Und auch vermeintlich einfache Bestellprozesse sind deutlich komplexer als man denkt. Die Endpunkte heißen nicht nur Verkäufer und Kunde, sondern auch Shop-Software, Mailserver, Zahlungsdienstleister, Versandservice, Lagerist, Buchhaltungssoftware und oft noch einiges mehr.

Je mehr Prozesse digitalisiert und automatisiert werden, umso wichtiger wird es, dass die entsprechenden Umgebungen und Tools mit unvorhergesehenen Ereignissen umgehen oder sich einzelne Prozessteile gegenseitig beeinflussen können.

Um das zu bewältigen, kommen in der Regel Workflow Engines zum Einsatz. Mit ihnen werden Prozesse von Ende zu Ende orchestriert. Naheliegend also, dass Unterschiede in der Workflow Engine auch Auswirkungen auf das Design des Workflows haben – wobei vor allem die Modellierungssprache einen entscheidenden Einfluss hat. Wie sehr, wird durch die folgenden Beispiele deutlich.

Dieser Beispielprozess ist in Amazon States Language (ASL), der Modellierungssprache von AWS Step Functions modelliert. Da ASL nicht auf externe Nachrichten reagieren kann, benötigt der Prozess einen Workaround, um die Bestellung abzubrechen, wenn der Kunde eine Stornierung schickt.

Dazu wird beispielsweise ein parallel laufender Zweig (1) gestartet, der auf eine Stornierung wartet, während die Bestellungen bearbeitet werden. Nun fehlt allerdings ein passender Korrelationsmechanismus, weil ASL auf Ereignisse außerhalb des laufenden Workflows nicht eingehen kann. In diesem Fall könnten wir Informationen zu dem AWS Workflow in einer eigenen Datenbank speichern, um eine Stornierung der richtigen wartenden Workflow-Instanz zuordnen zu können.

Kommt dann eine Nachricht mit dem Storno, läuft der parallele Zweig zu Ende und die Bestellung wird endgültig abgebrochen (2).

Wird die Bestellung nicht storniert, muss ein künstlicher Fehler erzeugt werden, der den Wartemechanismus beendet (3).

Und spätestens für den Bezahlvorgang wird ein weiterer Workaround der gleichen Art benötigt, um nicht auf den Zahlungseingang zu warten – ob er kommt oder nicht (4) und (5).

Eine andere Möglichkeit ist, die gesamte Logik für die Stornierung aus dem Prozessmodell auszulagern und via API einzubinden. Das bedeutet aber, dass die Logik an verschiedenen Stellen im Code verteilt wird, anstatt sie im Prozessmodell zu bündeln. So geht nicht nur bei der initialen Entwicklung, sondern auch im laufenden Betrieb oder bei der Fehlersuche einiges an Übersicht verloren. Außerdem steigt das Risiko, dass bei Änderungen am Prozessmodell die Stornierungslogik vergessen oder zu spät einbezogen wird. Die Implementierung des Prozesses gestaltet sich also viel komplizierter, als sie eigentlich sein müsste.

In BPMN hingegen können solche Anforderungen leicht über erweiterte Workflow-Muster abgebildet werden, zum Beispiel die Reaktion auf externe Nachrichten oder das Korrelieren von parallel ablaufenden Prozessen. Komplexere Abfolgen werden direkt als Baustein in den Prozess integriert, statt sie aufwändig zu umgehen oder in ein externes Programm auszulagern.  

So sieht derselbe Prozess in BPMN aus, der oben mit ASL modelliert wurde. BPMN, ein ISO-Standard für Prozessmodellierung, bietet eben jene erweiterten Workflow-Muster, durch die Workarounds hinfällig werden und ist mit einer kompatiblen Workflow Engine direkt ausführbar. BPMN kennt parallel ablaufende Prozesszweige (1), aber eben auch Reaktionen auf externe Ereignisse, Korrelationsmechanismen (2) und zeitbasierte Events. Wofür in ASL die Schritte (2) bis (5) benötigt werden, lässt sich in BPMN mit entsprechenden Bausteinen leicht modellieren.

Die einfach verständliche, grafische Darstellung in BPMN erleichtert zudem die Zusammenarbeit mit den Mitarbeitenden in Fachabteilungen und/oder Entscheidern, die eventuell keine tiefgehenden Kenntnisse in der Prozessmodellierung haben. Und auch Fehler und Engpässe lassen sich in einem in BPMN modellierten und einer Workflow-Engine ausgeführten Prozess besser erkennen.

Interessanterweise fehlen den meisten Workflow Engines die erweiterten Workflow-Muster. Das ist oft mit dem Versprechen verbunden, die infrage kommende Software sei einfacher und benutzerfreundlicher als BPMN – tatsächlich fehlen aber essentielle Funktionen. In vielen Modellierungssprachen werden daher über die Zeit auch immer neue Funktionen hinzugefügt. Ab einem gewissen Punkt kommt die Komplexität der Sprache an die von BPMN heran, allerdings mit einem großen Nachteil: Die Modellierungssprache ist proprietär und nicht oder schwer kompatibel mit der Software anderer Anbieter.

Unternehmensprozesse sind zunehmend auf erweiterte Workflow-Muster angewiesen. Stehen sie nicht zur Verfügung, wird die Modellierung und Orchestrierung von Prozessen unnötig komplex und langwierig. Zur Orchestrierung von Prozessen ist eine etablierte Modellierungssprache wie BPMN ein klarer Vorteil – vor allem, wenn sie in einer Engine ausgeführt wird, die BPMN umfänglich unterstützt.

Quelle: Bernd Rücker, Camunda

Bernd Rücker ist Mitgründer und Chief Technologist von Camunda, einem Anbieter von Software zur Prozessorchestrierung. Als passionierter Softwareentwickler hat er die Prozessautomatisierung von Unternehmen wie Allianz, Deutsche Bahn oder Deutsche Telekom unterstützt. Bernd ist zudem der Autor von „Practical Process Automation“ und Co-Autor des „Praxishandbuch BPMN“.