Robotic Process Automation

Wer sich ernsthaft mit Softwaretest auseinandersetzt, muss sich auch mit den Thema Testautomation auseinandersetzen. Insbesondere durch die fundamentalen kürzeren Releasezyklen und den heute umfangreicheren Softwarelösungen ist klar: Manuell geht nur im geringen Umfang, die Hauptlast muss automatisiert getestet werden. Und wer die Testautomationspyramide vor Augen hat, kennt auch die übliche Verteilung der Interaktionsmöglichkeiten: Testklassen im Code Unit, viel via Component und API-Schnittstellen - und nur noch ein bisschen GUI.

Diese Empfehlung ist ein klares Learning aus den Jahren vor 2012, wo man wider besseren Wissens zu viel über die GUI automatisiert hat. Warum stelle ich das in das Vorfeld der Diskussion? Weil Robotic Process Automation (RPA) jetzt wieder genau darauf ansetzt: Automation über die Standard User Interfaces, aka GUI. Ein Schritt zurück vor 2012 - oder doch eine Evolution, die kommt?

Wozu RPA?

Nicht nur in der Software Entwicklung - auch die (End) Kunden von Unternehmen erwarten sich heute rasche Services und einer optimierten Ablauf (Customer Experience) durch das Unternehmen selbst. Dh. alles muss so rasch wie möglich ablaufen. Anbieter wie Amazon oder Zalando setzen auf Self-Service durch den Kunden und skalieren so die Workforce für den Inbound. Abgesehen vom tatsächlichen Picking- und Packing im Lager und Weiterleitung der Pakete an die Frachtführer müssen noch viele andere Prozesse durch Mitarbeiterinnen und Mitarbeiter dazu im Hintergrund erledigt werden: Produktentwicklung, Einkauf und Beschaffung, Marketing, Kundenservice, Finance... auch hier müssen die Durchlaufzeiten optimiert werden, damit der Eigenaufwand für das Unternehmen optimiert und die Kosten für den Kunden so gering wie möglich sind.

Tatsächlich stellen sich für die Non-IT die gleichen Herausforderungen, die wir auch schon seit 2001 für die IT im Zusammenhang mit Testautomation diskutieren: Rasche Time-to-Market, hohe Personalkosten, Fehleranfälligkeit insbesondere bei wiederkehrenden Tätigkeiten und zu geringe (Business) Process Automation.

Aus der Praxis: In einem Projekt war die Anlage von Kreditkarten im System durch das verfügbare Personal nicht machbar. Wir haben einfach unsere Automationsscripts für das Produktionsenvironment adaptiert und damit Nacht für Nacht tausende Karten automatisiert angelegt. Ohne die Applikation anpassen zu müssen - in Zeiten, wo durch diese Massenanlage lange Antwortzeiten für die Endanwender unter Tag vermieden werden konnten.

Was ist RPA?

RPA ist ein Interaktions-Layer zur Steuerung vorhandener Anwendungen. RPA-Funktionen bestehen im Regelfall aus Screen Capture und record-and-replay Mechanismen, aufgepeppt durch Zeichenerkennung, Textanalysen (Intelligent RPA, Cognitive RPA) sowie der Möglichkeit Daten für die Verarbeitung aus anderen Quellen, z.B. Excel oder anfordernden Anwendungen, einzubinden.

RPA ist keine Alternative zur non GUI Automation - sondern lediglich eine potentielle Ergänzung zu API. RPA ist - aufgrund des Zugangs durch die Oberfläche - empfindlicher auf Veränderungen wie eine API-Integration.

Wie vermeidet man Shelfware?

Eine klare Erkenntnis beim Einsatz von Testautomationstools war: Viele haben es gekauft, begeistert ins Rennen geworfen... - und mussten es auf Basis der schlechten Ergebnisse wieder zurück ins Regal stellen. Wir hatten in der Vergangenheit viele Projekte deren Ziel ein „back to automation“ war: Sinnvoller Einsatz - fokussiert auf den Nutzen. Nicht selten mussten wir in Projekten den Kunden durch Hinweise auf den ROI (Return Of Investment) wieder auf den Boden der Realität zurückholen: Man darf nicht alles, was man automatisieren kann, automatisieren - es geht um die Haupt-Hauptstraßen in der Wertschöpfung. Herstellungsaufwand und Wartbarkeit müssen passen. Sonst lieber Finger weg!

Die Ansätze bei RPA sind - wiederum - vergleichbar:

• Fokus darauf, wo Manpower hineinläuft: Automatisieren was oft- und oft verwendet wird
• Erweiterung der Integration: Schaffen von Interfaces to Services, die bislang - weil sie im Unternehmen nicht nativ integriert sind - manuell abgefragt wurden; ggf. wird man auch einfache Interfaces über spezialisierte Applikationen legen und damit direkte Maschine-zu-Maschine Kommunikation etablieren (-> kein manueller Eingriff mehr notwendig)
• Teilabdeckung: Oft sind die wahren Bottlenecks nicht gesamte Wertschöpfungsketten (komplexe Umsetzung), sondern nur Teile davon; deshalb: Fokus auf die relevanten Teilabschnitte
• Vorarbeiten optimieren: Manche Prozesse sind arbeitsintensiv, weil die Eingangsdaten unstrukturiert und deren Bearbeitung unterschiedlich reguliert ist; daher: Realisierung von Bots, die unstrukturierte Daten überarbeiten und die Daten anhand vordefinierter Regeln analysieren

Fokus könnten beispielhaft CRM Applikationen sein: Viele Aufgaben sind wiederkehrend, regelbasiert und umfangreich i.S. einer hohen Anzahl. Ein echtes Potential!

Warum nicht alles in die Software integrieren - process improvement und Automation dorthin, wo es hingehört?

Meiner Meinung nach gibt es heute kein vernünftiges IT Projekt mehr, wo Prozessoptimierung und -automation keine Rolle spielt. Aber die IT Abteilungen sind überlastet oder die Lösungen sind cloudbasiert bzw. (Standard-)Produkte. Letztere sind daher mit nur einem reduzierten Umfang an Anpassungsmöglichkeiten durch/für das eigene Haus veränderbar (bzw. sind Anpassungen sehr teuer).

Wo wir mit RPA hinwollen und hinmüssen sind:

Fachabteilungen haben den Lead bei der RPA

Für die Umsetzung und Realisierung von IT Lösungen ist es üblich, dass die IT Abteilung federführend ist und bleibt.

Dieses Prinzip sollte für RPA aufgeweicht werden: RPA ist eine Geschäftsinitiative. Änderungen sollten auch unter Berücksichtigung bestehender produktiver ( ! ) Automationsscripts umgesetzt werden. Planen Sie mit ein, ggf. Wartung bei den bots zu machen ist. Hier ist die IT Abteilung wichtig, weil - selbst bei cloudbasierten Lösungen - Änderungen immer durch die IT Abteilung laufen und sie insbesondere das Timing der Umsetzung führt. Andererseits sollte die notwendige Anpassung von RPA bots jedoch durch den Fachbereich umgesetzt werden - sie sind aus meiner Sicht im Lead.

Gleichermaßen sollten Umsetzungen in diesem Bereich von der IT unterstützt werden (z.B. durch Konzeption, Architektur, Hilfe bei technisch komplizierten Umsetzungen), aber folgende Punkte sollten durch den Fachbereich gemacht werden:

• Bedarfsanalyse, wo welche Strecken automatisiert werden sollten (Fragestellung: WAS ist zu tun?)
• Detailanalyse, was konkret - Schritt für Schritt - automatisiert werden soll (Fragestellung: WIE ist es zu tun? - eine übliche Domäne der IT Abteilung)
• Umsetzung, Test und Dokumentation der RPA, dabei auch Festlegung KPIs und Einrichten des fachlichen Monitoring
• Verwendung der RPA

In der IT Abteilung bleiben zumeist - wenn notwendig - das Deployment, sowie die Realisierung des technischen Monitoring der RPA. Ggf. - falls dies notwendig ist - natürlich auch technische Hilfe für die Realisierung komplizierter Automation Keywords.

Aber Achtung: Ein Schlüsselfaktor muss jedenfalls bei der IT Abteilung bleiben, die letztlich für den Betrieb der Lösung verantwortlich ist: Die Spielregeln für RPA müssen von der IT kommen - insbesondere auch wg. der vermeintlich erhöhten Privilegien der RPA bots im Vergleich zu „Standard-User“. Darüber hinaus sollten weitere Bereiche, wie z.B. Human Ressource und ggf. auch der Betriebsrat, bei der Abstimmung der Spielregeln berücksichtigt werden.

Warum ist RPA ein next „big thing“ im Software Engineering?

Die Vorteile von RPA liegen in der schnellen Implementierung von Prozessautomatisierung. Mehr und mehr „Entwicklungsleistungen“ werden dabei von der IT Abteilung in Richtung Fachbereich gehen. Die IT Abteilungen sind aufgerufen, diesen Weg zu begleiten, um damit mündigere Keyuser in den Abteilungen zu etablieren. Mit dem wesentlichen Vorteil, dass RPA ein Serviceangebot aus der IT Abteilung ist - im Gegensatz zu produktiven Lösungen, die durch die Fachabteilungen realisiert wurden und ohne Kenntnis durch die IT betrieben werden.

RPA - richtig realisiert - ist ein kontinuierlicher Improvement-Prozess. Dabei...

• ... sollte es keinesfalls für komplexe Aufgabenstellungen herangezogen werden
• ... muss eine Agile Umsetzung (schneller Nutzen durch umgesetzte Prozesse) gewählt werden
• ... darf das RPA Engagement kein Argument sein, dass eine Anwendungsmodernisierung verzögert wird und damit die Lebensdauer von Legacy-Anwendungen unnötig verlängert wird
• ... sollten weitere Self-Service Optionen z.B. im DWH Bereich evaluiert werden - damit steigert man Selbstbewusstsein der Keyuser erneut und führt zu mündigeren IT Partnern in den eigenen Fachbereichen (Product Owner)