Robotic Process Automation (RPA) – ich glaub mich knutscht ein Elch

Wie Frankenstein mit Robotic Process Automation (RPA) am Leben gehalten wird, statt Modernisierung voran zu treiben.

Es gibt eine neue tolle Abkürzung die jeder kennen sollte – RPA. Das steht für ‚Robotic Process Automation‘ – irgendwas mit Robotern muss also gut sein.

Was verbirgt sich dahinter?

Einfache Antwort – ein Excel / Word Makro was über mehrere Applikationen hinweg funktioniert. Die fancy Definition ist “die vollautomatisierte Bearbeitung von strukturierten Geschäftsprozessen” – Makro halt.

Wie stell ich mir das vor?

Inspiriert (oder nachträglich ausgedacht) ist das Ganze wohl von den lustigen Industrierobotern die wir alle aus den Dokumentationen im Fernsehen kennen. Wenn Kollege Roboter – überlicherweise in Orange gekleidet – die Schweisspunkte bei einer Rohkarosserie im Autobau setzen kann und das dann auch noch präziser, ohne Gemaule und 24x7x365, dann sollte man das doch auch beim Wissensarbeiter über eine clevere Software lösen können. Toller Plan! Jeder der mal mit Software konfrontiert wurde die bei Großkonzernen (u.a. Banken) im Einsatz ist, erkennt, da ist vieeel Luft nach oben. Die Oberflächen grenzen zum Teil an Körperverletzung – von User Experience hat der Bankberater oder Sachbearbeiter in der Bank noch nie was gehört, er wäre froh wenn die Software die er tagtäglich ausgesetzt ist mal wenigstens halbwegs logisch aufgebaut wäre. Von Software Ergonomie (ja sowas gibt es und zwar schon seit den 70ern) haben die Entwickler dieser Lösungen, meist noch nichts mitbekommen. Da sitzt der arme Sachbearbeiter also in der Bank vor dieser Software und soll jetzt seinen Job machen. Wir als Menschen sind ja schon eine sehr schlau und pfiffige Spezies. Wenn der Sachbearbeiter also jetzt irgendwie einen Weg findet, vernünftiger und schneller seine Aufgaben zu lösen, dann wird er den finden. Das artet zum Teil in Keyboard Jiu-Jiutsu aus (einige Programme erlauben es, durch Tastaturkürzel schneller in die richtige Maske oder in das richtige Feld zu kommen) oder wenn man gar keine Lust mehr hat, dann sourced man ohne Wissen des Arbeitgebers einfach die komplette Arbeit an einen “digitalen Assistenten” in Indien aus. Dann darf der sich mit den Masken rumschlagen.

RPA – der Retter

Jetzt kommt also RPA, als weißer Ritter zur Lösung aller Probleme gebeutelter Bankberater und Sachbearbeiter vor stupider, repetitiver Arbeit. Die Idee dahinter ist, wenn ein Prozess so standardisiert ist, dass er in simplen Regeln beschrieben werden kann (Öffne Applikation 1, geh in Feld A in Maske 2 kopiere den Wert, dann öffne Applikation 2, gehe in Maske 322 in Feld FFF und füge den kopierten Wert ein, dann drücke auf speichern), dann kann man dazu in einer RPA Software einen “Robot” schreiben, der diesen “Prozess” dann ausführt. Dieser Robot kann das ganze dann in einem Affenzahn ausführen und wie oben präziser, ohne Gemaule, 24x7x365. Das Ganze kann man natürlich dann halt nicht nur für kleine Anwendungsfälle machen, sondern man kann natürlich auch “Robots” bauen, die andere “Robots” aufrufen und damit auch umfangreichere Prozesse automatisieren.

Echt jetzt? Elch-Knutsch

Reflektieren wir mal ganz kurz über das Konzept von RPA: RPA kommt nur bei standardisierten Prozessen zur Anwendung. RPA automatisiert mit Software einen standardisierten Prozess.

• Hmm – das klingt eigentlich wie die Anforderungsbeschreibung an ein Feature einer Software oder nach einer fehlenden Schnittstelle. Wird hier etwa ein fehlendes Feature statt in der Original-Software nun in RPA umgesetzt? Gab es einen Sinn warum das ein Mensch machen sollte? Wurde diese Anforderung einfach übersehen?

Gehen wir einen Schritt weiter. Das Resultat von RPA ist Software die mit Software interagiert um einen standardisierten Prozess umzusetzen, ggf. ein Prozess der bei der Erstellung der Original-Software nicht bedacht wurde oder noch nicht abzusehen war. Hmm – klingt auch wieder extrem vertraut. Ach ja, das ist die ureigenste Definition von API’s. Man schafft Schnittstellen zum System um dieses durch andere erweitern zu lassen. Also was genau macht RPA da eigentlich?

• Es erweitert über “Makros” legacy software, wo entweder Prozesse fehlen oder es schafft einen “API-Layer” über automatisierte Eingabe. Da regt man sich auf der einen Seite über screen-scraper auf und macht dann intern das Gleiche – oh jee.

Frankenstein’s Lebensverlängerung

Nun da wir RPA entlarvt haben, erkennt man auch langsam die Gefahr dieses Pflasters. So toll der Nutzen von RPA kurzfristig auch sein mag, zementiert RPA entweder eine miese Software mit fehlenden Features oder verlängert das Dasein dieser Frankenstein-Systeme. Es ist nachvollziehbar, dass Fachabteilungen sich probieren mit RPA selbst zu helfen. Die Umsetzungsgeschwindigkeit bei legacy Systemen ist sicherlich nicht die schnellste (plus, es wird meist teuer) und es suggeriert auch Schwächen im Anforderungsmanagement. Eine Maske zu optimieren wird gern mal runter priorisiert, wenn man auch noch den nächsten Mega-Prozess implementieren muss. Diese Denke ist fatal. Jedes Feature welches einem Sachbearbeiter eine Minute spart, ist wichtiger als jedes noch so tolle andere Feature, wenn diese Minute von hunderten Mitarbeiter dutzende Male am Tag eingespart werden kann. Mit RPA löst man nix, sondern man verlagert nur das Problem und sorgt somit für einen Flicken-Teppich von “Robots”. RPA skaliert nicht und ein auf “screen scraping” basierendes “Makro” ist kein Ersatz für echte Software. Das eigentlich Traurige ist jedoch, dass anstatt sich mit RPA’s zu beschäftigen, die Fachabteilungen lieber der IT und ihren Vorständen die Türen einrennen, statt endlich Schnittstellen zu ALLEN Bereichen der legacy Systeme zu erstellen. Diese abstruse Diskussion, welche API’s man denn zur Verfügung stellen sollte, ist komplett obsolet. Der Vorteil von API’s ist nunmal, dass darüber auch Anwendungen entstehen können, an die man heute und morgen noch nicht gedacht hat. Liebe IT / Rechenzentralen, wenn ihr die Schnittstellen nicht erstellt, werden sie per RPA-Wüsten gescriptet. Was ist Euch lieber – Software die per API mit Euren Systemen kommuniziert oder Script-Kiddie Prozesse, die auf screen scraping basieren?

Nachwort – Weckruf

Noch ein persönliches Statement – ich bin vor ca. 20 Jahren aus der Banken-Beratung in die Produkt-Erstellung gewechselt und interagiere mit meinem neuen Unternehmen wieder mehr mit Finanzinstituten. In jedem Meeting / Workshop welches ich mit Finanzdienstleistern habe, sitze ich irgendwann nur noch Kopf schüttelnd da. Die Probleme haben sich seit 2 Jahrzehnten nicht verändert, die Verzweiflung der Fachabteilungen ist kaum auszuhalten, leider aber auch die Hilflosigkeit der IT / Rechenzentralen und die Ignoranz der Vorstände. Nochmal 20 Jahre Stillstand überlebt diese Branche meines Erachtens nicht. Hört endlich auf Betriebsausflüge ins Silicon Valley zu machen, die Challenger Banken neidisch anzugucken und euch selbst zu bemitleiden weil die kein legacy haben und fangt endlich an. Ihr könnt nicht ewig 90% eurer Budgets in Maintenance verbrennen – bei uns, im Startup-Umfeld, nennt man das “kaputte Unit Economics” oder “fehlendes Business Modell”. Eine neue tolle App oder was da sonst als Digitalisierung gefeiert wird, sind Fassade und lenken nur davon ab sich nicht an die echten, schwierigen Probleme ranzutrauen.