Robotic Process Automation
Gemäss Google Trends steigt das Interesse an Robotic Process Automation (RPA) noch immer an, jedoch ist laut Gartner der Hype bereits vorüber. Zeit also, sich mit dem Thema in einer neutralen Art auseinanderzusetzen und anhand einiger Schlüsselreferenzen einen Themenüberblick zu liefern.
Basierend auf den aufgeführten Schlüsselreferenzen und unserer Erfahrung definieren wir zunächst den Begriff «RPA» und zeigen seine Beziehung zu artverwandten Konzepten auf. Dabei lösen wir auch häufig auftauchende Missverständnisse auf, wie z.B., dass RPA nur für das automatisierte Bedienen von grafischen Benutzerschnittstellen (GUI) steht. Anschließend beschreiben wir den Nutzen und typische Anwendungsbereiche dieser Technologie sowie deren Risiken. Der Artikel schließt mit einem Ausblick für Praxis und Forschung.
Geschichte, Definition und Abgrenzung
Die Ursprünge von RPA liegen in Technologien wie Scripting, Makros und insbesondere Screen-Scraping. Letzteres bedeutet, dass aus einer GUI unabhängig von bestehenden Schnittstellen automatisch Daten extrahiert werden können – eine Kernfunktionalität heutiger RPA-Lösungen. Doch RPA ist nicht einfach alter Wein in neuen Schläuchen – vielmehr bieten die aktuellen Tools mehr Flexibilität, Funktionalität und Anwendungskomfort.
Der Begriff «RPA» taucht nach unseren Recherchen etwa seit 2013 auf, während RPA-Produkte unter anderer Bezeichnung (z.B. «Presentation Integration») bereits seit 2010 existieren. In der Praxis wurde RPA 2015 erst vereinzelt eingesetzt, während Ende 2018 bereits die Mehrheit von 400 befragten (Groß-)Unternehmen RPA mindestens bereichsweise einsetzen.
Eine einheitliche Definition von RPA scheint es nicht zu geben, auch wenn es Aspekte gibt, die immer wieder genannt werden: insbesondere, dass einfache, repetitive, fehleranfällige Aufgaben, für welche Menschen häufig überqualifiziert sind, mittels einer Software ausgeführt werden. Die RPA-Tools übernehmen hier häufig die Aufgabe der Datenübertragung zwischen zwei Anwendungen, indem sie mit diesen über deren GUI interagieren und dabei einem vorgegebenen Workflow folgen. Die GUI-Interaktion ist sicher das aktuell prägendste Merkmal von RPA gegenüber anderen Integrationslösungen, ist aber nur eine Möglichkeit der Integration: So können etwa die drei marktführenden Produkte Automation Anywhere, Blue Prism und UiPath nebst GUI-Interaktion auch über APIs mit Desktop-Anwendungen wie Tabellenverarbeitung und Browser interagieren, sowie über REST und SOAP Web Services ansprechen. Um den RPA-Entwicklern diese Integrationsaufgaben zu erleichtern, stehen für zahlreiche APIs und Web Services in den herstellereigenen Marktplätzen fertige Bausteine zur Verfügung.
Oft hervorgehoben wird auch, dass die Roboter nicht «programmiert», sondern «trainiert» oder «konfiguriert» werden, und dies daher auch ohne Programmierkenntnisse gelinge: Das «Training» geschieht durch eine Kombination aus aufgezeichneten Benutzerinteraktionen mit Drag-and-Drop und Konfiguration vorgefertigter Bausteine zu einem flussdiagrammähnlichen Ablauf, wobei die Konfiguration speziell bei anspruchsvolleren Automatisierungen das Beherrschen von Scripting-Sprachen erfordert. Gerade letzteres lässt uns zweifeln, ob dies wirklich ganz ohne Programmierkenntnisse funktioniert. Auch Allweyer [1] relativiert diese Aussage, indem Business-Analysten und Fachexperten immerhin Schulungen und eine «ausführliche Einarbeitung» benötigen.
Bevor wir die Definition mit der Architektur typischer RPA-Systeme vervollständigen, wollen wir RPA zu artverwandten Begriffen abgrenzen: Entgegen seinem Namen geht es nicht um Prozesse als Ganzes, zumindest nicht um Ende-zu-Ende-Geschäftsprozesse, wie sie etwa in ERP-Systemen abgebildet werden. Auch ermöglicht RPA kein Straight-Through-Processing (STP) im eigentlichen Sinne, weil bei STP die Integration ausschliesslich über APIs, also nicht über GUIs vorgesehen ist. Zu solchen «traditionellen» Ansätzen zählen auch SOA oder Enterprise Application Integration (EAI). Darauf basierende Umsetzungen werden als Schwergewichts-IT bezeichnet – im Unterschied zur eher leichtgewichtigen RPA-Technologie. Nahe an das Konzept von RPA kommen Business-Process-Management-Systeme (BPMS). Dabei werden im Idealfall nach dem BPM-Ansatz Ende-zu-Ende-Prozesse zunächst analysiert, verbessert und erst dann automatisiert, im Unterschied zu RPA, wo lediglich Teile bestehender Prozesse automatisiert werden. Weitere zum Beispiel von Ivančić et al. [5] genannte Unterschiede zu BPMS scheinen uns gar nicht so eindeutig zu sein: BPMS sei nur von Software-Entwicklern zu meistern, RPA hingegen auch von Business-Anwendern; zum einen gibt es auch BPMS-Anbieter, die auf Low-Code setzen, und zum anderen ist auch bei RPA oftmals Scripting erforderlich. Auch greife RPA nur über GUIs auf die zu integrierenden Systeme zu im Unterschied zu BPMS, welches nur per APIs kommuniziere; richtiger wäre, dass BPMS für sich allein keine Möglichkeit vorsieht, Systeme mittels GUI-Interaktion zu integrieren, während RPA beide Möglichkeiten der Integration bietet.
Entsprechend wird die Kombination von BPMS und RPA von mehreren Autoren vorgeschlagen, damit auch Legacy-Anwendungen ohne verfügbare Schnittstellen wie REST oder SOAP direkt in ein BPMS integriert werden können. Doch nicht nur aus diesem Grund macht eine Kombination Sinn, sondern auch, weil sich aktuell BPMS für Ausführung und Monitoring von Ende-zu-Ende-Prozessen deutlich besser eignen als der alleinige Einsatz von RPA. Mehrfach vorgeschlagen wird nebst der Kombination auch der parallele Einsatz beider Technologien in einem Unternehmen, da die bei RPA geringeren Implementierungskosten auch Automatisierungen lohnenswert machen, die sich bei BPMS nicht lohnen würden.
Architektur
Abb. 1 zeigt eine stark vereinfachte Architektur von RPA-Lösungen, basierend auf Willcocks et al. [4] und IEEE Std 2755.1 [6], mit den folgenden Komponenten: In der Design-Komponente können RPA-Entwickler Abläufe aufzeichnen, anpassen, konfigurieren und testen. Diese können dann in einem zentralen Repository bereitgestellt werden.
Auf diese Repository greift auch die Management-Komponente zu: Mit dieser können sogenannte «Process Controller» manuell und automatisiert den Robots Aufträge erteilen. Es können zudem Robots, Ausführungen und weitere Systemressourcen verwaltet, überwacht und analysiert werden.
Die Robots-Komponente schliesslich, ist der Teil der Software, welcher den vorgegebenen Ablauf auf einem System ausführt und dabei mit den Applikationen interagiert. Dabei ist zu unterscheiden, in welcher Systemumgebung und in welchem Bezug zu einem Menschen ein Robot seine «Arbeit» verrichtet: Dieser kann z.B. auf einem Arbeitsplatzrechner installiert sein und von diesen wie ein «persönlicher Assistent» im sogenannten «Attended Mode» genutzt werden, also unter Aufsicht und mit den gleichen Benutzerrechten wie der angemeldete Benutzer. Der Robot, respektive eine Vielzahl von Robots können aber auch auf einer eigens dafür eingerichteten Umgebung auf virtuellen Maschinen laufen mit speziell für die Robots geschaffenen IT-Benutzern im «Unattended Mode». Letzteres erlaubt erst eine fast beliebige Skalierung und damit nicht bloss die Unterstützung von Menschen, sondern teilweise den Ersatz von Menschen, bedeutet aber auch, dass bei der IT-Abteilung eines Unternehmens neue Aufgaben hinzukommen.
Einsatzgebiete
Prozesse, die sich für eine Automatisierung mit RPA eignen, unterscheiden sich nur in einem wesentlichen Merkmal von solchen, die sich für eine BPMS-Automatisierung eignen: Sie umfassen bisher von Menschen durchgeführte Interaktionen mit mehreren, bisher nicht integrierten Anwendungssystemen. Abgesehen davon eignen sich – genau wie bei BPMS – stark strukturierte Prozesse mit wenig Varianz im Ablauf. Diese müssen auch bei RPA sehr oft ausgeführt werden, damit sich eine Automatisierung lohnt, wenn auch weniger oft als bei BPMS aufgrund der geringeren Automatisierungskosten.
Um für RPA geeignete Einsatzgebiete besser eingrenzen zu können, unterscheidet Czarnecki et al. [2] drei Typen menschlicher Aufgaben:
«1. Routineaufgaben, bei denen Daten aus unterschiedlichen Anwendungssystemen kopiert oder kombiniert werden;
2. Strukturierte Aufgaben mit regelbasierten Entscheidungen, bei denen Daten aus unterschiedlichen Anwendungssystemen genutzt und anhand eines Regelwerks bewertet werden;
3. Unstrukturierte Aufgaben und Entscheidungen, bei denen neben bestehenden Daten und Regeln ein Erfahrungswissen notwendig ist.»
Für die ersten zwei Typen sind zahlreiche Beispiele dokumentiert, während für den dritten Typ RPA-Produkte über mehr «Künstliche Intelligenz» verfügen müssen, worauf wir im Kapitel «Ausblick» zurückkommen.
Prozesse mit den genannten Merkmalen tauchen typischerweise im Back-Office auf und wurden von Großunternehmen bisher im Rahmen von Outsourcing-Initiativen vielfach ausgelagert. Mit RPA findet nun teilweise eine Rückverlagerung statt oder die Outsourcing-Anbieter nutzen ebenfalls RPA, um die Kosten weiter zu senken.
Nutzen
An erster Stelle steht die Effizienzsteigerung durch den verringerten Bedarf an menschlicher Arbeitskraft. Der eigentliche Nutzen entsteht dabei in der Kostenreduktion, falls hierdurch Personal abgebaut wird (Substitution von Mitarbeitenden) oder in höherer Mitarbeiterzufriedenheit, falls sich hierdurch Mitarbeiter spannenderen Tätigkeiten widmen können (Unterstützung von Mitarbeitenden), die allenfalls sogar mehr Wertschöpfung erzielen. Bezüglich Kostenreduktion wird geschätzt, dass ein Roboter nur rund ein Neuntel so viel kostet wie eine mitteleuropäische Arbeitskraft. Hinzu kommen mittelbare Einsparungen, zum Beispiel durch den Wegfall benötigter Büroflächen. Die höhere Mitarbeiterzufriedenheit ergibt sich, weil die automatisierten Tätigkeiten von den Mitarbeitenden «als langweilig und ermüdend empfunden werden» [1] und durch RPA gewissermassen der «Roboter» aus dem Menschen entfernt werde [4].
An zweiter Stelle steht die gleichbleibend hohe Qualität: Software-Roboter ermüden nicht und handeln stets gleich nach den vorgegebenen Regeln. Dadurch bleibt die Qualität auf einem konstant hohen Niveau und Compliance-Anforderungen werden besser eingehalten.
An dritter Stelle stehen die geringeren Durchlaufzeiten: Software-Roboter ersetzen nicht bloss die menschlichen Tätigkeiten, sie benötigen hierfür auch bedeutend weniger Zeit. Gemeinsam mit der gleichbleibend hohen Qualität führt dies zu einer höheren Zufriedenheit bei internen und externen Kunden.
Zusammenfassend wird also in kürzerer Zeit mit weniger Kosten eine höhere Qualität erreicht, oder nach Willcocks et al. [4]: «better, faster for less».
Ein weiterer Nutzen verdient noch Erwähnung: Aufgrund der von vielen Autoren genannten Möglichkeit, dass die Fachabteilungen Roboter selbst trainieren können, verringert sich die Abhängigkeit von der IT-Abteilung allgemein, respektive der Entwicklungsabteilung im Speziellen. Dies hat drei Vorteile: Es können dadurch Prozesse früher automatisiert werden, für welche die nicht selten überlastete IT-Abteilung noch keine Zeit hat. Es können auch Prozesse automatisiert werden mit geringerer Häufigkeit als bei der traditionellen Automatisierung, weil die Automatisierungskosten geringer sind. Und schliesslich entfällt ein Teil der sonst üblichen Kommunikationsprobleme zwischen der Fach- und Entwicklungsabteilung.
Risiken
Personalabbau ist die Kehrseite des größten Nutzens und verständlicherweise auch die am häufigsten genannte Angst: Waren gewisse Mitarbeiter bisher nur in repetitiven, informationsverarbeitenden Prozessen tätig, können sie durch RPA 1:1 ersetzt werden. Dies trifft insbesondere auf Mitarbeitende von Business Process Outsourcing-Unternehmen zu. Hinzu kommt, dass nicht alle Mitarbeitenden ausreichend qualifiziert sind, um anspruchsvollere Tätigkeiten auszuführen.
Umgekehrt bedürfen der Aufbau und Betrieb einer RPA-Infrastruktur auch mehr Ressourcen, jedoch ausgerechnet in der ohnehin schon ausgelasteten IT-Abteilung. Diese ist zudem oft skeptisch gegenüber einer RPA-Einführung, schließlich machen die zusätzlichen Systeme für RPA die bestehende IT-Infrastruktur noch komplexer. Hinzu kommt die berechtigte Angst vor einer Schatten-IT, gerade weil RPA – mindestens in der Anfangsphase – in den Fachabteilungen ohne Einbezug der IT eingeführt werden kann. Hieraus ergeben sich Risiken z.B. bei der IT-Sicherheit (z.B. Verwaltung von Authentifizierungsdaten), IT-Betrieb und der Einhaltung von Compliance-Anforderungen.
Ein weiteres Risiko wird auch in der potentiellen Verhinderung von echter Innovation gesehen, weil mit RPA lediglich bestehende Prozesse automatisiert werden, anstatt wie beim BPM-Ansatz üblich, zunächst bestehende Prozesse zu optimieren.
Ausblick
Die RPA-Produkte entwickeln sich aktuell vor allem im Themenbereich «Künstliche Intelligenz» weiter. In den Schlüsselreferenzen werden hierzu die Bereiche Cognitive Computing, Maschinelles Lernen, Process Mining und Natural Language Processing näher erläutert. Je nach RPA-Produkt, sind diese Funktionalitäten durch Eigenentwicklung oder Partnerschaften offenbar so weit gereift, dass verschiedene Autoren zunehmend den Begriff «Intelligent Process Automation» (IPA) verwenden [3]. Als wichtigste Auswirkung wird daraus abgeleitet, dass mit RPA- oder IPA-Software zunehmend auch komplexere und unstrukturiertere Prozesse automatisiert werden können, bei welchen in Ausnahmefällen die Software autonom entscheidet. Auch wird erwartet, dass RPA mit weiteren Technologien kombiniert wird, respektive mit solchen zusammenwächst. Dazu zählt insbesondere die erwähnte Kombination mit BPMS.
Für weitergehende Forschung schlagen die aufgeführten Schlüsselreferenzen thematisch die Kombination von BPMS und RPA sowie die direkten und indirekten Effekte von RPA auf die Performance einer Organisation mithilfe von etablierten Bewertungsmethoden vor. Darüber hinaus ist aus unserer Sicht relevant: Inwieweit trägt RPA in Mitteleuropa primär zum Personalabbau bei oder auch zur Lösung des Fachkräftemangels? Wie gering sind die Anforderungen an die Fähigkeiten von RPA-Entwicklern in den Fachabteilungen tatsächlich? In diesem Zusammenhang ist auch zu untersuchen, wie umfassend die herstellerspezifischen Marktplätze bereits dank vorgefertigten Bausteinen und Abläufen die Integration von betrieblicher Standardsoftware und Branchenlösungen unterstützen. Schliesslich scheint uns relevant, die Bedeutung von RPA für KMUs zu untersuchen, da sich die bisherige Forschung auf Grossunternehmen beschränkt.
Unternehmen, welche über eine Einführung von RPA nachdenken, sei empfohlen, diese strategisch anzugehen. Dabei soll frühzeitig ein abteilungsübergreifendes Team gebildet werden, wobei im Normalfall die Führung im Business liegt, aber die IT von Beginn an einbezogen ist. Nebst monetären Zielen sollten auch nicht-monetäre gewünschte und unerwünschte Wirkungen berücksichtigt werden.
Literatur
- Allweyer, T. (2016). Robotic Process Automation – Neue Perspektiven für die Prozessautomatisierung. Kaiserslautern. Abgerufen von www.kurze-prozesse.de/2016/11/10/paper-zum-download-jetzt-kommen-die-roboter-und-automatisieren-die-prozesse/
- Czarnecki, C., Bensberg, F., & Auth, G. (2019). Die Rolle von Softwarerobotern für die zukünftige Arbeitswelt. HMD Praxis der Wirtschaftsinformatik, 56(4), 795–808. doi.org/10.1365/s40702-019-00548-z
- IEEE Std. 2755-2017. (2017). IEEE Guide for Terms and Concepts in Intelligent Process Automation (Standard No. IEEE Std. 2755-2017). New York: IEEE Standards Association. Abgerufen von standards.ieee.org/standard/2755-2017.html
- Willcocks, L., Lacity, M., & Craig, A. (2015). The IT function and robotic process automation.
- Ivančić, L., Suša Vugec, D., & Bosilj Vukšić, V. (2019). Robotic Process Automation: Systematic Literature Review. In C. Di Ciccio, R. Gabryelczyk, L. García-Bañuelos, T. Hernaus, R. Hull, M. Indihar Štemberger, … M. Staples (Hrsg.), Business Process Management: Blockchain and Central and Eastern Europe Forum (S. 280–295). Springer International Publishing.
- IEEE Std 2755.1. (2019). IEEE Guide for Taxonomy for Intelligent Process Automation Product Features and Functionality (Standard No. IEEE Std 2755.1). New York: IEEE Standards Association. Abgerufen von
- https://ieeexplore.ieee.org/document/8764094
Autoren und Copyright
Björn Scheppler
ZHAW School of Management and Law, Winterthur
E-Mail
Christian Weber
ZHAW School of Management and Law, Winterthur
E-Mail
Online publiziert: 2. April 2020
© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2020