Als Prozessverantwortlicher ist es eine wichtige Aufgabe, klare Richtlinien und Standards für interne Abläufe zu etablieren. Eine zentrale Frage im (ProCode-) Entwicklungsprozess von Workflow-Anwendungen – an der Schnittstelle von Business-Analyse und Software-Entwicklung – ist die Klassifizierung eines ausführbaren BPMN-Modells: Ist es ein Artefakt der Business-Analyse oder der Software-Entwicklung? Diese Entscheidung beeinflusst Zuständigkeiten, Werkzeuge, Kompetenzen und den Projekterfolg im ProCode-Bereich maßgeblich.

Vorweg: Der erfolgreichste Ansatz liegt in der Kollaboration. Dennoch zeigt sich in der Praxis, dass unterschiedliche Kompetenzprofile berücksichtigt werden müssen. Dieser Beitrag trägt die Argumente für eine Entscheidungsfindung zusammen. Im NoCode/LowCode-Bereich werden Business Analyse und Entwicklung häufig in Personalunion durchgeführt.

Ziel dieses Beitrags ist es, für unsere Business Analysten und Entwickler einen fundierten Entscheidungsrahmen zu schaffen und den sinnvollen Übergabepunkt sowie den Round-Trip zwischen Business-Analyse und Software-Entwicklung zu definieren.

Die Rolle von BPMN in der digitalen Transformation

BPMN (Business Process Model and Notation) 2.0 hat sich als Standard für die Modellierung von Geschäftsprozessen etabliert. Es ermöglicht nicht nur die grafische Darstellung von Abläufen, sondern auch dank semantischer Erweiterung die Ausführbarkeit. Damit schlägt BPMN eine Brücke zwischen dem Fachbereich und der IT-Implementierung. Ein ausführbares BPMN-Modell ist potenziell eine Spezifikation, wie ein Prozess implementiert wird. Hier liegt der Kern der Debatte.

Ausführbare BPMN-Modelle als Ergebnisartefakt der Business-Analyse

Die Zuordnung zur Business-Analyse (BA) betont die Geschäftssicht und Domänenexpertise als treibende Kraft.

Ausführbare BPMN-Modelle als Ergebnisartefakt der Software-Entwicklung

Die Zuordnung zur Software-Entwicklung (SWE) betont die technische Implementierung und Systemintegration.

Der sinnvolle Übergabepunkt: Eine pragmatische Synthese

Eine starre Zuordnung ist nicht optimal. Der sinnvollste Übergabepunkt liegt in einer klaren Trennung der Verantwortlichkeiten bei enger Zusammenarbeit und schrittweiser Detaillierung.

1. Business-Analyse (BA) liefert das „Fachliche BPMN-Modell“:
   • Inhalt: Beschreibt den Prozess aus reiner Geschäftssicht, fokussiert auf fachliche Logik, Ablauf von Aktivitäten, Ereignissen, Gateways und Nachrichtenflüssen. Definiert die „Was“- und logische „Wie“-Ebene des Geschäftsprozesses.
   • Granularität: Fachlich benannte Aktivitäten (z.B. „Antrag prüfen“). Keine technischen Details wie API-Calls. Service-Tasks sind abstrakt als „Service-Aufgaben“ definiert.
   • Zweck: Validierung mit dem Fachbereich, gemeinsame Sprache, verbindliche fachliche Spezifikation.
   • Artefakt: Ein vollständiges, aber noch nicht ausführbares, fachliches BPMN-Modell.
2. Software-Entwicklung (SWE) transformiert zum „Ausführbaren BPMN-Modell“:
   • Inhalt: Aufbauend auf dem fachlichen Modell werden notwendige technische Details hinzugefügt.
   • Granularität: Abstrakte Service-Tasks werden konkretisiert (z.B. REST-Endpunkte, Parameter). Technische Konnektoren, Fehlerbehandlung, Skripte und technische Attribute werden ergänzt.
   • Zweck: Technische Implementierung, Ausführung auf der Prozess-Engine, Integration, Sicherheit, Sicherstellung von Performance, Skalierbarkeit und Robustheit.
   • Artefakt: Das ausführbare BPMN-Modell (XML-Datei), das in die Versionskontrolle eingecheckt und per CI/CD bereitgestellt wird.

Rolle des Business Analyst (BA) als Brücke

Der Business Analyst hat eine entscheidende Brückenfunktion. Er erstellt nicht nur das fachliche Modell, sondern arbeitet eng mit Entwicklern zusammen, um die technische Konkretisierung mit den fachlichen Anforderungen abzustimmen.

• Enge Kollaboration: Workshops und regelmäßige Abstimmungen sind im Rahmen des Business-IT-Aligments unerlässlich.
• „Executable by Design“: Schon bei der Erstellung des fachlichen Modells sollte der BA die technische Umsetzbarkeit berücksichtigen.
• Iteratives Vorgehen: Der Übergabepunkt ist nicht einmalig, sondern ein schrittweises Detaillieren im agilen Prozess.

Der Übergabepunkt ist somit primär eine Verantwortungsübergabe: Vom „Was“ und „Wie (fachlich)“ zum „Wie (technisch)“. Die Business Analyse liefert den „Blue-Print“, gemeinsam leiten sich ein ausführbares Prozessmodell ab, die Softwarte-Entwicklung füllt es mit technischem Leben.

Round-Trip von Entwicklung zum Prozessmanagement und zurück

Die schrittweise Detaillierung ist keine Einbahnstraße. Ein kontinuierlicher Round-Trip zwischen Entwicklung und Prozessmanagement ist für eine nachhaltige Prozessautomatisierung unerlässlich. Erkenntnisse auf beiden Seiten spiegeln sich konstant in den gemeinsamen Arbeitsartefakten wider und macht daher eine Synchronisation, besser noch eine Kollaboration auf einem einzelnen Artefakt, notwendig. Das Tooling sollte dem Rechnung tragen. Gelingt der Round-Trip, ist eine aktuelle Prozessdokumentation gewährleistet und gemeinsames Verständnis der fachlichen und technischen Prozesse erleichtern die Analyse-Arbeit.

Implementierung des Round-Trips

Der Round-Trip erfordert:

• Regelmäßige Abstimmungsmeetings zwischen BA und SWE.
• Gemeinsame Tool-Nutzung oder Schnittstellen für den Modell-Austausch.
• Versionierung und Änderungsmanagement für beide Modelltypen.
• „Business-Readable“ Metriken aus den Monitoring-Systemen.

Schlussbetrachtung und Empfehlung

Es empfiehlt sich die skizzierte Aufteilung und die Implementierung eines robusten Round-Trips. Dies maximiert die Stärken beider Disziplinen und minimiert Risiken.

• Vorteile für die Business-Analyse: Fokus auf Geschäftsanforderungen, frühe Validierung, datengetriebene Optimierung.
• Vorteile für die Software-Entwicklung: Klare Verantwortlichkeiten, Einhaltung von Software-Engineering-Prinzipien, Robustheit und Wartbarkeit.
• Vorteile für das Unternehmen: Schnellere Time-to-Market, höhere Qualität der Prozessautomatisierung, bessere Skalierbarkeit, geringere Wartungskosten und kontinuierliche Prozessverbesserung.

Ein ausführbares BPMN-Modell ist ein hybrides Artefakt. Seine Erstellung ist eine Gemeinschaftsaufgabe, bei der die Business-Analyse den fachlichen Kern liefert und die Software-Entwicklung die technische Ausführbarkeit sicherstellt – ergänzt durch einen kontinuierlichen Feedback-Kreislauf. Daraus ergibt sich auch ein benötigtes Kompetenzprofil auf seiten der Business Analyse und Software-Entwiclung

NoCode/LowCode-Entwicklung

Die NoCode-/LowCode-Entwicklung stellt in dieser Hinsicht eine Besonderheit dar, da in der Regel versucht wird, Nicht-Technikern entsprechende Implementierungsmöglichkeiten zu geben. Aus diesem Grund kommt es dann dazu, dass Business Analyse und Entwicklung in Personalunion existieren. IN diesen Fällen ist die Gestaltung eines Software-Entwicklungsprozesses von besonderer Bedeutung. Es muss vermieden werden, zu schnell in die technische Realisierung einzusteigen, ohne eine grundlegende und gründliche Analyse der Anforderungen vorgenommen zu haben. Es können also Business Analyse- und Software-Entwicklungs-Aktivitäten von einer Person vorgenommen werden. Wir empfehlen jedoch, einen wohl definierten Prozess zu definieren, der die Qualität der beiden Aufgabenbereiche sicherstellt. Auch wenn die Hersteller von NoCode-/LowCode-Tools artikulieren, dass keine Software-Entwickler mehr nötig sind, so bleibt der Softwareentwicklungsprozess, der Business Analyse und Implementierung enthält unverzichtbar.

Quellen und weiterführende Literatur

• Object Management Group (OMG). „Business Process Model and Notation (BPMN) Version 2.0.2.“.
• International Institute of Business Analysis (IIBA). „A Guide to the Business Analysis Body of Knowledge (BABOK® Guide).“ (Version 3).
• IEEE Computer Society. „IEEE Standard for Software and System Requirements Specifications.“ (oder ähnliche Standards).
• Schwaber, K., & Sutherland, J. „The Scrum Guide.“ (11/2020).
• Dokumentationen der jeweiligen BPM-Suiten und Prozess-Engines (z.B. Camunda Platform Documentation, Flowable Documentation).
• Krumrey, Peter (2018). BPMN 2.0 – Eine Einführung in den Standard. dpunkt.verlag.
• Rosemann, M., & vom Brocke, J. (Eds.). (2015). Handbook on Business Process Management 1: Introduction, Methods and Information Systems. Springer.