Es ist einer der Tage, die zum Glück seltener geworden sind. Komplettausfall des zentralen IT-Systems, alle arbeiten fieberhaft an einer Lösung!  Und tatsächlich ist noch vor 10:00 Uhr die Welt wieder in Ordnung. In der Kundenorganisation kann wieder gearbeitet werden und beim Service Provider macht man sich auf die Suche nach den Ursachen der Schwierigkeiten. Irgendwann wird dann die übliche, nicht immer aussagekräftige „root cause analysis“ übermittelt. Alles gut.

Doch dann passieren Dinge, die noch niemand so erlebt hat. Plötzlich steigt die von Anwendern verursachte Last für das zentrale IT-System in ungeahnte Höhen.

Das konnte nicht nur an dem näher kommenden Monatsabschluss liegen. Hat man wieder Teilzeitkräfte in großer Zahl engagiert, die extrem fleißig aufwendig zu verarbeitende Buchungen vornehmen?

Nein, diesmal sind die Verursacher einige Software-Roboter, denen beigebracht wurde, wie Kontenklärungen zu erfolgen haben und die dann mit kurzer Frequenz die dazu notwendigen Umbuchungen vornehmen. Alle Roboter laufen als sogenannte „attended Bots“, also unter der Aufsicht von Mitarbeitern des Bereiches Finanzen. Nach dem Ausfall am Vormittag war es dann so, dass alle mit den neuen Robotern ausgestatteten Mitarbeiter („a robot for every person“ ist grundsätzlich keine schlechte Idee) diese nahezu gleichzeitig in Betrieb nahmen. „Weil der Monatsabschluss pünktlich erledigt sein muss“ und „bevor es morgen wieder nix wird“, waren die einleuchtenden Begründungen. Im Bereich IT-Security gibt es für dieses Szenario einen Namen: DoS („denail of service“). Besonders wirksam ist dies als „distributed denail of service“. Ein „distributed denail of service“ ist ziemlich genau das, was in unserem Fall passierte.

Leider war dies nicht der einzige unerwartete Ärger nach dem Ausfall. Im Bereich Marketing wurden Roboter gestartet, die massenhaft Erinnerungen für Angebote an Kunden versandt haben, ohne zu berücksichtigen, welche Kunden bereits auf die Angebote reagierten. Pünktlich um 10:00, wir wissen warum, wurden die Roboter angeworfen… Leider waren da die Rückmeldungen der Kunden noch nicht vollständig verarbeitet.

Natürlich ist die zeitliche Synchronisation von Verarbeitungen nicht unbedingt das Top-Argument für den Einsatz einer Orchestrierung im Zusammenhang mit RPA.

Aber sicher habt Ihr Euch auch schon folgende Fragen gestellt:

– Wo ist die (zentrale) Stelle, die den aktuellen Stand aller Verarbeitungen durch unsere Roboter kennt?

– Noch besser, wo ist die (zentrale) Stelle, die den Stand der Verarbeitungen in allen wichtigen Geschäftsprozessen kennt?

– Wie können mehrere Roboter in einem Prozess zeitgleich arbeiten, ohne sich gegenseitig „ins Gehege“ zukommen?

– Wo legen die Roboter die Zugangsdaten zu den Anwendungen sicher ab?

– Wie tauschen die Roboter Daten untereinander aus (Excel ist keine Datenbank!)?

– Wo ist die Stelle, die uns hilft, die Fragen einer Revision oder Aufsicht oder Betriebsprüfung zu beantworten?

– Wie können wir das Vorgehen und Verhalten von Citizen Developern besser steuern?

Orchestrierung unterstützt uns auch dabei, einheitliche Regeln durchzusetzen. Angefangen bei simpel erscheinenden Dingen wie den Namen der Roboter-Lösungen bis hin zu einheitlichen Mustern für das Design von Robotern. Einheitlich entwickelte Lösungen sind gut für Qualitätssicherung und Wiederverwendung.

Eine spannende Frage ist auch, ob die Orchestrierung über ein BPM-Tool oder über die mit dem RPA-Werkzeug hoffentlich mitgelieferte Software die bessere Lösung ist. Hier muss sich jede Organisation selbst positionieren.

Aber RPA ohne Orchestrierung ist wie ein Schiff ohne Brücke oder ein Flugzeug ohne Cockpit.