Process Engineering und Process Mining
Ein Geschäftsprozess ist eine festgelegte Folge von Schritten: Antrag stellen, prüfen, genehmigen, abrechnen. Process Engineering heißt, solche Abläufe zu modellieren und als Software auszuführen. Process Mining geht den umgekehrten Weg: Jedes IT-System schreibt mit, wer wann welchen Schritt ausgeführt hat, und aus diesen Protokollen lässt sich der tatsächlich gelaufene Prozess rekonstruieren, samt aller Abweichungen vom geplanten.
Mein Schwerpunkt sind prozesszentrierte Objekte (Process-centric Objects). Ein gewöhnliches Objekt hat Felder und Methoden, und die Methoden lassen sich in beliebiger Reihenfolge aufrufen; welche Reihenfolge sinnvoll ist, weiß nur der Code drumherum. Ein prozesszentriertes Objekt bringt diese Reihenfolge selbst mit, als Prozess, der zu ihm gehört. Der Unterschied zeigt sich daran, was am Ende ausgeführt wird. Üblicherweise entsteht eine Software in zwei Schritten: Fachleute und Entwickler einigen sich auf einen Entwurf, und anschließend übersetzt jemand diesen Entwurf in Quelltext. Was läuft, ist der Quelltext; der Entwurf hängt daneben an der Wand und veraltet mit der ersten Änderung, die nur im Code passiert. Eine Low-Code-Plattform lässt den zweiten Schritt weg: Sie führt den Entwurf selbst aus und steuert Oberfläche, Datenhaltung und Aufgabenverwaltung bei, die man sonst programmieren müsste. Entwurf und Implementierung sind damit dasselbe Artefakt, und Modellieren wird zur eigentlichen Entwicklungsarbeit.
Die Prozesse, also wann welche Funktion im Programm überhaupt erlaubt ist, modelliert man als Petri-Netze: als Graphen, die festhalten, welcher Schritt wann möglich ist und was dabei nebenläufig geschehen darf. Damit stellt sich die Frage nach gutem Entwurf neu: Prinzipien wie lose Kopplung, hohe Kohäsion oder eine klare Verantwortlichkeit je Klasse sind für Quelltext formuliert. Ich untersuche, welche davon auf ein Netz zusammenarbeitender Prozessklassen übertragbar sind, welche fehlen und welche sich so fassen lassen, dass ein Werkzeug sie nachprüfen kann.
Daneben interessiert mich die empirische Seite: Wie verständlich ist ein Prozessmodell für den Menschen, der es lesen muss? Das lässt sich messen, statt es zu behaupten. In Studien mit Studierenden stelle ich Fragen zu Modellen und werte Trefferquote und Antwortzeit gegen Eigenschaften des Modells aus, etwa gegen die Zahl der Knoten oder den Grad an Nebenläufigkeit. Das Werkzeug dafür, „Petri-Dish", habe ich selbst gebaut.
