Software für Robotic Process Automation (RPA) im Aufwind

Ursprung und zunehmende Bedeutung von RPA

Die Aussicht auf Kosteneinsparungen hat Unternehmen aus einer ganzen Reihe von Branchen ermutigt, RPA-Software auszuprobieren und einzusetzen. Die Technologie selbst ist zwar noch jung – der Begriff Robotic Process Automation verbreitete sich erst 2012 – aber ihre Wurzeln gehen zurück auf die Großrechner-Ära des Screen Scrapping.

Screen Scrapping ist eine Methode zum Auslesen von Texten auf Computermonitoren. Sie wurde früher für Legacy-Anwendungen eingesetzt. Dabei wurden die dargestellten Daten auf Displays von Legacy-Anwendungen erfasst, um sie dann auf einer moderneren Benutzeroberfläche anzuzeigen.

Ein Software-Tool liest die Daten von Legacy-Anwendungen ein und formatiert sie um, so dass sie auf einem IBM 3270 – oder einem ähnlichen historischen Terminal – angezeigt werden. Anschließend transformiert das Werkzeug die Daten für die Verwendung auf einem modernen Client-Server oder webbasierten System. Dieser Ansatz bot eine kostengünstige und nicht-invasive Möglichkeit, ältere Systeme mit neueren zu verknüpfen: Man ersparte sich eine Neucodierung von Anwendungen oder teure Investitionen in eine hochleistungsfähige Systemintegration.

Das heutige RPA bietet ebenfalls einen dezenten Ansatz für die Integration von Systemen. Die RPA-Software emuliert die Schritte, die ein Mensch bei der Interaktion mit der Benutzeroberfläche einer Anwendung unternehmen würde, um beispielsweise Daten zu extrahieren.

Die Emulation ermöglicht es RPA, unterschiedliche Systeme in Situationen zu verknüpfen, in denen APIs fehlen oder in denen es keine Zeit oder kein Budget für den Aufbau einer benutzerdefinierten Integration gibt. Die Originalsysteme laufen unverändert weiter.

Moderne RPA gilt als Technologie, die weit über das Screen Scrapping hinaus geht. Sie kann heute viel komplexere Prozesse bewältigen, sich an Veränderungen in den zugrunde liegenden Systemen anpassen und über lokalisierte Implementierungen hinaus skalieren.

Die ersten Jahre der neuen Generation von RPA-Tools bestanden allerdings in erster Linie aus kleinen Implementierungen in einzelnen Abteilungen, die das Konzept des Softwareroboters testen sollten. Viele dieser Projekte wurden außerhalb der Zuständigkeit der IT-Abteilung und des CIOs durchgeführt. Diese Situation änderte sich jedoch, als Unternehmen begannen, RPA über die ursprünglichen Piloten hinaus zu skalieren.

Pat Geary, Chief Evangelist beim RPA-Softwareanbieter Blue Prism, erklärt, dass sich IT-Manager früher mit einem flüchtigen Blick auf RPA zufriedengegeben hätten – vorausgesetzt, es würde ihren Haupt-IT-Programmen nicht im Weg stehen. Mittlerweile ermutigt Geary, der den Begriff Robotic Process Automation geprägt hat, CIOs, sich RPA genauer anzusehen.

„Dies ist ein wichtiges Stück Technologie, und es muss gekauft und konsumiert und auf eine seriöse Art und Weise eingesetzt werden“, sagt er. „Die Zeit ist reif, dass CIOs einen Blick auf RPA werfen und es als permanenten Bestandteil einer operativen IT-Architektur verstehen.“

RPA-Software: verwandte Technologien und Anwendungen

Eine Vielzahl von RPA-Anbietern haben mittlerweile Produkte, mit denen Unternehmen Software-Bots erstellen und managen können. Blue Prism, Automation Anywhere und UiPath gelten als die Big Three der RPA-Anbieter. Auf der Gegenseite stehen die Challengers, die um Marktanteile kämpfen und spezielle Lösungen für die Technologie bieten, um Kunden zu gewinnen.

Im Wesentlichen konzentrieren sich die RPA-Produkte jedoch auf die Automatisierung repetitiver, hochvolumiger, regelbasierter Prozesse. Software-Bots funktionieren in der Regel am besten mit Prozessen, die eine geringe Variabilität aufweisen. Eine Aufgabe hingegen, die sich häufig ändert, ist schwer zu standardisieren und zu automatisieren.

Ken O'Brien, CIO bei R.R. Donnelley & Sons (RRD), einem in Chicago ansässigen Unternehmen für Marketing- und Geschäftskommunikation, sagt, wenn Menschen den Begriff Robotik hören, glauben sie, dass Robotik – und damit auch RPA – alle Probleme löst.

„Die Herausforderung bei RPA ist [...] zu einem gemeinsamen Verständnis zu kommen, was RPA ist und was es nicht ist“, sagt O'Brien. „Für mich ist RPA vor allem für etwas eng Begrenztes bestimmt – für repetitive Prozesse, die sehr gut definiert sind.“

Prozesse, die von Menschen verlangen, Entscheidungen zu treffen und Variablen zu berücksichtigen, sind „nicht unbedingt ideal für eine RPA-Implementierung“, erläutert O'Brien.

Bei RRD wird RPA zum Beispiel zur Automatisierung von Prozessen zur Dokumentenvorbereitung verwendet. Diese Prozesse beinhalten zahlreiche sich immer wiederholende Aufgaben zur Datenerfassung. Während sich diese RPA-Nutzung auf interne Prozesse beschränkt, beziehen sich andere RRD-Beispiele auf externen Kunden und Business Process Outsourcing. Für diese Fälle hat RRD Software-Bots eingesetzt, um die Bearbeitung von Versicherungsfällen und die Buchhaltung zu automatisieren.

Ron Schmelzer, Managing Partner bei Cognilytica, einem Marktforschungsunternehmen mit Schwerpunkt KI und Automatisierung, betont ebenfalls, dass Wiederholbarkeit bei RPA-Anwendungen wichtig ist. „RPA könnte man ebenso repetitive Prozessautomatisierung nennen“, sagt er.

Schmelzer betont, RPA sei in dem Sinne „robotisch“, dass es wiederholende Aufgaben löst. Er stellt aber fest, dass alle Softwareangebote dieselbe allgemeine Ausrichtung haben. Auch mache die Robotik allein die Automatisierung nicht intelligent, ergänzt Kathleen Walch, Managing Partner bei Cognilytica. Walch und Schmelzer glauben, dass RPA irrtümlicherweise mit KI in Konflikt geraten sei.

Gleichwohl ist Schmelzer der Ansicht, dass RPA als Integrationstechnologie und bei der Automatisierung repetitiver Aufgaben, die der Mensch sonst bewältigen müsste, einen erheblichen Mehrwert bietet.

Tatsächlich ist die Fähigkeit, die Anzahl der Vollzeitäquivalente (Full-Time Equivalents, FTE) zu reduzieren, möglicherweise das Hauptanliegen von RPA.  

Vollzeitäquivalent ist eine Kennzahl zur Mitarbeiterplanung. Ein Vollzeitäquivalent entspricht der Arbeitszeit eines Vollzeitangestellten. Zum Beispiel fanden Outsourcing-Anbieter, die durch die Verlagerung von Offshore- und Arbeitsarbitrage Kosten gesenkt hatten, heraus, dass sie die Ausgaben mit RPA-Technologie weiter senken konnten. Ein Softwareroboter ist einfach billiger als ein Offshore-Mitarbeiter.

RPA muss jedoch nicht dazu führen, dass Arbeitsplätze abgebaut werden. Bei RRD übernimmt jeder Software-Bot im Durchschnitt etwa die Hälfte der Arbeit, die ein Vollzeitäquivalent leistet. „Angestellte, die die repetitiven Aufgaben an die Bots abgegeben haben, konnten zu mehr Wissensarbeit übergehen“, sagt O'Brien.

Johnson ist überzeugt, dass die Mitarbeiter in den letzten Monaten RPA als eine Technologie sehen, die sie „für strategischere Aufgaben freisetzt“. Infolgedessen sei die Nachfrage nach RPA-Projekten bei Baker Hughes gestiegen.

Wer ist der Bot-Boss?

Die Einführung von RPA hat allerdings auch das Potenzial, im Unternehmen Spannungen zu produzieren. Die Interessen von Prozessverantwortlichen wie Fachbereichsleiter und IT-Manager stehen sich etwa bei RPA konträr gegenüber. Die Prozesse, die die RPA-Software automatisieren soll und die Effizienzsteigerungen, die zu realisieren sind, fallen typischerweise direkt in die Zuständigkeit der Fachbereiche.

Die Anwendungen und Datenspeicher, mit denen ein bestimmter Software-Bot interagieren muss, liegen jedoch in der Verantwortung der IT-Abteilung. Darüber hinaus haben Technologiemanager ein Sicherheitsinteresse bei RPA-Aktivitäten, da Software-Bots Anmeldeinformationen für den Zugriff auf verschiedene Unternehmenssysteme zugewiesen werden. Konflikte sind hier also immer ein Thema. Es gibt jedoch Anzeichen einer Versöhnung.

„Noch vor einem Jahr waren sich Unternehmen und CIO uneins“, sagt Marc Mancher, Direktor und Leiter des Federal Analytics Service bei Deloitte, der bundesstaatliche US-Behörden bei der Einführung von RPA berät. „Doch dieses Jahr gibt es eine Geschäfts- und IT-Partnerschaft.“

In einigen Unternehmen wird diese Partnerschaft innerhalb eines RPA Center of Excellence (CoE) vollzogen. Diese Zentren können als IT- oder Business Sponsoring firmieren, bestehen aber sowohl aus Geschäfts- als auch aus Technologievertretern. Das CoE definiert Rollen und Verantwortlichkeiten für die an RPA beteiligten Parteien und reduziert so das Konfliktpotenzial.

Die Aufgabe eines CoE ist es in der Regel, mögliche Kandidaten für eine Automatisierung zu bewerten und zu entscheiden, welche Bots zuerst gebaut werden. Entwickler innerhalb des CoE oder innerhalb einer kooperierenden IT-Organisation bauen dann die Softwareroboter. Nach Abschluss der RPA-Projekte sammelt das CoE die gewonnenen Erkenntnisse und teilt sie unternehmensweit.

Das Zentrum kann auch eine Bibliothek oder ein Repository von Bots integrieren, um die Wiederverwendbarkeit zu fördern und Redundanzen zu minimieren. Insgesamt generiert das CoE einen Governance-Rahmen, der unternehmensweite Standards setzt und die bereichsübergreifende Zusammenarbeit erleichtert.

Einige sagen, dass Deloitte 2019 CoEs für verschiedene Bundesbehörden aufgebaut hat und betonte die Wichtigkeit, eine RPA-Governance zu haben, bevor Software-Bots zu skalieren beginnen.

Sanjay Srivastava, Chief Digital Officer beim Dienstleister Genpact, äußert sich ebenfalls besorgt: „Wir raten unseren Kunden dringend, sich im Vorfeld Gedanken über die Governance zu machen.“

Baker Hughes folgte diesem Ansatz. Johnson sagt, dass das Unternehmen RPA-Tools evaluierte. Es wählte Automation Anywhere, Blue Prism und UiPath als Kandidaten aus und führte dann einen Proof of Concept durch. Als nächstes trat das Unternehmen einen Schritt zurück, um sich auf eine gute Governance zu konzentrieren – und sicherzustellen, dass sich die RPA-Technologie als skalierbar und nachhaltig erweist. Baker Hughes gründete ebenfalls ein CoE, um RPA Best Practices im gesamten Unternehmen auszutauschen.

„Es gibt so viel Nachfrage nach RPA, wenn wir nicht diesen Kern haben, den sie für die Zusammenarbeit nutzen können, würden wir am Ende eine Menge Schatten-RPA haben“, sagt Johnson. „Eine automatisierte Lösung ist wirklich nur so gut wie die Governance um sie herum.“

Balance zwischen Firma und individuellen Bedürfnissen

Beim Einsatz von RPA kann es auch in anderer Hinsicht Spannungen geben: Einerseits besteht der Wunsch des Unternehmens, RPA zu managen, während es skaliert. Andererseits haben Mitarbeiter ein wachsendes Interesse, lokale Bots einzusetzen, die ihnen die Arbeit leichter machen.

Die Bots der Enterprise-Klasse werden manchmal als unattended (unbeaufsichtigte) RPAs bezeichnet. Diese Bots konzentrieren sich typischerweise auf umfangreiche Geschäftsprozesse und sollen die Anzahl der Vollzeitäquivalente reduzieren, die eine bestimmte Aufgabe ausführen. Im Gegensatz dazu sind attended (beaufsichtige) Bots im Wesentlichen digitale Co-Mitarbeiter, die gemeinsam mit dem menschlichen Kollegen Finanzdaten abrufen, um ihm bei der Erstellung eines regelmäßig wiederkehrenden Berichts zu helfen.

Param Kahlon, Chief Product Officer bei UiPath, erklärt, dass sich attended Bots über die Bewältigung hochvolumiger und wenig variabler RPA-Szenarien hinaus entwickeln. „Sie werden nicht nur fünf oder zehn Prozesse automatisieren, sondern hunderte“, sagt er. „Viele von ihnen werden von Citizen Developern [normalen Endanwendern, Anm. der Red.] gebaut, anstatt von einem zentral verwalteten CoE.“

Kahlon geht davon aus, dass sich die CoEs weiterhin auf die Automatisierung von hochvolumigen Prozessen konzentrieren werden. Bots, die diese Prozesse automatisieren, werden vom CoE an die Benutzer weitergeleitet und unbeaufsichtigt ausgeführt. Endanwender hingegen werden sich auf attended RPAs konzentrieren und Prozesse automatisieren, die für sie von besonderer Bedeutung sind – und zwar jenseits der Bandbreite des CoEs. „Wir denken, dass wir in naher Zukunft beide Arten von Prozessen haben werden“, sagt Kahlon.

Deloitte-Berater Mancher sagt, dass sich in den nächsten fünf bis zehn Jahren zwei Klassen von Bots entwickeln werden: Enterprise-Bots, die stark kontrolliert werden, und Desktop-Bots, die die Arbeit eines Mitarbeiters schnell automatisieren.

Die Verbreitung von nicht kontrollierten Desktop-Bots beschäftigt auch Pat Geary von Blue Prism. Ohne Kontrolle wissen Unternehmen nicht, wo die Bots existieren, welche Prozesse sie verwenden und ob sie unerwartet ausgeführt oder gestoppt werden. „Stattdessen sollten RPA-Softwareanwender qualitativ hochwertige, prüfbare, belastbare Bots bauen, die statt technischem Firlefanz eher einen Geschäftsnutzen schaffen“, sagt er. Es gibt jedoch Raum für Kompromisse.

Ein zentralisierter CoE-Ansatz, so Geary weiter, könne die RPA-Entwicklung auf „akkreditierte Business-Anwender“ ausweiten. Sie können damit Automatisierungen „mit der Geschwindigkeit implementieren, die das Unternehmen benötigt“. Der „Connected-RPA“-Ansatz von Blue Prism zielt darauf ab, die Kreativität der Mitarbeiter zu fördern und gleichzeitig die Kontrolle zu behalten, so Geary. Der RPA-Lieferant bietet sowohl Kunden- als auch Partnerzertifizierung an.

Geary sagt auch, dass RPA für die Business Unit „demokratisiert“ werden kann. Allerdings müssen Geschäftsanwender die Regeln befolgen –- die Governance-Prinzipien, die durch das CoE festgeschrieben sind.

„Wir wollen nicht bis zur Anarchie demokratisieren“, sagt Geary. „Wir wollen uns in eine gut geführte Gesellschaft demokratisieren.“

Mancher sieht unterdessen eine Zukunft, in der das CoE regelt, wie Bots der Enterprise-Klasse erstellt werden sollen, während lokale Bots durch Kontrollen in Schach gehalten werden, die in autorisierte Tools für Desktop-RPA eingebettet sind.

Darüber hinaus werden Unternehmens- und Desktop-Bots künftig in der Lage sein, kooperativ zu arbeiten. Kahlon verweist auf die Entstehung einer hybriden Automatisierung, bei der ein attended Desktop-Bot einen unattended Enterprise-Bot aufrufen kann, um komplexere Geschäftsprozesse zu bewältigen.

Kahlon sieht auch Änderungen für das CoE. Zentren, die zunächst lediglich als RPA Gatekeeper auftreten und Regeln festlegen, wollen bald zu Organisationen werden, die die Einführung von RPA erleichtern, stellte er fest. Der anfängliche Fokus auf die Verwaltung und Kontrolle von Bot-Bereitstellungen wird schließlich dazu führen, dass Bot-Builder wiederverwendbare Komponenten einführen können.

Die Version 2.0 des CoE wird sich auch um eine Verbesserung der Berichterstattung auf Geschäftsebene bemühen. Laut Kahlon sollten RPA-Zentren nicht nur berichten, dass ein Bot hundertmal ausgeführt wurde. Vielmehr müssen sie auch seinen Nutzen betonen: „Was hat der Bot erreicht? Welche Geschäftsergebnisse hat er erzielt?“

Bedrohung oder Verheißung?

Die Einführung von Software-Bots am Arbeitsplatz können Mitarbeiter als bedrohlich empfinden. Dies gilt insbesondere für jene, die sich ohnehin schon Sorgen um den Verlust ihres Arbeitsplatzes machen. Ein Bericht über Automatisierung und Beschäftigung, der in den frühen Tagen von RPA veröffentlicht wurde, belegt diese Bedenken: Die Studie der Oxford Martin School (PDF) aus dem Jahr 2013 über die Auswirkungen der Computerisierung auf 702 Berufe ergab: „Etwa 47 Prozent aller Beschäftigten in den USA sind gefährdet.“

Neuere Studien zeigen jedoch ein differenzierteres Bild. Ein Bericht des McKinsey Global Institute (PDF) aus dem Jahr 2017 ergab, dass 60 Prozent der Berufe Aktivitäten aufweisen, die automatisiert werden könnten. Hingegen sind höchstens fünf Prozent der Berufe gefährdet, ganz zu verschwinden.

Allerdings sind Unternehmen, die RPA-Softwareimplementierungen planen, gut beraten, sich mit den Erwartungen der Mitarbeiter vor Beginn der Roboterimplementierung zu beschäftigen und zu steuern. O'Brien von RRD sagt, dass RPA nicht so sehr ein Technologiewechsel ist, sondern ein kultureller Wandel.

„Ich denke, das Beste, was wir getan haben, war, das Unternehmen auf die Veränderung vorzubereiten“, sagt O'Brien. „Wir haben gut sechs Monate damit verbracht, Erwartungen zu formulieren, bevor wir zugelassen haben, dass das erste Stück Code geschrieben wird.“

Um diese RPA-Erwartungen zu erfüllen, setzte RRD eine Mischung aus Maßnahmen zur Öffentlichkeitsarbeit ein, darunter Artikel und Websites.

Bei Baker Hughes ist die Situation ähnlich. Laut Johnson nimmt die RPA-Akzeptanz dann an Fahrt auf, wenn die Mitarbeiter sich damit wohl fühlen. Sie sagt, dass die Vorbereitung der Mitarbeiter auf die Veränderungen sehr geholfen habe. Aber sie lobt auch ausdrücklich die Mitarbeiter, die sich selbst über den Nutzen von Softwarerobotern informierten.

„Ich würde gerne sagen, dass die Akzeptanz das Ergebnis davon ist, wie wir die Idee der Automatisierung gestaltet haben. Aber das stimmt leider nicht“, erläutert Johnson. „Die Branche bewegt sich so schnell und positioniert RPA als praktikable Lösung. Die Menschen forschen und probieren Dinge selbstständig aus, so dass sie RPA mehr oder weniger akzeptieren. Wir sehen also nicht so viel Widerstand.“

Die RPA-Roadmap

Für Unternehmen, die RPA einführen, kann Change-Management zu einer ständigen Aufgabe werden. Die Technologie entwickelt sich weiter – was bedeutet, dass sich auch die RPA-Erfahrungen der Mitarbeiter weiterentwickeln.

Eine Richtung, die RPA einschlagen könnte, ist der Bot als digitale Person – im Gegensatz zum Aufgabenautomat. Anfang des Jahres lancierte Automation Anywhere einen Digital Workers Marketplace, von dem aus Benutzer digitale Kreditorenbuchhalter und andere Personal-Bots herunterladen können.

Max Mancini, Executive Vice President des Digital-Workers-Ökosystems bei Automation Anywhere, nennt die Digital Workers „menschenzentriert“. Das ist insofern bemerkenswert als herkömmliche Software-Bots durchgehend als aufgaben- oder prozessorientiert definiert werden. Er sagt, dass das Digital-Workers-Modell die RPA-Kategorie erweitert und kognitive und analytische Fähigkeiten zu den Fähigkeiten eines Bots hinzufügt, wiederholende Aufgaben auszuführen.

Diese zusätzlichen Skills lassen Digital Workers Muster erkennen und automatische Anpassungen vornehmen, sagt Mancini. So kann zum Beispiel ein digitaler Kreditorenbuchhalter Unterschiede in den Rechnungsformaten erkennen, so dass Unternehmen nicht jedes Mal, wenn ein neuer Lieferant ein neuartiges Rechnungsformat einführt, Bots umstellen müssen.

„Wir glauben, dass Digital Workers der nächste Schritt in der Entwicklung intelligenter digitaler Arbeitskräfte sind“, ist Mancini überzeugt.

Schmelzer von Cognilytica äußert sich jedoch skeptisch gegenüber den intelligenten RPA-Visionen der Anbieter. Er sagt, dass ein Bot, um vollständig intelligent zu sein, automatisch und autonom den Prozess lernen muss, den er ausführt. Er muss außerdem bestimmen, welche Schritte notwendig und unnötig sind und er muss eine bessere Möglichkeit finden, den Prozessablauf zu steuern.

Das Ziel, so Schmelzer, sei der autonome Geschäftsprozess. Er betont, dass bislang noch kein Anbieter dieses Niveau der kognitiven intelligenten Prozessautomatisierung erreicht hat. Gleichzeitig räumte er aber durchaus ein, dass sich Anbieter, von Start-ups bis hin zu etablierten Anbietern, in Richtung höherer Intelligenz bewegen.

Die Prozesserkennung ist ein weiterer Schritt auf dem Weg zur Intelligenz. Kryon Systems, ein RPA-Softwarehersteller, hat im vergangenen Sommer ein solches Angebot auf den Markt gebracht. Kryon Process Discovery setzt Discovery Bots auf den Computern der Kunden ein, um festzustellen, wie Mitarbeiter mit Anwendungen interagieren. Diese Daten werden an die Analyse-Engine von Kryon weitergeleitet, die vorschlägt, welche Prozesse die besten Kandidaten für die Automatisierung sind. Das Process Discovery Tool erstellt auch Workflows, die zur Erstellung automatisierter Prozesse in Kryon Studio exportiert werden können.

Richard French, Chief Revenue Officer bei Kryon, sagt, dass das Process Discovery Tool des Unternehmens bis zu 60 Prozent eines bestimmten Prozesses automatisieren kann. Und das gilt, bevor der Auftrag an Kryon Studio geht, das die Prozessaufbau-Aufgabe fortsetzt.

Der Prozessmanagementanbieter Kofax hat ebenfalls ein Angebot zur Prozessanalyse eingeführt. Die Funktion Automated Process Discovery wurde als Teil der Version 10.4 von Kofax Robotic Process Automation eingeführt. Das Tool lädt Agenten auf die Desktops oder Laptops der Benutzer und zeichnet die Interaktionen zwischen Mensch und Anwendung auf. Es verarbeitet die Daten und ruft die Analyse für einen Roboterdesigner oder Abteilungsleiter ab, merkt Bryant Bell, Senior Director of Product Marketing bei Kofax, an.

French geht davon aus, dass sich dieser Zweig der RPA-Technologie so weit entwickeln wird, dass Bots spontan wiederkehrende Aufgaben automatisch bearbeiten. In diesem Szenario beobachtet ein Bot die Arbeitsaktivitäten eines Mitarbeiters, identifiziert repetitive Aufgaben und bietet an, einen automatisierten Prozess zu entwickeln.

French sagt, dass die Realisierung vielleicht noch 18 Monate bis zwei Jahre dauern dürfte. Zukünftige Bots würden „den RPA-Mechanismus On the Fly erstellen und diesen auf Sie persönlich zuschneiden. Das ist die Richtung, in die es gehen wird.“