Den Tages­finanz­status von Software­robotern erstellen lassen

Der Konzern erstellt an jedem Bank­arbeits­tag einen Tages­finanz­status über alle Gesellschaften. Der Ablauf ist vollständig dokumentiert und vollständig manuell: Kontoauszüge aus fünf Bank­verbindungen über zwei Zugangswege in das ERP-System einlesen, die Salden je Gesellschaft aus einem Report übernehmen, zwei Excel-Berichte fortschreiben, beide als PDF ablegen und an einen festen Verteiler senden. Das muss früh am Tag fertig sein, weil daran die Rücksprache zwischen Bilanzierung und Finanzierung über Liquiditäts­überträge zwischen den Konten hängt. Ein Ablauf also mit Terminzwang und ohne Entscheidung. Der Auftrag ist, für genau diesen Prozess erstmals einen Software­roboter zu entwickeln — und die eigenen Leute dabei so einzubinden, dass sie den nächsten selbst entwickeln können.

Der Prozess war vor dem Angebot schon aufgeschrieben, und zwar von denen, die ihn ausführen. Das ist der Grund, warum dieses Projekt klein bleiben konnte. Die Fachabteilung hatte jeden Schritt dokumentiert, bis hin zu den Wortlauten der E-Mails, die der Roboter senden soll, und bis zu den Stellen, an denen der Ablauf regelmäßig hakt. Wir mussten den Prozess nicht erheben. An zwei Stellen stand in der Beschreibung wörtlich, dass das Lösungsdesign offen ist. Genau diese zwei Stellen haben wir im Projekt gemeinsam mit der Fachabteilung entschieden.

Zwei Roboter, weil ein einzelner an einer Stelle warten müsste. Das Einlesen der Auszüge läuft im ERP-System als Job, dessen Laufzeit mit der Menge der Umsätze schwankt. Ein einzelner Roboter hätte davor gestanden und gewartet, mit allen Folgen für Zeitfenster und Fehlerbehandlung. Deshalb startet der eine Roboter den Job, und der zweite fragt die Jobübersicht ab und arbeitet weiter, sobald der Lauf durch ist. Das ist keine elegante Architektur, sondern eine, die zu dem System passt, in dem sie arbeitet.

Bewusst nicht auf dem Standardgerüst entwickelt. Die gängige Empfehlung für Roboter dieser Art ist ein Rahmenwerk mit Protokollierung, Wiederaufnahme und Warteschlangen. Wir haben darauf verzichtet, weil die Mitarbeiter des Kunden mitentwickeln sollten und ein solches Rahmenwerk am Anfang mehr verdeckt als es erklärt. Der Preis dafür stand im Angebot: Wenn das Wissen im Haus gewachsen ist, kann der Roboter umgestellt werden. Für den ersten Roboter zählt, dass die eigene IT versteht, was er tut.

Entwickelt wurde in Sprints, besprochen wurde am Bildschirm. Nach jedem Zyklus haben wir die neu gebauten Abschnitte mit den Projekt­mitarbeitern des Kunden im Paar durchgesprochen. Die größeren fachlichen Tests hat der Kunde selbst übernommen, wir haben dabei nur unterstützt. Das war nicht Sparen an der Qualitäts­sicherung, sondern die Stelle, an der Wissen übergeht: Wer den Testfall selbst formuliert, kennt danach den Ablauf des Roboters.

Am Ende steht ein Roboter im Betrieb, nicht ein Prototyp in einer Präsentation. Er meldet Ausnahmen an namentlich hinterlegte Empfänger, er versendet die Berichte an den bestehenden Verteiler, und er läuft nach Auskunft des Kunden seit der Produkt­ivsetzung täglich. Betrieb, Überwachung und Wartung liegen beim Kunden. Das war so vereinbart und ist die Voraussetzung dafür, dass ein Automatisierungs­vorhaben nicht in einer Abhängigkeit endet.