Wenn „NoCode“ nicht mehr ausreicht. In unserem zweiten Teil zeigen wir die Grenzen von NoCode-Plattformen zur Prozessdigitalisierung. Da, wo ein Unternehmen einen Geschäftsprozess implementieren möchte, empfiehlt es sich, ein Workflowmanagementsystem zu verwenden, das richtige Entwicklung zulässt. Denn dann bewegt man sich in den Grenzen der gewählten Programmiersprache und diese Grenzen sind nahezu unendlich. Doch auch bei den Workflowmanagementsystemen, die man nicht als NoCode-Plattform bezeichnet, gibt es große Unterschiede.
Digitalisierung komplexer Prozesse
Bei der Implementierung von Workflows, die echte Unternehmensgeschäftsprozesse abbilden oder sogar Prozesse, die sich über mehrere Unternehmen erstrecken, wie z.B. bei einem Logistikprozess, müssen viele Aspekte beachtet werden. Ein Beispiel: Bei einem Logistikdienstleister soll der Lieferprozess eines Maschinenherstellers vom Lieferanten über den Logistikdienstleister hin zur Montage im Werk des Maschinenherstellers und dann weiter zur Betriebstätte der Maschine abgebildet werden. Da es sich hier um einen umfangreichen Prozess handelt, der sich über mehrere Unternehmen (Lieferant, Logistikdienstleister, Maschinenhersteller) erstreckt und weit von einem üblichen Standardprozess entfernt ist, lässt sich an dieser Stelle nicht viel ausrichten mit einer NoCode-Plattform. Die Grenzen wären zu eng gesetzt als dass man diesen Prozess mit einer solchen Technologie abbilden könnte.
Wie digitalisiert man komplexe Prozesse maßgeschneidert, stabil und wartbar?
Die Größe dieses Logistikprozesses erfordert ein ganzes Entwicklungsteam, da sich bei einem einzelnen Entwickler die Implementierung auf nicht akzeptable Weise in die Länge ziehen würde. An dieser Stelle sind wir bereits bei einem wichtigen Kriterium für die Auswahl eines geeigneten Workflowmanagementsystems. Das gewählte System muss die Verwaltung der entwickelten Workflows über ein Versionsverwaltungssystem wie git zulassen. Es genügt nicht, wenn das Workflowmanagementsystem grundsätzlich den Einsatz eines solchen Systems zulässt. Wichtig ist auch, dass alle Dateien sich am Standard orientieren. Zum Beispiel stellen proprietäre Dateiformate eigene Dateiformate für Prozesse und nicht den Standard BPMN 2.0, was ein echtes Problem für die Entwicklung darstellt. Sobald mehrere Entwickler denselben Prozess bearbeiten, führt dies unweigerlich zu Merge Conflicts, die in der Softwareentwicklung normal sind. Dann muss das Dateiformat aber für die Entwickler lesbar sein und darf keine kryptischen Inhalte aufweisen, da sonst das Lösen der Merge Conflicts zur echten Mammutaufgabe wird, die die ganze Entwicklung ausbremsen kann.
Updatefähigkeit des Workflowmanagementsystems ist ein weiteres wesentliches Kriterium für die Auswahl – und das gleich in doppelter Hinsicht. Einerseits baut – wie in der Informatik unumgänglich – auch ein Workflowmanagementsystem auf andere Technologien auf. Das heißt offensichtlich auch, dass ein Fehler in einer darunterliegenden Technologie sich auf den implementierten Workflow auswirken kann. Dann ist es unabdingbar, dass die Entwickler des Workflows in der Lage sind, die darunterliegende Technologie upzudaten, beziehungsweise die Version anzuheben, um den Fehler durch eine neuere Version zu beheben. Aber auch das Workflowmanagementsystem selbst muss updatebar bleiben. Oft wird das Look und Feel des Systems an das Corporate Design des Unternehmens angepasst. Dadurch kann aber die Fähigkeit verloren gehen, neue Updates vom Hersteller zu beziehen, was katastrophale Folgen haben kann. Es ist utopisch zu glauben, dass Software fehlerfrei ausgeliefert wird. Und Workflowmanagementsysteme sind eben auch Software, für die Updates notwendig und wichtig sind. Aus dem Grund muss ein Workflowmanagementsystem auch dann updatebar bleiben, wenn es customized wurde.
Die beschriebenen Kriterien zeigen, dass bei der Workflowimplementierung das Augenmerk auf dieselben Probleme gelegt werden muss, wie bei der normalen Softwareentwicklung. Zusätzlich ist es entscheidend, bei Prozessen in der Größenordnung des beispielhaften Logistikprozesses, dass der Workflowimplementierung eine ordentliche Softwarearchitektur zu Grunde liegt, dass Wert auf die Softwarequalität gelegt wird (Stichwort Clean Code) und automatisierte Test geschrieben werden. Dass eine ordentlich Versionsverwaltung unabdingbar ist, sollte an dieser Stelle niemand mehr anzweifeln.
Das führt uns zur Eingangsfrage: Ist Workflowimplementierung Softwareentwicklung?
Diese Frage lässt sich mit einem eindeutigen Jein beantworten. Solange kleine Standardprozesse auf NoCode Plattformen abgebildet werden, wäre es etwas überheblich, von Softwareentwicklung zu sprechen. Bei echten Geschäftsprozessen, aus der Wertschöpfungskette eines Unternehmens, stößt man auf die gleichen Probleme wie in der normalen Softwareentwicklung. Auch müssen dieselben Anforderungen und Qualitätsstandards an die Workflowimplementierung gestellt werden. Denn letztendlich ist die Workflowimplementierung nichts anderes als Softwareentwicklung, lediglich mit einer weiteren Technologie auf dem Technologiestack.
Vorteile:
- Maßgeschneiderte Integration in die bestehende IT- und Technologielandschaft
- Flexibel bei der Umsetzung von Sonderwünschen
- Anpassbarkeit auf Unternehmensbranding / Marke
- Möglichkeiten der Testabdeckung über Funktionen hinaus
Nachteile:
- Oft höherer Aufwand in Zeit und Kosten
- Setzt Kompetenzen in der Software-Entwicklung und Workflow-Architektur voraus
Sie planen, einen Prozess zu digitalisieren und sind unschlüssig bei der Auswahl der richtigen Systeme? Sie haben bereits eine Workflow-Engine im Einsatz und benötigen neutralen Sparring? Sprechen Sie uns gerne unverbindlich und direkt an oder vereinbaren Sie hier direkt einen unverbindlichen Termin!
Autor: Philipp Hehnle, Head of Technology
Autor
Philipp Hehnle
Head of Technology
