18. April 2023

Risiken in der Nutzung von Robotic Process Automation und Best Practices für die Prüfung

Bisherige Forschung zu Robotic Process Automation (RPA) und Publikationen von RPA-Anbietern und Beratungsfirmen konzentrieren sich weitgehend auf die Vorteile der Technologie für Unternehmen und Mitarbeiter. Dass bei der Nutzung von RPA jedoch verschiedene Risiken bestehen, zeigt der Forschungsartikel The Dark Side of Robotic Process Automation (Eulerich, Waddoups, Wagener und Wood 2022),¹ an dem sich der vorliegende Fachbeitrag orientiert. Die Autoren identifizieren fünf Kernprobleme im Zusammenhang mit RPA, die es zu beachten gilt. Der Beitrag gibt ebenfalls einen Ausblick auf Best Practices für Prüfung von RPA, die mit Hilfe eines Kontrollsets durchgeführt werden kann.

1. Einleitung und Begriffsbestimmung

Robotic Process Automation (RPA), auch Software-Roboter oder Bots genannt, beschreiben den Einsatz von Computerprogrammen zur Automatisierung strukturierter, regelbasierter und sich wiederholender Geschäftsprozesse (beispielsweise Cooper, Holderness, Sorensen und Wood 2019, 2020; Eulerich, Pawlowski, Waddoups und Wood 2021). Die Eigenschaften von RPA lassen sich wie folgt zusammenfassen:

Bei RPA handelt es sich um eine Software-Lösung, die an den Benutzerschnittstellen bestehender IT-Systeme und Anwendungen arbeitet.
Der Bot imitiert menschliche Handlungen anhand vordefinierter Abfolgen von Aktivitäten wie bspw. Mausbewegungen oder -klicks, Tastatureingaben oder Ablesen vom Computerbildschirm.
Der Bot liest und verarbeitet Daten in strukturierter Form.
RPA ist im Unternehmen einfach zu implementieren, da keine Integration in eine bestehende IT-Architektur erforderlich ist (minimalinvasive Technologie).
Die Programmierung erfolgt in der Regel über Drag-and-Drop auf einer ‚Low-Code/No-Code‘ Basis und erfordert keine tiefergehenden Programmierkenntnisse.
Sich wiederholende, regelbasierte, strukturierte und stabile Prozesse (mit hohem Datenvolumen) sind für RPA am besten geeignet.
Bei RPA handelt es sich nicht um eine „intelligente“ Automatisierung wie bspw. bei der Intelligent/Cognitive Automation.

Bei intensiverer Beschäftigung mit RPA sollte zudem zwischen Attended und Unattended Automation unterschieden werden. Bei der Attended Automation werden die automatisierten Prozesse beaufsichtigt (engl. attended) auf einem lokalen Rechner ausgeführt und durch den einzelnen Benutzer gestartet. In der Regel werden die Zugriffsrechte und -daten genutzt, die der Benutzer des Bots hat. Attended Bots eigenen sich besonders bei der Automatisierung von kleinen und sich wiederholenden Aufgaben, wobei der Prozess nicht vollständig automatisiert wird.

Bei der Unattended Automation werden die automatisierten Prozesse unbeaufsichtigt (engl. unattended) auf einem lokalen Rechner ausgeführt. Es handelt sich dabei um alleinstehende Bots, die Arbeitsabläufe und Arbeiten ohne menschliches Eingreifen automatisieren. Sie können je nach Geschäftsanforderung zu jeder Zeit gestartet und gestoppt werden.

Ein Orchestrator ist cloudbasiert, kann viele Bots zentralisieren und die Laufzeiten der Bots optimieren. Diese Orchestrierung eignet sich für End-to-End-Prozesse ohne Interventionen durch menschliche Mitarbeiter.

Viele praxisorientierte Berichte, White Paper und akademische Studien dokumentieren die Vorteile von RPA (unter anderem Asatiani und Penttinen 2016; Lacity und Willcocks 2016, 2017; Hallikainen, Bekkhus, und Pan 2018; Kokina und Blanchette 2019; Christ, Eulerich, Krane, und Wood 2021; Harrast und Wood 2022). Diese Studien zeigen beispielsweise, dass RPA die betriebliche Effizienz verbessert, die Genauigkeit und Nachvollziehbarkeit erhöht und dass RPA Menschen von einfachen und nicht wertschöpfenden Aufgaben entlastet, was letztlich zu einer höheren Arbeitszufriedenheit führt. Über die potenziell negativen Folgen des RPA-Einsatzes ist jedoch weitaus weniger bekannt. Vor diesem Hintergrund widmet sich die Studie von Eulerich, Waddoups, Wagener und Wood (2022) den Herausforderungen und Risiken im Zusammenhang mit RPA.

2. Risiken und Herausforderungen in der Nutzung von Robotic Process Automation

Ein Zitat des Revisionsleiters eines Fortune 500 Unternehmens zeigt eindrucksvoll einige der Herausforderungen mit RPA auf: Es hilft einem Unternehmen zwar kurzfristig, ist aber langfristig keine Lösung zur Behebung der tieferliegenden, strukturellen Probleme.

RPA is almost like a drug. It relieves the pain, it helps a lot, it cures to a
certain extent, but it does not address the underlying root cause of the problem.

Im Folgenden werden fünf wichtige Risiken und Herausforderungen von RPA näher erläutert. Viele der identifizierten Probleme sind auf die Tatsache zurückzuführen, dass RPA einfach zu bedienen, kostengünstig und minimalinvasiv ist. Aus diesem Grund scheinen die Stärken, die zu einer weit verbreiteten Anwendung von RPA geführt haben, für einige der größten Herausforderungen verantwortlich zu sein.

1. RPA wird oft als schnelle Pflasterlösung eingesetzt, anstatt die Kernprobleme des Systems zu beheben.

Die Benutzerfreundlichkeit von RPA kann Mitarbeiter ungewollt dazu veranlassen, weniger über die tatsächliche Behebung schlecht funktionierender Geschäftsprozesse nachzudenken, sondern vielmehr darüber, wie RPA eingesetzt werden kann, um die Potenziale der Technologie auszuschöpfen. Dabei wird unter Umständen ein bestehender aber nicht optimaler Prozess zusammengehalten. Dies führt letztlich dazu, dass RPA wie ein Pflaster wirkt, das die Prozessverbesserung innerhalb einer Organisation verlangsamen kann.

Dazu kommt, dass Unternehmen oft viele verschiedene Technologien einsetzen, die nicht miteinander kompatibel sind. Folglich können Daten nicht ohne menschliche Hilfe zwischen den verschiedenen Systemen übertragen werden. Da Bots menschliche Verhaltensweisen imitieren, bieten sie eine verlockende und kurzfristige Lösung für diese Datenflussprobleme, wobei eine vollständige systemweite Integration langfristig vielleicht die sinnvollere Lösung wäre. Dafür müssten jedoch Prozesse umgestaltet und Technologien konsolidiert werden. Diese Prozessumgestaltung kann durch Bots verzögert werden.

In diesem Zusammenhang ist eine weitere negative Folge von RPA, dass sie eine zusätzliche Technologie ist und auf die bestehende IT-Architektur aufgesetzt wird (anstatt sie zu ersetzen). Dies führt zu einer erhöhten Komplexität und Aufblähung der technologischen Infrastruktur.

2. RPA kann ernsthafte Kontroll- und Sicherheitsprobleme verursachen.

RPA ist ein weiteres IT-Element und kann ernsthafte Kontroll- und Sicherheitsprobleme verursachen. Die folgende Abbildung fasst diese potenziellen Probleme zusammen und der nachfolgende Abschnitt beschreibt diese konkreter.

Da RPA-Software leicht heruntergeladen und Bots ohne tiefergehende Programmierkenntnisse erstellt werden können, können diese leicht außer Kontrolle geraten. Das Konzept der „Citizen Developer“ erfreut sich in vielen Unternehmen zunehmend größerer Beliebtheit. Dabei entwickeln End-User RPA-Automatisierungen selbstständig für ihre Zwecke ohne die Unterstützung durch eine IT-Abteilung oder ein RPA-Expertenteam. Vor diesem Hintergrund spricht ein Interview-Teilnehmer treffend von einem Vergleich mit einer Lawine, die immer größer wird, wenn sie einmal ins Rollen gekommen ist.

Ein darauf aufbauendes Kontrollproblem besteht darin, dass Unternehmen nach einer gewissen Zeit nicht mehr in der Lage sind, RPA-Aktivitäten innerhalb des Unternehmens zu verfolgen. Es kann zu „dunklen Flecken“ im Unternehmen kommen, wenn Bots nicht bei der IT-Abteilung oder einem RPA-Expertenteam registriert sind. Besonders problematisch ist vor diesem Hintergrund, wenn Bots Aufgaben der Finanzbuchhaltung oder -berichterstattung übernehmen. Die Notwendigkeit für ein solches Bot-Register lässt sich unter anderem dadurch begründen, dass Wirtschaftsprüfer – und ggf. auch die Interne Revision – für ihre Prüfungen eine Übersicht über die Grundgesamtheit aller Bots benötigen, um daraus eine angemessene Stichprobe ziehen zu können. Bei Fehlen einer solchen Grundgesamtheit kann der RPA-Ansatz nicht angemessen geprüft werden.

Durch die einfache Handhabung kann es ebenfalls dazu kommen, dass Mitarbeiter Bots implementieren, ohne dabei alle Sicherheitsrichtlinien und -protokolle des Unternehmens zu befolgen. Ebenfalls können Mitarbeiter das mit RPA-Bots assoziierte IT-Risiko falsch einschätzen (oder erst gar nicht einschätzen). Wenn ein Bot beispielsweise Aufgaben im Zusammenhang mit der Finanzberichterstattung ausführt, sind zusätzliche Sicherheitsmaßnahmen und Kontrollen erforderlich. Ähnlich verhält es sich bei kritischen Geschäftsprozessen, die unter Umständen ebenfalls zusätzliche Kontrollen erfordern. Weil Bots so schnell und einfach zu implementieren sind, wird die Assurance-Perspektive möglicherweise nicht angemessen beachtet.

RPA ahmt menschliches Verhalten nach und benötigt für eine weitgehende Automatisierung entsprechende Benutzerrechte, um auf verschiedene Systeme zugreifen und ihre Funktionen ausführen zu können. Dies könnte dazu führen, dass RPA-Bots (in der Zukunft) zu bevorzugten Zielen von Hackern werden oder sich die Gefahr von Fraud erhöht. Hat eine unautorisierte Person Zugriff auf einen Bot (oder den Orchestrator), hat diese unter Umständen Zugriff auf das ERP-System und wichtige Daten des Unternehmens.

Ein weiteres Sicherheitsproblem besteht darin, dass Bots im Gegensatz zu Menschen nicht erkennen, wenn sich die zugrunde liegenden Prozesse ändern. Sie können beispielsweise wie gewohnt weiterarbeiten und dabei falsche Daten verwenden. Zwei mögliche Beispiele konkretisieren diese Bedenken:

Ein Unternehmen nutzt einen Bot, um sich von einer externen Webseite täglich Wechselkurse zu ziehen und diese in das ERP-System zu übertragen. Ändert sich an der Darstellung der externen Webseite etwas, kann es vorkommen, dass beim Wechselkurs eine zusätzliche Zahl hinzugefügt wird (beispielsweise zu Beginn eine 1 oder am Ende eine 0).
Ein Bot erstellt monatlich eine Auswertung über Kostenarten eines Unternehmens und verwendet diese Daten für weitere Berichte. Wird in einem Monat eine neue Kostenart hinzugefügt, die nicht mit in der Auswertung vom Bot eingeschlossen ist, werden in der Folge falsche Daten erzeugt. Dies kann bei einer manuellen Erstellung durch einen Mitarbeiter ebenfalls geschehen, im Gegensatz zum Bot prüft dieser die Daten jedoch in der Regel auf Plausibilität.

Solche Probleme bestehen insbesondere dann, wenn sich die Mitarbeiter vollständig auf die Bots verlassen, ohne die generierten Daten zu prüfen.

3. Die wahren Kosten von RPA werden oft missverstanden und unterschätzt.

Aktuell wird RPA häufig eingesetzt, um den sogenannten Backlog von Abteilungen abzuarbeiten. Damit ist gemeint, dass RPA den Mitarbeitern dabei hilft, die angestauten Aufgaben oder Aufträge zu erledigen oder sie in Zeiten entlasten, in denen besonders viele Aufträge gleichzeitig eingehen. RPA wird aber zunehmend auch dafür genutzt, alltägliche, routinemäßige Aufgaben zu automatisieren, wobei die freigewordene Kapazität anderweitig genutzt werden kann. Können die Mitarbeiter keine anderen Aufgaben übernehmen und müssen stattdessen auf weitere Aufgaben warten, sind die Einsparungen nur laut dem Business Case des Bots erreicht.

Aber selbst wenn Mitarbeiter weitere Aufgaben übernehmen können, da sie durch einen Bot entlastet wurden, können die wahren Kosten von RPA missverstanden und unterschätzt werden. In vielen Business Cases wird berichtet, dass RPA Arbeitsstunden eingespart und Fehler reduziert werden. In diesen Berichten fehlt jedoch oft die Betrachtung von wiederkehrenden Kosten im Zusammenhang mit der notwendigen laufenden Überwachung, zusätzlicher Assurance-Leistungen und anderer Sicherheitsmaßnahmen, die für die Bots erforderlich werden. Werden diese laufenden Kosten mit einkalkuliert, kann das den finanziellen Erfolg von Bots unter Umständen erheblich schmälern. Zu beachten sind ebenfalls ständige Anpassungen an der Programmierung der Bots, die in Reaktion auf Änderungen in darunterliegenden Systemen vorgenommen werden müssen. Es ist deshalb von großer Bedeutung, beim Einsatz von RPA die richtigen (und stabilen) Prozesse zu automatisieren.

4. Die RPA-Governance ist kompliziert und anspruchsvoll.

Eine weitere Herausforderung bei RPA besteht darin, eine Governance-Struktur zu finden, die eine Balance schafft zwischen der Autonomie und Motivation, die ein dezentrales RPA-Governance-Umfeld mit sich bringt, und der Sicherheit und Kontrolle einer zentralen RPA-Governance-Umgebung. Werden dem lokalen RPA-Entwickler viele zentrale Anforderungen auferlegt, so kann dies demotivierend und arbeitshemmend wirken im Vergleich zu den Freiheiten, die ein dezentraler Ansatz bringt. Dieses Problem ist zwar auch bei anderen Technologien anzutreffen, scheint aber bei RPA besonders problematisch zu sein, da die Technologie keine fortgeschrittenen technischen Fähigkeiten erfordert, die oft nur in zentralisierten IT-Abteilungen zu finden sind.

In der Fallstudie beschrieben mehrere Interviewpartner aus dem RPA-Entwicklungsumfeld ihren Wunsch nach schlankeren Prozessen mit mehr Freiheiten, während Interviewpartner aus Assurance-Funktionen für die Einhaltung aller Standards und Vorschriften plädierten.

Versucht ein Unternehmen eine Governance-Struktur für RPA zu formulieren und schafft es dabei nicht, allgemeine Anforderungen und IT-Anforderungen zwischen den Geschäftseinheiten und verschiedenen Funktionen abzustimmen, kann es zu einer uneinheitlichen und komplizierten Governance-Umgebung kommen, die die zuvor beschriebenen Sicherheitsprobleme weiter verschärft. Ebenfalls zu beachten ist, dass selbst bei einem Vorhandensein von RPA-Regeln nicht gesichert ist, dass sich die Mitarbeiter auch an diese Regeln halten, da RPA-Lösungen leicht heruntergeladen und implementiert werden können.

5. RPA kann zu einem Verlust von Prozesswissen führen.

Eine weitere Gefahr besteht darin, dass beim Einsatz von RPA mit der Zeit Prozesswissen verloren gehen kann. Zwei Dimensionen sind hier zu beachten: Verlust von Fachwissen über die zugrundeliegenden Geschäftsprozesse und Verlust von RPA-spezifischem Wissen.

Automatisiert ein Bot Teile von Geschäftsprozessen, so führt das zwangsläufig dazu, dass Mitarbeiter diese Teil-Prozesse nicht mehr ausführen. Meist überblicken die Mitarbeiter in diesem Fall jedoch noch recht gut, welche Prozessschritte ein Bot ausführt. Werden die erstellten Bots allerdings orchestriert und so in Reihe geschaltet, dass sie End-to-End-Prozesse automatisieren, sind unter Umständen keine Mitarbeiter mehr in diesen Prozess involviert und führen diesen dementsprechend nicht mehr aus. Mit der Zeit kann diese vollständige Automatisierung dazu führen, dass die Prozesse ausschließlich im Hintergrund laufen und die Menschen nach einiger Zeit oder Fluktuationen in der Abteilung vergessen, wie der Prozess ohne Bot-Unterstützung abläuft. Der Verlust von Fachwissen ist besonders problematisch, wenn Bots ausfallen bzw. nicht mehr funktionieren oder der Prozess umgestaltet werden soll.

Des Weiteren kann es dazu kommen, dass Unternehmen das Wissen über die Funktionsweise und Programmierung von Bots verlieren. Wenn Mitarbeiter, die Bots erstellt oder verwaltet haben, das Unternehmen verlassen oder die Abteilung wechseln, muss gewährleistet sein, dass die Bots auch später noch funktionieren. Dafür ist eine ordnungsgemäße Dokumentation erforderlich. Zwei Beispiele verdeutlichen diese Problematik:

Das erste Beispiel ist aus dem MS Excel-Kontext bekannt. Ein Werkstudent entwickelt in seiner Tätigkeit einen Bot, der einen Teilprozess automatisiert. Nach Abschluss des Studiums verbleibt der Werkstudent nicht im Unternehmen und erklärt einem anderen Mitarbeiter die Funktionsweise des Bots. Innerhalb kürzester Zeit kann es dazu kommen, dass der Mitarbeiter nicht mehr weiß, wie genau der Bot programmiert wurde. Ändert sich der Prozess, ist der Mitarbeiter unter Umständen nicht mehr in der Lage, den Bot entsprechend umzuprogrammieren, damit er weiterhin funktioniert. Ein weiteres Szenario wäre, dass keine Übergabe stattfindet und der Bot nach Ausscheiden des Werkstudenten nicht mehr genutzt werden kann.
Das zweite Beispiel beschreibt ein Szenario, das sich in einem kleinen Unternehmen abgespielt hat. Ein Mitarbeiter reißt die RPA-Entwicklung an sich und koordiniert alle RPA-Projekte selbst. Er programmiert über eine längere Zeit einen Bot, der einen wichtigen und arbeitsintensiven Prozess automatisiert. Das Unternehmen verlässt sich so stark auf den Bot, dass der Prozess ohne RPA nicht mehr durchzuführen wäre. Vor diesem Hintergrund kam es dazu, dass der Mitarbeiter das Unternehmen im Unguten verlies, den Zugriff auf den Bot jedoch durch ein Passwort geschützt hatte. Dem Unternehmen war es nicht mehr möglich, auf die Programmierung zuzugreifen, weshalb ein neuer Bot erstellt werden musste.

Diese beiden Beispiele veranschaulichen mögliche Probleme, die durch eine fehlende Governance und Dokumentation auftreten können.

Abschließend zu diesem Kapitel lässt sich festhalten, dass RPA zwar ein wirkungsvolles Werkzeug zur Automatisierung von Prozessen ist, jedoch mit Bedacht implementiert werden sollte. Wichtig ist vor allem, dass die richtigen Prozesse für einen RPA-Einsatz ausgewählt werden und die Governance von Anfang an beachtet wird. Trotz der hier dargestellten Herausforderungen mit RPA kann die Technologie für einige Unternehmen sinnvoll sein.

3. Best Practices für die Prüfung von RPA mit Hilfe eines Kontrollsets

Aktuell existiert in Wissenschaft und Praxis kein spezifisches Rahmenwerk für die Prüfung von RPA.² Ein konkreter RPA-Prüfungsansatz für die Interne Revision ist im Fachbeitrag von Eulerich, Meschke und Grüne (2019) zu finden. Aus dem Forschungsprojekt zur Analyse von Risiken und Herausforderungen ergaben sich zudem weitere Best Practices für die Prüfung von RPA mit Hilfe eines Kontrollsets. Dieses kann verschiedenen Einheiten im Unternehmen bei der Prüfung von RPA behilflich sein.

1. Das Unternehmen sollte über eine angemessene und formale Governance von RPA-Lösungen verfügen und die Nutzer nicht alleine lassen bei der Anwendung.

Mit einer formalen RPA-Governance sind unternehmens- bzw. geschäftsbereichsweite Rahmenbedingungen für den Einsatz von RPA gemeint. Diese definieren strategische Leitlinien und konkrete Anweisungen, unter anderem hinsichtlich Entwicklung, Implementierung, Monitoring und Change Management. Die Schaffung einer RPA-Initiative bzw. einer Organisationseinheit, die sich mit der Entwicklung und dem Betrieb von RPA befasst, wird in vielen Unternehmen vorangetrieben. Vor diesem Hintergrund ist zu beachten, dass sich die verschiedenen RPA-Stakeholder und Assurance-Funktionen abstimmen. Bei Installation eines reinen RPA-Expertenteams kann es dazu kommen, dass die Governance vernachlässigt und stattdessen lediglich Automatisierungspotenziale verfolgt werden.

2. Im Unternehmen sollten Kontrollen vorhanden sein (ITGCs), die IT-assoziierte Risiken von RPA minimieren und den Erfolg von RPA maximieren.

Angemessene Kontrollen sind unerlässlich für den Betrieb einer Technologie. Im Unternehmen sollte ein Rahmenwerk an allgemeinen IT-Kontrollen (ITGCs) vorhanden sein, die für alle Systeme, Prozesse und Daten der Organisation bzw. IT-Umgebung gelten. Ein effektives ITGC-Setup für RPA sollte unter anderem die IT Compliance, Change Management, User Access Management und IT Operations umfassen und damit die IT-assoziierten Risiken beim Einsatz von RPA reduzieren.

3. Ein Kontrollset für RPA bzw. ein PRA-Prüfungsrahmenwerk sollte auf bestehende Kontrollanforderungen im Unternehmen referenzieren und RPA als IT-Element behandeln. Es sollte für die gesamte Organisation gelten, alle gängigen Testbereiche abdecken und das jeweilige Prüfungsvorgehen detailliert beschreiben.

Entwickelt ein Unternehmen ein Kontrollset für RPA, sollte dieses auf bestehende Kontrollanforderungen im Unternehmen referenzieren. Oftmals bestehen im Unternehmen bereits Kontrollanforderungen für IT-Elemente, die auch für RPA gelten. Es bietet sich demnach an, ein solches Kontrollset im IT-Umfeld anzusiedeln und es für die gesamte Organisation als verpflichtend einzuführen. Eine solche Zusammenfassung von bestehenden Kontrollen kann um konkrete Prüfungshandlungen ergänzt werden, um so die Umsetzung der Kontrollen prüfen zu können.

4. Ein entwickeltes Kontrollset für RPA sollte von RPA-Entwicklern, Internen Revisoren und anderen Prüfern sowie den Service-Dienstleistern genutzt werden können.

Das Kontrollset sollte so gestaltet sein, dass sich diverse RPA-Stakeholder daran orientieren können. RPA-Entwicklern kann es dabei helfen, die Kontrollen so umzusetzen, dass bei einer anschließenden Prüfung keine Defizite auftreten. Verantwortliche für Interne Kontrollen können dieses Rahmenwerk anwenden, um die Umsetzung zu prüfen. Auch für die Interne Revision könnte dieses Rahmenwerk bei der Entwicklung eines Prüfungsplans hilfreich sein. Insgesamt kann mit einem solchen Kontrollset erreicht werden, dass im Unternehmen „eine Sprache“ im Hinblick auf Begriffe und Anforderungen gesprochen wird.

5. Eine regelmäßige Prüfung von RPA ist empfehlenswert. Dabei sollte zwischen Attended und Unattended Automation unterschieden werden.

Durch die häufigen Veränderungen und zunehmenden Gefahren in der RPA-Landschaft sind regelmäßige Prüfungen von RPA empfehlenswert. Besonders relevant sind dabei Bots, die eine Relevanz für die Finanzberichterstattung aufweisen. Attended Bots weisen in der Regel geringere IT-assoziierte Risiken auf: Sie greifen auf die Zugriffsrechte ihrer Entwickler zurück, operieren auf dem lokalen PC und sind von anderen Automatisierungstools nicht klar abgrenzbar. Für die Attended Automation sind Schulungen zur Schaffung eines Bewusstseins für Risiken und RPA-Richtlinien empfehlenswert. Unattended Bots und ihre Governance-Struktur müssen dagegen detaillierter geprüft werden.

Literaturverzeichnis

Asatiani, A., and E. Penttinen. 2016. Turning robotic process automation into commercial success – Case OpusCapita. Journal of Information Technology Teaching Cases 6 (2): 67-74.

Christ, M. H., M. Eulerich, R. Krane, and D. A. Wood. 2021. New frontiers for internal audit research. Accounting Perspectives 20 (4): 449-475.

Cooper, L. A., D. K. Holderness Jr., T. L. Sorensen, and D. A. Wood. 2019. Robotic process automation in public accounting. Accounting Horizons 33 (4): 15-35.

Cooper, L. A., D. K. Holderness Jr., T. L. Sorensen, and D. A. Wood. 2021. Perceptions of Robotic Process Automation in Big 4 Public Accounting Firms: Do Firm Leaders and Lower-Level Employees Agree? Journal of Emerging Technologies in Accounting.

Eulerich, M., R. Meschke, and J. Grüne. 2019. Robotic Process Automation als Prüfobjekt. Zeitschrift Interne Revision 54(6): 257-264.

Eulerich, M., J. Pawlowski, N. Waddoups, and D. A. Wood. 2021. A Framework for Using Robotic Process Automation for Audit Tasks. Contemporary Accounting Research Forthcoming.

Eulerich, M., N. Waddoups, M. Wagener, and D. A. Wood. 2022. The Dark Side of Robotic Process Automation. Working Paper. Available at SSRN: ssrn.com/abstract=4026996.

Hallikainen, P., R. Bekkhus, and S. L. Pan. 2018. How OpusCapita Used Internal RPA Capabilities to Offer Services to Clients. MIS Quarterly Executive 17 (1): 41-52.

Harrast, S., and D. A. Wood. 2022. The status of robotic process automation in accounting. The Routledge Companion to Accounting Information Systems Forthcoming.

Kokina, J., and S. Blanchette. 2019. Early evidence of digital labor in accounting: Innovation with robotic process automation. International Journal of Accounting Information Systems 35 (December): 1-13.

Über den Autor

M.Sc. Martin Wagener ist wissenschaftlicher Mitarbeiter und Doktorand am Lehrstuhl für Interne Revision der Mercator School of Management, Universität Duisburg-Essen. Der Lehrstuhl von Univ.-Prof. Dr. Marc Eulerich ist aktuell deutschlandweit der einzige Universitätslehrstuhl mit Fokus auf Interne Revision in Forschung und Lehre. Im Jahr 2020 wurde dem Lehrstuhl der Status „Center for Internal Auditing Excellence“ des Institute of Internal Auditors (IIA) verliehen. Diesen Status haben bisher nur elf Hochschulen weltweit erreicht. Martin Wagener war vor seiner Tätigkeit an der Universität mehrere Jahre als Business Controller in einem großen Technologiekonzern tätig.