Robotic process automation


Within digital transformation, which is continuously progressing, robotic process automation (RPA) is drawing much corporate attention. While RPA is a popular topic in the corporate world, the academic research lacks a theoretical and synoptic analysis of RPA. Conducting a literature review and tool analysis, we propose – in a holistic and structured way – four traits that characterize RPA, providing orientation as well as a focus for further research. Software robots automate processes originally performed by human work. Thus, software robots follow a choreography of technological modules and control flow operators while operating within IT ecosystems and using established applications. Ease-of-use and adaptability allow companies to conceive and implement software robots through (agile) projects. Organizational and IT strategy, governance structures, and management systems therefore must address both the direct effects of software robots automating processes and their indirect impacts on firms.

The emergence of robotic process automation

Digitalization is no longer a marginal phenomenon or a buzzword. ITs constantly evolve and bring about new products and opportunities (Vedder and Guynes 2016). Thus, today’s business environments face continuous digital transformation, leading to multifaceted information systems (IS) topographies (Vom Brocke et al. 2018). Within digital transformation, neither automation nor robotics are new developments. In the past few years, robotic process automation (RPA) has drawn much corporate attention concerning automation initiatives. According to Information Services Group (2018), 54% of European companies plan to automate at least 10 processes via RPA by 2020. Among others, accomplishing non-value adding activities (cost-)efficiently and in a scalable manner as well as reducing turnaround times are motivating companies to automate these processes using software robots (Sutherland 2013). RPA is interesting to companies that pursue an operational excellence strategy, although RPA’s use should not be limited to this strategy.

However, the academic research lacks a theoretical and synoptic analysis of RPA. Responding to the call by Van der Aalst et al. (2018), we seek to shed light on the academic discourse about RPA. To capture all relevant knowledge on the topic, we first conducted a systematic literature review (Webster and Watson 2002; Okoli 2015) in which we searched different electronic databases (AIS eLibrary, EBSCO, IEEE Xplore, JSTOR, ProQuest, Science Direct, Springer, Web of Science) and the major IS conferences (AMCIS, ECIS, ICIS, PACIS, HICCS), using “robotic process automation” and combinations of “automation,” “robot,” “software,” and “bot” as keywords. Complementing the initial set of publications, we conducted a backward-and-forward search. We also analyzed existing tools in an inductive reasoning process, adapting Thomas’s (2006) process steps. To ensure an unbiased approach towards the analysis, we collected a library of functional elements by examining features that are offered to users within the tool to build robotic process flows. Based on this we created and continuously reevaluated categories of functional classes. We selected tools that offer commercial solutions, enclose a variety of functionalities, operate in multiple regions and industries and are sold by key market players (Le Clair 2017, 2018). While there are other tools on the market, we only chose freely available ones for our analysis to guarantee transparent and reproducible results. As the analyzed tools offer the same or very similar functionalities in accordance with the existing literature, we do not expect additional insights by incorporating further tools in our analysis.

These methodological approaches allowed us to integrate and organize available knowledge, while also providing orientation and a focus for further research into RPA. We did not confine ourselves solely to RPA, but also examined its relationships to other technologies and research fields.

Characterizing robotic process automation

To characterize RPA in a structured way, we introduce the main characteristics of RPA in Fig. 1 by emphasizing four major traits. In our elaboration, we follow the extensive understanding of the IEEE Corporate Advisory Group (2017, p. 11), which defines RPA as the use of a “preconfigured software instance that uses business rules and predefined activity choreography to complete the autonomous execution of a combination of processes, activities, transactions, and tasks in one or more unrelated software systems to deliver a result or service with human exception management.”

Fig. 1

The nature of robotic process automation

Software robots automate processes originally performed by human work

RPA is an approach to automating processes within a broad pool of different technologies for process automation, each of which suits different processes and objectives (Willcocks et al. 2015b). In situations in which human labor or the construction and integration of business process management systems (BPMS) are too expensive or not justified by business needs (Lu et al. 2018), RPA serves as a transition element between human work and extensive business process automation (Van der Aalst et al. 2018). Thus, so-called software robots access systems and perform tasks for the most part similar to humans or by imitating them (Lacity et al. 2015; Moffitt et al. 2018; Van der Aalst et al. 2018). The automation of processes by means of RPA can also refer only to the automation of individual activities or even tasks. A software robot for example opens a new instance of Microsoft Excel, navigates to a specific spreadsheet, changes values in certain cells, and saves the spreadsheet before closing the application. In contrast to RPA automating processes in a more or less unattended way, robotic desktop automation (RDA) focuses on attending humans in tasks such as front-office functions (Evans 2017; Seasongood 2016). Nonetheless, RPA and RDA do not follow completely different concepts or objectives.

Choosing the right approach for the automation of processes requires one to consider many aspects, including organizational capabilities, available finances, and required time. To date, a process is especially suitable for RPA if it among others follows a standardized, rule-based structure (i.e. does not require cognitive or judgment effort), is conducted both often and manually by humans, and requires multiple-system access (Aguirre and Rodriguez 2017; Asatiani and Penttinen 2016; Fung 2013; Lacity and Willcocks 2016a; Moffitt et al. 2018). Since back-office processes typically have these characteristics, they often become the application area of RPA (Aguirre and Rodriguez 2017). These processes include for instance repetitive tasks such as periodic reporting (including some form of data analysis), data entry, the generation of mass e-mails, archiving, and the conversion of data format and graphics.

With software robots autonomously executing their choreography uninterruptedly, quickly, flawlessly, and traceably, RPA promises to improve process performance, efficiency, scalability, auditability, security, and compliance while at the same time being easy to implement at relatively low costs compared to traditional process automation (Asatiani and Penttinen 2016; Fung 2013; Lacity et al. 2015; Lacity and Willcocks 2016b; Lacity et al. 2017; Vom Brocke et al. 2018). Thus, RPA may help to improve process key performance indicators (KPIs), even though software robots do not engage in improving the processes themselves. If software robots execute predefined process flows on the basis of processes that contain inefficiencies or errors, they will also execute inefficient process steps, causing additional costs and superfluous resource use. Thus, process improvement and optimization prior to automation are crucial steps. Besides redesigning the process beforehand, it is essential to sustain RPA improvements once implemented. One may follow the Six Sigma methodology (Linderman et al. 2003) and specify for instance a maximum error rate for the software robot to still be effective.

Since RPA automates repetitive and often tedious tasks that require little mental effort (Forrester Research 2014; Leopold et al. 2018), human workers would be freed to invest their resources in tasks that require creative thinking, intellectual judgment, or social skills (Lacity and Willcocks 2016b; Willcocks et al. 2015a). For instance, software robots can support labor in preliminary work such as collecting and preprocessing information. Yet, process automation via RPA does not rely on the premise of separating and isolating humans and robots from one another, but seeks to enable efficient interaction between them (e.g. by humans handling exceptions to an automated process) (Hallikainen et al. 2018; Lacity and Willcocks 2016b; Van der Aalst et al. 2018). Human workers can be relieved of all repetitive and tedious tasks. However, human exception management limits the autonomy of software robots, since humans may have to manage exceptions that require some cognition, intuition, and situational decisions. The needed human-robot interaction level, as well as the development of RPA capabilities, influence the decision to deploy an RPA project. Also, automated processes are not limited to one department or process – process owners can re-use activities and execution logic.

Software robots follow a choreography of technological modules and control flow operators

RPA development environments provide intuitive user interfaces that foster usability and rapid implementation of software robots. Thus, users build software robots by arranging a sequence of configurable modules and control flow operator to create a choreography according to business rules (Aguirre and Rodriguez 2017; Lacity and Willcocks 2016a). A recording function often facilitates this process, since it allows one to construct robots by tracing the execution of the tasks by the user (Moffitt et al. 2018). In contrast to developing and changing interfaces of back-end systems or underlying programs (which can be the case for BPMS), a user can easily create and reconfigure software robots by deleting, adding, moving or reconfiguring elements. Thus, it is not necessary to introduce new ISs or to (extensively) change them (Lacity and Willcocks 2016a; Van der Aalst et al. 2018). However, the distinction between RPA and other automation solutions concerning the extent of system integration or necessary adaption is fluent. To profoundly determine the core capabilities of RPA and its functions, we analyzed three RPA tools: UiPath, WorkFusion, and Kryonsystems. The results indicate three superordinate functional areas: dealing with data, integration of systems, and process enhancement. In turn, these functional areas cluster software robots’ functionalities into eight functional classes that summarize RPA abilities’ scope on an aggregated level. Data-related functions enable data transfer, the modification of file formats, and the analysis of data. Since business processes often generate data decentrally, in different forms, and data structures, software robots provide an integrating function. These integration-related functions allow software robots to control or access applications and services automatically and to link existing data silos. Software robots’ process-related functions include event triggers and control flow operators. Table 1 summarizes the functional classes of software robots resulting from our analysis of the three tools.

Table 1 Functional classes of software robots

By combining these functional elements to a choreography in a modular way, a software robot performs an automation task. One use case for software robots is to use them to automatically transfer data from one application to another. Thus, the software robot would at least consist of an application operator (accessing the application and retrieving application data), data transfer (i.e. data caching), and another application operator (save data to the application). Owing to the differences in the complexity of data-related functions, one should distinguish between software robots using structured data (e.g. electronic records) and those using unstructured data (e.g. freeform notes from employees). Following Kroll et al. (2016), one may differentiate software robots in rule-based, knowledge-based, and learning-based software robots. While rule-based software robots repeatedly apply predefined rules, knowledge-based software robots search for information across systems. Learning-based software robots may apply machine learning methods to learn its functions from given data (Kroll et al. 2016). However, to date, rule-based software robots have been the main focus (Aguirre and Rodriguez 2017; Asatiani and Penttinen 2016; Lacity and Willcocks 2016a; Moffitt et al. 2018). Also, software robots differ concerning their extents of automation. Software robots may involve tasks that either work with employee intervention (i.e. attended) or without any human intervention at all (i.e. unattended). In sum, data usage (i.e. unstructured and structured data), programming (i.e. rule-based, knowledge-based, and learning-based), and the extent of automation (i.e. attended and unattended) are some dimensions to characterize the different software robot archetypes. These dimensions allow one to distinguish for instance between software robots used for simple screen scraping and those used to detect fraud.

Software robots operate within IT ecosystems and use established applications

Since companies use a wide range of ISs and applications with different functionalities and compatibilities, and of different ages, RPA in many cases is an attractive solution. Thus, software robots interact with ISs and applications with different layouts and interfaces by accessing them mainly via the front-end – the same way a person would (Bygstad and Iden 2017; Van der Aalst et al. 2018). Software robots therefore work with systems in the presentation layer in the sense that the execution of the software robot in an IS ecosystem does not impact on the underlying infrastructure of the business logic and on the data access layers (Lacity et al. 2015; Lacity and Willcocks 2016a). However, our tool analysis indicates that RPA also includes elements of accessing business logic and data access layers. Thus, restricting software robots to only actions within the presentation layer does not use RPA’s full potential. Examples include the functional elements of application operator, data transfer, and (cloud) service operator. Within these functional classes, a software robot accesses among others ISs and executes database queries, connecting to applications and cloud services such as Twitter via an application programming interface (API).

However, to enable effective (front-end) automation, the underlying infrastructure and systems must be robust and capable of operating RPA (Lacity et al. 2015; Penttinen et al. 2018; Willcocks et al. 2015b). Since the implementation of RPA does not invade existing infrastructures (Mendling et al. 2018; Penttinen et al. 2018), RPA qualifies as lightweight IT (Bygstad 2015; Penttinen et al. 2018; Willcocks et al. 2015b). In this context, effectiveness depends on the ways lightweight and heavyweight ITs complement one another in their interactions (Bygstad 2015).

Projects conceive and implement software robots

As the analysis of different RPA tools demonstrates, depending on the task, no specialized programming knowledge is required for developing software robots. Nonetheless, a basic understanding of IS functionalities is necessary, such as the structure of rule-based systems (e.g. loops, conditions, parameters), the use of data (e.g. data formats), and the interfaces to applications. While this fairly low IT complexity makes RPA an easy-to-use tool for different people and functions in a business, profound process knowledge is a decisive factor in software robot construction (Willcocks et al. 2015b). Process owners may become the initiators of innovation in a company (Bygstad and Iden 2017) and lead RPA projects by involving relevant stakeholder groups to develop software robots according to specific process steps and business requirements (Lacity et al. 2015). Stakeholder involvement decisions must be based on the specific RPA project goals and must include representatives of all affected functional business areas (e.g. IT, controlling, and human resources). Particularly, cooperation between business and IT functions in developing and deploying software robots is beneficial. Thus, IT functions can for instance facilitate software robots’ access to enterprise resource planning (ERP) systems. Thereby, the required involvement of IT functions differ, depending on given project requirements, so that project management must define suitable configurations of accountability, scope, governance, staffing, and integration (Jöhnk et al. 2017). As a result, process owners can enable the automation of their processes according to the specific process needs. Owing to RPA functions’ modularity and to short development times, employees can develop new functionalities or can agilely adjust existing ones. Automation projects approached this way require few additional resources (Aguirre and Rodriguez 2017), and make it possible for each of the involved actors to focus on their specific responsibility, enabling stable and safe processes that are also quick to implement and modify (Bygstad and Iden 2017). This approach enables businesses to increase their agility and to react quickly to changing environments and market conditions. Further, by storing and providing re-usable and scalable modules or whole choreographies (Fung 2013), RPA enables synergies in automation across business departments. Thus, automated processes are not limited to one department or process; process owners can re-use activities and execution logic in different contexts.

Notably, introducing RPA in a firm requires a strategic management approach to conduct the implementation process, since RPA affects not just one department of a business unit, but involves cooperation between different actors through projects (Bygstad et al. 2017; Bygstad and Iden 2017). Since RPA is still a form of IT, it cannot be regarded solely from a business operation perspective; IT personnel (i.e. IT executives, developers, and operators) must be included in the decision process regarding for instance the deployment of and security surveillance over software robots. However, the cooperation between business and IT personnel regarding RPA management will be different compared to conventional IT projects (Fersht and Slaby 2012). Thus, IT personnel could consider agile methods in their cooperation with process owners. Using agile methods allows one to address business demands compliantly and rapidly. Thus, introducing RPA into a company may lead to the necessity to redesign the (IT) organization regarding agility (Jöhnk et al. 2017).

Conclusion and questions to answer

With software robots autonomously executing their choreography uninterruptedly, quickly, flawlessly, and traceably while at the same time being easy to implement at relatively low costs compared to traditional process automation, RPA comes along with both qualitative and quantitative objectives. Organizations may apply RPA for one or more objectives such as process performance, efficiency, scalability, auditability, security, convenience and compliance. However, organizations should consider the advantages and disadvantages of RPA against other automation approaches such as workflow automation. Hence, organizations should embed RPA, as one of several automation approaches, in organizational methodologies supporting process automation.

RPA may automate processes enabling business transactions and therefore impact organizations and its electronic markets. Among others, RPA may change how organizations interact in procurement and warehousing (Kroll et al. 2016). There are potential use cases, for example, in data mapping, quantity management, contract management, and supplier relationship management. Thus, research should not only take a technological perspective, but also discuss the application of RPA (Alt, 2018). In addition, we motivate to investigate the impact of automation activities at the interface of electronic markets and other organizations.

However, some complain that RPA is not as good as back-end process automation solutions and is only a provisional step between human work and process re-engineering and redesign (Asatiani and Penttinen 2016). The organizational strategy must address both the direct effects of software robots automating processes and their indirect impacts on the organization. The organizational impacts include RPA deployment’s implications for human labor, the process landscape, and IS ecosystems. Thus, researchers should address software robots’ impacts on organizational and IT strategies, leadership, governance, and management systems, so as to derive the most suitable paths for managing RPA in organizations (Vom Brocke et al. 2018). This may include for instance discussing the applicability of governance approaches such as bimodal IT or the laissez-faire model (Bygstad and Iden 2017; Jöhnk et al. 2017).

While RPA may automate processes faster and easier, governance structures may become more challenging and complex. Thus, it strongly depends on every organization whether it regards RPA as only a temporary solution or if it plans to engage RPA as part of its strategic capability. Researchers may discuss which strategic approaches to RPA solutions should be chosen to design the implementation process and the ongoing management of software robots in a successful and sustainable way. The agile deployment of RPA projects brings about the necessity to consider short-term and long-term influences as well as necessary changes to strategic organization designs. As with any major decision in an organization, decision-making in the context of RPA must follow a strategic approach. Researchers should seek to determine what kind of strategic approach is suitable, given different RPA implementation goals. Considering a human labor perspective, researchers may consider the design of human-robot interaction patterns as well as RPA’s potential future impacts on employees and their perceptions of software robots. Inquiry into possible human-robot interaction schemes will help us to analyze RPA’s influences on the human workforce. In this context, strategic initiatives to deploy RPA should consider employee engagement, skills development, and sourcing decisions. Given changing areas of responsibility, companies need to rethink employees’ roles. Organizations need to decide if they want to apply RPA using their own resources or by engaging outsourcing providers (Vedder and Guynes 2016). As organizations can incorporate RPA through different sourcing alternatives (Lacity and Willcocks 2016b), outsourcing service providers may need to rethink their strategies and offerings.

Following a process perspective, it is necessary to integrate RPA initiatives with alternative process automation and optimization approaches (Lacity et al. 2015; Willcocks et al. 2015a). Specifically, not optimizing existing processes may lead to inefficient implementations of software robots that therefore do not deliver the expected organizational advantages. Since implementing RPA in companies is much more than just replacing people with software robots, we recommend research into suitable procedures to implement software robots in daily process routines. Here, a proposed method may guide among others the identification of relevant processes, deciding between process automation alternatives, and integrating human exception management. The method could also incorporate the state of the current process and thus the need for process redesign.

Decision-makers need to identify areas with potential for RPA, to select and develop software robots, and to continuously monitor and control them. Besides the apparent potential for short-term return on investment increases (Van der Aalst et al. 2018), decision-makers should consider two general KPI groups for measuring RPA’s business impacts. The first KPI group should focus on software robots’ influences on internal factors, such as employee productivity enhancement, job satisfaction, process acceleration, or cost savings. The second KPI group should consider software robots’ influences on external factors, such as customer satisfaction, cooperation with partners and suppliers, or stock market value. In this context, internal performance factors can be regarded as mediating factors to external performance. Since there are as yet no defined KPIs for the proper evaluation of software robots, researchers may seek to identify suitable performance measures.

Generally, it is key to focus not only on the short-term benefits of applying software robots, but also to concentrate on software robots’ long-term influences on the complexity of IS ecosystems and on the organization as a whole. Thus, decision-making in the context of RPA must have a strategical focus. We contribute to academic literature by characterizing RPA in a holistic and structured way. We recommend that researchers use our framework to evaluate the corporate relevance of the individual traits of RPA (as introduced in Fig. 1) and to describe archetypes of software robots by empirically evaluating the dimensions of RPA. With software robots being able to interact with the business logic and data access layer, we additionally recommend further research to evaluate the possible impact of RPA on the IS infrastructure within organizations. RPA has not yet developed its full potential. Although some companies have already successfully adopted RPA, the practical application of RPA is still in its infancy (Cline et al. 2016; Forrester Research 2017). Some scholars and consultancies claim that RPA is just one step on the way to more intelligent and cognitive automation (Accenture 2016; Berruti et al. 2017; Hull and Motahari-Nezhad 2016; KPMG 2016; Lacity and Willcocks 2016b; Van der Aalst et al. 2018). In this context, researchers should separate de facto implementations of artificial intelligence (AI) from RPA providers or consultancies’ sales pitches. Estimations for the future see RPA’s potential among others in additional modules capable of dealing with unstructured data and processes resulting from the development of new technologies (Lu et al. 2018; Willcocks et al. 2015b) as well as in improved human-robot interactions (Lacity and Willcocks 2016b). Since considering AI in automating processes strongly affects among others human labor, the process landscape, IS ecosystems, and customer experiences, companies require a strategic approach for long-term implementation. Here, analysis techniques (such as in the failure mode and effects analysis) (Teng and Ho 1996) could help to determine the implications of implementing RPA.

Further, we expect vendors of ISs or services (e.g. ERP) to offer technological modules that integrate interfaces to their systems in RPA platforms. However, even with automation becoming intelligent, we still see RPA’s value. RPA has two primary potentials: First, by easily constructing rule-based software robots that interact with different ISs and applications, RPA with its basic functions and capabilities will still allow process owners to automate their human work. RPA will become more intelligent and, in an integrating way, intelligent modules will enable new use cases. However, technological modules such as open character recognition (OCR) already use machine learning-based approaches. RPA’s modularity may motivate firms to provide easy-to-use, intelligent technological modules to a new customer segment. Also, an improved recording function may foster ease-of-use. Second, RPA evolves into some form of cognitive automation. Through AI technologies (e.g. machine learning), future software robots may no longer be rule-based, allowing them to self-reconfigure and to construct new software robots based on the experience of already constructed ones. Future research may longitudinally analyze the development of software robots’ data-related, integration-related, and process-related functionalities so as to analyze the shifts in the RPA market.


  1. Accenture. (2016). Getting robots right: How to avoid the SIX most damaging mistakes in scaling up Robotic Process Automation.

  2. Aguirre, S., & Rodriguez, A. (2017). Automation of a business process using robotic process automation (RPA): A case study. In J. C. Figueroa-García, E. R. López-Santana, J. L. Villa-Ramírez, & R. Ferro-Escobar (Eds.), Communications in computer and information science. Applied computer sciences in engineering (pp. 65–71). Cham: Springer International Publishing.

    Google Scholar 

  3. Alt, R. (2018). Electronic Markets on digitalization. Electronic Markets, 28(4), 397–402.

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

    Article  Google Scholar 

  5. Berruti, F., Nixon, G., Taglloni, G., & Whiteman, R. (2017). Intelligent process automation: The engine at the core of the next-generation operating model.

  6. Bygstad, B. (2015). The coming of lightweight IT. In Proceedings of the 23rd European Conference on Information Systems (ECIS) (pp. 1–16). Münster, Germany.

  7. Bygstad, B., Hanseth, O., Siebenherz, A., & Øvrelid, E. (2017). Process innovation meets digital infrastructure in a high-tech hospital. In Proceedings of the 25th European Conference on Information Systems (ECIS) (pp. 801–814). Guimarães, Portugal.

  8. Bygstad, B., & Iden, J. (2017). A governance model for managing lightweight IT. In Á. Rocha, A. M. Correia, H. Adeli, L. P. Reis, & S. Costanzo (Eds.), Recent advances in information systems and technologies (pp. 384–393). Cham: Springer International Publishing.

    Google Scholar 

  9. Cline, B., Henry, M., & Justice, C. (2016). Rise of the robots.: KPMG.

  10. Evans, G. L. (2017). Disruptive technology and the board: The tip of the iceberg. Economics and Business Review, 3(17)(1), 205–223.

  11. Fersht, P., & Slaby, J. (2012). Robotic automation emerges as a threats to traditional low-cost outsourcing.

  12. Forrester Research. (2014). Building a center of expertise to support robotic automation: Preparing for the life cycle of business change.

  13. Forrester Research. (2017). The new frontier of automation: Enterprise RPA.

  14. Fung, H. P. (2013). Criteria, use cases and effects of information technology process automation (ITPA). Advances in Robotics & Automation, 3(3).

  15. Hallikainen, P., Bekkhus, R., & Pan, S. L. (2018). How OpusCapita used internal RPA capabilities to offer services to clients. MIS Quarterly Executive, 17, 41–52.

    Google Scholar 

  16. Hull, R., & Motahari-Nezhad, H. R. (2016). Rethinking BPM in a cognitive world: Transforming how we learn and perform business processes. In M. La Rosa, P. Loos, & O. Pastor (Eds.), Business process management, Lecture notes in computer science (pp. 3–19). Cham: Springer International Publishing.

    Google Scholar 

  17. IEEE Corporate Advisory Group. (2017). IEEE guide for terms and concepts in intelligent process automation.

    Google Scholar 

  18. Information Services Group. (2018). RPA in Europe: Enterprise plans, budgets and organizational impact.

  19. Jöhnk, J., Röglinger, M., Thimmel, M., & Urbach, N. (2017). How to implement agile IT setups: A taxonomy of design options. In Proceedings of the 25th European Conference on Information Systems (ECIS) (pp. 1521–1535). Guimarães, Portugal.

  20. KPMG. (2016). Transforming business models with robotic process automation: Fulfilling the vision of global business services.

  21. Kroll, C., Bujak, A., Darius, V., Enders, W., & Esser, M. (2016). Robotic process automation: Robots conquer business processes in back offices.: Capgemini Consulting.

  22. Lacity, M., & Willcocks, L. (2016a). Robotic process automation: The next transformation lever for shared services. The Outsourcing Unit Working Research Paper Series.

  23. Lacity, M., & Willcocks, L. (2016b). A new approach to automating services. MIT Sloan Management Review, Fall.

  24. Lacity, M., Willcocks, L., & Craig, A. (2015). Robotic process automation at Telefónica O2. The Outsourcing Unit Working Research Paper Series.

  25. Lacity, M., Willcocks, L., & Craig, A. (2017). Service automations: Cognitive virtual agents at SEB Bank. The Outsourcing Unit Working Research Paper Series.

  26. Le Clair, C. (2017). The Forrester wave: Robotic process automation, Q1 2017. Forrester Research.

  27. Le Clair, C. (2018). The Forrester wave: Robotic process automation, Q2 2018. Forrester Research.

  28. Leopold, H., van der Aa, H., & Reijers, H. A. (2018). Identifying candidate tasks for robotic process automation in textual process descriptions. In J. Gulden, I. Reinhartz-Berger, R. Schmidt, S. Guerreiro, W. Guédria, & P. Bera (Eds.), Enterprise, business-process and information systems modeling, Lecture notes in business information processing (Vol. 318, pp. 67–81). Cham: Springer International Publishing.

    Google Scholar 

  29. Linderman, K., Schroeder, R. G., Zaheer, S., & Choo, A. S. (2003). Six sigma: A goal-theoretic perspective. Journal of Operations Management, 21(2), 193–203.

    Article  Google Scholar 

  30. Lu, H., Li, Y., Chen, M., Kim, H., & Serikawa, S. (2018). Brain intelligence: Go beyond artificial intelligence. Mobile Networks and Applications, 23(2), 368–375.

    Article  Google Scholar 

  31. Mendling, J., Decker, G., Hull, R., Reijers, H. A., & Weber, I. (2018). How do machine learning, robotic process automation, and Blockchains affect the human factor in business process management? Communications of the Association for Information Systems, 43, 297–320

    Article  Google Scholar 

  32. Moffitt, K. C., Rozario, A. M., & Vasarhelyi, M. A. (2018). Robotic process automation for auditing. Journal of Emerging Technologies in Accounting, 15(1), 1–10.

    Article  Google Scholar 

  33. Okoli, C. (2015). A guide to conducting a standalone systematic literature review. Communications of the Association for Information Systems, 37, 879–910.

    Article  Google Scholar 

  34. Penttinen, E., Kasslin, H., & Asatiani, A. (2018). How to choose between robotic process automation and Back-end system automation? In Proceedings of the 28th European Conference on Information Systems (ECIS). Portsmouth, UK.

  35. Seasongood, S. (2016). Not just for the assembly line: A case for robotics in accounting and finance. Financial Executive, 32, 31–32.

    Google Scholar 

  36. Sutherland, C. (2013). Framing a Constitution for Robotistan: Racing with the Machine of Robotic Automation : Hfs Research.

  37. Teng, S.-H., & Ho, S.-Y. (1996). Failure mode and effects analysis. International Journal of Quality & Reliability Management, 13(5), 8–26.

    Article  Google Scholar 

  38. Thomas, D. R. (2006). A general inductive approach for analyzing qualitative evaluation data. American Journal of Evaluation, 27(2), 237–246.

    Article  Google Scholar 

  39. Van der Aalst, W. M. P., Bichler, M., & Heinzl, A. (2018). Robotic process automation. Business & Information Systems Engineering, 60(4), 269–272.

    Article  Google Scholar 

  40. Vedder, R., & Guynes, C. S. (2016). The challenge of botsourcing. Review of Business Information Systems (RBIS), 20(1).

  41. Vom Brocke, J., Maaß, W., Buxmann, P., Maedche, A., Leimeister, J. M., & Pecht, G. (2018). Future work and enterprise systems. Business & Information Systems Engineering, 60(4), 357–366.

    Article  Google Scholar 

  42. Webster, J., & Watson, R. T. (2002). Analyzing the past to prepare for the future: Writing a literature review. MIS Quarterly, 26, xiii–xxiii.

    Google Scholar 

  43. Willcocks, L., Lacity, M., & Craig, A. (2015a). Robotic process automation at Xchanging. The Outsourcing Unit Working Research Paper Series.

  44. Willcocks, L., Lacity, M., & Craig, A. (2015b). The IT function and robotic process automation. The Outsourcing Unit Working Research Paper Series.

Download references

Author information



Corresponding author

Correspondence to Peter Hofmann.

Additional information

Publisher’s note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Responsible Editor: Rainer Alt

Rights and permissions

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Hofmann, P., Samp, C. & Urbach, N. Robotic process automation. Electron Markets 30, 99–106 (2020).

Download citation


  • Robotic process automation
  • Business process automation
  • Software robots
  • IS ecosystems
  • Back-office
  • RPA

JEL classification

  • M15 (IT Management)