Agile Methoden wie Scrum beinhalten in regelmäßigen Abständen das Vorführen der fertig gestellten Funktionalitäten (bzw. Features) in so genannten Reviews. Das schafft Transparenz, Akzeptanz und ist weiterhin förderlich für die Motivation, weil man eben stolz das Erreichte zeigen kann.
Aber was tun, wenn die Funktionalität für den Anwender größtenteils oder sogar vollständig unsichtbar abläuft und auch nur Artefakte auf einem sehr technischen Niveau erzeugt, wie es bei automatisierten Geschäftsprozessen häufig der Fall ist? Vorbeiflitzende Konsolenausgaben sind da genauso wenig hilfreich wie kryptische XML-Dateien, die erzeugt worden sind oder Aussagen wie: „Das Ergebnis steht dann in der Datenbank!“. Damit können und wollen die meisten Anwender nichts anfangen. Die Folge ist diese etwas lethargisch anmutende Konsumhaltung im Review. Zwar hat man hinterher das Gefühl, der Methode Scrum gerecht geworden zu sein, weil man ja ein Review durchgeführt hat, aber was hat man erreicht? Transparenz oder Akzeptanz? Wohl kaum – und die eigene Motivation hat auch nicht gerade zu einem Höhenflug angesetzt, weil Feedback wie: „Super, genau so haben wir uns das vorgestellt!“ oder „Mensch, das sieht ja noch besser aus, als wir dachten. Weiter so!“ ausgeblieben sind.
Wie können wir nun dieses Dilemma auflösen, einen eigentlich unsichtbar ablaufenden Prozess nicht nur sichtbar, sondern auch anfassbar und begreifbar zu machen? Folgende Ansätze haben sich in unseren Projekten als hilfreich erweisen:
- Schrittweise Prozess-Ausführung
Viele Prozess-Engines bieten die Möglichkeit, Prozesse gezielt schrittweise auszuführen und dies dabei grafisch darzustellen. Gestützt durch vorbereitete Szenarien lassen sich so gezielt bestimmte Abläufe auf Ebene des Prozesses anschaulich darstellen und verfolgen.
- Fachlich aufbereitete Datenstände
Zeigen Sie die Daten, die durch den Prozess erwirtschaftet wurden. Durch gezielte SELECT-Statements lassen sich die erzeugten Daten fachlich aufbereitet darstellen. Sinnvoll ist dabei zunächst die Bereinigung um technischen Overhead wie IDs, Timestamps, etc.. Weiterhin sollten die zu zeigenden Objekte und Zusammenhänge nach Möglichkeit auf einen Blick sichtbar sein. Hier helfen entsprechend fachlich motivierte JOINs über mehrere Tabellen. Im Zusammenspiel mit der schrittweisen Ausführung lassen sich so gezielt Datenstände zu bestimmten Zeitpunkten nachvollziehen. - FIT als (Ersatz-)Oberfläche
Da wir bei automatisierten Prozessen wenige bis gar keine Oberflächen haben, können wir Sachverhalte nicht in Dialogen darstellen. Hier kann das FIT-Framework helfen, da die Eingangs- und Ausgangsdaten auf einem abstrakteren Niveau als in der Datenbank dargestellt werden können. Da FIT-Tests in der Regel mit den Anwendern zusammen konzipiert werden, haben wir hier oft den Effekt feststellen können, dass sich die Anwender über dieses Vehikel sogar mehr mit den technischen Gegebenheiten beschäftigen und sich diesen öffnen. - Review als Dialog
Das Review sollte kein reiner Frontalvortrag sein. Klar, die Entwickler sollen und wollen zeigen, was sie geschafft haben. Aber dies gelingt besser, wenn man das Publikum einbindet. Und es ist wirklich nicht schwer: Überlegen Sie anhand ihrer vorbereiteten Szenarien (siehe oben), an welchen Stellen gezielte Fragen ins Publikum sinnvoll sein können. Zum Beispiel können Sie nach dem aktuellen Zustand oder den Inhalten eines im Prozess verarbeiteten Geschäftsobjekts fragen und die Antwort nach Ausführung des betreffenden Prozessschrittes mittels eines aufbereiteten SELECT-Statements kontrollieren. Oder Sie fragen an einem Gateway im Prozess nach dem zu erwartenden weiteren Verlauf auf Basis der aktuellen Datenlage.
Letztlich geht es darum, dem Publikum – und das können neben den Anwendern beispielsweise auch Abteilungsleiter sein – eine Geschichte zu erzählen und die Zuhörer/Zuschauer aktiv in die Geschichte einzubauen. Das ist zwar in der Vorbereitung etwas aufwändiger, macht aber in der Durchführung deutlich mehr Spaß und führt vor allem zu mehr Erfolg: Transparenz, Akzeptanz und Motivation.
Und mal ehrlich: ist das nicht auch ein Teil von Business-IT-Alignment?
Danke, dass Du dieses wichtige Thema ansprichst. Mir fällt noch eine Möglichkeit ein, wie die Prozesse dem Publikum präsentiert werden können: in einem Business Activity Monitoring Dashboard, falls BAM eingesetzt wird. Man kann sich diese Frage allerdings auch andersherum stellen. Gehört es nicht zu jeder Prozessautomatisierung dazu, ein Monitoring über die Prozessausführung zu etablieren? Es ist sicherlich notwendig, wenn die entwickelte Lösung in Betrieb geht, also warum sollte es nicht im Rahmen des Sprints erarbeitet werden? Und mal ehrlich, eine Definition of Done, die lautet „Prozessausführung kann im BAM-Dashboard monitored werden“ erscheint mir wesentlich attraktiver als die über SQL-Statements in der Datenbank, aber das ist Geschmackssache.