Auch wenn wir im Zuge der Digitalisierung meist zuerst an Automatisierung denken, gibt es immer noch eine Menge Dinge, die nur von Menschen erledigt werden können. Eine optimale Unterstützung der Nutzer*innen von Prozessanwendungen ist, neben der Automatisierung, darum der wichtigste Baustein der Digitalisierung von Geschäftsprozessen. Die erste Frage, die sich dabei aus Anwendersicht stellt: „Wo und wie finde ich meine Arbeit?“
Eigentlich hatte man sich von der Einführung einer Prozessengine erhofft, flexibel und gleichzeitig zuverlässig Anpassungen am Geschäftsablauf der Anwendung vornehmen zu können. Leider kommt es immer wieder zu Fehlern im Produktivbetrieb, da bei den Änderungen Abhängigkeiten im Prozess übersehen werden. Auch dass eine komplette Integrationsumgebung aufgesetzt wurde, um den Prozess vorab durch Tester manuell testen zu lassen, hat nur bedingt Besserung gebracht: Wiederholt rutschen Bugs in die Produktion durch. Die Idee, diese Tests automatisiert ablaufen zu lassen, wurde aufgegeben – zu aufwändig waren die Provisionierung der Integrationsumgebung, automatisierte Testdatenbereitstellung in allen beteiligten Systemen sowie die Pflege der Testabläufe im Fall von fachlichen Prozessänderungen. Und mit den gefundenen Fehlern konnte sowieso niemand etwas anfangen – sie waren unspezifisch und es dauerte Stunden, bis die Ursache gefunden und behoben werden konnte.
Waren die vollmundigen Versprechen des Zusammenwachsens von Fachbereich und IT durch die gemeinsame Arbeit mit Prozessmodellen also nur ein schöner Traum? Könnte man meinen. Es geht aber besser. Und wie das geht, wollen wir in diesem Blogbeitrag erklären.
Wer hat das nicht schon mal erlebt? (Gern und besonders schlimm in großen Projekten): Der Fachbereich formuliert Wünsche und weil die IT diese ja niemals verstehen würde, gibt es diverse Proxies, die das Geschwafel des Fachbereichs übersetzen. Dieses ist natürlich viel zu unkonkret und oberflächlich. Es gibt Business Analysten, die Fachkonzepte schreiben, Modellierer und Architekten, die alles genau durchdenken und in Modelle (häufig UML) gießen, so dass die Entwickler nur noch programmieren müssen. Im Gutfall gibt es dann noch Tester, die die Ergebnisse der Entwickler verifizieren und an den Fachbereich zurückmelden. Im Schlechtfall geht die Kommunikation die ganze Kette vom Entwickler über Architekten und Business Analysten zurück zum Fachbereich. Denn natürlich versteht dieser das Entwickler-Kauderwelsch ebensowenig.
Klingt irgendwie unagil und falsch? Ist es auch. Warum es gerade bei BPM-Projekten so nicht laufen muss, erkläre ich im Folgenden.
Wenn Sie sich mit der Automatisierung von Prozessen in einer Business Process Engine (BPE) beschäftigen, stehen oder standen Sie vielleicht auch schon vor der Frage, welche Daten Sie als Payload durch den Prozess schleusen.
Dass diese Frage alles andere als trivial und doch manchmal ganz leicht zu beantworten ist, haben wir kürzlich im Projekt erfahren.
In der Theorie ist das inklusive Gateway der BPMN-Notation eine feine Sache. In der Modellierung kommt es in zwei Szenarien zum Einsatz: Beim Verzweigen werden die Bedingungen aller ausgehenden Pfade ausgewertet und alle Pfade, deren Bedingungen zutreffen, aktiviert. Beim Zusammenführen wird auf alle aktiven eingehenden Pfade gewartet, der Ablauf wird an dieser Stelle also synchronisiert. Was sich so einfach anhört, stellt sich aber in der Praxis als nicht ganz so trivial dar, insbesondere, wenn verzweigendes und synchronisierendes Gateway nicht paarweise auftreten. Daher rät die einschlägige Fachliteratur hier zu eben jener Blockstruktur mit einem verzweigenden Gateway und einem korrespondierenden Gateway, dessen Eingänge die Ausgänge des Verzweigenden sind.
weiterlesen