Robotic Process Automation (RPA) in the Financial Sector: Technology - Implementation - Success For Decision Makers and Users [1st ed. 2021] 3658329734, 9783658329730

Citation preview

Mario Smeets Ralph Erhard Thomas Kaußler

Robotic Process Automation (RPA) in the Financial Sector Technology – Implementation – Success For Decision Makers and Users

Robotic Process Automation (RPA) in the Financial Sector

Mario Smeets · Ralph Erhard · Thomas Kaußler

Robotic Process Automation (RPA) in the Financial Sector Technology—Implementation—Success For Decision Makers and Users

Mario Smeets Düsseldorf, Germany

Ralph Erhard Düsseldorf, Germany

Thomas Kaußler Düsseldorf, Germany

ISBN 978-3-658-32973-0 ISBN 978-3-658-32974-7  (eBook) https://doi.org/10.1007/978-3-658-32974-7 This book is a translation of the original German edition „Robotic Process Automation (RPA) in der Finanzwirtschaft“ by Smeets, Mario, published by Springer Fachmedien Wiesbaden GmbH in 2019. The translation was done with the help of artificial intelligence (machine translation by the service DeepL.com). A subsequent human revision was done primarily in terms of content, so that the book will read stylistically differently from a conventional translation. Springer Nature works continuously to further the development of tools for the production of books and on the related technologies to support the authors. © Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 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. Responsible Editor: Vivien Bender This Springer 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

Contents

1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 State of the Art Research. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Robotic Process Automation—Background and Introduction. . . . . . . . . . . . 7 2.1 What is RPA— and What is Not. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 RPA from a Technical Perspective. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3 Cost Reduction, Quality Improvement, Time Saving, and More—The Diverse Potentials of RPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4 RPA in the Context of Process Management. . . . . . . . . . . . . . . . . . . . . . . 30 2.5 RPA in the Context of (Process) Digitisation . . . . . . . . . . . . . . . . . . . . . . 32 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3 Application Areas of RPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.1 Suitable Industries, Companies and Business Sectors. . . . . . . . . . . . . . . . 37 3.2 Technical Selection Criteria for Automatable Processes. . . . . . . . . . . . . . 40 3.3 Selection of RPA Use Cases in the Financial Sector. . . . . . . . . . . . . . . . . 42 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4 RPA Market Overview and RPA Software Solutions . . . . . . . . . . . . . . . . . . . 47 4.1 The RPA Market—Hype or Long-Term Trend. . . . . . . . . . . . . . . . . . . . . 47 4.2 Software Providers and Their Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.3 RPA Consultants and Implementation Partners. . . . . . . . . . . . . . . . . . . . . 50 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5 The Implementation of RPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.1 Overview of the Basic Process Model—Phases . . . . . . . . . . . . . . . . . . . . 61 5.2 Setting up a Suitable Project Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3 Selection of the Processes to be Automated . . . . . . . . . . . . . . . . . . . . . . . 64 5.4 Selection of a Suitable RPA Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.5 Execution of a Proof of Technique (PoT) . . . . . . . . . . . . . . . . . . . . . . . . . 76 v

vi

Contents

5.6 Realisation of an Upstream Process Optimisation. . . . . . . . . . . . . . . . . . . 77 5.7 (Agile) Development of Artefacts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.8 Test Design, Test Execution and Artefact Acceptance. . . . . . . . . . . . . . . . 84 5.9 Emergency Plans and Fallback Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.10 Ensuring the Long-Term Operation of the RPA Solution. . . . . . . . . . . . . 89 5.11 RPA Rollout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6 Introduction of RPA Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.1 Need for RPA Governance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.2 Contents and Steps to Establish RPA Governance . . . . . . . . . . . . . . . . . . 101 6.3 RPA Units and Their Organisational Classification. . . . . . . . . . . . . . . . . . 106 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7 Success Factors of RPA Implementations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.2 Correct Process Selection and Preparation . . . . . . . . . . . . . . . . . . . . . . . . 120 7.3 Early Establishment of RPA Governance . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.4 Consideration of Regulatory and Related Framework Conditions . . . . . . 121 7.5 Comprehensive Documentation Through Technical Concepts and Instructions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 7.6 Involvement of Relevant Stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 7.7 Building up Internal Know-How Carriers and Promoters. . . . . . . . . . . . . 130 7.8 Training of Employees in the Use of RPA. . . . . . . . . . . . . . . . . . . . . . . . . 131 7.9 Accompanying Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 8 Special Case—RPA in One-Time Situations . . . . . . . . . . . . . . . . . . . . . . . . . . 133 8.1 Distinction from the Automation of Repetitive Processes. . . . . . . . . . . . . 133 8.2 Case Study: RPA as Data Migration Tool. . . . . . . . . . . . . . . . . . . . . . . . . 134 9 Looking to the Future—The FurtherDevelopment of RPA Technology. . . . 137 9.1 Different Directions for Further Development . . . . . . . . . . . . . . . . . . . . . 137 9.2 Possible Combinations with Other Software Solutions. . . . . . . . . . . . . . . 138 9.3 Further Development of RPA: Intelligent Automation—Cognitive and Self-Learning Complete Solutions . . . . . . . 139 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

About the Authors

Mario Smeets  is a managing director of the swedish fashion and lifestyle brand Sanna Lindstroem, a management consultant as well as the founder and former managing director of a company for process automation. The author is Master of Business Administration with focus on Management of Financial Institutions and Master of Science in Economics.

Ralph Erhard is founder and partner of DCP Deutsche Consulting Partner. His consulting focus for banks and insurance companies is on strategic issues, the further development of business models, organisational consulting, and the implementation and support of (IT) implementations. He has been involved in process optimisation and automation for more than 20 years. The author is a graduate industrial engineer and Master of Science with focus on industrial engineering.

vii

viii

About the Authors

Thomas Kaußler  is founder and partner of DCP Deutsche Consulting Partner and specialises in consulting in the financial services segment for banks, insurance companies, service providers and system providers in the capital market business. His focus is on implementation and migration projects as well as the optimisation of organisational structures and processes including the operational implementation and design of business models and (IT) management processes. The author is a graduate industrial engineer.

1

Introduction

Abstract

Chapter 1 provides a first introduction to the topic of “RPA in the financial sector”. In addition to an overview of the contents of the book and its structure, the current state of research in the field of RPA is presented.

1.1 Introduction Everyone knows them: Time-intensive processes that keep other often more important activities from taking place, and which are completely rule-based and follow rigid patterns; maintaining spreadsheets, transferring data from one application to another or checking system entries using long lists, mostly in financial institutions in the back office, but also in IT or controlling and accounting. Automating such activities would give employees freedom for other, more complex tasks. Often, the costs of automation by creating interfaces and (re)programming the applications exceed their possible benefits or are simply technically not feasible. Robotic Process Automation (RPA) offers an alternative. With this software solution, applications can be automated without having to intervene in program codes or create interfaces. RPA is a technology that is neither old nor new, but is currently enjoying enormous attention, especially in the financial sector. Well-known consulting firms promise a large growth of the RPA market in the coming years. According to a study by the Information Services Group (ISG), 72% of all companies1 surveyed are already expected to use RPAs in 2019—either in live operation or at least as part of pilot

1Companies

in Germany, Austria and Switzerland.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 M. Smeets et al., Robotic Process Automation (RPA) in the Financial Sector, https://doi.org/10.1007/978-3-658-32974-7_1

1

2

1 Introduction

projects (see Otto and Longo 2017). Other studies also quote figures of around 70% (see Ostrowicz 2017, for example). Dickgreber et al. (2018) assume that the global RPA market will be worth five billion US dollars in 2020. This corresponds to an annual growth rate of 56% since 2012—which has even been increasing continuously in recent years. The McKinsey Global Institute assigns the global financial industry an (aggregated) technical automation potential of 43% (see McKinsey Global Institute 2017). Whether this refers to specific processes or individual activities is not clear from this highly aggregated figure. Nevertheless, the core statement is clear: the financial sector has enormous potential for increasing efficiency and saving costs through automation, much of which can be leveraged with RPA. Even though many companies in the financial sector have already recognised this potential and are beginning to use RPA, the number of companies with widespread use of the technology is still very small. According to a survey by the consulting firm Deloitte, only 3% of all companies surveyed use more than 50 RPA bots (see Watson and Wright 2017). At the same time, 63% of the companies surveyed were not able to meet the deadlines they had set themselves for RPA projects. Lamberton (2017) reports that around 30 to 50% of the RPA projects carried out by its customers fail. There is a corresponding need for action in order to be able to implement successful RPA projects in an organisation and to exploit the potential of this technology. To do this, it is necessary to understand and classify the technology and to know its relevant areas of application. The present book provides support in this respect. In addition, it offers its readers the opportunity to find their own answer to the question of whether RPA is just hype or a promising technology for long-term success. The book serves as a guide through a complete RPA implementation project. It enables you to carry out the (initial) RPA implementation in your own organisation. The aim is not to provide a detailed explanation of the technical background of RPA. Similarly, the focus is not on guidelines and recommendations for RPA developers. Rather, the work is intended for future or already experienced users of RPA and for anyone interested in the technology. Process and technology managers at all hierarchical levels of IT and organisational areas, as well as users and those responsible in the specialist areas— across all industries, even if the focus here is on the financial sector. Structure First, Chapter 2 defines the understanding of RPA used here. For this purpose, RPA is distinguished from other, partly similar technologies. This is followed by an in-depth look at the technical properties of RPA before the potential benefits of the technology are discussed in detail. Chapter 2 concludes by placing the technology in the context of process management and (process) digitalisation. Chapter 3 provides an overview of possible areas of application of RPA—across sectors and in relation to the financial sector. From this, the (general) technical selection criteria for processes that can be automated are derived. Finally, an exemplary selection of possible concrete use cases in the financial sector is presented.

1.1 Introduction

3

Chapter 4 deals with the RPA market. For this purpose, an overview is provided which allows a feel for the current development of the RPA market. After a brief discussion of the right choice of software providers, possible support services by RPA consultants and implementation partners are discussed in detail. Chapter 5 explains the (project-based) procedure for implementing RPA. The focus is on topics that are relevant to the initial implementation of RPA. However, other aspects also apply to subsequent implementations. The chapter can be used as a kind of guideline for implementing RPA in your own organisation. Many of the topics outlined earlier are addressed in depth in this chapter—for example, selecting the right RPA software and suitable RPA processes. Chapter 6 deals with RPA governance, a topic that has rarely been considered in the relevant literature to date, but which is at the same time highly relevant, especially when it comes to the long-term operation of RPA. In addition to the contents of RPA governance and the procedure for its introduction within an organisation, another thematic focus is the establishment of the so-called RPA unit—the integration of RPA into scheduled operations. Chapter 7 summarises the most important factors for successful RPA introduction and use and supplements these with other relevant components. Chapter 8 shows by means of a practical example how RPA can provide added value in non-recurring situations. Chapter 9 closes the book with a look into the (near) future. Here two different directions of development are discussed: on the one hand, the manifold possibilities of combining RPA with other technologies, the second is the further development of RPA technology itself. Contribution to Scientific Discourse RPA is still a young technology. In addition, RPA is one of many process management tools (see Sect. 2.4), even though it is currently receiving special attention, especially in the financial sector. As a result, the amount of scientific literature already available and the number of robust scientific studies is (still) relatively small. Although the present work is intended to support practitioners in the use of RPA, it is also a declared objective to prepare the basic outlines of a future scientific discourse. For this purpose, statements from documented scientific studies or practice reports were first evaluated and then validated by expert interviews. In addition, these expert interviews were used to develop possible future fields of research in the field of RPA by means of open questions. Appendix: “Explanation of expert interviews” explains the procedure in detail. The results of the expert interviews are listed at the relevant places within the book.

4

1 Introduction

1.2 State of the Art Research Scientific research on RPA has so far been limited to introductory essays explaining the technology, distinguishing it from other technologies and opening up potential applications. This is supplemented by individual case studies and expert interviews. Allweyer (2016) explains the technology in its basic features. He presents features that distinguish it from other similar technologies and provides a comprehensive explanation of the areas of application and potential benefits of RPA. In addition, he provides a first outlook— from a scientific perspective—on a highly relevant field of research, namely the impact of RPA on employees and workplaces and thus the future interaction between man and machine. Van der Aalst et al. (2018) position RPA in the environment of other automation technologies. They compare RPA in particular with “Straight Through Processing” (STP). The authors also open up further questions that need to be answered. These are, for example, the question of the correct process selection criteria or—here too—questions relating to the interaction between humans and machines and the allocation of responsibility for machine malfunction. As one of the landmark case studies, Lacity and Willcocks (2016) explain the use of RPA at Telefónica O2. They address many issues relevant to the use of the technology and provide valuable initial practical experience and comparative values. They also list twelve other companies that have introduced RPA but have not carried out any concrete studies on these use cases. Willcocks et al. (2017) use another case study based on the company Xchanging to derive further practical recommendations for the use of RPA. In particular, they explain a sensible procedure for RPA implementation. Willcocks and Lacity (2016) bring together the results of their case studies, expert interviews, and other results of their research on RPA. Their focus is on research into the automation of backoffice processes. A case study based on a company operating in the German market is being conducted by Hermann et al. (2018). The focus is on the added value that RPA can offer in the controlling department of any company. Kharchenko et al. (2018) examine the influence of RPA (and other technologies) on the previous business models of call centres. In addition to the literature published in scientific journals, there are various studies that have been carried out recently by larger consulting firms and the like. Examples are Ostrowicz (2017, 2018) or Watson and Wright (2017). From a scientific point of view, the studies are only of limited use, for example, because the methodology applied is not always explained in detail or the research design chosen lacks underlying premises. This is understandable; the studies rarely pursue the goal of scientific research. Nevertheless, they provide relevant statements for practice and starting points for further research. For this reason, their results—just like those of the other literature mentioned above—are regularly used and cited in this work.

References

5

Other sources are available in the form of guides for RPA developers or consultants (see for example Murdoch 2018). These generally do not correspond to scientific standards but are nevertheless used with the objective of a practical guide.

References Allweyer T (2016) Robotic Process Automation—Neue Perspektiven für die Prozessautomatisierung. Fachbereich Informatik und Mikrosystemtechnik Hochschule Kaiserslautern. https://www. kurze-prozesse.de/blog/wp-content/uploads/2016/11/Neue-Perspektiven-durch-Robotic-ProcessAutomation.pdf. Accessed: 27. Dec. 2018 van der Aalst WMP, Bichler M, Heinzl A (2018) Robotic process automation. Bus Inf Syst Eng 60(4):269–272. https://doi.org/10.1007/s12599-018-0542-4 Dickgreber F, Schneider H, Warren B, Adam R (2018) Robotic process automation. https://crm. arvato.com/en/solutions/crm-and-customer-services/download/whitepaper-robotic-processautomation-rpa-for-finance-back-office-processes.html#download. Accessed: 20. Jan. 2019 Hermann K, Stoi R, Wolf B (2018) Robotic process automation im finance & controlling der MANN+HUMMEL Gruppe. Controlling 30(3):28–34 Kharchenko A, Kleinschmidt T, Karla J (2018) Callcenter 4.0—Wie verändern Spracherkennung, Künstliche Intelligenz und Robotic Process Automation die bisherigen Geschäftsmodelle von Callcentern. HMD 55:383–397. https://doi.org/10.1365/s40702-018-0405-y Lacity M, Willcocks L (2016) Robotic Process Automation at Telefónica O2. MIS Q Exec 15(1):21–35 Lamberton C (2017) Get ready for robotic process automation. https://www.ey.com/gl/en/industries/financial-services/fso-insights-get-ready-for-robotic-process-automation. Accessed: 28. Jan. 2019 McKinsey Global Institute (2017) A future that works: automation, employment, and productivity. McKinsey & Company, New York Murdoch R (2018) Robotic process automation. Guide to building software robots, automate repetitive tasks & become an RPA Consultant. Eigenverlag Ostrowicz S (2017) Einsatz von Robotics in der Finanzindustrie. https://www.horvath-partners. com/es/media-center/studien/detail/einsatz-von-robotics-in-der-finanzindustrie/. Accessed: 24. Jan. 2019 Ostrowicz S (2018) Next Generation Process Automation: Integrierte Prozessautomation im Zeitalter der Digitalisierung. Ergebnisbericht Studie 2018. Horváth & Partners, Frankfurt a. M. Otto S, Longo M (2017) ISG-Studie: Robotic Process Automation (RPA) sorgt für mehr Produktivität und nicht für Jobverluste. https://www.isg-one.com/docs/default-source/defaultdocument-library/isg-automation-index-de_final_form.pdf?sfvrsn=15defe31_0. Accessed: 20. Jan. 2019 Watson J, Wright D (2017) The robots are ready. Are you? https://www.google.com/url?sa=t&rc t=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEwjizofA5MnfAhURYlAKHWHaBqoQ FjAAegQIChAC&url=https%3A%2F%2Fwww2.deloitte.com%2Fcontent%2Fdam%2FDeloitt e%2Ftr%2FDocuments%2Ftechnology%2Fdeloitte-robots-are-ready.pdf&usg=AOvVaw2luiVI NhzNclPK70Ac7_zc. Accessed: 31. Dec. 2018 Willcocks L, Lacity M (2016) Service automation. Robots and the future of work. Steve Brooks Publishing, Warwickshire Willcocks L, Lacity M, Craig A (2017) Robotic process automation: strategic transformation lever for global business services? J Inf Technol Teach Cases 7:17–28

2

Robotic Process Automation— Background and Introduction

Abstract

The chapter first defines the understanding of robotic process automation (RPA) used here. This is distinguished from other automation solutions and other technologies that are regularly referenced in connection with RPA. An introduction to the actual RPA technology follows. The focus here is not on a detailed IT-technological background, but on a fundamental understanding of technology for all relevant target groups. This is followed not only by a detailed discussion about the possible advantages and disadvantages of RPA, but also about the disadvantages of the technology, before finally classifying RPA in the context of process management.

2.1 What is RPA— and What is Not Basic Definition of RPA Before considering the technological details, the advantages and also the disadvantages of RPA, a common understanding of RPA must be established. How does it differ from similar technologies and why is RPA currently on everyoneʼs lips? As with comparative developments, there is no clear definition of RPA in the literature. Rather, there are various definitions and descriptions of what RPA is and what it is not. For example, van der Aalst et al. (2018, p. 269) describe RPA as a collective term for tools that operate other applications on computer systems via the graphical user interface, as a human would do. Allweyer (2016) describes RPA as a software program that supports people in performing certain tasks or completely replaces them. The following definition of RPA should be applied here. RPA is not a physical machine. Rather, RPA is installable software. The aim of this software is to support people in carrying out their activities or to relieve them of © Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 M. Smeets et al., Robotic Process Automation (RPA) in the Financial Sector, https://doi.org/10.1007/978-3-658-32974-7_2

7

8

2  Robotic Process Automation—Background and Introduction

individual activities completely. It communicates with other digital systems, extracts data, manipulates it, and inserts it into other applications. RPA is suitable in its basic features for fully or partially automated handling of business and administrative processes. It is a solution that does not require any fundamental changes to the existing IT infrastructure in order to be used. It uses the user interface in the same way as a human would use it. RPA can therefore also be described as a non-invasive technology. When we talk about an RPA bot, we refer to a single license of RPA software. Here the term “bot” is used instead of the alternative term “robot” to clarify that the software is acting independently—i.e. automatically. The RPA solutions under consideration here do not use artificial intelligence, components of machine learning, that is, the independent generation of knowledge by a system, or similar—unless explicitly stated otherwise. The reason for this is that experience shows that most applications—at least in extensive, high-volume process automation—in the financial sector have so far been limited to such (basic) solutions. Results of the Expert Interviews The experts surveyed confirm that the focus of the use of RPA to date has tended to be on less complex, highly structured, and frequently occurring processes. As a rule, these processes are automated with RPA. Further solutions, for example using artificial intelligence or components of machine learning, will only play a role in the future.

Types of RPA The term RPA does not always refer to the same type of technology. In the relevant literature not only at least two (see for example, Allweyer 2016, p. 2), but also three different types of RPA can be found. The latter are (see Willcocks et al. 2017, p. 19): 1. Desktop RPA, 2. RPA platforms, 3. IT software development tools. Desktop RPA tools (also called “robotic desktop automation”—RDA) are based on functionalities such as the execution of macros and scripts, and the use of so-called “screen scraping technologies” (which are used to read information or texts on the screen). In a simplified way, desktop RPA first records the actions of the (human) user. The tool then supports the user in carrying out routine tasks. This is not so much the automation of a documented, standardised process flow, but the pure reproduction of user input. Every user can carry out individual automation for his workstation. Although the tools mostly correspond to the definition of RPA chosen above: Desktop RPA is not suitable for an actual RPA implementation—in the understanding used here. This does not mean that desktop RPA cannot be a promising solution. Depending on the area of application and technical conditions, it may even be the only sensible solution.

2.1  What is RPA— and What is Not

9

For example, desktop RPA is successfully used in the service centre of a leading German energy company, where it supports employees in customer contact by automating subprocesses. The bots compile the relevant data in real time and support calculations (see Manager Magazin 2019). An alternative to desktop RPA are RPA platforms (also known as “enterprise RPA”, see Willcocks et al. 2017, p. 19). These have at least the same technical capabilities as desktop RPA tools and also meet the definition chosen above. In contrast to desktop RPA tools, however, they are not installed and operated on individual workstations (“desktops”), but are located on servers. Although process sequences can be recorded here as well, this is rather the exception. Significantly more frequently, process flows (hereinafter also referred to as “artefacts”) are created in a standardised form and make use of command libraries, for example, for login and logoff (similar to IT programing, but “easier” to implement, as will be shown in the following). The number of bots running on the RPA platforms can be scaled to almost any size. Central monitoring and targeted control are also possible—either by humans or by other bots (also known as “orchestrators” or “control rooms” depending on the RPA software provider). The third type, IT software development tools, is very different from the previous two. In order to be able to automate processes with them, extensive IT/programing knowledge is required. With the other two types, the operation of the tools—and thus the automation—can be carried out by business or process experts after a training and familiarisation phase. The third type of solution is often more like business process management (BPM) tools. A comparison of the three types of RPA outlined above quickly shows that only the first two are RPA within the definition used here. IT software development tools should, therefore, not be considered further here. As the following sections and chapters will show, RPA tools only reveal their full benefit when standardised processes with high volumes are automated across workstations. For this reason, type 2—the RPA platform or enterprise RPA solution—is the type that will be relevant in the following sections and chapters. Another, regularly recurring designation of the two types distinguishes between “attended” and “unattended” RPA bots (see for example, Appliedai.com 2017, p. 11). The “attended case” can be equated with the type desktop RPA, the “unattended case” with the RPA platform, that is, bots that act independently and may even be controlled by other bots. Both of them correspond in their properties to a large extent to the types distinguished above. Demarcation of RPA from other technologies For the purpose of further consideration, it is necessary to distinguish RPA in two directions. First, RPA must be distinguished from other, traditional process automation solutions in Fig. 2.1. Here, different solution approaches are assessed on the basis of the frequency of the process flow and the degree of case diversity. Meaning: One “case” corresponds to one process run. If a securities account is created and the process “create

10

2  Robotic Process Automation—Background and Introduction

Fig. 2.1  Differentiation of RPA on the basis of case frequency and diversity (following van der Aalst et al. 2018, p. 270)

Fig. 2.2  Classification of RPA according to the degree of automation and the use of artificial intelligence (based on Ostrowicz 2018, p. 4)

securities account” is run once, this is a case. Figure 2.2 then distinguishes between this process and more advanced technologies such as artificial intelligence. The criteria here are the degree of automation and the degree of use of artificial intelligence. Differentiation Based on Case Frequency and Degree of Case Diversity The vertical axis shows the fall frequency, for example, the number of executions of a certain process in a certain time period, increasing from bottom to top. On the horizontal axis, the degree of diversity of the cases is plotted, increasing from left to right. In the

2.1  What is RPA— and What is Not

11

left-hand area of the graph, some cases occur very frequently and are highly standardised, that is, to have only a small degree of difference. This can be, for example, the repetitive query of a certain parameter in an application every minute (case 1). On the right-hand side of the figure are the cases that occur only rarely and are very individual, which means they have a high degree of diversity. This could be, for example, the consultation of a customer by a customer advisor (case 3). For case 1, automation is a possible option. Due to the enormously high degree of standardisation and the high frequency of cases, well-known methods of process automation such as straight-through processing (STP), workflow management systems (WfMS), or business process automation (BPA) are suitable here. The main distinguishing feature of RPA is the way it is integrated into the applications to be automated. The known methods use programming interfaces and therefore often mean significantly more effort in implementation and usually require deep intervention in the automated systems (see also Allweyer 2016, p. 7). However, these solutions are usually even more stable than RPA solutions, which is why their use can be advantageous in case 1 outlined here. In case 3, automation is not worthwhile (for example, from a cost–benefit perspective) or is completely impossible, as in the case of customer consulting. Here, only a human being can perform the task. This is particularly the case if the consulting process does not follow predefined rules. All other cases (case 2), which are shown in the middle of the figure, can be automated and are particularly suitable for automation with RPA. Although Fig. 2.1 can only make a sketchy and quantitatively not exactly definable distinction between RPA and other solutions, it nevertheless provides a pictorial understanding of the possibilities and limitations of using RPA. Differentiation Based on the Degree of Automation and Use of Artificial Intelligence The process automation solutions considered according to our definition work based on firmly defined rules. They do not possess any machine learning abilities or artificial intelligence properties. The latter can be regarded as a further development of existing and proven RPA solutions. RPA represents the first step in this process (or the beginning of an “automation journey”, see Ostrowicz 2018, p. 4). As seen later on, it is possible to discuss whether these are actually further developments of RPA or rather RPA-related technologies that can be successfully combined with RPA. Figure 2.2 shows RPA and its further developments or related technologies. In contrast to RPA, “cognitive automation” has machine learning capabilities and recognises basic patterns within small amounts of unstructured data. The technology is used in particular to structure previously unstructured content. “Digital assistants” (also known as “social robots”, see Allweyer 2016, p. 8) go one step further: The bots can interact with employees and/or customers. They have the ability to analyse unstructured content such as text and speech. In addition to machine learning, both technologies use features such as natural language processing (NLP) or optical character recognition

12

2  Robotic Process Automation—Background and Introduction

(OCR) (see Appliedai.com 2018).1 “Autonomous agents” can process highly complex tasks automatically by simulating human judgement with the help of mathematical models. However, this technology is not yet fully market ready (see Ostrowicz 2018, p. 15).2 The horizontal axis of the Fig. 2.2 describes the degree of automation increasing toward the right. In this case, we do not refer to the number of parts of a process that can be automated (which would also be possible, for example, with very complex processes). Rather, we refer to the total number of processes that can be automated, e.g. within a company. On the vertical axis, it shows the upward increasing degree of artificial intelligence. As the degree of artificial intelligence used increases, the degree of automation— that is, the proportion of processes that can theoretically be automated—also increases. This correlation is easy to understand. RPA is only suitable—in the absence of artificial intelligence—for the automation of completely rule-based processes. No individual decisions can be made. The further right in the graph, the more complex decisions can be made. As a result, there is a tendency for more processes to be considered for automation here than in a solution that works exclusively on the basis of rules. As a result, the solutions shown here are increasing both in their degree of automation and in their use of artificial intelligence. As described at the beginning, the three solutions presented next to RPA are partly described as a further development of RPA due to the increasing use of artificial intelligence (see also Appliedai.com (2018)). This assessment is not entirely correct. All four solutions have different areas of application. Autonomous agents aim at the analysis of large, unstructured data sets. The focus of digital assistants is on communication with internal or external customers. RPA, on the other hand, automates repetitive processes with high volumes. The objectives are therefore completely different. Instead of a further development of RPA, the other solutions can be seen as a kind of addition to “the toolbox in handling data”. u

Instead of a perspective replacement of RPA by other solutions, it is more likely that the tools will co-exist and complement each other in the future (see also Chap. 9).

In the end, only cognitive automation comes close to an actual further development of RPA by continuing to automate repetitive processes, but with complementary pattern

1NLP

describes the recognition, understanding, and processing of language by software. OCR means the recognition and conversion of image-based characters into machine characters (see Appliedai.com 2018). 2Willcocks and Lacity (2016, p. 47) make an alternative subdivision based on the degree of use of artificial intelligence, following the Everest Group. They divide automation tools into (a) rulebased automation (i.e., RPA in the understanding used here), (b) knowledge-based automation, and (c) artificial intelligence.

2.1  What is RPA— and What is Not

13

Table 2.1  Characteristics of RPA (following van der Aalst (2018, pp. 269–271), Allweyer (2016, pp. 2–3), Appliedai.com (2017) and Willcocks et al. (2017, pp. 19–20)) Feature

Explanation

User interface

RPA usually uses the (graphical) user interface, that is, usually the graphical user interface of the applications to be automated

Imitation of the human being

RPA imitates human input in the applications to be automated—even though no decisions are made by the user

None Programming knowledge

No programming knowledge is required to configure the bots (however, a basic understanding of IT is useful and usually required). The configuration takes place for example on the basis of flowchartsa

outside-in approach

In contrast to conventional automation solutions (STP, WfM, etc.), which follow an inside-out approach (the application is adapted from scratch or newly developed), automation with RPA does not intervene in the existing applications from a programming point of view

Software

RPA is software, not hardware. For example, RPA should not be confused with industrial robots

Structured routine tasks

RPA executes structured processes whose procedures are stable and therefore do not change. Artificial Intelligence or Machine Learning are not used

aIn the following, for reasons of comprehension, we will nevertheless speak of “programing” the RPA artefacts and bots

recognition. However, even here we can speak of a supplementation of RPA by cognitive elements rather than of a replacement of one solution by the other. Features of RPA After an initial definition of RPA and the distinction from other, similar technologies, the next step is to define characteristics of RPA. On the basis of these characteristics, a more detailed definition of RPA can be made. Additionally, the characteristics are suitable for expanding the understanding of RPA, its capabilities and areas of application.3 Table 2.1 summarises the characteristics of RPA. These are—in addition to extensive practical experience—based on van der Aalst (2018, pp. 269–271), Allweyer (2016, pp. 2–3), Appliedai.com (2017) and Willcocks et al. (2017, pp. 19–20). Results of the Expert Interviews The expert interviews conducted confirm that RPA is seen more as a bridging technology. However, this does not mean that the technology itself has a short life cycle. Rather, it means that

3Chapter

3 deals in detail with the areas of application of RPAs in the financial sector.

14

2  Robotic Process Automation—Background and Introduction

RPA is an easy way to automate existing processes for a period of several years, before (sometimes) comprehensive process innovations offer the possibility of application-internal process automation (i.e., “programing” in the classical sense). This makes automation with RPA superfluous. Since RPA has a short payback period (see Sect. 2.3), even such short lifecycles can be profitable.

RPA as “digital disruptor” RPA has the potential of a digital disrupter (see Murdoch 2018, Chapter—“RPA in the Enterprise”). This means that RPA changes processes in such a way that they are not returned to their original state over time. Murdoch (2018, Chapter “RPA in the Enterprise”) places RPA in the concept adopted by Peter Diamandis, entitled “The Six Ds of Exponentials: digitisation, deception, disruption, demonetisation, dematerialisation, and democratisation”. This helps us not only to understand the potential (positive) influence of RPA on the business and process world, but also the different perceptions of RPA by potential users, responsible persons, etc.: Digitisation The digitisation of data is the decisive step that makes the use of RPA possible in the first place. RPA can only be used if the data is digital. Deception Things that are being digitised for the first time or are created in the digital environment usually receive very little attention at first. Their potential is often underestimated. Murdoch (2018, Chapter “RPA in the Enterprise”) cites the example of digital cameras, whose potential with an initial resolution of 0.01 megapixels has been massively underestimated. The same is true for RPA. The potential of RPA technology was also initially underestimated when it was still exclusively concerned with desktop automation. Demonetisation and Disruption RPA is increasingly displacing classic software developments from the market. Software development companies are also increasingly focusing on RPA as a highly demanded alternative to software development.4 Dematerialisation This basically means that material is no longer needed to provide users with the same functionalities as before—with material. As an example, the digital camera can be used here again. This has now been replaced by the camera in mobile phones, which can be

4However,

such a development trend would not be appropriate. As shown so far and as can be seen again and again in the further course, RPA is not a replacement of classical software development work, but rather a supplement.

2.2  RPA from a Technical Perspective

15

used anywhere and at any time with the same photo quality. The digital camera is therefore dispensable. As software, RPA is already not a physical product. However, “dematerialisation” can also take place here, for example, by making RPA, as a cloud-based solution, completely scalable and allowing access to bots from any location. Individual, stationary RPA solutions (“on premise”) are no longer necessary in this scenario. Democratisation The faster the dematerialisation and the general development and use of RPA progresses, the sooner RPA technology will be available to everyone. Price models will change, prices will fall, and implementation hurdles will decrease. marker.

2.2 RPA from a Technical Perspective After a detailed introduction in Sect. 2.1, the following part deals with a more detailed technological analysis of RPA. The objective of this section is to provide an overview of how the technology is structured, how RPA can be integrated into the IT architecture of a financial services company, and how RPA communicates with other applications. Detailed IT-related instructions are not provided, as the concrete technical steps are usually software-specific. Applications Automatable with RPA A clear statement about which applications can be automated and which cannot be automated is challenging because it depends on the following two factors: 1. The selected RPA software 2. The application(s) to be automated The most relevant RPA software offer different ways to access the applications to be automated. A first way is the automation via the user interface (UI). Alternatively, RPA can also use existing interfaces or application programing interfaces (API). Direct access to the operating systems and databases or their access layers is also possible. A rarely used access option is the use of screen coordinates (also known as “screen scraping”). Here, fields are selected and operated by virtual “mouse clicks”. This mouse click takes place at a predetermined position on the screen. The problem is obvious: If the field to be operated moves, the bot can no longer process it or, in the worst case, selects another field.5

5Another

division, which is not considered further here, distinguishes five options for “programming” an RPA bot (see Appliedai.com 2019): 1. Programming by code

16

2  Robotic Process Automation—Background and Introduction

Fig. 2.3   Access of RPA and BPM to individual “layers” (following Lacity and Willcocks 2016, p. 24)

u

Generally the following applies: The individual access options to the applications to be automated must be checked together with the manufacturer or an RPA consultant before deciding on a specific RPA software.

Type of System Access of RPA Compared to Other Automation Solutions The special feature of RPA is that the systems to be automated do not recognise that they are operated by other software. They behave as if human were to operating them, make inputs, and enter commands. While other types of automation software interact directly with the business logic and database access layer, RPA normally uses only the user interface. This comparison is shown in Fig. 2.3. This is one of the most important advantages of RPA over other solutions. This “simplicity” leads to a high degree of flexibility and independence from specific requirements that a target application potentially needs for other automation solutions. Structure of RPA Solutions Basic structure of the software RPA software includes a component for setting up the actual process automation, that is “designing” the process flow for the RPA bot. This is usually done by means of a

2. Use of the graphical user interface 3. Recording of the recorded commands (“recording”) 4. “no-code solutions” in which no manual commands need to be given at all 5. Self-learning bots

2.2  RPA from a Technical Perspective

17

high degree of graphical support. Such design components of relevant RPA software consist of the following building blocks (see Murdoch 2018, Chapter “Robotic Process Automation Platforms”): • Process construction kit, in which process sequences can be displayed by means of “drag and drop”. These usually have the form of “flowcharts” known in process management, that is, graphically displayed and interconnected process steps. • Selection lists with a variety of predefined commands. In contrast to the use of programing languages, many of the commands required later are already available, such as opening and operating spreadsheets, executing mouse clicks, etc. • Recorder, with which the processes are recorded in their basic structure. For this purpose, the process is executed by a human while all steps are recorded. These provide the subsequent basic structure for further processing by the RPA developer. The relevant software may differ in design, but only slightly in basic functionalities. For example, in one software a logical OR-branch in the process flow is represented as a graphical object, in another it is captured in code form. The relevant commands and action steps are predefined in the common RPA software. Further Components and Features of the Software RPA software should have the following components and features (see Murdoch 2018, Chapter “Choosing the right RPA platform/tool”): Modularity Modularity here means dividing developed RPA artefacts into individual modules. These can be reused in different artefacts, that is, in different automated processes. In this way, the complexity of RPA implementation can be significantly reduced, especially over time, which also results in a corresponding increase in speed when developing new artefacts. String operations This allows texts to be searched by the RPA software for specific text passages and words. Variable management As a rule, an RPA bot can read in, (temporarily) store and insert data. This process of (intermediate) storage does not always work in the same way. For example, some manufacturers have the data temporarily stored in encrypted form. Conditions, Loops, etc. Some RPA software offers the possibility to integrate instructions such as conditions, loops, etc., in the form of programing—similar to conventional programing.

18

2  Robotic Process Automation—Background and Introduction

Fig. 2.4   Exemplary RPA architecture (based on Automation Anywhere 2018)

Safety and Error Handling Many providers guarantee high-security standards for their RPA software. As a rule, RPA software is designed in such a way that it has no (negative) impact on the existing IT landscape. RPA Architecture The component described above, in which the development of the RPA artifact takes place (see also Sect. 5.7) is referred to as “studio”, “creator”, “designer”, etc., depending on the software provider. In addition to this component in which the RPA developers work, the complete RPA architecture contains other components. On the one hand these are the actual bots, also known as “runners”, and on the other hand a central control unit, for example called, “control room” or “orchestrator”. The bots themselves execute the created RPA artefacts. They run through the operative processes and are thus the component that—metaphorically speaking—replaces the person executing the process. The more the bots are operated in parallel, the more important the central control unit becomes. This is the unit that controls all bots. To do this, the workload and performance are monitored, processes are distributed among the bots, and so on. Figure 2.4 illustrates an example of an RPA architecture using an example from the RPA software provider Automation Anywhere (https://www.automationanywhere.com/). Experience shows that the architectures of the providers are similar, even if the names of the components and individual details differ. It can be seen that all other components are controlled by the central control unit. The example shows only one “creator”. If several RPA developers are working on RPA artefacts, more units are required here. The same applies to the “runners”, that is, the actual bots. Depending on the requirements, there may be more or less units instead of four. Integration of the RPA Architecture into the Organisation-wide IT Infrastructure When talking about the technological background of RPA, one important part is often neglected: the integration of the RPA architecture into the overall IT infrastructure of the organisation. To ensure that RPA can be integrated into the existing IT infrastructure, a number of things need to be taken into account, which are explained in detail below (see also Ganu (2018) and Murdoch (2018)).

2.2  RPA from a Technical Perspective

19

Fig. 2.5  Exemplary RPA architecture depending on the respective environment (own representation based on Ganu (2018) and Automation Anywhere (2018))

u

From the very first moment, the organisationʼs own specifications should be checked with regard to the integration of RPA into its own IT infrastructure.

RPA and Various Types of Infrastructure Many modern RPA software is infrastructure independent. They can be installed on desktop environments, but they can also be installed and operated server-based. Even virtual infrastructures—in private or public cloud environments—can be used with RPA without any problems. An observable trend in the financial sector is moving toward the use of virtual environments and in some cases even cloud solutions. If RPA is installed on virtual servers, a comprehensive examination of the access options to the applications to be operated is always necessary, as (solvable) difficulties can always arise here. Structure of Different Environments Ideally, financial organisations have three types of infrastructure (operated in parallel), called environments: A development environment, a test environment, and a production environment on which the live operation is carried out. In the context of RPA implementation, it makes sense to use all three environments. In this case, the following applies: Artifact development takes place in the development environment. The RPA artefacts are tested in the test environment and the RPA bots are then operated in the production environment. Correspondingly, all three environments require different combinations of the bots shown in Fig. 2.4. Figure 2.5 illustrates the different combinations. A central control unit is not always necessary in the development phase.6 Instead of this, corresponding units for artifact development are required (here “creator”). At least one bot (“runner”) is suitable for the

6Depending

on the software, this may also be necessary during development.

20

2  Robotic Process Automation—Background and Introduction

execution of developer tests. In the test environment, the central control unit controls the runners for the first time in test process execution. The creator is no longer used here. The production environment is similar to the test environment, but here more runners usually work in parallel. As always, adjustments to the RPA artefacts, which are comparable to adjustments to other programs, only take place in the development environment and then follow the path defined within the organisation; from the development environment to the test environment, and then into the production environment. Special Feature: Citrix When we speak of “Citrix”, we usually mean the centralised hosting and operation of applications that are made available to the individual clients as a kind of “image stream”. These applications can then be accessed from anywhere via the client. This is merely a kind of graphical replication of the applications. Figuratively speaking: the user controls the centralized applications and monitors them remotely—on his desktop or mobile device. If RPA is to be used here, installing the software on one of the clients will only help to a very limited extent. The only option is then to use coordinate-based automation— that is screen scraping—which, however, has the disadvantages described above. Optical character recognition components can be used to make text, which in this case is actually only available as an image, usable and analysable (see also Murdoch 2018, Chapter “Robotic Process Automation Platforms”). The software providers are now supplying solutions that are on the one hand directly integrated into the RPA software and on the other hand are intended to deliver the best possible results in automation under Citrix. However, promises in the form of high success rates in automation must be examined carefully. u

The ideal way is to install the RPA software centrally, where the other applications are hosted.

2.3 Cost Reduction, Quality Improvement, Time Saving, and More—The Diverse Potentials of RPA The potential benefits and advantages of RPA are numerous. Advertisements promise massive cost savings and quality gains. The temptation is immense to start a quick potential assessment trial and to implement RPA immediately in your own organisation. First, however, it is advisable to examine the promised potentials in detail, quantify them as far as possible and question them critically. The following section distinguishes four categories of potential from RPA: cost savings, quality improvements, time savings, and the other potentials that can often be derived from the first three.

2.3  Cost Reduction, Quality Improvement, Time Saving …

21

Overview of the Three Overarching Potentials of RPA Cost saving The main argument for any process optimisation and standardisation is the reduction of process costs. The next step after streamlining and standardisation of a process is its automation. This can often reduce (additional) employee capacities and replace them with (lower) costs of automation. Automation on the basis of BPM promises savings of up to 20% (see Schaffry 2009). Process optimisation is effective when the process remains within the organisation. An alternative is to outsource the process, for example, to an external service provider. This approach is known as business process outsourcing (BPO). The approach promises comparative cost savings in the range of 15–30% (see Tucci 2015). If the process remains within the organisation and is automated by means of RPA, the abovementioned cost saving potentials sometimes increase many times over. Table 2.2 provides an overview of various data and estimates of potential cost savings. The savings potentials are usually given in %-values. The reference basis varies, usually these are the process costs before automation or equivalent costs, for example, for outsourcing the process. Occasionally, potential is also shown in the form of savings in employee capacity (MAK) or full-time equivalents (FTE). This is also converted here into %-values (a reduction from ten FTE, who are involved in the execution of a process in full time, to five FTE, thus corresponds to a saving of 50%). Table 2.2 deliberately uses the term “savings potentials” instead of “cost savings potentials”. This is because automation by RPA does not mean that the staff previously involved in process execution are released and no costs are incurred for them. Rather, the purpose of RPA is to free them from repetitive, time-consuming processes so that more capacity is then available for value-adding activities.7 In the procedure described above and when reading the Table 2.2 caution is required. A cost saving can only refer to the FTE saved. In this case it is comparable to the percentage of FTE saved. If it also includes other costs (e.g., costs of RPA governance, see Chap. 6), this must be taken into account for comparability. Often the concrete reference and comparison values of the saving potentials are missing, so that all values listed here should only be used with caution for the estimation of saving potentials. The pure savings potentials from the use of RPA in processes are offset by the following efforts: Licence costs for the RPA software, initial costs for process automation and ongoing operating costs (see also Sect. 5.3). With regard to the reference value for the comparison, the savings potential can refer to the previous process costs before automation, total costs can be apportioned to these, savings potentials of comparable technologies can be used as a reference basis, etc.

7Nevertheless, participants in the study conducted by Ostrowicz (2018, p. 24) expect a long-term reduction of 18% of FTE by RPA (time horizon 10 years).

22

2  Robotic Process Automation—Background and Introduction

Table 2.2  Overview of data and estimates of cost savings Savings through RPA

Source

Explanation/Comment

Approx. 70%

Willcocks et al. (2017, p. 25)

Optimisation and automation of a process in the field of management of insurance contracts

66%

Willcocks et al. (2017, p. 22)

Basic estimate that one RPA FTE will replace about three human FTE

Up to 65%

Willcocks and Lacity (2016, pp. 49–50)

15–30% additional cost savings compared to offshoring. This represents up to 65% cost savings compared to onshore FTE (based on Everest Group results)

40–75%

Tucci (2015) and ComMagazine (2019)

No concrete case study, internal company KPMG experience

20–60%

Com-Magazine (2019)

Reference to EYʼs internal company experience Study results (n = 178)

25%

Ostrowicz (2018, p. 22)

25%

Watson and Wright (2017, FTE reduction through automation of 50 p. 8) accounting and reporting processes

At least 66%

Lacity and Willcocks (2016, p. 31)

Telefónica O2 case study. Only processes are automated that correspond to at least a full-time equivalent of three employees, which is the percentage on the left

32–43%

Otto and Longo (2017)

Reduction of FTE by an average of 43% in ordering processes and 32% in personnel processes

20–90%

Estimate the interviewed experts

Cost savings in %, related to the previous process costs. The large range of estimates is striking here. This shows how different the estimates and own experiences are at this point

Approximately 30%

Own project experiences

Within the scope of data migrations by RPA (see also Sect. 8.2)

40–90%

Own project experiences

RPA in its proven form—as an automation tool for repetitive processes

In principle, the following applies: As the volume of RPA use increases, that is, with an increasing number of automated processes, the costs for RPA control, operation, etc. also increase. At the same time, the effort required for implementing new automation is reduced and experience curve effects can be generated. As a result, the percentage of cost savings achieved by the use of one RPA process can vary depending on the extent to which the technology is used throughout the organisation—both upward and downward.

2.3  Cost Reduction, Quality Improvement, Time Saving …

u

23

A realistic value to be determined on the basis of Table 2.2 is a (cost) savings potential of 25% on average by RPA for the corresponding processes. This relatively low value is also in line with most of the estimates of the experts surveyed.

Not only the absolute cost saving potentials are relevant. The time frame for their realisation also requires further consideration. Whether the investment costs in a new technology or the automation of a process pay for themselves after a few months or after many years, usually has a great influence on the corresponding investment decision. The payback period, that is, the time in which the invested capital “flows back” in the form of savings due to lower process costs of the bots (or is ultimately returned in full) is usually very short for RPA. According to Watson and Wright (2017, p. 4), the payback period is around 11.5 months, taking all relevant costs into account. u

As a result, RPA automation is usually profitable within the first year of operation after its implementation.

Quality Improvement In addition to cost reduction, automation with RPA offers further potential benefits. One is the possibility of quality improvements in process handling. Human process handling, especially with frequent, repetitive activities, is prone to errors. Process execution by bots, on the other hand, is not—as long as they are correctly configured and the RPA artefacts are correctly developed. Unsystematic errors—that is errors caused by human error—are excluded by RPA. Systematic errors, on the other hand, are not, which poses a risk that should not be neglected. Faulty programming that goes unnoticed until the RPA rollout can quickly lead to large volumes of faulty process results. u

Practical experience has shown that the risk of systematic errors is assessed as particularly serious by the decision makers. It is therefore all the more important to exclude this type of error as far as possible by means of extensive preparatory work and appropriate tests (see Sects. 5.6 and 5.8).

In particular, use cases such as the recording of turnover data, securities buy and sell orders, and the like have a zero error tolerance. Here, RPA can have a positive influence on the quality of processes and results. Time Saving The potential time savings through RPA are closely linked to the cost reduction. The two are often mutually dependent. If the process handling time is reduced, the process costs are also usually reduced due to the lower tied capacities and (IT) resources. Nevertheless, time savings can also be an advantage in itself. Especially in processes in which the (external) customer is directly or indirectly involved, an increase in speed

24

2  Robotic Process Automation—Background and Introduction

can generate competitive advantages and increase customer satisfaction. This not only applies to external customers, that is, customers of the organisation in the true sense. But it also applies to the internal areas involved in or triggering processes as customers, and recipients of the services of another area. They also expect high process speed. In this case, RPA makes a significant contribution to increasing the speed of the process. The possibility of saving time means that, for example, “service level agreements” (SLAs) can be met by using RPA. Thus, the IRPA (2016) presented a case study in which an 82% RPA-related time saving enabled full compliance with the relevant SLA. Speed of the RPA Bot Before starting an RPA implementation, it is often asked how fast the bot will execute the process in the end. Its speed depends on factors that can only be partially influenced: process adjustments and optimisations can generate speed advantages for the bot. A reasonable configuration of the RPA artefacts is equally important. Nevertheless, the bots are completely dependent on the speed (including the “IT response times”) of the applications they serve. If they react slowly, which is often the case with web applications, for example, the bot can only work slowly, too. Load-related performance weaknesses of applications and systems can also lead to delays that affect the bot, for example, at peak times when many users are working. Example

The customers of a bank can change their account model online. To do this, they enter an order in an input mask within their online banking. Previously, the orders generated from this were processed manually in the bankʼs back office. Since all the necessary data has already been entered by the customer, it is available in a digital format (see Sect. 5.3 on RPA process selection criteria), and the processing does not necessarily have to be done manually. The use of RPA will enable immediate automated processing of the customer order in the future. In addition to cost savings and an increase in quality, the processing time in particular is reduced from several days to a few minutes. The customer will receive an automated confirmation of the successful implementation of his order by email within a very short time after placing the order. As a result, the customerʼs perception of the increase in benefits is very positive, and this is a competitive advantage for the bank. ◄ Further Potentials Reduction of compliance and operational risks In addition to the three benefits mentioned above, the use of RPA has other positive effects that can be traced back to these benefits. One is the possibility of reducing compliance risks. When a financial services company deals with RPA for the first time, often concerns are expressed, especially with regard to the generation of possible compliance

2.3  Cost Reduction, Quality Improvement, Time Saving …

25

risks: Access rights of the bots, possible unintentional circumvention of (regulatory) internal process controls and a few more. All of these concerns can be addressed appropriately, as will be shown below. Moreover, instead of generating compliance risks, RPA often helps to eliminate them. Once a RPA artifact has been developed in compliance with the companies requirements and protected against changes, it cannot be changed unintentionally or unnoticed. Misuse is thus significantly restricted. In addition, every step and every system input by the bot is documented (usually both within the target applications and in RPAʼs own documentation) and can thus be fully verified by third parties (see Lacity and Willcockʼs 2016, p. 30). The same applies to operational risks, that is, those that lie outside the actual business activity. These include human errors, system errors, or errors within internal processes. Operational risks are a significant risk category, particularly in the financial sector. The significant increase in process quality when using RPA reduces these operational risks. In the long term, this may even be reflected in a reduced regulatory capital requirement. Reduction of Time-to-Market RPA can drastically reduce time-to-market. While the market demands increasing flexibility and speed in all actions, adapting existing processes to new requirements often takes a relatively long time. Here, RPA can provide fast solutions for adapting processes to new conditions. For new processes, RPA is rarely the first choice. Here, the path of direct automation should be attempted as part of an application development or the initial definition of the process workflow. But especially the application development can cost time. In this respect, RPA itself can offer an opportunity to drastically reduce time-tomarket. Therefore, each individual case must be examined and evaluated. Relief of the IT Department RPA can provide relief for IT. Process adjustments done by IT often have a low priority—as long as they involve process optimisations and thus “optional adjustments” instead of implementing “mandatory adjustments”. This can further increase the time it takes for a process adjustment to be implemented. Here, too, RPA offers an alternative in which the IT only has to provide the infrastructure for the software solution. As already explained above, the following also applies in terms of security and compliance: RPA uses already existing, configured applications and processes. No additional effort is required for this. It is ensured that all testing and security precautions are complied with. Collection of Information and Data RPA has the potential to generate significantly more information from existing processes than would be possible without the use of technology. Thus, Watson and Wright quote (2017, p. 6) the employee of a major Swiss bank that uses RPA with this objective. The early collection of data creates the basis for a possible later use of cognitive and selflearning systems.

26

2  Robotic Process Automation—Background and Introduction

Increase in Productivity When we speak of productivity gains, we mean first of all the creation of more output per unit of input invested. This can be achieved in various ways. In particular, more efficient processes can lead to such an increase in productivity. More efficient processes can in turn be achieved through optimisation and automation and thus also through RPA (see also Willcocks and Lacity 2016, p. 50). Customer Satisfaction Many of the benefits mentioned above ultimately also increase customer satisfaction. Especially a possible time reduction supports this. Willcocks and Lacity (2016, p. 50), therefore, list customer satisfaction as a separate and relevant potential benefit of RPA. Expectations of RPA: A Comparison of Goals and Actual Results Watson and Wright (2017, p. 11) asked the participants in their study whether their different expectations of RPA were met, exceeded, or not met. In particular with regard to improved compliance followed by improved quality, expectations were often exceeded, but in almost all cases they were at least met. In 86% of the cases, RPA led to the expected productivity improvement or even exceeded expectations. The situation is different for cost savings. Although in slightly more than 60% of the time the expectations were met or exceeded, in almost 40% RPA fell short of expectations for cost savings. Whether the reason for this is the too high implementation or operating costs, or whether the initial expectations at this particular point were simply too high, remains unanswered. Conspicuous: In more than 60% of the time, the implementation speed of RPA falls short of expectations. This could be an indicator that RPA is still too often touted as a “quick fix” and that it needs the course of implementation to realise that many things have to be prepared for a successful RPA implementation. Like this implicit question, other questions derived from the study results remain unanswered and offer starting points for further scientific investigations. Important: The present book takes up the preparatory measures, as a basis for an efficient RPA introduction, in the further course. Automation Potential A typical question of future RPA users is how great the automation potential of RPA is. This question must be considered in a differentiated way. First, the automation potential in this context can refer to the potential per process. Here the question must be put in concrete terms: What is the percentage of a process (its steps) that can be automated with RPA? Or: What is the success rate of process automation—how many process runs could actually be automated? The third possible explanation is the share of automatable processes in the total number of all existing processes. Here the correct question is: What is the share of all automatable processes (in percent)? It is not possible to answer the first question in general. It is basically dependent on the individual “process map” and also on the “application map” of the respective organisation. If most processes take place within a single system, the potential for automation

2.3  Cost Reduction, Quality Improvement, Time Saving …

27

with an RPA tends to be lower for these processes than if they take place predominantly across different systems. This is because automation within an application is usually easier to implement through appropriate technical development work than through automation with RPA, that is, via the user interface.8 If, on the other hand, the process takes place across systems, it tends to have much more potential for the use of RPA. The second question can be answered quantitatively. The results of automation can usually always be evaluated in a decisive way, for example, by the number of successful process runs. From this, an automation potential for similar processes can be derived. The third question relates to the total number of processes within the organisation. It aims at the share of automatable processes in the total number of all processes. A distinction must be made here as to whether an automatable process is only partially or fully automated. Partial automation can also be considered. In relevant literature or studies, these questions are not always differentiated (see for example, Ostrowicz 2018). However, this blurring is not critical here. Ultimately, at least the results of the first and third question lead to a similar overall statement, provided that the first question is asked for each process and the results are compiled from it. In the following, the second question will be focused and answered first: What are the success rates of process automation with RPA? Willcocks et al. (2017, p. 23) cite success rates of up to 93%. The target value set in advance for this was 80%. Almato (2019) speak of an automation rate of up to 97%. Other empirical values from RPA projects also show that automation rates of more than 80% can be achieved without problems. However, a quota of 100% is usually not achievable. In the course of time, constellations arise again and again that make it necessary to deviate from the completely rule-based process flow. These can be foreseeable—for example, special cases—or can be unexpected exceptions. The latter makes human intervention necessary. The rate also depends on the complexity of the process and on the time or resource available for automation. u

As a rule of thumb, the more complex the process, the more effort (i.e., more time with the same resource or more resources within the same time) is required to increase the automation rate (see also Sect. 5.7).

The third possible reference value mentioned above is the share of automatable processes in the total number of all existing processes—i.e. the share of automatable processes in the entire “process pool” of the organisation. This process pool can be further subdivided into the processes of individual organisational areas or—in the case of a

8Of

course, this only applies if the respective organisation can intervene in all participating applications or their program codes. This is often difficult in the case of centralised applications provided for several institutes. In this case, process automation with RPA within an application can also be useful. Good examples are list processing, for example, overdraft lists, which are processed according to specified criteria.

28

2  Robotic Process Automation—Background and Introduction

more process-oriented organisational structure and workflow—into (cross-divisional) process groups. Here, too, the following applies: Concrete statements must always be made dependent on the individual conditions. However, rough conclusions can still be drawn for specific process areas. For example, the areas relevant to the financial sector— reporting, registration, finance, controlling, and also IT—offer, according to the study participants in Ostrowicz (2018, p. 12), particularly high-automation potential (see also Sect. 3.1). Willcocks and Lacity (2016, p. 49) emphasize an automation rate of 35% in the back-office areas of the companies using RPA—but this is across all industries. Experience has shown that this rate also applies to the back office areas of the financial sector, and depending on the focus of the instituteʼs activities and organisational structure, it could be even higher. Further potential for RPA results from the combination with other technologies, in particular with those described in Sect. 2.1. The study participants in Ostrowicz (2018, p. 23) assume an additional automation potential of 23% and 22% through the extension of RPA by cognitive automation solutions and the integration of digital assistants. Where Advantages can be Found, There are Also Disadvantages Although often beneficial, the use of RPA can also lead to major challenges or even disadvantages. Some challenges can be overcome relatively easily or are comparable to the challenges that arise in automation through “invasive” adaptation of the application (i.e., (re)programing of the application itself). Others are not. Bots must be installed, updated, and controlled. Errors and sudden system crashes must be adequately managed. Resources must be planned and provided for this purpose, often in the form of employees from the IT or organisational areas. Especially when automating several applications and many processes, many adjustments or at least checks of the automated processes may become necessary during the year. For example, releases of the core banking systems, office applications, or CRM systems may result in the need to adapt the automated process. Even if many people claim otherwise: In contrast to the use of interfaces, RPA is generally the more unstable solution. Interfaces are used for complete system integration. In contrast to RPA, the graphical user interface plays no role here. The latter is usually more unstable or “volatile” than a “real” interface. If there is a choice between the same alternatives (effort and implementation time) and no other factors speak against it, automation via interface should probably be preferred to automation with RPA in most cases. Due to the above challenges, some authors describe RPA as a step backward on the way to a modern and agile IT landscape (see Rücker 2018). We do not share this radical perspective. u

RPA is neither a step backward nor the only way to a modern and agile IT landscape. RPA is rather a tool which—if used skilfully and in the right places—brings agility and the ability to change processes quickly and thus complements a modern IT landscape.

2.3  Cost Reduction, Quality Improvement, Time Saving …

29

Time and again, we hear that RPA would tempt decision makers to forego extensive modernisation of their legacy systems and seek the supposedly easier solution via RPA (see also e.g., Freund 2019). This argument is not unfounded in parts. RPA must not be used as a substitute for necessary renewals of the underlying applications and systems. This is where it is again helpful to look at RPA as a technology that acts like a human being via the user interface and is fully dependent on the automated applications in all areas—especially the “capabilities” and also response/runtimes. As a result, RPA is by no means a substitute for continuously updating oneʼs own systems and applications. However, as explained above, RPA can provide valuable support in improving time-tomarket, quickly adapting processes where the market and customer demand it, and in many other areas. Obstacles to RPA implementation Otto and Longo (2017) examine, among other things, obstacles to RPA implementations. The most important of these are (see here Lüth 2018): 1. Security concerns (54%) 2. Obstacles in the area of governance, risk and compliance (35%) 3. Organisational resistance (33%) 4. Lack of support from the management level (30%) Chapter 7 takes up these and other obstacles, discusses them in detail once again and shows how they can be turned into success factors through appropriate measures. Strategic Decisions Before Implementing RPA and During the Use of It Despite all benefits of RPA, there are a number of key decisions and principles that management needs to make before the final decision on the use of RPA is made. These decisions are made at a strategic level. It is necessary to determine what specific objectives are to be achieved through the use of RPA. Such strategic decisions are not always taken before implementation begins. Time and again, it can be observed that RPA is implemented and processes are automated before the question concerning the goals of the use of RPA—at the overall organisational level—is answered. It can be guessed that this is not the most efficient way. A practical way to support the definition of the strategic objective of implementing RPA is to focus on one or more benefits of RPA. For example, it may be a strategic objective to save as many costs as possible through RPA or to achieve the greatest possible relief for employees. In other organisations, on the other hand, the focus is on reducing time in order to be able to respond more quickly to requests from internal or external customers. Others place quality objectives at the heart of their RPA-related strategic orientation or use RPA to establish extended control routines, for example, to comply with compliance requirements. If one of the latter objectives is pursued, this results in a different approach to the evaluation of RPA in general and the selection of processes

30

2  Robotic Process Automation—Background and Introduction

in particular. For example, overall RPA-related or process-specific business cases can be quite negative if the focus is not placed on the potential cost savings. Even during ongoing RPA operations—that is when RPA has already been implemented—it is worthwhile continuously reviewing and possibly realigning the strategic goals and priorities set. Watson and Wright (2017, p. 6) asked the participants in their study about their current strategic priorities regarding the use of RPA. Thirty-five percent of the participants focus on the continuous improvement of their own RPA operation. Twenty-four percent set themselves the goal of increasing the level of automation in their own organisation. As many as 8% want to improve their own RPA governance.9

2.4 RPA in the Context of Process Management RPA is one of the technologies that promise to quickly raise cost saving potentials and generate further benefits. As a result, automation with RPA is often implemented all too quickly and without first creating the appropriate framing conditions. Framing conditions can be, in particular, the prior differentiated process selection, a process optimisation, or a permanent process controlling following the automation. Section 5.6 will deal explicitly with the process management steps required for successful automation. Nevertheless, a classification of RPA in the context of process management should be made at this point. In particular, questions arise as to which process management functions RPA comes into contact with, how an established process management system can support the introduction of RPA, and to what extent RPA is a comprehensive tool (whether it is an always applicable automation approach or just one instrument among many others in process management). Results of the Expert Interviews The expert interviews conducted confirm the assumption that the explicit classification of RPA in the context of process management is useful and necessary for a successful implementation of the technology. André Meyer, Business Analyst/S-Servicepartner Germany GmbH, sees in RPA a suitable tool for a more industrial orientation of the own process management. Thanks to the possibility of RPA automation, process management is more strongly oriented toward industrial approaches that rely on a particularly high level of standardisation, for example, in process design. If financial service providers also use such an approach, this increases the subsequent automation of processes. According to the expertsʼ assessment, RPA can help to move away from a more documentary approach to proactive process management. RPA supports this process with the accompanying requirement to explicitly analyse processes for their automation capability and, if necessary, to adapt them accordingly. Another opinion is that process management in the financial industry often is too abstract to deal in detail with a operationally oriented technology such as RPA. For this reason, RPA can only

9See

also Chap. 6 on RPA governance.

2.4  RPA in the Context of Process Management

31

be driven by the business departments or IT in the sense of a “bottom-up approach”, whereas process management at the overall organisational level creates the overarching framework conditions.

Definition of BPM and Classification of RPA in the Concept Since the beginnings of thinking in terms of “value chains” and processes, shaped among others by the work of Michael E. Porter (“competitive advantage”) and Peter Drucker in the USA, process management has served to optimise organisations in terms of efficiency and quality. Initially developed and applied in the manufacturing industry and made known as a pioneer especially by the automotive industry, service companies successively adopted the management methods for recording and describing, analysing and optimizing processes, and establishing process-related responsibilities—(BPM). Especially by striving for higher quality (“zero-defect tolerance”) in the course of processes, many tools for the analysis and optimisation of processes, methods such as continuous improvement (CIP) or, in general, total quality management have been developed. In the further development, the efficiency of the processes moved more into the focus of consideration, which manifested itself, for example, in the methods of lean management. For service companies in general and the financial industry in particular, with a lot of technology within its processes, the automation of individual process steps or entire (sub)processes is a particular focus of process optimisation. The core task of BPM in many organisations is therefore—in addition to anchoring process-oriented thinking and establishing process-oriented responsibilities in the company—also the permanent search for optimisation and especially automation possibilities of processes. This is where RPA can play an important role, alongside the successive process automation in the banking systems themselves. The importance of BPM for the use of RPA is twofold: • On the one hand, efficient processes are also a prerequisite for resource-saving use when using RPA, and only then do they enable the hoped-for savings that are associated with many automation projects. • On the other hand, many processes can only be automated with RPA if they are analysed, structured, and simplified in the run-up to the introduction of RPA and thus made capable of automated processing by the robots to a high degree. The optimisation of the processes themselves with the methods of BPM, for example, by eliminating unnecessary process steps and loops contained in many processes, simplifying processing steps and reducing control procedures to a necessary minimum, is the basis for efficient processes before and after automation with RPA. In other words: “If a poor process is automated, a poorly automated process is created”. It has already been shown that the use of bots also results in processing times for the processes (among other things, due to the minimal acquisition times and the subsequent response waiting times

32

2  Robotic Process Automation—Background and Introduction

in automated data processing of systems), which ties up the capacity of the bots and is reflected in process costs. The necessary use of the IT infrastructure itself may also generate costs—it therefore makes sense to keep the processing times of processes as short as possible even when using RPA. In many cases, the recording, analysis and optimisation of processes are also a necessary prerequisite for the (meaningful) implementation of automation with robots. Robots handle processes as a sequence of individual instructions—their processing algorithm. If this sequence cannot be recognised before the processes are optimised, or—as is often the case—a large number of process exceptions that would require human intervention are defined at the beginning of the analysis, automation cannot be implemented in a meaningful way. In fact, however, many of these processes, which at first glance appear to be “complex”, can be modified and optimised using the classic methods of BPM in such a way that high automation rates can be achieved. This proves the high importance of process management in the context of automation with RPA. In fact, the intensive use of BPM also results in a “contradiction” to the use of RPA: The better the processes of a (financial) service provider are optimised for efficiency and high-processing quality, the better these processes can be automated by mapping the processes in the underlying systems accordingly. For example, many banks have succeeded in achieving a high-automation rate or “straight-through” rate in the processing of payment transactions by means of appropriate process optimisation procedures. The stringent application of process management creates the basis for these optimisation successes. In these cases, the use of RPA is then little or not necessary. Results of the Expert Interviews Dr. Sandro Schurig [Head of Business Services at DekaBank]: If BPM were to be applied stringently, the use of RPA might no longer be necessary. RPA always makes sense if automation in existing systems is not possible or too costly.

As desirable as the complete automation of optimised, efficient process flows in the systems is, daily experience shows that the possibilities for implementing IT changes are limited for many service providers, whether due to limited (IT) resources, complex IT measures that can only be implemented in older systems at great expense, or due to the use of standard software without direct change options of their own. The (supplementary) use of RPA, as an optimisation instrument in the process managerʼs tool set, is therefore a sensible alternative in many use cases.

2.5 RPA in the Context of (Process) Digitisation Digitisation creates major challenges for the financial sector. Customers demand digital information exchange, digital communication, and digital product deals. Banks and financial service providers are, therefore, required to provide their products and services

2.5  RPA in the Context of (Process) Digitisation

33

digitally, that is, to transform them—the so-called “digital transformation”. This often lacks an actual transformation. Rather, business processes that have been tried and tested in the field are reproduced digitally. This regularly leads to unclear and inefficient processes. These are often only partially digitalised and are provided with media breaks. An actual end-to-end digitisation is missing. Example

An insurance company enables its customers to take out a liability insurance policy online—fully digital. For this purpose, it places advertisements on its own homepage. A direct link to the product offer is missing in the advertisement. Instead, it refers to the menu item to be selected. Once there, customers will find a wide variety of insurance packages, some with modular components that can be selected. Once the customers have made their decision, they enter their own data in an online mask and finally receive a confirmation that the data has been saved and forwarded. This data is now initially stored temporarily until a clerk in the back office of the insurance company retrieves and prints it—after information by e-mail. With the help of the printout, he records the data in various systems. If individual data do not match, he creates a letter to the respective customer to request the remaining data or data that needs to be corrected. If he receives the data in a few days to weeks later, he creates the insurance policy in the system and sends all documents to the new customers. ◄ The example shows the weak points of this digitisation attempt. The process is not planned from the customerʼs point of view, otherwise a direct jump to product completion would be possible. The variety of possible product variations makes it almost impossible to close a deal without prior comprehensive consultation—an example of digitizing a stationary process without redesigning and adapting it accordingly—in other words, actually transforming it. The subsequent steps and in particular the printing and recapture of data show the break between digital and no longer digital process flow. There is no end-to-end digitisation. However, a “real” digitisation of the process would be possible with some adjustments, as the following continuation of the example shows. Example

The insurance company first revises the process by redesigning it from the customerʼs point of view and eliminating obstacles and detours. The online product offering is reduced significantly after analyses show that more than 80% of customers who take out policies online choose a certain basic variant of liability insurance. All other combinations are chosen only very rarely. In future, only two basic variants can be taken out online. For more specific variants, in future there will again be stationary (or even media) advice from consultants. Once customers have entered their data online, these could ideally be transferred directly into the legal database of all the necessary

34

2  Robotic Process Automation—Background and Introduction

systems. However, this would require an enormous amount of IT implementation work, as new interfaces would have to be developed, provided and maintained. RPA offers an alternative. In the future, a bot will take over the data entered by the customer and transfer it to all necessary systems—without paper printouts, without errors, and much faster than before. Instead of letters to the customers, emails are sent. Since the entry mask for customers was previously optimised and now contains mandatory fields and plausibility checks, the number of queries is reduced to a minimum. Only the final dispatch of the insurance policy is still done by a dispatch service provider. ◄ The example shows how an end-to-end digitisation and thus digital (partial) transformation can be achieved with few changes. RPA enables an enormous reduction of effort compared to large IT-technical changes. The adaptations can be implemented much faster so that a fast time-to-market is ensured.

References Allweyer T (2016) Robotic process automation—new perspectives for process automation. Department of computer science and microsystems engineering at the University of Kaiserslautern. https://www.kurze-prozesse.de/blog/wp-content/uploads/2016/11/NeuePerspektiven-durch-Robotic-Process-Automation.pdf. Accessed: 27. Dec. 2018 Almato (2019) Robotic process automation. https://almato.de/loesungen/robotic-process-automation-rpa/. Accessed: 9. Jan. 2019 Appliedai.com (2017) Robotic process automation comprehensive guide. https://blog.aimultiple. com/rpa-whitepaper/. Accessed 17. Nov. 2018 Appliedai.com (2018) Guide to cognitive automation, RPA’s future (2018 update). https://blog. aimultiple.com/cognitive-automation/. Accessed: 30. Dec. 2018 Appliedai.com (2019) RPA tools. https://blog.aimultiple.com/rpa-tools/#types. Accessed: 17. Febr. 2019 Automation Anywhere (2018) Enterprise architecture for the intelligent digital workforce. https:// www.automationanywhere.com/images/Enterprise-Architecture.pdf. Accessed: 17. Febr. 2019 Com-Magazine (2019) AI in robotic process automation. https://www.com-magazin.de/praxis/ business-it/ki-in-robotic-process-automation-rpa-1666853.html?page=2_vorteile-durch-bots. Accessed: 12. Jan. 2019 Freund J (2019) Plain text: “RPA is increasingly turning into a sweet poison”—Why RPA hinders transformation. https://www.it-finanzmagazin.de/klartext-rpa-gift-transformation-85578/. Accessed: 21. Febr. 2019 Ganu N (2018) Infrastructure setup for RPA. https://www.linkedin.com/pulse/infrastructure-setuprpa-nainesh-ganu/. Accessed: 17. Febr. 2019 IRPA (2016) RPA transforms business processes—Through faster and more accurate services and higher customer satisfaction. https://almato.de/fileadmin/files/downloads/DE_NICE_IRPA_ WP_RPA_is_Transforming_Business_Processes-2016.pdf. Accessed: 9. Jan. 2019 Lacity M, Willcocks L (2016) Robotic Process Automation at Telefónica O2. MIS Q Exec 15(1):21–35

References

35

Lüth A (2018) RPA market to grow strongly by 2020. https://www.bigdata-insider.de/rpa-marktsoll-bis-2020-kraeftig-zulegen-a-728203/. Accessed: 20. Jan. 2019 Magazin M (2019) Robotic Desktop Automation is the digital boost in customer communication. Manager Magazine, Manager Knowledge 1:2 Murdoch R (2018) Robotic process automation. Guide to building software robots, automate repetitive tasks & become an RPA consultant. Own publishing house Ostrowicz S (2018) Next generation process automation: integrated process automation in the age of digitalization. Report on the results of the 2018 study by Horváth & Partners, Frankfurt a. M. Otto S, Longo M (2017) ISG study: Robotic Process Automation (RPA) ensures greater productivity and not job losses. https://www.isg-one.com/docs/default-source/default-document-library/ isg-automation-index-de_final_form.pdf?sfvrsn=15defe31_0. Accessed: 20. Jan. 2019 Rücker B (2018) How to benefit from robotic process automation (RPA). https://blog.berndruecker.com/how-to-benefit-from-robotic-process-automation-rpa-9edc04430afa. Accessed: 18. Jan. 2019 Schaffry A (2009) BPM reduces process costs by 20 percent https://www.cio.de/a/bpm-reduziertprozesskosten-um-20-prozent,877610. Accessed: 30. Dec. 2018 Tucci L (2015) KPMG: death of BPO at the hands of RPA. https://searchcio.techtarget.com/blog/ TotalCIO/KPMG-Death-of-BPO-at-the-hands-of-RPA. Accessed: 30. Dec. 2018 Van der Aalst WMP, Bichler M, Heinzl A (2018) Robotic process automation. Bus Inf Sys Eng 60(4):269–272. https://doi.org/10.1007/s12599-018-0542-4 Watson J, Wright D (2017) The robots are ready. Are you? https://www.google.com/url?sa=t&rc t=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEwjizofA5MnfAhURYlAKHWHaBqoQ FjAAegQIChAC&url=https%3A%2F%2Fwww2.deloitte.com%2Fcontent%2Fdam%2FDeloitt e%2Ftr%2FDocuments%2Ftechnology%2Fdeloitte-robots-are-ready.pdf&usg=AOvVaw2luiVI NhzNclPK70Ac7_zc. Accessed: 31. Dec. 2018 Willcocks L, Lacity M (2016) Service automation. Robots and the future of work. Steve Brooks Publishing, Warwickshire Willcocks L, Lacity M, Craig A (2017) Robotic process automation: strategic transformation lever for global business services? J Inf Technol Teach Cases 7:17–28

3

Application Areas of RPA

Abstract

The chapter first provides an overview of industries, companies and individual company divisions that potentially have a sufficient number of processes that can be automated. One focus is on the industry-specific areas of financial organisations. In a further step, technical selection criteria for processes suitable for RPA are established and explained. The extension to business criteria—and the creation of processrelated business cases—follows in Sect. 5.3. The chapter concludes with a selection of proven RPA processes in the financial sector.

3.1 Suitable Industries, Companies and Business Sectors Cross-Sector RPA is a technology that can be used across sectors and industries. Its application focus is on the services sector. This is also confirmed by a review of published case studies, many of which come from the telecommunications, financial, healthcare and logistics sectors (see for example Lacity and Willcocks 2016, p. 34; Wadlow 2017, pp. 8–9; Hermann et al. 2018; Aimultiple 2019). Automation is also used in industry (and has been for years), but automation here means, for example, the construction of production lines equipped with robots. Of course, digitalized processes in such industries, which work with different applications, can also be automated by RPA. Examples are the controlling, personnel and IT departments of companies, but also all areas that interact with customers and perform the familiar repetitive activities.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 M. Smeets et al., Robotic Process Automation (RPA) in the Financial Sector, https://doi.org/10.1007/978-3-658-32974-7_3

37

38

3  Application Areas of RPA

Across industries, the following business areas are particularly suitable for RPAs (see Ostrowicz 2018, p. 12): • Accounting • Reporting • Logistics • IT • Customer service • Controlling • HR Industry Focus on the Financial Sector The focus of this book is on the financial sector. In this respect, the next step is to define the business areas within banks and insurers for which automation with RPA is suitable. A study conducted by PWC 2017 (see PWC 2017) serves as starting point. The study participants identified areas in which the potential of RPA exceeds the costs of its introduction and process automation. According to the study, the highest potentials are offered by the back office areas, with well over 80% agreement; finance and IT follow. In the areas of compliance, legal, risk controlling and human resources, only minor potential for RPA is assumed (approx. 5% agreement). The same applies to sales. The latter is not surprising, as customer interaction usually requires human interaction—apart from the increasing use of chatbots and similar technologies. At this point, however, caution is needed. While direct customer interaction cannot—or only very rarely—be automated with RPA,1 the subsequent processes, which usually end in the back office, can very often be automated. This is also illustrated by the example in Sect. 2.5. The participants in a study conducted by Ostrowicz in 2017 also cited the back office as one of the main potential areas for RPA. In addition, risk management, accounting and human resources are listed as potential areas. A study by the Information Services Group (ISG) assumes that the IT sector will be the one most affected by automation in the coming years (see Otto and Longo 2017). As an overall assessment, the following areas in the financial industry are particularly suitable for automation: • Back Office • Finance, i.e. accounting • IT

1As

defined in Sect. 2.1, RPA does not have any artificial intelligence components in the understanding used here. Thus, the bot would lack the fixed rules and structures required for customer interaction. The Digital Assistants presented in Sect. 2.1 can provide a solution here.

3.1  Suitable Industries, Companies and Business Sectors

39

Additionally, there is also fundamental RPA potential in the following areas: • Compliance • Law • Risk or overall bank management • HR The typical sales areas, on the other hand, are less suitable for automation according to the understanding of RPA used here. Here, existing processes must first be subdivided into individual sub-processes, some of which can then be automated. In the sales area, the use of desktop RPA is also quite conceivable. However, this type of RPA was deliberately excluded from the analysis (see Sect. 2.1). A closer look at the areas listed above allows a quick conclusion to be drawn about the criteria of areas suitable for an automation with RPA. Wherever data is available in a digital format and is processed digitally, the use of RPA is a viable option. If the average degree of standardisation of a process area is now added as a criterion, it becomes clear why the process areas of the back office and accounting are particularly suitable for RPA. In these areas most of the processes are standardised, rule-based and based on digitalised data. Results of the Expert Interviews The surveyed experts agree that the focus areas for RPA in the financial industry are primarily in the back office and IT areas. Other areas still play a rather subordinate role here. Focus: RPA for Back Office Automation The back office area of the financial industry has already been taken into account for the use of RPA above. This area is typically facing massive cost pressure—also in the financial sector. If turnover can no longer be increased adequately, the only way to stabilise or grow earnings is often to cut or at least “freeze” costs. Willcocks and Lacity (2016, p. 45) describe five combined levers for changing low-performing back office areas to high-performing ones: 1. Centralisation of the back office areas and the associated budgets. 2. Cross-departmental standardisation of processes. 3. Process optimisation to reduce errors and minimise waste. 4. Relocation of back-office operations from expensive to less expensive locations (for example through “offshoring”). 5. Technological advances, such as self-service portals.

40

3  Application Areas of RPA

The possibility of process automation with RPA now adds a new, sixth lever: 6. RPA—the automation of relevant processes While the first five levers have already been used extensively in the last 15 years or so, RPA has only been added in recent years.

3.2 Technical Selection Criteria for Automatable Processes After defining the basic process areas, the next step is to select the right processes to be automated. At this point, the technical selection criteria of RPA processes will be discussed first. In Sect. 5.3, these criteria will be extended once again to include business management criteria. It also explains concrete procedures for process selection in the context of an RPA implementation project. The technical criteria relevant here evaluate the properties of the process flow. For example, they do not refer to the profitability of process automation—unlike the business or economic criteria (see Sect. 5.3). A large number of possible selection criteria can be found (see, for example, Willcocks et al. 2017, p. 22; Allweyer 2016, p. 4)—some of which are mentioned regularly (for example, the degree of process standardisation), while others vary (for example, some are explicitly limited to middle and back office processes). Table 3.1 presents technical process selection criteria. These can be used partially or completely for process selection. It is also possible to weigh individual criteria. 

If one asks for a reduction to a single, decisive criterion, this is certainly the digitality of the data. Automation stands and falls with this criterion, since only digital data can be processed by software.



Practice shows that many processes—initially excluded from RPA automation due to the lack of digital data—can be automated by digitising the data or process flow at an earlier stage. For example, a bank’s front office employees could in future send the data for processing a customer inquiry to the back office in a digital order format instead of entering it in a form, printing it out and forwarding it by mail. Alternatively, the customer could enter the data electronically in a form that could be processed directly.

When searching for processes that can be automated, it should not be assumed that all processes that are basically suitable for RPA can actually be fully automated. Only less than 5% of all activities—across all industries—are 100% automatable (see McKinsey Global Institute 2017, p. 5). By contrast, around 60% of all activities have a share of automatable activities of at least 30%. This is another argument for not regarding RPA as

3.2  Technical Selection Criteria for Automatable Processes

41

Table 3.1  Technical process selection criteria (see Willcocks et al. 2017, p. 22; Allweyer 2016, p. 4) Criterion

Comment

Degree of standardisation

The more standardised, the sooner automation can take place

Rule-based nature

The process must be fully rule-based in order to be fully automated. Otherwise, partial automation should be considered

Process stability/ maturity

The more stable a process is—i.e. the less frequently the process is adjusted—the more suitable automation is, since fewer adjustments of the bot have to be made in the operating procedure

Complexity

The lower the complexity, the easier the automation

Digitality of the data

Only digital data can be processed by the bot

Structure of the data

RPA can only process structured data, i.e. data that the bot receives in the previously expected form. For example, arbitrarily formulated e-mails are not suitable; more advanced technologies are required for this (see Chap. 9)

Data type

Text and numbers are suitable, but pictures or handwritten data are less suitable. Supplementary technologies should be used for this purpose (see Sect. 9.1)

Applications involved

The more applications the process passes through and the higher the number of system breaks, the more sensible the automation with RPA

a complete replacement for human labour, but rather as a useful supplement and support for simple, repetitive activities. When selecting a process, it is therefore advisable not to interpret the technical criteria too strictly. A process that contains individual manual activities and yet processes predominantly digital data can still be a process that can be automated in a meaningful way. However, a corresponding division of the process in preparation for automation is then necessary (see also Sect. 5.6.2). Figure 3.1 shows the division of a process into fully, partially or not at all automatable process parts. In the partly automated process part, human and machine work hand in hand. The fully automated part is taken over by the bots independently. In the non-automatable part manufactured processing by humans takes place, for example in exceptional cases within the process. Results of the Expert Interviews An exciting question deals with the basic orientation of process selection. Does a company focus on the automation of complex and time-intensive processes, whose number of process runs is relatively small, or rather on less complex processes that are run through relatively often? Both cases outlined above can lead to identical process costs in their current state, if, for example, pure processing time and tied capacity are taken as a basis. So far, almost exclusively statements and case studies can be found which name less complex and therefore often executed processes as target processes for RPA. The catalogue of criteria presented here is structured accordingly. It also covers the standard case. However, the expert

42

3  Application Areas of RPA

Fig. 3.1   Processes that can be partially automated

interviews show that more complex, time-consuming processes are also increasingly becoming the focus of selection for automation with RPA. This is especially true if the company in question is already in an advanced phase of using an RPA system, i.e. has already automated several less complex processes.

3.3 Selection of RPA Use Cases in the Financial Sector Following the definition of possible process areas within the financial industry and the provision of selection criteria for RPA-suitable processes, some examples of proven RPA processes in the financial industry are described below. Parts of these published case studies are taken from the authors’ daily practice.2 Further examples can be found in the individual chapters. Customisation of Customer Data A securities institution manages a seven-figure number of customer securities accounts. Via various interfaces—digital and analogue—the institute receives up to several thousand change orders for customer data every day. After minor process adjustments, the digitally incoming data is further processed by bots, validated and imported into various applications or databases—including the adjustment of the legally leading data sets. The additional use of an OCR component means that RPA can also process analogue

2For

reasons of anonymity, the latter are modified accordingly.

3.3  Selection of RPA Use Cases in the Financial Sector

43

incoming orders. Even if this does not lead to complete automation, a large proportion of all incoming orders can still be processed automatically. Auditing of Securities Settlements and Other Book Entries In the same institute, several employees work daily on the reconciliation of securities transactions across different applications. Individual transactions are entered in in-house applications and transferred to spreadsheet programs for reconciliation. Visual checks and comparisons are carried out at the same time. This work can be fully automated. In particular, the transfer of data between systems and checking data for consistency or predefined values and thresholds are among the core capabilities of RPA. Digital Product Closures A bank has recently started enabling its customers to buy individual products and services online, such as an online current account. The data recorded digitally by the customer is transferred to a service provider who—after a plausibility check—enters the data manually into the bank's core banking system. The creation of an interface that would enable the data recorded by the customer to be transferred directly into the core banking system is not possible in the short term. Instead, an RPA solution was developed that enables both plausibility checks and data transfer. In this way, an actual end-to-end digitalisation of the process is achieved. In addition, the processing time and thus the costs of the individual process are reduced many times over. Authorisation Management and IT Every time an employee is hired, changes department, changes competence or leaves the company, the IT department of an institute is required to grant, change or delete various authorisations. In many cases, these are similar “authorisation packages”, especially in the case of new hires or employees leaving the company. In all other cases, too, the steps to be taken are largely identical and, therefore, an ideal application for RPA. With the help of RPA, all authorisations can be processed in all necessary applications, so that human intervention is only required for basic specifications such as the master data or the areas of competence to be assigned. Everything else, the “hard work” that is often perceived as annoying, is carried out by bots. Another example from the area of authorisation management is the resetting of passwords. This is a use case that occurs daily in large quantities. Sometimes only small changes are required to make such processes automatable—for example, the implementation of a simple ticket system instead of a password hotline. Resetting passwords is just one example of the potential of RPA in IT. In principle, RPA can automate entire ticket systems and in some cases even answer first-level support queries independently (see Beardmore 2017). RPA is also suitable for monitoring servers or complex job chains, which is highly relevant for the IT areas of the financial industry.

44

3  Application Areas of RPA

Invoice Processing As a rule, incoming invoices are not processed immediately. Before the invoice amount is transferred, the correctness and legality of the invoice is usually checked. If all data is available in digital form, the entire process can be automated. If the data is available in an unstructured form, an OCR component must also be connected upstream to make the data editable by RPA. Alternatively, initial cognitive components are already being used here, for example to recognise relevant information in unstructured texts. AIMultiple (2019) represents such a process by integrating cognitive components. The savings achieved in this case study—without further explanation of the reference value used— are estimated at 67 FTE and thus at about $4 million. At the same time, the processing time decreases from 6–8 min to about 30 s. Provision of Rule Reporting A bank’s controlling department, which is organisationally assigned to overall bank management, creates daily and weekly reports for which various sources of information are used. In addition to in-house databases, the content of various websites to which no interfaces can be created is also accessed. All contents and data are condensed in a structured form and made available to the management of the bank in a layout that is always the same. In order to relieve the employees of these routine activities, automation with RPA is introduced. The bots merge the information as far as possible and make it available to the employees of the controlling department. They then perform quality assurance, carry out final steps and provide the final report. An example of the largely smooth interaction between human and machine. Trading Traders continuously monitor price thresholds in order to make changes to stop or limit orders, for example, or to execute buy and sell orders when the threshold is breached. In order to relieve them of the ongoing observation of prices and relevant market information, bots provide support for some of the activities. The bots monitor the prices in the institute’s trading system as well as information on relevant websites and send e-mails or alerts to the traders on the basis of predefined patterns and when certain events occur, enabling them to take immediate action. Compliance The Compliance unit monitors and checks various processes and other activities. It can only carry out the control activities to the extent that it has resources—i.e. employees. The use of RPA can create additional capacity here. This enables the establishment of additional test routines. The bots are particularly suitable for routines that would mean repetitive and non-complex activities for the employees, where the susceptibility to errors in the control is particularly high.

References

45

Further Applications In addition to those mentioned here, there are many other potential applications in the financial sector, for example (see also AIMultiple 2019 in some cases): • Account closures • Statements • Preparation of reports for auditors • Online applications from customers for all topics, such as accounts, loans, securities accounts, master data changes, etc. • Chargebacks • All digital test routines • … Conclusion It cannot be conclusively determined how many processes or what proportion of the total number of processes can be automated with RPA. According to some estimates, the share of processes that can be automated (for the most part and not to be excluded at first glance from a business management perspective) at retail banks is in the region of around 20%. If the goal is to identify individual tasks that can be automated within larger processes instead of entire processes, the proportion will increase. Depending on the type of financial services company, the proportion of automatable processes can vary greatly. The decisive criterion here—again—is the digital or non-digital nature of the data.

References AIMultiple (2019) RPA use cases. https://blog.aimultiple.com/robotic-process-automation-usecases/#banking. Accessed 10 Jan 2019 Allweyer T (2016) Robotic Process Automation – Neue Perspektiven für die Prozessautomatisierung. Working Paper Fachbereich Informatik und Mikrosystemtechnik Hochschule Kaiserslautern. https://www.kurze-prozesse.de/blog/wp-content/uploads/2016/11/Neue-Perspektiven-durchRobotic-Process-Automation.pdf. Accessed 27 Dec 2018 Beardmore L (2017) Robotic process automation. https://www.capgemini.com/service/businessservices/enabling-technologies/robotics-process-automation/. Accessed 20 Jan 2019 Hermann K, Stoi R, Wolf B (2018) Robotic process automation im finance & controlling der MANN+HUMMEL Gruppe. Controlling 30(3):28–34 Lacity M, Willcocks L (2016) Robotic Process Automation at Telefónica O2. MIS Q Exec 15(1):21–35 McKinsey Global Institute (2017) A Future that works: Automation, employment, and productivity. McKinsey & Company, New York Ostrowicz S (2017) Einsatz von Robotics in der Finanzindustrie. https://www.horvath-partners. com/es/media-center/studien/detail/einsatz-von-robotics-in-der-finanzindustrie/. Accessed: 24 Jan 2019

46

3  Application Areas of RPA

Ostrowicz S (2018) Next Generation Process Automation: Integrierte Prozessautomation im Zeitalter der Digitalisierung. Ergebnisbericht Studie 2018. Horváth & Partners, Frankfurt a. M. Otto S, Longo M (2017) ISG-Studie: Robotic Process Automation (RPA) sorgt für mehr Produktivität und nicht für Jobverluste. https://www.isg-one.com/docs/default-source/defaultdocument-library/isg-automation-index-de_final_form.pdf?sfvrsn=15defe31_0. Accessed 20 Jan 2019 PWC (2017) What PwC’s 2017 survey tells us about RPA in financial services today. https://www. pwc.com/us/en/financial-services/publications/assets/pwc-fsi-whitepaper-2017-rpa-survey.pdf. Accessed 10 Jan 2019 Wadlow T (2017) Offering the digital choice. https://almato.de/fileadmin/files/downloads/ DeutscheTelekom-technology-April2017_V1.pdf. Accessed 10 Jan 2019 Willcocks L, Lacity M (2016) Service automation. Robots and the future of work. Steve Brooks Publishing, Warwickshire Willcocks L, Lacity M, Craig A (2017) Robotic process automation: strategic transformation lever for global business services? J Inf Technol Teach Cases 7:17–28

4

RPA Market Overview and RPA Software Solutions

Abstract

The following chapter first provides a brief overview of the current development of the overall RPA market. It then looks at the diversity of RPA software providers. However, this chapter deliberately avoids a comparison of software providers (by name). Section 5.4 provides details and advice on selecting the appropriate solution. The chapter also explains the role of RPA consultants and other implementation partners and defines four different roles they can take. Appropriate criteria are provided for the individual selection of suitable consultants and implementation partners.

4.1 The RPA Market—Hype or Long-Term Trend When talking about the RPA market, caution is required. Market research institutes, RPA vendors, but also RPA consulting firms and RPA implementation partners flood the market with forecasts and estimates for market development, some of which are far apart from each other, but all point in one direction: upwards. The RPA market promises to grow significantly in the coming years. In order to get a feel for this, first of all some growth forecasts current at the time of writing this book are presented and explained where necessary and possible. This is followed by an attempt to draw a conclusion from these different statements. Extract of Different Assessments Dickgreber et al. (2018) expect the size of the global RPA market to be 5000 million US$ in 2020. According to them, its size was still around 140 million US$ in 2012, around 1300 million US$ in 2017 and an estimated 3200 million US$ in 2019.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 M. Smeets et al., Robotic Process Automation (RPA) in the Financial Sector, https://doi.org/10.1007/978-3-658-32974-7_4

47

48

4  RPA Market Overview and RPA Software Solutions

This corresponds to an average annual growth rate of 56% since 2012—which in fact continues to increase on an annual basis. Grand View Research (2018) cites more moderate figures. Here, the size of the global RPA market in 2017 amounts to around 358 million US$. The forecasted annual growth rate until 2025 is 31.1%. The market size in this scenario is around 3110 million US$ in 2025. Grand View Research divides the RPA market into the market for RPA software and the market for RPA services, for example, RPA consulting (see Sect. 4.3). The forecasted annual growth rate for RPA services is even 33.4%. The market research and consulting company Gartner estimates the global size of the RPA market in 2018 at 680 million US$ (see Tornbohm 2018). In 2022, the market size is expected to have increased to around 2400 million US$. For all the figures mentioned here and elsewhere, it is important to check and compare the reference values carefully. For example, the forecasts sometimes only take into account the sales of RPA software providers; others also include sales from consulting services related to RPAs, etc. These factors may (partly) explain the differences between the individual forecasts. Market size is obviously not the only indicator that can be used to describe the RPA market. Market research institutes are now collecting key figures on various topics and offers related to the RPA industry. For example, market shares of individual software vendors or consulting firms are analysed, industry sizes are determined and country-specific values and sizes are collected. Examples of this are the market research reports of the market research companies Grand View Research or Gartner. The market for RPA in the financial sector is also expected to grow. According to Ostrowicz (2017), who investigates the views of potential RPA users, 70% of all financial institutions are already using or planning a productive RPA pilot. Only less than 30% do not plan to use RPA. The forecast examples show: The market for RPA software and accompanying services—consulting, implementation, etc.—is growing.

4.2 Software Providers and Their Solutions Software Providers In recent years, the number of RPA software providers has increased significantly (see van der Aalst et al. 2018, p. 269). These can be divided into vendors that focus exclusively on RPA technology and vendors that have integrated RPA as part of their product portfolio or add an RPA component to their existing software solutions. Examples of exclusive RPA providers are Automation Anywhere, AutomationEdge, Blue Prism, Kryon System, Softomotive or UiPath (see van der Aalst et al. 2018, p. 269).

4.2  Software Providers and Their Solutions

49

Pegasystems and Cognizant represent the other category of vendors that have integrated RPA as a complementary component in their portfolio.1 As of the beginning of 2019, the RPA market comprises around 50 different software providers (see AIMultiple 2019b). This number is constantly changing. The providers can be compared with each other based on different criteria (see AIMultiple 2019b). Some of them offer completely free versions or only free trial versions. Others differ in the way they price the individual bots. In addition to licensing complete platforms and packages, pricing per bot or per automated process is common. The software also differs in its functional scope. For example, individual software products now offer the possibility of directly recording processes by means of screen recording, as already explained, or the possibility of integrating other technologies, for example OCR components for converting handwritten texts into machine-readable formats.2 Selection of the Right Software Solution The selection of the right RPA software should always be made in the context of the objectives pursued with the RPA deployment. In addition, an organisation-specific review is necessary. Depending on internal requirements, procedures and options for RPA implementation, one software may be better suited than another. A concrete procedure for this is described in Chap. 5. Example

If a financial service provider decides to transfer responsibility for RPA to a unit within the IT department, RPA software that has (easily) programmable elements may be more suitable (see also Chap. 6 for the classification of RPAs in the organisational structure and RPA governance). If, on the other hand, responsibility is to lie within another department with less technical background, software that is strongly based on a graphical configuration is often the better choice. ◄ In addition to the criteria described in Chap. 5, the components of the RPA software listed in Sect. 2.2 can also be used to select a suitable software: The possibility of modularity in artefact development, the use of string operations, variable management, integration of conditions, loops, etc., as well as the software’s properties in the area of (IT) security and error handling.

1The

software providers mentioned here are only an exemplary selection of the constantly changing total number of RPA software providers. 2A comparison of different software is not made here, as it is not possible to guarantee sustained completeness in the constantly changing market environment.

50

4  RPA Market Overview and RPA Software Solutions

4.3 RPA Consultants and Implementation Partners In addition to software providers, various types of RPA consultants and implementation partners have been established in recent years. In this context, implementation partners are understood to be all partners who are connected with the company that wants to use RPA in the context of introducing and using the technology. These are not only consultants, but also the RPA software providers themselves. They can also be outsourcing service providers. RPA consultants, on the other hand, support the RPA implementation process at all stages, but do not act as software vendors or outsourcing service providers. The first step is to take a more detailed look at RPA consultants. Before possible differentiation criteria of RPA consultants can be discussed, the questions of what RPA consultants are and why their support can be useful must first be answered. RPA Consultant An RPA consultant is defined here as a consultancy firm (or an individual consultant) that can provide comprehensive support to its customers in the implementation of RPA. This means that an RPA consultant must know and be able to go through the entire RPA implementation process model (see Chap. 5). A closer look at this model will show that various skills are required here: project management, process management, test management and last but not least the ability to develop RPA artefacts. In most cases these skills are not covered by a single person. Different people are often employed for those skills, for example, differentiated into project and process managers and RPA developers. In some cases they all come from a single RPA consultancy firm, in others they work together across companies. Services of RPA Consultants RPA consultants offer their customers comprehensive services for the implementation of RPA (see also AIMultiple 2019a). These services can be divided into two categories. On the one hand, there are those that are provided prior to the actual implementation—in the sense of artefact development—and on the other hand, in services within the scope of the later artefact development itself. Services in the first category can be, for example: • • • • • • •

Support in the internal classification and decision-making process for the use of RPA Project planning Process selection Process recording Process optimisation Documentation of the optimised processes that can be automated RPA software selection

4.3  RPA Consultants and Implementation Partners

51

Services in the second category can be, for example: • • • • •

Setting up the necessary IT infrastructure and installing the RPA software Development of RPA artefacts Testing the RPA artefacts Rollout and rollout support Review of the first automation results and possible adjustments

There are also cross-category activities, such as managing the implementation and integration of various corporate divisions and, if necessary, external service providers. Added Value Through RPA Consultants In addition to simply providing resources to carry out RPA projects alongside “day-today business”, RPA consultants can bring experience and expertise to the implementation of RPA. This helps to avoid possible planning and implementation errors and often leads to efficiency gains. Especially when the organisation is dealing with RPA for the first time, support is recommended. After an initial process review, RPA consultants can quickly assess whether a process can be automated, whether it needs to be adapted in advance or whether it cannot be automated. At the same time they know where to look for processes that can be automated. In addition, engaging external consultants enables the organisation to react quickly to possible changes in its RPA strategy, especially through the scalability of external support. Results of the Expert Interviews The results of the expert interviews show that RPA consultants are not only called upon to provide support for initial implementations of RPA. They are also regularly consulted for subsequent implementations or the adaptation of existing RPA solutions and questions in the context of ongoing RPA operation. The main reasons for using them for initial implementations are existing knowledge and experience and RPA development skills. For subsequent implementations, the assessments differ. In some cases, experience and knowledge are the main factors. In many cases, however, it is the possible scalability of external RPA consultants that argues against a complete build-up of RPA know-how within the organisation.

Selection of the Right RPA Consultant Choosing the right RPA consultant is not easy. In addition to specialised consultants, established and well-known consulting firms have now also included RPA technology in their consulting portfolio. Some focus on the strategic elements of an RPA implementation. These can be elements such as objectives and the strategic use of RPA, or process selection procedures. As a rule, they do not carry out the actual development of the RPA themselves, but instead use other consulting firms or other cooperation partners. In addition to strategically oriented consultants, the more process-oriented consultancies provide support in the area of process optimisation and preparation for the subsequent

52

4  RPA Market Overview and RPA Software Solutions

Table 4.1  Selection criteria for RPA consultants (based on AIMultiple 2019a) Criterion

Description

RPA Experience

The RPA advisor should have sufficient experience in implementing RPA

Industry-specific experience

The right RPA advisor for a financial institution needs appropriate experience in the financial industry. This is the only way to be able to identify relevant processes and to evaluate and adapt them professionally

Business unit specific experience

The RPA consultant should have experience specific to the business unit in order to be able to assess the relevant processes in detail. For example, market and back office processes in banks differ significantly from one another

Experience in project management

The RPA consultant should be able to adequately control and, if necessary, manage (complex) projects with participants from different business units and external service providers

Experience in the preparation and monitoring of strategic decisions

The deployment and orientation of RPA are strategic decisions that need to be prepared and subsequently implemented. In addition, each potential RPA process requires a business-case-based decision pro/ contra automation. The RPA consultant should have the appropriate know-how

introduction of RPA. The actual artefact development is often carried out by system integrators or consultants focused on technical development. Various criteria can be used to select the right RPA consultant, which are shown in Table 4.1. Implementation Partner In the following, the implementation partners, some of whom have already been described above, will also be examined in more detail. It is not always easy to differentiate which provider offers which services here. For this reason, a classification will be made in the following, which will help to allocate and differentiate providers. Lacity and Willcocks (2016, p. 33; AIMultiple 2019a) use the “customer view”. They differentiate implementation partners (i.e. also software providers) on the basis of the type of “sourcing” according to the following scheme: 1. Insourcing: The direct purchase of RPA licenses from the software vendor. 2. Insourcing + consulting: The direct purchase of RPA licenses from the software vendor, supplemented by the use of consulting services for the development of RPA artefacts and other RPA-related activities. 3. Outsourcing to an established BPO provider: The RPA solution is implemented at the outsourcing service provider. The processes are outsourced to the provider, where they are handled by RPA.

4.3  RPA Consultants and Implementation Partners

53

Fig. 4.1  Categorisation of implementation partners and RPA consultants

4. Outsourcing to a (newer) RPA supplier: This option can be classified as novel, since RPA providers have only recently started to act as outsourcing service providers themselves. 5. “Cloud Sourcing”: The use of RPA as a cloud solution. This is still a new approach that presents (even now) big hurdles for the financial industry, a strictly regulated industry that operates with highly confidential data. The differentiation presented here uses the criterion of “sourcing” to ask what strategy should be pursued in the use of RPA. However, this criterion is not the only way to distinguish implementation partners from each other. In the following, a different differentiation is presented, which does not use this criterion alone. The perspective here is not just a (RPA) strategic one. Rather, the strategic and the operative implementation-oriented view are combined by differentiating between the types of implementation partners. At the same time, the different types, RPA consultants and implementation partners are linked here. Figure 4.1 shows four different types of RPA consultants or implementation partners, which can be distinguished by four dimensions.3 These dimensions describe individual services related to RPA: 1. License sales 2. Software programming and customizing 3. Implementation project realisation 4. Banking-specific process preparation/-optimisation

3Instead

of a direct purchase of RPA software from the software manufacturer, it is assumed here that the software is purchased from a reseller—a case which is more common in practice.

54

4  RPA Market Overview and RPA Software Solutions

The four types of implementation partners each offer a different spectrum of services in the area of these dimensions. Pure Reseller The pure reseller only sells RPA licenses. He does not provide support in implementing the RPA solution in the organisation. Accordingly, he does not carry out any RPA projects and does not provide any process consulting or adaptations. Depending on the terms of the contract, the reseller can, for example, provide first, second and/or third level support. Reseller and Technical Implementer Here, the reseller sells RPA licences, too. In addition, the reselling company offers its customers support in the technical implementation of the software. This refers to installation, customizing, and usually also to the development of the RPA artefacts. Technical implementers usually have very extensive technical RPA know-how. They are able to develop complex RPA artefacts and train the customer’s employees to operate RPA independently. Precise knowledge of the industry and thus individual process knowledge is the exception here. In most cases, it is not possible to provide professionally sound process management in the sense of process evaluation and optimisation. Outsourcer The outsourcers are usually established service providers who have been offering outsourcing services to their customers for a long time. They are usually very experienced in process management and automation. These companies are increasingly turning to RPA to handle the processes of their customers more efficiently (see Willcocks and Lacity 2016, p. 55). The focus here is usually on cost reduction. One disadvantage of using the outsourcers’ RPA solutions is that the entire RPA know-how remains with the service provider. The organisation that outsources its processes itself has no or only indirect contact with RPA. Therefore, this solution only makes sense if the company does not intend to use its own RPA in the long term. Allrounder An allrounder offers its customers the full range of services necessary for the successful introduction and operation of RPA. It sells RPA licenses and provides different levels of support. At the same time, the allrounder is able to carry out RPA implementation projects and pass on the relevant knowledge to its customers. In addition to the technical implementation and development of the RPA artefacts, the allrounder is able to perform active process management, i.e. select, evaluate and optimise processes to be automated before they are automated.

References



55

Which type of implementation partner is the right one has to be decided individually. The decision depends on expectations of the implementation, the organisation’s own know-how and, last but not least, available resources.

References van der Aalst WMP, Bichler M, Heinzl A (2018) Robotic process automation. Bus Inf Syst Eng 60(4):269–272. https://doi.org/10.1007/s12599-018-0542-4 AIMultiple (2019a) RPA-consulting. https://blog.aimultiple.com/rpa-consulting/. Accessed 17 Jan 2019 AIMultiple (2019b) RPA vendors comparison. https://blog.aimultiple.com/robotic-process-automation-rpa-vendors-comparison/#rpa-tool-list. Accessed 18 Jan 2019 Dickgreber F, Schneider H, Warren B, Adam R (2018) Robotic process automation. https://crm. arvato.com/en/solutions/crm-and-customer-services/download/whitepaper-robotic-processautomation-rpa-for-finance-back-office-processes.html#download. Accessed 20 Jan 2019 Grand View Research (2018) Robotic Process Automation (RPA) Market Size, Share & Trends Analysis Report By Type (Software, Services), By Application (BFSI, Retail), By Organization, By Services, By Region, And Segment Forecasts, 2018–2025. https://www. grandviewresearch.com/press-release/global-robotic-process-automation-rpa-market. Accessed 20. Jan 2019 Lacity M, Willcocks L (2016) Robotic process automation at Telefónica O2. MIS Q Exec 15(1):21–35 Ostrowicz S (2017) Einsatz von Robotics in der Finanzindustrie. https://www.horvath-partners. com/es/media-center/studien/detail/einsatz-von-robotics-in-der-finanzindustrie/. Accessed 24 Jan 2019 Tornbohm C (2018) Gartner schätzt RPA-Markt 2018 auf 680 Millionen US-Dollar. https://www. ecmguide.de/news/gartner-schaetzt-rpa-markt-2018-auf-680-millionen-us-dollar-24089.aspx. Accessed 20 Jan 2019 Willcocks L, Lacity M (2016) Service automation. Robots and the future of work. Steve Brooks Publishing , Warwickshire

5

The Implementation of RPA

Abstract

The following chapter describes the procedure for implementing RPA in detail. We focus on topics and special features that are relevant to the initial implementation of RPA within an organisation. However, many aspects also apply to subsequent implementations. All topics are covered, from setting up a suitable project structure, process selection and adaptation, RPA-development, testing and implementation of automated processes, to ensuring the long-term operation of the RPA. Helpful overviews are available in many places, which can also be used as checklists for practical application. This chapter is one of the most important parts on your way to an effective and efficient use of RPA in your own organisation. Relevance becomes clear when looking again at the rate of failed RPA projects mentioned in Sect. 1.1: 30–50%. A sound approach can help to avoid being one of those failed projects. Before considering the implementation of RPA solutions in detail, some preliminary considerations are necessary. First of all, a case distinction must be made. Basically, the implementation of RPA can take four different forms. These can be seen in Fig. 5.1. First, the initial implementation of RPA must be separated from a subsequent implementation. You can then differentiate between whether the implementation is carried out from an RPA project or from a line unit. The latter can be a pure enterprise resource planning unit or an existing line department, such as the organisational department. In addition to those listed here, other forms of implementation are also conceivable. On the one hand, however, these represent the exception rather than the rule, and on the other hand they are usually variations of the forms presented here.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 M. Smeets et al., Robotic Process Automation (RPA) in the Financial Sector, https://doi.org/10.1007/978-3-658-32974-7_5

57

58

5  The Implementation of RPA

Fig. 5.1  Implementation forms

1st Case “pilot project”: Implementation via Project as a Suitable Form of Piloting and Initial Introduction of the RPA Technology The first-time introduction of a new technology in an organisation regularly requires greater efforts than, for example, expanding the use of already established technologies. Expertise in handling the new technology has to be built up, specialist departments and IT have to be involved and stakeholders have to be convinced. Implementation in project form offers the following advantages: • Sufficient time, budget and resources are available. • A high level of attention from the management and ideally “sponsoring” by one or more decision-makers is assured. • A (long-term) decision for a certain form of line classification is not yet necessary at the beginning of the project. The decision for long-term implementation within the organisation can be made during the course of the project. Thus, first empirical values and well-founded estimations of the participants are available. This raises the question of how an initial implementation should be carried out. Should many or only a few processes be automated in parallel? Should simple processes be automated first, or should the verification of functionality be better done using complex processes? 

The simple solution is to think in large dimensions right from the start, but to start small (see also Willcocks et al. 2017, p. 19).

5  The Implementation of RPA

59

What this means: Right from the beginning, appropriate structures should be planned, the infrastructure has to be prepared and all relevant departments and persons should be involved. At the same time, the first processes to be automated should be both a few (possibly only one) and simple, less complex processes. This increases the chances of quick success—an important factor when it comes to convincing decision-makers of the advantages of an RPA solution through a pilot implementation. 2nd Case “rollout project”: Implementation via Project as a Suitable Variant for Extensive, Organisation-Wide or Cross-Departmental Rollouts of the RPA Technology If the technology has already been introduced and piloted in the organisation, other potential processes that need to be automated often follow quickly. In addition to the 4th case—the implementation without project after the technology has been established in the organisation—an implementation by project is also suitable for this purpose. This is always useful if a large number of processes are to be automated in a short period of time, many different participants have to be involved or more extensive topics are to be dealt with—for example, the implementation of RPA governance (see Chap. 6). 3rd Case “cold start”: Implementation in the Line Unit Without a Previous Pilot Project And Without Knowledge of the “fit” between Technology And Company Specifics Let us first consider the general conditions for implementing RPA in a line unit. This requires the existence of an RPA unit with appropriate roles and budget (see RPA governance Chap. 6). At the same time, the persons involved must have extensive experience in handling the technology. These prerequisites show that a first-time implementation of RPA should generally not be carried out within a line unit. This option will therefore not be considered further in the following. 4th Case “Established RPA use”: Implementation by Line Unit Only After RPA Technology is Established in the Organisation In contrast to the third case, the procedure described here can be observed more frequently in practice. In many cases, the appropriate framework conditions for long-term use of the technology can already be created within the first RPA implementation project. The interplay between RPA and people, processes and IT infrastructure, which is specific to each organisation, can thus be optimally taken into account and incorporated into the structure of the line unit. Comparison of RPA Implementations From Projects and From Line Units Table 5.1 provides an overview of the various advantages and disadvantages of implementing RPA in project and line form. The third case—implementation in the line unit without a previous pilot project—is deliberately excluded from the analysis.

60

5  The Implementation of RPA

Table 5.1  Advantages and disadvantages of implementation in project form and in line Advantages Implementation Project

Disadvantages Implementation Project

Advantages Implementation Line

Disadvantages Implementation Line

Sufficient budget, time Knowledge transfer and resources required after project completion

Permanent anchoring of automated and automation processes in the organisation

Greater use of resources required, since development is usually long-term

High management attention

High acceptance among employees

Less flexibility in reacting to changes in the general conditions

Risk of neglecting RPA operation, RPA release management, RPA error handling, etc

“Protected space” to gain experience in dealing with RPA

Focus not on quick success, but long-term commitment

Risk-minimizing; initially pilot-testing possible

Topics such as RPA operation, error handling, etc. usually more in focus

Stakeholders and employees can be “gently” introduced to technology

Results of the Expert Interviews The expert interviews conducted prove that the initial implementation almost always takes place in projects. The main reason is the initial lack of technological know-how within the organisation. Subsequent implementations are also often still carried out in project form, as the transition to line operation regularly takes up more preparation time than the first project provides. In some cases, there may also be organisational reasons for retaining the project form, such as the fact that it is easier to allocate required budgets to projects than to line units, or the greater flexibility of a project. In the medium term, however, the aim is usually to make some kind of transition to the line unit for subsequent implementations.

Maturity Level Of RPA Within an Organisation Murdoch (2018, Chapter “RPA in the Enterprise”) and Willcocks and Lacity (2016, p. 124) distinguish three levels of maturity of RPA within an organisation: 1. Initialisation The organisation is starting or has recently started to use RPA. The number of bots working in parallel is limited to a maximum of 10–15; the automated processes are rather homogeneous. The focus here should be on defining an RPA strategy, creating RPA governance and extended framework conditions. In addition, standardised procedures for process selection, automation, etc. will be developed.

5.1  Overview of the Basic Process Model—Phases

61

2. Industrialisation A significantly larger number of bots work in parallel. The bots are often divided into individual groups, which in turn process specific process groups of individual business units. In this context they are also referred to as “bot farms”. Here, RPA already represents an essential part of the IT strategy. 3. Institutionalisation Organisations in this phase exceed the limits of typical RPA usage. They add other technologies or use RPA for areas that are not typical target areas. The RPA culture in the organisation is strong, expertise is widespread and extensive metrics are used to measure and improve RPA performance. These three stages can each have different implications for the format of implementation. In stages 2 and 3 in particular, it can be assumed that RPA is already integrated into the line structure (see also Chap. 6). With regard to the type of implementation, we can assume implementations from within the line.

5.1 Overview of the Basic Process Model—Phases As explained above, the implementation of an RPA solution usually takes place in project form—at least as long as the technology is not yet established in the implementing organisation. In the following, we assume that the first implementation will take place as a project. Figure 5.2 describes the basic process model for a successful RPA implementation. The process model can—slightly modified—also be used for larger rollout projects. Even experienced RPA users can follow the structure described here and omit individual

Fig. 5.2  Process model for RPA implementation

62

5  The Implementation of RPA

steps. In this case, it is usually no longer necessary to select a suitable RPA solution and carry out a Proof of Technique (PoT). The individual steps are described in detail in the following Sects. 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9, 5.10 and 5.11. In practice, it regularly happens that the first step is to select an RPA solution and a subsequent PoT. This is to avoid the effort of setting up a project structure before it is certain that the software can be technically implemented. In addition, the possible implementation costs are only known after selecting the RPA solution or its provider. In this case, setting up the project structure is postponed (see Sect. 5.2) and becomes the third step.

5.2 Setting up a Suitable Project Structure The beginning of each project consists of defining its goals, framework, necessary resources, roles and the project team—all of which are set out in the project assignment. This is followed by project planning and structuring, process planning and cost estimation (see Meyer and Reher 2016). All these steps are also required to set up an RPA project. Objective The objective of an RPA project is usually to automate an initial process in the organisation. It is supplemented by other objectives, such as integrating the RPA software into the organisation's own IT infrastructure, preparing a rollout of the technology for other processes or a prior, fundamental examination of whether suitable business cases can be found in the organisation. 

Pilot projects for the implementation of a first RPA process and for the identification of further potentials can already be realised with little time and cost.

General Conditions Relevant stakeholders must be identified and involved at the beginning of the project. In the financial sector, these include in particular auditing and compliance departments, IT security management and the works council (see Chap. 7). In addition, the department responsible for the process to be automated must also be involved. 

All employees who will come into contact with the new technology in the course of the project should be fully informed and—as far as possible—integrated at the start of the project. This allows reservations, but also fears and concerns about RPA to be addressed early on.

5.2  Setting up a Suitable Project Structure

63

The use of RPA technology must be distinguished from other similar technologies, in particular if these technologies are also used within the same organisation. However, it is not only a distinction that makes sense. It is just as important to examine at an early stage to what extent different process management technologies can be linked and mutually integrated to create synergy effects. Resources and Team The resources required (time, cost and manpower) and the composition of the project team depend heavily on the scope of the RPA project. An RPA project to implement an initial automated process can be successfully completed within a few months, assuming the right framework and resources are available. The team should at least consist of: • • • •

An RPA project manager An RPA business analyst An RPA developer Employees from the IT and relevant specialist areas

While the RPA project manager takes over, coordinates and controls the project management, the business analyst takes care of the analysis, recording and possible adjustment of the process. The RPA developer later implements the process as an automated process using the RPA software. IT support consists in particular of providing the necessary IT infrastructure, i.e. hardware, software, servers, databases, etc. The process-responsible department provides the process experts and ensures that the automated process is later integrated into operations. Alternative compositions and sizes of the project team are also conceivable. Willcocks et al. (2017, p. 23), for example, report a team of more than 20 people for the initial implementation of ten pilot processes. However, similar role distributions can also be identified here as in the above-mentioned team structure—the roles are usually filled with several employees instead of one. Similarly, in very small implementations, several roles can be assumed by one person. 

The composition of an RPA team in long-term operation (usually in line form) is dealt with in Sect. 6.3, where the term “RPA unit” is used to distinguish the unit responsible for RPA in the line from the RPA project team we consider here.

It makes sense to fill the roles of RPA project manager, RPA business analyst and RPA developer with RPA-experienced external consultants or at least to place them at the side of the internal project participants—especially for initial implementations. These can accelerate the knowledge build-up and avoid initial errors in the RPA implementation. In addition, they usually bring a wealth of experience and best practices from other RPA implementations to the project. All in all because of the significantly faster

64

5  The Implementation of RPA

implementation, the use of external consultants can often even save costs. A precise assessment and quantitative evaluation of the costs of in-house provision of services (in the form of employee working hours) and the costs of external consulting are beneficial. 

In order to achieve a quick transfer of knowledge, the project work should not be carried out entirely by consultants. It makes more sense for internal and external project participants to work together.

Project Structure A breakdown into individual sub-projects is only required for larger RPA projects or programs. For example, if several processes are to be automated at the same time or if they are very complex. In such cases, the following subproject structure is useful: • • • •

Organisational implementation of RPA Technical implementation of RPA (infrastructure) Process analysis and adaptation Automation, testing and rollout

If the project serves to estimate the potential of RPA, a further sub-project can be set up for the RPA potential analysis. The structuring proposed here enables largely parallel and thus efficient work.

5.3 Selection of the Processes to be Automated The next step is to select the processes to be automated or a pilot process. For this purpose, different approaches are conceivable, which are shown in Fig. 5.3. They differ in their degree of complexity and time required. This increases from left to right. They also differ in their potential degree of coverage. A high potential coverage means that with

Fig. 5.3  Process selection procedures

5.3  Selection of the Processes to be Automated

65

this approach there is a high probability of identifying all processes of the organisation or the previously defined area that can be automated with RPA. The degree of coverage increases from bottom to top. Detailed Consideration of the Approaches In the first case, the process is already known at the time of the decision to introduce RPA. Either an automation technology for a specific process was sought here and the choice was made for RPA, or the decision was made to introduce RPA and the choice of process was included in this decision. In this case, there is no complexity in the process selection and no time is needed. However, the potential degree of coverage is very low. The process selection here is often made with little or no experience of the decision-makers in the field of RPA, and there is no comprehensive examination of various processes. The second approach is more complex and takes more time. The processes to be automated are determined in one or more workshops. Workshop participants are process owners and employees of the relevant departments. Together, they get to know the technology, jointly define the process selection criteria and then decide on individual target processes. The larger the number of participants, the greater the chance of identifying as many automatable processes as possible—but at the expense of complexity and time. This approach offers additional advantages. Relevant employees are involved at an early stage and ideally convinced of the benefits of the technology. Possible hurdles in the later implementation can be identified right here. The third approach is the most complex and time consuming. Here the process selection is done by assessing all processes documented in the organisation. If the organisation has an established process management, all processes and tasks are usually documented and can be analysed. If this is not the case, upstream process recording and documentation could be carried out, but this would usually exceed the scope of the RPA project. The advantage of this approach is the complete overview of all processes that can be automated throughout the organisation. Selection Criteria The selection criteria for processes suitable for RPA can be roughly divided into technical and business criteria. While technical criteria focus on the characteristics of the process flow, business criteria refer to the profitability of process automation, for example. In particular, they can be used as indicators for the benefit criteria of cost savings, quality improvement and time reduction (see Sect. 2.3)1

1The

criteria are not always divided into technical and business criteria. Willcocks et al. (2017, p. 22), for example, do not further divide the criteria they listed - degree of process standardisation, rule-basedness, process maturity and transaction volumes.

66

5  The Implementation of RPA

Table 3.1 has already comprehensively presented and explained the technical criteria for selecting processes suitable for RPA. These are now to be supplemented by business criteria in order to obtain a complete catalogue of criteria for selecting the processes that can be automated in the implementation project or later. Table 5.2 shows possible process selection criteria—divided into technical and business criteria. Here again, the criteria can be used in part or in full, or even be given a weighting. The technical criteria provide a quick answer to the question whether a process can be automated at all. The business criteria, on the other hand, require further consideration. Taken alone, they do not provide a valid statement for a process selection. They must either be set in relation to other processes (benchmarking), or—better—be checked by means of a process-specific business case. Process-Specific Business Case A process-specific business case compares the process costs in the actual state with the possible savings through automation. The savings are calculated as the difference between the process costs in the actual state and the costs for automation. The costs for automation are made up of the following parts in particular: Running costs for: • • • • •

RPA software Associated IT infrastructure Education/training of the employees responsible for RPA “Support costs” for RPA bots If necessary, adjustment effort after releases of the target applications, etc.

One-time costs for: • Initial effort for process recording, adaptation, etc. • Technical implementation of automation, i.e. artefact development and testing • Implementation and rollout 

The total cost of implementing and operating an RPA solution—including the cost of automating a process—is also known as the “Total Cost of Ownership”.

The one-time costs for the implementation depend largely on the amount of effort that has to be invested in the automation. This in turn determines the number of days required by an RPA developer to implement the automation. Experience shows that learning effects occur over time. The initial duration for process automation decreases with each additional process, down to a minimum value of time required. The reason for this is that at the beginning there are usually more extensive explanations, discussions, etc., which are necessary in the context of process adjustments and actual automation.

5.3  Selection of the Processes to be Automated

67

Table 5.2  Technical and business process selection criteria (see Willcocks et al. 2017, p. 22; Allweyer 2016, p. 4) Criterion

Technical/business

Comment

Degree of standardisation

Technical criterion

The more standardised, the sooner automation can take place

Rule-based nature

Technical criterion

The process must be fully rule-based in order to be fully automated. Otherwise, partial automation should be considered

Process stability/maturity

Technical criterion

The more stable a process is—i.e. the less frequently the process is adjusted—the more profitable the automation is, since fewer adjustments of the bot have to be made in the operating procedure

Complexity

Technical criterion

The lower the complexity, the easier the automation

Digitality of the data

Technical criterion

Only digital data can be processed by the bot

Structure of the data

Technical criterion

In its pure form, RPA can only process structured data, i.e. data that the bot receives in the previously expected form. For example, arbitrarily formulated e-mails are not suitable; more advanced technologies are required for this (see Chap. 9)

Data type

Technical criterion

Text and numbers are suitable, but pictures or handwritten data are less suitable. Supplementary technologies should be used for this purpose (see Sect. 9.1)

Applications involved

Technical criterion

The more applications the process passes through and the higher the number of system breaks, the more sensible the automation is with RPA

Case frequency

Business criterion

The higher the case frequency, the more profitable automation is, since more actual process costs tend to be saved

Process costs

Business criterion

If measurable/known: Here it is necessary to check how high the process costs are (and to what extent they can be reduced by automation). Basically, the higher the actual process costs, the more worthwhile the automation

Susceptibility to errors

Business criterion

The more complex, varied and therefore also demanding the process, the greater the tendency to make mistakes during manual processing. Here, RPA can possibly be used to improve quality (continued)

68

5  The Implementation of RPA

Table 5.2   (continued) Criterion

Technical/business

Comment

Process handling time

Business criterion

If measurable/known: Here it is necessary to check how high the process processing time is (and to what extent it can be reduced by automation). Basically, the longer the actual process handling time, the more worthwhile the automation

Results of the Expert Interviews Andreas Albrecht, Head of Open Digital Factory/DekaBank, reports that the average development time for automating a process with RPA in-house was initially around 20 days. In addition to the actual implementation of the process, this included IT governance-related topics, logging, error handling, documentation and discussions with process participants. As more and more processes were automated, the standardisation and centralisation of development reduced the time needed step by step within a year, so that the development time for an RPA process then averaged five days.

It should be noted that the one-off costs—as the name suggests—are only incurred in the first year of the term. As a result, the business case, which is usually positive in the first year, turns out to be much more positive in the second year. Figure 5.4 illustrates this relationship with t as the first year and t + 1 as the second year. Moreover, an RPA bot usually handles more than one process. Accordingly, the running costs of the bot are to be allocated to all processes it executes.

Fig. 5.4  Process-specific business case

5.3  Selection of the Processes to be Automated

69

Determining the business criteria is not always easy. Process handling times, frequencies and costs are not always available. The costs can, for example, be determined by means of frequency-based costing—i.e. by multiplying processing time, case frequency and an adequate personnel cost rate—or are already available as process unit costs (for example, in the case of outsourced processes). However, the difficulty often lies in the basic work, namely measuring exact processing times and determining the frequencies. In this regard, reference is made to Fischermanns (2015), for example. If an exact determination is not possible, approximate estimates can be made by the process owners, which can be collected in expert discussions or workshops. Alternative Approach to Process Selection Lacity and Willcocks (2016, pp. 30–31) describe an alternative approach to selecting automatable processes. They show that Telefónica O2 uses the potential saving of at least three FTE by RPA as a decisive criterion for process selection. This means that only those processes are automated that (mathematically) replace at least three FTE p.a. To estimate the number of FTE, the number of process runs is determined and multiplied by the process handling time (this is called process complexity—whether this actually means the process handling time or something else remains unclear). Figure 5.5 illustrates this approach graphically. The axes can be assigned any values. Lacity and Willcocks (2016, p. 31) assign a value range from low, 30 min per process run for the process handling time by a human on the horizontal axis. On the vertical axis, the process volume, that is, the number of process runs, ranges from low, 1000 per week. The figure illustrates that it is not only processes with high volumes that enable automation that makes sense from a business management perspective. In addition to a process P1, which is run 1000 times a week and takes only a few minutes, for example, a process P3, which is run only a few

Fig. 5.5  Alternative approach to process selection for Telefónica O2 (based on Lacity and Willcocks 2016, p. 31)

70

5  The Implementation of RPA

Fig. 5.6  Application example of a portfolio analysis for process prioritisation (based on Fischermanns 2015)

times a day and takes 60 min, offers equally large savings potential. Process P2 would also be suitable. This process has a high process volume and a high level of complexity. P2 needs a correspondingly large number of FTE.2 Process P4, on the other hand, is neither carried out frequently nor is it sufficiently complex. Therefore, it is not suitable for automation with RPA in the approach presented here. In principle, all processes above the diagonal dividing line—i.e. those that lie within the grey-shaded area—are suitable for RPA following this approach. Figure 5.5 is to be understood as a sketch. In particular, the value ranges are freely definable and can be adjusted according to the size of the company, but possibly also according to individual automation costs. The approach is therefore only suitable if extensive (organisation-specific) experience with RPA has been gained. Process Prioritisation Once a sufficient number of processes have been evaluated (with regard to automation) they must be prioritised. A structured approach is useful for documentation purposes alone. Various tools can be used for this purpose, such as quantitative or qualitative ABC analysis and portfolio analysis (see Fischermanns 2015). Figure 5.6 shows an example of prioritisation using portfolio analysis. The individual criteria are rated from 1 to 3. These

2Lacity

and Willcocks (2016, p. 31) place a surface at the height of the grey diagonal line in Fig. 5.5 and call it an “automatable belt". The processes located in this area are suitable for automation, as they provide the mentioned savings of at least three FTE per year. However, the belt selected there excludes high-volume and complex processes such as P2. For this reason, an extended presentation of the approach is introduced here.

5.4  Selection of a Suitable RPA Solution

71

are qualitative assessments. For example, the number of process runs is not measured here, but is estimated. Each criterion is weighted relatively to the other criteria. The final result is a points total and a ranking or priority derived from this. The criteria used correspond in part to those listed in Table 5.2, and in part are more advanced criteria that allow a targeted comparison of the processes. The final prioritised processes are selected as RPA processes and then analysed in detail and adjusted if necessary (see Sect. 5.6). Prior to this, in Sects. 5.2 and 5.5, the right RPA software is selected and a preliminary technical test is carried out.

5.4 Selection of a Suitable RPA Solution Since Sect. 4.2 has already provided an initial overview of the RPA solutions currently available on the market, this section deals with the actual selection of the appropriate RPA solution. The selection of the most suitable RPA solution is closely linked to the selection of the processes to be automated. Thus, some RPA solutions interact better with certain applications than others. The simplicity of artefact development or the ability to implement them in the existing IT architecture can also be relevant distinguishing features of the individual solutions. An intensive selection process should never be neglected. The long-term success of RPA for the entire organisation depends on it. So from day one, a gradual build-up of know-how in the use of the selected software begins. Later software changes are therefore rather rare and should only occur in exceptional cases. In practice, the software selection process often takes place in combination with a “PoT” (see Sect. 5.5). In particular, the ability to integrate the RPA software into one's own application environment is one of the extremely relevant decision criteria for software selection listed below. Only the PoT provides final confirmation of smooth integration. The following procedure for software selection has proven to be successful: 1. Providing an overview of the current RPA software market 2. Initial selection (e.g. on the basis of the provider's industry focus, required basic functionalities, etc.) 3. Go through the software selection process—ideally with the help of a Request for Proposal 4. If required: on-site presentation and execution of the “PoT” by a remaining, small number of suppliers 5. Selection of the most suitable solution The preparation of a Request for Proposal (RFP), i.e. a document with detailed requirements for the software and contract specifications, helps to intensively deal with your own wishes and formalises them.

72

5  The Implementation of RPA

Table 5.3  Selection criteria RPA software Category

If required: Subcategory

Costs

Implementation costs

Costs

Licence costs

Costs

Expected other costs

Software

Components (see also Sect. 2.2)

Software

Usability (see also Sect. 2.2)

Support/training Audit, information and compliance security System requirements and integration capability Required provision services Qualification of the provider

Experience of the supplier in the industry, process area considered, etc

Qualification of the provider

Location, legal form, etc

Support of the provider Product roadmap

Table 5.3 provides an overview of possible selection criteria for the appropriate RPA software. If required, Porter-Roth (2002), for example, shows in detail what has to be considered when preparing a Request for Proposal. The individual categories and subcategories of Table 5.3 are explained below. Implementation Costs If the provider of the RPA software is also the implementation partner—i.e. if the implementation partner develops the first RPA bots—costs are incurred which vary from provider to provider. The costs usually consist of an estimated number of days of work multiplied by individual daily rates. Fixed prices are an alternative, for example for a certain number of process automation or other services. Licence Costs This includes the actual license costs of the RPA software. These can be one-time costs for a purchase of the software, or regular license costs. Not to be forgotten are the costs for ongoing support by the software provider and for new software releases. Depending on the type of costs, the license costs (or one-time costs for a software purchase) must be taken into account accordingly when creating the process-specific business cases. Expected Other Costs If further costs are incurred, they can be allocated to this category.

5.4  Selection of a Suitable RPA Solution

73

Software Components and their Operability In this category we examine which components the software contains and how easy the software is to use. The medium to long-term objective is to have the software maintained and operated by (internal) employees. The graphical user interface of the software is usually intuitive, making the software easy to use. Nevertheless, the different software varies here: While one software is designed for use by a non-IT-experienced business user, the other requires more extensive IT knowledge, but may offer considerably more possibilities (for more details on RPA technology, see Sect. 2.2). 

In practice, in case of doubt, the decision should be based on ease of use. The software providers are very quick in their further development, so that new— possibly difficult to program—features are usually made available quickly and are easily usable.

Support/Training In particular, the providers that have been established for years offer their own training programs, training opportunities and certifications. Examples include Automation Anywhere University and the UiPath RPA Academy. In the same way, many RPA consultants and implementation partners also offer trainings. In view of the subsequent transfer of responsibility to the line unit, this category should be given a great deal of attention. In addition, the approximate duration of the training can already be checked and compared here. Audit, Information and Compliance Security Audit, information and compliance security plays a particularly important role in the financial sector. Two issues are of interest in this category: 1. What experience does the provider have in considering audit-, information- and compliance-relevant aspects? 2. What options does the software offer for ensuring audit, information and compliance security? Extensive logging should be guaranteed. In addition to the recording of inputs by the application automated by the RPA software, which is usually available anyway, it is also important to record all activities of the RPA software itself. This guarantees complete traceability of all activities. In addition to RPA software-inherent loggings, individual loggings can of course also be created, which the RPA bot creates in any level of detail and in any format. The scope and level of detail should be agreed in advance with Revision and Compliance.

74

5  The Implementation of RPA

In practice, the question of a suitable storage location for the loggings often arises. This must be protected against changes. At the same time, however, data protection requirements must also be taken into account, at the latest when working with customer data. A joint exchange of information with all parties involved is beneficial here.

The providers of RPA software have already recognised the great demand for adequate security measures and some of them have the corresponding certifications—for example, certification according to the ISO/IEC 27,001 standard, which defines the requirements for information security management (see for example WorkFusion 2017). In later practical use of the RPA bots, more detailed questions may be relevant, for example: Do the RPA bots also work on locked screens, which are protected against unauthorised access from outside? These questions must also be answered as soon as possible. System Requirements and Integration Capability In this category it is checked whether the software allows both single workstation operation and server operation. The former is often used for the initial introduction of RPA in the organisation or for targeted support of employees at their workstations. Virtualised single workstation operation is also possible. Server operation is often easier to scale up and offers advantages in the control and monitoring of RPA bots, but requires more IT support. Integration capability describes the ability of the RPA software to interact with and operate the organisation's own applications. Here it is useful to already know which applications are to be used for further automation. 

Especially in the financial sector, the applications used, for example core banking systems, are often very strongly protected. An early access test (“connectivity test”), ideally before the final selection of the software, makes sense to avoid new selection processes later.

Special care is required if the organisation is using the Citrix environment or similar. If no other solutions are found here, the only remaining option is to operate the application by reading screen information. In this case, software with extensive screen-scraping capabilities is required (see also Sect. 2.2 for the disadvantages). Required Assistance Services Most providers are able to quantify the level of assistance required by the customer whose processes are to be automated. How extensive is the installation, what adjustments to the IT architecture are required, etc.

5.4  Selection of a Suitable RPA Solution



75

Experience has shown that a large part of the initial assistance for the installation of software, etc. is to be provided by the IT department.

This must be distinguished from the assistance for project implementation, process selection, process adaptation, bot design, etc. These do not depend on the software selection. Rather, they are determined by the project scope and distribution between internal and external project participants (see Sect. 5.2). Qualification of the Provider This category can include a wide range of criteria. How long has the provider been operating in the market, in which country is its headquarters located or which use cases of its software already exist in comparable companies or for comparable processes. Other experiences can also be queried here, for example in dealing with strict data protection requirements. 

Not all providers can demonstrate experience in Europe or in Germany. In many cases, there are only examples of applications from and in other countries and continents. Basically uncritical, but the financial industry especially in Germany and Europe is strongly regulated and requires high standards of the software it uses. The advantage of corresponding experience is therefore valuable.

Support of the Provider Processes are of varying degrees of importance. In the financial sector, for example, the execution of payment transactions is of absolute business relevance for a normal commercial bank. A failure of the processes must not occur under any circumstances. The greater the relevance of an automated process, the more important is reliable support for software problems. In this context, it is necessary to assess the support levels of the software vendor, whether support is on-shore, near-shore, or off-shore and, last but not least, in which language support is provided. Product Roadmap Since RPA is usually intended to be used in the own organisation on a long-term basis, planned further developments of the software or the development of additional components play an important role. These can be, for example, basic enhancements such as the addition of cognitive automation components, but also additions such as an OCR component (see also Chap. 9). Not Considered Here: Scalability During the software selection process, the question of software scalability, i.e. an increase in the number of bots, is repeatedly raised. The bots considered here (which, as described at the beginning, are not desktop bots) act independently, mostly controlled by

76

5  The Implementation of RPA

orchestrators, virtual control rooms, etc. (see also Sect. 2.2). Their number can therefore be increased quickly and easily. Scalability is therefore deliberately not listed here as a criterion. 

The larger and more important the planned implementation project, the more extensive the software selection process becomes. It should be checked whether independent, external support is already being used here.

5.5 Execution of a Proof of Technique (PoT) The so-called “PoT” is the technical verification of the RPA solution selected in the previous step. Alternatively, the two steps can be carried out in combination. In this way, different providers and the performance of the respective solution in interaction with the organisation's own systems can be compared ideally. The following aspects should definitely be examined within the PoT: • • • •

Installation of the software in the organisation's own systems Accessibility to target applications to be automated (Reading) ability of field contents Writability of the RPA software/operability of elements of the target applications

The following special features must also be observed: The installation of the RPA software should already take place in the IT infrastructure where the software will later be used. This can be virtual infrastructures, public or private cloud solutions, server-client structures or desktop environments. Appropriate preparation of the infrastructure required later also ensures rapid scalability after the software is introduced. This does not necessarily require a test installation in the production environment of the institute. If the environments or their infrastructure are structured in the same way, a PoT within the development or test environment also delivers valid results. It is recommended—as far as possible—to also examine the applications to be automated in the first process for connectivity with the RPA software. In this way it is avoided that a later change to an alternative software becomes necessary. Parallel operation of several alternative software packages is also unfavourable. This causes significant additional expenses due to different usability and the associated training requirements for employees, release cycles and IT infrastructure requirements.

5.6  Realisation of an Upstream Process Optimisation

77

5.6 Realisation of an Upstream Process Optimisation In a first important step, Sect. 2.4 has undertaken the basic classification of RPA within the process management framework. It is now necessary to deepen this by first of all clarifying the relevance of process optimisation in RPA projects. This is followed by detailed instructions for optimisation and final process documentation.

5.6.1 Process Optimisation in RPA Projects: Often Neglected, Despite High Relevance “We no longer need process optimisation, we now use RPA” This and similar statements are unfortunately still to be found when talking about RPA. The correct classification of automation technology, which is still quite new for the financial services sector, does not always succeed here. The question of whether RPA actually makes process optimisation in the financial services sector superfluous could be answered with a hasty yes. After all, RPA treats the symptoms of inefficient business processes that were previously countered with the familiar methods of process optimisation: Too long process runtimes, frequent media disruptions, the involvement of many people or a lack of a sense of responsibility—often due to function-oriented instead of process-oriented organisation. Process automation with RPA brings speed, cost and quality advantages, supposed “quick wins”. A closer look reveals that RPA is not yet able to reach its full potential. Superfluous process steps are not eliminated, but only automated and thus run through faster. The necessity of multiple data acquisition is not questioned. Instead of humans, bots create unnecessary amounts of data. Quality improvements are achieved, but this is simply a matter of avoiding errors in manual data processing rather than eliminating process inherent weaknesses. A real quality improvement of the processes, and thus the possibility of avoiding unnecessary test loops, often does not occur. If the processes remain complex and not standardised, this leads to accepted inefficiency and even to accepted errors in the processing by the bots. Exceptions increase and more data records are sent to employees. This in turn increases process time and costs. So in a first step, RPA only treats symptoms. However, it does not analyse and combat the causes of inefficient business processes. A closer look at the IT and organisation department of financial service providers reveals the causes of inefficient business processes: core processes of financial service providers run in software landscapes that are decades old. Historical and complex, often still based on outdated programming languages. This results in a multitude of interfaces and parallel data storage. Over the years, the number and complexity of business processes have also grown. Changing customer needs, increasing regulatory requirements and new products: Process-oriented thinking and stringent alignment with customer needs have often been neglected or are difficult to realise on this basis.

78

5  The Implementation of RPA

The combination of these two influencing factors has produced a large number of non-standardised processes that use different systems and tools and cost time, quality and ultimately money.

5.6.2 RPA Technical and Banking-Specific Process Adaptation Process Adaptation as a Necessary Preliminary Stage of Process Automation Business processes must therefore always be checked for efficiency and stringency and adjusted before automation. Only by this can the full potential of RPA be realised. The process adaptation—or optimisation—should take two perspectives into account: 1. The RPA technical perspective 2.. The banking perspective The objective of the RPA technical perspective is to adapt the process in such a way that a) the bot can handle as much of the process automatically as possible and b) the process run through the bot is as fast and efficient as possible. The objective of the banking perspective is to avoid unnecessary work steps. At the same time, all banking requirements must be adequately taken into account. These increasingly originate from legal and regulatory requirements, such as the German Banking Act, the German Fiscal Code or the Money Laundering Act. The two perspectives must not be viewed in isolation from each other. They are mutually dependent. A bank's technical process adaptation requires a subsequent RPA technical assessment of the adaptation—and vice versa. Thus, process optimisation in the context of RPA follows a kind of countercurrent procedure, which is sketched in Fig. 5.7.

Fig. 5.7  Countercurrent method for process adaptation

5.6  Realisation of an Upstream Process Optimisation

79

Example

The process of an account opening triggered online by the customer is not always automated. Although the customer enters his data in a web mask, they are not transferred 1:1 to the bank's core banking system. Some or most of the necessary steps are regularly carried out manually. These can be, for example, the legitimation of the customer, inquiries to the Schufa (German credit bureau) or the inquiry of tax details from the customer. From an RPA technical point of view, it would make sense not to carry out individual queries or wait for the customer's answers in order to be able to complete the process more quickly. From a banking point of view, however, the queries may be mandatory and must be executed. In this case, a shift of the process steps to the beginning or end of the process could be considered, or a change to the step itself—for example, dispense with the Customer's handwritten signature and replacement by an electronic version. ◄ This shows that RPA technical and banking adaptations can only be considered as interdependent. Procedure for Process Adaptation The process is adapted in four successive steps: 1. Analysis of the current process 2. Determination of the process requirements 3. Definition of the target process 4. Process realisation Analysis of the Current Process The first step is to analyse the current process. The focus should also be on technical details that are not considered relevant, for example from a technical point of view, but which may be significant from an RPA point of view. It is therefore advisable to involve employees—internal or external—with RPA know-how at this point. Determination of the Process Requirements In the second step, the requirements to be met by the process for automation are defined. These are the RPA technical and banking requirements described above. Normally it takes some time to determine the requirements, coordinate them with each other and decide on their implementation internally. A wide variety of specialist departments must be regularly involved. Ideally—and in the case of a project-specific RPA implementation—the final decision on possible process adjustments lies with the project team itself.

80

5  The Implementation of RPA

Definition of the Target Process In the third step, the future RPA process is defined as a target process. The definition is made outside all applications—on paper. Here, the previously established requirements are taken into account and planned accordingly. Once the process definition has been completed, quality assurance and acceptance are required—again from the point of view of RPA technology and banking. Important decisions can already be made at this stage which will influence the later operation of the bot. For example, the question often arises as to whether certain audit routines are incorporated into the new process or whether they are stored in separate auxiliary files. Example

When carrying out a current account change, it must be checked whether the change requested by the customer is permissible. For example, it is not possible for customers of full age to transfer their current account model to a free account model for children. Such verification routines can be complex. If they are integrated in the new process, any subsequent adaptation of possible account changes requires a complete adjustment of various process steps. If, on the other hand, the bot only passes through a single process step, which involves checking a table with an account change matrix, no process adjustment is necessary, even for later changes. In this case, only the file held outside the process is updated with little effort. ◄ Process Realisation In the last step the process adjustments are implemented and the target process becomes the new process. With a view to subsequent automation, documentation should now again be carried out down to the lowest process step level. The documentation created in the first step can be supplemented or modified accordingly. Full or Partial Automation In practice, it is often not possible to fully automate processes in their current form. For example, especially in customer dialogue within the financial industry, printouts often have to be made and then signed by the customer. This is an ideal example of a possible partial automation. The majority of the process is handled automatically by a bot. At individual points, humans then provide support in the execution of manual process steps. Another example of partial automation is activities that require control in the form of a prescribed dual control principle. Here, data input can either be done by the bot and the subsequent control by a human being or vice versa.

5.6  Realisation of an Upstream Process Optimisation

81

5.6.2 Process Documentation in Preparation for Artefact Development The process is documented both during the analysis of the current process and during the process realisation (see Sect. 5.6.2). Since every detail is decisive for the later development of the RPA artefact, documentation is recommended down to the lowest process step level—metaphorically speaking: “Every mouse click and every system input should be documented”. For this purpose it is advisable to use screen recording tools. Detailed documentation is not only required for process automation. It fulfils two further functions. On the one hand, it serves as a medium for the units accepting the process and for other testing units to verify the correct functionality of the developed RPA artefact. On the other hand, it serves as a kind of organisational instruction for the subsequent operation of the bot and can be changed continuously if necessary adjustments are made. Documentation Structure For a later artefact development a three-part documentation is recommended: 1. Overview page with all relevant information like a) Creation date b) Revisions/adjustments c) Creating unit/person d) Unit/person responsible for process e) Bot developer f) Further individual information, if necessary 2. Representation of the overall process with identification of the individual sub-processes 3. Single page per sub-process with a) Previously created screenshots at the lowest level of detail b) Illustration of the process in workflow diagram form c) Verbal description of the steps d) References to special features e) References to additional data to be used (for example, tables outside the application to be automated that the bot is supposed to use) “Desk test” Before the process documentation is used, a so-called “desk test” is performed. Here, a person who does not know the process to be automated performs this test exclusively on the basis of the process documentation. Intuitive entries or arbitrary decisions are not allowed. If the test is successful, the actual development of the artefact can be started on the basis of the documentation. If not, further detailing must be provided in the process documentation.

82

5  The Implementation of RPA

5.7 (Agile) Development of Artefacts With the completion of the process documentation, a process is now available that has been optimised from a banking perspective and prepared in terms of RPA technology and can therefore be automated. Since the process is already “developed”, we will continue to refer to the automated process as an “(RPA) artefact” in the following. Probably the most purposeful form is the agile development of the artefact. This is based on two arguments: 1. RPA is still a young technology. When it is introduced into the organisation, it is important to convince all those involved of its efficiency and benefits. This is all easier the faster the first results become visible. An agile approach enables precisely these rapid successes, as will be shown in the following. 2. The development of an artefact that can handle all cases of possible process runs is often not possible. In practice, there are always a small number of exceptional situations that make it necessary to direct the process to a human. Another part of exceptional situations can be processed by the bot, but has not yet been identified in the process documentation. Such cases usually occur in the course of development and make it necessary to adjust or extend the artefact while it is still in the development stage. The procedure is shown in Fig. 5.8. In a first step, the artefact is developed to such an extent that it already represents the complete process, but only in its simplest and currently executable form. At this point, the artefact can be described as “MVP—Minimal Viable Product”, a term frequently used in agile development.3 Figuratively speaking, only the main part of the process is depicted here at first, all secondary parts, exceptions or special situations are not considered. Simple side lines and exceptions are developed in a second step. The artefact gains in scope and already covers the majority of all occurring cases. In a third step, more complex secondary lines, exceptions and also rarely occurring special situations are developed. Splitting into Several Artefacts In some cases, it is useful to divide them into several small artefacts (instead of one large one). For example, it is useful to split complex processes or those with many different variants (graphically: “ramifications in the process tree”) into several artefacts. This reduces their complexity and increases the possibilities for quick artefact adjustments. A further advantage: Individual artefacts can be reused in other processes. An example of this is the user login. The bot logs in to the automated applications with its user ID

3The

term was created by Eric Ries (see Ries 2011).

5.7  (Agile) Development of Artefacts

83

Fig. 5.8  Agile development of the artefact

at least daily. Once an artefact has been created for this purpose, it can be used for other processes as often as desired. Agility, Scrum and Budgeting This basic approach consisting of three steps can be further refined. It is conceivable, for example, to further subdivide the individual steps—following the agile idea (see Schwaber and Sutherland 2017)—into more detailed sprints, provided the process to be automated is complex and the development takes a correspondingly long time. This results in an alternative budgeting approach for RPA projects. It is conceivable, for example, that development budgets could be provided separately for each sprint. Before each sprint—or at the end of each completed sprint—a decision is made as to whether the scope of the artefact is already sufficient, or whether development should continue and further side lines, exceptional cases and special situations should be developed. This allows the desired level of detail in the development to be controlled. This is particularly useful if exceptional cases are accepted from the outset and 100% automation is not a goal. This approach can contribute to security on the decision maker side and allow flexible control of RPA projects. Application Environment for the Development Even if no software is developed, some principles of software development should be taken into account during artefact development. A relevant aspect is the selection of the right application environment. This refers to the target application, for example, the application that will be served by the bot. Usually there is at least one test and one production environment. Ideally—and especially if they are in-house developments—there is also a development environment. In this environment, new software components are developed and tested by the developers. This is followed by a more extensive test—no longer by the developers themselves—in the test environment. After successful testing, the developed components are transferred to the production environment and used in real-life-operation (see also Sect. 2.2).

84

5  The Implementation of RPA

The development of an RPA artefact should be done in the development environment, or at least in the test environment. Here iterative development and testing can be carried out. Errors are not critical here, even if unintentional changes are made to data sets. After successful testing (see Sect. 5.8), the artefact can then be used in the production environment. There are exceptional cases in which a) either no development and test environments are available or b) these differ from the production environment in their administration or functional scope to such an extent that the development of the RPA artefact is impossible. In this case, development must take place in the production environment, otherwise the individual process steps would differ too much after a subsequent change of environment. If this is the case, extended precautions must be taken. This is recommended: • • • •

To restrict user permissions for bots and developers as much as possible To create complete loggings and to control them regularly and randomly To work exclusively with defined test data sets To install test loops that ensure that a process in the development stage can only access data records with certain characteristics (for example, “Test” as part of a customer name)

The organisation-specific requirements should be coordinated with auditing and information security management.

5.8 Test Design, Test Execution and Artefact Acceptance RPA and Application Development Experience has shown that the subject of “testing” is only taken into account (too) late in the project related to RPA. From our point of view, the reason for this lies in the role of RPA as a software solution “at the borderline between the purchase of unchanged thirdparty software and in-house development”. In the financial industry, there are extensive regulations that describe the handling and testing of self-developed software. One example is the banking supervisory requirements for IT (BAIT), which specify the minimum requirements for risk management (MaRisk) and devote an entire section to application development and the associated testing of developments (see BaFin 2018, pp. 13–16). Consequently, the question arises whether the development of an RPA artefact is to be understood as application development in the sense of BAIT. After all, no independent application is being developed here. Instead, an existing application is configured or individually adapted, which is much less complex. In conclusion, the question of how to classify the development of RPA artefacts can presumably only be answered when statements of supervisory authorities on this will be available in the following years (see also Sect. 7.4 on the regulatory framework for RPA). However, the answer to this question is not relevant for practice or for the procedure described below. Every financial institution

5.8  Test Design, Test Execution and Artefact Acceptance

85

using RPA technology has an interest in the correct functionality of the RPA artefacts developed. After all, this is the only way to ensure error-free process execution. And only full testing of the artefacts proves their full functionality and enables those responsible to release the RPA artefact for use in production. For this reason, it makes perfect sense to take the above-mentioned BAIT specifications (and of course the organisation's internal specifications) fully into account when testing application developments. Procedure for Testing Newly Developed RPA Artefacts Step 1: Creation of test concept The first step is to create a test concept. This describes the processes for test preparation, test execution, acceptance of the tested artefacts and for the final release. Deviating from our chronological chapter approach chosen here, the creation of the concept can and should take place very early in the project. Ideally, it is completed or at least largely completed before the artefact development begins. Background: If the test conception already specifies test loops during the (agile) artefact development, these should be taken into account at an early stage. Among other things, the test conception must specify: • • • •

who is running the tests, when these are carried out, the scope of the tests, who does the final acceptance and releases the artefact.

Step 2: Test execution The second step includes the actual test execution. Here, a distinction must first be made between developer tests and business tests.4 The tests dealt with here belong to the latter category. The developer tests are carried out continuously as part of the development of RPA artefacts (see Sect. 5.7). Although, a final technical test would suffice to approve the artefact development, several tests at different times are nevertheless useful. Figure 5.8 describes the three steps of artefact development. Ideally, a functional test is performed after each of the steps, followed by acceptance by the responsible employees. This allows errors and the need for adjustments to be identified early. In addition, the test effort is distributed over the course of the project.5 This procedure also corresponds to the chosen agile basic idea of artefact development. The question arises as to who should take on the function of the person responsible for the project and thus the “acceptor”.

4The

subdivision used here differs from the classic subdivision of test types in the field of software testing. However, based on the latter, the technical tests can also be regarded as integration tests, which results in the familiar sequence of developer/functional test, integration test and acceptance test (see Pilorget 2012). 5This requires, however, that artefact components that have been successfully tested once are no longer fully tested in the next iteration, but only regressively.

86

5  The Implementation of RPA

Table. 5.4  Contents of test documentation (based on BaFin 2018, p. 15) Content

Explanation

Test case description

Classification of the test case and description of its contents

Parameterisation of the test case

Necessary preparatory work for test case execution

Test data used

Naming of the test data used (for example, customer record number)

Expected test result

As specific and measurable as possible

Test result obtained

Explanation of the achieved test result with reference to the expected test result (was the test result achieved? With which detailed result? …)

Measures derived from tests

In particular in the negative case: Explanation of the measures taken to rectify the identified errors

The developer responsible for creating the RPA artefact should not be the acceptor for reasons of separation of functions. If a process owner already exists,6 then ideally he or she should take on the role of acceptor. Otherwise, it is advisable to have a person who is currently (technically) responsible for the process execution and who is responsible for the correct output. Often the client himself is one of these persons. The test execution—i.e. the individual test cases and their execution—must be adequately documented. For example, the points listed in Table 5.4 and defined in the BAIT can be taken into account (see BaFin 2018, p. 15). The number and scope of the required test cases must be determined individually and in particular in a risk-oriented manner.7 Step 3: Acceptance and release Acceptance and release as the third and thus final step determine the productive use of the developed artefact. As explained in the previous section, they should be carried out by the person responsible for the process. This person may have previously executed the tests themselves, or delegated the test execution. Additional acceptance tests can be defined for acceptance. Alternatively, it is also possible to use existing test cases from step 2. The data used makes the difference. While synthetically generated test data was still used in step 2, the acceptance test in step 3 is performed with real data (see Pilorget 2012, pp. 68–69). The release confirms that the developed artefact complies with the specifications of the process documentation (see Sect. 5.6.3) and is functional. This does not necessarily mean that 100% of the process runs must be executed correctly. Finally, exceptional cases can be deliberately controlled and further processed by humans. However, only the previously defined exceptional cases may occur. In all other cases, the process flow must 6See

on the roles in process management, for example Fischermanns (2015). a more in-depth introduction to the field of testing/test management, see for example Pilorget (2012).

7For

5.8  Test Design, Test Execution and Artefact Acceptance

87

be correctly handled by the bot—only then is the artefact fully functional. The release is documented sustainably, for example by email or signature. In addition, the artefact is stored in its released form and protected against unintentional or unnoticed changes. Afterwards, the productive use of the process can be started from a technical point of view. Testing During Operation Testing is necessary not only in the course of developing new artefacts. All changes to existing IT systems and applications can lead to errors in the execution of the artefacts. For this reason, tests of the RPA artefact should be carried out in the automated applications after each release—planned or unplanned. In this case regressive tests are sufficient—i.e. the repeated execution of previously (successfully) completed tests (see Pilorget 2012, pp. 69–70). These are less time-consuming, since no new creation of the entire test case is necessary. Section 5.10 deals once again in detail with the requirements of ongoing RPA operation. Success Factors in Testing Table 5.5 summarises the success factors of successful RPA testing and supplements these with individual, additional factors. Table 5.5  Success factors for RPA tests Success factor

Explanation

Orientation towards (regulatory) requirements

Even if the development of an RPA artefact is not an application development, it is advisable to orientate oneself to regulatory guidelines such as the BAIT and to use already existing, organisation-specific guidelines

Phase separation

Developer tests, technical tests (or integration tests) and acceptance tests must be carried out at different times and to the appropriate extent

Separation of functions The acceptance tests are not carried out by the developers Selection of the acceptor

The client or the person responsible for the process is suitable for the role of the acceptor

Performance of positive and negative tests

While positive tests examine that the process is being carried out correctly if the correct data are given, negative tests deliberately use incorrect data to check for—intentional—error messages or aborts (see Pilorget 2012, p. 69)

Performance of load tests

Bots work with a much higher speed on the systems than humans. The limiting factor is especially the reaction time of the automated applications. It is therefore necessary to simulate load situations—for example the simultaneous work of several bots in one application—and to identify and eliminate performance problems (see Pilorget 2012, p. 73)

No adjustments after acceptance

After an artefact is removed, it remains unchanged. Any later adaptation triggers a new test cycle, starting with the developer tests within the artefact development

88

5  The Implementation of RPA

5.9 Emergency Plans and Fallback Solutions The creation of emergency concepts and alternative solutions in the context of an initial implementation of RPA can actually only take place at this point in time, i.e. shortly before a rollout. If the project resources allow, the concept can of course also be created earlier in the course of the project. Definition of Terms The two terms “contingency plan” and “fallback solution” must first be clearly defined. This is to be understood as solutions that can compensate for the failure of one or more RPA bots. Thus, this does not refer to the previously defined and planned exceptional cases in process sequences that are still being processed by humans, but rather to the unplanned exceptional cases for which there is initially no procedurally specified solution. Example

A process in a bank stipulates that a customer signature is required in previously defined exceptional cases. For this purpose, the bot generates printouts that are then sent to the customer. This step is performed by employees of the bank. This is a planned exceptional case. ◄ Example

While the final tests of the newly developed RPA artefact are being carried out, an emergency release is installed in one of the automated applications. The RPA project team is not aware of this and does not take the necessary artefact-adjustments into account. Immediately after the start of the productive bot deployment, the bot generates error messages and does not finally execute a process. This is an unplanned exception. Until the problem is identified and resolved, workarounds that have already been defined in an emergency plan must be used. ◄ Procedure First, possible scenarios are defined and described. For example, a distinction can be made according to the number of failed bots. The source of the problem can also be used as a distinguishing feature—for example, problems in the artefact, the RPA software or the underlying IT infrastructure. In an intermediate step, prioritisation can now be carried out as required. Afterwards, alternative solutions for the scenarios can be created and documented. Such solutions usually include the transfer of process execution to employees in the relevant departments. However, it must be taken into account that these employees often have other areas of responsibility and have little or no capacity for the RPA exceptions. Appropriate planning is necessary.

5.10 Ensuring the Long-Term Operation of the RPA Solution

89

The creation of contingency plans and fallback solutions must not be omitted or given only minimal consideration. In an emergency scenario, employees must know the relevant processes, have the necessary authorisations, etc. Last but not least, regulatory requirements, such as the BAIT, which demand corresponding framework conditions and prerequisites for securing IT operations (see BaFin 2018), should also be referred to here.

5.10 Ensuring the Long-Term Operation of the RPA Solution Actually, the productive use of the automated process could already take place at this point. In practice, this also happens regularly. However, some preparations relevant for the long-term operation of the solution are neglected. Particularly, the technical support of the bots in operation, the release management and also the continuous and thus also sustainable documentation of the automated process and all changes made. Production Support Like any other application—for example the automated ones—the RPA software itself requires sufficient support during operation. This ensures that suddenly occurring errors can be analysed and corrected as soon as possible. If the bots actually work 24 h a day and possibly more than five working days a week, ensuring support can be challenging and must be planned accordingly. There are different estimates of the number of employees required per bot, usually ranging from around 0.1 to 0.3 per bot. This means that one person “manages” about three to ten bots. Willcocks and Lacity (2016, p. 145) use a case study to illustrate an example in which two employees control and “look after” around 300 bots. In other words, at peak times the two of them control the work of about 600 equivalent employees. The ratios are fundamentally dependent on a wide variety of factors, such as the know-how of the supervisors, the maturity level of RPA within the organisation or the complexity and stability of the automated processes. The production support staff should be trained and have sufficient knowledge of RPA to identify, analyse and resolve most technical problems that arise. This refers in particular to the technical part. Employees do not need to be process owners or have specialist knowledge of the automated process. Rather, they are available to assist those responsible in solving the problem. There are also different approaches for the organisational classification of production support. This is often seen in the IT area, sometimes in the organisational area and—rarely—in other areas, such as the business department. Section 6.3 deals in detail with the organisational classification. Release Management The biggest errors in the release management of RPA solutions result from insufficient consideration of the release cycles of automated applications. This is because not only the RPA software itself receives updates and patches at regular intervals; all automated

90

5  The Implementation of RPA

Fig. 5.9  Release roadmap RPA

applications do, too. This can result in an extensive “release roadmap”, as the example in Fig. 5.9 shows. The one-year release roadmap is a fictitious back-office process automated with RPA. The applications involved and thus automated are the core banking system, a ticket system, the bank's e-mail application and a CRM application. The RPA software itself receives one release p.a. The core banking system and the CRM system even two. The other two applications are one each. Added to this are possible emergency releases and patches that are not planned in advance. These are also shown in Fig. 5.9, but of course they cannot be planned in reality. Around the respective release dates, the horizontal time axis shows the time period in which the release preparations and followups as well as the actual implementation take place. It is quickly apparent that activities are required almost all year round. The first question that arises is why the RPA operation support is affected by the release of the core banking system, for example. This is ultimately dealt with by the application support of the core banking system itself. The special features are in the details. Even if no major changes are apparent to the human user, individual input fields or other details within the application often change. Simply moving input fields within an input mask is usually uncritical from the point of view of RPA, since today's bots generally no longer work via screen coordinates, but instead access the fields directly via their identification features. If, on the other hand, new fields are added—i.e. further entries have to be made—the RPA artefact must be adjusted. This process is comparable to training or at least informing employees about changes in the application. The bot must also be “trained” here by adapting the artefact accordingly. This does not necessarily have to be done by the employees involved in release management. However, they must inform the colleagues

5.10 Ensuring the Long-Term Operation of the RPA Solution

91

Fig. 5.10  Procedure model for the adaptation of RPA artefacts

responsible for the process about the upcoming changes. The latter, in turn, then take over the artefact adaptation. For this adaptation, the known procedure of process adaptation or optimisation, artefact development (or adaptation in this case) and subsequent testing with release must be used (see Sects. 5.6, 5.7 and 5.8). However, this procedure differs from the procedure for an RPA implementation described in Chap. 5 in that it no longer requires the creation of basic framework conditions, such as the creation of emergency concepts and fallback solutions. However, the latter—and also all other framework conditions—must be checked in the event of release-related changes to determine whether they are still valid or whether there is a need for adaptation. Figure 5.10 shows the procedure graphically. In contrast to Fig. 5.2, only the three marked steps are relevant here. These steps are repeated over and over again in a cycle. The task of release management is therefore mainly the checking of release announcements and their evaluation with regard to influencing automated processes. Technical knowledge is therefore required, but also (specialist) process knowledge. For this reason it makes sense to locate release management within the RPA unit (see Chap. 6). 

The complexity in Fig. 5.9 shows that it is advisable to create and maintain a separate release roadmap for each automated process. This is the only way to make early adjustments and avoid errors.

Documentation When a process is automated for the first time, an extensive process recording, adaptation and subsequent detailed documentation of the process takes place (see Sect. 5.6). Under no circumstances should this documentation be regarded as static. As described above, the process is subject to continuous changes. These do not always have to be

92

5  The Implementation of RPA

release- or patch-related. In the same way, requirements for process adaptation from the individual departments that use the processes may make such changes necessary. All adjustments to the automated process must be documented accordingly. The originally created process documentation should be used for this purpose and stored as a new, adapted version. This continuous (and as accurate as possible) documentation is necessary for several reasons: • The documentation serves the artefact development as a manual. • The documentation is the basis of the completely developed artefact and serves as a decisive comparison tool during testing and acceptance. • Deviations between the process flow of the bot and process documentation can lead to errors and (false) alarms in monitoring by compliance and auditing.

5.11 RPA Rollout The final step in the procedure described here for implementing an RPA process is the rollout of the RPA solution. This refers to the actual going live of the RPA artefact. The RPA software is licensed, the IT infrastructure is prepared, the processes to be automated have been prepared in terms of banking and technology, and all the basic conditions (emergency concepts, etc.) have been created. The RPA artefact has been developed, tested and accepted so that RPA can be started in productive use. The basic rule is: In the first few days, experience has shown that previously undiscovered errors occur or isolated unplanned exceptional situations occur. As a rule, these can be rectified quickly. Nevertheless, the bot operation should initially be closely monitored by those employees who can intervene professionally and technically and adapt the artefacts and bot configurations. Procedure for More Extensive RPA Rollouts The procedure shown so far is only suitable to a limited extent or no longer suitable if the complexity of the RPA rollout increases. The introduction of an automated process can be done quickly and easily, but only if few people are involved in the process, it is not very complex and/or is only rarely executed. This is usually not the case with RPA. RPA processes therefore have high volumes, which means that they are often executed. If the automated processes are in the back office or IT, for example, many employees come into contact with the bots and their workflows and results. It therefore makes sense to plan a more extensive RPA rollout in a structured manner and to define your own rollout strategy. RPA Rollout Strategy Such a strategy can, for example, define the following components (see also Hansmann et al. 2012, pp. 277–300):

5.11  RPA Rollout

93

1. Introduction sequence of contents, processes and structures 2. Implementation sequence of the automated processes themselves 3. Training concept 4. Communication concept 5. If required: personnel measures Of course, not all the contents outlined here need to be taken into account. Content and scope must always be made dependent on the concrete application. For example, the introduction sequence of contents, processes and structures only has to be distinguished if the structures need to be adapted at all due to the upstream process adjustments. In the same way, measures for personnel changes are not always necessary. Often teams remain in place for the time being, but their tasks change (usually towards more complex activities, while RPA supports the simple, rule-based activities). What needs to be considered in this context, however, is the integration of contingency plans and fallback solutions. The affected employees need to know how to a) interact with the bot during operation, e.g. when the bot is controlling process flows, and b) how to act in case of a RPA failure, i.e. within an emergency scenario. It is therefore advisable to incorporate the previously defined fallback solutions and emergency concepts and the resulting measures into the RPA rollout strategy. 1. Introduction sequence of contents, processes and structures One of the first steps is to examine how extensive the adjustments to processes, the content of the processes and associated structures induced by automation with RPA are. If only individual process parts are automated and these are even only slightly adapted for automation, only minor effects on contents and structures can be expected. As described at the beginning, automation with RPA usually has an impact on all three dimensions. If this is the case, the concrete procedure must be determined. Three alternatives can be distinguished. It is assumed that the introduction of new content should be carried out together with the introduction of new or adapted processes: 1. Start with the rollout of new content and processes and subsequent introduction of new structures. 2. Start with the creation of the new structures and subsequent rollout of content and processes. 3.. Parallel introduction of content, processes and structures. It makes little sense to roll out content and processes without first creating new structures. On the other hand, structure preparation and a subsequent rollout of new content and processes are possible—option 2. This procedure saves time for the people involved. At the same time, the risk of setbacks during the rollout is reduced, since the extra time is often accompanied by a lower risk of (careless) errors.

94

5  The Implementation of RPA

However, the extra time can also have negative effects. The duration of the RPA implementation and thus the project duration is often significantly extended. Option 3 avoids this, which saves time through parallelisation. In addition, an iterative check can be carried out during the rollout to determine whether the structure and process still fit together or whether re-adjustments are necessary. Example

As part of an RPA implementation in a bank, a back-office process previously outsourced to a service provider is reintegrated into the bank (insourcing). In the course of automation, extensive innovations are made to the process. This now allows simultaneous data acquisition in several systems, which was previously only done sporadically and successively. In addition, in the past no internal resources were required for process execution. All activities lay with the service provider. However, insourcing now requires personnel to take over the special cases that the bot (deliberately) should not process. Here, changes to content, the process itself and the structure are present. If a sequential approach were chosen, in which structures are only adapted last, i.e. appropriate employees are made available and integrated organisationally, there would be a risk that individual process runs could not be carried out. No preparations would be made for emergencies either. ◄ The example shows that in the context of RPA implementations, it almost always makes sense to introduce new structures and processes at the same time, or the structures must be in place before the rollout of the automated process—i.e. options 2 and 3 above. 2. Introduction sequence of the automated processes themselves The next step is to determine the implementation sequence of the automated processes. A distinction must be made here: Case 1: Several different processes are optimised and automated within an RPA implementation phase. Case 2: Only a single process is automated within the implementation phase, but it is introduced within several business units that are not directly connected to each other or at several locations. Example

An example of Case 2 is the introduction of a new RPA process for a back office service provider for banks distributed across several locations throughout Germany. The process as such is identical in its basic definition at all locations. However, the individual characteristics of each location lead to different ways in which employees deal with the new technology. ◄ Both cases differ in the number of processes, but not in the procedures possible for the rollout. There are two possibilities:

5.11  RPA Rollout

95

1. Piloted rollout 2. Simultaneous rollout With the first option, only one process is initially introduced (in case 1), or the one process is introduced only at a single one of several locations or in a single division (in case 2). The advantage here is the significant reduction in risk compared to a parallel rollout. If unexpected errors occur, it is still possible to react with usually little effort and little damage. In addition, learning effects from the pilots can be transferred to the subsequent rollouts. On the other hand, the total duration of the rollout is significantly longer. If more than two processes are involved, instead of a pilot, we can also speak of a basically sequential introduction, in which process by process is proceeded. A simultaneous rollout offers a significantly higher introduction speed. Cost saving effects can be realised as quickly as possible. However, this is at the expense of risk. Initial errors often have to be corrected at great expense. 3. Training concept Employees who work with automated processes, or are even responsible for maintaining the operation of the RPA processes themselves, need training. The deeper they need to get into the technology, the more extensive the training should be. It is therefore important to plan for appropriate training—the earlier the better. Once the rollout has taken place, it is usually already too late. Which form of training is the right one depends on the respective circumstances. In addition to the above-mentioned role of the respective employees, this also depends on the type of automated processes and, last but not least, on the risk level of a possible bot failure. For example, the failure of an automated core process is much more risky than the failure of a support process that is only rarely carried out. The employees who work with this core process or the RPA solutions used for it require correspondingly extensive training. For those who need to make independent adjustments to RPA artefacts and operate the bot, professional training by RPA trainers is recommended. Experience has shown that such training can be carried out within a relatively short time frame. 

About three to five days of training are sufficient to be able to operate common RPA software and thus “look after” the bots.

4. Communication concept In addition to training of the persons directly involved, all other parties involved in contact with the automated process and the RPA technology must also be fully informed. This will eliminate prejudices and possible resistance. Those affected can be all areas of the organisation, in the financial sector at least the works council, board of directors or management and, where appropriate, shareholders and supervisory bodies. Experience has shown that the prejudices and resistance often refer to a lack of information. Comprehensive and, above all, very early communication is helpful here.

96



5  The Implementation of RPA

Practice shows that comprehensive communication directly after the decision to implement RPA is useful and can eliminate possible resistance and rumours.

In principle, personal discussions, information events or information material are possible for communication. However, the most effective means of communication in the context of an RPA implementation is probably the live demonstration of a working bot. It has the potential to eliminate prejudices and possible fears. At the same time, a bot working on the various systems will convince you of the efficiency and quality that RPA technology inherits. Results of the Expert Interviews The expert interviews conducted confirm that one of the most important accompanying measures when introducing RPA is to “take along” the employees or the entire organisation. According to the experts, this should also include the gradual empowerment of the organisation to handle RPA.

5. Personnel measures RPA is not meant to replace staff. Rather, it provides the freedom to take on more complex activities, such as sales or value-added sales support activities. As has been shown time and again up to now, 100% automation is also almost impossible. Therefore, the personnel redeployments considered here only refer to changes in the scope of duties of the persons concerned. Such a change should be professionally accompanied. The process of “change management” is used for this purpose. This includes all planned, managed, organised and controlled changes in strategies and business processes as well as structures and cultures in companies (see Thom 1995, p. 870). One focus of the RPA rollout is clearly on information and communication towards the personnel. Changes in their own area of responsibility must be explained. Employees need accompanying material, such as new process documentation, instructions for action and, last but not least, advisory support in the first weeks and months after implementing the change. Checklist: Rollout Capability Table 5.6 contains a checklist for examining the rollout capability of the RPA solution. Results of the Expert Interviews The procedure described here assumes a successive rollout of “completed” RPA artefacts. A conceivable alternative would be a release-like rollout. This would mean that RPA artefacts would be developed and accepted within a defined period of time and then collected, for example at two points in the year, and transferred to production operation. The experts consulted on this issue are clearly against such a procedure. The reasons for this are different. One of the most important arguments against a release-like procedure is the risks that arise from it. For example, it is much easier to fix a single

References

97

Table 5.6  Checklist RPA Rollout To examine

Done yes/no

Overall RPA strategy defined and communicable Process to be automated prepared for bot operation RPA artefact developed and tested RPA artefact ready for go-live RPA software prepared for productive operation and installed in the production system Drives prepared for file storage etc User IDs for Bot available Contingency plans and alternative solutions prepared Technical support, in particular for the start-up phase of RPA operation ensured Rollout strategy defined and communicable Employees informed, trained and prepared

automated process that has been taken over into production and may contain errors than to fix a large number of them at the same time.

References Allweyer T (2016) Robotic Process Automation – Neue Perspektiven für die Prozessautomatisierung. Working Paper Fachbereich Informatik und Mikrosystemtechnik Hochschule Kaiserslautern. https://www.kurze-prozesse.de/blog/wp-content/uploads/2016/11/Neue-Perspektiven-durchRobotic-Process-Automation.pdf. Accessed 27 Dez 2018 Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) (2018) Rundschreiben 10/2017 (BA) in der Fassung vom 14.09.2018, Bankaufsichtliche Anforderungen an die IT (BAIT). https://www. bafin.de/SharedDocs/Downloads/DE/Rundschreiben/dl_rs_1710_ba_BAIT.html. Accessed: 23 Dez 2018 Fischermanns G (2015) Praxishandbuch Prozessmanagement. Schmidt, Gießen Hansmann H, Laske M, Luxem R (2012) Einführung der Prozesse – Prozess-Roll-out. In: Becker J, Kugeler M, Rosemann M (Hrsg) Prozessmanagement. Springer Gabler, Wiesbaden Lacity M, Willcocks L (2016) Robotic process automation at telefónica O2. MIS Q Exec 15(1):21–35 Meyer H, Reher H-J (2016) Projektmanagement. Von der Definition über die Projektplanung zum erfolgreichen Abschluss. Springer Gabler, Berlin, S 277–300 Murdoch R (2018) Robotic process automation. Guide to building software robots, automate repetitive tasks & become an RPA consultant. Eigenverlag Pilorget L (2012) Testen von Informationssystemen. Vieweg + Teubner, Wiesbaden Porter-Roth B (2002) Request for proposal: a guide to effective RFP development. AddisonWesley, Boston Ries E (2011) Lean startup. Penguin, London

98

5  The Implementation of RPA

Schwaber K, Sutherland J (2017) The Srum guide. https://www.scrumguides.org/index.html. Accessed 9 Dez 2018 Thom N (1995) Change management. In: Corsten H, Reiß M (Hrsg) Handbuch Unternehmensführung. Springer Gabler, Wiesbaden, S 869–879 Willcocks L, Lacity M (2016) Service automation. Steve Brooks Publishing, Warwickshire, Robots and the future of work Willcocks L, Lacity M, Craig A (2017) Robotic process automation: strategic transformation lever for global business services? J Inf Technol Teach Cases 7:17–28 WorkFusion (2017) WorkFusion takes the lead as most secure RPA provider in automation space, announcing ISO 27001 compliance certificate and CyberArk partnership. https://www.workfusion.com/news/workfusion-takes-the-lead-as-most-secure-rpa-provider-in-automation-spaceannouncing-iso-27001-compliance-certificate-and-cyberark-partnership/. Accessed 18 Nov 2019

6

Introduction of RPA Governance

Abstract

The following chapter deals with RPA governance and its implementation within an organisation. RPA governance should be one of the key aspects of any RPA implementation. At least if several processes are to be permanently automated and crossdepartmental RPA use is planned. The chapter first clarifies the importance of RPA governance and distinguishes it from (general) IT governance. It then explains the specific components of RPA governance and possible procedures for introducing and establishing RPA governance in the organisation. One focus is the introduction of socalled RPA units. Both roles and tasks are defined within this framework. The final section is a discussion of RPA governance, RPA unit and the concept of the so-called Center of Excellence, which is often used in practice in connection with RPA.

6.1 Need for RPA Governance Example

A financial institution started using RPA in-house about a year ago. The IT department recognised the potential of the automation solution, acquired its own software licenses and began to automate individual processes in various departments. At the same time, individual departments also acquired licenses and tested RPA for their own purposes. In the meantime, more than 30 processes or activities have been automated. What is missing: The responsibility for RPA in the institute is not regulated. Each department acts on its own responsibility. This leads to the fact that:

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 M. Smeets et al., Robotic Process Automation (RPA) in the Financial Sector, https://doi.org/10.1007/978-3-658-32974-7_6

99

100

6  Introduction of RPA Governance

• • • •

no uniform license management exists, neither a regulated knowledge build-up nor a knowledge transfer takes place, no uniform procedure is defined for process automation, there is no operational management including production support and release management and • there is no overview of the economic success of the automations. This means that potential for synergy and learning effects are not exploited. In the end, the use of RPA is not efficient and also only partially effective, since it can be assumed that, for example, cost saving potentials are not even identified due to the lack of a standardised procedure. ◄ This example illustrates the importance of RPA governance. This is the only way to fully achieve the (strategic) objectives of in-house RPA use. In summary, the main reasons— and objectives—for establishing RPA governance are as follows: • Ensure clear responsibility for organisation-wide deployment of RPA in a single unit, thereby increasing efficiency. • Creation of uniform guidelines for the implementation and automation of RPA. • Centralised securing and transfer of knowledge and experience regarding the use of RPA technology. Results of the expert interviews One result of the expert interviews conducted is that the focus—especially in the case of first-time implementations—is less on creating RPA governance. Rather, the focus here is on the rapid generation of successes in order to achieve a short time-to-market and to counteract possible internal reservations about RPA. Accordingly, although individual specifications and procedures are defined from the outset, comprehensive guidelines (e.g. in the form of concepts) only follow in the course of subsequent implementations.

The need for governance also becomes clear when RPA is compared with other (automation) technologies. Thus, the creation of a corresponding governance is also recommended for the long-term use of BPM (see Kirchmer 2017, p. 81–100). This is always necessary if BPM is to be used on a permanent basis and not just once—for example, as part of an optimisation project. Participants in the study conducted by Ostrowicz (2018, p. 9) cite the lack of understanding the need for an anchoring of RPA in the organisation's own operating model as the second biggest challenge in the long-term and successful implementation of RPA. Only the complete integration of RPA into all processes, systems or even work and shift plans—and ultimately the establishment of RPA governance—will ensure the long-term success of RPA.

6.2  Contents and Steps to Establish RPA Governance

101

Differentiation from IT governance The RPA governance considered here should not be confused with IT governance, which is generally established in all financial institutions. Nevertheless, there are interactions between the two. For example, an RPA implementation must always be carried out in accordance with the existing IT governance. The latter can, for example, provide for how the IT infrastructure can be prepared for an RPA deployment or how processes must be optimised—before automation. This again highlights the need for IT support in the implementation of RPA. This is the only way to ensure that the regulations and framework conditions of IT governance are also taken into account (see also Lacity and Willcocks 2016, p. 24, 28).

6.2 Contents and Steps to Establish RPA Governance The first step is to determine what the objective of RPA governance should be. To do this, it is a good idea to look at one of the related technologies or methods, which also has one of its many focal points in process automation: BPM.1 The main objective of BPM Governance can be easily transferred to the objective of RPA Governance and will be used as such in the following: The creation of framework conditions for the successful, sustainable anchoring of the technology within the organisation in order to achieve the strategically set goals and create value for the company, its owners, employees and other stakeholders (see Kirchmer 2017, p. 83). Components of RPA governance In order to establish full RPA governance, it is necessary to define the elements that it must necessarily contain or take into account. The most relevant elements are then explained in detail. Kirchmer (2017, p. 83) lists various components of BPM Governance, some of which can also be transferred to RPA Governance, see Table 6.1. Not all elements need necessarily be considered and anchored in individual RPA governance. For example, it can make sense to dispense with RPA governance as far as possible when using RPA only once. The situation is different in the case of expected large-scale use. In this case, a large part of the above-mentioned elements should be taken into account. Additional content can be defined at any time. The components of RPA governance listed in Table 6.1 are explained in more detail below. Strategic definition of the objectives of RPA deployment in line with corporate objectives As explained in Sect. 2.3, RPA technology should be strategically targeted before deployment. This means that in particular the strategic objectives to be pursued with

1See

also Sect. 2.4.

102

6  Introduction of RPA Governance

Table 6.1  Components of BPM Governance and their transfer to RPA Governance. (based on Kirchmer 2017, p. 83) BPM Governance component

Transfer to RPA Governance

Clarity with regard to the overriding corporate goals for the definition of key figures for a control system

Strategic definition of the objectives of RPA; in line with the company's objectives

Identification of the core processes of the company

Identification, evaluation and prioritisation of processes that can be automated

Responsibilities, guidelines and competencies for the management of (business) processes

Responsibilities, guidelines and competencies for the management of automated processes and bots

Process related knowledge management

RPA-related knowledge management

Recognition and reward systems

Recognition and reward systems

Ensuring a continuous improvement process

Creation and subsequent assurance of an RPArelated continuous improvement process

the use of the technology are clearly defined and additionally prioritised. The objectives should of course be in line with the overall strategic business objectives. Example

A company in the financial sector uses the Balanced Scorecard as a system of key figures and for defining corporate goals. An explicit goal is the reduction of costs. Accordingly, it can be deduced from this that the use of RPA should in particular pursue the strategic goal of cost reduction (see Sect. 2.3). Another company prioritises customer satisfaction in its Balanced Scorecard. This satisfaction is particularly evident when customer concerns are served quickly, i.e. when processes are run through quickly. With regard to the use of RPA, it can be deduced from this that the reduction of process runtimes should be used as a strategic goal. ◄ These two examples illustrate the dependence of the strategic objectives of RPA deployment on the overall corporate objectives. Deviations are of course possible. This is particularly true if the company uses RPA only in individual business areas. For example, the strategic goals of using RPA in the back office area of a bank may be to reduce costs and process runtimes. At the same time, the bank uses RPA within the internal reporting of the overall bank management. Here, the focus is less on cost reduction and more on improving quality by eliminating human error. Figure 6.1 illustrates this correlation.

6.2  Contents and Steps to Establish RPA Governance

103

Fig. 6.1  Factors influencing the RPA strategy

Identification, evaluation and prioritisation of automatable processes If RPA is used in different departments of a company, this can lead to inefficiencies. Different people with different knowledge, experience and objectives often go through the RPA implementation process in different ways. To avoid this, RPA governance defines a clear procedure for identifying, assessing and prioritising the processes to be automated. It specifies individual steps, tools and responsibilities. In concrete terms, this means that the tools and techniques described in Chap. 5 are specified centrally by RPAGovernance and developed further as required. 

Regardless of the department using RPA, the approach of the parties involved should always be the same. This will help to avoid inefficiencies and mistakes, while at the same time learning and synergy effects can be achieved.

Responsibilities, guidelines and competencies for the management of automated processes and bots RPA governance first defines responsibilities. These are for example responsibilities for… • • • • • •

…the decision whether and where to use RPA. …the selection of the RPA software used throughout the company or division. …the selection of processes to be automated. …the decision about possible process adjustments within the scope of automation. …development, testing and acceptance of RPA artefacts. …the entire operation and further development of RPA.

Business and IT concepts are defined for this purpose. In addition, organisational manuals and technical instructions can be created. Appropriate competencies are required to fulfil the responsibilities defined in these manuals. As a rule, these are assigned by the management level. As in other areas, this allocation of competencies must not be neglected under any circumstances. Without the appropriate competencies, those responsible for RPA have no or only very limited capacity to act, as the following example shows.

104

6  Introduction of RPA Governance

Example

The RPA manager of a regionally active bank wants to automate a process within the bank's accounting department with RPA. In the future, bots will check the invoices submitted electronically by service providers for completeness, compare them with internal entries and transfer the invoice amount. Process adjustments are required for automation. Among other things, individual verification steps are to be eliminated, as manual input errors will be ruled out in future. The previous employee responsible for the process had a bad feeling when the verification steps were omitted and therefore refused these adjustments. If the person responsible for the RPA lacks the appropriate competencies, automation fails at this point. If, on the other hand, he has been given these competencies beforehand, which, for example, would allow him to decide on such process adjustments on his own, he could make the adjustments—but of course still in coordination with specialist departments and control bodies such as compliance—and successfully automate the process. ◄ Although the term RPA manager is used here, a more precise definition has not yet been given. This is also not trivial. Sect. 6.3 therefore deals with this in detail. RPA-related knowledge management If RPA is to be used permanently, comprehensive knowledge management is essential. Knowledge must be created and made available to all parties involved. Knowledge creation While most organisations in the financial industry have extensive process management knowledge, RPA is a new component of this subject area. In practice, knowledge about RPA is generated almost exclusively through active involvement with RPA. This is supported by external consultants who provide, guide and support new knowledge. If the organisation decides for permanent external support, the knowledge build-up around RPA can be less intensive than if only initial, but not subsequent implementations are to be carried out with external support. Summarized, the required level of knowledge creation should be determined at the very beginning of the work with RPA. Subsequently, knowledge transfer from external to internal, such as RPA training, must be organised at an early stage. Knowledge transfer In the case of an initial implementation of RPA, only the project participants will initially come into contact with RPA. Then others follow, such as the departments whose processes are automated. The project participants in particular have the opportunity to build up extensive knowledge in the area of RPA. Ideally, they should be required to ensure the internal transfer of knowledge.

6.2  Contents and Steps to Establish RPA Governance

105

This can be done in different ways. Information events can take place, multipliers can be used, training courses can be held or knowledge databases can be created. Which personnel groups are involved as recipients of these knowledge transfers and to what extent, is to be decided on a case-by-case basis. In principle, however, the more employees acquire knowledge about the RPA, the greater the acceptance of the technology and the greater the probability that employees will discover automation potential themselves and draw the attention of RPA managers. Recognition and reward systems Recognition and reward schemes are not a mandatory part of RPA governance. Nevertheless, they can provide an option to reward employees for proactive involvement in the search for automation potential. For example, successful process automation based on the advice of individuals can be rewarded with appropriate cash or non-cash bonuses—or other bonus components. Creation and subsequent assurance of an RPA-related continuous improvement process The continuous improvement process, or subsequently also the continuous process optimisation, is a core component of every successful process management. It includes measurement, diagnosis and control activities with the aim of achieving a continuous improvement of existing processes. It is based primarily on process indicators (see Fischermanns 2015, p. 468). This continuous process optimisation is also required for automated processes. As in any other process, there are changes over time in input, desired output, process participants and other basic conditions. These are not always communicated in an obvious or transparent way. Previously defined process key figures can help here and draw attention to changes. If there are deviations from an initially defined starting level, appropriate diagnoses can be made, followed by any necessary measures. Examples of such process indicators, which can also be used in particular for automated processes, are (see in parts also Fischermanns 2015, p. 469): • • • • • •

Process runtimes Legal costs Process quality Number of process runs Customer satisfaction Error rates of the bots

The process key figures must always be adapted to the individual strategic objectives of RPA. For example, it makes little sense to use process costs as a key figure if the strategic goal is exclusively quality improvement through additionally created, automated test loops.

106

6  Introduction of RPA Governance

Timing options for the introduction of RPA governance In a first step, the components and contents that RPA governance deals with were explained. In the following, two ways of creating RPA governance over time are compared. The time schedule corresponds to the course of RPA implementation as described in Chap. 5. 1. Immediate introduction of RPA governance In the first case, comprehensive RPA governance is already introduced during initial implementation. As explained above, this is always appropriate where the long-term and widespread use of RPA is expected. In this case, the required content is first defined and then planned. In Fig. 5.2, this procedure corresponds to a long-term accompanying introduction of governance from steps 1 to 8. 2. Downstream implementation of RPA governance In contrast to the previous case, RPA governance is introduced at a certain point in time during the RPA implementation or even completely afterwards. This can be useful if there are insufficient resources available during RPA implementation or if necessary decisions can only be made downstream. However, there are risks associated with this approach. For example, it can lead to the fact that the deployment of RPA is not consistently aligned with the strategic objectives. In the same way, there may be restrictions in the transfer of knowledge; both the transfer of knowledge from external to internal and purely internal may be affected. In particular, the lack of concepts and guidelines to be created by governance, which are already required during the initial implementation phase, has usually negative impacts over time.

6.3 RPA Units and Their Organisational Classification An essential component of RPA governance is the definition of responsibilities, guidelines and competencies for the management of automated processes and bots, as already mentioned in Table 6.1. The focus here is on the question: Who takes care of which necessary parts of successful and sustainable RPA operation? The latter also means here the implementation of new automated processes. In the following, a distinction is first made between three different approaches to organisational classification. For various reasons, which will be explained later, the centralised approach is particularly suitable at the beginning of an RPA journey. This is therefore examined in detail. Three approaches to the organisational classification of RPA When talking about the organisational classification of RPA, this means the design of responsibilities and competencies and their distribution within the company's organisational structure. Again, the classification of BPM and the associated BPM governance

6.3  RPA Units and Their Organisational Classification

107

Fig. 6.2  Approaches to the classification of RPA governance

can be referenced as an example (see Kirchmer 2017, pp. 95–99). It offers the following three possibilities for organisational classification: 1. Centralised approach 2. Decentralised approach 3. Hybrid approach Figure 6.2 presents the three approaches and shows their differences, which are explained below. 1 Centralised approach RPA unit and its tasks In the centralised approach, all responsibilities and competencies are bundled in a central unit. This unit is responsible for the implementation of the elements of RPA governance listed in Sect. 6.2 and is hereinafter referred to as the RPA unit.2 The term “RPA unit” is deliberately different from the term “RPA team”, which is used for example in Sect. 5.2. It refers to the unit responsible for RPA within the line. This means that the members of the RPA unit need appropriate competences to perform their tasks. In addition, the RPA unit can perform different tasks in the context of permanent, organisationwide RPA deployment. This includes ensuring the ongoing operation of RPA and, for example, the continuous automation of other processes. The possible tasks are listed in Table 6.2 and in some places also include the basic components listed in Sect. 6.2. They can be changed, reduced or extended—depending on the individual company. Not all of

2Another

common term is the “Center of Excellence”. This will also be described below and separated from the RPA unit.

108

6  Introduction of RPA Governance

Table 6.2  Tasks of an RPA unit Task

Explanation

Process identification

Technical identification of processes that can be automated and business assessment/prioritisation (see Sect. 5.3)

Process recording

Recording of the processes to be automated and documentation (see Sect. 5.6)

Process adjustment

Process optimisation with regard to (RPA) technical and functional adaptations (see Sect. 5.6)

RPA artefact development

Design and technical development of RPA artefacts (see Sect. 5.7)

RPA test

Test of the developed artefacts (see Sect. 5.8)

Release RPA artefact

Final release of the artefacts, also after adjustments during operation (see Sect. 5.8)

(Daily) RPA operation

Ensuring the entire ongoing RPA operation (see Sect. 5.10) as well as the availability of and compliance with emergency concepts and fallback solutions (see Sect. 5.9)

RPA controlling

Permanent monitoring, control and optimisation of the RPA operation—closely linked to the RPA-related continuous improvement process

Ongoing, RPA-related process Identification of potential for improvement within already automanagement mated processes. Also closely related to the RPA-related continuous improvement process Error handling

Identification of error causes in processes executed by the bot and their correction

Release management

Ensure that all release cycles are taken into account (see Sect. 5.10)

Securing/further development Maintenance of the RPA infrastructure with the aim of ensuring of RPA infrastructure permanent availability. Additional further development, which is particularly necessary in the context of scaling RPA Control RPA-Unit

Technical and/or disciplinary control of the RPA unit and its employees themselves

Communication in the organisation

Planning and implementation of all communication, information and training activities related to RPA (see 6.2)

the tasks listed need to be performed by the RPA unit itself, as will be shown below. However, it makes sense to keep at least the final responsibility for the listed tasks within the RPA unit. 

The superordinate and combined task of an RPA unit is to identify, prioritise and implement automation potential (see Willcocks and Lacity 2016, p. 133).

6.3  RPA Units and Their Organisational Classification

109

Roles within the RPA unit Now, it is necessary to define which roles are needed to perform the tasks in a meaningful way. The following division of roles is recommended: RPA Manager The RPA manager manages and controls the RPA unit. The RPA manager has overall responsibility for the operation of RPA within the organisation. He also ensures that the technology is widely known within the organisation and that RPA use is extended to other parts of the organisation. RPA Business Analyst Ideally, the RPA business analyst has extensive knowledge and experience in process management and RPA technology. This role thus forms the interface between the business departments and the RPA unit. The business analyst defines process flows and process optimisations. He works closely with the RPA developer. He differs from the typical business analyst, whose task is usually exclusively to create interfaces between the business and IT departments, in particular through the ongoing search for further automation potential (see Willcocks and Lacity 2016, p. 75). RPA Developer The RPA developer has mastered the technical development of RPA artefacts and their testing. The role requires a correspondingly high level of IT understanding. The RPA developer works hand in hand with the RPA business analyst. Strictly speaking, the following applies: Compared to the other understanding of an (IT) developer, the RPA developer does not develop, but configures (see Willcocks and Lacity 2016, p. 74)3 RPA Controller The requirements for the role of the RPA controller are similar to those of other controlling roles in the financial industry. In addition, there is a corresponding understanding of the RPA technology. The RPA controller manages, controls, and monitors the operation of RPA. In doing so, the controller ensures continuous development and improvement of the internal use of RPA. The roles listed up to this point usually represent a reasonable minimum to be able to handle all tasks in the RPA environment (minimum version). However, not all roles are always required. Individual roles can sometimes take on tasks that were not originally intended for them. For example, the RPA Manager can also take over RPA controlling, which would make the role of RPA controller obsolete. The number of employees who occupy the roles depends largely on the number of automated processes.

3For

the sake of clarity, we will nevertheless speak here of a development activity with regard to RPA artefacts, not of a configuration.

110



6  Introduction of RPA Governance

The greater the planned or existing spread of RPA within the organisation, the larger the RPA unit should be—i.e. the more staff capacity should be available for it.

In addition to the roles defined here, other roles are regularly found. However, these are usually only a more detailed differentiation of the roles listed above. These additional roles could be the following, for example (see UiPath 2019): RPA Sponsor The RPA sponsor ensures the (organisation-wide) establishment of RPA as an automation solution. The role creates the strategic framework and ensures that the necessary resources and budgets are made available. RPA Change Manager The RPA change manager takes care of the monitoring of changes in the employees’ area of responsibility. Through intensive communication at all levels he or she keeps all stakeholders informed and ideally ensures a positive attitude towards RPA across all departments. RPA Solution Architect The RPA solution architect is responsible for defining and supporting the (IT) infrastructure required for RPA deployment. He or she also ensures that the RPA infrastructure is oriented to all organisation-specific architecture guidelines. RPA Infrastructure Engineer The RPA infrastructure engineer is more operational than the RPA solution architect. The engineer ensures permanent support for the RPA infrastructure and takes care of installations of RPA software and related activities. RPA Service Support If queries arise during the operation of RPA, e.g. from the business departments, or if errors occur during operation, the RPA service support team is the first point of contact and takes care of error analysis and solution creation. Figure 6.3 shows all the roles of an RPA unit graphically. It also shows which of the last defined additional roles are included in which of the roles defined above in the minimum version. In the latter, the RPA manager also assumes the role of RPA change manager—in one person. Distribution of tasks and interfaces to the department Some relevant tasks of the RPA unit and its stakeholders have already been mentioned in the context of the definition of roles. These are discussed in detail below.

6.3  RPA Units and Their Organisational Classification

111

Fig. 6.3  Roles of an RPA Unit

An exemplary task distribution of the previously defined roles is shown in Fig. 6.4. In addition to the roles listed above within the RPA unit, the business department is also shown. This shows the interfaces between the RPA unit and the other departments or units—as well as the interaction between the two units. It has proven to be a good idea to involve the specialist department in the identification of automation potential. This can be done either by proactive suggestions regarding processes to be automated from the business unit itself, or by interviews and workshops within the business units conducted by the RPA business analyst. Ideally, the final release of RPA artefacts should also be carried out by the business department, as it is this department that knows the processes best from a business perspective and can judge whether the bots generate the same process output as humans do. Results of the expert interviews Dr. Sandro Schurig [Head of Business Services at DekaBank]: In DekaBank's Customer Services department, the identification of processes that offer potential for automation is carried out by

Fig. 6.4  Exemplary task distribution of an RPA unit

112

6  Introduction of RPA Governance

the employees of the division itself. Their suggestions are collected, evaluated by a coordinator, prioritised where necessary and then forwarded for automation. The necessary click instructions for developing the respective RPA artefact are also prepared by the employees of the Customer Services department. The development of the RPA artefacts is then carried out centrally by an RPA team in the IT department of DekaBank. The artefacts developed there are returned to the specialist department and, following final testing and any necessary adjustments, are transferred to productive operation. The chosen procedure illustrates the multiple interfaces between the business department and the RPA unit (here in the form of the RPA responsible IT department).

Further interfaces are found in daily RPA operation and error handling. For daily operation it can be decided individually whether the department controls the bots itself or whether this task remains within the RPA unit. The latter may mean that more resources have to be kept available in the RPA unit in order to guarantee operation at all times. In error handling, a distinction must be made between the types of errors involved. If there is a technical error, for example, in the form of a non-permitted specification to the bot within a process run, the business unit is the focus of error identification and correction. If, on the other hand, it is an error in the programming of the RPA software or in the software itself, the RPA business analyst is initially responsible and can call in other members of the RPA unit if necessary. Possible approach when using a large number of bots If the number of bots operating in parallel increases and if the responsibility for their operation is to remain centralised, an additional expansion of the RPA unit would be appropriate. Willcocks and Lacity (2016, pp. 143–144) propose here to split the RPA unit into two teams. The first team is responsible for the implementation of (new) process automation, i.e. develops new artefacts. The second team ensures the operation of the bots. This includes the rollout of the artefacts completed by the first team. In addition, the second team forms the interface to the departments. Any change requests received from there are evaluated, processed and passed on to the first team for artifact development, as well as any further automation potential that the first team identifies itself on an ongoing basis. Integration of the RPA unit within the organisational structure If the centralised approach is chosen, the next step immediately raises the question of integration within the organisational structure. Basically, two options are possible here: 1. Assignment to IT and/or organisation department 2. Assignment to another department The assessment of the interviewed experts, but also the experience from various organisational implementations of RPA speaks in favour for an assignment to IT and/or organisation department.

6.3  RPA Units and Their Organisational Classification

113

Results of the expert interviews According to the experts interviewed, the RPA unit should be centralised either within the IT or organisational area. Under no circumstances, however, should it be located within one of the other departments. This is the only way to pursue a cross-functional, organisation-wide RPA approach. In addition, IT and organisation generally have the most comprehensive knowledge of processes and process management. Many of the processes that can be automated can be found in the specialist departments. Appropriate (human) interfaces must therefore be ensured. In particular, a standardised procedure (for example, by providing a tool solution) can support the departments in the initial process identification. According to some estimates, it is not always possible to suggest processes from one's own department for automation or to automate them oneself. Here too, an RPA unit that is not assigned to the specialist department can help to promote RPA within the organisation.

Figure 6.5 shows a corresponding exemplary implementation of the centralised approach—based on the assignment of the unit to the organisation department. Here the RPA unit is shown in a classical, hierarchical or functional type of organisation. The RPA manager is also the team leader of the entire RPA unit. In the example, he or she reports to the organisational area manager. Of course, you can also choose other approaches to the organisational structure of the RPA unit. For example, it can take all forms, from a purely functional to a completely process-oriented organisation (see for example Kirchmer and Hofmann 2013, p. 85). However, it should be kept in mind that the organisational form of an individual unit is generally based on the organisational form of the company as a whole. Experience shows that a completely process-oriented organisation of an individual unit in a functionally organised company is rarely found. The great advantages of a centralised solution are the high scalability and the great efficiency gains (and cost reductions) by creating uniform standards. A major disadvantage, which is repeatedly observed in practice, is the creation of a possible bottleneck

Fig. 6.5  Exemplary implementation of the centralised approach

114

6  Introduction of RPA Governance

factor, since all processes and decisions are the responsibility of the centralised RPA unit (see Deloitte 2017, p. 13). Size of the RPA unit The size of an RPA unit—in the form of the number of its team members—depends on the size of the RPA user's company on the one hand, but also of course on the number and scope of automated processes and bots operated. A consulting firm cites the following sizes of RPA units4 of 22 customers (see Deloitte 2017, p. 12):4 • • • • •

six clients have an RPA unit with one to five employees seven clients have an RPA unit with six to ten employees five clients have an RPA unit with 11 to 24 employees two customers have an RPA unit with 25 to 49 employees two customers have an RPA unit with more than 50 employees

Following the roles outlined here, the RPA unit, comprising the RPA manager, the RPA business analyst and the RPA developer, consists of at least three employees. 2. Decentralised approach The second approach to RPA governance, shown in Fig. 6.2, uses a decentralised allocation. In the model considered here, this would mean that all RPA governance tasks would have to be performed within the areas where processes are automated with RPA. This makes it almost impossible to create specialised roles, as shown above. This regularly leads to different approaches and procedures within the same organisation and a lack of common standards. This can lead to massive inefficiencies. In addition, there is a lack of scalability and the risk of duplication of work increases (see Deloitte 2017, p. 13). 3. Hybrid approach The third approach shown in Fig. 6.2 is the hybrid classification of RPA governance. As a rule, this is not a model, which is pursued from the outset. Rather, such an approach emerges over time or exists as a transitional model. In practice, it can regularly be observed that RPA governance is only established after the first (or several) RPA process implementation (see also the two approaches in Sect. 6.2). In this case, individual components and tasks of RPA governance are already developing in a decentralised (and often uncoordinated) manner. Subsequently, when RPA governance is formalised, these are consolidated and brought together in a central RPA unit. Figure 6.6 illustrates such a procedure. The advantage of a hybrid approach lies in the individually tailored

4The

consulting company uses the alternative term “Centre of Excellence” (CoE). The understanding of a CoE used here differs and is described in more detail below.

6.3  RPA Units and Their Organisational Classification

115

Fig. 6.6  Transition from decentralised to centralised RPA governance

automation in the different departments, which are supported in a centralised and standardised manner. However, this can still lead to the fact that standards are not used uniformly. Moreover, decentralised responsibility for RPA can only be successful if the decentralised managers are given a clear mandate and a corresponding mandate for the implementation and operation of RPA (see Deloitte 2017, p. 13). Conclusion on the organisational classification of RPA Results of the expert interviews The experts interviewed here all agree that a centralised approach is the best way forward. The most important reasons cited are the avoidance of inefficiencies and the faster and more extensive development of RPA expertise. A centralised approach is seen as more efficient, as a single RPA software is usually used and all procedures remain consistent and coordinated. By concentrating RPA knowledge—and experience—in one unit, it grows much faster than with a decentralised approach. In the end, the centralised approach is almost the only option for an RPA unit. This is the only way to ensure efficient management of RPA with all the associated tasks in one's own organisation (see also Deloitte 2017, p. 14). If sufficient resources are available, this establishment of centralised RPA governance should already take place within the framework of the initial RPA implementation project in order to be able to realise all added value at an early stage and to prevent the emergence of possible inefficiencies. If, on the other hand, sufficient resources are not available, a temporary decentralised approach can be pursued, which is transferred as quickly as possible to a hybrid form and then to the centralised one (see Fig. 6.6).

116

6  Introduction of RPA Governance

“RPA Center of Excellence” The term “RPA Center of Excellence” (CoE) is regularly used in the relevant literature, as well as in documents from RPA software vendors and RPA consultants. The following section explains what this term means in the understanding chosen here. It also shows when it is worth setting up such a CoE in the first place. Definition of a CoE Once again, the following applies: There is no clear definition of the CoE. The descriptions here differ greatly from one another. Thus, the CoE is partly exclusively the RPA unit in the understanding chosen here. In other cases, the term CoE refers to the entire RPA governance, i.e. the RPA unit and all other tasks and issues related to RPA. Sometimes the misunderstanding may arise that the CoE is a further development of RPA—for example, the establishment of some kind of RPA Shared Service Centre within the own organisation. However, this is not the case. The following definition should therefore apply here: The term RPA-CoE refers to the RPA unit described above, including all its tasks. In addition, the term CoE includes the establishment of other, higher-level bodies. The RPA-CoE is thus an extended RPA Unit that is established throughout the organisation. This in turn is responsible for RPA governance within the organisation and thus for all matters concerning or related to RPA throughout the organisation. From the RPA unit to the CoE According to this understanding, the transition from an RPA unit to a CoE is smooth and can be implemented with relatively little effort. An essential component of the RPA-CoE is an RPA control circuit (see isg 2019). This consists of representatives from all relevant areas such as IT, organisation, specialist departments, internal audit, etc. The focus of this steering committee is on ensuring that RPA is established and developed across the entire organisation and thus across departments. 

The example shows that a CoE makes sense the most when process automation with RPA is to be part of an organisation-wide, strategic orientation.

References Deloitte (2017) Robotic process automation in FSI. Kundenevent – kurze Zusammenfassung. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact= 8&ved=2ahUKEwjM7P3l5rbgAhWRHRQKHRQ7B48QFjAAegQIAhAC&url=https%3A% 2F%2Fwww2.deloitte.com%2Fcontent%2Fdam%2FDeloitte%2Fde%2FDocuments%2Ffinanc ial-services%2F20171127_Robotics%2520Event_Transscript%2520(003).pdf&usg=AOvVaw3 4KtZBEjvQ4nmbWWWIp6pH. Accessed: 12. Feb. 2019 Fischermanns G (2015) Praxishandbuch Prozessmanagement. Schmidt, Gießen

References

117

isg (2019) RPA center of excellence. https://www.isg-one.com/articles/build-your-rpa-center-ofexcellence. Accessed: 10. Feb. 2019 Kirchmer M (2017) High performance through business process management. Springer, West Chester Kirchmer M, Hofmann R (2013) Value-driven process governance. IM+io Fachz Innovation. Organ Manag 28(03):82–89 Lacity M, Willcocks L (2016) Robotic process automation at Telefónica O2. MIS Q Exec 15(1):21–35 Ostrowicz S (2018) Next Generation Process Automation: Integrierte Prozessautomation im Zeitalter der Digitalisierung. Ergebnisbericht Studie 2018. Horváth & Partners, Frankfurt a. M. UiPath (2019) RPA center of excellence. https://www.uipath.com/de/rpa/center-of-excellence. Accessed: 10. Feb. 2019 Willcocks L, Lacity M (2016) Service automation. Robots and the future of work. Steve Brooks Publishing, Warwickshire

7

Success Factors of RPA Implementations

Abstract

This chapter summarises the success factors for an RPA implementation that have been worked out so far and explains them in a coherent and detailed manner. In addition, success factors that have not yet been dealt with in detail, such as the consideration of regulatory framework conditions, are also supplemented. The latter are particularly important in the financial sector, and increasingly also for the large area of information technologies. It is shown how the obstacles and challenges repeatedly mentioned in practice can be overcome by taking the success factors into account.

7.1 Overview So far, it has become clear in many places which success factors, directly or indirectly, favour the introduction and subsequent operation of RPA. Since taking these factors into account is crucial for a sustainable, successful deployment of RPA in one's own organisation, it has been summarised in this chapter once again. In addition, it also lists those factors that have not yet been the focus of attention. However, not all components of a successful RPA introduction are considered again. Instead, the focus is on the most relevant factors and those that are conspicuously often neglected in practice. Success factors serve, among other things, to remove obstacles. Therefore, in a first step it is necessary to analyse the challenges and obstacles during the RPA implementation and subsequent RPA operation (see also Sect. 2.3, Lüth 2018 and Ostrowicz 2018, p. 20). These are summarised below: 1. Security concerns 2. Personnel resistance © Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 M. Smeets et al., Robotic Process Automation (RPA) in the Financial Sector, https://doi.org/10.1007/978-3-658-32974-7_7

119

120

7  Success Factors of RPA Implementations

Fig. 7.1  Success factors of RPA implementations

3. Organisational resistance 4. Lack of backing at management level 5. Insufficient support from IT 6. Governance, risk and compliance concerns 7. Lack of understanding of integration into existing IT landscapes and operating models 8. Lack of management awareness of the relevance of the technology and therefore low support 9. Fear of high investment volumes for RPA implementation 10. Lack of know-how in the organisation All the challenges and obstacles listed here can be met with the help of the success factors shown in Fig. 7.1. These are discussed in detail in the following sections. 

The relevance of each success factor depends largely on the type and extent of RPA implementation in the organisation. It is therefore advisable to check at the very beginning of planning which factors are particularly important and should be taken into account during implementation.

7.2 Correct Process Selection and Preparation One of the most important factors for a sustainable successful RPA implementation is the selection of the right processes and their subsequent preparation. Both Sect. 3.2, 5.4 and 5.6 have explained this in detail. For the first use of RPA in your own organisation, it is recommended to start with the automation of simple processes. This will help to generate initial successes quickly, which in turn helps to overcome initial reservations and can create awareness at management level of the relevance of RPA technology (see obstacle 8). In addition, an

7.4  Consideration of Regulatory and Related Framework Conditions

121

initial pilot process that can be automated with little effort shows that RPA often does not require high investment volumes (see obstacle 9). The latter is closely linked to the fundamentally correct selection of processes. To this end, appropriate selection criteria must first be defined. These belong to two groups, the technical and the business selection criteria. For the technical selection, the same criteria usually always apply. This is different for business criteria. These are usually much more individual in their design than the technical criteria. For example, some institutes evaluate processes on the basis of detailed unit costs, while others work with flat-rate values. Once the appropriate processes have been selected and recorded, the technical and professional process optimisation follows. This is also a decisive success factor. In addition to the optimisation potential that almost every process offers, process adjustments are often the only way to enable the use of bots. A good example of this is processes that are still based on the mutual sending of faxes. Example

In the accounting systems of many banks, certain postings are still sent using fax confirmations. For example, if a customer makes two almost identical bank transfers within a short period of time, the responsible, usually central department asks the customer service department by fax whether the double transfer is okay or not. The customer service department then consults with the customer and confirms (or rejects) the transfer by fax. By means of a minor change - namely the change from fax to e-mail - this becomes an automatable process. ◄

7.3 Early Establishment of RPA Governance Although Sect. 6.2 also presented a downstream introduction of RPA governance, the recommendation clearly goes in the direction of the immediate establishment of RPA governance. This ensures that all necessary framework conditions, preparatory work, accompanying measures, etc. are taken into account. Many of the challenges and obstacles listed in Sect. 7.1 can be met by early establishment of RPA governance.

7.4 Consideration of Regulatory and Related Framework Conditions Overview In contrast to other sectors, the regulatory framework plays a particularly important role in the financial industry. They determine large parts of daily banking operations. Process management in banks is also largely determined by regulatory requirements and specifications. Process management is affected by the requirements for adequate process

122

7  Success Factors of RPA Implementations

documentation (in the narrower sense) and ends (in the broader sense) with the technical and regulatory specifications for individual processes, such as the detailed rules for internal control in the loans department. These specifications and requirements do not prevent the use of RPA. However, they do place high demands on the careful selection and planning of processes when using RPA. Together with the regulatory framework, other, similar requirements form a network of safety, regulatory and compliance requirements, in which RPA find themselves. This is shown in Fig. 7.2. As a matter of principle, it is important to coordinate with those responsible within one's own organisation at an early stage on the issues mentioned. This has a positive effect on obstacles 1, 3 and especially 6. In addition to basic information on the RPA technology and the planned project, the requirements of those responsible for the RPA implementation should also be obtained. If this is done early, they can easily be taken into account. General examples of requirements For example, data protection requirements can specify the file storage locations of the bot protocols. High sensitivity is required here, at the latest when documenting customer-specific data. The requirements in the area of data protection often go hand in hand with the requirements of compliance and concern topics such as the authorisation of the bots, spatial access to the bots, exclusion of operating errors, etc. The regulatory requirements can be more complex - depending on the individual case - and are discussed in detail below.

Fig. 7.2   RPA in the network of safety, regulation and compliance

7.4  Consideration of Regulatory and Related Framework Conditions

123

Two types of regulatory requirements When considering regulatory requirements in the context of RPA, a fundamental distinction must first be made: Is it a requirement for the content of the process itself, or is it a requirement for IT, process management or similar? The first case described above is not relevant here. It concerns, for example, the controls described above for the granting of loans, thus, a requirement for the business process content. This is different in the second case. Here, the BAIT, the banking supervisory requirements for IT, should be mentioned in particular (see BaFin 2018). These describe concrete requirements for information security and IT governance of banks. Since RPA is a software it can be assumed that it will have an impact on the use of RPA in the financial sector. In the following, two regulatory requirements documents will be examined in more detail, which in the authors’ view are the most relevant for the use of RPA in the financial sector: The already mentioned BAIT and the Minimum Requirements for Risk Management (MaRisk), especially the requirements of the General Part (Allgemeiner Teil, AT) 9 (see BaFin 2017). BAIT and RPA BAIT interprets the requirements of Sect. 25a, paragraph 1, sentence 3, nos. 4 and 5 of the German Banking Act (Kreditwesengesetz, KWG). In doing so, they create specifications with regard to the technical and organisational equipment of in-house IT systems, information security and the creation of emergency concepts. When assessing whether an RPA is affected, it must be kept in mind that the use of RPA software does not meet many of BAIT's criteria, e. g. an RPA implementation does not develop an application in the strict sense (see BaFin 2018, p. 13). It can now be discussed whether the requirements nevertheless apply to RPA. Instead of discussing or interpreting BAIT too narrowly (and thus not taking RPA into account), it is advisable to observe the requirements as far as possible and sensible and to apply them to RPA. In particular, the figures of BAIT and their contents listed in Table 7.1 are, in the authors’ opinion, potentially relevant with regard to RPA (see also Tranker et al. 2018, pp. 48–49). Their possible implications are also outlined in Table 7.1. Table 7.1 shows the potentially great relevance of BAIT for RPA. The focus is on IT governance, user authorisation management, IT projects, application development, IT operation and outsourcing and other external procurement (see also Deloitte 2017, p. 27). Practical experience shows, however, that many of the topics mentioned are already covered and complied with by existing guidelines and regulations, making their explicit consideration obsolete. As a summary recommendation with regard to the consideration of BAIT in the context of RPA implementation and RPA operation, it can be stated that discussions about the listed or even further points should be sought at an early stage. Contact persons for this can be the responsible departments in your own organisation or external consultants. In this way, it is possible to check whether the issues are actually affected and to derive necessary activities.

124

7  Success Factors of RPA Implementations

Table 7.1  BAIT and RPA (see BaFin 2017 and Tranker et al. 2018, pp. 48–49) Digit in BAIT

Category

Sketch of contents

Possible implications for RPA

5

IT governance

Staffing

For example, relevant for ensuring RPA operation

6

IT governance

Conflicts of interest and incompatible activities in build-up/process organisation

For example, separation between development of the RPA artefacts and subsequent operation of the bots

10

Information Risk Management

Overview of information RPA should be listed and network known

24

User Authorisation Management

Authorisation concepts/ sparing principle

Individual organisational rules also apply to bots

25

User Authorisation Management

Need to assign non-personalised authorisations

Documentation of exceptions is useful

36

IT projects, application development

Definition of processes for application development

Use/consideration of the processes in the context of RPA makes sense

38

IT projects, application development

Use/consideration of the Application developarrangements under RPA ment arrangements to makes sense ensure confidentiality, integrity, availability and authenticity

39

IT projects, application development

Arrangements for checking whether intentional or unintentional manipulation has occurred

It makes sense to observe the individual organisational regulations

40

IT projects, application development

Traceable documentation of the application development

It makes sense to observe the individual organisational regulations

41

IT projects, application development

Test methodology

It makes sense to observe the individual organisational regulations

42

IT projects, application development

Monitoring after going live

It makes sense to observe the individual organisational regulations

43

IT projects, application development

Rules for the handling of It makes sense to software by end users observe the individual organisational regulations (continued)

7.4  Consideration of Regulatory and Related Framework Conditions

125

Table 7.1   (continued) Digit in BAIT

Category

Sketch of contents

44

IT projects, application development

Regulations of user It makes sense to access, authorisations, etc observe the individual organisational regulations

46

IT operations

Management of the components of the IT systems and their relationships to each other

47

IT operations

Management of the port- It makes sense to folio of IT systems observe the individual organisational regulations

53

Outsourcing and other external procurement

Risk assessment before external procurement

Test required, see also below

54

Outsourcing and other external procurement

Other external procurement in accordance with IT strategy

For example, checking for compliance with IT strategy

55

Outsourcing and other external procurement

Taking measures from Organisation-specific examination into account in drafting contracts

56

Outsourcing and other external procurement

Regular risk assessment of other external procurement

Possible implications for RPA

It makes sense to observe the individual organisational regulations

Ongoing risk assessment makes sense

MaRisk AT 9 and RPA In addition to BAIT, the requirements on outsourcing described in AT 9 of MaRisk can also influence the use of RPA (see BaFin 2017, pp. 20–22). BAIT also comments on this (see BaFin 2018, pp. 20–21). In essence, the resulting question is to be answered as to whether RPA constitutes outsourcing or other external procurement in accordance with AT 9 of MaRisk. These respective circumstances result in different requirements, which differ in their complexity. For example, further steps are required in the case of outsourcing, such as checking whether the processes can be outsourced, whether it is a significant outsourcing, etc. (see Tranker et al. 2018, p. 48). Other external procurement and outsourcing First of all, the question arises as to what is other external procurement and what is outsourcing. An isolated purchase of software falls under other external procurement. This also includes the customisation of software for individual institutions, maintenance, implementation and other support services by external third parties as part of software acquisition (see Tranker et al. 2018, pp. 47–48). However, if this software is used for

126

7  Success Factors of RPA Implementations

essential tasks of the banking business or if extensive support is provided by the software provider for the identification, assessment, management, monitoring and communication of risks, this constitutes outsourcing (see Tranker et al. 2018, p. 45). Such support can also be provided here: the institution-specific adaptation of software, the implementation of programming services for changes to the software, testing and release of the software in the productive environment, error corrections and other support services that go beyond the actual consulting services. The complete operation of the software by external third parties is always outsourcing. (see Tranker et al. 2018, p. 45). Does RPA involve other external procurement or outsourcing? In principle, the use of RPA can initially be assumed to involve the purchase of software in isolation, usually including the additional services described above. However, it must be checked individually whether one of the three exceptions described in MaRisk applies (see Tranker et al. 2018, pp. 47–48): • The use of the software for the identification, assessment, control, monitoring and communication of risks (i. e. in particular its use in risk management). • Essential importance of the software for the execution of banking transactions. • Operation of the software by an external third party. If this is the case, outsourcing is to be assumed. RPA software carries out simple activities according to firmly defined rules. It is supportive and reduces the error potential of human process operations. For this reason, the relevant literature classifies RPA - even when used in risk management - as other external procurement in accordance with AT 9 of MaRisk (see Tranker et al. 2018, p. 48). 

In principle, the following applies: The effects of the regulatory requirements described above on the use of RPA in one's own organisation should be examined as early as possible in the implementation of RPA.

RPA and data protection RPA usually only controls the automated applications. These should already take into account all data protection requirements. For example, these can be specifications on storage periods or locations for customer data. However, caution is required at least at one point with regard to RPA and data protection: RPA documents system inputs, in practice usually supplemented by individually prepared and often extensive documentation, which may also contain specific customer data. In this case, all general conditions must be agreed in advance with the internal data protection officer and taken into account, also with regard to storage location and duration.

7.5  Comprehensive Documentation Through Technical Concepts and Instructions

127

7.5 Comprehensive Documentation Through Technical Concepts and Instructions RPA invites its users to install the technology quickly and with little effort and to automate processes or individual process steps in the shortest possible time. Documentation and written specifications need time for preparation and coordination. For this reason, these are often neglected in practice. It has already been pointed out in many places that a too fast and incomplete procedure for RPA implementation does not make sense and stands in the way of the full efficiency gain through RPA. Here again, the importance of comprehensive documentation should be emphasised. This has a positive influence on the removal of obstacles 3, 7, 8 and 10 - but also indirectly on many other obstacles mentioned in Sect. 7.1. Table 7.2 summarises and then explains the most relevant documentation in the field of RPA. Relevance of the concepts The column “Relevance” indicates the latest date from which the corresponding documentation should be used. In principle, the earlier, the better. Nevertheless, it is

Table 7.2  Documentation in the field of RPA Documentation

Content

Process documentation

For first-time RPA Documentation of the recorded implementation and optimised/adapted process in a form of documentation known and used in the respective organisation

Click instruction

For first-time RPA Detailed, process-specific stepby-step instructions for the devel- implementation opment of the RPA artifact

Contingency plan

Definition of fallback solutions and emergency measures

Test concept

Guidelines for testing and release For the planned long-term use of developed RPA artefacts of RPA; however, for first-time RPA implementation, the main features should already be used

Process selection concept

Description of the long-term In the planned long-term use of approach to process selection and RPA prioritisation

RPA framework

Description of the organisation of the RPA operation, roles and responsibilities as well as processes for the introduction and operation of RPA

Relevance

For first-time RPA implementation

In the planned long-term use of RPA

128

7  Success Factors of RPA Implementations

important to find an appropriate balance between cost and benefit. If, for example, it is not yet clear in the early phase of an RPA piloting whether the technology is to be used in the long term afterwards, it is not worth documenting a standardised process selection procedure, i. e. a process selection concept. A gradual formalisation - as opposed to a complete formalisation from the beginning - is also supported by possible learning effects resulting from the first implementations. One of the most important documents, right at the beginning of every RPA implementation, is the documentation of the process to be automated at the detailed level (“click level”) in a click instruction. This does not refer to the process recorded in a first step, but rather to the analysed and optimised process. The documentation serves the RPA developer when developing the RPA artifact. At the same time, it provides a basis for the person responsible for the technical process (and thus usually the person approving the automated process) as well as third parties, such as internal auditing, to check whether the artifact development and thus the automation was carried out correctly (see also Sect. 5.6.3). In addition, on the basis of the adapted process, the mostly already existing process documentation in the individual organisational instructions must be adapted. An emergency concept (see Sect. 5.9) is also relevant from the very first use of an RPA. A formal test concept (see also Sect. 5.8) is only required in its basic outline from the beginning. In most cases, rough basic conditions are sufficient at the beginning to enable valid and sufficient testing. Subsequently, the formalisation in concept form can then take place. A process selection and framework concept is only worthwhile in the case of a (planned) long-term establishment of RPA. These describe long-term oriented procedures, process flows, roles, responsibilities and framework conditions. The RPA framework concept also forms a kind of bracket around the other concepts and closes possible gaps.

7.6 Involvement of Relevant Stakeholders For many organisations, RPA is currently still a relatively new technology. Accordingly, it is unknown and often subject to prejudice. Early involvement of relevant stakeholders therefore plays a decisive role in the organisation-wide acceptance of RPA and is one of the most important success factors on the way to successful use of RPA. It has a positive impact on almost all the obstacles listed in Sect. 7.1. Procedure for the involvement of relevant stakeholders The first step is to identify relevant stakeholders. These should then be involved in the introduction of RPA as early as possible. In this way, information deficits can be quickly remedied and possible blockades resolved. In many cases, it is a lack of knowledge (rather than a lack of will) that creates challenges and obstacles in the first place.

7.6  Involvement of Relevant Stakeholders

129

To ensure sufficient involvement, the first step is to hold information meetings. Even before the start of a possible implementation, the technology with all its advantages and disadvantages should be explained transparently and presented using examples. In the further course of the project it is advisable to involve individual stakeholders in the project work. This can also be done in the form of information meetings, or even in the form of active participation in the project and the corresponding decision-making-competence regarding RPA. Relevant stakeholders The relevant stakeholders are usually. • Executive Board/Management • Human Resources • Works council/staff council • Organisation/IT • "Controlling bodies” (audit, compliance, data protection, data security) • Departments that use RPA Results of the expert interviews The assessment regarding relevant stakeholders is also confirmed almost uniformly by the experts surveyed. The different areas play a particularly important role when RPA leaves its pilot phase and is deployed across departments or even organisations. Here, increasing broad-based acceptance is required. When it comes to the (temporal) prioritisation of the involvement of relevant stakeholders, Lukas von Eicken, at that time Project Manager for robotics at Nassauische Sparkasse, recommends a pyramidal process model: In a first step, top management, the works or staff council and the controlling bodies are involved. In a second step, the divisional managers of the departments affected by the introduction of RPA are involved. The third step concludes with the involvement of all employees of these departments. The advantage of the model is that the time and effort involved can be spread out over time, and the top-down involvement of all stakeholders ensures acceptance by management and (supervisory) bodies. In addition, more and more multipliers are created over time, which means that the effort is distributed over more and more people and is smaller for the individual person.

In their study, Watson and Wright (2017, p. 12) examine the degree of support for (organisation-wide) RPA implementation by different stakeholders. With 72% each, top management and (functional) managers (e. g. non-disciplinary project managers) are the two most supportive groups. They are followed by process owners (65%), team members (53%), and disciplinary managers (such as department or team leaders) (50%). The IT department supports 31%.

130

7  Success Factors of RPA Implementations

7.7 Building up Internal Know-How Carriers and Promoters In order to generate internal organisational knowledge about RPA as quickly as possible, know-how carriers must be built up at an early stage (see obstacle 10). Section 6.2 explained how an RPA-related knowledge management system can look like and be set up. The advantage of a sufficient number of know-how carriers is complex. They contribute to increasing the level of awareness of RPA in all areas of the company. At the same time costs can be saved. If sufficient internal know-how is available for all the steps described in Chapter 5, RPA can be implemented and operated with little or no external support. Figure 7.3 outlines this relationship. On the left side of the figure is the degree of internal know-how within the organisation. This increases over time. The right side of the figure shows the distribution of tasks between internal and external resources (i. e. RPA consultants, RPA developers, etc.). Here, the ratio changes over time from an external to an increasingly internal assumption of tasks. 

Even though Fig. 7.3 is a schematic representation, for cost reasons in particular, the outlined understanding should be part of the target picture of any RPA introduction.

In addition to the know-how carriers, RPA promoters (or “sponsors”) are also an important component of the internal acceptance of RPA within the organisation (see also Willcocks and Lacity 2016, pp. 118–119). Members of top management and heads of divisions and departments are particularly suitable as promoters. They have the appropriate influence to overcome reservations. An organisation-wide well-connected project manager is also suitable for placing RPA and its benefits within the organisation.

Fig. 7.3  Development of RPA know-how and task transfer

References

131

7.8 Training of Employees in the Use of RPA In addition to the development of know-how carriers, all employees who come into contact with RPA require appropriate training. The points of contact can range from being only indirectly affected by the use of RPA in their own department to being directly affected by regular interaction with the software bots. Sections 5.11 and 6.2 have already explained the possibilities and contents of training courses, which is why they are referred to here.

7.9 Accompanying Change Management The importance of accompanying change management as part of the RPA rollout has already been explained in Sect. 5.11. This includes the understanding of consciously controlling change processes instead of letting them proceed unplanned (see also Hansmann et al. 2012, p. 277). The success of an RPA implementation depends in particular on intensive communication and information and the early involvement of all affected employees (and the stakeholders already mentioned in Sect. 7.6). Change management can thus be understood as a comprehensive, accompanying framework concept that supports the entire RPA implementation and also the first weeks and months of subsequent RPA operation. Results of the expert interviews Change management creates transparency. According to the experts surveyed, this in turn is one of the most important criteria for a sustainably successful RPA implementation.

References BaFin (2017) Rundschreiben 09/2017 (BA) vom 27.10.2017. Mindestanforderungen an das Risikomanagement – MaRisk BaFin (2018) Rundschreiben 10/2017 (BA) in der Fassung vom 14.09.2018. Bankaufsichtliche Anforderungen an die IT (BAIT) Deloitte (2017) Robotic Process Automation in FSI. Kundenevent – kurze Zusammenfassung. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact= 8&ved=2ahUKEwjM7P3l5rbgAhWRHRQKHRQ7B48QFjAAegQIAhAC&url=https%3A% 2F%2Fwww2.deloitte.com%2Fcontent%2Fdam%2FDeloitte%2Fde%2FDocuments%2Ffinanc ial-services%2F20171127_Validation: Please check Underscore symbolRobotics%2520Event_ Validation: Please check Underscore symbolTransscript%2520(003).pdf&usg=AOvVaw34KtZ BEjvQ4nmbWWWIp6pH. Accessed: 12.02.2019 Hansmann H, Laske M, Luxem R (2012) Einführung der Prozesse – Prozess-Roll-out. In: Becker J, Kugeler M, Rosemann M (Hrsg) Prozessmanagement. Springer Gabler, Berlin Lüth A (2018) RPA-Markt soll bis 2020 kräftig zulegen. https://www.bigdata-insider.de/rpa-marktsoll-bis-2020-kraeftig-zulegen-a-728203/. Accessed: 20.01.2019

132

7  Success Factors of RPA Implementations

Ostrowicz S (2018) Next Generation Process Automation: Integrierte Prozessautomation im Zeitalter der Digitalisierung. Ergebnisbericht Studie 2018. Horváth & Partners, Frankfurt am Main Tranker N, Langer L, Fredenhagen T (2018) Erschweren neue Vorgaben die Einführung von RPA? Die Bank 07:44–49 Watson J, Wright D (2017) The robots are ready. Are you? https://www.google.com/url?sa=t&rc t=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEwjizofA5MnfAhURYlAKHWHaBqoQ FjAAegQIChAC&url=https%3A%2F%2Fwww2.deloitte.com%2Fcontent%2Fdam%2FDeloitt e%2Ftr%2FDocuments%2Ftechnology%2Fdeloitte-robots-are-ready.pdf&usg=AOvVaw2luiVI NhzNclPK70Ac7_Validation: Please check Underscore symbolzc. Accessed: 31.12.2018 Willcocks L, Lacity M (2016) Service automation. Steve Brooks Publishing, Warwickshire, Robots and the future of work

8

Special Case—RPA in One-Time Situations

Abstract

The proven application area of RPA is the automation of repetitive processes. However, RPA does not provide benefits only here. Even in one-time situations, RPA can be used to reduce costs, increase speed or improve quality. A practical example is data migration with RPA. This chapter uses such an example to explain the special features of these one-time applications.

8.1 Distinction from the Automation of Repetitive Processes RPA's main area of application in the financial sector to date has been processes that are carried out on a permanent and regular basis. Here, organisations focus on the long-term use of the bots in “day-to-day business". However, the use of RPA as an automation solution for one-time tasks has so far been underestimated. However, it is often worthwhile using RPA even in one-time situations, e. g. when processing large volumes of data. Here, too, individual processes are run through several times, but only within a fixed, usually very short period of time and to achieve a defined goal. Thus, such use cases regularly have project character. An increasingly practical example is data migration. The importance of a fast and error-free implementation increases strongly if the content to be migrated is core business relevant data or customer information. Even complex mass data changes or one-time verification and adaptation measures are starting points for automation using RPA.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 M. Smeets et al., Robotic Process Automation (RPA) in the Financial Sector, https://doi.org/10.1007/978-3-658-32974-7_8

133

134

8  Special Case—RPA in One-Time Situations

8.2 Case Study: RPA as Data Migration Tool An example of a combination of data migration and verification action is the acquisition of insurance policies by another insurer.1 In this case, the accepting insurance company must check the data, some of which is decades old and often stored in outdated systems and formats, and transfer it to its own systems within a very short time. To this end, data mapping specifications are first created. In the classic case, these provide the basis for the subsequent development of migration programs. Alternatively, the mapping specifications can be implemented as an RPA process. In addition to web applications, banks and insurance companies often use mainframe computer applications for the input of bots. These have very short reaction times. This enables the bots to process data quickly, since almost no time has to be planned for waiting for feedback from the system - a great advantage due to the regularly short time window for exporting, transforming and importing data. In addition to a high data acquisition speed, an equally high acquisition quality is a prerequisite for the success of the migration. For this reason, the screen-scraping technology, which is still occasionally used in RPA implementations and is highly error-prone, must be avoided in data migrations at all costs. No machine migration programs or interfaces need to be developed for input via the user interfaces. This ensures that all input rules of the target system are automatically taken into account during data input. This is because - unlike machine migration - RPA makes profitable use of all the test routines and support processes of the target system that are available to employees in their daily work. Since RPA does not require any programming in the original sense, no program tests - only process tests - are necessary, which also contributes to a significantly faster implementation than with machine migration. An additional advantage of data migration with RPA: data export is not bound to a specific file format. After all, the bots can handle a wide variety of file formats. Thus, the format that is most suitable for the migration or easiest to use on the source system side can be used. Current implementation projects not only prove the success of RPA as an alternative to machine migration, but also to the only alternative so far: manual data entry by humans. Manual data migrations can avoid necessary programming and testing activities and thus avoid bottlenecks in the IT departments. This often leads to pure bottleneck shifts to the area or department that provides the employees for the data handling. Alternatively, temporary employee capacities can be procured cost-intensively on the market. Manual data migration has another disadvantage that has regularly been a decisive factor in previous implementation projects: people make mistakes (see also

1 See also Barenthien B, Smeets M (2018) RPA automation for data migrations. https://www. itfinanzmagazin. de/rpa-automatisierung-bei-datenmigration-66986/. Accessed: 26 February 2019.

8.2  Case Study: RPA as Data Migration Tool

135

Sect. 2.3). It can be assumed that a relevant part of the manually entered data contains errors that can only be found and corrected with great effort. RPA, on the other hand, runs through the programmed and tested processes in constant (error-free) quality. Experience has shown that the costs of RPA solutions are even lower than the costs for employees and thus usually lead to a positive project ROI. Only the frequently cited argument that RPA offers 24/7 data processing capability must be refuted for banks and insurers. Here, end-of-day processing often prevents the uninterrupted work of bots, even though the daily data entry time is still longer than with manual migrations. If bots are used for repetitive tasks over the long term, they often execute different processes during the course of the day - depending on where data is waiting to be processed. For data migrations, on the other hand, it makes sense to run individual processes continuously and with a large number of bots working in parallel. For example, customer master data often has to be entered first before the processing of contracts, sales or tax data can begin. Then, the full bot capacity can be used to move on to the next process - if the migration schedule requires it. A corresponding control system is indispensable here. This includes not only the technical operation of the individual bots, but also, for example, the distribution of input files to the bots. If only a small number of bots are in use, the control can be done manually. If a large number of bots are in use, it is advisable to use the central control units already mentioned. Example

Another relevant example of the use of RPA in one-time situations is an account migration carried out with the help of bots. Due to various technical challenges, an automated migration from Bank A to Bank B was not possible. The only alternative at first: manual data migration over a period of months by an almost three-digit number of employees - not a viable solution. The use of RPA as an alternative solution generated a reduction in migration time from several months to less than a week. At the same time, a quality level of almost 100% was achieved and unsystematic errors did not occur. Although artifact development, testing and acceptance took several months, an additional 30% cost saving was achieved compared to the original solution. ◄ In terms of infrastructure, you can also choose between a server-client and desktop-based installation of the bots for data migrations. If the installation is carried out on individual workstations, it must be taken into account that a large amount of hardware must be procured and made executable for a usually short period of time. If the bots are only used for a short period of time during a data migration, the purchase of corresponding licenses is only the second choice, rental models are better in this case. The possibility of this should be taken into account when selecting the implementation or software partner.

136

8  Special Case—RPA in One-Time Situations

RPA often offers a noteworthy alternative solution for the one-time processing of large amounts of data within a short period of time - for data migrations in the context of system changes or even mergers. Compared to an independent program development, RPA convinces by its simplicity and fast implementation capability. Compared to manual processing, RPA is ahead in terms of quality - in addition to the higher processing speed. 

Which procedure is best suited to the concrete project situation should be examined together with experienced experts, taking into account the technical and professional framework conditions.

9

Looking to the Future—The Further Development of RPA Technology

Abstract

In this chapter, we will look into the near future. First, a distinction is made between two possible forms of further development of RPA. One is the future combination of RPA with other technologies. The second is the further development of RPA to IPA, Intelligent Process Automation—thus, a complete solution instead of a combination.

9.1 Different Directions for Further Development Just as today's RPA technology has evolved from an initial desktop-based support that was mainly used in call centres (although the latter is still successfully in use and by no means obsolete), it can be assumed that the current RPA technology will continue to evolve. First of all, two different directions of further development can be distinguished: 1. New combinations with other existing or emerging software solutions 2. Further development of the RPA technology itself Both directions and the resulting possibilities are described below. At this point we would like to refer again to the note in Sect. 2.1. Some solutions, which are often described as further developments of RPA, are rather parallel existing or developing technologies that can complement RPA and should therefore rather be assigned to the possible combinations. A prominent example is solutions that include components of machine learning.

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 M. Smeets et al., Robotic Process Automation (RPA) in the Financial Sector, https://doi.org/10.1007/978-3-658-32974-7_9

137

138

9  Looking to the Future—The Further Development of RPA Technology

9.2 Possible Combinations with Other Software Solutions In many examples up to this point it has been shown that RPA is ideally suited for the automation of repetitive and standardised processes. The most important prerequisite for this: Digital and structured data. In many practical applications in the financial industry, this very structure is missing. The best example of this is e-mail, which has digital content but is usually unstructured. RPA in its original form cannot deal with this. Rather, technologies are needed that convert the content into a form that can be used by RPA. Embedding of RPA in upstream and downstream supplementary components One conceivable option is to use the digital assistants already described in Sect. 2.1. These use NLP technology to recognise patterns in unstructured texts. By means of such machine learning (ML), texts can be brought into a structured form over time with increasingly better quality. In addition, OCR components can be used a further step in advance to convert the unstructured texts first into a machine-readable form. Figure 9.1 shows such an “automation chain” as an example. The machine-readable and unstructured text is received, first made machine-readable and structured and can then be further processed using RPA. Ostrowicz (2018, pp. 7–8) also describes such a procedure on the way to an increasingly comprehensive end-to-end process automation. Here he describes cognitive automation as an ideal way to structure data. The study participants assume an additional automation potential of more than 20% by combining RPA with technologies such as cognitive automation and digital assistants. Results of the expert interviews According to the majority of the experts surveyed, the combination of RPA with other cognitive components has a much greater potential than the possible further development of RPA itself towards cognitive RPA solutions, as described in Sect. 9.3. The combination of different technologies described here is also partly covered by the term cognitive automation itself (see for example expert system 2019).

Fig. 9.1  Exemplary “automation chain”

9.3  Further Development of RPA: Intelligent Automation—Cognitive …

139

RPA and process mining Process mining analyses digitally occurring processes. It uses the “digital” footprints that each process step leaves in the participating applications and thus recreates the process. In combination with RPA, enormous advantages can be generated from this. Process mining itself serves as an analysis tool for creating transparency, but—on its own—does not yet allow for efficiency gains or the like. This is where RPA comes into play. Based on the results of process mining, processes suitable for automation can be identified and implemented as RPA processes (see also Lindner 2019). Process mining makes another important contribution here: One of the core problems when selecting processes to be automated lies in the business perspective, thus, the commercial assessment (see Sect. 5.3). In order to find out which costs a process has in its actual state, the tied employee capacities or the costs for this are often used. These in turn can be determined by the process throughput time (better, but more difficult to determine: process handling time). This is exactly where process mining comes in and helps to determine the relevant times exactly. Supplementing RPA with existing or new workflow systems In addition to supplementing and expanding the system with more novel technologies or at least those containing novel components such as ML, technologies used long before RPA also offer meaningful combination possibilities. For example, the integration of RPA in the context of holistic BPM. BPM can provide the ideal framework for automating individual processes. Freund (2019) also shows such an example. Another possibility is the integration of RPA into existing workflow management systems. It is conceivable, for example, that individual workflows start further processes at defined points, which in turn are then processed by RPA bots. Results of the expert interviews One of the interviewed experts sees a possibility in the combination of RPA and workflow management systems to facilitate the further processing of process flows controlled by bots. If a human-supported decision is required at a certain point in the process, the WfMS can take over, bring about the human decision and then return the process to the RPA bot for further processing.

9.3 Further Development of RPA: Intelligent Automation— Cognitive and Self-Learning Complete Solutions In contrast to a combination with other technologies, the term Intelligent (Process) Automation—or IPA—refers to the further development of RPA itself, towards a cognitive, self-learning and self-contained solution (see also Martens 2018). The research project “AI.RPA”, funded by the German Federal Ministry of Research and Education, deals with the development of such a solution (see Scheer GmbH 2019). The aim of the project

140

9  Looking to the Future—The Further Development of RPA Technology

is to create a self-learning RPA solution that “learns” by means of ML on the basis of human work steps. The software examines these work steps with the help of the process mining technology explained in Sect. 9.2, which makes processes analysable by means of their digitally traceable steps. Berruti et al. (2017) describe IPA as a combination of five different technologies within one tool: 1. RPA The well-known process automation according to the definition used here: An automated processing of digital and structured data. 2. “Smart Workflow” A workflow management system that controls the entire process from start to finish and, in particular, ensures smooth handovers and workflows at interfaces between bots and people involved in the process—both among each other and across groups (see also Sect. 9.2). 3. ML components Solutions that analyse and structure unstructured data. 4. NLG components NLG is the abbreviation for “Natural Language Generation”, i.e. the transfer of data into (prose) text. This is also intended to ensure the smooth and interface-spanning work of humans and machines. NLG is not to be confused with NLP (see Sect. 2.1), the machine processing of natural language, that is the “opposite direction”. 5. Cognitive agents As a tool solution, cognitive agents connect the ML and NLG components. Through their components of artificial intelligence on the one hand, but also the reduction of obstacles in machine-human cooperation on the other hand, they approach a machinebased, complete work force. How does this differ from the combination of RPA with other technologies described in Sect. 9.2? While the focus there is on RPA as a core technology that is complemented by upstream or downstream technologies, the focus here is on the (“equivalent”) combination of different technologies. None of the five are complemented, but rather all are combined. In addition, a solution “from one source” is described here. This means that it is no longer a question of components to be used separately, but—ideally—a single solution. The combination of the five technologies described above forms IPA. It remains to be seen whether this understanding will prevail in the future or whether it will be replaced by other possible combinations or complete “one-stop solutions”.

References

141

References Berruti F, Nixon G, Taglioni G, Whiteman R (2017) Intelligent process automation: the engine at the core of the next-generation operating model. https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/intelligent-process-automation-the-engine-at-the-core-ofthe-next-generation-operating-model. Accessed: 20. Feb. 2019 expertsystem (2019) What is cognitive automation? https://www.expertsystem.com/what-is-cognitive-automation/. Accessed: 20. Feb. 2019 Freund J (2019) Klartext: „RPA entwickelt sich immer häufiger zu einem süßen Gift“ – Warum RPA die Transformation behindert. https://www.it-finanzmagazin.de/klartext-rpa-gift-transformation-85578/. Accessed: 21. Feb. 2019 Lindner I (2019) Process Mining und RPA: Bremst die IT ihre Unterstützer aus? https://www. computerwoche.de/a/process-mining-und-rpa-bremst-die-it-ihre-unterstuetzer-aus,3546580. Accessed: 21. Feb. 2019 Martens H (2018) So verbindet intelligent process automation RPA und machine learning. https:// www.bigdata-insider.de/so-verbindet-intelligent-process-automation-rpa-und-machine-learning-a-725612/. Accessed: 20. Feb. 2019 Ostrowicz S (2018) Next Generation Process Automation: Integrierte Prozessautomation im Zeitalter der Digitalisierung. Ergebnisbericht Studie 2018. Horváth & Partners, Frankfurt a. M. Scheer GmbH (2019) Revolution in der Prozessoptimierung: KI.RPA erforscht KI-basierte Automation. https://www.pressebox.de/pressemitteilung/scheer-gmbh/Revolution-in-der-Prozessoptimierung-KIRPA-erforscht-KI-basierte-Automation/boxid/941322. Accessed: 19. Feb. 2019

Appendix A

A.1 Explanation of expert interviews In the course of preparing this book, interviews were conducted with RPA managers from various financial services companies. These include banks, savings banks, service providers for banks and savings banks, and securities firms. The objective of the interviews was twofold. On the one hand, they were intended to confirm or refute assumptions made or positions previously held in the literature. On the other hand, they were intended to open up new ideas and approaches in the field of RPA. As already explained at the beginning, the content, structure and methodology of the interviews do not pursue any explicit scientific objectives. In the following, the questions that the experts answered in the structured interviews are listed. If the questions were closed questions, a justification was subsequently asked. In some cases, for example, where not all questions could be asked or were meaningful, only individual questions from the listed catalogue were asked and answered. The response was always anonymous. In agreement with some experts, however, individual relevant quotations (direct or indirect) are reproduced in the text in a non-anonymous form. Current and planned scope of use of RPA in your company Is active process management established in your company? Your company uses RPA … In which life cycle do you classify the RPA usage of your company? How long have you been using RPA? How many processes has your company already automated? What kind of processes are you focusing on so far? How many processes does your company plan to automate in the next 12 months? What is the average implementation time of RPA (for a process) in your company?

© Springer Fachmedien Wiesbaden GmbH, part of Springer Nature 2021 M. Smeets et al., Robotic Process Automation (RPA) in the Financial Sector, https://doi.org/10.1007/978-3-658-32974-7

143

144

Appendix A

In which business areas are the current automation focuses? In your opinion, which business areas are the future focal points of automation? Which RPA software solutions do you use in your company? Procedure for implementing RPA in your company Was external support used for the initial implementation? Has external support been used for subsequent implementations or is it planned? Do you plan to use external support for future RPA implementations? Was the initial implementation done by a project or from line? Are the subsequent implementations carried out by a project or from line? Do you implement new bots in release form (for example 2 × p.a.) or successively after completion? What “framework measures” are you using to accompany the (technical) introduction of RPAs? Key figures/background information on RPAs in your company Your main motivation for using an RPA: cost reduction, time reduction or quality improvement? How high do you estimate the average achievable cost savings through RPA per process in % (based on actual process costs)? What other potential benefits does RPA offer in your view? In your opinion, which processes are most suitable for automation? How many RPA providers have you already had contact with? RPA governance In your view, what are the framework/conditions for the introduction of RPA? In your opinion, which stakeholders should be involved in the introduction of RPA? Is RPA in your company rather “driven” by the specialist departments or the IT department? In which area should the responsibility for RPA development, operation and control lie in your view? What is the level of formalisation of RPA in your organisation (are concepts in place, etc.)? RPA success factors and outlook In your opinion, what are the most relevant success factors for a RPA introduction? Would you also use intelligent (self-learning) automation solutions?