Vom BPMN-Modell zum digitalen Workflow –
Best Practices & Fallstricke 

Wir haben im vorgestellten Beispiel auf die Verwendung von Pools und Swimlanes verzichtet. Einerseits um den zeitlichen Rahmen des Webinars nicht zu sprengen. Andererseits, weil die meisten BPMN 2.0-konformen Workflow-Engines Pools und Lanes zwar bei der Modellierung unterstützen, sich die Execution, d.h. ob und wie Pools und Lanes bei der Ausführung berücksichtigt werden, je nach Workflow-Engine unterscheiden.

Die Verwendung von Pools und Lanes in BPMN dient der Darstellung von Verantwortlichkeiten und Kommunikationsbeziehungen zwischen Prozessbeteiligten.

• Verwende einen separaten Pool für jede Organisation, Abteilung oder externes System, das unabhängig agiert. Beachte: Verwende Message Flows zwischen Pools, nicht Sequenzflüsse (Sequenzflüsse zwischen Pools sind laut BPMN-Spezifikation nicht erlaubt) zum Trennen von internen Abläufen (Sequenzfluss) von der externen Kommunikation (Nachrichten).
• Nutze Lanes, um Verantwortlichkeiten innerhalb einer Organisationseinheit (Pool) darzustellen. Jede Lane steht für eine Rolle, Abteilung oder Funktion und sollte auch so beschriftet werden, z. B. Kunde, Sachbearbeiter und Kreditsystem.

Die unterschiedlichen Workflow-Engines stellen meist ihre eigenen Modellierungswerkzeuge bereit. Wir empfehlen grundsätzlich auch diese zu verwenden, da die Verwendung die Ausführbarkeit der BPMN-Modelle in den jeweiligen Workflow-Engine gewährleistet. KI-Unterstützung und gemeinsames Bearbeiten von BPMN-Modellen wird von den Herstellern immer mehr unterstützt (siehe z.B. Camunda 8).

Die Nummerierung einzelner Aktivitäten in einem BPMN-Prozess (z. B. „1. Antrag eingegangen“, „2. Auflagen anfordern“, etc.) wirkt auf den ersten Blick hilfreich zur Orientierung – bringt aber in der Praxis mehrere Nachteile mit sich:

• Keine semantische Bedeutung in BPMN: Die Prozesslogik ergibt sich aus den Sequenzflüssen (Pfeilen), nicht aus der Nummerierung. Die Reihenfolge wird explizit modelliert – zusätzliche Nummern sind überflüssig. Weiterhin ist ein Prozess selten “starr” sequentiell, sondern hat parallele Flows, Wiederholungen, Globale Events, Signale, “Rücksprünge”, etc.
• Fehleranfälligkeit bei Änderungen: Wird eine Aktivität eingefügt oder gelöscht, müssen alle Nummern angepasst werden. Das führt zu hohem Pflegeaufwand und Inkonsistenzen, vor allem in großen Prozessen.
• Visuelle Unruhe: Nummern blähen das Diagramm auf, ohne echten Mehrwert. Sie können das Modell unnötig überladen und die Lesbarkeit verschlechtern.
• Nicht BPMN-konform: Die BPMN-Spezifikation sieht keine nummerierte Reihenfolge in Task-Namen vor. Modellierungswerkzeuge validieren solche Nummerierungen ggf. nicht, aber sie sind kein Bestandteil der Methodik.

Ob eine Modellierung auf mehreren Ebenen möglich ist, ist abhängig von der eingesetzten Software. Vgl. Antwort zu “mehrstufigem Modellierungsansatz”.

In der BPMN-Modellierung ist ein Token ein abstraktes Konzept, das den Fortschritt eines Prozesses symbolisiert. Ein Token hilft insbesondere zu verstehen, wo sich ein Prozess gerade befindet und wie er abläuft. Was genau ist ein Token?

• Ein Token stellt den Fluss der Ausführung innerhalb eines Prozesses dar.
• Es „läuft“ entlang der Sequenz Flows durch das BPMN-Modell.
• Sobald ein Start Event ausgelöst wird, wird ein Token erzeugt oder bei parallelen und Aktivitäten dupliziert bzw. anschließend wieder synchronisiert.
• Der Token durchläuft Aktivitäten, Gateways und Events gemäß dem definierten Prozessmodell.

BPMN kann sowohl für die Beschreibung und Ausführung von fachlichen als auch für technische Prozesse verwendet werden. Als Beispiel für einen fachlichen Prozess kann der Prozess zur Auflagenprüfung bei einer Kreditvergabe mit fachlichen Aktivitäten genannt werden. Beispiele für technischen Prozesse wären E-Mail-Versandprozesse oder Prozesse für die automatische Verarbeitung von Dokumenten.

Wichtig zu erwähnen ist, dass BPMN nicht nur bei der Beschreibung von fachlichen Prozessen trumpfen kann, sondern auch (bedingt durch die Verwendung einer Workflow Engine) bei der Umsetzung von technischen Prozessen. Die Vorteile sind out-of-the-box Features von Workflow Engines wie z.B. Transaktions- und Fehlerhandling und die automatische Durchführung von Rollbacks.

Komplexe Datenstrukturen können und sollten durchaus in BPMN-Prozessen verwendet werden. Unsere Aussage bezog sich lediglich auf das Speichern von komplexen Datenstrukturen als Prozessvariablen.

Um mit komplexen Datenstrukturen innerhalb von BPMN-Prozessen zu arbeiten, ist die Empfehlung eine Referenz auf die komplexe Datenstruktur als primitiven Datentypen im Prozess zu speichern (z.B. eine Antragsnummer 12345, welches auf einen Datenbankeintrag mit weiteren antragbezogenen Eigenschaften in einer relationalen Datenbank verweist). Sobald das Objekt innerhalb vom Prozess gebraucht wird, z.B. um eine Operation / Logik innerhalb einer Service Task auszuführen, kann punktuell dort anhand der Referenz der Eintrag aus der Datenbank geladen werden. Um das Holen und Arbeiten mit komplexen Datenstrukturen innerhalb von einem Service Task abzubilden können Techniken aus gängigen Programmiersprachen wie Java genutzt werden.

Darüber hinaus existieren auch Low-Code Ansätze für den Umgang mit komplexen Datenstrukturen in Workflow-Engines. Z.B. unterstützt Alfresco Process Services (APS) einen Low-Code Ansatz mit Hilfe von relationalen Datenbanken.

Die Idee eines Job Workers im Kontext von BPMN, insbesondere bei modernen WorkflowEngines, ist es, die Prozessausführung (Logik) entkoppelt und skalierbar zu gestalten.

Ein Job Worker ist ein externer Service oder eine Anwendung, die asynchron Aufgaben übernimmt, die in einem BPMN-Prozessmodell definiert wurden – typischerweise Service Tasks. Die Engine erstellt sogenannte Jobs, die dann von einem Worker abgeholt, verarbeitet und als abgeschlossen zurückgemeldet werden. Dabei ist hier nicht definiert, mit welchen Tools oder Programmiersprachen die Job Worker umgesetzt werden. Ein Beispiel wäre, einen Job Worker als Microservice mittels Spring Boot umzusetzen und diesen dann in der Workflow Engine zu registrieren.

BPMN ist plattformunabhängig. Somit kann eine Integration von weiteren Services, wie z.B. die Integration von ECM flexibel gestaltet werden. So lässt sich die Integration beispielsweise über eine Service Task mit synchronem oder asynchronem Aufruf von dem jeweiligen ECMService realisieren. Darüber hinaus gibt es im Low-Code Ansatz verschiedene Mittel, um Services im BPMN-Prozess zu integrieren, z.B. Connectoren bei Camunda oder custom/ vordefinierte BPMN-Elemente für die Integration zwischen BPMN-Prozessen in Alfresco Process Services (APS). Voraussetzung ist natürlich, dass das jeweilige ECM-System auch die nötigen Schnittstellen zur Integration bereitstellt.

Eine weitere Möglichkeit, z.B. wenn die nötigen Schnittstellen zur Integration fehlen, ist RPA (Robotic Process Automation). Die dort abgebildeten Bot-Strecken lassen sich einfach mit BPMN kombinieren bzw. wird BPMN auch oft zur Orchestrierung genutzt.

Ja, beides lässt sich grundsätzlich kombinieren – durch einen mehrstufigen Modellierungsansatz. Das fachliche BPMN-Modell dient dann als Arbeitsanweisung im Sinne der MaRisk (AT 5) und beschreibt verständlich das Was, Wie und Wer für die Mitarbeitenden. Darauf aufbauend entsteht eine technische Version für die Workflow-Engine, die ausführbar ist und technische Details (z. B. Systemaufrufe, Formulare, Regeln) enthält. In der Praxis kann entweder eine Trennung der Ebenen stattfinden (verschiedene BPMN-Level => toolabhängig), oder aber man arbeitet über eine Verlinkung oder Synchronisation zwischen fachlichem und technischem Modell.