Wer sich ernsthaft mit Softwaretest beschäftigt, muss sich auch mit dem Thema Testautomatisierung auseinandersetzen. Insbesondere durch die wesentlich kürzeren Releasezyklen und umfangreicheren Softwarelösungen ist klar: manueller Test ist nur in geringem Umfang möglich, während der Großteil automatisiert getestet werden muss. Wer die Testautomatisierungs-Pyramide vor Augen hat, kennt die übliche Verteilung der Interaktionsmöglichkeiten: die Basis bilden Testklassen im Unittest, einiges geht über Komponenten und API-Schnittstellen – und nur noch ein bisschen über die GUI.
Diese Empfehlung ist eine Erkenntnis aus den Jahren vor 2012, wo man wider besseres Wissen zu viel über die GUI automatisiert hat. Warum stelle ich das an den Beginn der Diskussion? Weil Robotic Process Automation (RPA) jetzt wieder genau darauf ansetzt: Automatisierung über die Standard User Interfaces, aka GUI. Ein Schritt zurück vor 2012 – oder doch eine Evolution, die kommt?
Wozu RPA?
Die Kunden erwarten sich heute – nicht nur in der Software Entwicklung – rasche Services und einen optimierten Ablauf (Customer Experience) durch das Unternehmen selbst. Das bedeutet, dass alles so rasch wie möglich ablaufen muss. Anbieter wie Amazon oder Zalando setzen auf Self-Service durch den Kunden und skalieren so das Personal für den Kundenservice. Abgesehen von den Abläufen im Lager und der Weiterleitung der Pakete an die Frachtführer müssen noch viele andere Prozesse 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 werden.
Tatsächlich stellen sich für die Non-IT die gleichen Herausforderungen, die wir schon seit 2001 für die IT im Zusammenhang mit Testautomatisierung diskutieren: zu langsame Time-to-Market, hohe Personalkosten, Fehleranfälligkeit insbesondere bei wiederkehrenden Tätigkeiten und zu geringe (Business) Process Automation.
Ein Beispiel aus der Praxis: In einem Projekt war die Anlage von Kreditkarten im System durch das verfügbare Personal nicht machbar. Wir haben einfach unsere Automatisierungs-Scripts für die Produktionsumgebung adaptiert und damit Nacht für Nacht tausende Karten automatisiert angelegt. Und das, ohne die Applikation anpassen zu müssen und ohne lange Antwortzeiten für die Endanwender untertags.
Was ist RPA?
RPA ist ein Interaktions-Layer zur Steuerung vorhandener Anwendungen. RPA-Funktionen bestehen im Regelfall aus Screen Capture und Record & Replay Mechanismen, aufgepeppt durch Zeichenerkennung, Textanalysen (Intelligent RPA, Cognitive RPA) sowie der Möglichkeit, Daten für die Verarbeitung aus anderen Quellen wie z.B. Excel einzubinden.
RPA ist keine Alternative zur Non-GUI Automatisierung, sondern lediglich eine potentielle Ergänzung zur Automatisierung über die API. Sie reagiert aufgrund des Zugangs über die Benutzeroberfläche empfindlicher auf Veränderungen als eine API-Integration.
Wie vermeidet man Shelfware?
Eine klare Erkenntnis beim Einsatz von Testautomatisierungs-Werkzeugen war: Viele haben es gekauft, begeistert ins Rennen geworfen – und mussten es aufgrund 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 On Investment) wieder auf den Boden der Realität zurückholen. Man darf nicht alles, was man automatisieren kann, automatisieren – es geht vor allem um die Hauptstraßen in der Wertschöpfung. Herstellungsaufwand und Wartbarkeit müssen passen. Sonst lieber Finger weg!
Die Ansätze bei RPA sind vergleichbar:
- Fokus darauf, wo der Arbeitsaufwand hineinläuft: automatisieren, was häufig verwendet wird
- Erweiterung der Integration: Schaffen von Schnittstellen zu Services, die bislang – weil sie im Unternehmen nicht nativ integriert waren – manuell abgefragt wurden. Gegebenenfalls wird man auch einfache Schnittstellen über spezialisierte Applikationen legen und damit direkte Maschine-zu-Maschine Kommunikation etablieren (daher ist kein manueller Eingriff mehr notwendig).
- Teilabdeckung: Oft sind die wahren Bottlenecks nicht gesamte Wertschöpfungsketten (komplexe Umsetzung), sondern nur Teile davon. Deshalb sollte der Fokus auf die relevanten Teilabschnitte gelegt werden.
- Vorarbeiten optimieren: Manche Prozesse sind arbeitsintensiv, weil die Eingangsdaten unstrukturiert und deren Bearbeitung unterschiedlich reguliert ist. Daher hilft die Realisierung von Bots, die unstrukturierte Daten überarbeiten und die Daten anhand vordefinierter Regeln analysieren.
Im Fokus könnten beispielhaft CRM-Applikationen stehen: Viele Aufgaben sind wiederkehrend, regelbasiert und umfangreich im Sinne einer hohen Anzahl. Ein echtes Potential!
Warum nicht alles in die Software integrieren – Prozessverbesserung und Automatisierung?
Meiner Meinung nach gibt es heute kein vernünftiges IT Projekt mehr, in dem Prozessoptimierung und -automatisierung keine Rolle spielen. Aber die IT-Abteilungen sind überlastet oder die Lösungen Cloud-basiert bzw. (Standard-)Produkte. Bei Letzteren sind die Anpassungsmöglichkeiten beschränkt bzw. die Anpassungen sehr teuer.
Wohin wir mit RPA wollen und müssen:
Fachabteilungen haben die Führungsrolle 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 (!) Automatisierungs-Scripts umgesetzt werden. Planen Sie mit ein, dass die Bots auch gewartet werden müssen. Hier ist die IT Abteilung wichtig, weil selbst bei Cloud-basierten Lösungen Änderungen immer durch die IT-Abteilung laufen und diese wesentlich für den Zeitplan der Umsetzung ist. Andererseits sollte die notwendige Anpassung von RPA-Bots jedoch durch den Fachbereich umgesetzt werden – dieser ist aus meiner Sicht in der Führungsrolle.
Gleichermaßen sollten Umsetzungen in diesem Bereich von der IT unterstützt werden (z.B. durch Konzeption, Architektur, Hilfe bei technisch komplizierten Umsetzungen). Folgende Punkte sollten jedoch durch den Fachbereich erledigt werden:
- Bedarfsanalyse, wo welche Strecken automatisiert werden sollen (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 der KPIs und Einrichten des fachlichen Monitoring
- Verwendung der RPA
In der IT-Abteilung bleiben zumeist das Deployment sowie die Realisierung des technischen Monitoring der RPA. Falls es notwendig ist, natürlich auch die 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 wegen der vermeintlich erhöhten Privilegien der RPA-Bots im Vergleich zu „Standard-Usern“. Darüber hinaus sollten weitere Bereiche, wie z.B. Human Resources 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 Key User 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 Verbesserungs-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 dafür 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 Data-Warehouse-Bereich evaluiert werden – damit steigert man das Selbstbewusstsein der Key User und macht sie zu mündigeren IT-Partnern in den eigenen Fachbereichen (Product Owner)
Die Reise geht in Richtung “gemeinsam statt einsam”. Das ist das wahre Next Big Thing im Software Engineering.
Alexander Weichselberger ist Managing Partner.
Er hat seine Einsatzschwerpunkte in den Bereichen Systemanalyse, Softwaretest, Koordination und Management von exponierten Großprojekten und kann auf jahrelange Erfahrung zurückblicken. Dieses Wissen gibt er gerne in Form von Coachings, Methodentrainings und Fachvorträgen weiter.