Robotic Process Automation (RPA) - Digitization and Automation of Processes: Prerequisites, functionality and implementation using accounting as an example 3658386916, 9783658386917

Citation preview

Christian Langmann Daniel Turi

Robotic Process Automation (RPA) - Digitization and Automation of Processes Prerequisites, functionality and implementation using accounting as an example

Robotic Process Automation (RPA) - Digitization and Automation of Processes

Christian Langmann • Daniel Turi

Robotic Process Automation (RPA) - Digitization and Automation of Processes Prerequisites, functionality and implementation using accounting as an example

Christian Langmann München, Germany

Daniel Turi Cham, Switzerland

ISBN 978-3-658-38691-7    ISBN 978-3-658-38692-4 (eBook) https://doi.org/10.1007/978-3-658-38692-4 © Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2022 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. This Springer Gabler imprint is published by the registered company Springer Fachmedien Wiesbaden GmbH, part of Springer Nature. The registered company address is: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Preface to the First Edition

The use of Robotic Process Automation (RPA) can release considerable efficiency potential for organizations and thus create new opportunities for employees without having to set up costly (IT) projects. The increasing response from practitioners and the high growth expectations for the RPA market in the coming years are therefore not surprising. However, the necessary prerequisites, functionalities and steps for the introduction of this new technology are more extensive than one might initially suspect. Freely available literature and documentation on this are unfortunately usually superficial, not very objective or incomplete. For this reason, we decided to systematize our many years of experience with the use of RPA software and to document it in an easily understandable and practical manner. The feedback on the finished manuscript has confirmed our decision. Writing a book costs a lot of time. Therefore, we thank our families for their understanding that we sometimes have no or less time than usual. This book is dedicated to them. Munich, Germany Cham, Switzerland

Christian Langmann Daniel Turi

v

Preface Second Edition

We completed the manuscript for the first edition in mid-2019. Today, only about 2 years later, much has evolved in the Robotic Process Automation (RPA) space: consolidation among RPA software vendors, evolution from RPA to IPA, or the emergence of SaaS model for RPA, just to name a few developments. In sum, so much has changed and evolved that we decided, together with Springer-Verlag, to write a second and significantly expanded edition. RPA is slowly growing up, maybe it has already grown up. In English, one would say “beyond the hype, becoming mature.” In our experience, the number of companies using RPA today is considerable, which is why there can be no talk of niche technology here. And the number of companies using RPA continues to grow. At the same time, companies still face numerous challenges at the beginning, which actually have nothing to do with the development of software robots or RPA technology in the narrower sense. An experienced RPA expert once summed it up very aptly: “Anyone who introduces RPA quickly realizes that the technical development of software robots is the easy part of RPA.” This book is written precisely for companies that are experiencing this and are looking for solutions to the many challenges. As many positive voices as there may be about RPA, many companies are becoming a little disillusioned, even after years of experience with RPA. The scaling and maintenance of RPA requires companies to take a new look at structures and resources. The question of how to ensure the maintenance of software robots with which resources, for example, is just one example. Citizen developers or perhaps external SaaS service providers? One of the limits companies face when scaling RPA is where software robots need cognitive skills, that is, in reading, understanding, speaking, learning, and thinking. This is precisely where a lot has happened in the last 2 years. We will take a closer look at this development and present various technologies that turn RPA into IPA, that is, Intelligent Process Automation. We also dedicate the second edition to our families. Munich, Germany Cham, Switzerland

Christian Langmann Daniel Turi

vii

Comments on the First Edition

“RPA is an effective tool for businesses to automate repetitive and error-prone processes. When we started using RPA in operations in 2016, that’s exactly what we set out to do. It allows us to be much more accurate and deliver better service for our customers. To enable our employees to focus on value-added work, we set out to improve our processes even further in the future. This book serves as a valuable read to understand the RPA fundamentals and organizational models in detail to successfully get started and also evolve RPA within the organization.” –Josef Elkuch, Global Robotics Delivery Lead, Operations Division of UBS “Robotics enables employees in controlling to automate activities that are often perceived as time-consuming and boring and to focus on business management. The authors show how robotics can be successfully introduced and how employees can be inspired by it.” –Jörg Helten, Member of the Executive Board, ADAC SE “The ideal guidance for starting and further developing the RPA discipline in the company! In addition to valuable case studies from controlling and accounting, central topics such as technology, process selection, governance, operating model and change management are illuminated in an understandable and application-oriented manner.” –Reto Santschi, Head of Automation Center of Excellence, PostFinance “The book “Robotic Process Automation” provides a comprehensive understanding of robot-based process automation and is therefore highly recommended for both “RPA-­ interested” and “robotics-experienced” readers. In addition to the holistic view of the topic, this is also due in particular to the numerous design and practical examples, which represent valuable points of orientation for those responsible in companies.” –Achim Wenning, Partner, Horváth & Partners ix

Disclaimer

This book provides an overview of the necessary prerequisites, the mode of operation, and the individual steps for the successful introduction of Robotic Process Automation (RPA). The following statements represent the personal work of the two authors, and not that of a company or organization. The book was not written on behalf of a company, nor was it sponsored, endorsed, or otherwise funded by a company.

xi

Contents

1 Introduction   1 References��������������������������������������������������������������������������������������������������������������   3 2 Basics  of Robotic Process Automation (RPA)   5 2.1 What Is RPA?������������������������������������������������������������������������������������������������   5 2.2 Motivations for the Use of RPA��������������������������������������������������������������������  10 2.2.1 Technological Motivations����������������������������������������������������������������  10 2.2.2 Operational and Economic Motivations ������������������������������������������  11 2.3 Limitations and Disadvantages of RPA��������������������������������������������������������  13 2.4 Central Terms in the Context of RPA������������������������������������������������������������  15 Literature����������������������������������������������������������������������������������������������������������������  15 3 Introduction  of RPA in Financial and Management Accounting  17 3.1 Phase Model for the Introduction of RPA����������������������������������������������������  17 3.1.1 Proof-of-Concept as a Starting Point (PoC)�������������������������������������  17 3.1.2 Ramp-Up, Scale & Institutionalize and Mature & Innovate������������  19 3.2 Selection of Suitable Processes for RPA������������������������������������������������������  21 3.2.1 Selection Criteria for Processes��������������������������������������������������������  21 3.2.2 Process Optimization Before Automation����������������������������������������  30 3.2.3 RPA-Heatmaps for Central Processes in Financial and Management Accounting����������������������������������������������������������������������������������������  35 3.3 RPA Vendors and Architecture����������������������������������������������������������������������  37 3.3.1 Structure of an RPA Architecture������������������������������������������������������  37 3.3.2 Overview of Leading RPA Vendors��������������������������������������������������  40 3.3.3 Combination of RPA with Other Digitization Technologies������������  42 3.4 RPA Roles ����������������������������������������������������������������������������������������������������  42 3.4.1 RPA Business Analyst����������������������������������������������������������������������  42 3.4.2 RPA Developer & Citizen Developer ����������������������������������������������  43 3.4.3 RPA Architect ����������������������������������������������������������������������������������  44 3.4.4 RPA Support ������������������������������������������������������������������������������������  45 3.4.5 Summary Overview of RPA Roles ��������������������������������������������������  45

xiii

xiv

Contents

3.4.6 Examples of an RPA Role Model from Practice������������������������������  45 3.4.7 Relationship Between RPA Roles and Roles in Financial and Management Accounting������������������������������������������������������������������  47 3.5 RPA Governance������������������������������������������������������������������������������������������  48 3.5.1 Basics of RPA Governance ��������������������������������������������������������������  48 3.5.2 Monitoring and Control of RPA�������������������������������������������������������  51 3.5.3 Compliance and Data Protection in the Use of RPA������������������������  53 3.5.4 RPA Board����������������������������������������������������������������������������������������  54 3.6 RPA Operating Model����������������������������������������������������������������������������������  54 3.6.1 Basics of the Operating Model for RPA ������������������������������������������  54 3.6.2 Operating Models for RPA ��������������������������������������������������������������  56 3.6.3 RPA Development Approaches Within the Operating Models ��������  63 3.6.4 Software-as-a-Service Approach for RPA����������������������������������������  65 3.7 RPA-Specific Change Management��������������������������������������������������������������  66 3.7.1 Basics of Change Management��������������������������������������������������������  66 3.7.2 Impact of the Introduction of RPA on Employees����������������������������  67 3.7.3 Arousing Employee Enthusiasm for RPA����������������������������������������  67 3.7.4 Successfully Embedding RPA in the Organisation��������������������������  69 3.7.5 Knowledge Management for RPA����������������������������������������������������  70 3.8 RPA Performance Measurement������������������������������������������������������������������  73 Literature����������������������������������������������������������������������������������������������������������������  76 4 From  RPA to IPA: How Software Robots Are Becoming Smarter  81 4.1 Evolution from RPA to IPA��������������������������������������������������������������������������  81 4.2 Technologies in Use at IPA ��������������������������������������������������������������������������  83 4.2.1 Technologies for ‘Seeing’ ����������������������������������������������������������������  84 4.2.2 Technologies for ‘Speaking’ ������������������������������������������������������������  87 4.2.3 Technologies for Thinking & Learning��������������������������������������������  89 Literature����������������������������������������������������������������������������������������������������������������  91 5 RPA  in Practice: Results of an Empirical Study  95 5.1 Data Collection and Database����������������������������������������������������������������������  95 5.1.1 Data Collection ��������������������������������������������������������������������������������  95 5.1.2 Composition of the Database������������������������������������������������������������  97 5.2 Results of the Empirical Investigation����������������������������������������������������������  99 5.2.1 Scaling and Experience with RPA����������������������������������������������������  99 5.2.2 Effect of RPA on Success ���������������������������������������������������������������� 101 5.2.3 Selection of Suitable Processes for RPA������������������������������������������ 101 5.2.4 RPA Platforms and Types ���������������������������������������������������������������� 106 5.2.5 RPA Governance������������������������������������������������������������������������������ 109 5.2.6 RPA Operating Model���������������������������������������������������������������������� 111 5.2.7 RPA-Specific Change Management�������������������������������������������������� 114 5.2.8 RPA Performance Measurement������������������������������������������������������ 117

Contents

xv

Literature���������������������������������������������������������������������������������������������������������������� 118 6 Application  Examples for RPA in Financial and Management Accounting 121 6.1 Monthly Reporting in Management Accounting������������������������������������������ 121 6.2 Invoice Dispatch at the KION Group������������������������������������������������������������ 122 6.3 Application Processing at KfW�������������������������������������������������������������������� 122 6.4 Preparation of the Quarterly Closing Report at Union Investment�������������� 123 6.5 Accounting for Accruals and Deferrals�������������������������������������������������������� 123 6.6 Cost Allocation in Cost Accounting�������������������������������������������������������������� 124 6.7 Electronic Booking Document at Heraeus���������������������������������������������������� 124 6.8 Creation and Validation of Upload Files������������������������������������������������������ 125 Literature���������������������������������������������������������������������������������������������������������������� 125 7 Conclusion and Outlook

127

About the Authors

Christian  Langmann  teaches financial and management accounting at Munich University of Applied Sciences (Hochschule München). For years, his focus has been on the impact of digitalization on the role, organization, processes, and IT of financial and management accounting (rpa-controlling.de or digitalisierung-controlling.de). Christian Langmann started his professional career as a project manager at Horváth & Partners, a specialist management consultancy for management accounting and corporate management. He was subsequently appointed chief financial officer (CFO) at various companies, including blau Mobilfunk in Hamburg and cbs in Heidelberg. He was also in the management of Telefónica Deutschland, where he held commercial responsibility for the B2B area.  For years, Christian Langmann has been advising companies on the further development of financial and management accounting in the age of digitalization, both for large corporations and SMEs (www.langmann-consulting.de). He was also involved in scientific research on the digitalization of financial and management at an early stage. For example, he wrote about the application of statistical process control in accounting as early as 2006. In the meantime, Christian Langmann has written several articles and books on the subject. You can reach him at [email protected]. Daniel  Turi  is currently head of the financial data management department at Allianz Suisse Versicherung-Gesellschaft AG. In his role, he is responsible for the planning and reporting applications as well as the automation and robotization of financial processes. He has led the RPA implementation at Allianz Suisse and built the RPA training and operating model accordingly.  In his career, he has managed various international finance projects, such as the implementation of SAP BW for reporting and planning in Austria as well as in Central and Eastern European countries at HDI Versicherung AG. He has held various roles in different functions, such as the management of an M&A project, lean projects for the optimization of financial processes, and the management of central cost

xvii

xviii

About the Authors

controlling.Daniel Turi has given numerous presentations in Germany and Switzerland on the topic of Robotic Process Automation and the integration of RPA. In addition to the technical requirements, his presentations also make it clear that employee training and the establishment of a “digital mindset” are of central importance for successful implementation.He is also a co-founder of the RPA Community in Switzerland, where companies have the opportunity to discuss with each other the introduction and anchoring of RPA. You can reach him at https://www.linkedin.com/in/danielturi1/.

Abbreviations

BPM BPMS BPR CC CEO CFO CoE CRM CV GDPR ERP FTE IPA IRPAAI IT AI SME NLG NLP OCR OKR PoC PR RDA ROI RPA RPA Labs SLAs SPA SSC VBA

Business process management Business process management systems Business process reengineering Competence center Chief executive officer Chief financial officer Center of excellence Customer relationship management Computer vision General Data Protection Regulation Enterprise resource planning Full-time equivalents Intelligent Process Automation Institute For Robotic Process Automation & Artificial Intelligence Information technology Artificial intelligence Small and medium-sized enterprises Natural language generation Natural language processing Optical character recognition Objectives and Key Results Proof of concept Public relations Robotic Desktop Automation Return of investment Robotic Process Automation RPA Laboratories Service level agreements Smart Process Automation Shared service centre Visual Basics for Applications xix

List of Figures

Fig. 2.1 Fig. 2.2 Fig. 2.3 Fig. 3.1 Fig. 3.2 Fig. 3.3 Fig. 3.4 Fig. 3.5 Fig. 3.6 Fig. 3.7 Fig. 3.8 Fig. 3.9 Fig. 3.10 Fig. 3.11 Fig. 3.12 Fig. 3.13 Fig. 3.14 Fig. 3.15 Fig. 3.16 Fig. 3.17 Fig. 3.18 Fig. 3.19 Fig. 3.20 Fig. 3.21

RDA, RPA and IPA development stages 8 Relationship between processes, IT specialization and RPA5 9 Central terms in the context of RPA 14 Procedure for Proof-of-Concept (PoC)/Pilots 18 Stage model for the introduction of RPA 20 Scoring model for RPA process selection 26 Matrix automation value and capacity savings 27 Checklist for selecting the processes to be automated in RPA at the MANN+HUMMEL Group. (Cf. Hermann et al. 2018, p 33) 28 Questionnaire for determining the RPA automation potential of processes at Merck. (Cf. Pellegrino and Mega 2020, p 36) 29 Properties of suitable processes for RPA at Wien Energie. (Cf. Schmelzer 2020, p 36) 29 Selection interface of the PEPA model for selecting suitable processes for RPA. (Cf. Plattfaut et al. 2020, p 1124) 30 Procedure for process optimization in the context of RPA (simplified) 31 Optimization approaches for processes8 33 EORA model as procedure model for process selection for RPA at Union Investment. (Cf. Tröndle 2020, p 61 f) 34 RPA heat map for management accounting processes12 35 RPA heat map for financial accounting processes 36 Exemplary RPA architecture 38 Overview of the naming of the central RPA components using the example of UiPath, Automation Anywhere, and Blue Prism38 Modeling a process in UiPath Studio 39 Modeling a process with Blue Prism Process Studio 39 Modeling a process with Automation Anywhere40 Overview of leading RPA providers (as of March 2021) 41 Tasks and knowledge of the RPA roles 46 RPA roles at ECE. (Cf. Petersen and Schröder 2020, p 1142) 46 xxi

xxii

Fig. 3.22 Fig. 3.23 Fig. 3.24 Fig. 3.25 Fig. 3.26 Fig. 3.27 Fig. 3.28 Fig. 3.29 Fig. 3.30 Fig. 3.31 Fig. 3.32 Fig. 3.33 Fig. 4.1 Fig. 4.2 Fig. 4.3 Fig. 4.4 Fig. 4.5 Fig. 5.1 Fig. 5.2 Fig. 5.3 Fig. 5.4 Fig. 5.5 Fig. 5.6 Fig. 5.7 Fig. 5.8 Fig. 5.9 Fig. 5.10 Fig. 5.11 Fig. 5.12 Fig. 5.13 Fig. 5.14 Fig. 5.15 Fig. 5.16 Fig. 5.17 Fig. 5.18 Fig. 5.19

List of Figures

Employee activities after robotization 51 Centralized operating model for RPA 56 Advantage and disadvantage of the centralized operating model for RPA 58 Decentralized operating model for RPA 59 Advantage and disadvantage of the decentralized operating model for RPA 60 Hybrid operating model for RPA 61 Advantages and disadvantages of the hybrid operating model for RPA 62 Overview of the Operating Models for RPA 63 Objectives of RPA training courses 71 Development stages for RPA training courses 71 Overview of key figures for RPA performance measurement 74 RPA Analytics report – Example UiPath 75 Differentiation RPA vs. IPA. (Cf. Hermann et al. 2018, p 29) 82 Stages of Intelligent Process Automation. (Cf. Ng et al. 2021, p 6) 83 Automatic OCR text recognition when entering an invoice document in Lexoffice. (Cf. Lexoffice 2021)85 Meaning of words depending on context (here: online communities). (Cf. Hamilton et al. 2016)88 RPA & NLP Workflow. (Cf. Arria 2021, p 15) 89 Sector distribution of the sample (N = 101) 97 Distribution of company size by turnover (N = 101) 98 Distribution of company size by number of employees (N = 101, in thousands) 98 Distribution of participants by functional area (N = 101) 99 Year of introduction of RPA (N = 101) 100 Number of software robots currently in use (N = 101) 100 Relationship between year of introduction and number of software robots used (N = 101) 101 Effect of RPA on success (N = 101) 102 Process preparations for RPA (N = 99–101) 103 Complexity of processes for RPA (N = 99) 104 RPA use by functional areas (N = 101) 104 RPA use in finance, financial accounting, and management controlling processes (N = 81) 105 Activities of software robots (N = 101) 106 Single vs. multiple RPA platforms (N = 101) 107 Attended vs. Unattended RPA (N = 101) 108 RPA vs. IPA (N = 101) 108 Digitization technology combined with RPA (N = 63) 109 Components of RPA governance (N = 100–101) 110 RPA testing (N = 100) 111

List of Figures

xxiii

Fig. 5.20 Fig. 5.21 Fig. 5.22 Fig. 5.23 Fig. 5.24 Fig. 5.25 Fig. 5.26 Fig. 5.27

112 113 114 115 116 116 117 118

Operating models for RPA (N = 101) Involvement of the IT department (N = 100) Support from external consultants (N = 101) Communication in the context of RPA implementation (N = 101) Change management during RPA implementation (N = 100) RPA training (N = 100) Top management support for RPA (N = 100) RPA performance measurement (N = 101)

1

Introduction

The automation of activities in controlling & accounting has been intensively discussed in science and practice for years. In the meantime, the efficiency pressure on the finance organization has increased so much that, according to surveys, automation now occupies the number one spot on the CFO agenda.1 A far-reaching automation of processes in controlling & accounting has failed so far because traditional automation technologies (e.g. BPMS) are usually only used for a few, central business processes due to the IT costs required for this. Processes such as reporting are usually not among them. It is therefore hardly surprising that the manual preparation of financial data, for example for the regular creation of reports, still plays a major role for the majority of companies today.2 For a few years now, a new generation of software solutions for process automation has been gaining importance: Robotic Process Automation (RPA), also abbreviated as Robotics. The relatively fast, inexpensive and simple implementation, i.e. without in-depth programming knowledge, explains the increasingly strong acceptance and spread of RPA in practice. In the meantime, globally known major companies such as Daimler, Merck, Telefónica, Deutsche Telekom, Deutsche Bahn or Allianz Insurance are also using modern RPA software platforms for process automation.3 However, RPA is not only accepted by large companies, but also by small and medium-sized enterprises (SMEs).4 It is not uncommon for the introduction of RPA to start in the finance area of a company. For example, Merck started with software robots in the finance area in 2016. Marcus Kuhnert, the CFO of Merck, said in a recent interview about the software robots used:

 Cf. Langmann (2019); Horváth and Partners (2018), p 3.  Cf. KPMG and FhG FIT (2017), p 15. 3  See PWC (2018); Weber (2018); Lacity et  al. (2015); Schmitz et  al. (2019); Schneider (2018); Stackoverflow (2019); Swiss Post Solutions (2019). 4  Cf. IDG (2019). 1 2

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2022 C. Langmann, D. Turi, Robotic Process Automation (RPA) - Digitization and Automation of Processes, https://doi.org/10.1007/978-3-658-38692-4_1

1

2

1 Introduction They’re basically replicating the pure transactional activities of an employee pretty perfectly already – and they’re doing it at a pace and with a resistance to error that’s pretty impressive.5

The first reports on possible efficiency gains when using RPA are simply impressive. For example, project examples from the finance sector show double-digit percentage reductions in manual activities combined with shorter lead times after the introduction of RPA for processes such as invoicing or the creation/release of order forms.6 On the efficiency gains from RPA, the Wall Street Journal recently wrote: Early adopters of robotic process automation report higher productivity, happier customers […].7

The finance area with its functional areas of controlling, accounting, finance, treasury and taxes is one of the administrative areas where companies expect high efficiency gains through RPA implementation and therefore prefer to introduce RPA.8 Company representatives now believe that finance processes will be well over 80% automated and digitized by new technologies like RPA in 5–10 years.9 However, the implementation of RPA in finance is not just an IT technical process. Rather, the successful introduction depends on a variety of factors, such as the documentation and standardization of process flows, cooperation with the IT department or specific governance.10 In view of the increasing importance of RPA for controlling & accounting, this book is dedicated to the central dimensions that companies should address when introducing RPA.  Reports on experiences from previous RPA implementations and numerous case studies show which approaches and solutions work in practice. In doing so, the authors draw on their many years of experience with the digitalization of finance in general and the application of RPA in particular. Chapter 2 therefore first goes into the basics and explains what is meant by RPA in detail and what goals companies are pursuing with the introduction. In Chap. 3, the authors address the various dimensions that are central to the introduction of RPA. In addition to the selection of processes to be robotized and the appropriate RPA platform, the focus is also on the design of governance and the choice of an operating model for RPA.  The introduction of roles related to RPA, the importance of change management and performance measurement complete the chapter. Selected case studies on RPA applications in controlling & accounting are explained in Chap. 4, before Chap. 5 takes another look at the topic in summary.

 See Marcus Kuhnert’s interview with Jürgen Weber, in: Weber (2018), p 26.  Cf. UiPath (2019), p 14. 7  Wall Street Journal (2019). 8  Cf. Capgemini (2016), p 19, 21. 9  Cf. KPMG and FhG FIT (2017), p 26. 10  Cf. Deloitte (2018); PWC (2017). 5 6

1 Introduction

3

References Capgemini (2016) Robotic Process Automation – Robots conquer business processes in back office, abgerufen am 15.05.2019 unter: https://www.capgemini.com/consulting-­de/wp-­content/uploads/ sites/32/2017/08/robotic-­process-­automation-­study.pdf Deloitte (2018) The robots are ready. Are you? abgerufen am 18.03.2019 unter: https://www2. deloitte.com/content/dam/Deloitte/tr/Documents/technology/deloitte-­robots-­are-­ready.pdf Horváth & Partners (2018) CFO-Studie 2018: „Chancen der Digitalisierung erkennen und die digitale Transformation der Finanzfunktion meistern“, abgerufen am 18.03.2019 unter: https:// www.horvath-­partners.com/fileadmin/horvath-­partners.com/assets/05_Media_Center/PDFs/ deutsch/180626_WP_CFO_Studie_B_g.pdf IDG (2019) Studie Process Mining & RPA 2019, München KPMG und FhG FIT (2017) Digital Finance  – Ergebnisse einer empirischen Untersuchung zur Digitalisierung im Finanzbereich, Studie der KPMG und des Fraunhofer-Institut für Angewandte Informationstechnik FIT Lacity M, Willcocks L, Craig A (2015) Robotic Process Automation at Telefónica O2, Paper 15/02, The Outsourcing Unit Working Research Paper Series, London School of Economics and Political Science Langmann C (2019) Digitalisierung im Controlling, 1. Aufl. Springer Gabler. Wiesbaden PWC (2017) Successful implementation of RPA takes time – Lessons learnt by 18 of the largest Danish enterprises, abgerufen am 18.03.2019 unter: https://www.pwc.dk/da/services/2018/RPA-­ rapport-­engelsk.pdf PWC (2018) Digitalisierung im Finanz- und Rechnungswesen und was sie für die Abschlussprüfung bedeutet, abgerufen am 18.03.2019 unter: https://www.pwc.de/de/im-­fokus/digitale-­ abschlusspruefung/pwc-­digitale-­abschlusspruefung-­2018.pdf Schmitz M, Dietze C, Czarnecki C (2019) Enabling Digital Transformation Through Robotic Process Automation at Deutsche Telekom, in: Urbach N, Röglinger M (Hrsg.) Digitaliziation Cases, S 15–33, 1. Aufl. Springer International Publishing. Cham Schneider S (2018) Robotics im Reporting – Reiner Effizienztreiber oder auch Begeisterungsfaktor?. Bericht von der Fachkonferenz Reporting & Analytics 2018 zum Vortrag von Daniel Turi, Leiter Finanzdatenmanagement der Allianz Suisse, abgerufen am 07.08.2018 unter: https://www.haufe. de/controlling/controllerpraxis/robotics-­im-­reporting_112_462342.html Stackoverflow (2019) Stellenanzeige als UiPath Developer / Consultant (m/f) bei BASF, abgerufen am 18.03.2019 unter: https://stackoverflow.com/jobs/196293/uipath-­developer-­consultant-­m-­f-­basf Swiss Post Solutions (2019) Reisekostenabrechnung per Robotic Process Automation, abgerufen am 01.06.2019 unter: https://www.swisspostsolutions.com/de/casestudydocument/sps_kundenreferenz_deutschebahn_reisekosten-­app_transport.pdf UiPath (2019) Automating Finance & Accounting, White Paper, abgerufen am 01.03.2019 unter: https://www.uipath.com/solutions/whitepapers/rpa-­will-­transform-­finance-­accounting Wall Street Journal (2019) Unleash the Bots: Firms Report Positive Returns With RPA, abgerufen am 15.05.2019 unter: https://www.wsj.com/articles/unleash-­the-­bots-­firms-­report­positive-­returns-­with-­rpa-­11551913920 Weber J (2018) Robotics wird so selbstverständlich sein wie Elektrizität – Interview mit Marcus Kuhnert (CFO Merck), in: Controlling & Management Review, 8/2018, S 24–29

2

Basics of Robotic Process Automation (RPA)

2.1 What Is RPA? There are many definitions of RPA.  The Institute For Robotic Process Automation & Artificial Intelligence (IRPAAI), for example, defines RPA as. …the application of technology that allows employees in a company to configure computer software or a ‘robot’ to capture and interpret existing applications for processing a transaction, manipulating data, triggering responses and communicating with other digital systems.1

Lacity/Willcocks (2016), on the other hand, write about RPA. ...software tools and platforms that can automate rules-based processes that involve structured data and deterministic outcomes.2

Similarly, Aguirre/Rodriguez (2017) describe RPA as. Robotic Process Automation (RPA) emerges as software-based solution to automate rules-­ based business processes that involve routine tasks, structured data, and deterministic outcomes.3

And Gartner (2021) defines RPA as.

 IRPAAI (2019).  Lacity/Willcocks (2016), p 42. 3  Aguirre/Rodriguez (2017), p 65. 1 2

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2022 C. Langmann, D. Turi, Robotic Process Automation (RPA) - Digitization and Automation of Processes, https://doi.org/10.1007/978-3-658-38692-4_2

5

6

2  Basics of Robotic Process Automation (RPA) Robotic process automation (RPA) tools perform “if, then, else” statements on structured data, typically using a combination “of user interface (UI) interactions, or by connecting to APIs to drive client servers, mainframes or HTML code.4

Simply speaking, RPA can initially be understood simply as a software program with which (software) robots can be programmed. The developed robots are then able to perform entire business processes or individual process steps independently and automatically. Here, the robot interacts with the systems or applications involved in the process, processes structured data on the basis of clear if-then rules, and thus mimics human user interaction in the process. Efficiency gains result, among other things, from the fact that the robot can work faster, error-free, and permanently.5 Since the basic principle of automation with RPA is user input, it has technical similarities to existing approaches such as screen scraping.6 In contrast to classic screen scraping, however, robots typically do not work with pixel points, but with so-called (technical) selectors. So while classical screen scraping found a button to be pressed on a website using pixel coordinates, RPA uses the technical specifications of the button from the website’s code. This allows the robot to find the button even with different resolutions or different placements, for example, if the browser window is reduced in size. RPA can be divided into two types, attended and unattended RPA: Attended RPA is sometimes also referred to as Robotic Desktop Automation (RDA). The robot runs directly on the user’s desktop. The user starts, monitors, and interacts with the robot via its own screen, which is integrated into various processes of the user and executes them automatically via the applications involved. Similar to an Excel macro, a robot can thereby mimic simple activities, but also control other applications besides Excel. (In-depth) programming knowledge is not necessarily required to set up a simple robot. Attended RPA can be used in accounting, for example, for monthly reporting. The user triggers the robot to extract the current monthly figures from the systems and to aggregate them after the closing date. Unattended RPA, on the other hand, refers to robots that usually run on a server in the background, start themselves and (usually) execute the affected processes without user interaction. The robots under Unattended RPA are centrally monitored and controlled (e.g., in an RPA Center of Expertise (Sect. 3.6). They are often triggered by specific triggers (e.g., receipt of an email, presence of a file in a folder) or controlled by a timed schedule. In this case, the robots usually address several different systems and can divide the tasks among themselves. An example of the use of Unattended RPA in accounting is the use of robots in accounts payable, where incoming invoices (via email) are automatically read using Optical Character Recognition (OCR) and posted in an ERP system such as SAP. The results of a recent study among companies using RPA show a stronger use of Unattended RPA compared to Attended RPA in practice (Chap. 5). Between Attended and Unattended RPA, there are various hybrid models that combine both types of RPA. For example, robots triggered by the user under Attended RPA can trigger  Gartner (2021).  Cf. Lhuer (2016). 6  Cf. Czarnecki and Auth (2018), p 117. 4 5

2.1 What Is RPA?

7

a robot running in the background under Unattended RPA. An example for this combination would be a request to delete customer data from all systems in the company under the GDPR. In this case, the user triggers the (Attended) robot on his desktop, which in turn triggers other (Unattended) robots in the background to delete the data from the various systems. Another form of hybrid model is the so-called “human-in-the-loop” concept. These are (unattended) robots that automate most of the process steps in the background, but involve a human in complex decisions. The human decides and hands the process back to the robot. Deutsche Telekom, for example, reports very positive experiences with “human-in-­ the-loop” concepts in the service area.7 Robots can be used for processes that have a recurring, rule-based character and structured data (e.g. tables, databases) as input (Sect. 3.2.1). For processes that are unstructured or/and have unstructured data (e.g. text, video, images) as input, do not run according to transparent rules and do not repeat in the same way or repeat extremely rarely, classical RPA is not a useful solution. In other words, the application of RPA is mainly suitable for structured routine tasks with rule-based decisions and high frequency. After RDA and RPA, the next stage of development is the combination with new digitalization technologies such as machine learning or advanced analytics, which is also referred to as Smart Process Automation (SPA) or Intelligent Process Automation (IPA). This can also be used to automate processes in which unstructured data is to be processed or complex decisions are to be made.8 Since SPA/IPA has evolved in recent years and many companies today are already linking classic RPA with more intelligent technologies, this topic area is discussed in detail separately in Chap. 4. Figure  2.1 illustrates the relationship between RDA, RPA, and SPA/IPA. Software-supported process automation has already been successfully used in companies for decades and is therefore fundamentally nothing new. Business Process Management Systems (BPMS) are an example of software-supported process automation.9 RPA differs from these automation solutions in the following respects, among others10: • RPA is built on top of existing systems and accesses these systems through the presentation layer (graphical user interface – gui), eliminating the need to modify existing application systems. • RPA solutions usually require little to no programming knowledge to develop robots. Instead, the robots are developed using drag-and-drop of ready-made activities (e.g. mouse click, open browser), which are brought into a process flow and visualized.11 RPA solutions such as UiPath StudioX take over even the simplest basic programming processes, such as the creation of variables.12  Cf. Zeiss/Jenesl (2020), p 51.  Cf. Czarnecki and Auth (2018), p 118 ff. 9  Cf. Gartner (2019a). 10  See Aguirre/Rodriguez (2017); Czarnecki and Auth (2018); Willcocks/Lacity (2016). 11  At this point, it should be noted that robots (may) require programming skills for more extensive processes. 12  Cf. Uipath (2021). 7 8

8

2  Basics of Robotic Process Automation (RPA)

Robotic Desktop Automation (RDA) 



Robotic Process Automation (RPA) 

Robots usually run directly on the desktop



User starts and monitors the robot (‘Attended Robots’)



Intelligent Process Automation (IPA) 

Robots usually run centrally on servers in the background Usually does not require active user interaction Robots are started and controlled from a central control center (‘Unattended Robots’)



Intelligent Process Automation (IPA) refers to the combination of RPA with modern digitization technologies. Examples of technologies are Machine Learning, Predictive Analytics, Natural Language Processing / Generation or Big Data technologies

Fig. 2.1  RDA, RPA and IPA development stages

• RPA solutions do not create a new application, but rather a software robot that typically does not store the processed data either, which is why no data model or database is required as in BPMS systems.13 Another difference lies in the scope of the process to be automated. RPA usually focuses on the automation of individual sub-processes or activities, less on the entire process. Automation solutions such as BPMS aim at the automation of integrated, more complex business processes that rely on applications specialized for this purpose (see point 1 in Fig. 2.2). The use of integrated solutions (e.g. SAP) for core processes such as order-to-­ cash or purchase-to-pay are also examples of this. The high importance of these central processes for the economic success of the company means that the majority of the already scarce IT development and operating capacities are usually reserved for them.14 For subordinate processes or individual sub-activities in processes, central IT resources are usually not available or not sufficiently available (see point 2  in Fig.  2.2). Instead, process automation is left to the business units or departments themselves. An example of a mostly subordinate process is the travel expense accounting process. This subordinate process, which is administered by the accounting department and anyway only concerns traveling persons in business units, is often manual and time-consuming. Checking receipts, comparing them with submitted travel expenses, obtaining approvals, instructing payments are just a few examples of process steps. Although central ERP systems can support the individual process steps, different applications are usually involved in the process, and/or manual steps remain with the employees in charge. This is exactly where RPA can support. For example, sub-process steps (e.g. reconciliation of travel expenses or  Log files, i.e. log files in which all activities of a robot are recorded (Sect. 3.5), are to be distinguished from this. 14  Cf. Willcocks et al. (2015), p 8 f.; Lacity et al. (2015a), p 12; on the IT skills shortage, cf. e. g. Bitkom (2018). 13

2.1 What Is RPA?

9 IT-Resources (Development, Operation)

Business Resources (Development, Operation, IT-Support)

High 1 Interconnected core processes in specialized applications (e.g. ERP, CRM)

Focus for RPA

Importance of the process to the business & IT-Resources required

2 Subordinate, function-specific processes (e.g., finance, HR) that often use (function-) specific software applications

Low High

Degree of Specialization in IT-Solutions

Low

Fig. 2.2  Relationship between processes, IT specialization and RPA5

bookings) can be automated by the functional areas themselves without using central IT resources with the help of RPA. For example, at Deutsche Bahn, 92.6% of the applications for the settlement of a business trip or the associated travel expenses are automated thanks to an RPA solution.15 Due to the differences to classic automation solutions such as BPMS described above, RPA solutions allow for a significantly more cost-effective implementation of process automation, among other things due to the smaller amount of IT resources required for this. Using Telefónica UK as an example, Lacity et al. (2015a) report, for example. [...] when it came to the financials, RPA was the clear winner. Butterfield said, ‘Our projections showed that RPA for 10 automated processes would pay back in 10 months. In contrast, the BPMS was going to take up to three years to payback.’.16

Against the backdrop of the various facets and advantages of RPA, BPMS, or classic interfaces, companies often also combine the different automation approaches. For example, Deutsche Post DHL combines RPA with its Business Process Management

 Cf. Swiss Post Solutions (2019).  Lacity et al. (2015a), p 7.

15 16

10

2  Basics of Robotic Process Automation (RPA)

(BPM) platform, Deutsche Telekom, for example, reports good experiences with the combination of RPA and classic interfaces.17 In addition to financial aspects, RPA offers a number of benefits, which are discussed in detail in the following chapter.

2.2 Motivations for the Use of RPA 2.2.1 Technological Motivations In addition to the automation of processes, CFOs have seen a considerable need for action in system integration for years.18 It is not uncommon for transactional activities in finance, financial accounting, or management accounting to be characterized by a fragmented system landscape. Controllers, for example, compile the necessary figures from several systems to create a report before they process the figures further. Accountants, on the other hand, reconcile the incoming invoice with the purchase order form, obtain factual and budgetary approvals, post and allocate the payment; often not only in one system, but in several separate systems. In practice, system-side integration usually fails due to high costs or the availability of IT resources. Here, RPA platforms can be used as a bridging technology and eliminate missing interfaces in a fragmented system landscape. Whether it is permanent or only until complete system integration is achieved plays a subordinate role. From the RPA experience at Union Investment, however, Tröndle (2020) points out that an implementation of process automation in standard systems or via interface leads to more stable or functionally better systems. This means that RPA is used when it is not possible to implement it in another way that is better, faster, or cheaper.19 The use of RPA as a bridging technology usually does not require any modification of the IT infrastructure, but is based on the existing IT landscape. The systems and applications used to date therefore remain untouched. Only the operation, which was previously carried out by clerks, is replaced by a robot. The robot behaves in the same way as the clerk.20 This circumstance and the relatively simple handling of RPA software, which often does not require any (in-depth) experience in programming languages, have the consequence that robots are mostly set up by the operational units – and not by the (central) IT department, although close coordination with the (central) IT is indispensable for topics such as installation, operation, security or governance.21 In addition to its use as a bridging technology that does not require any modifications to the IT infrastructure and is easy to handle, the low costs for introduction and operation and the high return on investment (ROI) of RPA technology are cited as a central reason  Wenzel (2020); Zeiss/Jenesl (2020).  Cf. e.g. e.g. Horváth & Partners (2014). 19  Cf. Tröndle (2020), p 62. 20  Cf. Scheer (2017), p 29 f. 21  See PWC (2017), pp. 10, 21–22; Scheer (2017), p 30. 17 18

2.2 Motivations for the Use of RPA

11

for its introduction.22 Project examples and studies confirm the correlation. For example, the RPA implementation for back-office activities at Telefónica UK had only a 10-month payback period. Other studies report payback periods of less than 12 months.23 The ROI associated with RPA is estimated at 30–200% in the first year alone.24 Another motivation for the use of RPA is the high scalability of robots. In a case study of a European energy supplier, for example, 300 robots are used for back-office activities (e.g. invoicing), which do the work of 600 employees. The robots are supervised and maintained by only 2 employees.25 The high scalability is mainly due to the working speed of the robots and the possibility to let them work theoretically 24 h a day, 7 days a week. The reusability of modules of already developed robots in comparable processes can also be cited as a motivation for the use of RPA.  Modern RPA platforms such as Blue Prism have already developed modules in an integrated library, such as retrieving e-mails, reading data from an Excel file, or conducting a user dialog. These pre-developed modules only need to be adapted to the respective process characteristics.

2.2.2 Operational and Economic Motivations In addition to the technological motivations, there are also a number of operational and economic motivations for the use of RPA in financial and management accounting. The operational efficiency increases associated with RPA are often the central motivation for an RPA implementation. Shorter processing times, no processing errors due to creeping fatigue, as well as consistent work speed and quality are the distinguishing features of robots in contrast to human interaction. Case studies from financial and management accounting underline this connection. For example, according to UiPath, automating daily P&L reports using RPA at a financial services company improved cycle time by 67% and reduced the error rate to 0%.26 In a study by PWC (2020), 84% of companies cite time savings as the biggest benefit they have gained from using RPA.27 In addition to purely increasing time and efficiency, the use of RPA in financial and management accounting can also lead to real cost savings.28 According to Gartner (2018), the cost of using RPA is only about one-third to one-fifth of an employee, which would represent a 66–80% savings.29 Case studies confirm this estimate.30 However, the use of RPA does not only lead to cost-saving potentials by saving existing employee capacities,  Cf. e.g. e.g. Lacity et al. (2015a).  Cf. Deloitte (2018), p 2. 24  Cf. Lhuer (2016). 25  Cf. Lacity et al. (2015b), p 10. 26  Cf. UiPath (2021c), p 14. 27  Cf. PWC (2020), p 15. 28  Cf. Capgemini (2016), p 39. 29  Cf. Gartner (2018). 30  Cf. UiPath (2021c), p 14. 22 23

12

2  Basics of Robotic Process Automation (RPA)

but also by the reshoring (insourcing) of outsourced financial processes from low-wage countries. Thus, the trend of the past years towards offshoring, i.e. the relocation of financial processes to shared service centers (SSC) in emerging economies seems to be facing a new bifurcation. In this regard, Slaby (2012) writes. [...] a robot that costs less than half of an offshore FTE is a significant threat to every outsourcing firm whose value proposition rests on low human labor costs.31

According to a joint study by KPMG and the Fraunhofer Institute for Applied Information Technology FIT, more than half of those surveyed believe that automation through technologies such as RPA will go so far as to enable cost-saving potential through the reshoring of outsourced processes from low-wage countries.32 This inevitably raises the question of whether offshoring financial processes in SSCs will still make sense in the future if processes are automated using RPA. Another motivation for RPA compared to other automation technologies is the relatively short implementation time. A look at practice shows that the technical development of a robot with the help of modern RPA software can be completed after just a few weeks.33 From this point on, efficiency gains become directly apparent. However, previous experience also shows that a complete integration of RPA into the organization with all relevant dimensions (governance, operating model, etc.) takes rather 4–6 months.34 The introduction of RPA can also increase the satisfaction of employees who were previously involved in the process, as well as the satisfaction of the recipients of the process results, i.e. other employees or stakeholders of the company. Recent studies show, for example, that after process automation with RPA, employees were more satisfied with their work and were able to focus on more value-added tasks, and employee retention increased.35 In order to robotize processes and to achieve the described positive effects from the use of RPA, it is first necessary to identify and document suitable processes (for the selection of processes, see Sect. 3.2.1). The content of a process documentation is the definition and sequence of the individual process activities as well as the clear definition of responsibilities and involved systems. Regarding the level of detail, the activity level (level 4) and transaction level (level 5) are necessary (Sect. 3.2.2). Surveys on the introduction of RPA show, however, that processes are often not standardized and are lived differently in reality despite existing process documentation.36 Thus, the exact recording of the lived process is necessary in order to uncover inefficiencies and to carry out optimizations (e.g. elimination of double loops) before the process is mapped by a robot. Due to this necessary

 Slaby (2012), p 14.  See KPMG and FhG FIT (2017), p 24; also the study by Capgemini (2016), p 31. 33  See, for example, Lacity et al. (2015a). 34  Cf. PWC (2017), p 7. 35  See, for example, Forrester Research (2018), pp. 2–3. 36  Cf. Deloitte (2018), p 14. 31 32

2.3 Limitations and Disadvantages of RPA

13

prerequisite, the introduction of RPA ultimately also has the effect of improving process documentation and optimizing existing processes without automating them directly in RPA.37 These are exactly the effects Deutsche Post DHL made when introducing RPA. Wenzel (2020) describes that the prior examination of the business processes with regard to standardization and optimization potential and the subsequent improvement led to the subsequent RPA implementations being less complex and paved the way for future system consolidation and optimization.38

2.3 Limitations and Disadvantages of RPA Despite the numerous advantages described, RPA also has limitations and disadvantages.39 A central point here is the maintenance of the robots. Even the smallest change in the underlying process (e.g., in the user interface of the applications involved) can cause robots to run into errors and require an adjustment. Especially in more complex processes with many decision possibilities or in processes with frequent changes, there is an increased susceptibility to errors, the maintenance of which can be time-consuming and costly. The efficiency gains of RPA generally increase with the number of robots. Nevertheless, an increasing number of robots also requires a correspondingly powerful organization that maintains sufficient resources (e.g., RPA developers), regulates central processes (e.g., change request process), and establishes dedicated RPA governance. However, studies show that companies struggle with the scaling of RPA.40 As described in Sect. 2.2.2, the introduction of RPA requires precise documentation of the process to be robotized, down to the click level, which is usually not yet available but must first be created. Although this type of documentation can also reveal and optimize possible inadequacies in the process, it initially represents a considerable, often underestimated effort in the introduction of RPA. Finally, the application range of RPA still has limits. In principle, RPA is ideally suited for rule-based, standardized, and stable processes that follow clear if-then rules and process structured data. For more complex processes that require decisions or process unstructured data, RPA reaches its limits or proves to be unsuitable. This requires the combination of RPA with other digitization technologies, i.e. the use of SPA/IPA.

 Cf. Capgemini (2016), p 39.  Cf. Wenzel (2020), p 45. 39  Cf. on the disadvantages and limitations of RPA, for example, Taulli (2020) or Koch (2020). 40  Cf. Deloitte (2018), p 7. 37 38

14

2  Basics of Robotic Process Automation (RPA)

2.4 Central Terms in the Context of RPA Figure 2.3 lists key terms and their definitions that companies encounter when implementing RPA.

Explanation

Expression Attended Robots

So-called 'Attended Robots' are started by the user. After that, no active interaction of the user with the robot is necessary, unless the process requires it (e.g. user has to enter information or make an active decision). Attended robots usually run on the user desktop, which is why they are called Robotic Desktop Automation (RDA) instead of Robotic Process Automation (RPA).

Unattended Robots

So-called 'Unattended Robots' usually do not require active user interaction, but work in the background on central servers. There, the robots can be started, stopped, scheduled, audited, analyzed or monitored via a central monitoring and control center. The efficiency gains often associated with RPA are usually achieved with 'Unattended Robots'. This is another reason why many authors and practitioners only refer to 'Unattended Robots' as RPA.

BPM

Business Process Management and its methods deal with the analysis, design, optimization and implementation of operational business processes. Before processes are automated by means of RPA, BPM helps to standardize and optimize the processes to a greater extent (see also Section 3.2.2).

Structured data

Structured data refers to data that has a predefined structure and format. The standardized structure makes the data easy to process by machine (e.g. telephone numbers).

Semi-structured data

Semi-structured data does not have a predefined, but only a partial structure. I.e. the data contain again markers, with which the data can be assigned can be assigned or separated from each other. An example of semi-structured data is an e-mail. It has a basic structure (sender, recipient, subject, message), but the actual content is text, which in turn has no structure.

Unstructured data

Unstructured data has no predefined structure. Only the data type is known. Text files, presentations, videos, images are examples of unstructured data.

Operating Model

The operating model for RPA refers to the way in which the organization for RPA. The design of the (internal) organization depends both on the choice of the sourcing model (make-or-buy) and the phase of implementation (build vs. run phase). phase (build vs. run phase).

Governance

RPA Governance refers to specific behavioral guidelines and rules for RPA including the instruments for their enforcement.

IPA

Intelligent Process Automation (also called Smart Automation) refers to the combination of classic RPA with modern digitization technologies such as machine learning, predictive analytics, natural language generation or big data technologies. Data technologies.

Fig. 2.3  Central terms in the context of RPA

Literature

15

Literature Aguirre, S/Rodriguez, A (2017) Automation of a Business Process Using Robotic Process Automation (RPA): A Case Study, in: Figueroa-García JC, López-Santana ER, Villa-Ramírez JL, Ferro-Escobar R (eds) 4th Workshop on Engineering Applications, WEA 2017 Cartagena, Colombia, September 27–29, 2017 Proceedings, S 65–71 Bitkom (2018) Der Arbeitsmarkt für IT-Fachkräfte, retrieved on 15.05.2019 at: https://www.bitkom. org/sites/default/files/2018-­12/181213_Bitkom_Charts_PK_IT-­Fachkräfte_final.pdf Capgemini (2016) Robotic Process Automation – Robots conquer business processes in back office, retrieved on 15.05.2019 at: https://www.capgemini.com/consulting-­de/wp-­content/uploads/ sites/32/2017/08/robotic-­process-­automation-­study.pdf Czarnecki C, Auth G (2018) Prozessdigitalisierung durch Robotic Process Automation, in: Barton T, Müller C, Seel C (eds) Digitalisierung in Unternehmen – Von den theoretischen Ansätzen zur praktischen Umsetzung, 113–132, 1. Aufl. Springer. Wiesbaden Deloitte (2018) The robots are ready. Are you? retrieved on 18.03.2019 at: https://www2.deloitte. com/content/dam/Deloitte/tr/Documents/technology/deloitte-­robots-­are-­ready.pdf Forrester Research (2018) Harness RPA To Optimize Customer Outcomes, October 2018, retrieved on 01.03.2019 at: https://dfe.org.pl/wp-­content/uploads/2018/12/Forrester_Harness-­RPA.pdf Gartner (2018) Manage Robotic Process Automation, retrieved on 01.03.2019 at: https://www.gartner.com/en/finance/trends/robotic-­process-­automation Gartner (2019) Business Process Management Suites (BPMSs), retrieved on 01.03.2019 at: https:// www.gartner.com/it-­glossary/bpms-­business-­process-­management-­suite Gartner (2021) Robotic Process Automation Software, retrieved on 06.08.2021 at: https://www.gartner.com/en/informationtechnology/glossary/robotic-process-automation-software Horváth & Partners (2014) CFO-Studie 2014: Best Practices und Trends in Controlling und Finance, retrieved on 18.03.2019 at: https://www.horvath-­partners.com/fileadmin/horvath-­partners.com/ assets/05_Media_Center/ PDFs/deutsch/CFO-­Studie_2014_g.pdf IRPAAI (2019) Definition and Benefits, retrieved on 01.03.2019 at: http://irpaai.com/ definition-­and-­benefits/ Koch, C (2020) Robotic Process Automation: ein Leitfaden für Führungskräfte zur erfolgreichen Einführung und Betrieb von Software-Robots im Unternehmen, 1. Aufl. Springer Vieweg, Berlin KPMG und FhG FIT (2017) Digital Finance  – Ergebnisse einer empirischen Untersuchung zur Digitalisierung im Finanzbereich, Studie der KPMG und des Fraunhofer-Institut für Angewandte Informationstechnik FIT Lacity M, Willcocks L, Craig A (2015a) Robotic Process Automation at Telefónica O2, Paper 15/02, The Outsourcing Unit Working Research Paper Series, London School of Economics and Political Science Lacity M, Willcocks L, Craig A (2015b) Robotic Process Automation: Mature Capabilities in the Energy Sector, Paper 15/06, The Outsourcing Unit Working Research Paper Series, London School of Economics and Political Science Lacity M, Willcocks L (2016) A New Approach to Automating Services, in: MITSloan Management Review, Vol. 58, No. 1, 40–49 Lhuer X (2016) The next acronym you need to know about: RPA (robotic process automation), in: Digital Mckinsey, Ausgabe December 2016, 1–4 PWC (2017) Successful implementation of RPA takes time  – Lessons learnt by 18 of the largest Danish enterprises, retrieved on 18.03.2019 at: https://www.pwc.dk/da/services/2018/RPA-­ rapport-­engelsk.pdf PWC (2020) Robotic Process Automation (RPA) in der DACH-Region, retrieved on 01.03.2020 at: https://www.pwc.de/de/rechnungslegung/robotic-­process-­automation-­rpa-­in-­der-­dach-­region.pdf

16

2  Basics of Robotic Process Automation (RPA)

Scheer A-W (2017) Performancesteigerung durch Automatisierung von Geschäftsprozessen, 2. Aufl., AWS-Institut für digitale Produkte und Prozesse gGmbH Slaby JR (2012) Robotic automation emerges as a threat to traditional low-cost outsourcing, HfS Research, retrieved on 01.03.2019 at: https://www.horsesforsources.com/wp-­content/ uploads/2016/06/RS-­1210_Robotic-­automation-­emerges-­as-­a-­threat-­060516.pdf Swiss Post Solutions (2019) Reisekostenabrechnung per Robotic Process Automation, retrieved on 01.06.2019 at: https://www.swisspostsolutions.com/de/casestudydocument/sps_kundenreferenz_ deutschebahn_reisekosten-­app_transport.pdf Taulli, T (2020) The Robotic Process Automation Handbook, 1. Aufl. Apress. Berkeley Tröndle, R (2020) Robotic Process Automation  – die Magie der Governance, in: REthinking Finance, 03/2020, 59–64 UiPath (2021) UiPath StudioX, retrieved on 01.03.2021 at: https://www.uipath.com/de/ product/studiox UiPath (2021c) Automating Finance & Accounting, White Paper, retrieved on 01.03.2021 at: https:// www.uipath.com/solutions/whitepapers/rpa-­will-­transform-­finance-­accounting Wenzel, S (2020) Robotic Process Automation – das Altsystem von morgen oder doch Beschleuniger digitaler Transformation?, in: REthinking Finance, 03/2020, 43–48 Willcocks L, Lacity M, Craig A (2015) The IT Function and Robotic Process Automation, Paper 15/05, The Outsourcing Unit Working Research Paper Series, London School of Economics and Political Science Willcocks L, Lacity M (2016) Service Automation: Robots and the Future of Work, Steeve Brokes Publishing, Warwickshire Zeiss S, Jenesl P (2020) Robotic Process Automation als Enabler für Digitale Transformation – Ein Erfahrungsbericht der Telekom, in: REthinking Finance, 03/2020, 51–53

3

Introduction of RPA in Financial and Management Accounting

3.1 Phase Model for the Introduction of RPA 3.1.1 Proof-of-Concept as a Starting Point (PoC) The so-called Proof-of-Concept (PoC) is recommended as a starting point for the introduction of RPA. Put simply, a PoC is a pilot or lighthouse project. While some see the scope of pilot or lighthouse projects as somewhat larger than the PoC, others treat them as equal.1 In the following, we will equate the PoC with a pilot or lighthouse project for reasons of simplification.2 The PoC aims to use the first software robot(s) to test the functionality of the technology, to build up basic know-how about the technology, to build up acceptance and support (e.g. from management), and to prepare for the subsequent introduction. The PoC goes through a series of typical steps, which are illustrated in Fig. 3.1. The entire PoC takes a few weeks to a few months, depending on the resources used and the context. At the beginning of the PoC, the focus is also on coordination with management. This involves communicating the topic, releasing personnel resources, and approving a budget for the PoC. A project team is then put in charge to oversee the PoC. The team should consist of at least a project manager, an RPA expert or an employee with technical affinity for RPA, and a representative of the IT department. Since a software robot is developed for a department’s process in the PoC, the department or a department representative should be directly involved. Although not necessarily as a member of the project team, it may be advisable to present the project to employee representatives (works council, staff council, etc.) at this 1  On the distinction between PoC and pilot, see for example Leurs and Duggan (2018). Watkins (2009) and Pottruck (2014), for example, treat them as equal. 2  Cf. on this and on the following remarks above all Koch und Fedtke (2020), p 36 ff. and Helm et al. (2020), p 482.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2022 C. Langmann, D. Turi, Robotic Process Automation (RPA) - Digitization and Automation of Processes, https://doi.org/10.1007/978-3-658-38692-4_3

17

18

3  Introduction of RPA in Financial and Management Accounting

Reconciliation Management and Budget clarification

RPA vendor selection or Technology Partner

Selection process(es) for PoC Technical development of the robot based on PDD/DSD

User Acceptance Tests, functional, technical test

Optional: Vote Employee representative Set-Up Project Team for PoC

Go-Live and Stabilization

Creation of functional and technical process documentation, e.g. Process Design Document (PDD) and Development Specification Document (DSD)

Fig. 3.1  Procedure for Proof-of-Concept (PoC)/Pilots

early stage. Early involvement and transparency about the project reduce reservations and prejudices among the employee representatives, which in turn creates an initial basis for a later, comprehensive introduction. The technical RPA software used to develop the software robot can either be provided directly by an RPA software provider (see Sect. 3.3.2) or by a technology partner.3 If the existing, internal technical know-how is not sufficient for this, RPA providers or RPA technology partners can support the PoC with expert knowledge and development services. On the one hand, the PoC gains speed. On the other hand, valuable know-how can be built up internally. For use in the context of a PoC, i.e. not in productive operation, some RPA providers usually offer free licenses/versions of their RPA solution. Wien Energie, an Austrian energy company, for example, included an IT technology partner in its project team right from the start, in addition to the functional department (which plans to introduce RPA), the purchasing department, and the IT department.4 In terms of PoC, for example, the pharmaceutical company Merck reports that they gave the same process (automation of a daily sales report) to three RPA vendors and three technology partners/consultants in the sense of competition.5 In this regard, it should be noted that RPA vendors and RPA technology partners/consultants often provide support at the beginning (free of charge or for a small budget) to accompany or license the later, widespread introduction. For robotization in the PoC, it is recommended to select a process that has a certain scope, relevance, and possible reusability for the company. A process that is not considered  For example, AKOA, Roboyo, Weissenberg-Solutions, PwC, KPMG etc.  Cf. Schmelzer (2020), p 66. 5  Cf. Pellegrino and Mega (2020), p 35. 3 4

3.1 Phase Model for the Introduction of RPA

19

in day-to-day business and whose robotization does not generate any benefit is probably the wrong candidate for a PoC. On the other hand, the process must not be too complex in terms of the number of applications, variants, if-then rules, etc. The more stable and standardized the selected process is, the lower the development effort and the shorter the development time. In the next step, a process documentation is created by or with the department unit describing each step of the process at click level. This documentation is also referred to as Process Design Documentation (PDD) (see Sect. 3.2.2). Based on this, the Development Specification Document (DSD) and the subsequent development of the robot take place, which is subjected to testing. If the development already has the maturity level for productive use, the robot could actually go in production. If the focus of the PoC was only on feasibility, the decision on the introduction of RPA now follows (e.g. based on a cost-benefit assessment) as well as the revision of the previous steps from documentation to development for productive use.

3.1.2 Ramp-Up, Scale & Institutionalize and Mature & Innovate While the PoC focuses mainly on the technical feasibility or technical implementation, the next phases of RPA implementation also deal with the non-technical issues related to RPA (Fig.  3.2). When introducing RPA, it becomes clear very quickly that the technical implementation of software robots is the easy part.6 In addition to the creation of a PoC or pilot, the start phase can also include the selection of a suitable RPA platform or the selection of external partners to support the RPA implementation. The ramp-up phase is the first challenge for many companies. This phase involves the development of a process selection procedure for potential processes for robotization, the technical design of the RPA platform, and the creation of an initial version for RPA governance. The initial RPA operating model and necessary RPA roles are defined. In this phase, employees and managers should be informed about the company’s motives for RPA. The detailed elaboration of the RPA role model, the specific RPA governance, and the establishment of an RPA operating model is then the subject of the Scale & Institutionalize phase. In this phase, the focus is on scaling RPA and thus increasing the efficiency gains through the use of RPA. Processes are selected on the basis of a standardized and ready-­ to-­use process selection model (and, if necessary, through the use of process mining). This also includes process optimization prior to robotization. The technical extension by a monitoring and control component for the control of several robots takes place (at the latest) in this phase. Under certain circumstances, further software programs for the control of robots will be used. In this phase, it is advisable to set up a specific performance measurement for RPA in order to be able to measure the goals pursued with RPA.  Cf. Schmelzer (2020), p 68.

6

20

3  Introduction of RPA in Financial and Management Accounting

Number of robots/complexity of processes

Start (Proof-of-Concept) RPA Processes (Chapter 3.2)

Experiment' with first robots, employees build first own robots No systematic process selection for RPA Prookol concept (POC) using a known process as an example

RPA Vendor/ Architecture (Chapter 3.3)

RPA Roles (Chapter 3.4)

Compilation of requirement en RPA-Plattfons Software selection process of an RPA vendor and if necessary selection of an external partner

No activities

Start (Proof-of-Concept) RPA Governance (chapter 3.5)

Compliance with existing governance guidelines

Scale & Institutionalize

Ramp-Up Loading of a model for systemic process selection for RPA (e.g., determination of the rating criteria)

(Technical) set-up of the selected RPA platform together with IT, if necessary with an external partner Focus on development components (e.g., Studio) for modeling and developing individual robots

Review of existing role models in the company, in particular in IT and Finence Compilation of required RPA roles (without elaboration)

Mature & Innovate

Process selection for RPA (e.g. using a Swring model) Process optimization of potential processes for RPA Fixing of documentation requirements for RPA processes Focus on processes that process structured data

Confining selection of processes for robelling Pipeline management (e.g. selection, evaluation, decision) for upcoming processes incl. Workflaws

Continuous roll-out of development components (e.g. Studio) to multiple desktops, extension by monitoring and control center to control increasing number of robots

Establishment of an RPA library Linking the RPA solution - in the sense of Smart Process Automation (SPA) - with modern digitization technologies (e.g., NLP, NLG, machine leaming, analytics, OCR) in order to automate complex processes with unstructured data (see also Can. 3.3-3)

Additional software programs for monitoring and control of robots. such as Enate. Kibena (see also chapter 3.5.2) Elaboration and introduction of dedicated RPA roles

Ramp-Up

Extension of process selection to include processes in which unstructured data is processed using modern technologies (e.g., NLP, OCR) (see also chap. 3.3.3)

Link RPA roles with roles that support complementary digitization technologies (see also section 3.3.3), such as Data Scientist. Data Stewad

Scale & Institutionalize Further development of a dedicated RPA governance (considering existing governance guidelines)

Linkage or extension of the RPA governance to include governance guidelines for modern digitization technologies (see also section 3.3.3)

Selecting and setting up an operating model, which may still change as scaling progresses

Optimization of the operating model and the development approaches (e.g., expansion to include local hoarding)

Determination of future development approach for RPA (make vs. buy)

Reviewing and, if necessary, adjusting the development approach for RPA that has been followed so far (e.g., from Buy to Make)

Linking of RPA units (e.g., CoE) with units that have a modern digitization technologies (see also chap. 3.3.3), such as Data Science CoE

Review existing governance guidelines, esp. dedicated RPA governance Establishment of a first RPA-Govemance

RPA Operating Model (chapter 3.6)

Selection of an RPA project team for POC

Mature & Innovate

Listing of possible alternatives for the Operating Model Identification of potential RPA staff

Change Management (chapter 3.7)

No activities

Communication to managers and employees about the objectives and initial use of RPA in the company

RPA specific change management concept and associated measures

Change management of RPA to include the use of modern digital technologies (see also chap. 3.3.3)

RPA Performance Measurement (chapter 3.8)

No activities

No activities

Development and regular collection of specific RPA metrics

Ongoing collection of specific RPA metric

Fig. 3.2  Stage model for the introduction of RPA

In the last phase (Mature & Innovate), the transition from RPA to IPA takes place. RPA is extended by modern digitization technologies (e.g. NLP, machine learning) in order to be able to automate processes that process unstructured data (e.g. text, language) or involve complex issues (e.g. forecasts, analyses). As a result, the other categories need to be aligned with this. For example, the RPA roles should be expanded or linked with roles that support modern digitization technologies (e.g., Data Scientist). Further details on the different dimensions can be found in the following chapters.7

 The following chapters consider the respective dimension (e.g. processes, roles) holistically and therefore do not explicitly address the different phases again. 7

3.2 Selection of Suitable Processes for RPA

21

3.2 Selection of Suitable Processes for RPA 3.2.1 Selection Criteria for Processes Not all processes or sub-processes in financial and management accounting are suitable for transfer to RPA solutions. In research and practice, a number of selection criteria have been established that can be used to check the suitability of processes for RPA.8 In practice, however, the evaluation criteria are sometimes perceived as too diffuse, not differentiated enough, or too abstract.9 In the following, we present various selection criteria, which we have divided into three categories: (1) Minimum criteria, (2) Additional criteria, and (3) Specific criteria. The classification of the criteria into the three categories (and thus also the weighting of the criteria) is a subjective view based on our experience. Depending on the context, individual criteria can be assigned to other categories or the weighting can be chosen differently. Regardless of whether individual processes are better or worse suited for support by RPA on the basis of the criteria presented, it is important to check in advance whether the process can be automated better, faster, and cheaper in existing standard systems. Companies such as Union Investment or ProSiebenSat.1 examine this in advance.10

3.2.1.1 Minimum Criteria Robots expect rule-based processes, e.g. if-else. Rules in the process clearly specify which activities should be performed next for foreseeable decisions. So, if the robot does not find any figures in the system for the daily sales report, for example, it writes an email with an error message to the RPA user or to the process owner because the rules of the process stipulate this behavior. In addition to being rule-based, frequency is another minimum criterion for selecting processes for using RPA. The core question here is how often a process is run through. Due to the limited efficiency gains, processes that are only run through once a month are generally less suitable than processes that are run through daily or hourly. The next criterion that processes should meet for RPA is a high degree of standardization. Standardized processes follow a predefined sequence, are usually precisely documented, and have no unknown variations. Thus, the same process steps are always run through, whereby decisions in the process are handled with the help of fixed rules as mentioned above. This can lead to predictable variations in the process. Nevertheless, all process variations are standardized. This type of process is usually stable and has a high degree of maturity. In accounting, for example, the invoice receipt processing and verification process is usually highly standardized. Regardless of whether an incoming invoice  See AWS Institute (2019); Aguirre and Rodriguez (2017); Czarnecki and Auth (2018); Murdoch (2018) or King (2018) examples of the selection criteria below. 9  Cf. Plattfaut et al. (2020), p 1119. 10  Cf. Beisswenger et al. (2020), p 21; Tröndle (2020), p 62. 8

22

3  Introduction of RPA in Financial and Management Accounting

was successfully processed or errors occurred during processing, standardized processes offer a defined sequence of process steps to be performed for both variants. Another minimum criterion for transferring a process to RPA is the presence of electronically readable standard data types in the process. Specifically, electronic standard data types should be available, for example, formats such as CSV, XML, XLS, e-mail, or websites. This electronically available data usually contains structured (e.g. table) or semistructured data (e-mail). Non-electronically available data, such as printed documents (e.g. letters, invoices), on the other hand, must first be scanned (as native text PDF) and digitalized using Optical Character Recognition (OCR) or converted into (semi-)structured data before robots can process them. Since the robot works on the application level and operates the software programs involved in the process like a human user, RPA is flexible with regard to the integration of software programs (e.g. ERP, CRM). If in the invoice receipt process, the release of the invoice comes electronically via email, a robot can process this information and subsequently trigger a posting in SAP, for example. If the invoice is processed manually and approved by signature, it must first be digitized (scan, OCR) before the robot can process it further. Finally, the use of RPA is particularly suitable for processes that have a highly repetitive character. Repetitive processes repeat themselves, i.e. the same process steps are run through again and again. This criterion is to be evaluated independently of the frequency, which states that a process is performed regularly, but does not make any statement about the repetitive character of the process steps. The data collection of a reporting process, for example, often has a highly repetitive character and a fixed frequency. For a weekly sales report, the same process steps are performed every week: Extract figures from a system, transfer them to an Excel report, check their plausibility, convert them to PDF and send them to the recipient by e-mail.

3.2.1.2 Additional Criteria In order to robotize a process, the above-mentioned minimum criteria for processes should be correspondingly high. Additional criteria, on the other hand, are desirable but not absolutely necessary. The process volume is the first additional criterion. It is often also listed under the above minimum criteria. The development and operation of robots cause costs. In order to achieve a correspondingly high ROI, i.e. the investment and operation of RPA pays off, the processes to be robotized should have a correspondingly high volume. The logic behind this is that only through a high process volume does the use of RPA lead to a noticeable cost saving. However, this must be countered by the fact that the necessary investments and ongoing operating costs for RPA depend heavily on the respective provider, the selected license model, and the existing know-how in the company. If these are correspondingly low, even the transfer of processes with medium or low volumes could lead to a positive ROI in a short time. Another additional criterion for the use of robots is the complexity of calculations in the process. Software robots are particularly suitable for simple, less complex process

3.2 Selection of Suitable Processes for RPA

23

sequences. This does not mean, however, that robots cannot cope well with process sequences with complex decision rules and mathematical calculations. Rather, it means that process sequences with highly complex mathematical calculations (e.g. dynamic calculation methods, complex statistical calculations) greatly increase the development costs and duration of the development of a robot, while at the same time the performance and stability tend to decrease. The additional criterion of the number of exceptions in the process is similar. For each possible exception, a corresponding rule-based action instruction must be stored in the robot. As a result, the development costs and duration of the robot increase on the one hand, because all conceivable variants must be mapped. On the other hand, stability tends to decrease because there is a risk of not having all variants of exceptions coded in the robot. The fewer exceptions there are in the process, the more suitable the process is for transfer to a robot. Exceptions in the process often result in manual interventions. Therefore, manual interventions represent another additional criterion. Manual, human interventions in the process are, for example, additional checks, necessary approvals, or required additions that the robot needs from the user in order to continue processing the process. Ideal for RPA are processes that do not require any manual intervention, but are completely automated. Therefore, the more manual interventions are required, the lower the efficiency gains from using robots will be. As a result, manual interventions for processes to be automated should be limited to the most necessary. While the classic robot efficiently processes known decision points with predefined decisions, it cannot continue with unknown decision points or non-predefined decisions because it first requires an active decision from the user. This is where the weakness of classical RPA technology comes into play. Because without prior instructions on how a robot should behave in a precisely specified situation (e.g. copy cell only if content over 1000 EUR), the robot is incapable of acting. Although processes that require many decisions can in principle also be automated by using software robots, the development costs and duration also increase here, while the gain in efficiency tends to decrease. One remedy can be to combine RPA with more advanced technologies (Sect. 3.3.3). With an increasing number of software applications involved in a process, the efficiency gain through the use of RPA increases. Instead of human users working with different applications and losing valuable time each time by switching applications, a robot takes over the bridge between the applications and the repetitive activity therein. However, the increasing number of applications goes against the stability of a robot. The logic behind this is that the more applications are involved in the process, the more frequent changes or adjustments (e.g. updates) can occur in the applications. Even small, previously undetermined changes in applications (e.g. the sequence of fields) lead to an erroneous termination of the robot. According to this additional criterion, processes that access only a few software applications tend to be the most suitable for stable, error-free robots. This also leads to the recommendation not to transfer any processes to RPA whose participating systems will soon undergo technical adjustments or changes (e.g. new release, server move).

24

3  Introduction of RPA in Financial and Management Accounting

A similar relationship as with software applications can be observed with the number of users involved. This additional criterion states that with an increasing number of users involved in the process, the use of a robot seems to make less sense. Several users are usually involved in processes when several software applications are required or information or decisions are requested from several users. Both increase the complexity and reduce the stability of a process. Against this background, processes with few users involved are more suitable for transfer to robots than processes with many users involved.

3.2.1.3 Specific Criteria In addition to the described minimum criteria and additional criteria, two specific criteria in particular can positively or negatively favor the use of RPA. The first specific criterion for the selection of processes for RPA is multilingualism. Especially in an international environment it can happen that the applications, data, or user interaction used within a process are not only in English or German but in other languages (e.g. Italian, Spanish, French). RPA solutions and RPA developers are usually designed and prepared for an English language environment. If, on the other hand, the successful execution of the process (e.g. processing of numbers/texts, calling up applications) requires profound knowledge of another language, increased development, and operating costs are to be expected initially, since specialist translators have to be used. In the ongoing operation of the robot, maintenance also proves to be a challenge if, for example, a robot has an unforeseen termination and central applications are operated in a language other than English. The second specific criterion concerns the security risk of the process. Processes with a high risk of being affected by fraudulent activities are not ideal candidates for transfer to RPA. While robots reduce risks related to compliance and employee availability – robots are virtually 100% compliant – they increase IT risks, such as data security and access, and the pool of potential fraud threats.11For example, if payment instructions are instructed and approved by authorized employees in an ERP system, both the compliance of the corresponding employees and that of the associated support team for the ERP system must be ensured. If a robot is used in addition, the compliance of the RPA support must also be ensured, as well as the data security in the robot itself. 3.2.1.4 Scoring Model for Process Evaluation In order to systematically apply the selection criteria described above for the evaluation of processes, a so-called scoring model, also known as a point evaluation procedure, can be used. The specific scoring model for the evaluation of processes for RPA suitability comprises the following steps:

 Cf. Shared Services Working Group of the Schmalenbach-Gesellschaft für Betriebswirtschaft e.V. (2017), S 42. 11

3.2 Selection of Suitable Processes for RPA

25

1. Compilation of relevant evaluation criteria – All or a selection of the criteria described above from the categories minimum, additional, and specific criteria can be used as evaluation criteria for processes that are to be transferred to RPA. 2. Weighting of the individual criteria – The next step is to weigh the evaluation criteria. For this purpose, it is thinkable to assign 3 times the weight to the minimum criteria, 2 times the weight to the additional criteria, and 1 times the weight to the specific criteria. 3. Establish a rating scale – A uniform rating scale should be established for the evaluation criteria (e.g. 1–5 points), which applies equally to all criteria. Now it is evaluated how well a process fulfills the individual evaluation criteria. Ideally, descriptions of certain points (e.g. low, high, midpoint) of the rating scale are provided with specific examples. In their model, Plattfaut et al. (2020) show numerous examples for descriptors, specifically for rating scales in the context of RPA process selection.12 In the evaluation criterion frequency, for example, suitable descriptions could be: –– 1 point for ‘single execution’, –– 3 points for ‘monthly implementation’ and –– 5 points for ‘daily implementation’. In this way, the evaluation is based on concrete descriptions. This evaluation is recommended in a team in order to ensure multiple perspectives on the evaluation. 4. Determination of the weighted score (‘automation value RPA’) – For each process, the weighted score is now determined, which is composed of the proficiency of each evaluation criterion and its weighting. Figure 3.3 shows an example of a scoring model for three financial and management accounting processes based on the criteria presented above. In addition to the scoring model, in which processes are evaluated on the basis of various (objective and subjective) criteria, process mining can be used (as a supplement or alternative) for process selection. Process mining uses event data to analyze the actual process flow in order to identify stable processes with a high degree of standardization and high volume (see Chap. 4).13 In addition to the calculation of the ‘automation value RPA’ via the scoring model (or via a process mining approach), the current costs and thus the potential cost savings play a decisive role in the decision to automate a process using RPA. Examples from corporate practice (e.g. ProSiebenSat.1, Deutsche Telekom, Merck, or Union Investment) show that a cost-benefit analysis in the sense of a profitability calculation is an integral part of

12 13

 Cf. Plattfaut et al. (2020), p 1122 f.  Cf. van der Aalst (2012); van der Aalst (2016).

26

3  Introduction of RPA in Financial and Management Accounting

Processes Weighted point value ('automation value RPA')

FI-/COFI-/COFI-/COProcesses 1 Processes 2 Processes 3 90

79

Degree of rule-basedness

2

2

1

Degree of standardization

4

3

3

Minimum criteria (3-fold weight) Frequency

Standardized data types Degree of repetition

83 Scale 1-5

3 5 5

3 3 5

2 5 3 Scale 1-5

Additional criteria (2-fold weight) Extent of the process volume

2

1

1

Number of exceptions

2

1

1

Degree of complexity of calculations Number of applications used Number of decision points

Number of manual interventions Number of users involved

2 3 2 1 2

1 3 1 5 1

Specific criteria (1-fold weight) Number of languages used Expression of the security risk

1 3 4 4 4 Scale 1-5

1 4

1 4

1 4

Fig. 3.3  Scoring model for RPA process selection

assessing the use of RPA for new processes.14 The potential cost savings often represent capacities tied up in the process which are freed up by using RPA. Capacities are then usually converted into time (e.g. hours) or monetary values (e.g. EUR). With the help of the two dimensions ‘automation value’ and ‘potential capacity savings’, a matrix can be drawn up in which the potential processes can be plotted and then – depending on the location of the process – corresponding recommendations for action can be derived (Fig. 3.4). The first quadrant contains processes with a low capacity commitment and low automation value. These processes, classified as ‘non-relevant’, are hardly suitable for a transfer to RPA solutions from a technical and commercial perspective. We refer to processes in the 2nd and 3rd quadrants as ‘RPA Selectives’. These include processes that are potentially suitable for mapping into RPA. For processes in the 2nd quadrant, however, the question is whether the capacity savings are sufficiently high enough to justify the use of robots. The level of capacity savings at which the use of robots appears to make sense also depends on the development and operating costs of the selected RPA

14  See Beisswenger et al. (2020), p 19; Helm et al. (2020), p 478; Pellegrino and Mega (2020), p 34; Tröndle (2020), p 62; Zeiss and Jenesl (2020), p 51.

3.2 Selection of Suitable Processes for RPA

27

'Degree of automation' (points)

High

4.RPA-Favorites

2.RPA-Selectives

Medium

?

3.RPA-Selectives

1.Non-Relevant Low

Low

Medium

High

Potential Capacity savings'

Fig. 3.4  Matrix automation value and capacity savings

solution. According to surveys, the majority of the development costs for a robot (design, coding, licenses, implementation, etc.) are in the range of approximately 25,000–100,000 USD, while the annual operating costs (maintenance, licenses, etc.) are mostly below 25,000 USD.15 If the expected capacity savings through the use of the robot are rather small (e.g. only a few minutes) despite the high automation value, the investment is unlikely to pay off from a purely financial point of view. Reports from the field show that companies sometimes demand values of 0.1–0.4 FTE in capacity savings for the development and operation of new software robots, depending on the company’s level of experience with RPA.16 Processes in the 3rd quadrant, which we also refer to as ‘RPA selectives’, exhibit high potential capacity savings, but currently still have a rather low automation value. The automation value of these processes should therefore be increased through suitable process optimizations (e.g. by increasing the degree of standardization) which might move the processes into the 4th quadrant of the matrix. Suitable approaches for process optimization are explained in more detail in the following section. Finally, the 4th quadrant includes processes that have both high automation value and high potential capacity savings. Since these processes are ideally suited for automation using RPA, we refer to these processes as ‘RPA favorites’. 15 16

 Cf. Forrester Research (2018), p 7.  Cf. Biel (2021), p 15.

28

3  Introduction of RPA in Financial and Management Accounting

My Process Is constant (i.e., no frequent changes in process) Is mature (i.e., is documented and sufficient process experience exists) Is standardized (i.e., can be applied to different sites, for example) Is structured and rule-based (i.e., there are clear guidelines and procedures) Involves routine tasks (e.g., copy and paste between systems) Repeats frequently (e.g., every week or every hour) Has digital input and output sources (e.g., Excel spreadsheets, SAP, etc.) Causes a high expenditure of time

Fig. 3.5  Checklist for selecting the processes to be automated in RPA at the MANN+HUMMEL Group. (Cf. Hermann et al. 2018, p 33)

3.2.1.5 Examples of Selection Criteria from Practice This section concludes with some practical company examples of criteria used to select processes for RPA. For example, Fig. 3.5 shows a checklist used by the MANN+HUMMEL Group to determine which processes in the area of Finance & Controlling can be automated with RPA. For each process, the time required for the (manual) execution of the process is also recorded. The more manual hours the process requires, the higher the achievable return on investment through the use of RPA. MANN+HUMMEL reports an annual return of 30%, which corresponds to a payback period of about 3 years. In order to achieve high automation returns, the MANN+HUMMEL Group initially focuses its RPA deployment on highly standardized and transactional processes (e.g. accounts payable and accounts receivable).17 Another example comes from the pharmaceutical company Merck. Figure 3.6 shows the questionnaire with 12 questions that the company initially sent to team leaders and process experts to evaluate their financial processes with regard to their suitability for RPA. The results were discussed in subsequent workshops (600 processes in 80 h). This identified process candidates with high automation potential, which were later analyzed step-by-step in deep-dive meetings on the screen. Here, the processes were not only examined in terms of their suitability for RPA, but also initially with regard to the potential for eliminating the process (“Is the process really necessary?”), for standardization (“Is the process performed in the same way in other teams or locations? “) and for automation with existing systems (“Can we automate the process with existing systems?”). Only then did RPA prove suitable as an automation solution for the process. Finally, they examined whether traditional RPA or IPA was more suitable for the process (“Does the process require understanding unstructured content?”). The prioritization of the processes was based on a cost-benefit matrix.18

 Cf. Hermann et al. (2018), p 30 f.  Cf. Pellegrino and Mega (2020), p 36 f.

17 18

3.2 Selection of Suitable Processes for RPA

29

Questionnaire for Fast Process Assessment

1

Is the process supported by digital data, initiated and managed in digital systems?

7

Does the Process have Low exceptions rate?

2

Is the process documented to Level 5 and fully optimized?

8

Does the process have high transaction volume?

3

Is the process highly manual and repetitive work?

9

Does the process have handoffs?

4

Is the process rule based?

10

How low is the potential for human error?

5

Does the process have electronically readable input types?

11

Is the process not dependent on any human judgments?

6

Does the process have standard input types?

12

Does the process have seasonal or unpredictable peaks?

Fig. 3.6  Questionnaire for determining the RPA automation potential of processes at Merck. (Cf. Pellegrino and Mega 2020, p 36) Suitable processes for RPA have the following characteristics

o Routine: Monotonous digital processes o Standardized: No/few deviations, well-structured o High transaction volume: regular, time-critical and/or frequent execution

o High process maturity: few exceptions and rule-based o Cross-application: interfaces to other programs are not present

Fig. 3.7  Properties of suitable processes for RPA at Wien Energie. (Cf. Schmelzer 2020, p 36)

Figure 3.7 shows the test criteria for processes of Wien Energie with which processes were selected for the pilot phase of RPA. The characteristic ‘cross-application’ stands out, i.e. several applications are involved in the process execution, between which there is no interface. Based on these considerations, Wien Energie selected the following four processes for its pilot phase in which RPA was to be used: (1) Pulling electronic invoices from the document archive to FI documents from SAP (ad hoc evaluation), (2) e-mail filing of a specialist department (mass process), (3) database maintenance of procurement transactions (periodic), (4) order extensions of existing orders (periodic). Finally, Fig. 3.8 shows the PEPA model of Plattfaut et al. (2020), a process selection model that the authors developed together with a medium-sized company from the metal processing industry. Many of the criteria included there are also included in the models presented above, such as standardization, frequency, or stability. The process selection, which is structured as a scoring model, additionally provides a weighting of the criteria.

30

3  Introduction of RPA in Financial and Management Accounting

Criterion

Rating scale 1

Exclusion criterion

2

3

4

5

Process type

Decision-based

Rule-based

Data source

Unstructured and analog

Structured and digital

Low

High

Automation effort in other systems

1

Quality factor

2

3

4

5

Data type

Image recognition

Number based

Stability

Frequent updates

Few changes

Standardization

Low

High

Risk

High

Strengthening criterion Complexity

Low

1

2

3

4

5

Complex

Simple

Error-proneness (man. processing)

Low

High

Involved applications & systems

Few

Many

1

Economic impact

2

3

4

5

Processing time

Low

High

Case frequency

Rarely

Often

Fig. 3.8  Selection interface of the PEPA model for selecting suitable processes for RPA. (Cf. Plattfaut et al. 2020, p 1124)

The evaluation of the individual criteria is based on supplementary descriptions and scaling (see also Sect. 3.2.1.4). In the end, the model produces an overall result for each process which is the basis for process prioritization.19

3.2.2 Process Optimization Before Automation As already briefly mentioned above, the automation of processes with robots requires detailed process documentation. However, even if process documentations are available, processes in reality often deviate significantly from the documented steps. Therefore, understanding, documenting, and analyzing the ‘real’ processes is one of the key challenges and at the same time represents a central prerequisite for the successful implementation of RPA.20 Process mining can help to determine and model the actual process flow based on event or log data in systems.21

 Cf. Plattfaut et al. (2020), p 1119ff.  Cf. Deloitte (2018), p 14. 21  Cf. van der Aalst (2012); van der Aalst (2016). 19 20

3.2 Selection of Suitable Processes for RPA

31

However, a direct transfer of precisely documented processes or sub-processes to a robot is neither effective nor efficient. The goal is not, as Deutsche Telekom describes it, to automate existing processes 1:1 using RPA.22 Even if processes meet the criteria presented in Sect. 3.2.1, their optimization potential should be examined. The complexity of a process drives the complexity of the associated software robot, which in turn increases the costs for development and maintenance for the robot. Efficiency gains are thus smaller. Thorsten Dirks, former CEO of Telefónica Deutschland, once said in the context of digitalization and automation of processes: If you digitize a crap process, then you have a crap digital process23

Automating non-optimized processes with robots carries the risk that the process and thus the robot will not run stably. Thus, process optimization also contributes to subsequent process stability. In summary, the following principle applies: process optimization before automation. Figure 3.9 shows the ideal procedure for optimizing a process before transferring it to a robot. Step 1 represents the selection of suitable processes for RPA as discussed in Sect. 3.2.1. Steps 2 and 3 contain the actual process optimization, the contents of which are 1 Selection of suitable processes for RPA Compilation and weighting of relevant evaluation criteria for potential processes Evaluation of potential processes on the basis of a uniform scale Prioritization of suitable processes as a basis for process analysis (see step 2)

3

2 Process documentation If not available, documentation of the selected process Including all sub- and sub-processes down to the level of the individual keystrokes/clicks (keystroke level) For the documentation can be used for example Swi m-Lane diagrams or Process flow diagrams with responsibilities and system applications

Process analysis and optimization Establish process understanding through exchange with process owners Testing and iterative application of optimization measures (e.g. Elimination of activities, change of sequence) Redesign the process with the aim of reducing complexity and standardization Checking whether automation of individual process steps is possible through existing system applications (e.g. SAP Workflow)

4

Process implementation & robotization Together with process owners, the Technical implementation (development, testing etc.), eitherin existing systems or in RPA solution for entire process or individual process steps Functional implementation in terms of documentation and roll-out of the new process to all participants

Fig. 3.9  Procedure for process optimization in the context of RPA (simplified)

22 23

 Cf. Zeiss and Jenesl (2020), p 51.  Süddeutsche Zeitung (2018) (translated from German).

32

3  Introduction of RPA in Financial and Management Accounting

based on business process management (BPM), business process optimization, and business process reengineering (BPR).24 Once suitable processes have been identified for transfer to robots, step 2 involves detailed a process documentation (also known as process design documentation PDD). Since this is usually not available, a detailed process documentation must be created at click (keystroke) level. It is crucial that the real, lived process steps are documented. Swim lane diagrams, for example, in which responsibilities and system applications are integrated, are a starting point. Screenshots or video screen recordings (e.g. via Adobe Captivate or SAP Enable Now) of the executed process are a good basis for the developer.25 For a full picture of process, further information26 is to be obtained: • • • •

Costs of the process (e.g. what costs are incurred at which process step?), Capacities in the process (e.g. can the process be carried out with less capacity?), Variants of the process (e.g. are variants necessary or desired?), Bottlenecks in the process (e.g. are there bottlenecks due to interfaces, lack of information, etc.?), • Rules of the process (e.g. are current rules hindering the process?) or • Exceptions to the process (e.g. which exceptions to the process are conceivable?) Step 3 then involves process analysis and optimization. The prerequisite for this is a deep understanding of the process, which is created both through the process documentation created in step 2 and through a close exchange with those responsible for the process. Only through a deep process understanding can processes be significantly improved. In this phase, the search for optimization potentials begins. For this purpose, process mining can be used again, which identifies the deviations of the actual process flow from the target flow and thus provides indications of optimization potentials (see Chap. 4).27 The optimization potentials found should first be discussed and critically scrutinized. At Deutsche Post DHL, for example, the process is examined at the beginning of each RPA initiative with regard to standardization and optimization potential.28 Measures for standardization and optimization include for example (see also Fig. 3.10) • the elimination of unnecessary process steps or variants, • the parallelization of process steps, • the change of the sequence of individual steps with the aim of low media changes and avoidance of idle times or • the consolidation of process steps.  See Gadatsch (2017); Bleicher (1991); Gaitanides (2012); Hammer and Champy (2003).  Cf. Murdoch (2018), p 54. 26  Cf. inter alia European Association of Business Process Management (2009) (ed.), p. 94 ff. 27  Cf. van der Aalst (2012); van der Aalst (2016). 28  Cf. Wenzel (2020), p 45. 24

25

3.2 Selection of Suitable Processes for RPA

33

Explanation

Sketch

Concept 1. Omit

2 1

Verify necessity of processes or sub-processes to fulfill function

3 4

2. Removing

2 1

5

Outsourcing of sub-processes or complete processes to external specialized service providers (e.g., accounting to tax consultants)

3 4

3. Summarize

Elimination of media discontinuities Eliminate approval steps that do not make sense

5

Process steps are combined in such a way that one processor carries out related steps completely without a change of processor (e.g., simultaneous data deduction and plausibility check in the monthly report)

2+3 1

4

4. Parallelize

5

Increase in the division of labor in the case of sub-steps that can be carried out in parallel (e.g. preparation of the sub-reports for the monthly report by different controllers)

2 1

3

5

4 5. Shift

2

3

1 6. Accelerate

4

5

17

4

1

8. Supplement

2

3

4

5

2 1

Elimination of loops in processes, i.e. no repetition of sub-steps of a process

6

3 4

5

Shifting process steps, for example, to bring tasks forward without becoming a bottleneck later (e.g., complete deduction of data for monthly report)

Use of time-saving tools (reporting tool replaces Excel) Reduction of waiting and idle time by increasing capacity

4

Dauer

7. No loops

17

6

Supplementing process steps with the aim of adding downstream additional processes for "damage repair" (e.g. supplementing a quality control)

Fig. 3.10  Optimization approaches for processes8

In practice, before even standardization and optimization is taken into consideration, the question is often asked whether the process can be completely eliminated. Both Union Investment and Merck, for example, put this question first when selecting processes for RPA. Only then does the optimization or further standardization of the process take place

34 Fig. 3.11  EORA model as procedure model for process selection for RPA at Union Investment. (Cf. Tröndle 2020, p 61 f)

3  Introduction of RPA in Financial and Management Accounting

ELIMINATE Can the process be eliminated?

OPTIMIZE

What measures are available for optimization?

AUTOMATE

What automation approaches are there for the process?

ROBOTIZE

How can I use RPA?

(see also Fig.  3.11).29 The goal here is to reduce the complexity of the process and to achieve maximum standardization of the process, with as few exceptions and variations as possible. The transition to this redesign of the process is fluid. In iterative loops, the improvement measures are applied to the process and discussed. It is important to consider how the improvement measures affect the quality, time, and cost of the process. It may well be that the process throughput time is reduced by eliminating individual activities, but at the same time the process quality decreases. In some cases, the improvement measures applied may already improve the process to such an extent (e.g. in terms of error rate, throughput time, or quality) that the efficiency gain from subsequent IT automation could be marginal. Thus, not every process that meets the criteria for RPA (Sect. 3.2.1) necessarily ends in IT automation. But if so, the next question is whether and which process steps can be automated by IT. At the beginning, one must check whether existing systems/applications (e.g. core systems, workflow systems) or a new interface are suitable. Automation via existing systems/applications may only incur low costs and is particularly suitable if the entire process runs within one system or application. In addition, the automation in the existing system itself or via interfaces, if further systems are involved, usually leads to more stable IT automations. However, if several systems or applications are affected, the existing systems or interfaces are not suitable for automation or the costs are too high, the use of RPA is a good option. Step 4 is the process implementation. The implementation includes the update of the process documentation, the distribution to all persons involved in the process, and, in the case of more complex processes (or their adaptation), also training. The technical implementation for processes that are automated via existing systems or applications or RPA includes the technical development (e.g. programming), tests, and integration into the  Cf. Pellegrino and Mega (2020), p 36; Tröndle (2020), p 61.

29

3.2 Selection of Suitable Processes for RPA Main process

Sub-processes

Strategic planning

Strategic analysis

Operational planning, budgeting Forecast Cost accounting

35

Audit/adjustment of business model

Definition of objectives and measures

Specify/communicate premises & top-down goals

Preparation of individual plans & budgets

Summary & consolidation of individual plans

Identification of a data basis for the forecast

Comparison of the data basis with the previous forecast or plan/budget

Definition & maintenance of master data

Audit/ adjustment vision, Values

Cost element and cost center accounting

Offer /order plan calculation

Management Reporting

Management of the reporting system and data process

Project and investment controlling

Planning the project/ investments

Support approval procedure

Risk management

Identification & classification of risks

Analysis & evaluation of risks

Functional controlling

Strategic planning

Operational planning

= Strongly affected

Reporting (figure selection)

Creation of investment reports

Individual risk/overall risk options

Cost accounting

Evaluation of the strategy

Monitoring of strategy implementation

Coordination of strategy

Communication of the strategy

Checking/ adjustment of planning results

Presentation & approval of the planning

Development of countermeasures

Tracking- & post-calculation

Approval of the forecast

Period profit & loss statement

Period-end closing of cost accounting

Deviation analysis

Reporting (deviation analysis and comment)

Evaluation by management & initiation of measures

Creation of decision documents

Post calculation and final report

Derive & track risk measures

Creation of a risk report

Project evaluation

Coordination and communication

= Moderately affected

Reporting

= Slightly/weakly affected

Fig. 3.12  RPA heat map for management accounting processes12

ongoing operation. In the case of a first-time introduction of RPA, issues such as the choice of the RPA solution (Sect. 3.3), necessary RPA roles (Sect. 3.4), governance (Sect. 3.5), or the operating model for RPA (Sect. 3.6) need to be clarified. These dimensions are discussed throughout the next chapters.

3.2.3 RPA-Heatmaps for Central Processes in Financial and Management Accounting Financial and management accounting are dominated by a number of central processes. A good overview is provided, for example, by the International Group of Controlling (2017) and Horváth & Partners (2015).30 The central management accounting processes listed there include management reporting, operational planning (budgeting), forecasting, and cost accounting. Central processes in accounting are, for example, accounts receivable, accounts payable, final payment and travel expense accounting, or general ledger and asset accounting. For the listed processes in financial and management accounting, the question arises as to how well they are suited for transfer to RPA solutions. Not all processes are equally suitable. Rather, even within a process, the individual sub-process steps are suitable to varying degrees. So-called ‘heat maps’, which we will refer to as RPA heat maps in relation to RPA, are useful for a clear, graphical representation of these relationships. 30   Cf. International Group of Controlling (2017) and Horváth & Partners Management Consultants (2015).

36 Main process

3  Introduction of RPA in Financial and Management Accounting Subprocesses

Accounts receivable

Maintain customer master data (create, maintain, validate)

Accounts payable

Maintain vendor master data (create, maintain, validate)

Remuneration and Travel Expenses

Maintain employee master data (person accounts) (create, maintain, validate)

Asset accounting

Maintain asset master data (create, maintain, validate)

General ledger

Maintain master data (create, maintain, validate)

Make postings in the general ledger

Consolidated Financial Statements

Maintain master data (create, maintain, validate)

Collect, validate and release data

Steer

Create and maintain tax master data

Treasury

Determine treasury structures and principles

Record and evaluate performance

Read out, process, and archive invoices

Manage incoming payments

Post asset acquisition

Validate intercompany issues

Payment transactions and cash management

Value adjustment, adjustment or closing entries carry out

Manage open items and initiate payment

Analyze accounts

Prepare and execute tax declaration Manage financial risk

Support inventory

Perform closing activities

Perform consolidation steps

Prepare required notes

Make adjustment and closing entries

Trigger payment run and account reconciliation and archive

Post payroll

Valuate assets and execute depreciation run

Balance accounts

Run. Calculate Calculate and and post taxes post lat. taxes

Dun open items

Check invoice and assign to account

Process, check, and post travel expense reports

Post asset acquisition

Identify recognition and valuation differences between HB and StB

= Strongly affected

Create and send invoice

Validate consolidated financial statements Determine Determine and sales tax track tax risks Planning and managing liquidity

= Medium affected

Perform period-end closing Prepare consolidated financial statements (incl. Group management report) Consider special circumstances

Prepare e-balance sheet according to taxonomy

Carry out financing = Slightly/weakly affected

Fig. 3.13  RPA heat map for financial accounting processes

Figure 3.12 shows the RPA heat map for the central management accounting processes, i.e. how well the individual sub-processes in management accounting are suited for the transfer to RPA.31 Fig. 3.13 shows the same for the financial accounting sub-processes. In other words, the two RPA heatmaps show to what extent the individual sub-processes in financial and management accounting are affected by the introduction of RPA. Conceptually, the RPA heat maps are based on the consideration of how strongly the respective sub-process fulfils the evaluation criteria listed in Sect. 3.2.1. In the management accounting process of management reporting, for example, the sub-process steps ‘Management of the reporting system and data process’ and ‘Reporting (numerical part)’ are standardized in most companies, have a repetitive character, and are performed correspondingly frequently. Among other criteria, these are indications that the two sub-­process steps are well suited for transfer to RPA. Previous studies and case studies support the assessment presented in the RPA head maps.32 However, a process may look completely different in a specific individual case. For example, there are management reporting processes that are not standardized or are rarely performed. A look at the RPA heat map for financial accounting shows that sub-processes in accounts receivable and accounts payable, payroll and travel expense accounting, as well as fixed asset and general ledger accounting are particularly well suited for robotization. At the KION Group, a worldwide leading intralogistics provider for supply chain solutions, for example, robots are used to maintain the goods receipt/invoice receipt clearing account (general ledger), to create invoices (accounts receivable), or to approve invoices

31 32

 For Fig. 3.11, see Isensee et al. (2018), p 5; Wenning and Przytulla (2020), p 11.  See, for example, UiPath (2021c); PWC (2018); Isensee et al. (2018).

3.3 RPA Vendors and Architecture

37

(accounts receivable).33 Robert Köthner, Chief Accounting Officer at Daimler AG also gives an example of the use of RPA in accounting: Our current use cases for Robotic Process Automation (RPA) in the SSCs are [...] to deduct closing entries, to generate bulk entries, to replace many previously manual activities for month-end closing.34

The central processes in financial accounting are therefore fundamentally more suitable for transfer to automation technologies such as RPA than the processes in management accounting due to their higher degree of standardization combined with clear if-then rules, their repetitive character, and their usually higher volumes.35 It is therefore not surprising that many practical examples come primarily from financial accounting.36Against this background, it can also be explained that finance managers in a recent study expect financial accounting processes to be almost completely automated (96%) in 5–10 years, while the degree of automation is estimated to be lower for other processes in the finance area.37

3.3 RPA Vendors and Architecture 3.3.1 Structure of an RPA Architecture The structure of an RPA architecture differs in detail from provider to provider, but the architectures of the various providers have a comparable basic architecture, which consists of three simplified components (Fig. 3.14): A developer component, the actual software robot, and a monitoring and control component. Depending on the respective RPA provider, the naming of the components differs (Fig. 3.15).38 The developer component is an application that is used to design and develop the processes to be automated or the associated robots. With many providers, little programming knowledge is required for this. Instead, the individual process steps of the robot can be modeled from hundreds of pre-structured activities or components (e.g. reading and writing in databases or Excel files, logging into ERP systems, performing calculations, or opening and processing e-mails) using drag-and-drop. Process-specific parameters per activity (e.g. file names, fields, user names) can be conveniently defined directly in activity windows. The graphical modeling of a process is – to a certain extent – comparable to

 Cf. Beisswenger et al. (2020), p 22.  PWC (2018), p 22 (translated from German). 35  Cf. also Langmann (2021). 36  Cf. Obermeier (2020), p 31 f. 37  Cf. KPMG and FhG FIT (2017), p 23. 38  See Tripathi (2018); Ying (2018); Automation Anywhere (2018) for examples of naming UiPath, Blue Prism, and Automation Anywhere. 33 34

38

3  Introduction of RPA in Financial and Management Accounting

Monitoring/ControI component

Test environment

Development environment

Robot(s)

Productive environment

Developer component

Fig. 3.14  Exemplary RPA architecture

Developer component Monitoring/ControII component

UiPath

Automation Anywhere

Blue Prism

Studio

Bot Creator

Object/Process Studio

Orchestrator

Control Room

Control Room

Fig. 3.15  Overview of the naming of the central RPA components using the example of UiPath, Automation Anywhere, and Blue Prism

Microsoft Visio (e.g. start, end, decision). Figures 3.16, 3.17, and 3.18 show examples of the developer components of UiPath, Blue Prism, and Automation Anywhere. In addition to graphical modeling, users with programming skills can also code the process directly (e.g., based on C#, VisualBasic). Some RPA providers offer their developer components in different versions or characteristics, depending on whether the user has the profile of an RPA developer or a so-called citizen developer (Sect. 3.4.2). The version for the latter then takes over even the simplest basic programming processes, such as the creation of variables.39 The result of the modeling in the developer component is a software robot. The robot can be hosted either on a single desktop or on a central server. Robots that are hosted on individual desktops and controlled by the user are strictly speaking RDAs (also called attended robots or front-office robots, see Sect. 2.1), not RPAs. As explained earlier, these robots are comparable to a macro script. Classical RPA software robots, on the other hand, which are centrally controlled and work independently, usually run on a central server and represent RPA in the true sense (also called unattended robots or back-office robots). The robot is not limited to the applications of one desktop, but can access existing applications company-wide. Regardless of whether the robot runs on a central server or an individual  Cf. Uipath (2021).

39

3.3 RPA Vendors and Architecture

39

Fig. 3.16  Modeling a process in UiPath Studio

Fig. 3.17  Modeling a process with Blue Prism Process Studio

desktop, it usually accesses the application level and not the data storage or data processing level, although this is possible. In the monitoring and control component, robots can be centrally controlled, monitored, scheduled (e,g. management of queues). In addition, reports and logs about the speed, the exact accesses (so-called audit trails), and the errors/exceptions per robot can be called up. Versioning of the robots used or the central creation of a so-called robot library/ repository is also possible. In the latter case, individual robots or standardized modules are

40

3  Introduction of RPA in Financial and Management Accounting

Fig. 3.18  Modeling a process with Automation Anywhere

managed centrally, which can be used repeatedly in several processes and thus save development effort. As shown in Fig. 3.14, a development, test, and productive environment should be set up for the RPA architecture with different landscapes. ECE, the European market leader in the management of shopping centers, also uses such a three-tier RPA architecture for its RPA program.40 The three-tier environment architecture guarantees the testability and traceability of developments and ensures that the productive environment runs stably and securely, since customizing and code changes do not immediately affect the productive environment.41

3.3.2 Overview of Leading RPA Vendors Today, there are a large number of RPA providers on the market.42 Market research firms such as Forrester Research and Gartner have for years identified UiPath, Automation Anywhere, and Blue Prism as the leading RPA vendors.43 Nevertheless, the market has been consolidating for some time and the positions of leading vendors in the market seem to be moving as a result.44 In the latest edition of the so-called Forrester Wave from

 Cf. Petersen and Schröder (2020), p 1135ff.  Cf. Roth-Dietrich (2018), p 68. 42  For an overview, see for example Gartner (2017). 43  The current Forrester Report or Gartner Quadrant can be found at UiPath (2021a) and UiPath (2021b). For the leading RPA vendors, see also King (2018), p 90. 44  The trend towards consolidation in the RPA market is already evident in the example of the takeover of Softomotive by Microsoft or Another Monday by Hyland. Cf. Hyland (2020) and Microsoft (2020). 40 41

3.3 RPA Vendors and Architecture RPA-Provider Headquarters Year of foundation Operation

41

UiPath

Blue Prism

Automation Anywhere

New York (US)

Warrington (UK)

San Jose (US)

2005

2001

2003

Drag&Drop functionalities, Workflow-oriented interface

Drag&Drop functionalities, Workflow-oriented interface

Drag&Drop functionalities, Workflow-oriented interface

(Desktop) Recording

Yes

Yes

Yes

Desktop Automation (RDA) Trial version

Yes

Via trust portal partnership

Yes

60 days trial version + Free Community Edition for small companies, developers and students

30 days trial version

30 days trial version + Free Community Edition for small companies, developers and students

Official training and certificate programme available free of charge

Official certificate programme, Training via partner

Arvato Bertelsmann, Linde, BASF, Siemens, GE

O2, Siemens, Lufthansa, Fujitsu etc.

Official training and certificate programme either available free of charge or at a reduced price Siemens, Lilly, Symantec, Bouygues etc.

Training

References (examples)

Fig. 3.19  Overview of leading RPA providers (as of March 2021)

Forrester Research, Microsoft has moved into the category of the leading providers (‘Leaders’), while Blue Prism was rated ‘only’ as ‘Strong Performer’.45 In order to get a first impression of the solutions of various providers, the RPA solutions of UiPath, Automation Anywhere, and Blue Prism are presented and compared below on the basis of individual elements.46 For a more detailed introduction to the operation of these RPA solutions, please refer to Ying (2018) or Tripathi (2018) as examples. At this point, it should be explicitly pointed out that the comparison does not claim to be complete. For a professional selection of a suitable RPA solution, interested companies should rather refer to a specific criteria catalog that represents an integral part of a software selection process. Figure 3.19 shows the characteristics of selected elements for the three leading providers of RPA solutions. Although the providers still differ on a number of elements, they have nevertheless converged in recent years. While UiPath and Blue Prism relied on a visually-­oriented user interface from the very beginning, Automation Anywhere initially resorted to a somewhat more technically-oriented interface. In the meantime, however, a visually-­oriented user interface has also become established there. There are also differences in the availability of so-called recorders. Recorders are used to record a user’s 45  Cf. on Microsoft’s position, for example, Whitaker (2021); on Microsoft’s position and Blue Prism’s position, cf. the current Forrester Wave Q1 2021, available at UiPath (2021a). 46  For the comparison of the three providers, the websites (www.uipath.com, www.blueprism.com, www.automationanywhere.com) were consulted, the authors’ own experiences were included, and findings from conversations with other users were taken into account. The comparison of the RPA providers is not accompanied by any recommendation by the authors, nor is there any claim to completeness or conclusive accuracy of the information.

42

3  Introduction of RPA in Financial and Management Accounting

actions on the screen and convert them into a process that the robot then runs through automatically. To the best of our knowledge, Blue Prism does not currently offer this functionality. Both UiPath and Automation Anywhere offer a limited trial and a Community Edition for small businesses, developers, and students. Blue Prism also offers an official trial version and a Learning Edition. In terms of training availability, UiPath has offered official training and a certification program for free early on (UiPath Academy). Today, Blue Prism and Automation Anywhere also offer free training and certification programs (Blue Prism University and Automation Anywhere University, respectively).

3.3.3 Combination of RPA with Other Digitization Technologies Regardless of which RPA provider is choosen, robots are particularly suitable for processing structured data (e.g. databases, tables) that are handled in standardized and repetitive processes. For the robot to work, it needs precise instructions at the key or click level, as mentioned above. The robot only does exactly what it is instructed to do. While desirable from a compliance perspective, this highlights the weakness of software robots. Only the slightest changes in the process (e.g. software update of addressed applications), not exactly predefined decision rules or missing instructions lead to errors in the execution and to the termination of the robot. To address these shortcomings, RPA vendors try to integrate other digitization technologies from areas such as analytics, OCR, or parts of artificial intelligence into their solutions. This makes software robots more intelligent, turning RPA into Intelligence Process Automation (IPA) (see Chap. 4).

3.4 RPA Roles For the introduction and operation of RPA solutions, different knowledge and activities are required, which are divided into so-called RPA roles. Each role is either filled by specialized employees or several roles fall to one employee. In practice and research there is a multitude of used or recommended RPA roles. The following sections focus on what we consider to be the central RPA roles and the tasks and knowledge associated with them.47 General roles, such as project managers who support the introduction of RPA, are not discussed.

3.4.1 RPA Business Analyst The RPA business analyst is characterized by having knowledge of both the individual business processes and RPA technologies. He is responsible for selecting suitable processes 47

 For examples of the different RPA roles, see Anagnoste (2018); PWC (2018); King (2018).

3.4 RPA Roles

43

(see Sect. 3.2) to be supported by RPA. For the recording/documentation, analysis, and optimization of the identified business processes he needs knowledge in Business Process Management (BPM) and Business Process Reengineering (BPR). In this context, the RPA Business Analyst needs strong analytical and communication skills to manage the exchange with process participants, especially process experts, from the business units and to document results in a structured way. Although the business analyst does not need in-depth technical knowledge of RPA solutions, a basic understanding of the functionality and limitations of RPA solutions is indispensable. The RPA business analyst also acts as a contact person for other RPA roles when it comes to questions about the underlying business processes. For example, the RPA business analyst bridges the gap to the RPA developer (Sect. 3.4.2) by ensuring that the process requirements of the business unit are taken into account during the development of the robot. Depending on the operating model (Sect. 3.6), RPA business analysts either work centrally in a dedicated RPA department or directly in the business unit.

3.4.2 RPA Developer & Citizen Developer The RPA developer is responsible for the technical design, development, testing, and documentation of the robots. The developer ensures that the robots work smoothly with the software applications addressed and – if used – that technical links to other digitization technologies (see Sect. 3.3.3) function properly. Together with the RPA business analyst, he ensures that the requirements of the business unit are (technically) completely mapped. When testing, he works closely with the business unit. Together they define the test concept, test cases, or test procedure. In some cases, specific RPA testers also may support. After implementation, the RPA developer also takes care of the technical maintenance and further development of the robots. If several RPA developers work in the company, the individual developer also has the task of reviewing or auditing the developments of the other developers. The review of RPA governance guidelines (Sect. 3.5) is another possible task of the RPA developer. In contrast to the technical RPA developer, the so-called RPA citizen developer is usually an employee from the business unit who has a certain IT affinity, but is a rather nontechnical user or has no profound IT background. He develops simple software robots for himself and for his department. Organizationally, the RPA citizen developer works together with the later users of the software robots and the technical RPA developer. The idea behind this is that while the RPA developer develops new software robots for more complex processes, often programming them as well, the RPA citizen developer develops his software robots for simple processes using existing, prefabricated robot sequences based on graphical modeling, for which he does not need any programming knowledge. In order for the RPA citizen developer to take on this task, he should have some basic IT technical understanding, but most importantly, he should know the business processes of his department well. In this way, the RPA citizen developer is equivalent to an RPA business analyst

44

3  Introduction of RPA in Financial and Management Accounting

with basic developer skills. Due to his knowledge in the development of robots, he plays an important role in scaling RPA.48 Instead, in order for pure RPA developers to fulfill their role, they need in-depth technical knowledge of the RPA solution being used. Often, RPA developers have extensive knowledge of specific RPA platforms.49 Extensive experience in scripting or/and programming languages (e.g. in C#, .Net, VisualBasic) are required. For some years now, there have been certificates that systematically test the knowledge of the RPA developer, although they are often geared to a specific RPA solution (Sect. 3.7.5). A basic understanding of business processes together with analytical and communication skills round off the profile of the RPA developer. It is also conceivable that experienced RPA developers act as trainers for less experienced RPA developers or citizen developers in the business units. Especially in the case of a broad introduction of robots in the company, a so-called RPA controller can be used in addition to the RPA developer. The controller controls, schedules, monitors, and audits existing robots via a central control center. The control center and the robots are usually located on central servers, not on individual desktops (Sect. 3.3.1). Furthermore, it operates an appropriate escalation management in case robots fail. The capabilities are largely based on those of the RPA developer.

3.4.3 RPA Architect Together with a project manager, the RPA architect carries out the selection process and the technical introduction of an RPA solution. In this process, he also defines the technical specifications of the architecture and later provides holistic support for the RPA solution. During the introduction as well as in the later operation, the architect checks which modules or further technologies (e.g. OCR) are required for the RPA solution in order to automate the business processes via robots. For offers, questions, or coordination with RPA providers, the RPA architect is the contact of choice. Within the company, the architect works closely with the IT department. Together, the installation environment is defined, necessary hardware is selected, technical service level agreements (SLAs) are specified, or security and access policies are defined and implemented. RPA governance plays a crucial role in this process (Sect. 3.5). In addition to the pure architecture, the RPA architect is also responsible for defining and implementing suitable RPA workflows. For example, the RPA architect defines the concrete steps that have to be performed from the testing to the implementation of a process or subprocess in a robot (Sect. 3.2.2). The RPA architect typically has an IT technical background. He brings extensive technical experience in the design, description, and operation of IT solution architectures. Agile development methods (e.g. SCRUM) are familiar to the RPA architect. Finally, the  Cf. Gartner (2021); Neagu (2021); Nintex (2018).  Cf. CoSourcing Partners (2018), p 8.

48 49

3.4 RPA Roles

45

architect has strong communication and coordination skills to serve the various RPA stakeholders (e.g., business units, RPA developers, IT department, RPA vendors).

3.4.4 RPA Support The RPA support is the first level support, i.e. the first point of contact for questions regarding the provided RPA solution. In addition to technical questions, the RPA support is the contact point for emerging errors or aborts with robots. In order to record occurring errors and to carry out regular checks of the functionality of the robots, the RPA support works closely together with the RPA controller (Sect. 3.4.2) or even combines the tasks of the same. If emerging errors cannot be solved, RPA developers come into play. Employees in RPA support have a good basic understanding of the RPA solution used, although not necessarily in-depth technical knowledge (e.g. in programming languages). For the handling, processing, and tracking of error messages and questions, the RPA support is appropriately trained (e.g. via processing guidelines). Finally, employees in RPA support also have a basic understanding of business processes in order to be able to assess corresponding questions or error messages.

3.4.5 Summary Overview of RPA Roles The roles presented above have different tasks in the introduction and operation of RPA solutions. The necessary knowledge of the roles also differs. For a structured overview, the tasks and knowledge of all roles are listed and compared in Fig. 3.20.

3.4.6 Examples of an RPA Role Model from Practice To further illustrate the design of RPA roles in practice, the example of ECE is used (see Fig. 3.21). Some of the roles presented below are considered optional at ECE, depending on the context. The departmental roles envisaged there are analyst, developer, RPA program owner, and leader. The analyst, presented above as business analyst, actively seeks and defines the processes and activities to be automated. The developer, what we called above RPA developer or RPA citizen developer, implements the processes specified by the analyst by developing and testing appropriate software robots. The RPA program owner is located in the business unit and is responsible for the actions and content of the RPA program. The RPA leader coordinates all RPA activities in the department with the other roles and decides (as a member of an RPA board) on new automation ideas.50

50

 Cf. Petersen and Schröder (2020), p 1141ff.

46

3  Introduction of RPA in Financial and Management Accounting

RPA Citizen Developer

Knowledge

Tasks

RPA Business Analyst

RPA Developer

Selection of suitable processes for RPA Documentation, analysis and optimization of selected processes Bridge between business unit and RPA developer Contact person for other RPA roles for questions about business processes

Technical Design development testing and documentation by robots

In-depth knowledge of business processes Basic understanding of functionality and limitations of RPA solutions

In-depth technical knowledge of RPA platforms

Knowledge of Business process management (BPM) and Business process reengineering (BPR)

RPA Architect Selection and implementation of the RPA platform Definition of technical specifications of the RPA architecture and holistic support of the RPA solution

Technical integration of software applications and linking to other digitisation technologies (e.g. AI)

Extension/further development of the RPA solution (e.g. OCR, AI) Coordination with IT department (e.g. hardware, guidelines, IT governance) Definition of RPA workflows

Technical maintenance and further development of the Robots Review & Audits of robots

Basic knowledge of business processes Knowledge of scripting and/or or programming languages (e.g. in C, Java) V.a. technical-specific, structured

V.a. analytical, structured, communicative, Moderation skills

RPA Support

Technical knowledge in RPA solutions Many years of experience in design, description and operation of IT solution architectures

First point of contact for questions about the RPA solution Contact point for emerging errors or aborts with robots Regular tests of the functionality of the robot/RPA solution

Basic understanding of the RPA solution used Basic understanding of business processes No deep technical knowledge (e.g. in programming languages)

Experience in agile development methods (e.g. SCRUM) V.a. technical-broad, communicative, coordinating

V.a. communicative, coordinating, testing

Fig. 3.20  Tasks and knowledge of the RPA roles

Existing roles

Department

Analyst

Developer

RPA Program Owner

Leader

IT Department

RPA roles in the department

Process Consultant

Develop Consultant

DevOps Engineer

Manager

Process Owner

Product Onwer

Enterprise Architect

Karin role to take (depending on department role)

Fig. 3.21  RPA roles at ECE. (Cf. Petersen and Schröder 2020, p 1142)

3.4 RPA Roles

47

As RPA roles within the IT department, the ECE has the process consultant, the development consultant, the devops engineer, and the manager. Together with the business department, the process consultant develops new automation ideas and can also assume the role of an analyst in the business department. The development consultant is an experienced RPA developer who advises other developers in the business unit or can also take over this role. This immediately brings to mind the distinction between RPA developer and RPA citizen developer discussed in Sect. 3.4.2. A devops engineer is responsible for advanced RPA development, license management, deployment, and monitoring at ECE. Finally, the RPA unit manager coordinates all activities in the RPA unit at ECE and is the contact person within IT and for the RPA leaders of the various departments.51

3.4.7 Relationship Between RPA Roles and Roles in Financial and Management Accounting There seems to be little doubt that RPA has the potential to sustainably change processes in financial and management accounting. Hereby, RPA also affects the role model in financial and management accounting.52 RPA acts as an enabler to further shift the focus of roles (and thus the necessary tasks and competencies) in financial and management accounting in the coming years. The production role in financial and management accounting, i.e. the execution of simple, mostly transactional activities for the generation of information, will be largely replaced by software robots in the future. Instead, the focus of tasks and competencies in financial and management accounting is likely to shift to roles such as the business partner or new roles such as a innovator/pathfinder. The latter role is expected to continuously develop financial and management accounting towards state-of-the-art by, among other things, testing new digitalization technologies such as RPA for their transferability and applicability in financial and management accounting. Such a role requires knowledge in digitization and automation technologies. Thus, this role or the employee in financial and management accounting who holds it could simultaneously develop in the direction of a RPA business analyst or RPA citizen developer. The fact that the roles in financial and management accounting are changing due to the introduction of automation solutions such as RPA is shown by the example of Deutsche Post DHL.  Deutsche Post has established a new role in accounting called ‘Automation Design Expert’. In this role, employees technically maintain established automation solutions such as RPA, i.e. to carry out the first level maintenance activities. This is

51 52

 Cf. Petersen and Schröder (2020), p 1141ff.  Cf. also Langmann (2020), p 6ff. for the following remarks.

48

3  Introduction of RPA in Financial and Management Accounting

supplemented by the technical implementation of desired enhancements and improvements. The ‘Automation Design Expert’ is trained in a specially created internal ‘Automation Academy’ of Deutsche Post DHL.53

3.5 RPA Governance 3.5.1 Basics of RPA Governance Governance generally represents guidelines and rules, including the instruments for their enforcement, which shape how a company is managed and controlled.54 Analogously, IT governance is a framework that sets guidelines and standards specifically for IT.55 Consequently, RPA governance is specific to RPA and provides all relevant areas (business, IT, etc.) with clear guidelines and standards on RPA or Robotics.56 The components of RPA governance are wide-ranging and differ from company to company. Central points of RPA governance at Union Investment are, for example, the following points: • • • • •

Access rights for robots (What access rights should robots have?) Change requests (Who releases which changes for robots?) Monitoring of robots in operation (How is the performance of robots controlled?) Budgeting & prioritization (Which robots will be developed first? Is there a fast track?) IT security, workers council, and data protection (Which security guidelines must be observed? Is a works agreement necessary?) • RPA and individual data processing (Is there a risk of individual data processing?) • RPA and AI (At what point should AI complement the use of RPA?). • RPA and architecture (What role does RPA play in the system landscape?) One of the goals of RPA governance is to provide a clear answer for these areas and to these questions. While the technical development of software robots is the rather easy and quick part of RPA implementation, the development of RPA governance policies usually takes longer.57 Therefore, it is advisable for all companies that want to implement RPA to start developing governance quickly so that the policies are in place at the latest when the robots are desired to go live. The following principle applies here: “Without governance, no productive robots”. Without clear governance guidelines, robotization can have far-­ reaching, negative consequences for corporate processes. The following sections, therefore, touch on some central principles that play a role in the creation of RPA governance.  Cf. Wenzel (2020), p 48.  Cf. Wentges (2002), p 72. 55  Cf. Fröhlich and Glasner (2007), p 17. 56  Cf. Langmann (2020), p 6. 57  Cf. Schmelzer (2020), p 68. 53 54

3.5 RPA Governance

49

The guiding principle in the creation of a RPA governance is that the same or sometimes even stricter rules should apply to robots than to employees. For this purpose, robots first receive their own user identification number (user ID), which makes the activities and authorizations of each robot clearly traceable. In the next step, robots should be clearly assigned to the respective organizational unit and manager in the company who is responsible for them. This clear assignment increases the sense of responsibility among the responsible managers. With regard to system permissions, robots should only receive the permissions that are absolutely necessary for the execution of a process. It is advisable to define separate authorization groups for robots that contain only the necessary authorizations instead of using existing employee role profiles. In practice, it has been shown that employee roles often contain authorizations that are not necessary for robots or lead to a higher authorization profile. Furthermore, RPA governance policies should also address the following components: Organisation  In the ‘Organisation’ part of the RPA governance guideline, the operating model is introduced and defined, i.e. which department(s) are responsible for the development, maintenance, monitoring, review of robots. The different operating models are explained in Sect. 3.6. In this part of the governance, the functional and technical roles are also defined and described (Sect. 3.4). Security  The ‘Security’ part of the RPA Governance Guideline describes the risks that arise from the use of RPA and measures for risk elimination or mitigation. Risks associated with the use of robots include cyber-­attacks (either by insiders or external hackers) or incorrectly executed activities in critical processes. To eliminate or mitigate these risks, permissions, access rights and protocols must be defined in detail. By giving robots only the most necessary (minimal) permissions, the risk is not only greatly reduced, but completely eliminated in many places with verification steps. The following example illustrates this point: employees create a specific input (e.g., files) that is provided to a robot for further processing. If the input is not available, the robot informs the workers that it is missing without performing any further steps. The risk of incorrectly executed activities causing damage is thus eliminated. Robots can be operated as attended or unattended RPA (Sect. 2.1). In both cases, different log files are created.58 Log files are data records in which all activities of a robot are recorded (logged) that could be important in the context of a later audit. A distinction is made between standard log files (standard logs), which store information predefined by the software provider, and custom log files (custom logs), which are used as supplements. Standard logs usually contain information such as the start and end of the process, the user ID of the robot, the name of the process, and a unique identification number (known as the job ID). Although the information in the standard logs is important, it is not sufficient for a more in-depth analysis. For this reason, standard logs are enriched with additional 58

 Cf. on log files and on log analysis in general Peikari and Chuvakin (2004), p 409.

50

3  Introduction of RPA in Financial and Management Accounting

custom logs. Custom logs can be divided into two main categories: Error logs or info logs. While error logs document errors that occur, info logs record different information, such as the successful entry of a customer in the inventory system. The definition of which information should be logged and which information may be logged should be made before the actual development of the robot. The following example illustrates the relationship: If data processing takes place in a process, the selected data is read into a working memory (in memory), but is not stored long-term in the process by the robot and is deleted again when the process is completed by the robot. This means that robots can also process more sensitive data without hesitation. However, processes in which robots write such sensitive data as salary data to log files are to be classified as critical. To avoid this, the use of alternative IDs is recommended. For example, after successful processing, the robot writes the employee number or another ID in the log file instead of salary data, so that it is clear that the data record was successfully processed. In addition to the log files, which are usually simple text documents, the use of socalled log tables is also possible. Log tables facilitate the cooperation between employees and robots. Log tables contain different information that is relevant for process managers. Structurally, log tables are usually divided into success (successful transactions) and failure (incorrect transactions) logs. Log tables are separate documents. They are not necessarily part of log files. Together with log files, log tables thus offer a variety of log options and areas of application for developers, IT security, and employees, which significantly increases the transparency of robot activities. As a further point, an RPA governance should define under security how robots use the required passwords. The approach to password management differs from company to company. The use of special software such as Windows Credentials59 or CyberArk60 can help here. It is important that companies establish clear guidelines on how passwords are stored and used by robots. Pipeline and Case Management  To sustainably integrate RPA into the organization, it is essential to continuously and systematically identify the processes that can be robotized. This part of the RPA governance guideline defines the process identification steps (details: Section 3.2), documentation requirements, the implementation process, and the acceptance process for processes to be robotized. For the selection of new processes and their prioritization, an RPA board can also be installed (Sect. 3.5.4). The documentation of processes to be robotized is done at the click level (Sect. 3.2.2), where each step is defined individually. The resulting documentation has two main tasks. On the one hand, it is the specification for developers, and on the other hand, it serves as the basis for possible audits. In addition, process documentation typically also contains tests or test cases that were performed in connection with the robotized process. The results of the executed test cases are either positive, if everything worked correctly (so-called “happy path”), or negative, if different error situations, system problems, or various input problems occurred.  Cf. for example Dauti (2019), p 378 ff.  Cf. www.cyberark.com

59 60

3.5 RPA Governance

51 E-mail to employee that task has been has been completed

Order to the Robot

Report update

Validating performance

Processing

Upload

Change in areas of activity

Fig. 3.22  Employee activities after robotization

The tests ensure that the robotized processes also run appropriately stable in real operation and fulfill the desired expectations. After successful testing, a formally defined acceptance process is used for both the functional acceptance of the robotized process together with the process owners and the robot ‘manager’ and the technical acceptance by a developer. The formal acceptance process increases the sense of responsibility of all participants. Operations  The technological infrastructure of RPA operations is the subject of the ‘Operations’ section of the RPA governance. Identical to ERP systems, RPA is typically deployed with different landscapes such as development, test, and production environments (Sect. 3.3.1). These environments ensure the auditability and traceability of developments. Responsibilities are also defined similarly for RPA and ERP software. The business department is responsible for the data recorded or created in the software, while IT is responsible for the infrastructure and technical setup. Similar to ERP software, companies should also think about the possible infrastructure and scalability of RPA software right from the start. Some companies focus on the rapid development and realization of robotizable processes and neglect the infrastructural foundations. This can result in the initial infrastructure not having the desired scalability or stability later on. If the use of robots increases continuously, the worst-case scenario is that the technical infrastructure has to be virtually rebuilt. Companies should therefore define a sustainable and scalable infrastructure right from the start, which creates the basis for long-term robotization.

3.5.2 Monitoring and Control of RPA Robots can perform processes fully autonomously, independently, and control themselves to determine whether they have successfully completed the process. Despite these independent controls, robots themselves should be controlled. Here, the principle applies: Processes that robots perform must be controlled in the same way as processes that employees perform. Figure 3.22 shows the connection. Through the robotization of a process, employees in this process will in the future still perform two roles. One is a trigger role and the other is

52

3  Introduction of RPA in Financial and Management Accounting

the role of a supervisor. Robotization thus leads to a change in tasks of the employee, who mostly focuses on the execution of the task. The trigger role is mostly relevant in attended RPA, hence, not required for every robot. In unattended RPA, either fixed times are defined for when the robot performs the process, or certain events trigger the execution, such as a new incoming email. If, however, neither the starting point for the execution of the process can be fixed or linked to a trigger event, employees must trigger the robot actively. In contrast, the role of the supervisor must always be actively performed by employees. After robotization, the actual process responsibility remains with the department. Similarily, each robot always has an owner who has the (technical) responsibility for the robot. Thus, even after the introduction of robots, the accounting department continues to have the responsibility for proper accounting. If the robot does not perform certain tasks correctly or incompletely, e.g. due to incorrectly prepared input files, the accounting department must check the results of the completed tasks and ensure the quality accordingly. The department has various options for checking the outputs created by the robot. One way is to check the different log files, which were presented in detail in Sect. 3.5.1. On the other hand, additional test mechanisms and control steps can be used, such as frameworks or a monitoring and control component (see also Sect. 3.3.1). Framework  A framework is used to ensure that robotized processes always have the same logs and contain identical checking mechanisms. In this way, they help developers to standardize and employees to control and check robotized processes. Frameworks usually include standardized exception handling and error handling. Exception handling defines the handling of a software crash or an unpredictable system message. In the framework, the required steps (screenshot, e-mail or SMS to employees, etc.) are defined for such cases. This prescribes exactly which steps the robot will perform if it is unable to complete a process or can only complete it partially. If an error occurs during the execution of the process, e.g. because an application cannot be started, error handling is required. Error handling defines exactly which steps the robot performs next as soon as an error occurs.  Monitoring and Control Component  RPA tools usually also contain so-called monitoring and control components, which ensure the technical and partly also the functional monitoring. In addition, other software programs, such as Kibana from the provider Elastic, can be used for monitoring robots.61 Software programs that manage the workload (of employees and robots), completed and open process steps, as well as current malfunctions at the overall process level are particularly suitable for functional monitoring. An example of this is the software program Enate.62 Enate allows the easy integration of RPA into daily business processes. Enate can be used to monitor activities that have been distributed to employees or robots and to check whether or at which point in a process an activity has not been performed or has only been partially performed.

 Cf. www.elastic.co.  Cf. www.enate.net

61 62

3.5 RPA Governance

53

Together, the monitoring and control component and the framework ensure that robots correctly execute the planned activities of a process and generate the desired outputs.

3.5.3 Compliance and Data Protection in the Use of RPA Even if robots hardly seem to be affected by compliance and data protection at first glance, a look at practice shows the an other picture. Existing compliance and data protection guidelines should therefore be analyzed and, if necessary, expanded to include the application field of RPA in order to establish a comprehensive RPA governance. Data Protection  Robots collect data, process it, and carry out precisely predefined work steps in the process. In many cases, this data includes personal data, such as when capturing personal data from a system. For the processing of personal data, the robot may only read the data into the working memory (in-memory) without storing it. Immediately after processing by the robot, the data must be automatically deleted again from the robot’s process cache. Therefore, the following principle applies: Robots may process any data and information as long as the data is not permanently stored in the robot or during the process.  Not only in the actual data processing by the robot itself, but also in the use of log files (see Sect. 3.5.1), personal data and thus data protection can play a role. The far-­ reaching consequences of this can be illustrated by the example of customer data: Robots usually collect customer data from a structured data set, which is often stored in an ERP or CRM system. To ensure that the data has been entered correctly and completely, the name, address (es), and telephone number(s) are logged in the log file. If the company now receives a deletion request from one of the recorded customers, all listed personal data in the data deletion request must be deleted from all systems.63As explained in Sect. 3.5.1, log files are used for audits, among other things, which is why they may not actually be modified or deleted. Strictly speaking, the company cannot fulfill the customer’s deletion request. This simple example illustrates the challenges of compliance with data protection and the associated need to check exactly what data (in what form) is recorded in the log file. One possible solution is anonymized logging in the log file, such as “Customer 4392 was recorded in ERP” instead of “Max Miller was recorded in ERP”. Compliance  In addition to the data protection guidelines described above, existing compliance guidelines (e.g. IT compliance) of the company should also be applied to RPA and extended if necessary. Especially in the case of an extensive introduction of RPA or the introduction for sensitive processes, it is a good idea to identify a compliance risk specifically geared to RPA and to develop appropriate measures for control and sanction. This is (mostly) not about the robots themselves. Marcus Kuhnert, CFO of Merck, correctly states:

63

 See, for example, Paal and Pauly (2018) on the request for erasure under Section 17 of the GDPR.

54

3  Introduction of RPA in Financial and Management Accounting

If issues and processes are well documented, these bots are virtually 100 percent compliant.64 Thus, examining compliance risk and appropriate control measures also involves the processes, organization, and people used to operate and develop robots. Questions that arise here for RPA compliance are, for example: Who is liable for a robot’s violation of compliance policies? Who decides on the selection of processes for robotization? Is there a regulated and documented process for this? Who defines new control mechanisms for robots or changes existing ones? The setup of an RPA board is one possibility to tackle those questions.

3.5.4 RPA Board An RPA board is a committee that discusses automation proposals and decides on their implementation. Proposals may represent new or existing robots. By deciding which automation proposals are to be implemented in RPA, the board also decides on the resources required for this. RPA boards are located either centrally or at the department level, which depends on where the implementation of the development takes place. Only in this way can the RPA board seriously consider whether the necessary resources for the development are not needed more urgently elsewhere in the department or in the company.65 In the case of a central, cross-departmental RPA board, experts from different areas (e.g., departments, IT) are typically represented on the board. On the one hand, this allows potential synergies to be identified at an early stage. On the other hand, it ensures that robots that already exist in one department can be used by other departments. As members of the RPA board, experts from IT can also provide new impulses as to how possible solutions for the automation may look. Here, for example, a combination of RPA + IT interface may be more suitable and stable than the automation by RPA alone.66

3.6 RPA Operating Model 3.6.1 Basics of the Operating Model for RPA The operating model for RPA (also called Robotic Operating Model or Robotic Operating Concept) is one of the most important elements for a sustainable RPA implementation. The operating model predetermines various framework conditions and processes. The choice of the operating model determines, among other things, the organization of

 See Marcus Kuhnert’s interview with Jürgen Weber, in: Weber (2018), p 25.  Cf. Petersen and Schröder (2020), p 1141. 66  Cf. Zeiss and Jenesl (2020), p 51 f. 64 65

3.6 RPA Operating Model

55

development and maintenance (incl. setup options), the pipeline management for upcoming projects, or the knowledge management for RPA.67 The goal of the Robotic operating model is to integrate robots into the organization and into the daily processes of the company. The prerequisite for this is a sustainable linkage of the new technology with the existing workforce. The closer the robotized processes (robots) are linked with the manual processes (people), the more likely the technology will establish itself in the organization and become a success. The linkage should not only take place technologically, i.e. by means of software via which employees and robots can be tracked and monitored separately. Rather, there should also be an operational linkage in which employees accept the robot as a supporting helper in the sense of a digital colleague. A simple measure to promote operational integration is the assignment of names to robots by the employees themselves (e.g. “Scott, my robot”). Naming the robot humanizes it and increases its acceptance by employees as their new digital colleague. Regardless of the chosen (Robotic) operating model, the nomination and development of dedicated staff are important for the successful implementation of RPA. At the beginning of an RPA implementation at the PoC (see Sect. 3.1.1), dedicated employees for RPA do not have to be nominated. However, as soon as the first robot is in use in the company and the robotization strategy has reached a certain level of maturity, dedicated employees must be appointed for this purpose. For the successful development and implementation of robots, the nominated employees need different knowledge and skills. In addition to programming skills (e.g. C#, Net, VisualBasic, SQL), in-depth process knowledge is also necessary (Sect. 3.4). Central to the design of the operating model is the choice of the organizational model for RPA. The organizational model influences the orientation of the other parameters of the operating model. Accordingly, operating models can be categorized into three organizational types: centralized, decentralized, and hybrid operating models.68 The three models are explained in detail in the following sections. They differ mainly in terms of robot development and maintenance. The selection of an appropriate operating model that is suitable for the existing business organization should be discussed at the beginning of an RPA implementation. The choice of operating model for RPA depends on various factors. Factors such as the size of the company, existing technical knowledge in the departments, the current organizational structure, or the acceptance of a central, new RPA department in the other areas are of particular importance. In addition, there are ‘softer’ factors, such as the digital mindset in the company, leadership style, agility, or motivations for robotics. Depending on whether robotics is used to increase efficiency in the short term, as a strategic tool to support the digital transformation of the company, or as a platform for the integration of artificial intelligence, different operating models are suitable.

 For the RPA operating model, see Capgemini (2019) for example.  For the variants of an operating model in RPA, cf. e.g. Deloitte (2017).

67 68

56

3  Introduction of RPA in Financial and Management Accounting

Fig. 3.23  Centralized operating model for RPA

For SMEs, it is obvious to set up the RPA department in the form of a central model (Sect. 3.6.2.1). SMEs often have neither the need nor the resources to maintain their own robotics experts in decentralized departments, as a decentralized operating model would provide (Sect. 3.6.2.2). The centralized operating model with a central RPA department (Sect. 3.6.2.1) is also often favored by large companies, especially if the effects of an RPA implementation are to be realized in the shortest possible time (see Sects. 2.2.1 and 2.2.2). However, even large companies within the same industry have different operating models for RPA. Which organizational model is best suited for one’s own company must therefore be examined on a case-by-case basis. The following sections examine the various operating models for RPA in detail.

3.6.2 Operating Models for RPA 3.6.2.1 Centralized Operating Model for RPA The centralized operating model is the first model that is conceivable for the implementation of RPA in the company.69 In this model, RPA roles (e.g., RPA developer, RPA business analyst) and tasks (e.g. development, maintenance, or pipeline management) are bundled in a central department. In corporate practice, the department is often referred to as an RPA Center of Excellence (CoE) or RPA Competence Center (CC), for which either an existing department is expanded or a new department is created (see Fig. 3.23). Research suggests that the centralized model in the form of the RPA CoE is a very common organizational model in RPA.70 The new department can be located in different areas of the company, for example in the IT or a functional department such as finance. The location of the RPA CoE in the IT seems logical due to the proximity to IT in general and promotes the exchange with the rest of IT department.71  Cf. the study by Deloitte (2018), p 18 ff.  Cf. Willcocks et al. (2019), p 20ff; Langmann (2021). 71  On the integration of IT, cf. e.g. King (2018), p. 217. 69 70

3.6 RPA Operating Model

57

Advantages of the centralized model in the sense of a CoE or CC are initially short communication channels and clearly defined responsibilities. The central department has a clear overview of the processes that can be robotized or have already been robotized and can accordingly prioritize the processes centrally in the interest of the company. All necessary RPA knowledge is located directly in one department and not distributed throughout the company. Continuous knowledge transfers and training to stay up to date with the latest RPA technologies are facilitated by centralization. Since the existing know-­ how and knowledge in the field of robotics are essential for successful RPA development, many companies favor central development and thus the centralized model. Another advantage of the centralized operating model for RPA (in the sense of an RPA CoE or RPA CC) is its character as a one-stop-shop for robotics. RPA platform, development guidelines, identification of robotizable processes, or maintenance of robots come from a single source. The standards and process specifications for RPA are also largely created and maintained in the central department, since all the necessary skills are directly available. As a result of this centralized bundling, the centralized model usually also causes lower costs compared to hybrid (Sect. 3.6.2.3) or decentralized (Sect. 3.6.2.2) operating models, which also results from the use of a centralized and standardized platform. Through the bundling of the entire know-how, the short communication channels, and clear responsibilities the centralized operating model leads to fast usable results, especially at the beginning of an RPA implementation. Therefore, if companies want to achieve the benefits in the shortest possible time through the introduction of RPA, they should opt for the centralized model. The scalability of the centralized operating model and its integration with the rest of the organization depends on the size, capacity, and experience of the central department. Due to the lack of available RPA specialists in the market, the central department often has a limited number of RPA developers and RPA business analysts at the beginning (see Sect. 3.4 for roles). The robotization of processes is therefore usually initially limited to certain departments or business processes. A comprehensive rollout of robots  – in the sense of a simultaneous development of numerous robots in different company areas – is therefore often not possible at the beginning due to the limited number of internal resources. This is because both know-how and resources are needed for a broad rollout of robots. Deloitte (2018) underlines the context in a recent study, according to which the lack of RPA resources and skills is a key challenge for companies.72 In addition to the resource bottleneck already mentioned, which can result from the simultaneous robotization of many processes, a resource problem also arises with the centralized operating model in the case of larger, more extensive maintenance. If many robots access the same system (e.g. SAP, Windows), an update of the system (e.g. SAP version update or a changeover from Windows 7 to Windows 10) can lead to a maintenance backlog in the central department. As a result, numerous robots may be offline at the same time.

72

 Cf. Deloitte (2018), p 18.

58

3  Introduction of RPA in Financial and Management Accounting

Centralized operating model for RPA Advantages

Disadvantages

Central point for all RPA concerns

Little flexibility in the development and maintenance of robots within the Company

Concentrated skills and sufficient knowledge about robotics

Rigid structures

Clear communication channels and responsibilities

Dedicated manpower for RPA

Acceptance by the departments as well as the anchoring of RPA in the organization can be challenging

Clear goal setting and central control of the RPA strategy

Resource bottleneck is possible, esp. when many robots work on the same software (e.g. 80% of the robots work with SAP, in case of a SAP changeover, all robots may have to be robots have to be adapted at the same time)

Clear and centralized prioritization of processes andprocesses and resources to be robotized

In prioritization, often only quantitative metrics (time, FTE) not qualitative aspects (quality improvement, skill-appropriate use of employees) RPA knowledge is only built up centrally built up and not anchored anchored

Fig. 3.24  Advantage and disadvantage of the centralized operating model for RPA

In addition to this resource problem, there is also the danger with the centralized operating model that the central department will increasingly be called upon not only for the development and maintenance of robots, but also for the execution of processes. As a result, the responsibility for the processes may gradually shift from the respective department to the central RPA unit, which is generally undesirable from the company’s point of view. Also, for the integration of robotics into the daily work of the employees and the anchoring in the organization, the centralized operating model has certain weaknesses. The central bundling of the RPA can have the consequence that the employees in the functional departments, for which the robots are build, do not have sufficient points of contact with RPA or the robots. As a result, RPA as a technology and the robots themselves become poorly embedded in the organization, which in turn may lead to low acceptance by employees in the functional departments. Figure 3.24 summarizes the advantages and disadvantages of the centralized operating model for RPA.

3.6.2.2 Decentralized Operating Model for RPA In the decentralized operating model, the RPA roles (e.g., RPA developer, RPA business analyst) and tasks (e.g. development, maintenance, or pipeline management) are decentralized, i.e., anchored in the decentralized units (see Fig. 3.25). This can be bundled at the geographical level (e.g. robotics unit per country), organizational level (e.g. robotics unit per business unit or subsidiary) or functional level (e.g. robotics unit per functional

3.6 RPA Operating Model

59

Fig. 3.25  Decentralized operating model for RPA

area), or a combination of these. A look at corporate practice shows that partially decentralized operating models and thus partial bundling, especially at the geographic level in the form of geographic robotics hubs, can be found especially in large corporations. This ensures the individual national companies to robotize flexibly and implement RPA individually as needed. A purely decentralized operating model with no form of bundling (e.g. geographically or organizationally) is found rather rarely. The involvement of the central IT department is usually low.73 In the decentralized operating model, the units themselves define how they want to robotize, which RPA tools they use for this purpose, and which RPA guidelines apply to the respective unit. The basic prerequisite for successful robotization using a decentralized model is sufficient skills, processes, and resources in the respective decentralized unit. Furthermore, a communication channel or platform (e.g. file sharing, forum, chat, blog) should be created across the organizational boundaries of the individual decentralized units, through which the employees of the units can exchange information with each other and share experiences and developed robots. In this way, one unit benefits from the experience of the other units without sacrificing the high flexibility in the development, implementation, and maintenance of robots. Without such exchange, there is a risk of costly duplication (e.g. developing the same robot for a similar process). If the units are set up independently of each other in the decentralized operating model, in extreme cases the units not only operate their own RPA platforms with their own development and maintenance, but also use different RPA roles, their own RPA governance guidelines, or even individual documentation requirements for RPA.  The resulting disadvantages are obvious. For example, if the decentralized units use different RPA platforms, the exchange of developed robots can only take place on a theoretical level due to the different orientation of the platforms (Sect. 3.3) and is therefore likely to be fruitful only to a limited extent. If the decentralized units have identical RPA platforms in use, 73

 On the integration of IT, cf. e.g. King (2018), p. 217.

60

3  Introduction of RPA in Financial and Management Accounting Decentralized operating model for RPA Advantages Flexibility in development and maintenance Direct communication channels between developer and client The individual units can act quickly and act according to given requirements High flexibility in case of a change

Disadvantages Creation of silos that do not or only partially cooperate with each other to a limited extent Guidelines and governance policies can vary widely Different applications reduce the possibility for synergy effects Exchange of developed elements is possible only to a limited extent

Fig. 3.26  Advantage and disadvantage of the decentralized operating model for RPA

they can easily exchange building blocks or already developed robots among themselves. It is therefore advisable to opt for one or only certain RPA platforms in the decentralized organizational model. A minimum level of standardization for all units should also be the goal in the decentralized operating model when defining RPA roles, RPA governance guidelines, and documentation requirements. This is the only way to define the basic framework and goals of Robotics across the enterprise. Through this form of harmonization, the decentralized units benefit from synergy effects in terms of quality, time, and costs, without sacrificing the advantages of the decentralized operating model. Particularly worthy of mention here are the high degree of flexibility in the development, modification, and maintenance of robots, the direct communication channels with the operational areas (clients), and the speed of the units, which results primarily from their independence. Figure 3.26 summarizes the advantages and disadvantages of the decentralized organizational model for RPA.

3.6.2.3 Hybrid Operating Model for RPA Studies on RPA show that in addition to the centralized model, the hybrid organizational model is often used in practice (see Fig. 3.27).74 In a hybrid operating model for RPA, the advantages of the centralized and decentralized models are combined. Here, a central, cross-functional CoE is first established, which is responsible for defining the RPA roles, RPA governance, documentation requirements, and for designing knowledge management and compliance. In addition, the central team manages the vendor selection of the RPA platform. Additionally, central IT is involved at an early stage.75 The development and maintenance of the robots, on the other hand, may be carried out decentrally – in coordination with the central team – in teams or units set up for this purpose in the respective areas. The first level support for questions about robots is to be provided by the decentralized teams. This division ensures flexibility and agility in the  Cf. Deloitte (2018), p 20.  On the integration of IT, cf. e.g. e.g. King (2018), p. 217.

74 75

3.6 RPA Operating Model

61

Fig. 3.27  Hybrid operating model for RPA

development and maintenance of the robots. However, the hybrid operating model requires a high degree of discipline from all participants to comply with the division of tasks and responsibilities, which may involve more coordination effort. Through decentralized development and central coordination, the RPA technology is sustainably anchored, a robotics mindset is established, and the robots are efficiently interlocked with the employee processes, which is, among other things, due to the direct communication channels with the operational areas (clients), similar to the decentralized operating model. The establishment of decentralized teams, each with their RPA (citizen) developers and RPA business analysts (for roles, see Sect. 3.4), ensures that the company has an extensive pool of RPA specialists. A temporary pooling or exchange of the decentralized teams’ RPA resources in times of peaks and resource bottlenecks balances out any resource issues. Advantages but as well as disadvantages in the hybrid operating model come with own RPA developers and RPA business analysts in the decentralized teams. The resources for these RPA roles (see Sect. 3.4) is often not available in the decentralized teams or departments at the beginning of robotization. As a result, existing employees have to be trained (“upskilling”) or the missing skills have to be acquired through new recruitment. Due to the lack of available RPA specialists on the market, this can be associated with high costs.76 Another challenge of the hybrid model lies in the coordination and communication between the central and the decentralized teams. The central, cross-functional team controls and monitors  – in coordination with the decentralized teams  – all RPA developments and derives any necessary measures from them. For this collaboration to work, the central team must control the goals associated with robotics and clearly define

76

 For the salaries of the different RPA roles, see e.g. CoSourcing Partners (2018).

62

3  Introduction of RPA in Financial and Management Accounting Hybrid Operating Model for RPA Advantages Strong anchoring of RPA in the Organization High flexibility and agility in the development and maintenance of robots Central definition of the RPA framework (Governance, platform, processes, etc.) Sufficient pool of RPA developers for the same platform Direct communication channels between developer and client

Disadvantages The establishment and management of the Organization can be resource intensive. It is possible that the benefits of RPA (time savings, quality improvement, etc.) Are not tightly controlled

Fig. 3.28  Advantages and disadvantages of the hybrid operating model for RPA

them for all participants. The use of OKR (Objectives and Key Results) is conceivable as a control instrument for this.77 Figure 3.28 provides an overview of the advantages and disadvantages of the hybrid operating model for RPA. In summary, the hybrid model is ideal if RPA is seen as a longterm technology and as an active part of the digital transformation and a strong anchoring in the organization is desired.

3.6.2.4 Comparison of the Operating Models Each of the three operating models presented offers specific advantages and disadvantages. A structured overview can be found in Fig. 3.29, which shows the characteristics of the three organisational models on the criteria discussed above. The overview shows that the centralized operating model clearly scores in terms of standardization, control, economies of scale and synergy effects, and the generation of RPA knowledge. In contrast, the decentralized model has the greatest degree of freedom for a department-specific design, has the closest involvement of the departments in RPA development, and has a comparatively high number and availability of RPA resources in the company. The hybrid model has a balance of the advantages and disadvantages of the centralized and decentralized models, but associated with a higher resource commitment. Therefore, Noppen et al. (2020) consider the hybrid model as the most promising model. In their study of hybrid operating models in practice, they conclude that certain framework conditions should be created so that the hybrid model is considered advantageous. An important framework condition was that the central CoE should provide development resources or development know-how in case decentralized units need support. Similarly,

 Cf. Doerr (2018).

77

3.6 RPA Operating Model

63 Central

Organization model / Assessment Criterion

Hybrid

Degree of standardization Control over RPA framework (platform, governance, roles, processes etc.)

Degree of freedom of area-specific design of RPA Extent of involvement of departments in RPA development Exploitation of economies of scale and synergy effects Extent, timeliness and depth of RPA knowledge Availability of RPA resources = low proficiency

= high proficiency

Fig. 3.29  Overview of the Operating Models for RPA

in the hybrid model, the company should take care to select an RPA platform that fits the company context. For example, if the employees in the units have no or very little IT-related background, a more visual-oriented RPA solution should be selected.78

3.6.3 RPA Development Approaches Within the Operating Models Regardless of the choice of operating model (Sect. 3.6.2), companies pursue different approaches for the actual (conceptual and technical) development of robots. Simplified, possible approaches are the buy, make, or offshore approach. The three approaches are presented below and their respective opportunities, risks, and prerequisites are discussed. In the buy approach, as the name suggests, companies purchase the RPA resources they need (e.g. RPA developers) to develop the robots from one or more external partners. This approach is often chosen by companies at the beginning of an RPA implementation because they do not need to make a large investment and get results quickly. The external partner develops the robot independently based on the company’s (process) documentation. In doing so, the development of the robot should be combined in parallel with the training of the responsible employees so that they understand the robot and the RPA software in detail to be able to take over the later maintenance of the robots.

78

 Cf. Noppen et al. (2020), p 461ff.

64

3  Introduction of RPA in Financial and Management Accounting

However, the robot can also be developed together with the external partner in the form of co-development. In this case, parts of the robot are developed by the company’s own employees and other parts by the external partner. In this way, the employees better understand the robot and the interrelationships of the functions and usually build up their robotics skills faster and more efficiently. In the make approach, companies develop the robots with their own employees or their own RPA resources, i.e. in-house. Either existing employees are trained or new employees with RPA knowledge are recruited. In this approach, employees are responsible for both developing and maintaining the robots without relying on external support. The make approach represents a cost-effective alternative for RPA development and maintenance. However, the approach first requires that the responsible employees have sufficient RPA skills to develop independent robots (see in particular the skills of the RPA developer role in Sect. 3.4.2). Secondly, to develop sufficient skills, there must also be enough processes to be robotized. The make approach significantly increases the acceptance of robotics in companies, but requires an investment in knowledge management and the further training of employees. Although the responsible employees automatically expand their RPA skills by developing robots themselves, targeted training to expand (e.g., linking RPA and analytics, see also Sect. 3.3.3) and deepen the RPA skills is indispensable. The biggest advantage of the make approach is that the employees involved understand the robot down to the smallest detail and can quickly adapt it to changes in the process (e.g., updating the systems addressed). In an offshore approach, parts or the entire process are robotized in an offshore location. The robots developed entirely in the offshore location are used productively in the company on site (onshore location) after completion. A major advantage of an offshore development is its high concentration of RPA skills.79 Numerous examples of offshore centers exist in the market (e.g. in India, Central Eastern Europe), which can support the on-site (onshore) RPA units in robotization in a cost-effective manner. The offshoring approach can be successfully combined with the make approach. This makes onshore units more flexible and allows them to focus on tasks such as error and exception handling. Rather an exception is the sole pursuit of the offshore approach, i.e. ‘stand-alone’. A major reason for this is the lack of in-depth knowledge of local processes at the offshore units. How a process is actually run through in reality, which adjustments are necessary or which changes are planned, is ultimately best known by the employees in the onshore unit due to their proximity to the operational business. The three development approaches presented and the operating models addressed above can be combined in any way. For example, a company can choose a hybrid organizational model but pursue different development approaches depending on the situation in the decentralized functional departments (e.g. make approach in department A, buy approach in B) in order to achieve the desired results more quickly. In contrast, the 79  For example, Daniel Dines, CEO of UiPath sees India as the global hub for RPA; see International Business Times (2018).

3.6 RPA Operating Model

65

current maturity level of robotics in the company has a stronger influence on the decision for a certain RPA development approach (see Sect. 3.1). In the early phase of an RPA introduction (start-up phase), when companies evaluate the functionalities of RPA within the scope of a PoC and test the feasibility, most companies pursue a make or buy approach. Either employees ‘experiment’ and build the first robot themselves or companies hire an external partner to develop it. Both approaches are goal-oriented with the advantages and disadvantages mentioned above. When opting for a buy model in the early phase, it must be ensured that employees are sufficiently involved and can thus build up the RPA skills needed later (e.g. for maintaining the robots). In the next phase, the so-called ramp-up phase, the company’s own employees move more into focus. In this phase, employees responsible for RPA inform their colleagues about the possibilities and advantages of robotics and try to establish a positive attitude towards robotics. The expectations of employees (what can a robot do, what can it not do) towards robotics arise in this phase. Both a make and a buy approach can be used for this. Since communication by internal employees is usually perceived as more authentic than by external consultants, the make approach is to be favored in this phase of communication. In the scale & institutionalize phase, external partners again play a greater role because fundamental decisions on the operating model and other RPA-relevant topics (e.g. RPA governance) are made in this phase. In this phase, RPA and the developed robots are rolled out across the company, which is why a certain level of resources is required. A combination of a make and buy approach is suitable for this. In the last phase, the mature&innovate phase, all three development approaches are often combined, especially in large corporations. The role of the offshore approach increases significantly because the company’s own employees now have the skills to develop and maintain the robots and can therefore define specific requirements for the developers of new robots in the less expensive offshore centers.

3.6.4 Software-as-a-Service Approach for RPA In recent years, so-called Software-as-a-Service (SaaS) models have increasingly established themselves in the software market. Here, companies pay a usage-based rental fee to a service provider for the use of the software, which they use cloud-based (online). Infrastructure, middleware, and software are located in the service provider’s data center. The service provider manages the hardware and software.80 SaaS models are also slowly establishing themselves in the RPA market, which are then referred to as Automation-as-a-Service (AaaS) models. Here, service providers take over the complete RPA operations management, from RPA development to monitoring of the robots as well as proactive adjustments if an irregularity occurs. There are various operating models on the market for AaaS models, with the so-called hybrid cloud being the most 80

 See, for example, Microsoft (2021).

66

3  Introduction of RPA in Financial and Management Accounting

common model. In this model, the robots are located in the customer’s data center. Only the control and administration takes place in the cloud of the service provider. The data exchange is thus limited to the technological level and does not take place at the content level. The data (e.g. personal data, booking data, customer data) that the robot processes in the process therefore never leave the company network. The AaaS model is an interesting alternative for companies to building and operating their own, internal RPA service, which often fails due to resources, especially for SMEs.81

3.7 RPA-Specific Change Management 3.7.1 Basics of Change Management RPA has a profound impact on existing processes, work priorities, and the required competencies of financial and management accounting. In order to successfully master this digital transformation not only professionally, but also humanly, companies use accompanying change management. Simplified, change management refers to [...] the management of change taking into account the human factor [...].82

Change management can be implemented through a variety of general measures and media that start at the level of the individual, the corporate structure, or the corporate culture.83 Change roadmaps, info markets, special change workshops, or dedicated newsletters are just a few examples.84At an info market, the essential topics of robotics can be conveyed to the entire community who is interested in RPA.  Individual information booths provide information about changes through RPA for processes, roles, or organization. The following sections address specific change actions for robotics. To provide a better understanding of the proposed change measures for RPA, the basic effects of RPA on employees are explained first.85 For further information on change management, please refer to the relevant literature.86

 Cf. Dickemann and Obermair (2020), p 72ff.  Lauer (2014), p 7. 83  Cf. Lauer (2014), p 7 f. 84  An overview of general instruments and measures in change management can be found in Vahs and Weiand (2013). 85  Cf. Turi (2020). 86  See, for example, Doppler and Lautenburg (2014) and Kotter (2011); for an overview of empirical results on change management, see, for example, Gärtner (2017). 81 82

3.7 RPA-Specific Change Management

67

3.7.2 Impact of the Introduction of RPA on Employees Robotization in financial and management accounting changes the tasks of employees working there. As soon as a robot is put into production, employees no longer carry out the robotized processes at all or not to the same extent. Previously, employees were responsible for the processing, execution, and control of the process. After the robotization of the process, employees are mainly responsible for the control, because the processing and execution are taken over by robots (see Sect. 3.5.1). The described change represents an enormous change and requires adjustments for employees and managers. Employees  Through the introduction of RPA, certain roles in financial and management accounting will no longer exist in the future. On the other hand, new roles will be created and tasks or focal points of tasks will shift. For example, employees whose tasks are taken over in whole or in part by robots will generally have to take on higher-quality tasks. For example, robots assist controllers with monthly reporting by taking over non-value-added, repetitive activities (e.g., pulling data, copying files). As a result, the controller’s reporting task focus shifts to higher-quality analysis (e.g., commentary). The shift in this task focus should be proactive on the part of the controller, accompanied by appropriate training. In order to identify the activities that employees could perform after robotization, the “meinside” approach can be used (Sect. 3.7.5).  Managers  Robotization is also significantly changing the range of tasks performed by managers. Resources freed up by robotization must be redeployed or restructured. While managers have so far only taken employees (human workforce) into account in resource planning, companies will in future do almost identical planning for robots (digital workforce). In which combination employees and robots are best deployed to complete tasks will be a key task for managers in the future. In addition, managers are entrusted with pointing out to their employees new possibilities and opportunities that arise from robotization (e.g. changes in task content or further training opportunities in the area of robotics). 

3.7.3 Arousing Employee Enthusiasm for RPA One goal of the accompanying change management (or corresponding measures) during the introduction of RPA is to win over employees for the technology and the associated change. A look at practice shows that companies have had different experiences with the introduction of robotics with regard to the reaction of employees. If companies choose a purely top-down approach for the introduction of robotics, i.e. RPA is introduced from the top down by the management level with little communication and exchange, employees often tend to adopt a passive, possibly even destructive attitude towards RPA. The limited communication with employees can lead to a misinterpretation of the motives for robotics.

68

3  Introduction of RPA in Financial and Management Accounting

If companies involve their employees directly in the introduction of robotics (bottomup approach), the employees have a much more constructive attitude towards robotics and show much more understanding for the associated changes. In the bottom-up approach, employees learn themselves, e.g. through Build-Your-Own-Robot workshops, what a robot can do and what its limits are. As a result, they tend to see the robot as a supporter in their daily work, reducing the workload for employees and thus creating more freedom for value-creating tasks. The pharmaceutical company Merck writes appropriately: We recognized that change resistance was decreasing drastically when the operational teams were involved in the implementation right from the beginning or when they even identified the steps to be automated themselves.87

If a company wants to anchor RPA sustainably and in the long term, it will reach its limits relatively quickly with a purely top-down approach. If employees initially adopt a negative attitude towards robots, they will later become less intensively involved in their maintenance, further development, or the identification of new processes that can be robotized. In the case of a long-term anchoring of RPA in the company, employees should be closely involved in the introduction of robotics, which speaks for a bottom-up approach. Employees must be made aware that robots take on repetitive and often time-consuming tasks, which they usually perceive as a burden or as boring. Robotics thus leads to qualitative improvements in daily work and relieves employees. Studies also confirm this connection.88 The linkage of a top-down approach covering the conditions and strategic goals of RPA and a bottom-up approach with motivation, training, development, and change management is most promising to sustainably successful anchor robotics in the organization. However, getting employees sustainably excited about robotics, while at the same time handing over tasks to robots, presents companies with a certain challenge. Successful companies go one step further. In all robotics initiatives, they not only show their employees the benefits of robotics, but also create transparency about the opportunities it offers them. In addition to the benefits to their daily work, companies should show their employees the development potential associated with RPA.  RPA offers a wide range of training opportunities. Since the technology is relatively new, it also creates numerous new job profiles that did not previously exist on the job market in this form. Examples include roles such as RPA developer or RPA architect (Sect. 3.4). These roles bring a variety of new activities and numerous opportunities for employees.

 Pellegrino and Mega (2020), p 41.  Cf. Capgemini (2016), p 33.

87 88

3.7 RPA-Specific Change Management

69

3.7.4 Successfully Embedding RPA in the Organisation A number of change measures support the successful anchoring of RPA technology in the organization. For example, the following measures are specific to RPA: (1) communication, (2) “Me inside”, (3) motivations of the company, and (4) solving problems with robotics. The measures are presented in detail below. Communication  Communication is a key success factor for change processes in companies.89 The form of communication with which RPA is communicated in the company is decisive for the perception of robotics. Our practical experience shows that robotics initiatives with little or no communication are not very successful. The most successful robotics initiatives are not created in isolated boardrooms, but in large communities that involve employees in detail about the benefits and motivations of robotics. Wide-ranging communication with appropriate communication platforms (e.g., community, forum) enables colleagues to talk openly about robotics and address questions as they arise. In addition, internal training offers the opportunity for an open exchange about the technology or the opportunities of robotics.  “Me-Inside”  If RPA is implemented via a bottom-up approach, employees often identify possible processes for robotization themselves (Sect. 3.7.3). Suggestions for new processes to be robotized often come from employees themselves. The point of “me-inside” is that for all processes that can be robotized, the first question is why employees want to robotize a process. What are the employees’ motives? Examples from practice show that employees have answers to these questions, such as “I will have more time for analysis and control”, “we will finish the process faster” or “the processes will be faster and more efficient”. In many cases, the employee’s response already includes activities to which the employee can shift his or her resources that have become free after robotization. As soon as employees have recognized their own advantages from robotization, they support the overall process in a much more motivated and proactive manner than when the company’s motives are the sole focus.  Motives of the Company  In terms of content, the communication on robotics should definitely clearly state the motives of the company. This is less about the concrete operational goals of the RPA introduction, e.g. the productive number of robots by the end of the year, but rather about the reasons why a company wants to use robotics in the first place. Some companies pursue higher productivity with RPA, others the saving of employee resources or an increase in quality. These goals are formulated in short, catchy sentences such as “more time for qualitative tasks” or “more process quality by reducing the error rate”. This should help employees understand the motives for RPA, which is the basis for proactively supporting the initiative. Some companies also use robotics in public relations (PR) by openly and clearly communicating the effects of using robotics and the resulting opportunities for employees outside the company. In terms of content, communication takes the form of interviews  Cf. Vahs and Leiser (2007).

89

70

3  Introduction of RPA in Financial and Management Accounting

printed in company magazines or trade journals, for example. There, employees or managers report on the positive experiences and effects of robotics. These publicly available experiences and motivations regarding RPA are often perceived as authentic by employees and potential applicants. Solving Problems  One of the most important, specific change measures for embedding RPA is the requirement that RPA must solve real, significant problems in the business. Few, small robots tend to bring few benefits. Although small processes can be robotized quickly and easily (e.g., a robot copies individual Excel files into an overall file and captures data in the ERP system), the efficiency gains from this robotization are usually limited. Robots should help solve significant problems, such as reducing employee workload, significantly improving service time, or increasing employee satisfaction. Otherwise, they are classified as a toy instead of a useful tool. For this reason, companies should focus not only on small processes that can be robotized quickly, but on larger, more complex ones. Technically, robotics is capable of effectively supporting most business processes, even if processes require numerous interactions with users or a large number of (binary) decisions. In practice, it can be observed that at the beginning of an RPA implementation, companies often classify the more extensive, daily end-to-end processes as too complex for robotization. Yet it is precisely these processes that offer the highest added value for employees and the company. 

3.7.5 Knowledge Management for RPA How to train and develop employees or recruit new employees is the content of knowledge management. Myers (2014) defines knowledge management as: a formal approach to acquiring, creating, codifying, storing, sharing and using contextualized information, expertise and other intellectual assets to support achieving an objective.90

In order for employees in RPA teams to work successfully, new skills and knowledge must be built up on an ongoing basis. The required skills and knowledge differ depending on the employee group. For this reason, it is advisable to define employee groups or RPA roles as early as possible, such as RPA developer, RPA business analyst, or RPA architect (Sect. 3.4.). In the context of RPA implementation, knowledge management can support these roles in the form of (1) training and (2) a suitable, central communication platform, among other things. Training  Leading RPA vendors such as UiPath, Blue Prism, and Automation Anywhere offer online training that successfully helps employees build new skills.91 The online train Myers (2014), p 30.  For the UiPath Academy see: https://academy.uipath.com/learn, for the Automation Anywhere University see: https://www.automationanywhereuniversity.com/courses

90 91

3.7 RPA-Specific Change Management

71

Fig. 3.30  Objectives of RPA training courses Collaboration

Talents

Continuing education

Fig. 3.31  Development stages for RPA training courses RPA Laboratory Expert trainings Basic trainings

ing courses follow a self-learning approach, in which employees watch tutorial videos online at a flexible time and then solve theoretical or practical tasks. Leading RPA providers also offer certificates tailored to RPA roles, where learning progress is measured on an ongoing basis.92 To build the skills and knowledge of RPA teams, companies should not only rely on freely available online training from RPA vendors, but also organize internal RPA training in presence. Combining internal RPA presence training with online training from a vendor is promising. The target audience of internal RPA training is not only RPA developers, but rather all employees. In order to adjust the content and focus accordingly, different RPA presence training courses should be designed per participant group or per skill level. Not only does training play an important role in building skills and knowledge, but also in Robotics’ internal communication. Training provides a communication platform to convey robotics’ motives and goals to employees. Furthermore, face-to-face training is suitable to identify potential RPA talents and to stimulate collaboration (see Fig. 3.30). For this purpose, a multi-level course model (see Fig. 3.31) with the following three development levels can be used: basic training, expert training, and an RPA laboratory (RPA lab).

92  Cf. e.g. For example, the ‘RPA-Developer Advanced Certification’ from UiPath, which is geared towards the role of the RPA-Developer.

72

3  Introduction of RPA in Financial and Management Accounting

In basic training courses, participants learn about RPA basics and company-specific RPA peculiarities. In addition to the governance guideline, documentation requirements and concrete goals of robotics are also presented there. Basic training courses are usually open to all employees and serve as a communication platform for presenting the advantages and possibilities of RPA.  Especially for new employees (e.g. trainees) basic training is ideal. In basic training, employees learn how to build simple robots (e.g. copy several Excel files into a spreadsheet), e.g. in a ‘Build-Your-Own-Robot-Workshop’. In this way, they understand essential functionality and limitations of robotics, which immediately increases their acceptance of it. Basic training is also a good way for managers to learn about the possibilities of robotics and thus identify processes that can be robotized more easily in the future. Expert training is more focused on robot development and RPA technology with the goal of training future RPA developers (Sect. 3.4.2) for the company. Expert training is composed of different modules (e.g. junior, advanced, senior) depending on the experience of the participants. In the junior module, developers learn how RPA software works, what basic settings can be made, and how robot development works based on existing building blocks that are reused. The advanced module goes one step further and deals with error analysis and exceptions. Special application examples for SAP or Citrix, among others, are trained and analyzed. The senior module focuses on the scalability and robustness of robots. Scalability refers to the combination of several robots that are to perform the same task simultaneously. In this case, for example, the robots involved automatically distribute the pending tasks among themselves, marking the individual positions as soon as they have been processed. Robustness also plays a central role in robots, which should be addressed in the senior module. Robotized processes or robots are considered robust if there is standardized error handling as well as exception handling in the robotized processes. This makes the processes more stable and they can be used in any situation (even during peak times). After employees have attended the internal RPA presence training courses and have successfully used the skills learned, the establishment of an RPA lab is a good idea. Companies pursue different objectives with an RPA lab. In addition to organizing one-day workshops in which, for example, a PoC for a robot is developed, tests with digitization technologies (e.g., OCR, NLP, or process mining) that complement robotics also take place in the RPA lab (see also Sect. 3.3.3). In addition, the participants of the RPA lab discuss different cases that can be robotized and work together on their implementation possibilities. In this way, a lab increases acceptance among employees and supports the agile, dynamic implementation of robotics in the company. Communication Platform  A central communication and knowledge management platform for RPA connects employees, makes formal knowledge accessible and promotes the exchange of experiences. With regard to RPA, a central communication and knowledge management platform allows the exchange of templates (e.g., for capturing processes), documentation on RPA (e.g., processes, RPA governance, RPA platform), contact data of

3.8 RPA Performance Measurement

73

contact persons for RPA in the organization or, by means of a blog/chat function, the exchange of employees. In addition, it is conceivable that an RPA repository is also set up here, in which robots or standardized modules of robots that have been used repeatedly in several processes are managed. An example of a flexible communication and knowledge management platform is Confluence from Atlassian.93 In addition to training courses and a central communication platform, modern event formats such as hackathons94 or championships promote the exchange of information about RPA. Here, employees exchange ideas about the possibilities and potential of robotics in a relaxed environment and present their own projects to each other. Such event formats can also be used to organize cooperation with a college/university or with another company. However, these events only develop their full potential once the company has a sustainable, broad team of RPA developers.

3.8 RPA Performance Measurement With the sustainable introduction of RPA, companies associate a number of goals that are technological, operational, and economic in nature (Sect. 2.2). In order to monitor the pursued goals and benefits of RPA, performance measurement is a useful tool. According to Bourne et al. (2003), performance measurement is defined as follows: A business performance measurement system refers to the use of a multidimensional set of performance measures for the planning and management of a business.95

Transferred to RPA, performance measurement refers to the quantification of RPA performance by means of suitable key indicators. In the following, selected key indicators for the measurement of RPA performance are therefore briefly presented.96 Fig.  3.32 provides an overview of these. For control purposes, the indicators are often bundled in a reporting dashboard that RPA vendors have often already integrated into their solutions (see Fig. 3.33). A first, relatively simple key figure for measuring the performance of RPA is the ‘number of productive robots’. This metric provides an impression of the spread of robotization in the company over time and is therefore often published by companies in case studies. In the form of a target figure (e.g. ‘number of productive robots’), the indicator can also be used for planning and target-setting purposes in the company. In order to be able to better estimate the surveyed number of productive robots, it is useful to relate it to the  www.atlassian.com/de/software/confluence  For more information on hackathons, see Knoll (2017), p 155 ff. 95  Bourne et al. (2003), p 4. 96  The key indicators focus on the measurement of operational performance of robots after the successful introduction of RPA rather than the implementation of the project itself. 93 94

74 Nr

3  Introduction of RPA in Financial and Management Accounting Key figure

Description

Objective

,Number of productive robots or

Number of currently productive robots, either as an absolute total number or normalized to 1,000 employees

Indicator reflects the spread of of robotization in the company

2

,Number of robotized processes

Number of processes currently processes already supported by robots

Key figure reflects in combination with key figure 1, the extent to which robots already support processes (but no statement about the intensity of robotization)

3

'Capacity savings

Capacity freed up by robots capacities, measured in units of time (days, hours, minutes), person-days or FTEs

Indicator reflects the efficiency and efficiency and quality gains achieved quality increases achieved by robots

4

'cycle times'

Time span, usually in minutes or hours from the beginning to the end of a process run

Indicator reflects the achieved by robots efficiency gains achieved by robots

5

'error rates'

Number of defective process runs / Number of total process runs

Indicator reflects the achieved by robots efficiency gains achieved by robots

6

RPA costs

RPA costs according to material and personnel costs, one-time and running costs

Key figure on costs reflects the resource consumption of RPA and form an input variable for profitability calculations

7

'Employee satisfaction

Index key figure from different satisfaction dimensions

Key figure reflects - among other factors - the impact of process process automation with RPA on the general satisfaction of the employees

8

'Uncontrolled turnover rate'

Employee terminations, i.e., all terminations that cannot be not intentionally influenced by the Company departures

Indicator reflects - among other factors - the impact of process automation with RPA on the willingness of the employees

1

Number of productive robots per 1,000 employees'

Fig. 3.32  Overview of key figures for RPA performance measurement

number of employees (as a proxy for the size of the company), e.g. in the form of ‘number of productive robots per 1000 employees’. After all, the use of 50 robots in a large corporation with 250,000 employees is to be evaluated differently than in a medium-sized company with 800 employees. Closely related to the key figure ‘number of productive robots’ is the key figure ‘number of robotized processes’. This figure shows how many processes are already supported by robots and, in combination with the number of robots, provides an insight into how

3.8 RPA Performance Measurement

75

Fig. 3.33  RPA Analytics report – Example UiPath

many processes a robot intervenes in. However, this does not provide any information about the intensity of robotization in processes (robot takes over a single process step vs. robot takes over the entire process). In addition to the number of processes that are actually robotized, the number of processes that are being tested or prepared is also interesting (Sect. 3.2.2). A central motivation for the introduction of RPA is operational efficiency gains. In order to measure the efficiency gains, the first step is to record and regularly monitor the ‘capacity savings’ achieved through the use of robots. Savings can be measured in units of time (days, hours, minutes, etc.), person-days, or FTEs. The metric is intended to track whether the robots introduced are actually freeing up previously planned capacity. The planned capacity savings through the use of robots are an important decision criterion for the selection of processes for robotisation (Sect. 3.2.1). Other metrics that can be considered to measure efficiency gains through the use of robots are ‘cycle times’ (time span in minutes/hours from start to finish of the process) and ‘error rates’ (incorrect process runs/total process runs). Companies often pursue the goal of shortening process cycle times with the use of robots. Therefore, the key figure for the relevant processes should be analyzed before and after the introduction of RPA.  The pharmaceutical company Merck refers to this as recording the baseline performance of the process.97The key figure ‘error rate’ is similar. If the error rate is to be reduced by the use of robots, the comparison of this key figure before and after the introduction of RPA shows

97

 Cf. Pellegrino and Mega (2020), p. 41.

76

3  Introduction of RPA in Financial and Management Accounting

whether this objective has been achieved. How the two key figures ‘cycle time’ and ‘error rate’ are calculated in individual cases depends on the respective process. Another advantage of RPA is the often (relatively) low costs combined with a high ROI compared to other automation solutions (Sect. 2.2.1). However, practical experience to date shows that the costs for an RPA implementation can rise quickly, among other things due to the use of external consulting support. In order to systematically record the costs as a key figure for the introduction and operation of RPA, several cost types should be recorded separately: on the one hand, the material costs associated with RPA (e.g. license costs, consultant costs, hardware costs) and, on the other hand, the personnel costs caused by RPA (e.g. salaries, training). The cost types can be further divided into one-time costs (e.g. hardware costs, consultant costs for RPA setup) and ongoing costs (e.g. license costs for robots). By comparing the costs of RPA and the (monetarily evaluated) increase in efficiency achieved with it (e.g. through shorter throughput times, lower error rates, or capacity savings), profitability calculations can be made. Finally, the key figure ‘employee satisfaction’, which is usually calculated in the form of an index, can also provide a statement on the performance of RPA.98The lack of available skilled workers on the labor market means that companies do not want to lose employees due to their dissatisfaction with company processes or activities. The logic behind this is that through process automation with RPA, employees are more satisfied with their jobs because they are freed from simple, repetitive tasks and can focus on more value-added tasks. As a result, employee retention increases and turnover decreases. Therefore, in addition to ‘employee satisfaction’, the key figure ‘(uncontrolled) turnover rate’99could also be collected in departments that already use RPA.

Literature Aguirre S, Rodriguez A (2017) Automation of a Business Process Using Robotic Process Automation (RPA): A Case Study, in: Figueroa-García JC, López-Santana ER, Villa-Ramírez JL, Ferro-­ Escobar R (eds) 4th Workshop on Engineering Applications, WEA 2017 Cartagena, Colombia, September 27–29, 2017 Proceedings, S 65–71 Anagnoste S (2018) Setting Up a Robotic Process Automation Center of Excellence, in: Management Dynamics in the Knowledge Economy, Vol. 6, No. 2, S 307–322 Arbeitskreis Shared Services der Schmalenbach-Gesellschaft für Betriebswirtschaft e.V. (2017) Digitale Transformation und Leadership, in: Shared Service Organisationen. Krause, S/Pellens, B (eds.) Betriebswirtschaftliche Implikationen der digitalen Transformation. ZfbF-Sonderheft (72/17): S 29–48

 Cf. Sattelberger and Scholz (2012), p. 120 ff.  The ‘(uncontrolled) turnover rate’ only includes employee terminations, retirement and death of employees, i.e. all departures from the company that cannot be deliberately influenced by the company. This type of resignation usually occurs either because of dissatisfaction or because an even more attractive job could be found. Cf. Sattelberger and Scholz (2012), p. 127 f. 98 99

Literature

77

Automation Anywhere (2018) Enterprise Architecture for the Intelligent Digital Workforce, retrieved on 01.07.2019 at: https://www.automationanywhere.com/images/Enterprise-­Architecture.pdf AWS-Institut (2019) Was kann automatisiert werden? retrieved on 11.12.2018 at: https://www.aws-­ institut.de/rpa-­hmi/#!/qualit%C3%A4t Beisswenger A, Schlott A, Von Hirschausen G, Küster T, Hamann K, Leser C (2020) Robotic Process Automation im Accounting  – Beispiele von ProSiebenSat.1, KION und PwC, in: REthinking Finance, 03/2020, S 17–26 Biel (2021) Robotisierung im Controlling?, Interview mit Prof. Dr. Christian Langmann, in: Controller Magazin, 03/2021, S 13–17 Bleicher K (1991) Prozessoptimierung vor Automatisierung, 2. Aufl. Springer Gabler. Wiesbaden Bourne M, Neely A, Mills J, Platts K (2003) Implementing performance measurement systems: a literature review, in: International Journal of Business Performance Management, Vol. 5, No. 1, S 1–24 Capgemini (2016) Robotic Process Automation – Robots conquer business processes in back office, retrieved on 15.05.2019 at: https://www.capgemini.com/consulting-­de/wp-­content/uploads/ sites/32/2017/08/robotic-­process-­automation-­study.pdf Capgemini (2019) Center of Excellence & Operating Models: Why RPA is more than just a software, retrieved on 15.05.2019 at: https://www.capgemini.com/de-­de/2017/09/ why-­rpa-­is-­more-­than-­just-­a-­software/ CoSourcing Partners (2018) Robotic Process Automation Salary Guide 2018, retrieved on 15.05.2019 at: https://cosourcingpartners.com/wp-­content/uploads/2018/01/CoSourcing-­Partners-­RPA-­ Salary-­Guide-­2018.pdf Czarnecki C, Auth G (2018) Prozessdigitalisierung durch Robotic Process Automation, in: Barton T, Müller C, Seel C (eds) Digitalisierung in Unternehmen – Von den theoretischen Ansätzen zur praktischen Umsetzung, S 113–132, 1. Aufl. Springer. Wiesbaden Dauti B (2019) Installing and Configuring Windows 10, 1. Aufl. Packt Publishing. Birmingham Deloitte (2017) Robotic Process Automation in FSI, retrieved on 15.05.2019 at: https://www2. deloitte.com/content/dam/Deloitte/de/Documents/financial-­services/20171127_Robotics%20 Event_Transscript%20(003).pdf Deloitte (2018) The robots are ready. Are you? retrieved on 18.03.2019 at: https://www2.deloitte. com/content/dam/Deloitte/tr/Documents/technology/deloitte-­robots-­are-­ready.pdf Dickemann T, Obermair A (2020) Automation as a Service: Robotic Process Automation wird erwachsen, in: REthinking Finance, 03/2020, S 70–75 Doerr J (2018) Measures What Matters, 1. Aufl. Portfolio. New York Doppler K, Lautenburg C (2014) Change Management: Den Unternehmenswandel gestalten, 13. Aufl. Campus Verlag. Frankfurt am Main European Association of Business Process Management (2009) (eds.) Business Process Management – Common Body of Knowledge – BPM CBOK, Band 1, Version 2.0, 1. Aufl. Verlag Dr. Götz. Gießen Forrester Research (2018) Harness RPA To Optimize Customer Outcomes, October 2018, retrieved on 01.03.2019 at: https://dfe.org.pl/wp-­content/uploads/2018/12/Forrester_Harness-­RPA.pdf Fröhlich M, Glasner K (eds.) (2007) IT Governance  – Leitfaden für eine praxisgerechte Implementierung, 1. Aufl. Springer Gabler. Wiesbaden Gadatsch, A (2017) Grundkurs Geschäftsprozess-Management, 8. Aufl. Springer Gabler. Wiesbaden Gaitanides M (2012) Prozessorganisation, 3. Aufl. Franz Vahlen. München Gartner (2017) Market Guide for Robotic Process Automation Software, retrieved on 01.05.2019 at: https://www.gartner.com/doc/3835771/market-­guide-­robotic-­process-­automation Gartner (2021): Citizen Developer, retrieved on 01.053.202119 at: https://www.gartner.com/ it-­glossary/citizen-­developer/

78

3  Introduction of RPA in Financial and Management Accounting

Gärtner C (2017) Weisheit oder Wirklichkeit? in: changement! Ausgabe Januar/Februar 2017, S 40–41 Hammer M, Champy J (2003) Business Reengineering: Die Radikalkur für das Unternehmen, 7. Aufl. Campus Verlag. Frankfurt am Main Helm L-V, Janiesch C, Helm A, Imgrund F, Fuchs K, Hofmann A, Winkelmann A (2020) A Consolidated Framework for Implementing Robotic Process Automation Projects, in: Fahland D, Ghidini C, Becker J, Dumas M (eds) Business Process Management, BPM 2020, Lecture Notes in Computer Science, Vol 12,168, S 471–488, Springer, Cham Hermann K, Stoi R, Wolf B (2018) Robotic Process Automation im Finance & Controlling der MANN+HUMMEL Gruppe, in: Controlling  – Zeitschrift Für Erfolgsorientierte Unternehmenssteuerung, 3/2018, S 28–34 Horváth & Partners Management Consultants (2015) (eds.) Finance-Prozessmodell: Leitfaden für die Beschreibung und Gestaltung von Rechnungswesen, Steuern und Treasury, 1. Aufl. Haufe Lexware. Freiburg Hyland (2020) Hyland schließt Akquisition von RPA-Softwareanbieter Another Monday erfolgreich ab, retrieved on 01.04.2021 at: https://www.hyland.com/de-­DE/learn/press-­releases/de-­de/ hyland-­another-­monday International Business Times (2018) Robotic process automation and AI is the future, retrieved on 01.06.2019 at: https://www.ibtimes.sg/robotic-­process-­automation-­ai-­future-­india-­bangalore­singapore-­rpa-­summit-­2018-­23249 International Group of Controlling (2017) (eds.) Controlling-Prozessmodell 2.0: Leitfaden für die Beschreibung und Gestaltung von Controllingprozessen, 2. Aufl. Haufe Lexware. Freiburg Isensee J, Ostrowicz S, Reuschenbach D (2018) RPA im Controlling  – Steigerung der Effizienz im Reporting durch Robotic Process Automation, retrieved on 28.02.2019 unter https://www. horvath-­partners.com/fileadmin/user_upload/WP_RPA_im_Controlling_web_g.pdf King R (2018) Digital Workforce: Reduce Costs and Improve Efficiency using Robotic Process Automation, 1. Aufl. CreateSpace Independent Publishing Platform Knoll N (2017) „HackHPI“: How to organize a Hackathon, in: Knoll T (eds.) Veranstaltungen 4.0 – Konferenzen, Messen und Events im digitalen Wandel, S 155–170, 1. Aufl. Springer Gabler. Wiesbaden Koch C, Fedtke S (2020) Robotic Process Automation: ein Leitfaden für Führungskräfte zur erfolgreichen Einführung und Betrieb von Software-Robots im Unternehmen, 1. Aufl. Springer Vieweg, Berlin Kotter JP (2011) Leading Change, wie Sie Ihr Unternehmen in acht Schritten erfolgreich verändern, 1. Aufl. Franz Vahlen. München KPMG und FhG FIT (2017) Digital Finance  – Ergebnisse einer empirischen Untersuchung zur Digitalisierung im Finanzbereich, Studie der KPMG und des Fraunhofer-Institut für Angewandte Informationstechnik FIT Langmann C (2020) Robotic Process Automation als Wegbereiter eines modernen Rechnungswesens, in: REthinking Finance, 03/2020, S 4–8 Langmann C (2021) Robotic Process Automation (RPA)  – Study on Characteristics of Successful RPA Implementations, retrieved on 18.03.2021 at: https://w3-­mediapool. hm.edu/mediapool/media/fk10/fk10_lokal/05_diefakultt/03_personen/langmann/ final_rpa_study_2021_results_report_010221_web_kl.pdf Lauer, T (2014) Change Management  – Grundlagen und Erfolgsfaktoren, 2. Aufl. Springer, Wiesbaden Leurs B, Duggan K (2018) Proof of concept, prototype, pilot, MVP – what’s in a name?, Nesta, retrieved on 01.04.2021 at: https://www.nesta.org.uk/blog/proof-­of-­concept-­prototype-­pilot-­ mvp-­whats-­in-­a-­name/

Literature

79

Microsoft (2020) Microsoft acquires Softomotive to expand low-code robotic process automation capabilities in Microsoft Power Automate, retrieved on 01.04.2021 at: https://flow.microsoft.com/ en-­us/blog/microsoft-­acquires-­softomotive-­to-­expand-­low-­code-­robotic-­process-­automation-­ capabilities-­in-­microsoft-­power-­automate/ Microsoft (2021) What is SaaS? – Software as a service, retrieved on 01.04.2021 at: https://azure. microsoft.com/en-­us/overview/what-­is-­saas/ Murdoch R (2018) Robotic Process Automation, 1. Aufl. Independently published Myers PS (2014) A normative model of knowledge management effectiveness, in: Örtenblad A (eds.) Handbook of research on knowledge management: adaptation and context, 28–52, 1. Aufl., Edward Elgar Publishing. Northampton Neagu M (2021) Understanding Citizen Developers: Your Secret Weapon in Scaling Automation, retrieved on 01.05.2021 at: https://www.uipath.com/blog/understanding-­citizen-­developers-­ your-­secret-­weapon-­in-­scaling-­automation Nintex (2018) What is a citizen developer and where do they come from?, retrieved on 01.05.2021 at: https://www.nintex.com/blog/what-­is-­a-­citizen-­developer/ Noppen P, Beerepoot I, van de Weerd I, Jonker M, Reijers HA (2020) How to Keep RPA Maintainable?, in: Fahland D, Ghidini C, Becker J, Dumas M (eds) Business Process Management, BPM 2020, Lecture Notes in Computer Science, Vol 12,168, 453–470, Springer, Cham Obermeier W (2020) Financial Process Automation: Neue Chancen im Rechnungswesen, in: ReThinking Finance 03/2020, 27–32 Paal BP, Pauly DA (eds.) (2018) Datenschutz-Grundverordnung, Bundesdatenschutzgesetz, 2. Aufl. C.H. Beck. München Peikari C, Chuvakin A (2004) Security Warrior, 1. Aufl. O’Reilly Media. Sebastopol Pellegrino M, Mega P (2020) Robotics Process Automation @ Merck, in: ReThinking Finance 03/2020, 33–42 Petersen J, Schröder H (2020) Entwicklung einer Robotic Process Automation RPA-Governace, in: HMD Praxis der Wirtschaftsinformatik, Vol. 57, Issue 6, 1130–1149 Plattfaut R, Koch JF, Trampler M, Coners A (2020) PEPA: Entwicklung eines Scoring-Modells zur Priorisierung von Prozessen für eine Automatisierung, in: HMD Praxis der Wirtschaftsinformatik, Vol. 57, Issue 6, 1111–1129 Pottruck DS (2014) How to Lead Breakthrough Change Against Any Odds, Jossey-Bass, San Francisco PWC (2018) Digitalisierung im Finanz- und Rechnungswesen und was sie für die Abschlussprüfung bedeutet, retrieved on 18.03.2019 at: https://www.pwc.de/de/im-­fokus/digitale-­abschlusspruefung/ pwc-­digitale-­abschlusspruefung-­2018.pdf Roth-Dietrich G (2018) Grundlagen und Methoden der Wirtschaftsinformatik: Eine anwendungsorientierte Einführung, 1. Aufl. BoD – Books on Demand. Norderstedt Sattelberger T, Scholz C (2012) Human Capital Reporting, München Schmelzer A (2020) Robotics Process Automation im Mittelstand am Beispiel Wien Energie, in: ReThinking Finance 03/2020, 36–69 Süddeutsche Zeitung (2018) Alles schon digital? retrieved on 01.05.2019 at: https://www.sueddeutsche.de/wirtschaft/digitalisierung-­alles-­schon-­digital-­1.3983161 Tripathi AM (2018) Learning Robotic Process Automation, 1. Aufl. Packt Publishing. Birmingham Tröndle R (2020) Robotic Process Automation – die Magie der Governance, in: REthinking Finance, 03/2020, 59–64 Turi D (2020) Menschen und Roboter – Die Rolle von Change Management bei RPA, in: REthinking Finance, 03/2020, 54–58 UiPath (2021) UiPath StudioX, retrieved on 01.03.2021 at: https://www.uipath.com/de/ product/studiox

80

3  Introduction of RPA in Financial and Management Accounting

UiPath (2021a) The Forrester Wave™ Robotic Process Automation, Q12 2021, retrieved on 01.05.202119 at: https://www.uipath.com/de/resources/automation-­analyst-­reports/ forrester-­wave-­rpa UiPath (2021b) 2020 Gartner Magic Quadrant for Robotic Process Automation, retrieved on 01.05.2021 at: https://www.uipath.com/resources/automation-­analyst-­reports/gartner-­magic-­quadrant-­ robotic-­process-­automation UiPath (2021c) Automating Finance & Accounting, White Paper, retrieved on 01.03.2021 at: https:// www.uipath.com/solutions/whitepapers/rpa-­will-­transform-­finance-­accounting Vahs D, Leiser W (2007) Change Management in schwierigen Zeiten: Erfolgsfaktoren und Handlungsempfehlungen für die Gestaltung von Veränderungsprozessen, 2. Aufl. Deutscher Universitätsverlag. Wiesbaden Vahs D, Weiand A (2013) Workbook Change Management: Methoden und Techniken, 2. Aufl. Schäffer-Poeschel. Stuttgart Van der Aalst W (2012) Process Mining, in: Communications of the ACM, Vol. 55, Issue 8, 76–83 Van der Aalst W (2016) Process Mining – Data Science in Action, 2. Auflage, Springer, Heidelberg Watkins JE (2009) Agile testing: how to succeed in an extreme testing environment, Cambridge University Press, New York Weber J (2018) Robotics wird so selbstverständlich sein wie Elektrizität – Interview mit Marcus Kuhnert (CFO Merck), in: Controlling & Management Review, 8/2018, 24–29 Wenning A, Przytulla G (2020) Robotic Process Automation im Controlling, in: REthinking Finance, 03/2020, 9–16 Wenzel, S (2020) Robotic Process Automation – das Altsystem von morgen oder doch Beschleuniger digitaler Transformation?, in: REthinking Finance, 03/2020, 43–48 Wentges P (2002) Corporate Governance und Stakeholder-Ansatz – Implikationen für die betriebliche Finanzwirtschaft, 1. Aufl. Deutscher Universitätsverlag. Wiesbaden Whitaker S (2021) Microsoft named a Leader in the 2021 Forrester Wave for Robotic Process Automation, in: Blog Microsoft, retrieved on 01.05.2021 at: https://flow.microsoft.com/en-­us/ blog/microsoft-­named-­a-­leader-­in-­the-­2021-­forrester-­wave-­for-­robotic-­process-­automation/ Willcocks L, Hindle J, Lacity M (2019) Keys to RPA Success, retrieved on 01.04.2021 at: https:// www.blueprism.com/uploads/resources/white-­papers/KCP_Summary-­Executive_Research_ Report_Final.pdf Ying LM (2018) Robotic Process Automation with Blue Prism Quick Start Guide: Create software robots and automate business processes, 1. Aufl. Packt Publishing. Birmingham Zeiss S, Jenesl P (2020) Robotic Process Automation als Enabler für Digitale Transformation – Ein Erfahrungsbericht der Telekom, in: REthinking Finance, 03/2020, 51–53

4

From RPA to IPA: How Software Robots Are Becoming Smarter

4.1 Evolution from RPA to IPA The new or further development of numerous digitization technologies in recent years has contributed to the evolution of RPA into so-called IPA. IPA combines RPA with other digitization technologies in order to give classic software robots more advanced (cognitive) capabilities. The ability to process complex data structures should make the connection clear. Today, RPA is dependent on structured data. Structured data (e.g. numbers, tables) are characterized by the fact that structuring information is available for them, by which the data is defined. This so-called metadata provides information about the format, permitted values, or semantic meaning of the data, among other things. In the case of semi-structured data (e.g. e-mail), the metadata is only available for part of the data because only individual components are structured. In the case of unstructured data (e.g. video, images), on the other hand, the structured information is completely missing or unrecognizable.1 By using additional technologies such as optical character recognition (OCR) or natural language processing (NLP), robots are now able to capture, understand and process unstructured and thus complex data such as texts. However, the link with digitization technologies does not only give robots the ability to process unstructured data. Rather, software robots are being equipped with such cognitive capabilities through artificial intelligence (AI) technologies2 that they can perform even more complex analyses and make cognitive decisions or imitate human decisions.3 An example of a customer service decision made by IPA might look like this. The robot first

 Cf. Baars/Kemper (2008), p 132f; Piro/Gebauer (2008), p 146.  For an overview of technologies and subfields of AI, see, for example, Houy et al. (2020). 3  Cf. Ng et al. (2021). 1 2

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2022 C. Langmann, D. Turi, Robotic Process Automation (RPA) - Digitization and Automation of Processes, https://doi.org/10.1007/978-3-658-38692-4_4

81

82

4  From RPA to IPA: How Software Robots Are Becoming Smarter Categories

Rule-based automation

Intelligent automation

Degree of standardization

High

Low

Data sources

Structured

Unstructured

Decision basis

Rule-based

Experience-based

Exceptions

only a few possible,mostly requiring user intervention; number remains constant

Human interaction

none or only extremely limited

any number possible that trigger machine learning; number thereby decreasing interactive social system

Fig. 4.1  Differentiation RPA vs. IPA. (Cf. Hermann et al. 2018, p 29)

uses OCR to read and structure information such as text or numbers from scanned customer letters or directly from customer emails. The robot then uses NLP to evaluate the texts of the customer inquiries and classifies them according to whether the inquiry is a complaint or a neutral inquiry about a product or service. Based on this classification, the robot can then forward the request to the responsible customer service.4 Fig. 4.1 illustrates the differences between RPA and IPA. According to Ng et al. (2021), the evolution from RPA to intelligent process automation can be divided into different stages (Fig. 4.2). According to this, IPA is only the first stage of intelligent process automation. IPA still needs interactions with human users to make correct decisions if the decision situations are not based on clear if-then rules or already known through sufficient training. In the second stage, Ng et al. (2021) refer to the stage as Augmented Intelligent Process Automation, the cognitive abilities of robots improve to increasingly make their own decisions in the context of process automation. The robots learn to do this by observing or processing human decisions that users make. Level four, full automation (autonomous agents), can handle highly complex processes independently. Full automation is self-managing, self-learning, and self-healing when errors occur. It, therefore, no longer requires any intervention by the user.5 A study by McKinsey (2018), among others, shows what the development towards more intelligent process automation means for companies. According to this study, the use of IPA increases the range of applications for process automation, i.e. the number of possible processes for automation. In addition, there are further advantages compared to RPA, such as higher process quality and shorter throughput times.6 A study by the Munich University of Applied Sciences shows that about 2/3 of the companies already link RPA with other digitization technologies and thus apply IPA. In  Cf. Wittenburg/Tyroller (2020), p 77.  Cf. Ng et al. (2021); Schmelzer (2020). 6  Cf. Jogani et al. (2018), p 66 f. 4 5

4.2 Technologies in Use at IPA

83

Decision support for exception handling, quality control and smartness

Autonomous agents

Augmented intelligent process automation

Intelligent process automation Robotic process automation

Fig. 4.2  Stages of Intelligent Process Automation. (Cf. Ng et al. 2021, p 6)

detail, it shows that although the companies primarily link their RPA solutions with OCR technologies, some of the companies also already link RPA with more modern technologies such as machine learning or process mining.7 Therefore, the following sections provide a more detailed insight into the various technologies that transform RPA into IPA.

4.2 Technologies in Use at IPA The technologies used within the context of IPA can be structured along the capabilities they add to classical RPA. Following the structure of Bornet et al. (2021), the following sections consider the following capabilities8: • ‘Seeing’  – recognising and processing visual elements such as scanned documents or images. • ‘Speaking’ – reading, understanding, and generating natural language or texts. • ‘Think & learn’ – perform complex data analysis, make cognitive decisions, and learn from experience.

 Cf. Langmann (2021).  Cf. Bornet et al. (2021), p. 114ff.

7 8

84

4  From RPA to IPA: How Software Robots Are Becoming Smarter

The technologies presented in these three dimensions can be linked together in any combination or used in isolation with RPA.

4.2.1 Technologies for ‘Seeing’ In the following, we will focus on technologies that help software robots to ‘see’ better. To do this, one must first understand how classical software robots actually ‘see’. Robots usually use so-called (technical) selectors to recognize the elements they are supposed to capture or read. The robot finds (or ‘sees’) the elements (e.g. fields, buttons) that it is supposed to access or click on in an application by means of underlying technical specifications of these elements. In practice, however, software robots encounter situations during the processing of business processes in which technical selectors are not available or are unreliable, i.e., no usable technical specifications are available. An example of this would be a document scanned as an image (e.g. invoice) or the use of a virtual desktop (e.g. Citrix). For the robot, the scanned document or the virutal desktop is then a single image without recognizing elements in it (e.g. text, numbers). In order to recognize (‘see’) the relevant elements in it as well, the software robot needs additional technologies. Three of them are briefly presented below.

4.2.1.1 Optical Character Recognition (OCR) OCR is a technology for optical character recognition that can extract relevant content (e.g. text, numbers) from stored or scanned images and documents (digitally) and thus make them digitally readable or processable. For example, OCR technology can convert typed, handwritten, or printed text into digitally encoded text and pass it to a software robot for further use. For example, OCR can be used to extract the invoice amount from an incoming invoice scanned as an image and pass it to a software robot, which then enters it into the designated field of the accounting program. You could say that OCR thus acts as the eye of the robot.9 OCR engines from Microsoft10 or Google11 can be integrated comparatively easily into RPA solutions or are already integrated. OCR has been attracting a great deal of attention in the financial sector for years. For example, companies use OCR to read the relevant key data from incoming invoices from suppliers  – PDF or paper format  – and process them automatically. A 2016 study by Deloitte Austria concluded that around 50% of companies use OCR technologies in accounting.12 Another study by KPMG shows that the spread has continued to increase in recent years and will continue to increase, as e-billing, for example, has not become  See Patel et al. (2012); NICE (2021).  Cf. https://azure.microsoft.com/de-de/services/cognitive-services/computer-vision/ 11  Cf. https://cloud.google.com/vision/ 12  Cf. Deloitte (2016), p 13 f. 9

10

4.2 Technologies in Use at IPA

85

Fig. 4.3  Automatic OCR text recognition when entering an invoice document in Lexoffice. (Cf. Lexoffice 2021)

e­ stablished in many areas.13 Modern finance and accounting systems often already have OCR technologies integrated (see e.g. Fig. 4.3).

4.2.1.2 Intelligent Character Recognition (ICR) OCR’s underlying technology has evolved significantly over the past decades. In the past, the extraction performance of previous OCR technologies was not always satisfactory, especially for documents with poor quality, handwritten notes, or complex content, resulting in manual rework. Due to the increasing advancement of technologies, OCR can now extract the relevant information even from documents with low print quality such as faxes or photocopies as well as from documents with complex content (e.g. mixing mathematical formulas and handwriting) with the help of AI.14 If OCR is extended to include AI algorithms, such as those from the field of machine learning (Sect. 5.2.3.2), the term intelligent character recognition (ICR) is used. ICR has, among other things, considerably expanded the field of application of OCR. ICR not only extracts text but also checks the plausibility of the captured text context-sensitively with the help of linguistic principles, grammar, and dictionaries, and corrects the results itself in the event of errors. An example should clarify the context. While OCR can only read the text ‘5auce’ from a document, ICR recognizes with the help of grammatical principles that

13 14

 Cf. KPMG (2020), p 12, 32.  Cf. Berchmans/Kumar (2014).

86

4  From RPA to IPA: How Software Robots Are Becoming Smarter

words with a digit at the beginning and a capital letter in the word do not exist. ICR now automatically corrects the word or makes a suggestion for it, for example ‘sauce’.15 Especially for the classification of documents (e.g. classification of incoming invoices in accounting) and the recognition of a variety of different document (contents) (e.g. invoices with different layouts and handwritten notes etc.) the use of ICR leads to higher throughput rates or less manual controls.16

4.2.1.3 Computer Vision Computer vision comprises algorithms from the field of AI that can be used to identify objects, scenes, and activities in images (or on screens). Computer vision first breaks down images into manageable, smaller parts. Techniques for recognizing the edges and textures of objects in an image help in this process. Using further classification techniques, computer vision can then determine whether the features identified in an image are likely to represent a type of object that is already known from the past. One well-known application of computer vision is the facial recognition software that Facebook uses to identify people in photographs.17 Software robots, when combined with computer vision, are able to recognize buttons, input fields, or check boxes even when no technical selectors are present.18 Thus, computer vision in combination with RPA is suitable for the use of a virtual desktop, for example, since the robot would otherwise only recognize an image and no technical selectors. 4.2.1.4 Application Example RPA & OCR/ICR Wittenburg/Tyroller (2020) report an application example where RPA is endowed with the ‘seeing’ capability through OCR. The initial situation is as follows. In a company in the aviation industry, three employees read the relevant data from more or less standardized scans or photos – for example, photos of sickness certificates – and transfer them manually to the target systems. This step is performed up to 280 times a day. By using RPA in combination with OCR, the relevant data is now extracted and validated regardless of the scan format. The software robot further processes the extracted information into the target systems or involves an employee for quality assurance in case poor image quality results in insufficient information being obtained. By using IPA, this company was able to reduce the processing time per case from 5 to 1 min.19

 Cf. Ten Hompel et al. (2008), p. 18.  See Capgemini (2018); Ling et al. (2020); Ptucha et al. (2019). 17  Cf. Deloitte (n.d.); SAS (2021a); Szeliski (2010). 18  Cf. UiPath (2021). 19  Cf. Wittenburg/Tyroller (2020), p 79. 15 16

4.2 Technologies in Use at IPA

87

4.2.2 Technologies for ‘Speaking’ As already mentioned above, software robots cannot process unstructured data such as texts or understand natural language. Although the software robot can copy, cut or paste the text, i.e. the words themselves, it cannot understand their meaning. In the following, we will focus on natural language processing (NLP), natural language understanding (NLU) and natural language generation (NLG), technologies that provide software robots with this ability and thus enable them to understand and generate natural language and texts.

4.2.2.1 Natural Language Processing (NLP) & Natural Language Understanding (NLU) NLP is simply about processing natural language.20 Algorithms recognize and analyze spoken or written language.21 The analysis performed by NLP can be used, for example, to categorize content, to recognize topics, to analyze mood, or to convert speech into text. Thus, NLP is able to transform the unstructured data source ‘speech’ into structured and analyzable data.22 NLP processes texts (e.g. questions) by algorithms searching for keywords or word patterns in order to find the appropriate answer. NLU (natural language understanding) as a component of NLP tries to understand the meaning of the text, e.g. a question or a statement in detail. To do this, algorithms must be able to understand grammar and context.23 NLP & NLU face a number of challenges. For example, a word or word pattern not only has regional characteristics (e.g. accent, dialect) but can change its meaning depending on the sentence or context in which the word is used. For example, in English, a ‘star’ can be either a star or a well-known personality. Further examples are shown by Hamilton et al. (2016).24 For example, the English word ‘insane’ has either a positive or negative connotation depending on the context in which it is used (see Fig. 4.4). In the last 20 years, NLP & NLU have evolved considerably to meet these challenges, partly due to the massive increase in computing power of computers and the progressive development of machine learning algorithms.25 The range of applications of NLP is wide.26 In finance, for example, NLP can be used to detect fraud by analyzing textual information in financial statements.27 In customer service, for example, the combination of RPA and NLP can be used to classify incoming  See further on NLP at https://nlp.stanford.edu or The Stanford NLP Group (2019).  Cf. Houy et al. (2020); Nadkarni et al. (2011). 22  Cf. SAS (2021b); Zhang (2019), p 71. 23  Cf. Kavlakoglu (2021). 24  Cf. Hamilton et al. (2016). 25  Cf. Chowdhury (2005), p 55; Hirschberg/Manning (2015), p 26. 26  Cf. Fisher et al. (2016). 27  See, for example, Chen et al. (2017). 20 21

88

4  From RPA to IPA: How Software Robots Are Becoming Smarter

“big men are very soft“

soft

"freakin raging animal“

animal

"went from the ladies tees"

ladies

“two doqsfiahtina“ “being able to hit" "insanely difficult saves“

“some soft pajamas“ “stuffed animal“ “lovely ladies"

dogs

“hiking with the dogs“

hit

"it didn't really hit me“ "a difficult time"

difficult shot

“totally shot me down"

*he is still crazy good“

crazy

"overreacting crazy woman“

“his stats are insane“

insane

“amazing shot"

Ex. Contexts in r/sports

"people are just insane“ -10

more positive in sports community, More negative in female/gender community

-5

-0

5

10

Ex. Contexts in r/TwoX

more positive in female/gender community More negative in sports community

Fig. 4.4  Meaning of words depending on context (here: online communities). (Cf. Hamilton et al. 2016)

e-mails from customers based on their sentiment (‘emotional mood’) and magnitude (‘strength of mood’), whereupon a response e-mail matching the customer’s mood can be automatically generated and sent.28

4.2.2.2 Natural Language Generation (NLG) Simplified, one could say that NLG is the counterpart of NLP, although NLG is strictly speaking – besides NLU – another component of NLP.29 While NLP is more about understanding and processing text, NLG focuses on generating it. NLG can thus be described as automatic text generation. By combining NLG systems with further technologies from AI (e.g. neural networks), they are able to generate qualitative text of such high quality and richness of variants that readers usually cannot distinguish them from texts written by humans. The areas of application are diverse and range from the creation of journalistic reports for sporting events, to weather reports, to stock market or stock reports.30 In the financial area, NLG is used for (management) reporting, for example. Union Investment uses NLG to automatically generate activity reports for investment funds.31 4.2.2.3 Application Example RPA & NLG The link between RPA and NLG is illustrated by the practical example of an international bank (Fig. 4.5) reported by Arria (2021). At the bank, the data required for a reporting dashboard is scattered in several systems due to numerous acquisitions in recent years. The bank, therefore, initially uses software robots to collect the data in a central system.  Cf. on sentiment score and magnitude score e.g. Google (2021).  Cf. Kavlakoglu (2021). 30  Cf. Celikyilmaz et al. (2018); Siebert/Sommer (2020). 31  Cf. Siebert/Sommer (2020), p. 30 f. 28 29

4.2 Technologies in Use at IPA

Systems

89

RPA Instantly performed the tedious human tasks of assembling data from disparate Systems. BI Dashboards Provided illustrative two-dimensional visuals of the newly aggregated data.

RPA

Data Assembled

NLG Instantly produced expert narrative that explained insights found both within the displayed BI visuals and also within all of the underlying data.

BI Dashoard Visuals

NLG

Actionable Insights

BI Dashboard Narratives

Fig. 4.5  RPA & NLP Workflow. (Cf. Arria 2021, p 15)

The bank uses Microsoft Power BI as its dashboard solution. Power BI provides a dashboard with analytics and visual elements based on the data brought together by the robot. Using an NLG system integrated with Power BI, a text commentary is now generated based on the data in the dashboard, explaining relevant findings from the data in textual terms.32

4.2.3 Technologies for Thinking & Learning RPA today cannot think or learn. Thus, classic software robots cannot perform complex analyses, make cognitive decisions (based on these) or learn from mistakes made during repeated process execution. The ability to think, for example, in order to analyze complex data (e.g., with the help of statistical algorithms) and to recognize anomalies and patterns in it, can only be achieved by linking robots with technologies from the field of AI, such as machine learning. Through the combination with process mining, RPA obtains another special capability. This technology can be used, for example, to analyze how business processes in the company actually (not conceptually) run. As a result, the potential for optimization is identified and additionally if the process is suited for RPA. Thus, process mining provides RPA with the capability of process analysis, which today often takes place manually in RPA implementations. The two technologies process mining and machine learning are presented in more detail below.

32

 Cf. Arria (2021), p 14 f.

90

4  From RPA to IPA: How Software Robots Are Becoming Smarter

4.2.3.1 Process Mining Process mining is a technology to analyze and improve business processes based on event data. Event logs are created whenever people, machines, or software perform an activity and this activity is recorded in information systems. This can be events such as a customer order entered into SAP, a passenger checking in for a flight, or a doctor changing a patient’s dosage. The amount and availability of event data has increased significantly in recent years, which in turn provides the basis for the application of process mining.33 Event data can be used to perform 3 types of process mining: ‘process discovery’, ‘conformance’, and ‘enhancement’. In ‘process discovery’, process mining uses the event data to model an actual, non-ideal process flow. ‘Conformance’ focuses on comparing the actual process flow with the target process flow in order to detect deviations in the process flow. Finally, in ‘enhancement’, the adaptation of the process model is to take place.34 Process mining can be linked with RPA in several ways. A first example of this can be found at Vodafone. Using process mining, Vodafone recognized that many orders have increased lead times because they deviate strongly from the standard process. Vodafone first used this insight to optimize the process, i.e. to identify, analyze, and ultimately eliminate the cases with increased lead times. This enabled Vodafone to ensure that the process was running stably, which was an important prerequisite for the successful introduction of RPA.  After all, the software robot only runs as stable as the underlying process. Thus, process mining can be used in the run-up to the development of new software robots in order to identify the most stable processes with a high degree of standardization and volume on the one hand and to optimize processes in advance on the other hand (see Sect. 3.2). But process mining is also suitable for tracking throughput times and, if necessary, for optimizing software robots that are already running on this basis (see also performance measurements in Sect. 3.8).35 In addition to Vodafone, ProSiebenSat.1 also reports that process mining can be used very effectively to identify processes for RPA.36 4.2.3.2 Machine Learning Machine learning is another subfield of AI. In simple terms, machine learning refers to a system that learns on the basis of historical data and thus becomes increasingly powerful in order to ultimately make more accurate predictions in the future. The quantity and quality of the historical data plays a decisive role in the accuracy of the predictions.37 As an example, machine learning uses self-learning algorithms to analyze the classifications of documents that have already been scanned (e.g. invoice, letter of complaint, invitation). While the simple reading of documents can be done via OCR, machine learning algorithms first learn which documents belong to which category by processing  Cf. van der Aalst (2012), p 76.  Cf. van der Aalst (2012), p 77ff; van der Aalst (2016). 35  Cf. Klingeberg et al. (2018), p 6. 36  Cf. Beisswenger et al. (2020), p 18. 37  Cf. Mohri et al. (2018), p. 1. 33 34

Literature

91

existing documents and classification by the user. As each document is processed, the algorithm learns and becomes more accurate in predicting which document belongs to which category. The algorithms used in machine learning are diverse, e.g. linear/logistic regressions, decision trees, clustering, or support vector machines.38 Machine learning is often used in conjunction with (predictive) analytics.39

4.2.3.3 Application Example RPA & Machine Learning An application example for the linking of RPA and machine learning can be found in reporting. Classical RPA first pulls together the data for reporting from the various data sources. This reporting sub-process is usually highly repetitive and standardized with few to no exceptions, which is why RPA is ideally suited for this.40 With the use of machine learning algorithms, the data can now be examined for anomalies (e.g., noticeable deviations) and patterns (e.g., correlations in the data).41 The algorithms can search for all potentially interesting patterns, even in previously unknown data sets, independently and without human intervention.42

Literature Alpaydin E (2020) Introduction to Machine Learning, 4. Auflage, MIT Press, Cambridge Arria (2021) Transforming Automation Workflows With Today’s Best-of-Breed Technologies, retrieved on 18.03.2021 at: https://cdn2.hubspot.net/hubfs/2047838/Downloadable%20files/ NLG+RPA%20Brochure.pdf Baars H, Kemper H-G (2008) Management Support with Structured and Unstructured Data  – An Integrated Business Intelligence Framework, in: Information Systems Management, Vol. 25, 132–148 Beisswenger A, Schlott A, Von Hirschausen G, Küster T, Hamann K, Leser C (2020) Robotic Process Automation im Accounting – Beispiele von ProSiebenSat.1, KION und PwC. Rethinking Finance 3(2020):17–26 Berchmans, D, Kumar SS (2014) Optical Character Recognition: An Overview and an Insight, 2014 International Conference on Control, Instrumentation, Communication and Computational Technologies (ICCICCT), Kanyakumari, 10–11 July 2014, IEEE Bornet P, Barin I, Wirtz J (2021) Intelligent automation.https://doi.org/10.1142/12239 Capgemini (2018) AI fuelled Character Recognition solutions pave the way for RPA, retrieved on 01.04.2021 at: https://www.capgemini.com/de-­de/2018/03/ai-­fuelled-­character-­recognition/ Celikyilmaz A, Deng L, Hakkani-Tür D (2018) Deep Learning in Spoken and Text-Based Dialog Systems, in: Deng L, Yang L (eds) Deep Learning in Natural Language Processing, Springer Nature, Singapore, 49–78  Cf. Alpaydin (2020).  Cf. Wakefield (2021). 40  Cf. Wenning/Przytulla (2020), p 11 f. 41  Cf. Inspirient (2021); Wittenburg/Tyroller (2020), p 80. 42  Cf. Wittenburg et al. (2020), p 27. 38 39

92

4  From RPA to IPA: How Software Robots Are Becoming Smarter

Chen Y-J, Wu C-H, Chen Y-M, Li H-Y, Chen H-K (2017) Enhancement of fraud detection for narratives in annual reports, in: International Journal of Accounting Information Systems, Vol. 26, 32–45 Chowdhury GG (2005) Natural Language Processing, in: Annual Review of Information Science and Technology, Vol. 37, Issue 1, 51–89 Deloitte (2016) Automatisierung und Digitalisierung im Rechnungswesen  – Eine Studie von Deloitte Österreich, retrieved on 01.04.2021 at: https://www2.deloitte.com/content/dam/ Deloitte/at/Documents/about-­d eloitte/at-­s tudie-­a utomatisierung-­u nd-­d igitalisierung-­i m-­ rechnungswesen.pdf Deloitte (o.J.) Intelligent automation entering the business world, retrieved on 01.04.2021 at: https:// www2.deloitte.com/content/dam/Deloitte/pt/Documents/strategy/2lu-­intelligent-­automation-­ business-­world.pdf Fisher IE, Garnsey MR, Hughes ME (2016) Natural Language Processing in Accounting, Auditing and Finance: A Synthesis of the Literature with a Roadmap for Future Research, in: Intelligent Systems in Accounting, Finance and Management, Vol. 23, Issue 3, 157–214 Google (2021) Grundlagen der Natural Language API, Google, retrieved on 01.04.2021 at: https:// cloud.google.com/natural-­language/docs/basics Hamilton W, Clark K, Leskovec J, Jurafsky D (2016) SocialSent: Domain-Specific Sentiment Lexicons for Computational Social Science, retrieved on 15.04.2021 at: https://nlp.stanford.edu/ projects/socialsent/. Hermann K, Stoi R, Wolf B (2018) Robotic Process Automation im Finance & Controlling der MANN+HUMMEL Gruppe, in: Controlling  – Zeitschrift Für Erfolgsorientierte Unternehmenssteuerung, 3/2018, 28–34 Hirschberg J, Manning CD (2015) Advances in natural language processing, in: Science, Vol. 349, Issue 6245, 261–266 Houy C, Gutermuth O, Fettke P, Loos P (2020) Potential Künstlicher Intelligenz zur Unterstützung von Sachbearbeitungsprozessen im Sozialwesen, Berichte des NEGZ, Nr. 8, retrieved on 01.04.2021 at: https://negz.org/wp-­content/uploads/2020/04/NEGZ-­Kurzstudie-­08-­Potentiale-­ Künstlicher-­Intelligenz-­2020.pdf Inspirient (2021) Analytics: Intelligent Process Automation, retrieved on 15.04.2021 at: https:// www.inspirient.com/analytics/intelligent_process_automation.php Jogani R, Kaniyar S, Koul, V, Yum C (2018) How to avoid the three common execution pitfalls that derail automation programs, in: Digital McKinsey (eds) Driving impact at scale from automation and AI, 64–71, retrieved on 15.04.2021 at: https://www.mckinsey.com/~/media/McKinsey/ Business%20Functions/McKinsey%20Digital/Our%20Insights/Driving%20impact%20at%20 scale%20from%20automation%20and%20AI/Driving-­i mpact-­a t-­s cale-­f rom-­a utomation-­ and-­AI.ashx Kavlakoglu E (2021) NLP vs. NLU vs. NLG: the differences between three natural language processing concepts, Watson Blog IBM, retrieved on 15.04.2021 at: https://www.ibm.com/blogs/ watson/2020/11/nlp-­vs-­nlu-­vs-­nlg-­the-­differences-­between-­three-­natural-­language-­processing-­ concepts/ Klingeberg J, Nakladal J, Baldauf F, Veit F (2018) Process Mining and Robotic Process Automation: A Perfect Match, in: International Conference on Business Process Management 2018, Industry Track Session, Sydney, Australia KPMG (2020) Digitalisierung im Rechnungswesen 2020, retrieved on 01.04.2021 at: https:// home.kpmg/de/de/home/media/press-­releases/2020/09/digitalisierung-­im-­rechnungswesen-­ stagniert.html Langmann C (2021) Robotic Process Automation (RPA)  – Study on Characteristics of Successful RPA Implementations, retrieved on 18.03.2021 at: https://w3-­mediapool. hm.edu/mediapool/media/fk10/fk10_lokal/05_diefakultt/03_personen/langmann/ final_rpa_study_2021_results_report_010221_web_kl.pdf

Literature

93

Lexoffice (2021) Belege erfassen mit intelligenter OCR-Texterkennungssoftware, retrieved on 01.04.2021 at: https://www.lexoffice.de/funktionen/texterkennung-­ocr/ Ling X, Gao M, Wang D (2020) Intelligent document processing based on RPA and machine learning, 2020 Chinese Automation Congress (CAC), Shanghai, 6–8 Nov. 2020, IEEE Mohri M, Rostamizadeh A, Talwalkar A (2018) Foundations of Machine Learning, 2. Auflage, MIT Press, Cambridge Nadkarni PM, Ohno-Machado L, Chapman WW (2011) Natural language processing – an introduction, in: Journal of the American Medical Informatics Association, Vol. 18, Issue 5, 544–551 Ng KKH, Chen C-H, Lee CKM, Jiao JR, Yang Z-X (2021) A systematic literature review on intelligent automation: Aligning concepts from theory, practice, and future perspectives, in: Advanced Engineering Informatics, Vol 47, 101,246. NICE (2021) What is RPA OCR?, retrieved on 01.04.2021 at: https://www.nice.com/rpa/rpa-­guide/ rpa-­ocr-­elevating-­process-­automation/ Patel C, Patel A, Patel D (2012) Optical Character Recognition by Open Source OCR Tool Tesseract: A Case Study, in: International Journal of Computer Applications, Vol. 55, No. 10, 50–56 Piro A, Gebauer A (2008) Definition von Datenarten zur konsistenten Kommunikation im Unternehmen, in: Hildebrand K, Gebauer M, Hinrichs H, Mielke M (eds.) Daten- und Informationsqualität, Vieweg+Teubner, Wiesbaden, 143–156 Ptucha R, Petroski Such F, Pillai S, Brockler F, Singh V, Hutkowski V (2019) Intelligent character recognition using fully convolutional neural networks, in: Pattern Recognition, Vol. 88, 604–613 SAS (2021a) Computer Vision – What it is and why it matters, retrieved on 01.04.2021 at: https:// www.sas.com/en_us/insights/analytics/computer-­vision.html#history SAS (2021b) Natural Language Processing (NLP), retrieved on 01.04.2021 at: What it is and why it matters https://www.sas.com/en_us/insights/analytics/what-­is-­natural-­language-­ processing-­nlp.html Schmelzer A (2020) Robotics Process Automation im Mittelstand am Beispiel Wien Energie, in: ReThinking Finance 03/2020, 36–69 Siebert A, Sommer J (2020) Natural Language Generation im Reporting  – Praxisbeispiele von Union Investment, Sopra Steria, ISS und Targobank, in: REthinking Finance, 06/2020, 29–34 Szeliski R (2010) Computer Vision: Algorithms and Applications, Springer, London The Stanford NLP Group (2019) The Stanford Natural Language Processing Group, retrieved on 01.05.2019 at: https://nlp.stanford.edu Ten Hompel M, Büchter H, Franzke U (2008) Identifikationssysteme und Automatisierung, Springer, Berlin UiPath (2021) About the UIAutomation Activities Pack, retrieved on 01.04.2021 at: https://docs. uipath.com/activities/docs/about-­the-­ui-­automation-­activities-­pack#section-­computer-­vision Van der Aalst W (2012) Process Mining, in: Communications of the ACM, Vol. 55, Issue 8, 76–83 Van der Aalst W (2016) Process Mining – Data Science in Action, 2. Auflage, Springer, Heidelberg Wakefield K (2021) Predictive analytics and machine learning, retrieved on 15.04.2021 at: https:// www.sas.com/en_gb/insights/articles/analytics/a-­guide-­to-­predictive-­analytics-­and-­machine-­ learning.html Wenning A, Przytulla G (2020) Robotic Process Automation im Controlling, in: REthinking Finance, 03/2020, 9–16 Wittenburg G/Tyroller M (2020) Intelligentere Prozessautomatisierung, in: REthinking Finance, 03/2020, 76–83 Wittenburg G, Roos A, Harnoss J (2020) Adaptives Reporting - Der Schatz im Datensee, in: REthinking Finance, 6/2020, 21–28 Zhang C (2019) Intelligent Process Automation in Audit, in: Journal Of Emerging Technologies In Accounting, Vol. 16, No. 2, 69–88

5

RPA in Practice: Results of an Empirical Study

5.1 Data Collection and Database In addition to the theoretical concept, the basis of any empirical study is above all the collected data, which should ideally be extensive and have high quality. The next two sections therefore first explain the data collection procedure and the database used for the study.1

5.1.1 Data Collection For the empirical study, companies that have already successfully introduced RPA as an automation technology were defined as the group of participants. In order to address as many companies as possible, no restriction was made according to industry, size, geography, or other criteria. The survey method chosen was a written online survey using a standardised online questionnaire. This type of survey is classified as a quantitative survey method. Significant disadvantages of surveys using online questionnaires include the lack of opportunity to clarify ambiguities and the uncontrollability of the survey situation. In particular, the uncontrollability of the survey situation harbours the risk that people other than the target group complete the questionnaire. Various measures were used to try to mitigate the problems inherent in online surveys. The following measures were pursued2:

 For the structure of the study, the study results and the following sections, see also Langmann (2021).  See also Sue/Ritter (2021).

1 2

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2022 C. Langmann, D. Turi, Robotic Process Automation (RPA) - Digitization and Automation of Processes, https://doi.org/10.1007/978-3-658-38692-4_5

95

96

5  RPA in Practice: Results of an Empirical Study

• The introductory page to the online questionnaire was designed in a visually appealing way and contains important information about the person responsible for the survey, the objective of the study, the length of the questionnaire, the group of participants in the study, the handling of data protection as well as a short explanation of how to fill in the online questionnaire. • The instructions for completion were placed separate from the actual questions of the examination. • In the online questionnaire, the questions of a topic area were summarized in a block. Each block of questions was placed on a separate (online) page. By clicking, the participant then gets to the next page and thus to the next topic area. • The topic areas and question blocks were arranged in such a way that no spillover effect from previous to subsequent question blocks can be assumed. • The length of the questionnaire was designed in such a way that the questions could be answered in about 15–20 min. For the selection and formulation of the questions used, the study also draws – as far as possible – on previous (international) empirical studies. Most of the questions in the questionnaire are formulated as closed questions (structured questions) and designed with a 7-point ordinal scale with explanations at the highest and lowest point. The latter corresponds to common research practice and avoids overtaxing the respondents due to too much differentiation.3 An extensive pre-test was conducted to ensure the comprehensibility and content verification of the questions and answer options used. The pre-test was intended to check, among other things, • whether the questions contained in the online questionnaire are complete and the wording understandable without explanation, • whether the graphic and content structure of the online questionnaire is acceptable, • or how long it takes to complete the online questionnaire. The entire online questionnaire (access, entry page, and all questions) of the present study was submitted to a total of five RPA experts – academics, consultants, and company representatives from different industries  – for pre-testing. The comments collected in the pre-tests were taken into consideration in the final design. In addition to the pre-test, the questionnaire was also subjected to a technical functional test. Already in the run-up to the study it became clear that the group of participants is neither easy to find nor easy to win for surveys. For this reason, on the one hand the online questionnaire was available in English and German in order to address the largest possible number of potential companies. On the other hand, every participant who left his or her

 Cf. e.g. Döring/Bortz (2016).

3

5.1 Data Collection and Database

97

e-mail address received a free report of the results. This was already pointed out on the entry page of the online questionnaire. A reference to the link to the online questionnaire and the associated study description was placed freely accessible on various social media business platforms, such as LinkedIn. In addition, the reference was sent to associations (from the field of automation) as well as RPA software providers with the request to distribute it to members or customers. In order to ensure that only companies with experience in the introduction of RPA are included in the study, a filter question on the use of RPA in the company was asked first. For participants without experience with the use of RPA in the company, the online questionnaire ended directly. The questionnaire was online for 3 months and could be answered from 01.09.2020 to 01.12.2020. In total, 157 participants were obtained during this period. The tool used was SoSci-Survey (https://www.soscisurvey.de). Of the 157 participants, the answers of 56 participants were sorted out, as these had more than 50% missing values or dropouts at the beginning of the questionnaire. The database of the study thus consists of 101 online questionnaires with responses from companies that have implemented RPA at their company and have gained corresponding experience in its use. The composition of the database consisting of 101 participants is presented below.

5.1.2 Composition of the Database The composition of the final database is discussed on the basis of selected characteristics. First, the industry affiliation of the participating companies was evaluated. The evaluation of the industry distribution is illustrated in Fig. 5.1. This reveals a slight concentration on manufacturing, banksand financial services, and services. The remaining distribution of industries shows no anomalies.

Fig. 5.1  Sector distribution of the sample (N = 101)

Manufacturing

18.8%

Banks & Financial Services. Services Automotive

16.8% 8.9% 7.9%

Information Technology

5.9%

Telecommunication

5.9%

Utilities

4.0%

Retail

3.0%

Transportation & Logistics

3.0%

Government Public

2.0%

Other

23.8%

98

5  RPA in Practice: Results of an Empirical Study 54.5%

20.8% 11.9%

12.9%

 100 m€

 100 m€ &  500 m€

Not specified

 500 m€

Fig. 5.2  Distribution of company size by turnover (N = 101) 26.7%

22.8% 14.9%

13.9%

16.8% 5.0%

20

Not specified

Fig. 5.3  Distribution of company size by number of employees (N = 101, in thousands)

In addition to the industry classification, the companies from which the surveyed participants come were classified in terms of their size. For this purpose, both the number of employees and the company turnover of the previous financial year were used. As Fig. 5.2 shows, the sample exhibits a certain concentration in the distribution of turnover. The majority of companies (54.5%) have a turnover of more than 500 million euros in the previous financial year. According to the German Federal Statistical Office this represents rather large companies.4 Looking at the number of employees of the participating companies in Fig. 5.3, a similar distribution picture emerges as for turnover. Around 27% (57%) of the companies included have more than 20,000 (5000) employees. Thus, from the perspective of the number of employees, the sample is also increasingly dominated by large companies. Since large companies with their mostly complex, administrative processes benefit from the efficiency advantages of RPA, the distribution of company size is not surprising.5 In addition to information on the industry and size of the company, each participant was also asked to provide information on the functional area in which he or she works. Figure 5.4 shows the results. Among the participants there is a certain concentration on the  Cf. definition of size classes according to Destatis (2021).  Cf. Willcocks et al. (2019), p 19 ff.

4 5

5.2 Results of the Empirical Investigation

99

RPA-department (director or staff)

39.6%

Finance & Accounting (director or staff)

18.8%

Information Technology IT (director or staff)

Management (e.g., C-Suite, executive management)

17.8%

5.0%

Other

18.8%

Fig. 5.4  Distribution of participants by functional area (N = 101)

RPA department as the functional area (39.6%) they belong to. Among the remaining functional areas, the two areas Finance, Accounting & Controlling (18.8%) and IT (17.8%) stand out in particular, which is less surprising given the areas in which RPA is typically used in companies.6

5.2 Results of the Empirical Investigation After the data collection and basis were presented in the previous chapter, this chapter now focuses on the results of the study. The focus is on a descriptive evaluation of the results across various dimensions that play a role in the introduction and use of RPA (see also Chap. 3).

5.2.1 Scaling and Experience with RPA The level of experience of companies in using RPA is shown, among other things, by how long they have been using the automation technology and how many software robots they have in use. Over 60% of the companies in the study have been using RPA since 2018 or later. In contrast, only about 10% of companies have been using RPA earlier than 2017. This result thus reflects that RPA is a relatively new technology in practice. If we exclude the year 2020 due to the Covid situation, the figures show a steady increase of RPA since 2017 (Fig. 5.5).  See also, for example, Schulze/Jiles (2020) on the favoured areas of application of RPA in companies.

6

100

5  RPA in Practice: Results of an Empirical Study How long have you been using RPA in your organization?

27.7%

29.7%

18.8%

13.9%

9.9% Before 2017

2017

2018

2019

2020

Fig. 5.5  Year of introduction of RPA (N = 101) How many software robots are currently running in your organization?

35.6%

1–5

29.7% 13.9%

14.9%

6–10

11–15

5.9% 16–20

>20

Fig. 5.6  Number of software robots currently in use (N = 101)

In terms of the number of software robots currently in use – by which is meant the number of automated processes running on a technical robot license – the surveyed companies focus on having either 1–5 (35.6%) or more than 20 (29.7%) robots in use (Fig. 5.6). The result is comparable to other studies.7 In order to better understand whether – once introduced – the extent of use of RPA in the companies increases over time, the period of use and the number of software robots used were related to each other. Figure 5.7 illustrates the results. The number of software robots used increases with increasing number of years in use. Thus, companies seem to scale RPA over time. Since the largest category only shows >20, no conclusion can be drawn about the strength of the scaling. However, other studies show that companies struggle with scaling RPA.8 Nonetheless, the results here demonstrate an increase in the number of software robots deployed over time, albeit with no indication of the exact magnitude. Considering that the

 Cf. e.g. PWC (2020).  Cf. Deloitte (2018), p 7.

7 8

5.2 Results of the Empirical Investigation

101

Number of software robots running 1–5

6–10

11–15

16–20

>20

6 0 0 0

Before 2017

12

11

9

1

17

1

8 5

4 0

2017

7 4 4 4

2018

2

2 2

2019

2

0 0 0

2020

Fig. 5.7  Relationship between year of introduction and number of software robots used (N = 101)

marginal costs (development, licensing, and maintenance costs) of RPA generally decrease with each additional software robot, scaling RPA seems perfectly understandable from an efficiency perspective.

5.2.2 Effect of RPA on Success The effects of RPA on success are manifold (Sect. 2.2). Numerous studies and case studies deal with the different aspects of success of RPA.9 They range from cost savings to quality improvements to higher job satisfaction. In this study, participants were asked what impact the RPA implementation had. Thus, the focus is not on the expectations of the participants, but on the actual impact after implementation. The results in Fig. 5.8 show that the companies primarily experience an improvement in productivity (∅ 5.2), an improvement in process quality (∅ 5.1), and a reduction in costs (∅ 4.8) as a result of the RPA implementation. Ensuring the service availability (∅ 4.3) of a process – after all, robots are basically available 24 h a day, 7 days a week – on the other hand, receives less approval when it comes to the success effect of RPA.

5.2.3 Selection of Suitable Processes for RPA 5.2.3.1 Preparation of Processes for RPA The automation of processes with RPA first requires the selection of suitable processes, their detailed documentation, and, ideally, process optimization based on this. For example, the pharmaceutical company Merck checks, if the processes with potential for RPA are documented down to the click level and already fully optimized.10  See Capgemini (2016); Deloitte (2018); Eikebrokk/Olsen (2020); Kokina/Blanchette (2019); Ostrowicz/Schmidt-Schröder (2017); PWC (2020) for examples. 10  Cf. Pellegrino/Mega (2020), p 36. 9

102

5  RPA in Practice: Results of an Empirical Study

Our software robots perform the following tasks: Multiple answers possible

Data entry (e.g. fill data in forms, enter data in files, systems or databases) Data transfer (e.g. transfer data between systems, copy&paste data or files)

96.0% 92.1%

Log in to enterprise systems / apps Open, read, or create emails Obtain data (e.g. obtain input via workflow or emails, extract data from internet, extract data from documents) Process transactions (e.g. make calculations, analyze data, validate data) Other

88.1% 82.2% 81.2% 79.2% 5.0%

Fig. 5.8  Effect of RPA on success (N = 101)

The rationale behind it: Insufficiently documented or non-optimized processes always bear the risk that the process and thus the robot will not run stably later on (Sect. 3.2.2). The results of the study confirm this view (Fig.  5.9). The majority of the companies included in the study confirmed that they had selected the processes thoroughly (∅5.5) and documented them comprehensively down to click level (∅5.4) before the technical development of the software robots is done. The optimization and standardization of processes prior to RPA implementation, on the other hand, receives slightly lower approval among the participants (∅4.7). One explanation for this could be the complexity of the selected processes. Optimizing processes, foremost, makes sense if the processes are also sufficiently complex, i.e. there is also something to optimize. In other words, simple processes with few, unambiguous steps can probably only be optimized to a limited extent. The data of the present study support this argumentation. The participants’ agreement with the optimisation and standardisation of processes correlates with their assessment of the complexity of the processes (Sect. 5.2.3.2). This means that the greater the complexity of the processes was assessed, the more the participants considered optimization and standardization of the processes to be relevant in the run-up to robot development.11

5.2.3.2 Process Complexity in RPA In principle, (classic) RPA is suitable for processes with low complexity. The less exceptions and variations, dependencies on other processes, or uncertainties in the process flow, the lower the complexity of processes.12 The drivers behind this complexity are, for example, the number of applications addressed, the number of decision rules, or the number of  The Pearson correlation coefficient between the two variables is 0.182 (p-value  =  0.034 | one-­ sided); according to Spearman-Rho, the coefficient is 0.190 (p-value = 0.029 | one-sided). 12  See, for example, Karimi et al. (2007); Langmann/Kokina (2021). 11

5.2 Results of the Empirical Investigation

103

Before software robots were developed for the selected business processes in our RPA implementation, we... 1 = Strongly Disagree 7 = Strongly Agree

fully documented the business processes (on a click-level)

5.5

thoroughly screened and selected the business processes most suitable

5.4

thoroughly compared (automation) technologies and decided to use RPA

5.1

first optimized and standardized the selected business processes

4.7 1

ø 5.2

7

Fig. 5.9  Process preparations for RPA (N = 99–101)

users/departments involved in the process. Based on these examples, the participants of the study were asked how complex they classify the processes for which they use software robots. The results are illustrated in Fig. 5.10. The companies included in the study estimate the complexity of the processes for which they use RPA as moderately complex (∅ 4.2). Process complexity could also be addressed by companies through the use of other digitilization technologies in addition to RPA, thereby enabling software robots to handle more complex processes (Sect. 2.3). A comparison of the assessments of the complexity of the processes between companies with and without additional digitization technologies for RPA in place shows differences, but these are not statistically significant.13

5.2.3.3 Relevant Functional Areas for RPA In principle, RPA can be used in all functional areas of a company, as long as the corresponding requirements for the processes selected there are met. In practice, it can be observed that many companies start with RPA in the finance area.14 Hence, the participants  The mean values for process complexity of the two groups are: 1st group ‘RPA with additional digitization technologies’  =  4.40, 2nd group ‘RPA without additional digitization technologies’ = 3.95. For the statistical analysis of the values, a t-test was applied and validated by a non-­ parametric Mann-Whitney U test. The results of both procedures were not statistically significant. For an example of both procedures, see Sprinthall (2011). 14  Cf. Anagnoste (2018); Petersen/Schröder (2020); Schulze/Jiles (2020). 13

104

5  RPA in Practice: Results of an Empirical Study How would you evaluate the process complexity1 in the processes supported by software robots?

Low complexity

High complexity

4.2

1

7

1) number of systems accessed, number and complexity of business rules in process, involved teams etc.

Fig. 5.10  Complexity of processes for RPA (N = 99) In which of your organization's functions are software robots currently in place? Multiple answers possible

Financial Accounting (bookkeeping) Finance

60.4% 57.4%

Management Accounting

50.5%

Customer service

40.6%

IT

38.6%

Procurement

36.6%

HR

32.7%

Logistics Sales Marketing Other

30.7% 23.8% 11.9% 19.8%

Fig. 5.11  RPA use by functional areas (N = 101)

of the present study were asked in which functional area they use software robots. The results are illustrated in Fig. 5.11. The companies in the study use RPA primarily in financial accounting (60.4%), finance (57.4%), management accounting (50.5%), customer service (40.6%), IT (38.6%), and procurement (36.6%). One driver for this distribution is probably the degree to which the processes of the respective functional area are already standardized or the process volume. It is therefore hardly surprising that processes in financial accounting, finance, and

5.2 Results of the Empirical Investigation

105

Software robots are supporting in the following Finance & Accounting processes... Multiple answers possible

Accounts Payable

58.0%

Accounts Receivable

51.9%

Management Reporting

49.4%

General Accounting

38.3% 25.9%

Closing (the books)

22.2%

Consolidation

18.5%

Payroll

16.0%

Inventory accounting Cash management Fixed asset Accounting Legal Reporting Other

16.0% 14.8% 13.6% 4.9%

Fig. 5.12  RPA use in finance, financial accounting, and management controlling processes (N = 81)

management accounting dominate. It is precisely in these areas that processes are increasingly found that ideally meet the requirements for the use of RPA. In addition, employees in the finance area often have experience in the development of macros and thus development and automation experience, which accelerates a broad implementation of RPA.15

5.2.3.4 Excursus: Use of RPA for Processes in Finance, Financial Accounting, Management Accounting The study results on the functional areas showed that RPA is increasingly used in the areas of finance, financial accounting, and management accounting. In the next step, the study participants who use RPA in one or more of these functional areas were asked about the specific processes for which they use RPA. The results are shown in Fig. 5.12. In finance, financial accounting, and management accounting, the companies in the study use RPA primarily for accounts payable (58.0%), accounts receivable (51.9%), and management reporting (49.4%). Accounts payable and accounts receivable in particular embody processes that are typically relatively highly standardized, repetitive, and usually higher-volume. The management reporting process – at least to a large extent – also corresponds to these characteristics. The study results are thus in line with conceptual considerations made in the context of so-called process heat maps (Sect. 3.2.3).

15

 Cf. Petersen/Schröder (2020), p 1138ff.

106

5  RPA in Practice: Results of an Empirical Study

Our software robots perform the following tasks: Multiple answers possible

Data entry (e.g. fill data in forms, enter data in files, systems or databases) Data transfer (e.g. transfer data between systems, copy&paste data or files)

96.0% 92.1%

Log in to enterprise systems / apps

88.1%

Open, read, or create emails

Obtain data (e.g. obtain input via workflow or emails, extract data from internet, extract data from documents) Process transactions (e.g. make calculations, analyzedata validate data) Other

82.2% 81.2% 79.2% 5.0%

Fig. 5.13  Activities of software robots (N = 101)

5.2.3.5 Activities Performed by RPA Within Processes In addition to the selection of processes in which RPA is used, the question arises as to which activities the software robots will actually take over. Software robots are ideally suited for taking over the simplest activities based on if-then rules (Sect. 3.2.1). Based on case studies in accounting, Kokina/Blanchette (2019) find that companies use software robots there primarily for simple activities, such as reading emails, copying data into forms based on fixed if-then rules, or logging into applications to enter data.16 Figure 5.13 shows which activities software robots perform at the companies surveyed. At the top of the list are activities such as data entry (96.0%), data transfers (92.1%), or logging into systems/apps (88.1%). In contrast, robots are used less for processing transactions (79.2%), presumably due to the increasing complexity associated with these activities. The distribution thus confirms the findings of Kokina/Blanchette (2019).

5.2.4 RPA Platforms and Types 5.2.4.1 Single vs. Multiple RPA Platforms There are currently a large number of RPA platforms on the market, which differ in terms of functional scope and handling, among other things. The RPA market is fundamentally fragmented, competition is intense and characterized by smaller niche providers, although three providers are increasingly assuming a leading role (Sect. 3.3).17 The RPA market is

 Cf. Kokina/Blanchette (2019), p 6.  Cf. Everest Group (2019).

16 17

5.2 Results of the Empirical Investigation

107

Percentage of participating companies which have more than one RPA platform in place:

More than an RPA platform

19.8%

80.2%

One RPA platform

Fig. 5.14  Single vs. multiple RPA platforms (N = 101)

therefore likely to consolidate further in the coming years.18 One question associated with RPA platforms is whether companies tend to pursue a single or multiple vendor strategy.19 As Fig. 5.14 illustrates, the results of the survey show that more than 80% of the companies surveyed use a singular RPA platform. Thus, companies pursue a single-vendor strategy. Since the economies of scale increase with the concentration on one platform and the developed robots of the different platforms are only interchangeable to a limited extent, this approach is understandable.

5.2.4.2 Attended vs. Unattended RPA RPA can be simplified into the 2 types Attended and Unattended RPA. Attended RPA runs directly on the user’s desktop. The user starts, monitors, and interacts with the robot via his own screen. Unattended RPA runs on a central server in the background, the robot starts itself and handles the affected processes (usually) without user interaction. The evaluation of the results in Fig. 5.15 show that Unattended RPA (∅5.2) is used much more intensively by the companies surveyed than Attended RPA (∅3.3). One possible explanation for the favored use of Unattended RPA is that with Attended RPA, the users themselves decide when and how often they run the robot. In order to ensure that the robots function correctly and to minimize safety risks, very stringent handling is required and appropriate RPA governance must be ensured. Robots running under Unattended RPA, on the other hand, are usually controlled and monitored centrally. Following this principle, Union Investment, for example, pursues the strategy of running as many robots as possible under Unattended RPA and thus without manual intervention by a user.20  The trend towards consolidation in the RPA market is already evident in the example of the takeover of Softomotive by Microsoft or Another Monday by Hyland. Cf. Hyland (2020) and Microsoft (2020). 19  Cf. in general on sourcing strategies exemplary Werner (2020), p 177ff. 20  Cf. Tröndle (2020), p 59ff. 18

108

5  RPA in Practice: Results of an Empirical Study Which types of RPA are you using in your organization? Attended RPA No Usage

Intensive Usage

3.3

Unattended RPA No Usage

Intensive Usage

5.2 1

7

Fig. 5.15  Attended vs. Unattended RPA (N = 101)

Are you connecting RPA together with other digitalization technologies?

Yes

62.4%

37.6%

No

Fig. 5.16  RPA vs. IPA (N = 101)

5.2.4.3 RPA vs. IPA By linking classic RPA platforms with other digitization technologies to so-called intelligent process automation (IPA), software robots are also able to automate processes in which unstructured data is processed or more complex decisions are required. Which ‘smarter’ technology is combined with RPA depends on the use case. In this study, participants were asked about the use of IPA.21 Fig. 5.16 shows the results.  Cf. for IPA, for example, Bornet et al. (2021).

21

5.2 Results of the Empirical Investigation

109

Concerning RPA & other digitalization technologies, our software robots are connected with... Multiple answers possible

Optical Character Recognition (OCR)

34.6%

Machine Learning/ Artificial Intelligence

16.9%

Advanced Data Analytics

16.2%

Process Mining

15.4%

Natural Language Processing (NLP) Natural Language Generation (NLP) Other

10.8% 1.5% 4.6%

Fig. 5.17  Digitization technology combined with RPA (N = 63)

When asked whether the participating companies combine RPA with other digitization technologies, 62.4% answered yes. Thus, only about one third (37.6%) of the companies surveyed use RPA as the sole technology. Since the linked digitization technologies relate to different areas of application and differ considerably from one another, the participants were asked which technology they specifically combine with RPA. The results are shown in Fig. 5.17. The companies that link RPA with other technologies primarily use optical character recognition (OCR) with 34.6%. Other technologies include machine learning (16.9%), advance analytics (16.2%), process mining (15.4%), and natural language processing (10.8%). By using OCR, software robots are able to read (unstructured) data from scanned documents, transform it into (structured) data and thus process it further. Reading the order date, supplier, and/or invoice amount from incoming invoices and their further processing in the accounting system are just a simple example.

5.2.5 RPA Governance 5.2.5.1 Components of an RPA Governance RPA governance provides clear guidelines and standards for handling RPA and software robots in all areas (Sect. 3.5). In practice, the guidelines include, for example, access rights

110

5  RPA in Practice: Results of an Empirical Study

Together with our RPA implementation we established a dedicated RPA governance which... 1 = Strongly Disagree │ 7 = Strongly Agree

defines access rights for robots

5.8

defines how processes are selected and documented

5.5

includes data protection rules

5.4

defines IT security standards for robots and the RPA Plattform clarifies responsibilities, roles and rights concerning operations, development, maintenance and changes in robots

5.3 5.2 5.0

includes procedures for change requests for robots provides clear instructions how to handle exceptions in robots

4.7 1

ø 5.3

7

Fig. 5.18  Components of RPA governance (N = 100–101)

for robots, IT security, or change requests.22A functioning RPA governance proves to be a success factor in practice and has a positive effect on the efficiency of RPA implementations.23 Figure 5.18 shows the results of the study on RPA governance. The questions asked about RPA governance cover their typical dimensions.24 The results show that governing definitions of access rights (∅5.8), process selection and documentation (∅5.5) as well as data protection (∅ 5.4) receive the strongest approval among the companies surveyed. The definition of instructions how to handle exceptions in robots (∅4.7), on the other hand, receives the least approval, although still a majority. One explanation for this result could lie in the selection of processes for RPA. If only highly standardized processes are selected for support by RPA along their happy path without exceptions, exceptions do not occur (or only very occasionally).25

5.2.5.2 RPA Testing During the development of new software robots or the maintenance of existing ones, the robots undergo various tests. The definition of tests (e.g. technical function tests, user acceptance tests) are typically also part of an RPA governance. Extensive testing is considered critical in RPA.26 Therefore, the participants of the study were also asked about  Cf. Tröndle (2020), p 60.  See, for example, Lacity/Willcocks (2018); Langmann (2021). 24  Cf. Tröndle (2020), p 60. 25  See Aguirre/Rodriguez (2017), p 67; Fung (2014), p 2; Koch und Fedtke (2020), p 6. 26  Cf. Koch und Fedtke (2020), p 63ff; Taulli (2020), p 183 f. 22 23

5.2 Results of the Empirical Investigation

111

Concerning tests and go-live of our developed software robots,... 1 = Strongly Disagree

7 = Strongly Agree

extensive functional, technical and integrated tests were conducted before go-live

5.7

a dedicated plan has been designed for the go-live of the software robots (e.g. with checklists)

5.0

1

ø 5.4

7

Fig. 5.19  RPA testing (N = 100)

testing in RPA. The results are shown in Fig. 5.19. According to the results, the majority of the surveyed companies fully agree that they perform extensive technical, functional, and integrated testing prior to going live with developed software robots (∅5.7). The results thus underline the importance of tests for RPA.

5.2.6 RPA Operating Model 5.2.6.1 Selection of the RPA Operating Dodel The introduction of RPA is accompanied by the choice of an operating model. The operating model essentially determines which organizational units are responsible for which processes in connection with RPA (Sect. 3.6.1). In principle, there are three operating models for RPA: centralized, decentralized, and hybrid models. As an alternative or supplement to the (internal) operating model, it is also possible to use an external provider that offers services related to RPA (development, maintenance, etc.) as software-as-a-service (SaaS).27 Some research suggests that the centralized operating model in the form of an RPA Center of Excellence (CoE) has some dominance in practice.28 The results of this study are shown in Fig. 5.20. According to the results, the majority of the surveyed companies agree

27 28

 Cf. Dickemann/Obermair (2020).  Cf. Willcocks et al. (2019), p 19 ff.

112

5  RPA in Practice: Results of an Empirical Study

The development of software robots, their operation and maintenance are... 1 = Strongly Disagree │ 7 = Strongly Agree

mostly carried out by a separate, dedicated unit (e.g. RPA Center of Excellence)

4.6

partly carried out by a separate, dedicated unit and partly by the departments in which the software-robots are running

3.9

mostly carried out by each department separately in which the software-robots are running

3.2

are carried out by an external software service provider

2.4 1

7

Fig. 5.20  Operating models for RPA (N = 101)

that they primarily use a centralized and separate entity (e.g., RPA CoE) for the development and maintenance of software robots (∅4.6). The second strongest agreement is for the hybrid model, i.e., a combination of a centralized RPA unit and decentralized departments (∅3.9). The use of RPA-as-a-service, on the other hand, receives less approval (currently) (∅2.4), which is in line with other studies. However, this model is likely to increase more in the future.29 The appropriate operating model could depend on the number of robots a company has in use. Scaling in RPA requires additional resources for development, operation, and maintenance. A centralized RPA CoE cannot easily grow due to the scarce resources required (such as RPA developers).30 A hybrid model, on the other hand, generally has more resources with RPA know-how, simply due to the inclusion of decentralized units (Sect. 3.6.2). However, an analysis of this relationship in the present study shows that the participants favor the centralized operating model (e.g. CoE), regardless of how many robots they have in use. Also, the year of introduction, reflecting the experience and scaling of RPA, has no influence on the above assessment on the operating model.31 Thus, the advantages of the central bundling of scarce resources, such as the associated scaling effects and the clear responsibility, seem to outweigh the disadvantages.

 Cf. Willcocks et al. (2019), p 13.  See also, for example, Pellegrino/Mega (2020), p 41. 31  For this purpose, cross-tabulation and related statistics were used to examine whether the assessment of the operating models differs between the different size classes of robots (Fig. 5.7) and the different service lives (Fig. 5.6). See IBM (2021) for cross-tabulations and statistics. However, it should be noted that the maximum size class of robots was >20. 29 30

5.2 Results of the Empirical Investigation

113

Regarding the collaboration with the IT department for our RPA implementation,... 1 = Strongly Disagree │ 7 = Strongly Agree

the IT-department was closely integrated into the RPA implementation from the beginning

5.7

1

7

Fig. 5.21  Involvement of the IT department (N = 100)

5.2.6.2 Involvement of the IT Department Many companies have implemented RPA in the past, sometimes with little or no IT involvement. Although this certainly speeds up the introduction, the involvement of the IT department is likely to be indispensable for scaling RPA in most cases.32 The IT department is (co-)responsible for numerous company-wide requirements and guidelines such as IT security, compliance, data protection, or testing. Since these requirements also play a central role for RPA (as an IT platform), it is advisable to involve IT early on in the RPA introduction.33 The answers of the participating companies reflect the importance of involving the IT department (Fig. 5.21). The majority of the study participants agree that they have closely involved the IT department from the beginning of the RPA implementation (∅5.7). 5.2.6.3 Involvement of External Consultants When introducing RPA, the support of external consultants can help to ensure missing technical and professional know-how and thus accelerate the introduction or scaling. In order to avoid the need for permanent external support and to build up internal know-how, external consultants ideally hand over their know-how and tasks step by step to the RPA project team or those responsible for it within the company. For example, KION – a leading global intralogistics provider – reports that they rely on external support to scale RPA to ensure rapid progress and success. At the same time, knowledge is being built up internally and a dedicated centre of automation, the KION Bot Factory, is being established.34 Previous research shows that companies primarily run RPA in-house, either with or without the support of external consultants.35 In the present study, almost 70% of the companies surveyed have external consultants for the RPA implementation (Fig. 5.22). The  Cf. Petersen/Schröder (2020), p 1137; Taulli (2020), p 300; Wenzel (2020), p 46.  Cf Koch und Fedtke (2020), p 43ff; Willcocks et al. (2019), p 21. 34  Cf. Beisswenger et al. (2020), p 22. 35  Cf. Willcocks et al. (2019), p 13. 32 33

114

5  RPA in Practice: Results of an Empirical Study For our RPA implementation we made use of external consultants:

Yes

69.3%

30.7%

No

Fig. 5.22  Support from external consultants (N = 101)

result thus supports the above line of argument that external consultants can bring knowhow into the company and thus ensure rapid implementation or scaling. It remains open, however, how long companies use or need the help of external consultants.

5.2.7 RPA-Specific Change Management 5.2.7.1 Communication and Change Management Measures Practical experience in dealing with RPA shows how important communication and change management is. At Wien Energie – an energy supplier from Vienna – the introduction of RPA was not seen as an IT project with change management, but rather as a change management project with an IT component. Therefore, Wien Energie focused on communication and transparency from the very beginning.36 The evaluation of the results about communication in RPA implementations are shown in Fig. 5.23. For the vast majority of the study participants it is true that communication took place both at the beginning (∅5.6) of the implementation and continuously to all stakeholders (∅5.4). However, communication about RPA should not be limited to the implementation phase, but should also take place during subsequent operation. The investment bank Union Investment, for example, has a structured regular communication in place to important stakeholders (e.g. the workers council) about upcoming developments or changes in the regular RPA operation.37

 Cf. Schmelzer (2020), p 66.  Cf. Tröndle (2020), p 60.

36 37

5.2 Results of the Empirical Investigation

115

Regarding communication of our RPA implementation, there... 1 = Strongly Disagree │ 7 = Strongly Agree

was an initial communication towards all stakeholders

5.6

was an ongoing communication towards all stakeholders

5.4

1

ø 5.5

7

Fig. 5.23  Communication in the context of RPA implementation (N = 101)

Communication is an essential element of change management (Sect. 3.7.4). Companies like the pharmaceutical company Merck see change management as critical for the sustainable introduction of RPA. This is because the process know-how of the employees, whose daily work may be eliminated by the introduction of software robots, is often indispensable for the RPA introduction.38 Clever change management measures are needed here. As Fig. 5.24 shows, it is true for the majority of the companies surveyed that dedicated change management measures (e.g. workshops) were used to support the introduction of RPA (∅4.7). However, this does not answer the question of which individual change management measures the companies surveyed used.

5.2.7.2 RPA Training The introduction of RPA in companies requires new skills and knowledge. For this purpose, the use of specific training courses is recommended, which differ depending on the target group (Sect. 3.7.5). For example, while the RPA developer receives technical training, the RPA business analyst rather receives RPA basics. Figure 5.25 shows the results of the study in relation to RPA training. Majority of the participants in this study consider RPA trainings to substantially improve the understanding of RPA users (∅5.1). They also consider majority of their trainings as suitable in terms of content, length, and the trainers (∅5.0).

38

 Cf. Pellegrino/Mega (2020), p 36.

116

5  RPA in Practice: Results of an Empirical Study Regarding change management, there... 1 = Strongly Disagree │ 7 = Strongly Agree

were explicit measures taken to support our RPA implementation (e.g. videos from RPAy-users, success stories or Build-YourOwn-Bot workshops)

4.7

1

7

Fig. 5.24  Change management during RPA implementation (N = 100) As part of our RPA implementation trainings & workshops on RPA... 1 = Strongly Disagree │ 7 = Strongly Agree

substantially improved the level of users understanding

5.1

were handled by knowledgeable and competent trainers

5.1

were of adequate length and detail

5.0

1

ø 5.1

7

Fig. 5.25  RPA training (N = 100)

5.2.7.3 Top Management Support for RPA For a sustainable introduction of RPA, the employees affected by it must be involved (Sect. 3.7.3). An important component for this is the support of top management and the attention it devotes to the topic. Wien Energie therefore describes the support of top management as an important success factor in its RPA implementation.39 Willcocks et  al. (2019) also see top management as a crucial stakeholder for successful RPA implementations.40  Cf. Schmelzer (2020), p 69.  Cf. Willcocks et al. (2019), p 19 f.

39 40

5.2 Results of the Empirical Investigation

117

Concerning the RPA implementation our top management... 1 = Strongly Disagree │ 7 = Strongly Agree

supported the adoption and use of RPA

5.6

gave frequent updates on the developments regarding RPA

4.8 1

ø 4.3

7

Fig. 5.26  Top management support for RPA (N = 100)

The results of the present study in Fig. 5.26 also reflect this relationship. The majority of the study participants agree that top management supports the introduction and use of RPA (∅5.6). Somewhat less consent is the statement that top management regularly informs about the progress of the introduction (∅4.8).

5.2.8 RPA Performance Measurement In simple terms, RPA performance measurement tries to measure and control the performance of RPA by means of key indicators. The metrics include operational metrics for controlling RPA development, operation or maintenance as well as for measuring the impact on success (see Sect. 3.8). The results are illustrated in Fig. 5.27. Accordingly, the majority of the companies surveyed track the number of robots running (∅ 5.3) as well as their impact, such as cost savings or quality improvement (∅ 5.2). On the other hand, the tracking of the number of software robots in the individual development phases (∅4.7) receives less approval. Although it is not possible to make a statement about the concrete key indicators used for RPA performance measurement at the companies surveyed, the results show that companies track RPA through performance measurement.

118

5  RPA in Practice: Results of an Empirical Study To monitor performance of our software robots and the RPA team, we track the... 1 = Strongly Disagree │ 7 = Strongly Agree

number of softwarerobots that are currently running

5.3

performance impact of software robots running (e.g. cost savings,quality improvements)

5.2

number of softwarerobots in the different development phases

4.7

1

ø 5.0

7

Fig. 5.27  RPA performance measurement (N = 101)

Literature Aguirre S, Rodriguez A (2017) Automation of a Business Process Using Robotic Process Automation (RPA): A Case Study, in: Figueroa-García JC, López-Santana ER, Villa-Ramírez JL, Ferro-­ Escobar R (eds) 4th Workshop on Engineering Applications, WEA 2017 Cartagena, Colombia, September 27–29, 2017 Proceedings, 65–71 Anagnoste S (2018) Robotic Automation Process – The operating system for the digital enterprise, Proceedings of the International Conference on Business Excellence, Vol. 12 (1), 54–69 Beisswenger A, Schlott A, Von Hirschausen G, Küster T, Hamann K, Leser C (2020) Robotic Process Automation im Accounting  – Beispiele von ProSiebenSat.1, KION und PwC, in: REthinking Finance, 03/2020, 17–26 Bornet P, Barin I, Wirtz J (2021) Intelligent Automation, https://doi.org/https://doi.org/10.1142/12239. Capgemini (2016) Robotic Process Automation – Robots conquer business processes in back office, retrieved on 15.05.2019 at: https://www.capgemini.com/consulting-­de/wp-­content/uploads/ sites/32/2017/08/robotic-­process-­automation-­study.pdf Deloitte (2018) The robots are ready. Are you?, retrieved on 18.03.2019 at: https://www2.deloitte. com/content/dam/Deloitte/tr/Documents/technology/deloitte-­robots-­are-­ready.pdf Destatis (2021) Kleine und mittlere Unternehmen (KMU), retrieved on 18.03.2021 at: https://www. destatis.de/DE/Themen/Branchen-­Unternehmen/Unternehmen/Kleine-­Unternehmen-­Mittlere-­ Unternehmen/Glossar/kmu.html Dickemann T, Obermair A (2020) Automation as a Service: Robotic Process Automation wird erwachsen, in: ReThinking Finance 03/2020, 70–75 Döring N, Bortz J (2016) Forschungsmethoden und Evaluation in den Sozial- und Humanwissenschaften, 5. Aufl. Springer, Berlin Eikebrokk TR, Olsen DH (2020) Robotic Process Automation and Consequences for Knowledge Workers: a Mixed-Method Study, in: Hattingh M, Matthee M, Smuts H, Pappas I, Dwivedi Y, Mäntymäki M (eds) Responsible Design, Implementation and Use of Information and

Literature

119

Communication Technology, I3E 2020, Lecture Notes in Computer Science, Vol. 12066, Springer, Cham Everest Group (2019) RPA Vendors Market Share and Y-o-Y Growth by License Revenue | Market Insights, retrieved on 01.04.2021 at: https://www.everestgrp.com/2019-­08-­rpa-­vendors-­market-­ share-­and-­y-­o-­y-­growth-­by-­license-­revenue-­market-­insights-­51098.html Fung HP (2014) Criteria, Use Cases and Effects of Information Technology Process Automation (ITPA), in: Advances in Robotics & Automation, Vol. 3, Issue 3, 2–10. Hyland (2020) Hyland schließt Akquisition von RPA-Softwareanbieter Another Monday erfolgreich ab, retrieved on 01.04.2021 at: https://www.hyland.com/de-­DE/learn/press-­releases/de-­de/ hyland-­another-­monday IBM (2021) Crosstabs statistics, retrieved on 01.04.2021 at: https://www.ibm.com/docs/en/spss-­ statistics/SaaS? topic=crosstabs-statistics Karimi J, Somers TM, Bhattacherjee A (2007) The impact of ERP implementation on business process outcomes: a factor-based study, in: Journal of Management Information Systems, Vol 24(1), 101–134 Koch C, Fedtke S (2020) Robotic Process Automation: ein Leitfaden für Führungskräfte zur erfolgreichen Einführung und Betrieb von Software-Robots im Unternehmen, 1. Aufl. Springer Vieweg, Berlin Kokina J, Blanchette S (2019) Early evidence of digital labor in accounting: Innovation with Robotic Process Automation, in: International Journal of Accounting Information Systems, Vol 35, 1–13 Lacity MC, Willcocks LP (2018) Robotic Process and Cognitive Automation – The Next Phase, SB Publishing Langmann C (2021) Robotic Process Automation (RPA)  – Study on Characteristics of Successful RPA Implementations, retrieved on 18.03.2021 at: https://w3-­mediapool. hm.edu/mediapool/media/fk10/fk10_lokal/05_diefakultt/03_personen/langmann/ final_rpa_study_2021_results_report_010221_web_kl.pdf Langmann C, Kokina J (2021) Robotic Process Automation (RPA) in Accounting, in: Czarnecki C, Fettke P (eds.): Robotic Process Automation  – Management, Technology, Application, De Gruyter Oldenbourg, 243–262. Microsoft (2020) Microsoft acquires Softomotive to expand low-code robotic process automation capabilities in Microsoft Power Automate, retrieved on 01.04.2021 at: https://flow.microsoft.com/ en-­us/blog/microsoft-­acquires-­softomotive-­to-­expand-­low-­code-­robotic-­process-­automation-­ capabilities-­in-­microsoft-­power-­automate/ Ostrowicz S, Schmidt-Schröder F (2017) Robotic Process Automation  – Ergebnisbericht Studie, retrieved on 01.03.2020 at: https://www.horvath-­partners.com/de/media-­center/studien/ robotic-­process-­automation/ Pellegrino M, Mega P (2020) Robotics Process Automation @ Merck, in: ReThinking Finance 03/2020, 33–42 Petersen J, Schröder H (2020) Entwicklung einer Robotic Process Automation (RPA)-Governance, in: HMD Praxis der Wirtschaftsinformatik, Vol. 57, Issue 6, 1130–1149 PWC (2020) Robotic Process Automation (RPA) in der DACH-Region, retrieved on 01.03.2020 at: https://www.pwc.de/de/rechnungslegung/robotic-­process-­automation-­rpa-­in-­der-­dach-­region.pdf Schmelzer A (2020) Robotics Process Automation im Mittelstand am Beispiel Wien Energie, in: ReThinking Finance 03/2020, 65–69 Schulze M, Jiles L (2020) Robotic Process Automation im Finanzbereich, in: REthinking Finance 05/2020, 4–7 Sprinthall RC (2011) Basic Statistical Analysis, 9. Aufl. Pearson, Boston Sue VM, Ritter LA (2021) Conducting Online Surveys, 2. Aufl. Sage, Thousand Oaks Taulli, T (2020) The Robotic Process Automation Handbook, 1. Aufl. Apress. Berkeley

120

5  RPA in Practice: Results of an Empirical Study

Tröndle, R (2020) Robotic Process Automation  – die Magie der Governance, in: REthinking Finance, 03/2020, 59–64 Wenzel, S (2020) Robotic Process Automation – das Altsystem von morgen oder doch Beschleuniger digitaler Transformation?, in: REthinking Finance, 03/2020, 43–48 Werner H (2020) Supply Chain Management. Grundlagen, Strategien, Instrumente und Controlling, 7. Aufl. Springer, Berlin Willcocks L, Hindle J, Lacity M (2019) Keys to RPA Success, retrieved on 01.04.2021 at: https:// www.blueprism.com/uploads/resources/white-­papers/KCP_Summary-­Executive_Research_ Report_Final.pdf

6

Application Examples for RPA in Financial and Management Accounting

6.1 Monthly Reporting in Management Accounting Reporting is a central, if not the most central process in (management) accounting. In the typical reporting process, data collection and preparation are followed by report creation and plausibility checks before the accountant then goes into analysis, commenting, and report discussion.1 Studies on the reporting process show that approximately 70% of the total effort in the process is required for data collection and preparation as well as for report preparation and plausibility checks.2 Thus, the majority of the effort in the reporting process is still in non-value-added activities. This often leaves the management accountant little time for value-added activities, such as creating additional analyses (e.g. root cause analysis), commenting, or deriving measures. However, it is precisely these activities that improve the quality of reporting and that generate added value. Nevertheless, purely quantitative reports (evaluations) can also be found in reporting, in which figures are simply extracted from various sources, processed, and sent without performing further analyses or adding comments. The creation of such quantitative reports is often time-consuming, either because of the diversity and performance of the source systems or because of the volume of figures required. Quite understandably, management accountants usually consider the activities associated with quantitative reports to be tedious and non-value-adding, even though they are necessary. Robots are ideal for creating purely quantitative reports. The robot logs into the source systems, performs the desired queries, and copies the results of the prepared data into a central file (e.g. Excel). In the process, the robot can also perform validations or checks (e.g. reconciling the figures from system 1 with system 2). The robot is also capable of

 See also International Group of Controlling (2017) on the reporting process.  Cf. Gräf et al. (2013).

1 2

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2022 C. Langmann, D. Turi, Robotic Process Automation (RPA) - Digitization and Automation of Processes, https://doi.org/10.1007/978-3-658-38692-4_6

121

122

6  Application Examples for RPA in Financial and Management Accounting

regularly updating the reports and automatically distributing them to the respective recipient groups by e-mail. The effects of using robots in reporting are immediately measurable and apparent: time savings, employee enthusiasm, and/or increased process quality. Therefore, many companies robotize reporting as one of the first processes in financial and management accounting. Efficiency gains through the use of RPA in reporting are particularly evident when reports have to be created multiple times for each product group, recipient, or team. Although often only marginal adjustments in the parameters are necessary (e.g. product A or product B), the additional reports lead to a higher workload for the employees, while at the same time valuable capacity (e.g. during month-end closing) is lost.

6.2 Invoice Dispatch at the KION Group As a leading global intralogistics provider of supply chain solutions, the KION Group is driving forward the digital transformation of its finance division with the use of RPA. The aim here is to efficiently support employees in their tasks by automating and standardising processes. This context can be illustrated using the example of invoice dispatch.3 KION’s customers require KION to upload their invoices to a portal. The accounts receivable department has to operate a large number of portals due to the number of customers in different countries. Until then, invoices were entered manually, with a high dependency on loading times. Due to the increasing number of invoices for the portals, a software robot was developed for the process. Here, the robot first identifies the final invoices and determines the type of invoice dispatch. The robot identifies the invoices with the dispatch type ‘portal’ and enters the relevant fields from the ERP system into the portal.4

6.3 Application Processing at KfW In Germany, due to the Covid-mitigation law in the context of the Covid pandemic, many companies were applying for a deferral of their current loan repayments at the Kreditanstalt für Wiederaufbau (KfW), a national development bank. This has not only led to a sharp increase in the number of applications compared to normal figures but also to the requirement to process the high number of applications quickly, as otherwise the solvency of the companies would be at risk. Since a manual application processing does not fullfill this requirement, an automation of the electronic deferral applications was implemented within 5 weeks based on RPA. A software robot opens the application, checks it, enters changes to the repayment schedule, submits the application for review, and finally for final  Cf. Beisswenger et al. (2020), p 22.  Cf. Beisswenger et al. (2020), p 23.

3 4

6.5 Accounting for Accruals and Deferrals

123

approval using the dual control principle. The dual control, i.e. double check, was ensured by two completely separate robots, one robot taking on the role of ‘first processor’ and the other taking on the role of ‘approver’. In this way, an automation rate of 80% was achieved.5

6.4 Preparation of the Quarterly Closing Report at Union Investment As an active asset manager in the cooperative financial network, Union Investment has been using RPA productively since the beginning of 2019. Union Investment uses software robots to create quarterly reports, among other things. In this context, a software robot creates a quarterly closing report every 3 months that informs the management teams of the various Union Investment companies about the current situation. Specifically, the robot loads the company’s balance sheets, income statements, and line item lists from SAP and enters them into an Excel spreadsheet. It then formats them and checks the plausibility of the results. The manual preparation of a single quarterly financial statement by an employee takes about 1–2 days, while the software robot needs only a fraction of the time.6 With or before the introduction of RPA, an optimization of the process took place. On the one hand, uniformly structured reports were defined and the reports were thus standardized. On the other hand, individual report creation was replaced by central data processing.7

6.5 Accounting for Accruals and Deferrals When introducing RPA in financial and management accounting, the question of whether robots should also make booking entries in the accounting system is often discussed critically. Among other things, companies see the risk that robots may make incorrect entries. Such risks in connection with accounting systems can be mitigated. If robots are to carry out booking entries - for which Unattended RPA (“dark processing”) is often used (see Chap. 2) – the robots are usually first given their own user ID. The user ID clearly defines the robot’s authorizations and access rights (Sect. 3.5.1). If robots make booking entries, the focus of the accountant’s tasks shifts to controlling the bookings and the overall process. The accountant controls the robot’s bookings according to the dual control principle. The quality of the bookings depends on the quality of the input files. If the input files are always created in the same form, robots can also process repetitive bookings and post them in the accounting system without any problems. The input files are usually Excel templates containing account information, amounts, and  Cf. AKOA (2021).  Cf. Tröndle (2020). 7  Cf. Tröndle (2020), p 63. 5 6

124

6  Application Examples for RPA in Financial and Management Accounting

predefined texts. The robot reads the required information from these and uses it to make the postings in the accounting system. The Excel templates for the postings are often created decentrally by the respective departments and delivered to the accounting department. To ensure stable posting by the robot, the Excel templates must be standardized.

6.6 Cost Allocation in Cost Accounting The (monthly) cost allocation in the sense of the allocation of the secondary cost centers to the primary cost centers or the allocation to cost objects is one of the most important tasks of the cost accountant. The allocations, cost center allocations, and general ledger allocations are usually carried out using fixed, predefined allocation runs, whereby the allocation keys (parameters) are (can be) maintained monthly by the controller. Depending on the complexity, the execution of the allocation runs is often time-consuming and sometimes takes several hours. The cost allocation process is ideally suited for processing by robots. The robot receives the allocation keys (parameters) in a prepared input file (so-called config file) and systematically performs the allocations in the desired order. Subsequent controls check whether all costs have been allocated correctly or whether all cost centers that should be credited have been credited accordingly. A “cost allocation robot” can also be used during off-peak hours, giving employees more time for higher-value tasks (e.g. analyses). The robot can also take over subsequent processes such as the creation of cost center or cost type reports. After successful allocation, the robot updates the reports and sends them directly to the cost center managers by e-mail.

6.7 Electronic Booking Document at Heraeus In 2017, the Heraeus technology group began to introduce or test the first software robots in accounting. In the expansion of the RPA solution to other processes within the SSC Accounting, software robots were developed for the ‘electronic booking document’ process, among others. Heraeus describes the initial situation for this process as follows. In terms of volume, approximately 36,000 general ledger documents were booked in the SSC accounting system using electronic booking documents in 2016 and 2017. Here, (mostly) management accounting sends a booking request to a central e-mail box. The booking information (e.g. company code, account, cost center) is attached to the e-mail in a standardized Excel file. The employees in the SSC open the e-mail and start a macro in the Excel file, which makes a booking entry attempt in SAP and creates a process log. Depending on whether the booking entry attempt was successful or not, the e-mail with attachments is archived in SAP or an individual check/correction is performed. The process can be described as stable as over 90% of the attempts are successful. The use of RPA for this standardized process, namely opening emails, opening Excel documents, and

Literature

125

starting a macro reduced the required resource capacity to a quarter, namely from 2.0 to 0.5 FTE.8

6.8 Creation and Validation of Upload Files It is not uncommon to find fragmented and heterogeneous system landscapes in companies, resulting from the diversity of (acquired) companies or from the geographical distribution of the company. The integration of individual systems into a uniform company-wide system platform, into which all business units enter their figures or upload them automatically through interfaces, has therefore been on the list of pending projects in many companies for years. However, the costs and complexity of these projects prevent them from quickly moving up the priority list. It is therefore hardly surprising that, according to the Horváth & Partners CFO Study (2018), one in two CFOs (and thus 20% more than in the previous year’s survey) complain about a fragmented and heterogeneous IT landscape.9 There is still a lot of data or files being manually uploaded and validated into systems in companies today. The preparation and uploading of these files (upload files) is usually time-consuming due to required validations. Added to this is the unfavorable circumstance that the upload usually coincides with certain key dates such as the month-­ end closing, which unnecessarily eats up employee capacities. This is where the use of robots comes into play. After the upload files have been created by a source system and automatically stored in a predefined folder, the robot starts with the automated processing. The robot either processes the upload file first or uploads it directly to the desired target system and then validates the process. This form of robotization proves to be particularly efficient when numerous, standardized upload files need to be uploaded to a target system on a regular basis (e.g., monthly).

Literature AKOA (2021) Wie die KfW die Liquidität während der Corona-Krise durch den Einsatz von RPA gesichert hat, retrieved on 07.05.2021 at: https://www.akoa.com/de/client-­stories/kfw Beisswenger A, Schlott A, Von Hirschausen G, Küster T, Hamann K, Leser C (2020) Robotic Process Automation im Accounting  – Beispiele von ProSiebenSat.1, KION und PwC, in: REthinking Finance, 03/2020, 17–26 Gräf J, Isensee J, Kirchmann M, Leyk J (2013) KPI-Studie 2013 – Effektiver Einsatz von Kennzahlen im Management Reporting. Studie  – Horváth & Partners, retrieved on 16.07.2018 at: ­https:// www. horvath-­partners.com/fileadmin/horvathpartners.com/assets/05_Media_Center/PDFs/ deutsch/KPI-Studie_2013_Impulspapier_v3.pdf. Accessed on 16. Juli 2018

 Cf. Warisch and Winkler (2019), p 307 ff.  Cf. Horváth & Partners (2018), p 2.

8 9

126

6  Application Examples for RPA in Financial and Management Accounting

Horváth & Partners (2018) CFO-Studie 2018: „Chancen der Digitalisierung erkennen und die digitale Transformation der Finanzfunktion meistern“, retrieved on 18.03.2019 at: https:// www.horvath-­partners.com/fileadmin/horvath-­partners.com/assets/05_Media_Center/PDFs/ deutsch/180626_WP_CFO_Studie_B_g.pdf International Group of Controlling (2017) (eds.) Controlling-Prozessmodell 2.0: Leitfaden für die Beschreibung und Gestaltung von Controllingprozessen, 2. Aufl. Haufe Lexware. Freiburg KPMG (2020) Digitalisierung im Rechnungswesen 2020, retrieved on 01.04.2021 at: https:// home.kpmg/de/de/home/media/press-­releases/2020/09/digitalisierung-­im-­rechnungswesen-­ stagniert.html Tröndle, R (2020) Robotic Process Automation  – die Magie der Governance, in: REthinking Finance, 03/2020, 59–64 Warisch W, Winkler D (2019) Robotisierung im Rechnungswesen – Einblicke in ein Praxisprojekt, in: Fink C, Kunath O (eds.) Digitale Transformation im Finanz- und Rechnungswesen, Schaeffer-­ Poeschel, Stuttgart, 295–322

7

Conclusion and Outlook

With RPA, a new digitalization technology for the automation of processes in financial and management accounting is currently establishing itself on the market. Unlike previous automation solutions, RPA can be implemented relatively quickly and cost-effectively, in some cases without in-depth programming knowledge. Therefore, the increasing use of RPA in companies in the context of financial and management accounting comes as little surprise. For many companies, RPA seems to be a credible answer to the increasing pressure on efficiency that finance and accounting departments in companies are facing. In view of the impressive efficiency potential that can be leveraged with RPA, companies are tempted to introduce an RPA solution as quickly as possible. However, the introduction of RPA in financial and management accounting is not a purely IT-related process, but rather a complex undertaking with a multitude of dimensions to be considered. This book therefore presents the most central dimensions that need to be considered in the RPA context and reports on previous experience and practical examples. The book focuses initially on the question, which processes in financial and management accounting are suitable for transfer to RPA, i.e. robotization. To select suitable processes, various selection criteria are presented and linked in a scoring model. The presented heatmaps for the central processes in financial and management accounting provide valuable indications for the process selection. In addition to the necessary roles for the introduction and operation of RPA, the RPA governance is described in detail and the various operating models for RPA are presented. Through the well-founded discussion of the operating model alternatives, companies are able to make a resilient decision that fits the objective and the respective framework conditions. Without a sustainable anchoring of RPA in the organization by means of suitable change management measures, RPA initiatives are doomed to failure in the long run. Against this background, the authors discuss measures that have been tried and tested in practice and are specific to RPA.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2022 C. Langmann, D. Turi, Robotic Process Automation (RPA) - Digitization and Automation of Processes, https://doi.org/10.1007/978-3-658-38692-4_7

127

128

7  Conclusion and Outlook

The application fields of RPA will systematically expand over the next few years, from today’s highly repetitive, simple tasks to higher-value, more complex tasks. RPA will thus increasingly be replaced by IPA. The linking of RPA with other digitalization technologies such as analytics or artificial intelligence will play a decisive role here. This means that today’s ‘simple’ robots, in which every step of execution, no matter how small, must be precisely specified, will become much more intelligent and independent. The exciting question here is how the robots will work together with their human colleagues in the future. Practice and research will certainly explore this aspect further in the coming years.