Chancen und Risiken des Zero-Coding-BPM

Es existieren mittlerweile einige gute BPM-Systeme und -Suiten die es ermöglichen Prozesse komplett ohne Programmierung zu realisieren. In einigen Tools wird mehr modelliert und in anderen eher konfiguriert. Durch die stetige Verbreitung anerkannter Standards (von WebServices, über BPEL und auch BPMN) haben auch die Software-Hersteller eine immer breitere Basis auf denen ihre Tools aufgebaut werden können.

Doch wo liegen die Chancen und Risiken der auf dem Markt existierenden Zero-Coding-Lösungen? Fangen wir aber ganz vorne an. Was verstehe ich unter Zero-Coding? Im Idealfall beschreibt Zero-Coding eine Vorgehensweise zur Implementierung eines Prozesses in einer Prozess-Engine ohne eine einzige Zeile Code zu programmieren. Hier sind viele erst einmal skeptisch, dass dies überhaupt funktioniert. Aber es gibt einige Systeme mit denen das möglich ist. Ich selbst kenne 3 solcher Systeme:

In allen drei Systemen habe ich schon Zero-Coding Prozesse implementiert und einsetzen können und kenne die Möglichkeiten und Grenzen der Systeme gut oder kann diese gut abschätzen. Also ist der Ansatz Zero-Coding heutzutage nicht mehr unrealistisch oder nicht erfüllbar.

Darüber hinaus habe ich schon gutes gehört über

Und es gibt noch einige Tools mehr, die eine Zero-Coding-BPM ermöglichen.

Wenn man die oben genannten Produkte etwas näher betrachtet merkt man schnell, dass dort verschiedene Arten von Prozessen fokussiert werden. Die einzelnen Tools haben sich teilweise auf bestimmte Prozesstypen spezialisiert oder decken auch mehrere Prozesstypen ab. Hier möchte ich auf die Prozessgruppierung von Forrester verweisen, die mir sehr gut gefällt:

  • people-intensive
  • decision-intensive
  • document-intensive
  • system-intensive

Die Ausprägung der verschiedenen Prozesse hat einen enormen Einfluss auf die Prozessmodellierung und die Tools, die dazu benötigt werden. So sind zum Beispiel bei “people-intensive processes” vor allem die Gestaltung der GUI interessant, sowie die Gestaltung der Formulare zur Bearbeitung einzelner Aktivitäten und eine damit verbundene notwendige Plausibilitätsüberprüfung der Benutzereingaben. Bei “document-intensive processes” steht die Verwaltung von Dokumenten im Vordergrund und damit z.B. Aspekte wie Versionsverwaltung, Archivierung, digitale Signaturen. Bei “system-intensive processes” stehen die Automatisierung und die Verarbeitung großer Datenmengen im Fokus. Natürlich gibt es auch Mischformen. Die größte Herausforderung für die Zero-Coding BPM liegt hier bei den people-intensive processes. Da nicht nur die Prozesse und die damit verbundenen Schnittstellen modelliert und konfiguriert werden müssen, sondern zusätzlich auch die GUI für den Endbenutzer. Hier gibt es je nach Toolhersteller verschiedene Ansätze.

Beim Opentext BPM werden zum Beispiel alle Felder angegeben die auf einem Formular angezeigt werden müssen, inklusive Validierung. Dann kann man noch die Position auf dem Formular mit Hilfe von Zeilen und Spalten-Angaben festlegen. Im Anschluss wird anhand eines Templates ein .NET Web-Formular generiert. Dieses kann man, wenn man möchte im MS Visual Studio weiter bearbeiten.

Bei Intalio wird der Tibco General-Interface Builder verwendet. Dieses Tool ist sehr mächtig. Es unterstützt die Einbindung von Datenbank-Quellen z.B. für DropDown Felder, AJAX-Funktionalitäten für mehr Dynamik im Formular und sehr umfangreiche Validierungsmechanismen. Dafür lassen sich die generierten Formulare nicht mehr so einfach manuell anpassen.

Eine weitere Herausforderung für alle Prozesstypen ist die Integration diverser Umsysteme. In Prozessen werden häufig Informationen benötigt, die aus Legacy-Systemen, Datenbanken, ERP-Systemen, Produktionssystemen, etc. gelesen werden müssen. Genauso oft werden neue Informationen generiert die in eines der Systeme zurückgeschrieben werden müssen. In den meisten BPM-Systemen werden hierfür verschiedene Adapter zur Verfügung gestellt, mit denen eine Schnittstelle konfiguriert werden kann. Diese Adapter existieren meistens für große etablierte Systeme, wie z.B. SAP R/3 und Nachfolger, verschiedene Datenbankserver oder sie nutzen etablierte Standards wie WebService, SOAP, JDBC, etc. Falls ein Adapter fehlt besteht in der Regel die Möglichkeit einen Enterprise Service Bus (ESB) zu nutzen, der die verschiedenen anzubindenden Systeme als Webservice kapselt und dem BPMS zur Verfügung stellt. Die Frage ob der Einsatz eines ESB sinnvoll ist häufig eine generellen strategischen Überlegungen. Sinnvoll ist auf jeden Fall eine lose Kopplung der Schnittstellen, so dass Systeme ausgetauscht werden können, ohne die Prozesse anpassen zu müssen in dem die auszutauschenden Systeme genutzt werden.

Wo liegen nun die Chancen und Risiken?

“Die größten Chancen liegen in der Geschwindigkeit!

Durch die Umfassende Unterstützung der BPM-Systeme und -Suiten können Prozesse extrem schnell implementiert werden und man erhält einen sehr kurzes “time-to-market“. Dadurch, dass man auf ein BPMS aufbaut, welches sich um das gesamte Handling der Prozessinstanzen (von der Persistierung verschiedener Status, Kontrolle des Prozess-Flow und Alerting bei Problemen) braucht man sich hier nur wenig Gedanken zu machen. Auch eine Änderung bestehender Prozesse ist häufig schnell implementiert und die BPM-Systeme übernehmen die Verwaltung der verschiedenen Prozess-Versionen. Dadurch wird sichergestellt, dass laufende Prozessinstanzen noch im “alten” Prozess beendet und neue Instanzen im “neuen” Prozess gestartet werden. Man kann sich auf den Prozess konzentrieren. Durch die Verwendung von Adaptern für die Integration von Drittsystemen entfällt in den meisten Fällen die Entwicklung einer Schnittstelle und den damit verbundenen Risiken (zumindest auf der BPMS-Seite). Häufig wird eine sehr umfangreiche GUI zur Verfügung gestellt, damit die Mitarbeiter mit den Prozessen arbeiten können, so dass man sich nur auf die Prozessformulare konzentrieren muss.

“Das größte Risiko ist ein ggf. beschränkter Funktionsumfang

Das größte Risiko stellt der Leistungsumfang der verschiedenen BPMS dar. Wenn bei einem Zero-Coding BPM eine Funktion nicht mehr ohne Entwicklung implementiert werden kann stellt sich die Frage, ob das BPMS erweiterbar ist. Hier sind vor allem die Open Source Tools ganz vorne mit dabei, da man bei diesen notfalls selber Hand anlegen kann. Closed Source Produkte bergen hier die große Gefahr, dass an einer bestimmt Stelle einfach Schluss ist. Wenn der Funktionsumfang nicht selbständig erweitert werden oder ein Problem nicht durch Konfiguration gelöst werden kann steht schnell ein kompletter Prozess auf der Kippe. Viele Closed Source Anbieter haben hier die Möglichkeit geschaffen zumindest eigene Adapter zu entwickeln und diese in den Prozessen zu nutzen. Dies ist sehr wichtig wenn einige proprietäre Systeme im Einsatz sind, die in die Prozesse integriert werden müssen. Ansonsten hat man eine große Abhängigkeit vom Hersteller. Darüber hinaus habe ich bei “human-intensive processes” festgestellt, dass die Validierungsmöglichkeiten nicht immer ausreichend sind. Bei der Prüfung einzelner Felder sind die Tools gut, aber wenn ich verschiedene Eingaben gegeneinander Prüfen muss wird es schwieriger (z.B. Prüfen ob Datum1 > Datum2). In einigen Systemen ist auch der Punkt Performance ggf. ein Problem. Durch die Architektur und die Verwendung von XML wird häufig ein gewisser Overhead erzeugt. In vielen Systemen wird die Prozessbearbeitung auch in Queues realisiert. Dieser Overhead und die Queues können bei Anforderungen die Richtung Echtzeit-Systemen gehen problematisch werden. Dies sind aber meistens sehr spezialisierte Systeme mit einem extrem hohen Datendurchsatz. BPM-Systeme die auf “system-intensive processes” ausgerichtet sind reichen nur in wirklichen Ausnahmefällen nicht mehr aus.

Zukünftig wird der Trend immer weiter Richtung Zero-Coding gehen, da der Geschwindigkeitsvorteil gegenüber der Programmierung und die damit verbundenen Einsparungen einfach enorm sind. Durch die immer stärkere Etablierung von Standardschnittstellen (z.B. WebServices) und den verschiedenen Service-Ansätzen (z.B. SOA) wird das Problem fehlender Adapter immer weiter reduziert.  Lediglich in Spezialanwendungen muss man bestimmt noch weiterhin selber Hand anlegen.

Commentary

Leave a response »

Trackbacks

  1. [...] wie weit die Toolhersteller mittlerweile sind. Alle vorgestellten Produkte waren ausschließlich Zero-Coding Lösungen. Im Kern der BPMS sind kaum noch Unterschiede auszumachen. Alle unterstützen Prozessversionierung, [...]

    Process Solution Day 2010 der gfo « BPM+

Leave a comment, a trackback from your own site or subscribe to an RSS feed for this entry. Trackback URL for this entry Comments feed for this entry

Leave a response

Leave a URL

Preview