Robotic Process Automation (RPA) in a company. Success factors and recommendations for the start

Textbook , 2020 , 103 Pages

Computer Science - Commercial Information Technology

Numerous tasks in a company follow a structured process and could be automated. However, they occur too rarely to justify the automation effort. Robotic Process Automation (RPA) aims to change this: By having a robot emulate the input on an existing user interface, no changes are required in the target application. Automation is possible in a timely and cost-effective manner.

So far, many companies have had positive experiences with RPA. However, there are also a number of failed projects. What factors determine success and failure when introducing an RPA system? Björn Freivogel explains how the introduction of robotic process automation succeeds.

He first gives an overview of the topic of RPA and presents the features and functionality of RPA systems. Based on this, he examines which properties suitable processes should have and how important it is to systematically select process candidates. In his publication, Freivogel not only summarizes the theoretical basics, but also gives practical recommendations for the introduction of RPA in the company.

From the content:
- robotic desktop automation;
- agility;
- Agile methodology;
- business process management system;
- BPMS

Table of contents

Summary

Foreword

Glossary

1 Introduction
1.1 Starting situation
1.2 Research problem
1.3 Research question
1.4 Objectives, delimitation of content
1.5 Structure and procedure

2 Theoretical part
2.1 Literature research
2.2 State of research
2.3 RPA Basics
2.4 Field of application of RPA
2.5 Benefits of RPA
2.6 Limits and challenges
2.7 Success
2.8 Theoretical findings

3 Methodological approach
3.1 Qualitative research
3.2 Guideline interview as expert interview
3.3 Procedure
3.4 Data collection 5
3.5 Data analysis 6

4 Empirical part
4.1 Category: Initial situation/motivation
4.2 Category: Project initialization
4.3 Category: Litigation candidates
4.4 Category: Challenges
4.5 Category: factors
4.6 Category: Benefit
4.7 Category: Operation

5 Conclusion
5.1 Summary of results
5.2 Critical appreciation of the results
5.3 Outlook and further research needs
5.4 Concluding remark/reflection

Appendix:

List of references

List of abbreviations

Summary

Question and objectives

Many of a company's tasks follow a structured process and could be automated, but occur too rarely to justify the automation effort. with Robotic Process Automation (RPA) this should change: By emulating the inputs on an existing user interface, no changes in the target application are necessary, which makes automation possible in a timely and cost-effective manner. Although the potential of RPA and the experience gained from implementations that have already been implemented are promising, this confidence is also offset by numerous failed RPA projects. For this reason, the core of this thesis sheds light on the central success factors in the introduction of an RPA system with the aim of giving a circle of interested parties the essence of the experiences of successful introductions.

theory.

The theoretical part gives an introduction and overview of the topic of RPA, shows the characteristics and functionality of RPA systems and deals with the differentiation from Business Process Management System (BPMS). The characteristics of suitable processes are examined, and the importance of the systematic selection of process candidates is pointed out. From the extensive literature sources, the potentially versatile benefits and the limitations as well as challenges that an RPA introduction can bring with it are shown in a concentrated manner. At the end of the theoretical part, the recommendations and findings for a successful introduction follow, which are then checked in empiricism.

method

The author sees openness and dialogue-focused qualitative research as the best opportunity to address the different ways in which companies deal with the introduction of an RPA system. The success factors are considered from different perspectives with the help of guideline interviews with experts from the target groups of users/application managers, manufacturers and consultants. The transcribed interviews then serve as data material for the qualitative content analysis, which condenses the results in a structured way.

Results and conclusion

The findings of the theoretical part are clearly reflected in the findings of empiricism and are supplemented and concretized by them. At the beginning of a project, it is crucial to think about how RPA should be positioned in a company in the long term. The initial deployment and expansion can take place in small steps, whereby it is important to have a vision. In addition, employees are to be affected by a Change Management be involved from the beginning of the process. Clear communication about the goals of the project dispels the usually exaggerated fears of the employees. The support of the management is essential. In this way, a representative of the management should lead the way, emphasize the importance of the introduction and motivate the employees to attend internally. RPA becomes attractive when it can scale, which is usually only possible if the process candidates can be identified across the entire breadth of the company. The currently possible spectrum with a clear demarcation to the artificial intelligence of RPA should be shown and the expectations of the management should be picked up at an early stage.

Another key success factor is the early involvement of the IT department, which is a prerequisite for setting up a scalable and secure robotics infrastructure. Since the existing IT Policies are usually not (yet) designed for the use of RPA, it is advisable to allow enough time for educational and persuasion work. In addition, it should be checked together with the IT department whether all possibilities have already been exhausted on the respective target application. Integration via the existing application landscape is the primary goal, while a robot, apart from tactical and temporary solutions, is only the second or third best solution. Furthermore, a governance indispensable for the medium and long-term success of an RPA deployment. It is advantageous to have a central office or a central team, for example in the form of a Center of Excellence.

Foreword

My colleague, Mr. Stefan Michel, who was always at my side with valuable advice, drew my attention to the topic of RPA, for which I would like to thank him. As a business informatics specialist, I have been working in the field of core banking systems for over 20 years and have so far only looked at the development of RPA from a distance. In mostly superficial reports, I was able to draw from the media both extremely positive and negative experiences. When I heard that my employer was thinking about using RPA, I took this opportunity to shed light on the topic of RPA and its successful introduction in detail.

I would like to take this opportunity to thank all the interview partners who, despite their very busy agendas, made themselves available for the discussions and were willing to share their experiences with me.

A special thank you goes to my speaker, Mr. Guido Schlobach, who contributed to the creation and development of this work with his professional advice and precise answers to my questions. I would also like to thank my parents-in-law, Mrs Uschy Fuchs for proofreading and Mr Emmerich Fuchs for his always valuable and constructive inputs, not only in the context of this thesis, but during my professional and school career so far.

Finally, my special thanks go to my parents and my family for the constant support, especially my wife Karin and my children Lenny and Malea, who had to do without me again and again and endured the exhausting time with a lot of patience. I would also like to thank Ms. Sara Furler for editing this work.

For reasons of better readability of the text, the spelling with -er/-innen is omitted in this work. Instead, the general names of people are used in the shorter, masculine spelling. This spelling is used as a synonym for the female and male form, so all female and male persons are addressed equally.

Glossary

Abbildung in dieser Leseprobe nicht enthalten

1 Introduction

1.1 Starting situation

For decades, operational optimization has focused on the automation of business processes. Since the 1990s, thanks to integrated databases and the Enterprise Resource Planning systems, ERP systems for short, significant productivity increases are achieved by developing them with the aim of supporting business processes as holistically as possible (Scheer, 2017a).

In addition, since the 1990s, numerous companies have opted for a Business Process Management (BPM) and thus for the introduction of a process organization. The better understanding of problems in the business processes and the possibilities for improvement of the existing organization are the main goals. As a rule, an actual situation is mapped by a process model and its shortcomings are discussed. Subsequently, a target model is developed, taking into account the possibilities of software to be introduced, such as an ERP or an Customer Relationship Management Systems, crm system for short. The target model is to be implemented by customizing the ERP or CRM system. A further approach to the implementation of the target model is Business Process Management System (BPMS), which – to put it simply – can generate the software from the model. A BPMS is pushed by means of a central Process Engine the tasks according to the target model and passes on the required data. Although a process implementation using BPMS is simpler and more flexible compared to a hard-coded process, the necessary connections of the applications still usually cause high efforts (Scheer, 2017a).

The automation of tasks using ERP and CRM systems as well as BPMS could increase productivity, among other things. However, since such projects are usually associated with high efforts, only those tasks that occur very frequently are automated. As the following figure shows, there are numerous tasks in a company that also follow a structured process and could therefore be automated, but occur too rarely to justify the automation effort (see figure below, marked in yellow). These tasks are also called so-called tasks. long tail tasks.

Abbildung in dieser Leseprobe nicht enthalten

Figure Distribution of tasks according to frequency and diversity

Source: based on von der Aalst, Bichler, & Heinzl (2018, S. 270)

1.2 Research problem

In the context of digitalization, new technologies such as Cloud Computing And that Internet of Things changed organizations with themselves. In this context, a new wave of automation is also emerging, driven by robotics (Czarnecki & Auth, 2018). Those long tail tasks that follow a structured process, but occur too rarely to justify their automation effort with previous solutions, should now be able to be efficiently automated by RPA.

RPA is a novel approach to process automation in which tasks are learned and automatically performed by robots. In the context of RPA, robots are not understood as a physical machine, but as a software program. "The innovative idea is to transform the existing process execution from manual to digital, which distinguishes RPA from traditional approaches to BPM" (Czarnecki & Auth, 2018, S. 113). The robot emulates the inputs on the existing user interface, so that neither a change of the application nor a connection of interfaces is necessary.

The idea of an integration via the user interface is not new and has long been used by so-called user interface. Screen Scraping Tools used (Allweyer, 2016). However, RPA promises to be much more powerful and flexible. This approach aims to achieve significant cost savings while increasing efficiency and process performance quality. (Allweyer, 2016, S. 5). Automation using RPA should also be implemented faster than with comparable IT solutions such as BPMS (Czarnecki & Auth, 2018, S. 117). Experience from projects already implemented has confirmed the potential of RPA (Schmitz, Dietze, & Czarnecki, 2019). Thanks to such positive experiences, consulting institutes predict a rapidly growing demand for RPA systems (ATKearney & Arvato, 2018). On the other hand, however, there is the fact that so far 30-50% of the initial RPA projects have failed. (Ernst & Young, 2016). According to the Gartner Hypecycle for Emerging Technologies reached the topic of RPA, under Smart Robots in 2017. What happens after the hype – does RPA make the transition to the productive phase?

1.3 Research question

The so-called "long tail tasks account for a significant proportion of the activities in a company, including those of the author. For this reason, the approach and potential of RPA seems promising, which is why the following research questions are to be answered in the context of this master's thesis:

1. What are the characteristics of RPA systems? What are the fundamental differences between BPMS and RPA systems?

working hypothesis: Highly structured routine tasks that were previously performed by humans are being taken over by robots. The robots are not programmed, but configured by experts without programming knowledge. The integration takes place via the user interfaces. No changes are made to the existing system and no technical interfaces are used. The main distinguishing feature to BPMS is the type of integration. BPMS uses application programming interfaces, web services or similar technologies as access to third-party systems, whereas RPA systems directly control the existing user interfaces (Allweyer, 2016).

2. What are the key success factors in the introduction of an RPA system in companies?

working hypothesis: The success factors are manifold. Automation using RPA is not used to solve problems in the processes, which is why the processes should be optimized before using RPA. "The digital input must be accurate and structured" (ATKearney & Arvato, 2018, S. 7). All stakeholders must be involved in communication at an early stage. With a Proof of Concept (PoC), which quickly shows success and thus creates trust, should be started. The implementation design should take into account the entire affected team, as roles and organizational structures will change. An agile procedure methodology should be chosen in which in Sprints is tested and refined (ATKearney & Arvato, 2018).

The first research question focuses on what characterizes RPA systems and how they differ from BMPS. The reader should be picked up thematically. The answer to this question takes place in the context of a literature search.

The second research question forms the core of the thesis and deals with the central success factors of an RPA system introduction. The thesis focuses on a series of practice-oriented interviews that address the core research question from the point of view of users./Application Managers, manufacturers and consultants.

1.4 Objectives, delimitation of content

A first and at the same time priority goal of this Master's thesis is to answer the mentioned research questions systematically, methodically correct and at the same time well-founded and to refer to the developed working hypotheses.

1.4.1 Target groups

In the search for interview partners, a conscious focus is placed on the financial services industry, in which the author himself is also active. The results may therefore include specific elements of the financial services industry. Basically, this master's thesis is aimed at a specialist audience who is interested in new findings about RPA and, if necessary, considers the introduction of an RPA system. The following objectives and content-related boundaries apply to this Master's thesis:

1.4.2 Objective

1. It should be explained in a comprehensible way what exactly is understood by RPA and thus a clear understanding of RPA terms should be created.
2. On the basis of a literature search, the question is answered as to how BPMS and RPA systems differ fundamentally. These remarks are deliberately held in a compact manner due to the thematic framework.
3. The focus is on interviews with users/application managers, manufacturers and consultants. The qualitative and practice-oriented data collection pursues the goal of providing a circle of interested parties with inputs for an RPA implementation and advice on the associated challenges.

1.4.3 Demarcations

1. The introduction of RPA systems often takes place in the context of higher-level digitization strategies, which are not considered in more detail in this thesis due to reasons of effort and time.
2. The evaluation process of an RPA system is not part of this thesis. In most companies – and thus also in that of the author – standardized procurement processes have been established, according to which the evaluation of an RPA system can also take place. In this context, this thesis does not develop or even evaluate a landscape of available RPA systems, but refers to already published landscapes of consulting companies.
3. The thesis does not contain any technical aspects of the functioning of specific RPA systems or their technical integration in the company.
4. In order to answer the first research question, what are the characteristics of an RPA system, the basic distinction to BPMS is discussed, among other things. However, the thesis does not deal with BPMS in detail, but only to the extent necessary for differentiation from RPA systems.
5. In the context of this thesis, the procedure for identifying suitable processes for automation using RPA is examined in more detail. However, the development of a catalogue of criteria is not part of this thesis (publications are already available).
6. The next stage in the development of RPA systems is seen as the combination of RPA with artificial intelligence (AI) approaches. In this context, there is also talk of intelligent robots. The combination of RPA and AI is currently still the subject of research and has not yet reached market maturity (Czarnecki & Auth, 2018). In the context of this thesis, therefore, the approaches of AI are not considered and the focus is on the so-called simple RPA applications (Scheer, 2017a, S. 35).

1.5 Structure and procedure

This thesis is divided into five parts: Introduction, theory, methodological approach, empiricism and conclusion. In the theoretical part, an overview of the existing literature on the topic of RPA is created by discussing the current state of research, the basics and the typical areas of application of RPA so far. Furthermore, the benefits and challenges of RPA are examined. How to deal with certain challenges is then shown by published success factors and recommendations. The literature is to be condensed in order to enable the investigation of the nuclear research question of success factors in the introduction of an RPA system. At the end of the theoretical part, the findings from the theory are compared with the working hypothesis.

In the third part, the methodological approach, i.e. how the findings were gained, is shown. Qualitative research is discussed and its use justified. For the data collection, the interview guidelines were developed based on sensitizing concepts. The key questions translate the question of nuclear research and the findings of theory in the form of questions to empiricism. For the subsequent evaluation of the transcribed interviews, a category system was set up as part of a qualitative content analysis.

The results of the discourse with empiricism are described in the fourth part along the category system and substantiated with quotations.

In the fifth part, as a summary, the findings of empiricism are compared with the findings of theory and a conclusion is drawn about the answer to the nuclear research question. The research process is followed by a critical appreciation of the results. The present thesis is rounded off with a brief outlook on further research needs and a concluding remark.

The following figure serves as a red thread and thus visualizes the path from the research problem to the conclusion. In the left area of the figure, the different parts of this thesis are visible (marked in grey), while in the middle area the essential steps of these parts are listed (marked in blue) and to the right of them further additions (marked in yellow).

Abbildung in dieser Leseprobe nicht enthalten

Figure Structure and procedure of the thesis

Source: based on Meier (2018)

2 Theoretical part

At the beginning of the theoretical part, it is shown how the literature search was carried out in order to achieve the widest possible coverage in the context of the research questions.

2.1 Literature research

The so-called 'snowball principle', in which well-known titles are navigated from bibliography to bibliography, enables the rapid collection of literature. In order for the research to produce results that are as broadly based as possible, a systematic and methodological approach was developed within the framework of this work in accordance with the Handout of Economics of the Zentralbibliothek Zürich (2018) (see figure below).

Abbildung in dieser Leseprobe nicht enthalten

Figure Four steps of research

Source: based on Stettler (2018, S. 3)

In the first step, the preparation, the research questions were broken down into individual key terms and searched for suitable synonyms as well as generic and sub-terms. Based on these terms and the use of Boolean operators, various search terms were then compiled.

Abbildung in dieser Leseprobe nicht enthalten

Source: based on Stettler (2018)

During the preparation, the depth of research was also determined. With the support of the Central Library, the author of this work identified further suitable specialist databases from the subject areas in addition to the library catalogue as part of an individual research consultation. computer science and economics as well as appropriate e-resources and search engines. The following table gives an overview of the selected sources.

Abbildung in dieser Leseprobe nicht enthalten

table : Selected sources

In the second step, the search, all selected sources were searched with the prepared search terms. Depending on the number of results, additional terms such as 'features', 'application scenarios' or 'challenge' as well as the use of wildcards were used.

In the evaluation, the third step, the found literature was reviewed and examined and evaluated according to its quality and relevance with regard to the research questions.

In further processing, the fourth and final step, the Alerting Services of the sources. With the help of this function, search terms can be stored, whereby a message by e-mail is sent for newly available publications. In this way, it was possible to ensure that current publications were taken into account.

In the following, the theoretical foundations that are necessary for the understanding and implementation of the methodological approach are considered.

2.2 State of research

For more than 130 years, companies have been trying to increase the efficiency of the organization by looking at structure, unified, and measure work. As a consequence, the employees became robots, so to speak. Software such as RPA now makes it possible to reverse this development by supporting employees and focusing them on those tasks that require human strengths such as creativity and judgment, thus increasing job satisfaction and the potential of the company (Lacity & Willcocks, 2016, S. 41).

In industry, robots are already a familiar image and dominate entire production lines. They can work independently around the clock, make no mistakes, do not get tired and can be flexibly configured for new activities within the scope of their possibilities. These features are also attractive for office tasks. Various applications in use should therefore also be operated in the office by so-called software robots (an RPA system). Tasks that are frequently repetitive, controlled by rules, and with few exceptions are in the sights of this automation. The software robots thus behave like employees and carry out the work steps as previously carried out by the employee. For this reason, the applications do not have to be changed and are quasi an automation of the automation (Scheer, 2017a, S. 29-30). In the following chapter 2.3 discusses in detail how RPA works and the characteristics of RPA systems.

As in the introduction under Chapter 1.2 , numerous case studies and surveys on RPA have been published in the last two to three years. Based on positive experiences in projects that have already been implemented, consulting institutes assume a rapidly growing demand for RPA systems. This is how A.T. Kearney predicts in the study 'Robotic Process Automation – The impact of RPA on finance back-office processes' (2018)that the global market volume will have reached around five billion by 2020, compared to 120 million in 2012 (ATKearney & Arvato, 2018, S. 1). According to KPMG (2016) the question is not whether RPA should be introduced, but which way is best for the company to introduce RPA (KPMG, 2016, S. 12). The automation possibilities with Robotics counts KPMG (2016) on the most significant future opportunities for global capital markets and the financial services industry (KPMG, 2016, S. 4). Deloitte (2016) sees Switzerland in particular as an attractive location for automating processes using RPA for the following four reasons. (Deloitte, 2016, S. 6):

- Strict data protection law, which makes alternatives such as outsourcing processes to near- or offshore locations more difficult.
- expensive labor (RPA helps to increase efficiency and thus save costs)
- high level of education (RPA frees up resources and enables focus on value-adding activities)

According to Jürgen Nöther (2018), Managing Director of VR FinanzDienstLeistung GmbH, a subsidiary of Berliner Volksbank, the bank's internal processes will be revolutionized in the coming years as part of the wave of digitization. "In the future, the focus of process management will be on the automation of complete process chains with the help of software robots and digital assistants" (Nöther, 2018, S. 68). In the long run, a bank or insurance company can only survive if it can meet the needs of customers quickly and at the same time work efficiently and cost-effectively, which can only be achieved by using more and better technology. (Singh, 2018, S. 39).

"RPA is a catalyst," said Cathy Tornbohm of Gartner Consulting (2018) in an interview and wants to express that RPA can be used as a catalyst for change on a company's digital journey (Weldon, 2018, S. 3). In this context, RPA can also be seen as an entry-level technology for intelligent process automation (Bremmer, 2018b; Ostrowicz, 2019, S. 1). Companies can lay the foundation with the early introduction of RPA to use robot software of the next stages in addition in the future (see figure below).

Abbildung in dieser Leseprobe nicht enthalten

Figure 4-stage model for intelligent process automation

Source: Ostrowicz (2019, S. 1)

The 4-step model shows that RPA is seen as an entry point. The different stages do not replace each other, but are used in different areas. In the second stage, under Cognitive Automation Software from the field of Machine Learning, which can recognize unstructured data and process it by means of an algorithm that is constantly improving itself. Digital Assitants, the third stage, are used in communication with people and process text and speech. the Autonomous Agents form the fourth and highest level and take on tasks and decisions such as autonomous driving. While the first three stages are already establishing themselves, the fourth stage is still a dream of the future and so far only very few companies have approached the Autonomous Agents in use (Ostrowicz, 2019, S. 1-2).

This thesis focuses on the introduction of RPA systems and thus on the first stage of the 4-step model. The differentiation from robots with cognitive abilities of the 2nd-3rd level is examined in more detail in the following chapter, which deals with the term RPA in advance.

2.3 RPA Basics

2.3.1 Terms

The use of the term RPA is not always completely uniform and is partly mixed with cognitive concepts. The essential characteristics of RPA can be described as follows (Allweyer, 2016, S. 2):

- Highly structured routine tasks that were previously performed by humans are being taken over in whole or in part by robots.
- Subject matter experts who do not need to have any programming knowledge configure the robot, i.e. there is no conventional programming.
- The integration of the applications involved takes place via the user interface. No changes are made to the applications and no technical interfaces are used.

To better distinguish between RPA and cognitive concepts, it is recommended to focus on performance characteristics. In RPA, they are characterized by structured data with rule-based processes and a clearly defined outcome, while in cognitive automation, it is unstructured data with conclusions and a set of various possible outcomes (see figure below). (Lacity & Willcocks, 2016, S. 43).

Abbildung in dieser Leseprobe nicht enthalten

Figure Features RPA vs. cognitive automation

Source: based on Lacity & Willcocks (2016, S. 43)

Protiviti (2019) distinguishes between RPA and RDA, the latter for Robotic Desktop Automation Is. While the focus of RPA is on the automatic, independent processing of processes with very few or no human intermediate steps (unattended), RDA's focus is clearly on robot/human interaction. RDA can be compared to a wizard that performs certain tasks on offense (protiviti, 2019, S. 2).

A differentiation into RPA and RDA as well as software robots with cognitive abilities can be found in Kleehaupt-Roither and Unger (2018) again. They distinguish between the three following archetypes of software robots (Kleehaupt-Roither & Unger, 2018, S. 50-51):

RPA – 'The Autonomous Worker'

With RPA, the robot works in the background and the full automation of large-volume tasks with structured data as input and output is in the foreground. Robot/human interaction is low and limited to strict rule-based collaboration.

RDA – 'The Constant Companion'

With RDA, the robot does not have its own identity from a technical point of view, which means that it acts via the role and access reports of the user employee. The employee can assign tasks to the robot at the push of a button. For this reason, it is often used in call centers so that employees have to interrupt the customer conversation as little as possible and can delegate routine tasks ad-hoc.

Software robots with cognitive abilities – 'The interaction and analysis professional' Thanks to cognitive abilities, the robot can also process unstructured information such as speech or images. The process sequences are not permanently stored as with RPA and RDA, but trained models of machine learning are used.

In order to be aware of the possibilities of a touted software robot, especially in the diverse marketing and keyword jungle of the numerous manufacturers, it is crucial to recognize which archetype it is. On the one hand, the technological basis differs as well as – which is particularly decisive – the procedure and the use of the respective software robot (Kleehaupt-Roither & Unger, 2018, S. 50).

The focus of this thesis is the introduction of software robots of the first mentioned archetype. If a robot is mentioned below without further specification, it refers to an RPA software robot.

Although the term RPA is based on physical robots, it is based exclusively on software systems. A robot therefore corresponds to a software license. An RPA system is a software solution with which robots can be configured and operated (Willcocks, Lacity, & Craig, 2015b, S. 5).

The following subchapter discusses how RPA systems work in principle. Their characteristics are also discussed in more detail.

2.3.2 Functionality and features of RPA systems

"In the narrower sense, RPA is not an automation solution, but a virtualization solution." (Kleehaupt-Roither & Unger, 2018, p. 52). Robots work as virtual employees and operate the target applications via the user interface on a virtual instance. How the task is performed does not change, only the where (Kleehaupt-Roither & Unger, 2018).

The interaction with the target applications takes place exclusively via the user interface, which is why no changes to the applications are necessary. This circumstance is a significant difference to the traditional approaches of process automation, where adjustments are made, for example, by technical modulations within the application or with the help of a BPMS, which communicates with the application via a technical interface. (Czarnecki & Auth, 2018, S. 116-117).

The following figure shows the basic architecture of RPA. Just as humans perform their tasks via the presentation layer (user interface), the robot also enters data via the presentation layer and reads it out again. Other layers such as processing (also called application layer) and data storage do not have to be changed or addressed directly.

Abbildung in dieser Leseprobe nicht enthalten

Figure Basic architecture of RPA

Source: based on Czarnecki & Auth (2018, S. 117)

The automation of user input is not new and is technically due to so-called user input. Screen Scraping Tools, but the functionality of RPA systems is much broader and more flexible (Czarnecki & Auth, 2018, S. 50). Instead of pixel-precise information about the position of fields and functions, RPA can recognize the logical structure of the user interface and be used to assign data or sequence steps. For example, minor changes to the user interface require little or no customization of the configured robot, but must be done with caution or tested well. If the affected target application is subject to a release cycle that can potentially change the user interface, the tasks automated with the robot must be tested (Allweyer, 2016, S. 3).

Basically, the automation of complete processes is aimed at from a technical point of view, but depending on the RPA system and manufacturer, the functionality can vary. Since the configuration with the help of RPA does not require traditional programming, it can be implemented by specialist departments (Czarnecki & Auth, 2018, S. 117), for example, by creating a flowchart by listing the individual steps of the tasks to be completed and, if necessary, the necessary decision rules as well as the different paths. Some RPA systems offer the possibility to record the activities of the employee when completing a task in order to be able to generate the flowchart, which is then configured. Although the configuration of a robot does not require any technical knowledge, it does require detailed training and introduction to the respective RPA system. (Allweyer, 2016, S. 3)

The robots are assigned passwords that authorize them to access the required applications. Below is a small selection of typical functions that robots can perform (Scheer, 2017a, S. 35):

- Fill in masks
- Extract data
- Perform calculations
- Open e-mails
- Create reports

In the simplest case, the installation of an RPA system takes place locally on an employee's workstation computer in order to automate the routine tasks that arise. However, the central installation in the IT landscape of a company offers much greater optimization potential. For example, the robots can be controlled centrally, which also enables central monitoring of current and completed tasks as well as any exceptional situations (Allweyer, 2016, S. 2).

The market for RPA systems offered is still highly fragmented. The current leading providers are UiPath, Blue Prism as well as Automation Anywhere and are also strongly represented on the market Pegasystems, Nice, Edgeverve, Kryon, Kofax and Thoughtonomy (Bremmer, 2018b, S. 2). An overview of the main suppliers can be found in Annex 6.4.5.

As mentioned earlier, RPA differs from traditional approaches to process automation such as BPMS in terms of architecture. In the following, the differences between RPA and BPMS are analyzed in more detail.

2.3.3 RPA systems versus BPMS

The introduction mentioned how BPMS works. With the help of a central Process Engine BPMS sets up tasks according to the process model and thus passes on data from application to application. The connection or integration of the applications is traditionally done via the application layer, in English often business logic layer called. At best, the application offers existing interfaces on this layer, so-called "interfaces". application programming interfaces (API), which cover the requirements. Depending on the application, however, the API must be extended or even newly developed, which is time-consuming and costly. (Cewe, Koch, & Mertens, 2018, S. 643).

The result of a BPMS introduction – i.e. the process logic created, including application integration via API – represents a new application. In RPA, on the other hand, the robot performs tasks over the presentation layer like an employee (cf. 2.3.2) and no new application is created. This is how testing differs: While BPMS tests a new application, RPA only requires checking the result or output of the automated task (Cewe, Koch, & Mertens, 2018, S. 644).

The goals of BPMS and RPA solutions are very similar: automated task processing as consistently as possible without system breaks (Allweyer, 2016, S. 7). With RPA, cost savings can be achieved by reducing the number of user actions, while BPMS focuses on optimizing the processes themselves. RPA and BPMS complement each other (Cewe, Koch, & Mertens, 2018, S. 644).

Based on numerous studies, Willcocks, Lacity and Craig (2015b) the following two main differences (Willcocks, Lacity, & Craig, 2015b, S. 6-10):

RPA is Lightweight IT and does not affect the other applications.

This point largely coincides with the fact already described above that RPA, in contrast to BPMS, does not require any adjustments or new interfaces to the applications thanks to integration via user interfaces. under Lightweight IT will be a software, which can also be introduced without the involvement of the IT department.

RPA is easy to configure and requires no programming knowledge.

Employees who have specialist knowledge of the tasks to be automated can configure the robots within a few weeks (cf. 2.3.2).

Willcocks, Lacity and Craig (2015b) also conclude that RPA and BPMS complement each other and are suitable for different process types. BPMS is used to automate processes that are central and common, so that the usually high investments are justified. BPMS solutions are implemented by the IT department in cooperation with the specialist departments, while RPA is suitable for processes that also follow a structured process and could therefore be automated with BPMS, but occur too rarely to justify the necessary effort (cf. 1.1). RPA solutions can be implemented by the specialist department, whereby an early involvement of IT is recommended (cf. Fehler! Verweisquelle konnte nicht gefunden werden.) (Willcocks, Lacity, & Craig, 2015b, S. 8-9).

The following table summarizes the differences between RPA and BPMS in an overview:

Abbildung in dieser Leseprobe nicht enthalten

table : Differences RPA – BPMS

Source: based on Cewe, Koch, & Mertens (2018, S. 644) Willcocks, Lacity, & Craig (2015b, S. 9)

2.3.4 Conclusion first research question

After dealing with the terms around RPA, the analysis of the functioning and features of RPA systems and the demarcation of BPMS, the chapter on the basics of RPA closes. Based on these findings, it is possible to return to the first research question and make a comparison to the working hypothesis. In the following table, the various elements of the working hypothesis are compared with the findings from the theoretical part. For the sake of clarity, only a few examples are listed in the column with the findings, which also applies to the literature citations.

[...]

• Author: Björn Freivogel (Author)
• Publication Year: 2020
• Pages: 103
• Catalog Number: V1175611
• ISBN (PDF): 9783346586551
• Language: English
• Tags: robotic, process, automation, success