Robotic Process Automation: Contemporary themes and challenges

Abstract

Through the application of Robotic Process Automation (RPA) organisations aim to increase their operational efficiency. In RPA, robots, or 'bots' for short, represent software agents capable of interacting with software systems by mimicking user actions, thus alleviating the workload of the human workforce. RPA has already seen significant uptake in practice; solution technologies are offered by multiple vendors. Contrasting with this early practical adoption is the hitherto relative lack of attention to RPA in the academic literature. As a consequence, RPA lacks the sound theoretical foundations that allow for objective reasoning around its application and development. This, in turn, hinders initiatives for achieving meaningful advances in the field. This paper presents a structured literature review that identifies a number of contemporary, RPA-related themes and challenges for future research.

1. Introduction

To remain competitive, organisations strive to improve the efficiency of their operations through the redesign and management of their business processes. Information technology (IT) plays a key part in supporting this objective. Unfortunately, early adopters of IT have found it hard at times to evolve their legacy systems as they tended to be closed and inaccessible through a lack of application programming interfaces (APIs).

Recently, there has been a strong interest in industry in a specific area of automation: Robotic Process Automation (RPA). This term amalgamates robotics, referring to software agents acting as human beings in system interactions, and process automation, i.e. workflow management systems or, more generally, systems that are process-aware. In essence, RPA is a relatively new technology comprising software agents called 'bots' that mimic the manual path taken by a human through a range of computer applications when performing certain tasks in a business process. The tasks that bots perform are typically rule-based, well-structured, and repetitive. Examples of tasks that bots perform include data transfer between applications through screen scraping, automated email query processing, and collation of payroll data from different sources.

Organisations with successful RPA adoption and efficient business processes have experienced positive impacts on their strategic goals, staff productivity, and customer service [1] . RPA is of particular interest to industries that have traditionally been quick in the uptake of new technology, in particular process-aware information systems (e.g. banking, insurance) [2, 3] . Demand for RPA technologies is rapidly increasing, and it is estimated that up to 90% of large and medium size organisations will opt for RPA solutions by 2020 [4] .

Despite the existence of a large number of RPA vendors and products in the market, there remains much hyperbole around what RPA represents for organisations, as well as uncertainty about how to successfully utilise this technology. The various guidelines and frameworks offered by vendors and consultants for the selection and implementation of RPA solutions may not always provide unbiased information. At the same time, academic research in the area has only recently begun to rise. According to a Google Trends Analysis, 'RPA' only started to become a trendy topic (score: 25/100) in March 2017, but had increased to a score of 100 by September 2018, which indicates the peak popularity for the term. 1 Therefore, 1 https://trends.google.com/trends/explore?date=today%205-y&q=RPA.

https://doi.org/10.1016/j.compind.2019.103162 0166-3615/© 2019 Elsevier B.V. All rights reserved.

Table 1

Search String

("Robotic Process Automation" OR "Intelligent Process Automation" OR "Service Automation" OR "Desktop Automation" OR "Artificially Intelligent Workers" OR "Enterprise Robotic Process Automation" OR "Autonomics" OR "Virtual Workforce" OR "Software Robots" OR "White Collar Robots") it seems an appropriate time to review the literature on RPA, to investigate the state of the art, to research consensus around the scope of the term, to identify the main developments and trends, and to become aware of the gaps in our knowledge on successfully applying RPA. This paper reports on a structured literature review of 125 papers in the area of RPA. This review was driven by a number of predefined research questions that guided the initial synthesis. The synthesis is reported along the themes of what RPA means, key benefits and potential capabilities, RPA readiness, and the methodologies and technologies to support RPA. The findings show that there is currently a dearth of research literature that explores the techniques underpinning RPA. This paper identifies key research gaps within the current RPA landscape, especially on how to systematically design, execute, and operate bots (i.e. automating the RPA life-cycle). It sets a concrete foundation of contemporary themes and challenges for future research in this area.

The rest of the paper is organised as follows: Section 2 discusses the adopted research method. Section 3 presents key findings from the systematic literature synthesis. Section 4 presents a call for action with a series of prospective themes and challenges to guide future research in this space. Section 5 concludes the paper.

2. Approach

Literature reviews are important activities in scientific research, which aim to provide the synthesis of existing knowledge and to support a research agenda. Considering the novelty of the selected area, this study followed the "scoping review" classification [5] . A scoping review is useful for providing the size and nature of literature in an emergent topic of research [5] . This systematic literature review approach followed the guidelines of Bandara et al. [6] and Saldaña [7] to support the multi-staged coding and analysis approach deployed. The data analysis followed a quasi-deductive approach [6] . In this section, we describe the search, extraction, selection, and synthesis process.

2.1. Searching And Extracting The Relevant Pool Of Papers

The goal of our search strategy was to identify and select a collection of articles that discuss RPA. An evolutionary search strategy was used for this review. First, an online RPA terminology catalogue 2 was consulted to identify a potential set of key words. A preliminary Google Scholar search was then conducted to further specify these keywords and to identify which domains and outlets RPA literature is most likely to come from. After some initial paper extraction and analysis, the search string presented in Table 1 was applied across multiple databases, namely Springer Link, AISel, ProQuest, Elsevier, AB/INFORMS, IEEEXplore, Web of Science, Scopus, and Google Scholar. Search for literature was conducted in keywords, title, abstract, and full text fields. The search was not constrained to any time frame to ensure full coverage of published literature.

The search took place in two iterations. Firstly, only full text, peer reviewed articles in English were searched for. In the second iteration, backward searching was performed and the scope of literature was extended to include industry white papers cited in the peer reviewed articles (1st iteration results). The search process is illustrated in Fig. 1 .

The first iteration resulted in 145 articles, which were then exposed to further relevance quality checking. Each article was carefully examined by two members of the research team to confirm and classify their relevance, then further validated through corroboration sessions with the full team. This resulted with the grouping of articles into three categories:

1. 59 articles classified as category 'A' were very clearly about RPA, noted in the title, keywords and abstract, and the full articles discussed matters of relevance to RPA. 2. 9 articles classified as category 'B' were those where the main theme of the article was not about RPA, but had some details about RPA contained within them. The degree of detail here varied from having only a few lines that discussed RPA to having dedicated sub-sections/chapters on RPA. 3. 77 articles classified as category 'C' only mentioned RPA in passing or had come through the search due to the extended search terms used (see Table 1 ), but were not directly about RPA. These category 'C' articles were considered not relevant and were excluded from the analysis.

In the second iteration, 'A' and 'B' category papers were used for backward and forward search, resulting in the identification of an additional 57 papers. In this iteration, we also included nonpeer reviewed white papers that were cited in the peer-reviewed papers. All newly identified papers went through the same relevance/quality checking as explained above. This resulted in an overall pool of 125 papers (A:107 and B:18), of which only 36% (45 out of 125) were academic papers. The distribution of articles is illustrated in Fig. 1 . The group of peer-reviewed papers were used to derive a high level coding structure, as listed in Table 2 . NVivo 12 was used as the supporting tool and the coding took place in two main phases: deductive coding (Level 1) and axial coding (Level 2).

During Level 1 coding, the articles were read and coded line by line and content related to the pre-determined themes (Table 2) was captured in a deductive manner. Coders were paired for the Level 1 coding, where a sample of papers were coded together to confirm adherence to coding rules. Once confirmed, all the papers were coded to these high level themes. Annotations were often maintained to capture the 'coder's thoughts' during coding, which assisted with the applied multi-coder approach. Emerging sub-themes identified in this first round of coding were noted in separate memos pertaining to each main theme (and which formed input to Level 2 coding). The Level 1 coding results were further quality checked via corroboration sessions.

During Level 2 coding, the content captured under each theme was analysed further in multiple rounds for 'sense making' [8] to identify coherent reportable themes that emerged from the literature. Similar to Level 1 coding, Level 2 coding also was done by multiple coders following quality assurance procedures (i.e. deriving and applying coding rules and conducting corroboration sessions).

3. Key Findings

The following subsections present key findings from the synthesis, and are listed by theme in the same order as that shown in Table 2 .

3.1. Rpa Definitions

Only 24 of the 125 papers reviewed explicitly attempt to define Robotic Process Automation, and 28 papers position RPA by comparing and characterising it with respect to related fields.

Key themes mentioned in the definitions are that the purpose of RPA is to replace human tasks in business processes by software ('bots') and that this software interacts with front-end systems similarly to human users. There were, primarily, two different views of the nature of the software robots (or bots): in some definitions, the software is rule-based [2,9-13] and primarily performing repetitive, high-volume, lengthy, mundane tasks [14] ; in others the software is trained with data, advanced, complex or flexible and adaptable to circumstances [15, 9] . In both cases, the software is used to deliver business processes, including IT services [9] . Only three definitions [16, 1, 14] were not limited to the software used in RPA, but also hint at steps towards performing RPA in the definition, which seems to be suggested by the term "automation", which intuitively indicates a process rather than an artefact.

A detailed analysis of the definitions using Wacker's rules [17] is included in Appendix A.

In our review, we found that RPA is positioned within a field of other concepts, as shown in Fig. 2 . RPA is typically considered to be more rule-based and structured than artificial intelligence, cognitive automation or expert systems [13, [18] [19] [20] 14] , but may also incorporate these techniques as a part of RPA [21] . However, [14] indicates that RPA could be more aware and adaptable to change.

Compared to non-robotic (standard) automation and business process management, RPA is considered to be a more lightweight solution [22, 23] , targeting the front-end user interface rather than the back-end and data layers [24, 25] . Furthermore, compared to business process management, RPA is considered a bottom-up integrating approach rather than a top-down standardising approach, and is easier to configure [19, 20, [26] [27] [28] . A detailed analysis of the comparison of RPA to other concepts is shown in Appendix B.

3.2. Rpa Benefits

A total of 42 papers discuss a variety of benefits that may be achieved from RPA deployment. The main focus is on improvements to operational efficiency, quality of service (or work) produced, easier and faster implementation and integration with other systems, and improved risk management and compliance.

3.2.1. Operational Efficiency

Operational efficiency is addressed in terms of reduction in time, cost and human resources, reduction of manual tasks and workload, and increased productivity. Reduced operational cost is on top of the list. Based on quantifiable measures, such as the number of full time equivalent employees (FTEs) replaced by robots, RPA technology has proven to cut the cost of human resource-related spending by 20-50% [14, 9, [29] [30] [31] , and can reduce the cost of transaction processing by 30-60% [15, 11, 13, 32, 1, 33] . Reduction of manual tasks [34, 35, 28] and reduction of workload [36, 37] have also led to time efficiencies, as evidenced by significant reduction (from 30% to 70%) in process cycle time, task handling time, waiting time, and so on [13, 32, 1, 38] . Increased productivity is stressed (equally) from two viewpoints. Firstly, the fact that robots can work 24/7 non-stop is an obvious contributing factor to improved productivity [26, 39] . Secondly, RPA can free human resources from repetitive and tedious tasks [40, 24] and, as a result, "employees can participate in more value-added activities that involve personal interaction, problem solving, and decision making." [14].

3.2.2. Quality Of Service

By deploying RPA, common transactional errors such as incorrect data inputs, missed steps, and mistakes in rule-application are reduced [10, 41, 42] , the amount of human errors is decreased [43, 44] , and tasks being automated are expected to achieve 100% accuracy [3, 45] . Results of a case study [14] identify that an RPA solution "has enabled the insurer to guarantee 99.99 percent availability of its critical systems". Similarly, it is claimed [10, 39] that the 24/7 working schedule of software robots provides reliability and continuity of service. A study [28] explained that companies regard RPA as a tool to help them deliver service excellence to customers, whereas another study [39] mentioned that RPA can deliver transformative customer experiences.

3.2.3. Implementation And Integration

As pointed out in the literature [9, 10, 46, 47] , RPA is relatively easier and cheaper to implement, configure and maintain, compared to large enterprise systems and other forms of automation, and typically provides a simple and intuitive interface to users. Also, RPA can be implemented in a short timeframe [24, 15] . For example, it was reported [37] that a robot programmed for automating a simple process "was ready in three weeks". Another study [48] claimed that a bank "was able to build an automated solution that went into full production within six weeks". As stated in the literature [49] [50] [51] 43, 42] , since RPA replicates the type of standardised procedural work by humans, it uses existing user interfaces, is integrated with existing infrastructure and systems, and does not require expensive and sophisticated systems integration.

3.2.4. Risk Management And Compliance

Early adopters of RPA have reported that reducing risk and increasing compliance is also seen as a valuable asset of RPA [35, 23, 45] . A typical example mentioned in the literature is that RPA software keeps a log of the work performed to ensure that the tasks and processes being automated meet regulatory requirements [49, 11, 26] . One study [39] points out that RPA is used to monitor human transactions and generates alerts for any anomalous action against compliance rules. According to case studies [13, 20] , clients "reported that compliance increased with RPA" and the higher compliance is due to the fact that "software 'robots' were configured to follow regulations and [that] processes are all recorded and thus easily audited".

3.2.4.1. Benefit realisation: opportunities and challenges. Despite the fact that the benefits that may be gained from RPA deployment are well documented, it cannot be taken for granted that adopting RPA in an organisation will undoubtedly lead to achieving benefits. Benefit realisation draws upon a number of key factors such as organisational readiness for RPA, the capabilities of the RPA technology to adopt, and implementation and delivery of an RPA solution. Often these factors vary from organisation to organisation and differ from each other given specific business contexts. So far, guidelines or best practices for benefit realisation of RPA deployment (from adoption to delivery) rarely exist. Hence, development of a systematic approach supporting benefit realisation of an RPA solution becomes an open issue to address.

Measuring the benefits (to be) delivered by an RPA solution is also an interesting topic. Usually RPA benefits are measured in terms of reductions in time, cost, error and human resources. However, RPA benefits are not limited to these direct and tangible outcomes only. For example, the capacity of human resources saved from repetitive tasks automated by RPA can be reallocated to more creative tasks leading to increased productivity, in which case, measuring RPA benefits should incorporate measuring of productivity as a result of resource reallocation. Additionally, when an RPA solution supports integration between different existing systems, measuring the increase in system utilisation is another element to take into account. Hence, the definition of metrics for benefits associated with an RPA solution, and how they may be measured, are worthy of further study.

3.3. Rpa Readiness

75 out of 125 papers discussed various themes around RPA readiness. A common challenge that many organisations face is how to identify where to deploy RPA [45] . "A lot of companies don't really understand" [28,p. 298] and available literature on criteria to consider for suitability of RPA is vague [35] . This section presents a synthesised overview of what the current literature states, summarising RPA readiness considerations within two key levels: (i) organisational and (ii) process/task.

3.3.1. Organisational Characteristics

It is vital to evaluate RPA within a company's context as it needs to align to company goals, challenges and capabilities [52] . Also, the efforts of implementing and maintaining bots will vary according to specific organisational circumstances [53, 54] . Based on the literature analysis, we present three organisational characteristics that affect the readiness/suitability for RPA; business drivers, the nature of existing technology and degree of maturity.

Business drivers. RPA is a viable option to consider when the business is driven by cost reduction, quality improvement, efficiency, and better compliance goals [55, 53, 56, 3] . RPA also needs to fit with organisational procedures, strategy and shared operational problems [27, 46] . RPA can be an alternative to outsourcing tasks to low-cost labour regions [56] . It can also be a tool for those firms who need to make high-stake decisions to help grow and manage their business. A study [42] explains this further with an example which shows how RPA-generated analysis can help companies to keep track of capital expenditure and new infrastructure investments. While RPA is often used to maintain a 'lean' staff headcount [13] , it is also well suited for organisations that seek to do more 'value-adding' work with existing staff resources, getting them to focus on more interesting and critical work, and improving service speed and quality [57, 46, 58] . In fact, it is argued [59] that "the focal point of RPA use cases should not be the removal of human workforce; they should aim to improve accuracy, speed, agility, and remove the need for humans to execute repetitive tasks".

Nature of existing technology. Some view RPA as a hardware and software standardisation strategy in organisations that have a "hodgepodge of data processing and word processing equipment" [60] . Organisations with many different systems that need to be 'meshed together' are ideal candidates for RPA [14, 59] , especially those with many legacy systems [59] and those that are unlikely to move to a single system in the near future [9]. These multiple systems often lack appropriate interfaces [25, 3] and RPA can become the 'chief interface' between these systems [9] . The remaining shelf life of these systems play a role, as RPA cannot deliver target benefits with legacy systems that are soon to be de-commissioned [59] . The stability of the environment where existing systems operate (i.e. the degree of change within the components of an IT system) also plays a role [25] .

Degree of RPA maturity. A study [21] explains how more mature RPA adopters show higher satisfaction levels with their RPA returns. The authors argue that this is a strong message to risk-averse organisations: to recognise the need to start somewhere to develop maturity so as not to miss out on opportunities. Maturity also means the company has the required resources, both funding to support and proceed with RPA, and the required people skills internally [9] . RPA is more easily deployed in organisations which have "technology and innovation at its strategic and cultural core" [61] . Staff personality contributes to an RPA-conducive culture [27] . RPA success is far more attainable when the firm has staff who are interested in staying on top of the latest technologies, and see RPA as a fascinating and futuristic concept [41, 43] . When RPA is deployed in customer service (front-end) areas, the company's customers also need to be ready and able to respond to the required technical requirements [43] .

3.3.2. Process/Task Characteristics

The literature acknowledges that selecting the right process/task for RPA is important (e.g. [39]), but how to determine suitable processes, sub-processes or tasks for RPA is not always self-evident [19] . In recognition that RPA is not suitable for every process, and if applied to unsuitable processes the development effort rises and inhibits RPA outcomes, this section attempts to derive a synthesised list of process/task characteristics where RPA is most suitable.

While checklists [62] , 'questions to ask' when assessing the automation potential [19] , and lists of criteria [40] do already exist, they have limitations. One is that they do not differentiate between organisational and process/task level characteristics, which we argue fall under two different levels. Another is that they are not based on a detailed analysis, and they do not have (or only very slightly have) a supporting evidence-base. An exception is [19] , where a detailed analysis based on a literature review is presented, albeit based on only 23 papers. Using a grounded approach to coding and analysis, we present a list of synthesised characteristics which is more comprehensive and complete, and derived systematically from literature.

We extract the following characteristics of RPA-suitable tasks from these papers: [9-11,19-21,48,39,62-80,15,34-36, 52-54,49,23,16,13,43-45,60,25,30,3,41,59,56,32,57,26-28 ]:

• Highly rule-based: the decision logic needs to be expressed in terms of business rules. RPA requires a prescribed rule for every eventuality, which needs to be unambiguous. • High volume: sufficient transaction volumes help to maximise benefits from the implementation of software bots in an organisation. They are generally routine and repetitive tasks where automation becomes an ideal choice. • Mature: mature tasks are those that have been in place for a while, are stable and people understand what is going on. • Easy to achieve and show impact: tasks performed within processes with the best return (a meaningful impact) and simplest delivery (quick and inexpensive to deploy RPA). Areas where a clear understanding of current manual costs can be calculated will make it easier to identify and highlight the business value for RPA. • Has digitised structured data input: all input data must be digital and in a structured format. • Highly manual: "Swivel chair"-like processes/tasks, which do not require much human intervention, but are able to be automated. • Transactional: RPA is well suited for tasks at the bottom of the pyramid dealing with transactional work, as it reduces the risk of transactional errors (e.g. incorrect data) and can perform many transactional activities at once, replacing nearly all the transactional work that humans do. • Standardised: processes with a higher degree of standardisation (how consistently process execution follows a predefined path) are generally better candidates for selection, especially in the initial RPA implementation phases. • Low-levels of exception handling: processes targeted for RPA should not have to deal with exceptional behaviours; the more exceptional the cases that bots need to handle, the more process automation, testing and optimisation will be delayed or aborted. • Highly repetitive: automating tasks that are 'repeatable enough' will help to yield a better return on investment. • Less complex processes: processes should be simple enough so that bots can be implemented quickly. Increased process complexity drives robot complexity (which in turn can increase operating costs, and potential business disruptions). • Well-documented: process descriptions that accurately detail processes are essential for bots to be taught behaviours at the keystroke level. When processes are well known, the programming and testing of the bots will take less time. • Interacts with many systems: good candidates for RPA are processes that need access to multiple systems. Manual effort for frequent access to multiple systems can be high and lead to increased human error, inconsistent performance and high cost of impact, making such processes good candidates for RPA.

While these characteristics are often consistently spoken about in the literature, there were some contradictions noted. For example, while stability and maturity of processes are highlighted in the literature as a characteristic supporting RPA [25] , when presenting their selection criteria for automation approaches, the authors position RPA as a light-weight technology that is better suited for temporary processes (implying the opposite of a stable process). Similarly, while the common norm is that RPA is most suitable for high volume transactions, some argue otherwise [66, 28, 30] , stating that business processes need not handle extremely high transaction volumes to be suitable candidates for RPA. Medium transaction volumes [28] and tasks that are business-critical and high in value can also be good candidates for RPA [30] . While process standardisation is deemed an essential RPA pre-requisite, RPA is at times also seen as a means to achieve standardisation [60, 79] .

The analysis also pointed to some further clarifications to the process and task characteristics identified. Lacity and Willcocks [28, p. 299] clarify the notion of process complexity, stating that when process complexity is conceptualised as having subtle and dynamic causes and effects then RPA is not suitable, but when complexity is defined as 'requiring compound steps and the control of many variables', then RPA is very suitable.

In terms of digitised data, while data quality can be an outcome of RPA, the quality of input data is emphasised as an essential ingredient for RPA success. Input data must be consistent, not contain 'surprising' null values, and in general be carefully defined [23] . The current cognitive skills of bots are limited, and cannot always guarantee to successfully process cases with poor data, and in the worst case they will perform the task incorrectly or need extra exception handling capabilities built in, which can delay the training and testing of bots [43] . This is one reason why processes which have lower quality of input data are deemed unsuitable for RPA and/or only those with strict controls in place of the received data are recommended for RPA [43] . However, rapid technology developments in RPA are underway (see Section 3.6), enabling bots to be 'smarter' and capable of handling more complex and less defined tasks. Some of these developments are already starting to hit the market and as they grow, the scope of tasks and processes that can be automated with RPA is likely to be expanded and become less limited by input data quality, consistency or complexity.

In terms of exceptional handling, while bots can be programmed to handle exceptions, prior studies [36] have found that it is more cost-effective to have a human specialist spend a few hours resolving an unusual exception that arises occasionally per year, than to deploy developers to configure and test bots to manage these. A report by Ernst and Young [34] supports this, emphasising not to attempt to program 100% of the cases: "Continuing to automate the remaining 30% often involves convoluted exception handling or multiple diversions from the 'happy-path', so can double the time to deliver".

3.4. Rpa Capabilities

Many papers, in scientific as well as professional literature, elaborate on the (expected) potential of RPA. In Section 3.2 the benefits of RPA were reported. In this section, we identify potential capabilities that are associated with RPA. Our literature study revealed 24 papers that describe a variety of capabilities that are associated with RPA. We identified capabilities on two different levels: capabilities that focus on the work of the individual employee, such as the change of routine-based work to higher value-added tasks [63] , and those that relate to the general organisation and its processes, such as strengthening standardisation [40] and supporting decision making [67] .

3.4.1. Employee Level Capabilities

Our survey revealed two types of employee level capabilities. First, we found that several papers highlighted the capability of RPA to change the nature of work. When RPA is used to automate routine tasks, employees are able to focus on higher-value work [37, 18, 11, 16] . A concrete example of an RPA implementation leading to a change in the nature of work is described by Castelluccio [81] . The implementation of RPA in purchase-to-pay software automated so many aspects of the process that it enabled the people who monitored the process to perform only those activities that required "judgement-based decision making".

The second type of employee-level capability goes beyond changing the nature of work that is affected; it describes the creation of new roles for employees. Examples are jobs that are created in a new RPA center of excellence [37] and all kinds of jobs related to robot management, consulting and data analysis [24] . Interestingly, in two reports, RPA robots themselves were considered as the new, digital workforce layer [11] or as new digital employees that are designed to work with humans [49].

3.4.2. Organisation And Process Related Capabilities

Most capabilities that are described in the literature relate to the general organisation where RPA is applied and its processes. Several of these capabilities, such as standardisation and flexibility, are highly general and can be linked to almost all RPA implementations. Others are more specific, such as the capability to automate legacy business processes [18] or automate IT processes [40] . This section provides an overview of four themes behind the capabilities that emerged from the review: (i) increasing transparency, standardisation and compliance; (ii) harnessing process intelligence for decision-making; and (iii) ensuring flexibility, scalability and control of the supporting software.

3.4.3. Process Transparency, Standardisation And Compliance

Transparency, standardisation and compliance were recurring themes in our survey. When processes are automated through RPA, these processes will always be carried out in the same way, which, according to two studies [16, 46] should result in a large increase in standardisation. Furthermore, since every step of the robot's actions is logged, this will improve transparency [10] and offers the opportunity to identify and handle process deviations [11] . The increase in standardisation and transparency eventually results in improved auditability [40, 66] and improved compliance [39, 11] .

3.4.4. Process Intelligence For Decision-Making

Several papers in our survey emphasised the capability of gathering process intelligence and using this intelligence for decision-making. One paper proposed that this self-monitoring capability of RPA will open all kinds of possibilities of gathering intelligence [14] . This intelligence can then be used for decisionmaking, for example through predictive analytics [53, 81] . RPA may be a basis for content analytics and process intelligence [53], as well. By making sense of real-time data, RPA can help us to anticipate on what will happen next [67] . Finally, according to Davenport and Kirby [67] , it is a small step from systems merely supporting humans in their decision making to taking the decisions on their own. However, for a system to manage itself and adapt to changing circumstances it needs self-awareness [82] . Davenport and Kirby [67] explicitly note that current technologies lack this ability, which limits the type of decisions they can make autonomously to relatively stable, well-understood settings.

3.4.5. Flexibility, Scalability And Control

In several papers, capabilities can be found that relate to the flexibility, scalability and control of RPA implementations. RPA may increase flexibility [10] for several reasons. First, robots are much more flexible than humans with regards to work hour flexibility [40] . Second, RPA does not require IT systems to be changed or integrated with them [24, 40, 66, 49, 27] . Third, no external consultants or technical background are necessary to have them installed or operate them [37] . And lastly, RPA software is easy for business owners to implement [27] . Furthermore, it is much easier to increase the workload of an automated process than of a manual process, which means that RPA can easily scale [15, 27, 46] . A final point worth mentioning relates to control. Jalonen [23] asserts that moving tasks from humans to robots improves control of the processes affected. Especially when comparing RPA implementations to outsourcing processes, control for the business owner is much higher with RPA.

3.4.6. Additional Capabilities And Limitations

Capabilities mentioned in the papers that do not belong to one of the discussed themes are: ensuring privacy because data can be encrypted easily so that only results can be seen by humans and not the used data [23], dealing with mismatches in processes, systems and steps [20], automating IT processes [40] , working autonomously on infrastructure components [40] , and automating legacy business processes [18] .

Finally, our literature review also revealed several limitations related to the (expected) capabilities of RPA. Most of these relate to the comparison of human capabilities and robot capabilities. Davenport and Kirby [67], for example, warn that although computers may potentially work beyond human levels of intelligence, this is still decades away. One study proposed that robots are still not able to handle new situations [45] . Other scholars argue that robots miss the capability of exercising subjective judgement and building empathy for customers [45] . This corresponds with the assumption that capabilities such as sensing emotions and creativity are difficult to automate [83] . A different type of limitation cautions that RPA is mostly about tactical quick wins and that RPA is not able to truly transform and re-engineer business processes [3].

3.5. Rpa Methodologies

Since RPA is a relatively young field, so-called RPA 'methodologies' come in the form of lessons learned, guidelines, best practices, and experience reports of RPA implementations within organisations. From the analysis of the 57 publications with codes related to RPA 'methodologies', the themes that emerged include advice about various considerations that one should take into account before embarking on an RPA journey, to discussions about how to choose suitable tasks for automation, and RPA life cycle management.

3.5.1. Pre-Implementation Guidelines

Davenport and Kirby [84] point out various ways in which organisations can respond to RPA technology, from stepping 'aside' (i.e. focusing on what humans do best) to stepping 'forward' (i.e. building advisory systems based on RPA technologies). Overall, there is agreement that RPA technology should be considered as part of the long-term business and automation strategy of an organisation [64, 10, 85, 13, 28] . Consistent with the oft-quoted line by Bill Gates (whereby automating an inefficient process only magnifies its inefficiency), the literature emphasises the need to optimise processes first before automating them [14, 86] . Further, it was argued [2,41] that processes should be first redesigned to maximise RPA capabilities. Tornbohm [85] also highlights the need to catalog and standardise organisational processes before launching into RPA.

A somewhat contradictory point of view is suggested by the Forrester Consulting Prism report [48] which suggests automating those tasks that represent the "weeds in the gardens that choke growth". In other words, those tedious, and by implication, not necessarily optimised tasks should be considered for RPA automation.

Regardless, the very nature of RPA that uses bots to 'mimic' the manual path taken by a human to accomplish a task implies that processes automated through RPA are likely to have limited, or no, human oversights [87] . Therefore, special considerations, above and beyond those that apply to the more traditional process automation, need to be recognised: RPA-enabled processes require far more detailed rules for the bots, as bots can be completely oblivious to certain (suspicious) patterns that can be easily picked up by humans (e.g. highly-inflated debts calculated through the 'robo-debt' program [88] could have been picked up quickly by an experienced human worker); and, RPA-enabled processes which bypass human workers can be, at least technically, easily replicated at a large scale, potentially causing large-scale damage if not properly controlled.

In terms of expectation management prior to the deployment of RPA, Boulton [18] advocates setting expectations early to avoid bold claims that may not be met, while another study [39] recommends starting the RPA journey early, as early adopters tend to generate more shareholder value and market differentiation.

3.5.2. Selection Of Initial Rpa Tasks

There is a consensus in the literature to 'think big' but to 'start small' [11, 35] to avoid falling into the trap of 'scope creep'. In fact, Lacity et al. [16] argued that it can be worthwhile to automate just a portion of a process. Likewise, the Institute for RPA [14] and Accenture [10] suggest that end-to-end automation of a process should be the next step after small low-risk tasks have been RPA automated. Such observations are consistent with the nature of RPA explained above whereby the inherent risk of RPA, due to the lack of human oversight and the large scale at which bots can be rallied, means that it is better to start small. In a study [18] , the authors also cautioned against falling down the 'data rabbit hole' whereby CIOs may get carried away with applying machine learning to the data collected by the bots, leading to a much larger project.

Jalonen [23] cautioned the withering of interest of staff when "too difficult" business processes are automated, and proposed a list of attributes that make a process viable for RPA. The report by Accenture takes a more holistic view of solution design that identifies high-value areas and capabilities for optimal efficiency [10] . Similarly, a number of authors suggest that low to medium complexity tasks are a good target for initial RPA automation, while complex tasks should be left for later [34, 9, 71, 49] .

3.5.3. Stakeholders Buy-In

Another focus of the literature in relation to RPA methodologies is the need to engender the buy-in of all stakeholders, from toplevel management to end users, to ensure the success of an RPA project.

The report by ACCA [9] raises the concern that CFOs may not appreciate the full benefit of RPA compared to those closer to the process, and that it is important for value-added benefits to be demonstrated in terms of how RPA is transformative for the organisation, rather than simply as a generic tool deployment.

Boulton [18] argues that it is important to highlight the business impact of RPA, for example the impact on customers, instead of focusing only on return on investment and cost reduction, while a Deloitte report [11] suggests that 'seeing is believing': it is more persuasive to show examples of how RPA has delivered benefits in other organisations. A Forrester Consulting report [89] suggests proving the value of robotic automation to win support from executive and gain their buy-in to create centres of excellence. Another study [16] suggests that IT infrastructure teams were sometimes excluded from an RPA project because it was considered more of a business operation. All stakeholders should be made aware of the benefits of an RPA implementation, and to have their concerns addressed [13, 49] .

3.5.4. Stages Of Rpa Roll-Out

The advantages of a staged RPA roll out, starting from a pilot stage before scaling up to other processes, are widely discussed. Case studies [49, 37, 57, 10] suggest that RPA should start with an initial proof of concept, followed by an pilot, before scaling up to wider organisational processes. Other studies suggest similar stages, though with minor variations [90, 30, 24, 70, 2, 79] .

The need to perform opportunity assessment to identify the right tasks to be RPA-automated is a recurring theme in the literature [23, 34, 56, 85] . Because RPA essentially integrates the presentation-layer of various applications (something which is traditionally performed by human resources), the level of complexity involved should not be understated: humans may easily manage the various if-else conditions in navigating the various applications to accomplish a task, however, attempting to spell out all the rules for bots to follow may be a lot more involved. Therefore, identification of the right tasks for RPA automation should be carefully thought out so as not to pick those tasks whose complexity becomes a stumbling block.

Similarly, the need to perform business case justification is echoed by a few studies [35, 41] . A 5 step approach for task selection, including the use of BPMN-R to model processes to be automated via RPA is described in [19] . The use of business process mapping was also referred to as an effective way to launch robotic automation program [56] .

The approach suggested by Deloitte [11] is to start an RPA project with bold ambition, accompanied by a solid foundation consisting of high performing bots, as well as developing an organisational mindset that is able to adapt to rapid changes. In another study [61], a 7-step RPA adoption model that has a strong focus on the RPA governance structure within an organisation is proposed while 5 action principles are proposed for organisations considering to apply RPA [1]. There is a strong consensus that Agile methodologies should be adopted in the development of RPA bots [34, 11, 37, 59, 26] . There are quite a few papers suggesting the development of internal RPA capability within an organisation, with the need to establish an RPA centre of excellence (CoE) [89] [90] [91] 41, 85, 70, 28, 16, 61, 49] . Other authors [56, 40] , provide a more generic framework for introducing organisational support.

3.5.5. Development And Management Of Bots

The view that there should be a segregation between the bot development and deployment environments is shared by a few studies [19, 13] . Seasongood [56] mentions the risk of failing to apply finance controls on RPA, while another study [83] suggests that it is imperative for top management to keep an eye on the speed and direction of automation to keep risks related to the quality and safety of automated processes in control. Studies [37, 50] also highlight the importance of developing RPA manuals and documenting bot knowledge to prevent any loss of knowledge within the organisation. Hodge's findings [50] highlight other risks, including ensuring compliance to regulatory bodies, management of quantities/volumes, knowledge retention, as well as physical security in case of disaster.

Many authors suggest the importance of not neglecting human resources when robots are deployed [11, 35, 13, 46, 28, 18] , and argue the importance of involving human workers early in the design and implementation phase to reduce resistance to RPA and the need to upskill human workers with the knowledge to work with a virtual workforce effectively. Bots are dynamic and should not be governed like ERP or other systems; their management and governance call for a different mindset [11, 56, 61] .

While bots are being developed, the authors of one study [49] argue the need to involve domain experts and end users to capture their knowledge properly. Jalonen [23] recommends that technical expertise aid in the conceptualisation of a process from a bot's point of view. However, process analysts who define the processes could be non-technical, hence, it is important to provide technical expertise early in the process. A study [53] argues that designing a robotic process should be intuitive and visual, independent of the skill of the designer.

3.5.6. Long-Term Rpa Success

A common theme in the literature is that the early involvement of both IT and business in the adoption of the technology is critical for long-term success [48] [49] [50] 10, 18, 11, 34, 46, 59] . Nevertheless, several authors [2, 13, 61, 92] argue that business should lead the RPA adoption. It was argued [45] that while different models may be used -centralised, hybrid, or distributed -it is important that ownership and control of bots are kept close to business users. Stople et al. [51] investigate the nature of the integration within organisational units for a successful RPA implementation and conclude that loose integration between IT and business can be quite effective.

'C-suite' support is seen to be critical to cut through organisational barriers and to accelerate the scaling up of bots [11, 46, 13] . Lacity and Willcocks [28] suggest the need to continually improve the automated process to reap the greatest benefits from RPA, as well as the reuse of components to scale up quickly and to reduce development costs. Seasongood [56] argues for the need for a process owner to take responsibility for when and how to incorporate business rule changes that may require updates to bots.

3.6. Rpa Technologies

There are 56 papers that make some reference to RPA from a technological perspective, primarily in terms of what is currently available, how RPA is deployed, and possible future developments, but for the most part without any detail on how those developments may be realised. All mature RPA products are closed-source, which naturally tends to limit discussion to those commercial products, and hinders academic research into product improvements, enhancements and extensions. Nevertheless, the literature provides an insight into existing platform architectures and capabilities.

3.6.1. Rpa Vendors

Much discussion is centred around the various RPA vendors, their products and sub-components.

Some commonly mentioned products include the 'big three': market leaders Blue Prism, arguably the pioneer RPA product [28, 20, 66, 92, 41, 73, 79, 69] , UIPath [49, 28, 37, 20, 92, 41, 79, 69] , and Automation Anywhere [28, 20, 92, 41, 69] . Other products mentioned include Workfusion, Kryon Systems, Softomotive, Contextor, EdgeVerve, niCE, and Redwood Software (for example [92, 79, 69, 93] ). While all of the above are standalone RPA tools, others, such as Pegasystems and Cognizant, provide RPA functionality embedded into more traditional BPM, CRM and BI functionalities [93] . Le Clair et al. [92] provide an in-depth 28 criteria evaluation against the 12 leading RPA providers.

Generally, RPA products comprise three main components: a graphical modelling tool, an orchestrator that manages robot execution, and the bots themselves [37] , covering the development, testing, staging and production lifecycle phases [51] . Other components may include schedulers, collaboration tools, audit trails and performance analytic tools [30, 37] .

3.6.2. Architectures

Most of the discussion on RPA architectures is concerned with the positioning of RPA within the presentation layer of the Open Systems Interconnection (OSI) model. The original RPA articles [66, 48] that introduce pioneer vendor Blue Prism (mentioned above) describe the 'brittle' interfaces created when integrating applications at the data and/or application layers, and argue for presentation layer integration. This positioning locates RPA as a means to "introspect, access, extract, and transform data from virtually any existing application source" [48] without the reliance on those specialised skills required for data and application level integrations. Such mechanisms "deliver the business self-service capability" [48] that are situated across, rather than within, the overall IT architecture of an organisation [61, 79] .

Other authors also describe the ease of robot development through a focus on the presentation layer, thus allowing noninvasive accesses to other organisational systems in the same way that a human would access them (for example [16, 56, 54, 28] ). This allows RPA to be deployed without programming or disruption to the core technology platform [54, 28] , an approach which greatly differs from, for example, BPM solutions that require invasive development across the OSI stack [28] .

While many RPA architectures began as macro-recording [53] or screen-scaping [66] desktop tools, they now primarily support centralised server models [53] , combined with a virtual desktop environment [34] . This architecture significantly reduces hardware and software licensing costs, in addition to maximising performance and scalability by providing for deployments of a single robotic process server-side that can execute multiple instances of itself [71, 53] .

RPA solutions generally fall into two modes of operation: attended and unattended [3, 40] . Unattended mode is autonomous and is suitable for simpler processes that do not vary between instances, but can result in significant errors when used for more complex cases. Attended mode allows individuals to trigger bot activities to perform parts of a process, and to actively monitor those activities, delivering a 10-20% improvement in use cases such as address change, payment change, and fund transfers across systems [71, 3, 40] .

The need for rapid robot development and deployment can be satisfied by the creation of extended libraries for industry-specific processes, as discussed in [23, 21] . The application of such a centralised component library of common RPA modules is described in [41, 49] . This architectural framework also provides easier maintenance of robot activities.

3.6.3. Constraints And Limitations

RPA requires 'adjustments' to both business units and IT infrastructure teams to gain full advantage from RPA deployments [27] . A common criticism is that the integrations offered by RPA are less robust than those that are by nature embedded into core systems [22] . Other identified limitations include business-as-usual disruptions, employee anxiety, lack of tangible benefits, implementation difficulties, reduced incentive for further optimisations, and the often misplaced belief that existing systems can handle increased throughputs [49, 72] .

Currently, another major constraint for successful RPA deployment is the mandatory requirement for structured data [64], although AI and other complementary technologies may allow the broadening of RPA benefits to unstructured or semi-structured data. There may be limitations to the number of virutal machines that can be supported effectively by a lead orchestrator module [13] . Also, environments wholly based on a virtualised layer (e.g. Citrix) may have difficulty supporting RPA [23].

3.6.4. Process Script Development

One novel approach to developing bot process scripts during the design phase is Test Driven Development (TDD) [94] , which involves creating unit tests that initially fail but gradually are passed as script development continues around them. Together with video recording of screen actions and agile techniques, developing RPA processes may be greatly improved in terms of completeness and time efficiencies through the application of these methods [94] .

Another innovative approach is the use of process mining techniques to analyse clickstreams and key logs of user actions on human interfaces to facilitate automatic discovery of bot process scripts from such logs [93, 95] . The resulting 'declarative' scripts seek to offer better coverage of exceptional process paths by specifying a set of constraints that must be satisfied during process execution, rather than the more common flowchart definitions of what is possible [95] . Process mining techniques may also be used to automatically identify processes with the highest automation potential [93] . Such methods will help to ensure that bots are built in a way that "truly mimics" what a human user does when interacting with an application [53] . Tornbohm and Dunie [71] recommend that when selecting an RPA tool, consideration should be given to ease of scripting, and the level of coding knowledge and compiling required. Even when easeof-use is claimed, clarity around governance, scripting best practice and how and when IT is involved are fundamental requirements [71].

3.6.5. Exception Handling

Exception handling is an important consideration in all phases of the RPA lifecycle, but particularly during the scripting phase of bot development. RPA tools typically offer recording functionality to create a basic script from user actions, but this method will only record the "happy path" for the process [85] . As such, multiple exceptional behaviours are typically ignored, and so caution is advised when relying solely on record-button functionality [71] . Often exceptions are mitigated by simply rebooting the bot, but such instabilities can cause long term process problems [23] .

Conformance checking can be used to discover deviations and predict problems, but care must be taken when allowing bots to mimic human behaviour [93], especially when ethical and security risks are considered.

Ease of recovery is important, as a process exception can mean regulatory failure or loss of business in many cases [21] . Currently, all such exceptions and related process data must be manually analysed to determine the cause of the exception and its potential remedies [21, 9] . Even with attempts to include all possible variants in a process script, rare events are often overlooked [49] , but may be included in the automation by adding extra rules post-discovery. Future RPA tools may allow bots to eventually learn to adjust their rulesets on the fly by 'observing' human problem solving capabilities [93] and leveraging ML capabilities [85] .

3.6.6. Risk Management

Security concerns are raised whenever process control is passed to a bot, none more so than access control [21] . Ways of making RPA solutions more secure include robust logging and (change) auditing, adherence to security standards, guards against intrusion vulnerabilities, solid login and password policies, and network security more widely [21, 46] . Robots should also have the capability to run behind locked screens when necessary to ensure data privacy [21] . However, in [50] it is argued that robotic processes tend to be more secure than human-operated processes, since, once implemented correctly, they keep strictly within the regulatory and security parameters set for them. And unlike humans, they do not err (within the context of the script defined for them). But in situations that may include ambiguity, either in the data itself, or where judgement is needed, a bot can fail (at least until AI capabilities become available) [40] .

It is important though to have clear communication between business units and IT Infrastructure support to ensure controls are not applied too stringently. For example, [49] reports one case where IT blocked all non-human users, preventing bots from logging on to the system.

3.6.7. Complementary Technologies

Emerging technologies may be applied to transform unstructured to structured data using artificial intelligence (AI) and Machine Learning (ML) techniques to support document recognition, intelligent capture and natural language processing (NLP) activities for items such as automated customer email and document interpretation [63, 40, 21, 54, 71] (see also Section 3.6.8). In fact RPA can also be considered to be complementary to AI [40], for example Blue Prism have partnered IBM Watson to bring cognitive capabilities to clients [54] .

Chatbots, image and speech recognition, and other technologies that "enhance, augment and compliment human abilities" [22] are seen as ideal candidates for integration with RPA [96, 3, 22, 59] . Blockchain technologies have also been integrated with RPA in financial markets supporting the field of derivatives [38] . Measurement tools for monitoring and improvement are also fundamental to a "balanced, rational, and focused" robotics approach [3].

3.6.8. Machine Learning And Artificial Intelligence

RPA needs to become 'smarter' to achieve wider adoption, so that support can be offered for more complex and less well-defined tasks [93] . Numerous authors point out the importance of ML and AI techniques for the future applicability, advanced capabilities and extensibility of RPA (for example: [40, 64, 21, 18, 26, 22, 45, 59, 79, 10, 84] ). It is envisaged by Tornbohm and Dunie [71] that "RPA tool vendors will either partner for AI functionality, or they will continue to invest in developing AI-style capabilities, either charged as extras or integrated to work with the basic tool". While it is clearly anticipated throughout the literature that ML and AI methods will drive the RPA technologies of the future, there is little to no detail given on how those developments might be achieved.

Natural language processing, coupled with machine learning and chatbots, will eventually replace customer relations activities that currently require direct human interaction [26, 54] . Kristian [41] envisages a use case where "the initial assessment of customer requests in a web portal would be done by a neural network trained with machine learning and the following rules-based process of completing the request can be completed with RPA". Kashyap [80] uses the collective term Machine Intelligence to group machine learning, deep learning, cognitive analytics and RPA under one umbrella.

3.6.9. Future Technological Directions

One current innovation focus is on management and governance functionalities, such as centralised control, preservation of process knowledge, and features such as "connectivity monitoring, rollback capabilities for failures, and testing capabilities" [57] .

Another future direction is the field of Intelligent Robotics (IRPA) where RPA can be integrated with cognitive and deep learning methods, incorporating natural language generation, computer vision (AI-screen recognition), cloud integration and selfimprovement [28, 37, 63, 57, 84] (see also Section 3.6.8). The ability to use analytics to build 'smart' knowledge bases that find less common and more complex patterns, and advanced control capabilities, will position future successful RPA implementations [92] .

Future bots will use AI to understand, decide on and process a request [92] . AI will assist with coding or creating no-code robot development methods for the most advanced RPA vendors [21] . Vendors may develop and incorporate their own AI subsystems, or leverage AI service providers such as Microsoft Azure ML or IBM Watson [92] . Process mining will support the discovery of processes amenable to automation and the use of those processes as a basis for bot training [95, 93] .

4. Robotic Process Automation -Research Themes And Challenges

From the summary of our literature review presented in Section 3, it is evident that the literature surrounding RPA primarily consists of position papers and white papers describing RPA case studies and experiences aimed at higher-level management. Issues pertaining to the use of RPA from the strategic and management points of view, such as business drivers for RPA adoption (see Section 3.2), RPA capabilities (Section 3.4), guidance in ensuring RPA success (Section 3.5), as well as RPA readiness (Section 3.3) are discussed quite extensively.

The literature mentions specific human-aspects for successful RPA such as the importance of; managing fear of bots and potential job loss (e.g. [41, 3, 72] ), the need for clear communication [3] , dealing with RPA 'mistrust' [43, 72] , the need to set the right expectations [11] and the critical role of leadership [12, 27, 28, 30, 32, 83] . The literature mentions some practices that have proven effective to address these human aspects in prior RPA cases, such as; treating bots as 'team members ' [74] , and celebrating success [43] after bot go-lives. We perceive these human aspects of RPA to be similar to other technology adoption challenges which could be addressed by the plethora of prior and ongoing IT adoption literature, hence have not focused on these in our formation of the research agenda However, as can be seen from Section 3.5 and particularly Section 3.6, there is currently a limited number of academic papers that explore the operationalisation of RPA from the technical and implementation perspectives.

In this section, we enumerate the key research challenges for each of the themes arising from our review and suggest ways in which they may inform future research in the RPA topic space.

4.1. Benefits

The evidence from the literature explains the need to identify and justify how RPA can contribute towards achieving diverse corporate strategies (such as cost reductions, efficiency, higher service quality, better compliance). Future research on RPA benefits realisation (that considers and can cater for various business contexts) can assist towards addressing the identified gaps. Challenge 1. Support for benefit realisation.

Despite the fact that the benefits of RPA deployment are obvious, it cannot be taken for granted that adopting RPA in an organisation will undoubtedly lead to achieving benefits. Benefit realisation draws upon a number of key factors such as organisational readiness for RPA, capabilities of the RPA technology to adopt, and implementation and delivery of an RPA solution. Often, these factors vary from organisation to organisation and differ from each other given various business contexts. So far, guidelines or best practices for benefit realisation of RPA deployment (from adoption to delivery) rarely exist. Hence, development of a systematic approach supporting benefit realisation of an RPA solution becomes an open issue to address.

Challenge 2. Comprehensive metrics for benefits.

Measuring the benefits delivered by an RPA solution needs to be re-considered. Usually RPA benefits are measured in terms of reductions in time, cost, error, and human resources. However, RPA benefits are not limited to these direct and tangible outcomes. For example, the capacity of human resources saved from repetitive tasks automated by RPA can be reallocated to more creative tasks leading to increased productivity, and in this regard measuring of productivity should also be included in RPA benefits. Hence, benefit metrics for measuring benefits associated with an RPA solution in a comprehensive view and how to measure such benefits are worth of further study.

4.2. Readiness

Other than mere lists of 'things to consider for RPA', the existing literature provides no theoretically grounded, and/or empirically validated frameworks that are actionable. Challenge 3. Models for organisational readiness assessments.

Organisations require RPA readiness and maturity assessment frameworks. These frameworks will assist organisations to achieve strategic alignment by providing guidelines and tools to prepare for effective RPA implementations. Organisations will be able to formally determine the potential opportunities and barriers, and optimise their resource utilisation to achieve strategic objectives.

Challenge 4. Mechanisms For Infrastructure Assessments.

A model to assess the composition of an organisation's technology infrastructure to support an RPA implementation is currently lacking. Such a model would be a valuable tool for practice, enabling organisations to decide the conditions in which an RPA solution will best suit their needs.

4.3. Capabilities

The findings presented the nature of organisational capabilities required for RPA. Future research on how to assess and develop the required RPA capabilities can assist organisations to effectively plan and sustain their RPA initiatives.

Challenge 5. Models for organisational capabilities assessments.

Organisations also need a RPA capability assessment model. Such a model, with clear guidelines on how to adapt it within different project and organisational contexts, could systematically assist organisations to evaluate their organisational capabilities for RPA and assist design the road map for RPA programs.

Challenge 6. Maximise analytical capabilities.

We call for future research that can further investigate RPA affordances, to develop innovative solutions with RPA capabilities related to artificial and cognitive intelligence to support human decision making.

4.4. Methodologies

In Section 3.5, we discussed advice and recommendations found in the literature from 6 different dimensions, namely (1) preimplementation guidelines, (2) RPA tasks selection (3) stakeholders buy-in, (4) stages of RPA roll-out, (5) development and management of bots, and (6) advice on how to ensure long-term RPA success. It can be observed that although there are quite a number of papers describing experience reports and lessons learned from one or more RPA implementations within organisations, there is still a need for an overarching methodology which is vendor-neural and is underpinned by rigorous academic research. A successful deployment of RPA technologies in an organisation depends on a systematic approach to tackle the strategic level considerations surrounding the adoption of RPA, as well as the technical considerations surrounding RPA implementations.

Challenge 7. Methodological support for adoption.

Issues pertaining to the use of RPA from the strategic and managerial points of view, such as business drivers for RPA adoption and capabilities, guidance in ensuring RPA success, as well as RPA readiness are discussed quite extensively in literature. However, there is a need to further synthesise all the recommendations and proposed approaches for RPA adoption and to develop and evaluate such a methodology with academic rigour.

Challenge 8. Methodological support for implementation.

There is currently no consensus on what a methodology for RPA implementation will entail, although there is some agreement on the use of Agile methodologies for the development of RPA bots. Thus, there is a need for a methodology that focuses on the 'technical' considerations for large-scale RPA implementation. Such a methodology can build upon the existing themes discussed in this paper (e.g. Agile, software development life cycle, stage-based approaches).

Challenge 9. Critical Success Factors.

While the literature contains many 'points of advice on' and 'considerations for' RPA, it lacks a clear framework on what the critical success (or failure) factors are and how they may have different implications. These may be considered across the different RPA project lifecycle stages or the diverse organisational or process/task contexts in which RPA is considered. A deeper understanding of RPA critical success factors can help firms to identify and better manage different elements to gain the best outcomes from RPA.

Challenge 10. Socio-technical implications.

While RPA is rapidly growing, the changes its implementations brings forth to the workforce needs to be better understood and managed. Organisational research that unveils the socio-technical implications of RPA is needed to better guide RPA related IT/HR policies and assist with the design of effective change-management efforts within RPA programs.

4.5. Technologies

Although there are many references to technological aspects of RPA in the literature, they are almost exclusively presented at a high level. For example, there are broad categories of functionalities and architectures of current commercial tools, deployment constraints, process design, and the management of exceptions and risk. A much deeper exploration of these topics is needed to lift the capabilities of RPA technologies to address emerging domains and applications.

Challenge 11. Techniques for task selection.

Choosing the right activities for automation is one of the main challenges for successful RPA adoption. Design principles for selecting the candidate tasks for RPA are lacking empirical validation. Current techniques are largely developed by specific RPA vendors (within a basis of limited anecdotal evidence) and may be biased. Therefore, there is a need for formal, systematic and evidencebased techniques to determine the suitability of tasks for RPA.

Challenge 12. Systematic Design, Development, And Evolution.

A bot requires a design blueprint that captures the many possible sequences of detailed actions that the bot should perform to accomplish a task. For the most part, the design of a bot is still a largely manual effort, which can be tedious, inflexible, and errorprone. This represents a real hindrance to launching bots on a larger scale. To overcome these problems, there is a need to develop and implement capabilities to systematically extract logical structures from user activities and transform these into algorithms for bot executions, and to proactively and continuously acquire, develop, and apply knowledge about variations related to those tasks.

Challenge 13. Seamless handling of exceptions.

When RPA-enabled workflows are being enacted, the manifestation of certain operational risks, especially those that arise from run-time exceptions, are inevitable (cf. 3.6.5). However, bots are generally not coded with sufficient instructions to handle the various deviations that can arise. The causes of exceptions may range from a change to a user interface (e.g. different screen resolution or layout), a change to system interaction (e.g. the use of a different system required in handling an atypical scenario) to a change in business rules (e.g. special considerations regarding certain types of customers). As a result, bots may stop working or progress to an incorrect path, leading to the need for human intervention [9, 21, 49] . However, manual interventions and resolutions act to lessen or negate the benefits sought from the implementation of an RPA solution. Novel, system-based, automated exception handling architectures and frameworks are needed to maximise the benefits RPA offers so that the promised returns on investment can be realised.

Challenge 14. Techniques for managing scalability.

While small-scale, localised bot deployments may perform well, in practice scaling up the use of bots to provide solutions to a wider range of applications can become complex and are often unattainable [23, 13] . Enterprise-wide adoption of RPA technologies remains a challenge due to scalability problems. Innovative methods and techniques are needed to overcome the existing barriers to largerscale implementations.

Challenge 15. Proactive monitoring and control.

Currently, bots cannot monitor themselves and do not automatically adapt their behaviours to changes in business rules. However, business rule sets constantly change, as new rules are added and existing rules are updated or removed. Consequently, there is a risk of bots generating incorrect results due to their reliance on out-ofdate rules, leading to degradation in their performance over time. Early detection of such risk phenomenon is essential to minimise disruptions and to trigger, as soon as possible, the application of appropriate control mechanisms. As such there is a need to develop new approaches to monitoring the health of bots and to proactively adapt to changes in business rules.

5. Conclusion

Organisations aim to achieve their strategic objectives by investing in RPA technologies to improve their existing business processes and operations. In their quest to understand the preparation, selection, and implementation of RPA, organisations seek advice from vendors and consultancy organisations. Motivated by the increase in interest in Robotic Process Automation from industry and academia, this paper presents key insights from a structured literature review on the topic of RPA involving 125 papers and is guided by six overarching research questions. The paper synthesises the findings around six key themes, namely, RPA definitions, RPA benefits, RPA readiness, RPA capabilities, RPA methodologies, and RPA technologies. The paper acts as a call for action to the research community to synthesise and extend techniques from a variety of disciplines including business process management, process mining, data mining, artificial intelligence, machine learning, and risk management to design, operationalise, and evaluate more intelligent and robust suites of bots.

A software application that can replicate processes humans would do to move information through and between different technology systems; uses software as a virtual FTE to manipulate existing application software (e.g. ERPs, CRMs, and claims applications) in the same way that a person completes a process [26] • Technology to execute human tasks • Delivery of business processes • Replicating human behaviour

• FTE (full-time-equivalent) is not very applicable to robots (iii)

The use of software 'robots' or 'bots' to automate tasks as if a real person were doing them [39] • Software to execute human tasks • Replicating human behaviour

• None

The software (commonly known as a 'robot') used to capture and interpret existing applications for the purpose of transaction processing, data manipulation and communication across multiple IT systems [15] • Software to interact with other software • Trained software • Multiple IT systems

The automation of rules-based processes with software that utilises the user interface and which can run on any software, including web-based applications, ERP systems and mainframe systems [11] • Software using the user interface • Rule-based

• Repetition (any . . .including, iv)

A style of automation where a computer mimics a human's action in completing a task -effectively a computer drives application software in the same way that a user does [89] • Software to execute human tasks • Repetition (vi)

Software bots are being harnessed to mimic user actions in certain rules-based processes, eliminating the need for human intervention [12] • Software to execute human tasks • Rule-based • Fully autonomous

• None Software robots that are running code / processes, and that for the most part work in the user interface of applications, like humans do [22] • Software to interact with other software • Delivery of business processes • Replicating human behaviour

• Tautology (software . . .code, iv)

The automation of service tasks that were previously performed by humans [49] • Replicating human behaviour • Delivery of services

• Overly broad (vi)

A software-based robot that mimics the actions taken by a human colleague to perform a specific process or process part by accessing the user interface layer of different Information systems (IS) and tools [27] • Software to execute human tasks

SECTION

https://thoughtonomy.com/automation-robots-and-autonomics-know-yourterminology/.