Automatisierung von Fachprozessen: Wie hilfreich sind Low-Code und BPMN

Viele deutsche Unternehmen haben Probleme mit der Automatisierung ihrer Fachprozesse. Das lässt sich in der Praxis eindrucksvoll beobachten. Wer neue Technologien einsetzt, aber bisherige Ansätze verwendet, steht über kurz oder lang vor denselben Problemen wie in der Vergangenheit. Letztendlich ist ein Zustand erreicht, in dem man sich dem Motto „never change a running system“ ausgeliefert sieht. Dies führt zu handlungsunfähigen IT-Abteilungen – die aber gerade in der digitalen Transformation besonders handlungsfähig sein müssten.

In Teil 1 meines Blog-Artikels zeige ich auf, warum die herkömmliche Programmierung der Fachprozesse nicht mehr zukunftsfähig ist. Ich erläutere, dass auch Low-Code und BPMN (Business Process Model and Notation) in der Praxis kaum dabei helfen, die Prozessautomatisierung in den Griff zu bekommen – wenn Unternehmen sie falsch verstehen und nutzen. So viel sei bereits verraten: Es gibt einen nachhaltigen Ansatz hierfür, den ich Ihnen in Teil 2 vorstellen werde.

Die aktuelle Situation: Never change a running system

Das reine Programmieren der eigenen Fachprozesse unter Verwendung von Programmcode ist nicht mehr zukunftsfähig. Grund dafür sind die Schnelllebigkeit und Komplexität der Welt, in der sich Unternehmen heute bewegen. Das Tempo, in dem innovative IT-Technologien auf den Markt kommen, wird immer rasanter. Damit wachsen auch die Erwartungen der Kundinnen und Kunden. Neue Geschäftsmodelle werden möglich, während die Regularien durch den Gesetzgeber weiter zunehmen. Damit ein Unternehmen am Markt bestehen kann, muss es auf all diese Faktoren heute und morgen flexibel reagieren können.

Angesichts dessen ist die reine Programmierung der Fachprozesse in Anwendungen zu aufwendig und unflexibel. Auch die Wartung ist schwierig, da es bei historisch gewachsenen Anwendungen an Transparenz mangelt. Viele Unternehmen trauen sich deshalb nicht mehr an ihre Anwendungen heran, sondern sehen sich dem Motto „never change a running system“ ausgeliefert. Die Lösung der Probleme wird also aufgeschoben. Irgendwann jedoch muss sich ein Unternehmen mit seinen historisch gewachsenen und intransparenten Anwendungen beschäftigen und hierfür wertvolle IT-Ressourcen bereitstellen.

Diese Situation ist heute in vielen Unternehmen anzutreffen – und sie ist für die Zukunft fatal. Denn sie verhindert, dass Fachprozesse mit IT-Unterstützung flexibel angepasst oder neue Fachprozesse geschaffen werden. Der Spielraum für Innovationen und neue Geschäftsmodelle ist stark eingeschränkt. Die Folge: Das Unternehmen büßt seine Wettbewerbsfähigkeit ein und wird im schlimmsten Fall in der Zukunft nicht mehr existieren.

Low-Code: Die traditionelle Denkweise muss aufgebrochen werden

Nach meiner Beobachtung kommen viele Unternehmen bei der Automatisierung ihrer Fachprozesse zu dem Schluss, dass sie dem Trend Low-Code-Entwicklung unreflektiert folgen müssen. „Nur so werden Sie erfolgreich!“, behauptet das Marketing der Softwarehersteller und kann damit offenbar überzeugen. Der Ursprung des Trends findet sich in den 1990er Jahren. Die Idee ist, dass sich die Anwendungsentwicklung dank graphischer, vordefinierter Bausteine beschleunigt. Zusätzlich lässt sich individueller Programmcode integrieren. Letztendlich handelt es sich hierbei lediglich um einen Marketing-Begriff, nicht um einen Standard. Man kann Low Code vielleicht als eine Entwicklungsphilosophie auffassen, aber auf keinen Fall als vollständigen Implementierungsansatz.

Low Code gibt es für verschiedene Einsatzgebiete. Im Kontext von professionellen Unternehmensanwendungen beobachte ich bei der Mehrzahl der Softwarehersteller, dass diese die Abhängigkeit ihrer Kunden von ihren Plattformen in Kauf nehmen. Unter dem Aspekt einer schnelleren Anwendungsentwicklung bieten sie spezifische Konnektoren für die Anbindung verschiedener Systeme an. Sie werben damit, dass man dank des Konnektors innerhalb der fachlichen Prozessablauflogik direkt das benötigte System aufrufen kann.

Zum Beispiel bieten aktuell nahezu alle Softwarehersteller einen Konnektor zu ChatGPT bzw. OpenAI an. So kann man im Rahmen des Fachprozess gleich diese Funktionalität nutzen. Doch was passiert mit den Fachprozessen, wenn der ChatGPT-Serviceanbieter später die Lizenzgebühren drastisch erhöht? Dann muss das Unternehmen die Anbindung des Services in allen Fachprozessen austauschen.

Im Unternehmen entsteht also eine enge Kopplung zwischen der wertvollen Prozessablauflogik und der Systemlandschaft. Bei Migrationsprojekten von Systemen fehlen der IT die Möglichkeiten, bei der Umsetzung von Innovationen und neuen Geschäftsmodellen zu helfen. Stattdessen muss sie sich aufwendig mit der Anpassung der Anwendungen beschäftigen.

Zudem bieten die Softwarehersteller solcher Plattformen oft eigene Notationen in verschiedenen Ausprägungen an: von textuell bis angelehnt an Flussdiagramme. Auch für die Daten- und Frontend-Implementierung gibt es eigene Editoren und Ansätze. Die hier entstehenden Artefakte lassen sich nicht in andere Produkte exportieren.

Was sagen die Hersteller zu den Migrationsmöglichkeiten?

Fragt man die Softwarehersteller nach den Migrationsmöglichkeiten, erhält man typischerweise die folgenden Antworten:

• Einzelne Artefakte (meist Daten oder Formulare) lassen sich in die JavaScript Object Notation (JSON) exportieren. Damit soll die Migrationsmöglichkeit ausreichend gegeben sein. Problem ist, dass die JSON-Struktur, in der das jeweilige Artefakt vorliegt, herstellerspezifisch ist. Dafür müsste ein Unternehmen die Struktur analysieren und ein Tool für die automatische Migration entwickeln. Dies ist zu aufwendig und kostenintensiv.
• Man könne die Anwendung via Copy-and-paste in eine andere Plattform übertragen, heißt es. Dies ist aber schon heute kein guter Entwicklungsstil, da keine Code-Fragmente wiederverwendet werden können. Auch dieser Ansatz ist zu aufwendig. Man müsste erst die fachliche Prozessablauflogik sowie die Unterschiede und Eigenheiten der beiden Plattformen verstehen, um dann den Fachprozess auf die spezifischen Eigenheiten der anderen Plattform zu übertragen.
   

Damit wird die Abhängigkeit vom Produkt des Softwareherstellers enorm erhöht – zugleich auch das Risiko des Unternehmens, seine Wettbewerbsfähigkeit zu verlieren. Denn keiner kann heute sagen, ob die gewählte Plattform in zehn bis 15 Jahren noch in dieser Form existieren wird.

BPMN: Ein falsches Verständnis steht dem Erfolg im Weg

Während bei Low-Code-Plattformen meist proprietäre (also herstellergebundene) Notationen für die Abbildung von Fachprozessen verwendet werden, ist die BPMN (Business Process Model and Notation) ein Standard mit vordefinierten Regeln und Elementen. So ein Standard ermöglicht die einheitliche Beschreibung von Fachprozessen, die Verständlichkeit für alle Prozessbeteiligten sowie die Portierbarkeit in andere Workflow-Management-Systemen oder -Plattformen.

Die BPMN ist dafür gedacht, Prozesse aus Sicht der Fachexpertinnen und -experten zu beschreiben. Dieser graphische Fachprozess kann nahezu unverändert in einem BPMN-basierten Workflow-Management-System ausgeführt werden. Damit lässt sich eine Brücke zwischen Fach- und IT-Implementierung realisieren. Die BPMN ermöglicht es Unternehmen, ihren Schwerpunkt auf die Fachprozesse zu legen. Die IT spart dadurch Zeit und muss nicht die Steuerung der Prozesse implementieren.

In der Praxis herrscht jedoch oft ein falsches Verständnis der BPMN und von Workflow-Management-Systemen vor. Leider verstehen viele nicht, dass ein Workflow-Management-System als eine Infrastrukturkomponente für die Ausführung der Prozessablauflogik gedacht ist – mehr nicht. Die BPMN wird dann methodisch und syntaktisch nicht richtig angewendet. So kann sie ihre Potentiale nicht entfalten, also nicht zu der erhofften Transparenz des Fachprozesses und einer effizienten Kommunikation zwischen Fachbereich und IT führen.

Die Tücken der traditionellen zweistufigen Implementierung

Mit diesem falschen Verständnis geht einher, dass BPMN-basierte Workflow-Management-Systeme traditionell mit einem zweistufigen Implementierungsansatz genutzt werden: unter Verwendung eines fachlichen Prozessmodells, das im zweiten Schritt in ein technisches Prozessmodell münden soll. Der gewünschte Erfolg kann sich auf diese Weise kaum einstellen.

Die Kluft zwischen Fachbereich und IT wird künstlich groß gehalten. Beispielsweise werden Fachprozesse nur in einer spezifischen Modellierungsplattform für den Fachbereich beschrieben. Meist ist der Prozess zwar mit Elementen der BPMN dargestellt, aber nicht syntaktisch und methodisch richtig abgebildet. Zudem finden sich auf Detailebene nicht die relevanten Prozessinformationen wieder. Dieses schlechte grafische Prozessmodell wird als fachliches Prozessmodell gesehen.

Im Rahmen der Umsetzung durch die IT-Entwicklung wird auf Basis dieses „fachlichen Prozessmodells“ ein „technisches Prozessmodell“ erzeugt. Dieses liegt auch in der BPMN vor, da man in einem BPMN-basierten Workflow-Management-System arbeitet. Die Entwicklerinnen und Entwickler haben das Verständnis, sie müssten das grafische Modell um Implementierungsdetails ergänzen. Dadurch entstehen zwei verschiedene Prozessmodelle – und große Probleme. Stattdessen hätte das grafische Prozessmodell so gut sein müssen, dass es nahezu unangetastet bleiben kann. Dann hätte sich das technische Prozessmodell aus dem fachlichen Prozessmodell (zuzüglich Konfiguration sowie ergänzende Implementierung von Fachkomponenten) ergeben.

BPMN im echten Leben: Wenn niemand mehr den Fachprozess versteht

Die Auswirkungen eines solchen Irrglaubens konnten einige Beteiligte bereits im frühen Stadium einer Prozessautomatisierungsinitiative erleben. Hier ist genau die von mir aufgezeigte Folge eingetreten: Sobald die wissenstragenden Personen das Projekt verlassen, kann niemand mehr das Prozessmodell verstehen – denn fachliche Prozessinformationen sind mit technischem Prozessinformationen vermischt. Wohlgemerkt, das technische Prozessmodell ist in der BPMN, von der die meisten wohl glauben, allein die Nutzung der BPMN-Elemente sorge für Kommunikationseffizienz. Dies ist nicht der Fall: Die BPMN liefert eine Syntax mit, und kluge Köpfe haben praxiserprobte Methodiken erarbeitet, welche die Definition von Fachprozessen in BPMN effektiv und effizient gestalten lassen. Sie müssen aber auch angewendet werden. In dem erwähnten Projekt mussten die Prozesse schließlich neu definiert und implementiert werden. Denn aus diesem Prozessmodell konnte niemand den Fachprozess verstehen.

Eine spätere Migration wird aufwendig, da sich die Fachlogik mit der spezifischen Implementierung, die das Workflow-Management-System benötigt, vermischt. Die Systemintegration ist eng an den Fachprozess gekoppelt, da die Softwarehersteller Schnelligkeit bewerben und spezifische Konnektoren für die Systeme anbieten. Dass dies kein nachhaltiger und zukunftsweisender Integrationsstil ist, haben wir oben gesehen. Hinzu kommt, dass für eine Integration eines Systems mehr Aufgaben zu erledigen sind, als nur einen Konnektor bereitzustellen. Zum Beispiel sind die vorliegenden Daten in das Datenformat des Zielsystems zu bringen. Dies ist nicht Aufgabe eines Workflow-Management-Systems. Stattdessen gibt es dafür spezifische Integrationsplattformen und -frameworks.

Die beschriebenen Ansätze haben eines gemeinsam: Sie helfen Unternehmen wenig, die Herausforderungen des 21. Jahrhunderts erfolgreich zu meistern und wettbewerbsfähig zu bleiben. Wertvolle IT-Ressourcen werden allein dafür gebraucht, den Betrieb am Laufen zu halten. Wie sich Migrationsaufwände reduzieren lassen, lesen Sie im zweiten Teil meines Blog-Artikels, in dem ich einen nachhaltigen Ansatz zur Lösung der skizzierten Herausforderungen vorstelle: den Prozessgesteuerten Ansatz nach Volker Stiehl.