1
Selecting IT controls for Robotic Process
Automation
Chris van Veen
S2769212
MSc BA Management Accounting and Control
Supervisor: prof. dr. J.A. Emanuels
Date: 22-6-2020
2
Abstract
Large amounts of data are generated by organisations each day. This data contains important information about the firm, in the form of customers or financial data. Managers make decisions based on this information, so the reliability of this data is vital. IT controls are in place to check and assure the quality of the IT systems and the data it holds. The processes of checking the IT controls are time-consuming and require human interaction in some cases. These IT controls that require human interaction are known as IT user controls. Automation might help in saving time and reducing the error rate. Robotic Process Automation or RPA is a simple technology that helps organisations in the automation of processes. The case organisation wants to select the right IT user controls for automation with RPA. In this paper a design science approach is used to develop a selection model that solves the problem for the case organisation. This model follows the characteristic of IT controls and the capabilities of RPA. Based on internal documents and interviews with the case organisation the model is created. The selection model has steps which are more general and apply to different organisations. External validation at a different firm made it clear that, some aspects are specifically linked to the case organisation. With the growing interest from organisations to implement RPA in their business processes, research to the impact and right implementation of RPA becomes more relevant.
Introduction
3 Controls on the systems are in place to contribute to the correctness of the data and prevent manipulation. The set of internal IT controls is an example of these controls. The objectives of the internal IT controls are compliance, efficiency of operation and reliability of financial data (Rubino et al., 2017). Since different stakeholders rely on internal IT controls, improper management of the controls may result in reporting errors and financial losses (Chang et al., 2014). Internal IT controls are a vital element of the controls in the organisation. Not only managers use financial data to make their decisions, so do investors. Auditing of the IT controls is essential for the success of the controls.
4 possibilities for academics to investigate the possibilities and implications of RPA on organisations.
In this study a design science approach is used. Design science follows a problem-solving paradigm (Hevner et al., 2004). The researcher takes a problem from an organisation and through this approach, the design of a solution in the form of an artefact, is the outcome of the study. An artefact is a model, method, construct or instantiation which can be used in the specific context of research (Hevner et al., 2004). Taking this qualitative approach, this paper can add some new information about RPA for IT controls. As there is little information from a business perspective about the use of RPA within organisations, other streams of literature are necessary to create the artefact. The goal of design science is to change the current situation to the preferred one (Geerts, 2011), which is in solving the problem that is presented by an organisation. For the design science approach presented in this paper, a case organisation is used. The validation of the new artefact is done within the case organisation and at another company. The organisation is an American producer of ingredients for the food and pharmaceutical industry. As a listed firm on the American stock market, they must comply with the Sarbanes-Oxley act (SOX). SOX requires a statement in the annual report, where management and auditors provide assurance that the internal controls are effective (Grant et al., 2008). For compliance with SOX, the organisation has multiple IT controls in place, which are used to check the reliability of the financial data. Checking these controls is labour-intensive, so automation could have major benefits. As the work is mostly repetitive and requires checks in multiple systems, a software robot could take over parts of the work. Automation results in more efficient and effective controls with a robot working on the time-consuming tasks. The case organisation started to work on the implementation of the first robot for a control. For the long term, the organisation wants to further implement RPA for other internal IT controls. Secondly there is the motivation to take the robot to other branches of the firm, like the US headquarters. The case organisation selected the first control without a justification for that specific control. However, for a further roll-out of RPA, it would be helpful to select controls based on a model. This gives a solid basis for development of a robot and helps in creating acceptance in the firm. As with any new technology, acceptance is needed to successfully implement the new technology in the organisation (Szajna, 1996). The main question for the design of the artefact will be: “How to decide which IT user controls can be automated with the
use of RPA?” The artefact is a selection model which uses the characteristics of internal IT
5 internal documents of the firm are used and the link is made with existing literature. The model is externally validated by another organisation to get some more details about the generality and usability of the model. From this validation it became clear that some aspects of RPA are linked to the kind of process which are automated, and some are not connected to the process. These general properties of the business processes make the artefact useable in more cases, however some modifications are necessary. The model may provide a basis for other organisations in selecting their IT control for automation. In the creation of the artefact, this paper limits the scope to the selection of the right controls. After the selection, the implementation of RPA is crucial. Not only does the robots need to be managed, some acceptance of the new technique is required to get people working with the technology.
The selection model as an artefact is helping the organisation in the further implementation of RPA, but the study will contribute additionally to academic literature. Existing literature on design science is scarce in the field of controlling and accounting. These fields focussed on a research approach which looks at the understanding of why something happens (Geerts, 2011). With this study the field of design science is further extended in a business setting. Another addition to the literature will be on RPA. One of the questions raised by Van de Aalst et al. (2018) is what characterises make a process suitable for RPA. The selection model designed in this paper might provide an answer to this question in the case organisation.
Literature review
Internal controls
Organisations generate a lot of data, not only about the customers but from internal streams of data as well. A large part is used for accounting and the creation of financial reports. Especially if firms are split in multiple divisions, this information needs to be combined to get an overview which can be reported to the stakeholders. However, correctness of the data is essential, as decision-making relies on this information. Reliable information is not solely relevant for the organisation itself, but external stakeholders need them in decide whether to invest. A control system can provide assurance on the quality of the data.
6 2014). For controlling the information flowing through the system, several approaches can be taken. One type of control is exerted in the ERP system, by constraining users to make large transactions or limit access for transactions to specific roles in the organisation (Maas et al., 2014). This kind of control is part of the internal controls of a firm. The internal controls provide some assurance about the correctness of information generated in the IT systems. The IT systems are also used for managerial decision-making, and auditing (Rubino et al., 2017). Since organisation highly depend on IT systems, controls become increasingly relevant. This dependency on data and information, makes the IT systems a vital component of the organisation.
For assuring the quality and reliability of data, a specific group of internal controls are defined as IT controls (Rubino et al., 2017). IT controls are split into two major categories: IT general controls and IT application controls. IT general controls are controls that provide assurance for the systems to function as they should (Marley & Mooney, 2015). These controls oversee the procedures and policies which are applicable to many applications and guarantee the right operation of the IT system (Rubino et al., 2017). For example, procedure of back-ups is part of the IT general controls. The IT application controls are related to the functioning of specific software packages (Marley & Mooney, 2015). The application controls rely on the general controls but include specific functions to control the overall performance and accuracy of the application (Rubino et al., 2017). With the IT application controls, the software package restricts the user from making a transaction for which it lacks authorisation. The main question of this paper mentions a third kind of IT control. The IT user controls are the IT controls which require human interaction in the procedure. These controls are like the application controls, but the human interaction means that steps in the automated procedure are performed by a human. For example, someone wants access to a new part of the system and the human needs to compare the authorisation with an authorisation matrix if the person has clearance. This distinction is important when designing the control framework. While some of the IT controls, like the general IT controls are companywide, application controls can only be applicable in a specific situation. This makes the design of the control framework detailed in some conditions and more general in others.
7 of the accounting information can be given by the internal control system. However, a weak internal control system impacts the firms performance (Stoel & Muhanna, 2011). Organisations therefore have an incentive to invest in a stronger IT control system. For a company this means that the effectiveness of the ERP systems is under constant audit (Chang et al., 2014). A control framework is used to keep track of the internal controls and this makes it easier for management and external auditors to assess the effect of the ERP system’s controls (Chang et al., 2014). The internal IT controls are in place to cover any IT operational risk events. These events are any instance of a threat to the confidentiality, integrity or availability of data or when an IT asset is compromised (Benaroch et al., 2012). When a risk events occurs, the accuracy of the data cannot be guaranteed. Decision-making based on information then becomes impossible, so the controls are vital for the organisation.
8
Robotic process automation
Automation of processes helps organisations to reduce the workload of employees and decrease the error rates. Industrial processes began with automation and now digital processes follow that same path. In car manufacturing automation is a common practice, as most cars are built with the help of robots and software. A study in a car manufacture shows that automation reduces the negative effects related to higher complexity of the task (Fast-Berglund et al., 2013). The focus in this study is on cognitive automation. A cognitive tasks is a tasks which require cognitive effort of the worker, like for example decision-making (Fast-Berglund et al., 2013). Complex tasks that require cognitive work, could benefit from automation. In the case of IT user controls, someone has a cognitive task which works in a digital environment. A digital robot might have the capabilities to take over these tasks and reduce the workload and lower the error rate. New tools are available which help in the development of digital robotic workers. The set of tools is called robot process automation, or RPA.
9 The frequency of the task is the main factor which justifies the kind of automation solution (van der Aalst et al., 2018). When tasks occur frequently, economic benefits are in complete automation of the process instead of RPA (van der Aalst et al., 2018). In that scenario the high frequency of the process with high volumes of data, makes the choice for a solid and stable kind of automation better. When tasks happen very occasionally, automation would not provide any benefits (van der Aalst et al., 2018). In this situation a human will process the tasks faster manually than the time it would take to automate the process with RPA or any other solution. The tasks that are situated between these situations, are the ones which are repetitive but not to frequent that justifies traditional automation (van der Aalst et al., 2018). When established what the frequency of the processes are, a second factor which influence the automation is the suitability of the process. Software robots built with RPA require processes which consists of rule-based tasks without requiring judgement, that are done manually and require multiple systems access (Hofmann et al., 2019). A software robot with more advanced properties like artificial intelligence (AI) and machine learning capabilities, increases the number of processes that are suitable for automation with RPA (Romao et al., 2019). This is a feature which could help the adoption of RPA within organisations (van der Aalst et al., 2018). As the combination of RPA and AI is still limited in practice, this paper will not consider AI and machine learning capabilities as part of RPA. The last criterium is for the process to require manual interaction with the software systems (Leshob et al., 2018). When there is not a human who uses the interfaces of the systems, RPA would not work. These three criterium already narrow down the kind of process which are suitable for RPA, but there are likely more aspects involved in the selection of the right kind of automation solution.
10 programming, innovation can be initiated by the process owner (Hofmann et al., 2019). Understanding of the robot and RPA capabilities of the human workers is needed to deploy RPA in an organisation (Hofmann et al., 2019). For the organisation it is important to keep an overview of the robots that are in place. With the relatively simple tools, there is the potential to lose track of the robots. Not only understanding of the robot is key, but of the automated process as well. As the robot follows a rule-based predefined path, not knowing the exact steps when building the robot diminish the benefits of RPA. Increased efficiency through RPA is not achieved when inefficient process steps or errors within the process itself are programmed in the robot. This leads to inefficiency and additional costs (Hofmann et al., 2019). The work done by the robot becomes unnecessary when humans need to correct the actions of the robot. With the promise of machine learning and artificial intelligence, this could become less of an issue as robots can learn directly from humans and take non-standard cases (van der Aalst et al., 2018). The further development of RPA tools will help organisations in the future in automating repetitive tasks and shift the focus to specialised work.
Some studies describe the use of RPA for auditing and controlling. The repetitive tasks in auditing like internal control testing, reconciliations and detail testing are potential candidates for automation with RPA (Moffitt et al., 2018). General use of RPA in auditing requires some important aspects to consider. The RPA tools and the data used by the robot need to be reliable and privacy and security should be monitored with the use of RPA (Moffitt et al., 2018). RPA might reduce the time an auditor needs for audits due to the automation of the work. However, new skills are necessary for the auditor due to the increased complexity of the work. From a study across the ‘Big Four’ accounting firms, RPA development in their activities provide some insights (Cooper et al., 2019). In the controlling function for example, RPA has the potential to automate 5-20% of the controlling processes (Cooper et al., 2019). Taken this to a bigger scale, within the accounting or client firm, between 10 and 30% of the general accounting processes can be automated with RPA (Cooper et al., 2019). Even though the work gets automated, the accounting firms are not expecting to reduce the number of employees (Cooper et al., 2019). This is the results of a change in work, rather than the replacement of the work. Robots performing the repetitive tasks and human workers focus on the tasks that require judgement. This robot-human interaction is a vital part of the success of RPA.
11 RPA as an IT project. Investing in these kind of projects can result in an important source of competitive advantage (Imamoglu & Gozlu, 2008). However, many IT projects tend to fail in meeting the objectives (Standing et al., 2006). The most common reasons for these projects to fail are the poor planning within the project, no need for a solution in the organisation and lack of support or involvement from top-management (Whittaker, 1999). Other reasons for failure can be found in the complexity of the project or on the social side like motivation or skills of the employees (Lehtinen et al., 2014). Most of the time, the interaction between several aspects result in the failure of the new IT project (Lehtinen et al., 2014). At the start of the project it is important to have a basis of support, not only from top management but from the employees as well. This aspect of support is explained by the technology acceptance model (TAM). The model states that the actual use of a system is based on two beliefs, which are the perceived usefulness and perceived ease of use (Davis et al., 1989). In this model the acceptance of a system, is based on the person’s intention to accept the technology (Szajna, 1996). Managers that want a new technology in the organisation, need to promote the technique by showing the usefulness and user friendliness (Wallace & Sheetz, 2014). These two belief predict the intentions of use well enough to focus on when a new technology is implemented (Davis et al., 1989). Without the intention of usage, the new technology will not lead to the complete adoption in the business setting. In the case organisation the software robots require investments for development and maintenance. When there is no support from the person who needs to work with the robot, this could eventually lead to the robot to become obsolete. The two beliefs in the technology acceptance model are vital for the success and acceptance of RPA in an organisation. Selecting the right IT controls based on a model, might provide a tool to explain the relevance of RPA.
Methods
Design science approach
12 The design science approach is a problem-solving paradigm (Hevner et al., 2004). For a problem it tries to identify a solution in the form of an artefact. Through creativity and problem-solving capabilities, the researcher needs to identify the solution for the given organisational problem (Hevner et al., 2004). Design science is a common practice in the field of Information Systems (IS) research (Gregor & Hevner, 2013). IS research use theories from different angles, like computer science and economics, to solve problems that occur with IT in organisations (Peffers et al., 2007). By the use of design science in IS research, five types of design science can be described: design theory, design science methodology, design-oriented research, explanatory design theory and action design (Peffers et al., 2018). For this paper, the design science research methodology is most applicable. This genre focusses on the design and construction of a practical and applicable artefact that contributes to the effectiveness of IS in an organisation (Peffers et al., 2018). The role of theory in the case of design science research is about creating more knowledge about the design aspects and the technical basis of the artefact (Peffers et al., 2018). This is the kind of literature found in the literature review, where information about internal IT controls and RPA are explained. With the information from these topics, the design process of the artefact becomes easier.
13 important about the solution. The objectives of the solution should be derived from the problem statement (Peffers et al., 2007).
The next stage is design and development of the artefact. The artefact is a construct, a model, a method or an instantiation, which is explained in detail so it can be implemented and used in the specific context (Hevner et al., 2004). This artefact is never the complete solution to the problem, but helps to further develop ideas, practices or products that could be used (Hevner et al., 2004). In this step, the research will focus on creating a solution to the stated problem with the use of theories and known methods (Geerts, 2011). With this knowledge the functionality and architecture of the artefact are established, which leads to the design of the real artefact (Peffers et al., 2007). Most of the time, the artefact brings novelty, generality and significance that contributes to the literature (Hevner et al., 2004). In the development of the artefact, the focus will be on collecting theoretical information about the possibilities of RPA. Besides this, information from the organisation is required. As the focus is on creating a selection model, the characteristics of the IT controls are essential in creating a model. The internal documents like the risk control matrix and IT control descriptions help in this step of designing the artefact. During the process, each step of model is checked with the available information and small iterations are made to improve the model. Once the artefact has been developed, the model is demonstrated, to prove that the designed artefact is a solution to the problem (Geerts, 2011). It is about showing the artefact can solve the problem with an experiment (Peffers et al., 2007). The experiment in this paper is the use of the demonstrative interview 2 (table 1) with the case organisation. During this meeting, the artefact is showed, and feedback is received. The compliance manager in this case is the person who is responsible for the IT controls and the one who is selecting the IT controls for automation. The model is tested by going through the artefact and checking whether it meets the requirements of the solution. In this step the comparison with the demonstration and the stated objectives are made (Geerts, 2011). When there are any mismatches at this point, the model goes through an extra iteration and modifications are made.
14 is also evaluated for its effectiveness. Besides the internal evaluation, the model is externally validated. In this step, the artefact is evaluated in another organisation than the one the artefact was built for. The interviewed organisation listed as interview 3 (table 1), was consulted to check the model for its validity and generalisation in another company. This makes the model of a higher quality because the information from this interview gives some new insights in the model. When the artefact has the potential to function in other organisations, it is a wider solution than to the problem stated by the case organisation. The person in interview 3 is responsible for building RPA robots and has therefore knowledge about important characteristics of the automated processes. Besides that, he is part of the process optimisation. The final step is the communication of the artefact. This is the process of presenting the utility, novelty and effectiveness of the solution (Geerts, 2011). The outcome of the research needs to be understandable by a manager and from a technical perspective, so the audience can work with the presented solution for the problem (Hevner et al., 2004). The artefact is communicated with the case organisation and researchers for the further development of the artefact.
Table 1: Table with the interviews performed for this study.
Interview Date Interviewee(s) Goal Reference
1
31-3-2020
Compliance and Security Manager Senior IT Internal Auditor
(Case organisation) Requirements of artefact Appendix I 2 18-5-2020
Compliance and Security Manager (Case organisation) Internal validation Appendix II 3 8-6-2020
Global Innovation Specialist (External organisation)
External validation
Appendix II
15
Case
The problem for this paper is presented by the case organisation. This US based producer of ingredients for the food and pharmaceutical industry, has an international division based in the Netherlands. The company is listed on the American stock market, and therefore it is required to follow the SOX regulations. With over 200 business sites across the globe, the streams of information are divers and come from different systems. The internal IT controls are used in the development of the artefact. The focus is on the IT controls that have a human component, which entails the controls that are linked to controlling human interactions with the system. These IT user controls are the focus of controls when the artefact is designed.
The SOX act has impact on the internal controls of the firm. With the SOX act, management of the firm, as well as the auditors require to take responsibility for the correctness of the financial reporting and the adequate effect the IT controls have (Grant et al., 2008). SOX made management require to asses and report the effectiveness of the controls in the organisation (Grant et al., 2008). Within the case organisation IT controls are in place on their ERP system. This system is audited to show that the IT controls are operating as they should, and that the resulting information is correct. However, some of these IT controls are manual processes. Automation in that case might help in reducing the workload and reducing the number of errors associated with IT controls.
Artefact design
Problem definition and requirements
16 there was a conversation about the company itself, to get a better idea on how the firm operates. This helps in understanding the purpose of the IT controls and how RPA might help. In this meeting it became clear the organisation started the implementation of the first robot for an IT control. At the start of the project, the organisation faced the problem that the selection for the IT controls lacked a scientific foundation. The IT control was chosen without a clear idea if that IT control was the right one to automate. Based on the risk control matrix discussed during the meeting, it became apparent that there were multiple candidates for RPA, but the selection of the right ones remained an issue. Without a basis, the investment made in RPA might not be justified. Selecting the wrong IT control could result in building a robot that does not have any benefits. The organisation expressed the desire for a way which helps in the selection of suitable IT controls for RPA. This resulted in the research question of this paper; “How to decide which
IT user controls can be automated with the use of RPA?”
17 are not in the narratives, but those are important for the use of RPA. When asked about the suggested model, the organisation responded that this kind of model could help in the implementation of RPA.
Selection of RPA suitable IT controls
19 Each step is motivated by several sources of input. Before this model can be used for the selection of IT controls, there are some important aspects. The first step is to ensure that two distinct criteria are met before the rest of the model is applicable. The activity in the control should require manual interaction with an application and the tasks are rule based (Leshob et al., 2018). The model therefore uses IT user controls to decide if the control is suitable. Without these conditions RPA is not the right tool for automation, as the technology uses both conditions in automating repetitive work. When the IT control meets the criteria, it can proceed to the next step. This step looks at the process which is underlying the IT control. For any process to function with RPA, the process should work optimal. Building a robot requires understanding of the underlying process, as the robot takes over the work. Errors and inefficient steps in a process, will result in additional costs and the use of more resources (Hofmann et al., 2019). The question asked in this step, is whether the process is optimised for RPA. In broad terms this will mean the process functions without errors, has no inefficient steps, and the steps are clearly defined. When this is not the case, the process needs some optimisation before RPA can handle it. When the process is optimised, the next step of the model is about the function of the robot. The robot has the possibility to take over repetitive human tasks, but it can also perform tasks that are not performed by a worker due to the repetitiveness. When an IT control is checked daily, it would mean a lot of work and this will not provide any benefits due to the time spend on checking the controls. Within the case organisation, there are two types of tasks which the robot can do, monitor or check the control. With monitoring the robot is part of the controls and checks the system on a regular interval. In the model this is referred to as monitor. The robot could check a setting in the ERP system daily and report to the control owner when the setting does not meet the requirements. Another task is in checking the success of a control for an audit. Selecting the required data and assist in analysing this data. This is referred to in the model as check. Constant monitoring and periodic checks have different characteristics. This has implications for the rest of the model. That is why a distinction between these two tasks is made in the early stages of the selection model.
20 checked daily, monitoring would be a better approach to take. For checks on a yearly basis, the benefits from automation will be diminished by the interval making it not suitable for RPA. Also, each year the robot needs updates due to changes in the software interfaces, making the benefits disappear. Therefore, using RPA is not beneficial and the model suggests looking at other controls for automation. IT controls that are checked monthly or quarterly are suitable in this model.
21
Table 2: Three categories for the number of steps which are used in the selection model. The description helps in selecting the right IT control.
Cut-off points Description
Low There are a few steps in the model involved and these steps are relatively simple. The manual execution of this control will not take much time. Medium The steps are increased and become more complex. For someone to handle
these by hand, it takes considerable time.
High A lot of steps are involved. Some of the steps are complex, as they require more detailed rules to executed. Plenty of time is saved if automated.
When the robot is used to check the IT control, the number of steps should be medium to high to be use for RPA. The low frequency of the control makes it beneficial if a lot of work is done by the robot. Extra resources in the development of the robot are necessary to prevent any mistakes. In the case of monitoring, the high frequency of the control makes the number of steps lower. As a robot monitors daily, the impact of failures in the robot is higher. To reduce the complexity, monitoring robots should focus on small controls. As with both sides of the selection model, not meeting this requirement does not result in a unsuitable control. The control is less suitable for RPA, but robots can still take the work. The question is whether this will lead to any benefits for the organisation.
22
Table 3: Three categories for the accepted deviations which are used in the selection model. The description helps in selecting the right IT control.
Cut-off points Description
Low The IT control has no or a small number of accepted deviations. This makes it possible to add them to the robot and report on true deviations.
Medium The number of accepted deviations increase, but it still possible to handle them. The occurrence of these accepted deviations is medium, and someone is not working a lot on checking the deviations before RPA.
High Many accepted deviations are linked to IT control. Due to the large amount, it takes a lot of time to check the deviations in the control.
For monitoring robots only controls with a low number of accepted deviations are suitable. These controls are straightforward making the robot not complex. Even when there are a small number of accepted deviations, these can be added to the robot. Medium or high cut-off points state that the control is not suitable. For the checking robot the medium category is added, as the smaller interval makes it possible to spend some time on checking the deviations the robot cannot handle. In this case, the robot does not require to have all the accepted deviations programmed, but it reports the deviations which are checked by the control owner. An IT control in the high category is less suitable for the check robot, like the case of monitoring.
23 Following the model there are four possible outcomes. RPA is not a suitable way of automating the IT control, RPA is less suitable for the automation of the IT control, RPA is suitable and has priority or RPA is suitable for the automation of the control. In the case RPA is not suitable for the automation of the control, it might be possible to make some alterations to the process. With changes to the process of the IT control, RPA can become suitable. This is possible when steps are lowered or there are fewer accepted deviations.
Demonstration and validation
The final steps in the development of the artefact are the demonstration and validation of the model. The design science approach takes several iterations to design a solution. For the internal validation of the model, the artefact is demonstrated and discussed with the case organisation. This demonstration can provide some new insights to further develop the model. For this study, a first model was presented to the case organisation and during a meeting the model was discussed. The report of this meeting can be found in Appendix II. Feedback received in this meeting was added to the model and this resulted in a new version. This modified model is presented in this paper. One adjustment is the further extension of process optimisation within the model. As explained in the literature review, the automation of process requires that the processes themselves are performing optimal ahead automating them with RPA. Therefore, a new step is included which covers the optimisation of the as one of the first steps in the model. The model assumes a control that works optimal, so the process needs some optimisation first. Another important element in the feedback was the selection of the number of steps and deviations. In the first model these elements were selected based on the information from the organisation. During the session, some questions were raised about the validity of these numbers, which resulted in changes in the presented model. With the inclusion of a three-level cut-off point, the use of numbers is avoided. With a more general approach to the number of steps and accepted deviations, the model become more practical for the organisation. The user of the model has some judgement in the selection of the control.
24 tool in automating several business processes. This organisation is referred to as the interviewed organisation. Their main goal of automation by RPA is to get less time spend on this process and let people focus on other aspects of their work. To make a comparison with the case organisation in this paper, the interview contained some question about the approach to RPA at the interviewed firm. The report of the interview can be found in Appendix III.
For the validation of the artefact, the selection model was presented to the interviewee and he was given the opportunity to provide some feedback to this model. Besides feedback to the model during the interview the possibility of using the selection model within his firm was discussed. This led to some new aspects and ideas which were not considered in the presented artefact. One aspect is the volume of data handled by the software robot. The model uses frequency of the IT control, but not the amount of data which is linked to the IT control. When a control has a low number of steps, but in that step a lot of data is processed, the model could suggest that RPA is less suitable. This is not the correct outcome, because the large volume of data would make RPA appropriate. It would save a lot of time when the robot is handling this vast amount of data. The biggest difference between the interviewed organisation and the case organisation is the processes for which RPA is used. This means that the artefact cannot be used directly for the interviewed organisation. That company uses RPA in administrative processes like invoices, while the case organisation adopted RPA for controls and compliance. One step which is specific for the case organisation is the distinction between a robot that helps with the checks and a robot that monitors. For administrative processes there is no distinction because these processes occur only when requested and on a shorter time span. Another major difference is the factor time. The artefact does not have a selection criterion for time. Instead, the model uses frequency and number of steps to make a estimate of the time spend on the control. The interviewed organisation however had a record of the time spend by an employee on the processes, and thus making it possible to have a cut-off point based on time. The interviewed organisation uses the guideline that below 650 hours per year spend on the process, will not be automated with RPA. Time was a factor that could really help in de model to make it usable for another organisation.
25 some cases it is impossible to build a robot that is able to handle a lot of variations in the data. This step was not used in the interviewed organisation as such, but instead they look at the process itself. When a process has a lot of deviations, it might be inefficient and some of the deviations can be removed from the process. This is an addition that might help in better selecting the controls. Overall, the model showed similarities with the work in practice with the interviewed firm. But with the different approaches to RPA by the organisations, the model might not be applicable to every organisation. Some of the basic aspects are still relevant, but the case specific factors like monitoring of the control, affect the usability of the model for the automation of more general processes. At the end of the interview, the importance of acceptance was stressed. Based on experience, the interviewee had noticed that without real acceptance for the robot, RPA became obsolete. The robot was used for a short period of time, but eventually the employees did not use them anymore and took over the work the robot was doing. This is a major problem when a new technology is presented in a organisation.
Conclusion
RPA has a lot of potential in a business setting. Software robots take over work from employees so they can focus on other aspects of their work (Lacity & Willcocks, 2017). This paper took a design science approach in solving a problem which was derived from a case organisation. The research question as stated in the introduction is: “How to decide which IT user controls can be
automated with the use of RPA?” The created artefact answers the question. This selection
26 the time someone spends on a control as a major determinant in selecting a process, the case organisation has no record of this data. This makes the model on some aspects specific to the case organisation.
The methodology in this paper shapes the selection model. Design science is using a problem-solving approach to find a solution for the problem stated by an organisation (Hevner et al., 2004). This means the artefact is related to the case organisation. How it will function for other organisations is unclear. By external validation of the model, general aspects were found that are applicable to the external organisation as well. Since the external organisation uses RPA for different purposes, the generality of the model can be argued. For example, the number of steps in the process underlying the IT control, is now linked to the narratives of the case organisation. During the external validation it became clear that, using the number of steps in a process was not really related to the kind of processes they select for automating with RPA. The model might help the case organisation, but for different companies or another types of process, the artefact needs modifications to function in other settings. This also shows the limitations of the model. As the artefact is based on internal documents from the case organisation, applying the model on a different organisation requires most likely modifications. This paper cannot provide certainty to the extent of which the model can be generalised to other companies or situations. As the external validation was not performed for similar processes, the specific effects of IT controls within the case organisation on the model are not checked. When the model was internally validated, the interviewee explained how the case organisation was already automating all the IT user controls and reducing the spend time on all these IT controls from 40 FTE monthly to 30 minutes each day (Appendix II).
27 solution to a problem, but it also demonstrates new insights and ideas for future research to work on RPA. For future research, some questions might be relevant to investigate, like:
• What other characteristics are relevant for the selection process?
• What is needed to make a more general model for business process selection to automate with RPA?
• What are the right cut-off points in the model?
28
References
Benaroch, M., Chernobai, A., & Goldstein, J. (2012). An internal control perspective on the market value consequences of IT operational risk events. International Journal of
Accounting Information Systems, 13(4), 357–381.
https://doi.org/10.1016/j.accinf.2012.03.001
Brown, A. B., Keller, A., & Hellerstein, J. L. (2005). A model of configuration complexity and its application to a change management system. 2005 9th IFIP/IEEE International
Symposium on Integrated Network Management, 2005. IM 2005., 631–644.
https://doi.org/10.1109/INM.2005.1440836
Chang, S.-I., Yen, D. C., Chang, I.-C., & Jan, D. (2014). Internal control framework for a compliant ERP system. Information & Management, 51(2), 187–205.
https://doi.org/10.1016/j.im.2013.11.002
Cooper, L. A., Holderness, D. K., Sorensen, T. L., & Wood, D. A. (2019). Robotic Process Automation in Public Accounting. Accounting Horizons, 33(4), 15–35.
https://doi.org/10.2308/acch-52466
Davis, F. D., Bagozzi, R. P., & Warshaw, P. R. (1989). User Acceptance of Computer
Technology: A Comparison of Two Theoretical Models. Management Science, 35(8), 982–1003. JSTOR.
Fast-Berglund, Å., Fässberg, T., Hellman, F., Davidsson, A., & Stahre, J. (2013). Relations between complexity, quality and cognitive automation in mixed-model assembly.
Journal of Manufacturing Systems, 32(3), 449–455.
https://doi.org/10.1016/j.jmsy.2013.04.011
Geerts, G. L. (2011). A design science research methodology and its application to accounting information systems research. International Journal of Accounting Information
Systems, 12(2), 142–151. https://doi.org/10.1016/j.accinf.2011.02.004
Grant, G. H., Miller, K. C., & Alali, F. (2008). The effect of IT controls on financial reporting. Managerial Auditing Journal, 23(8), 803–823.
https://doi.org/10.1108/02686900810899536
29 Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information
Systems Research. MIS Quarterly, 28(1), 75–105. JSTOR. https://doi.org/10.2307/25148625
Hofmann, P., Samp, C., & Urbach, N. (2019). Robotic process automation. Electronic
Markets. https://doi.org/10.1007/s12525-019-00365-8
Imamoglu, O., & Gozlu, S. (2008). The sources of success and failure of information technology projects: Project managers’ perspective. PICMET ’08 - 2008 Portland
International Conference on Management of Engineering Technology, 1430–1435.
https://doi.org/10.1109/PICMET.2008.4599756
Kokina, J., & Blanchette, S. (2019). Early evidence of digital labor in accounting: Innovation with Robotic Process Automation. International Journal of Accounting Information
Systems, 35, 100431. https://doi.org/10.1016/j.accinf.2019.100431
Lacity, M. C., & Willcocks, L. P. (2017). A new approach to automating services. MIT Sloan
Management Review, Fall. http://sloanreview.mit.edu/
Lehtinen, T. O. A., Mäntylä, M. V., Vanhanen, J., Itkonen, J., & Lassenius, C. (2014). Perceived causes of software project failures – An analysis of their relationships.
Information and Software Technology, 56(6), 623–643.
https://doi.org/10.1016/j.infsof.2014.01.015
Leshob, A., Bourgouin, A., & Renard, L. (2018). Towards a Process Analysis Approach to Adopt Robotic Process Automation. 2018 IEEE 15th International Conference on
E-Business Engineering (ICEBE), 46–53. https://doi.org/10.1109/ICEBE.2018.00018
Li, C., Peters, G. F., Richardson, V. J., & Watson, M. W. (2012). The Consequences of Information Technology Control Weaknesses on Management Information Systems: The Case of Sarbanes-oxley Internal Control Reports. MIS Quarterly, 36(1), 179–203. JSTOR. https://doi.org/10.2307/41410413
Maas, J.-B., Fenema, P. C. van, & Soeters, J. (2014). ERP system usage: The role of control and empowerment. New Technology, Work and Employment, 29(1), 88–103.
https://doi.org/10.1111/ntwe.12021
Marley, R., & Mooney, J. L. (2015). Essential IT Controls for Preventing Cash Fraud. Journal
of Corporate Accounting & Finance, 26(2), 49–57. https://doi.org/10.1002/jcaf.22019
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.
30 Peffers, K., Tuunanen, T., & Niehaves, B. (2018). Design science research genres:
Introduction to the special issue on exemplars and criteria for applicable design science research. European Journal of Information Systems, 27(2), 129–139. https://doi.org/10.1080/0960085X.2018.1458066
Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. Journal of Management
Information Systems, 24(3), 45–77. https://doi.org/10.2753/MIS0742-1222240302
Provost, F., & Fawcett, T. (2013). Data Science and its Relationship to Big Data and Data-Driven Decision Making. Big Data, 1(1), 51–59.
https://doi.org/10.1089/big.2013.1508
Romao, M., Costa, J., & Costa, C. J. (2019). Robotic Process Automation: A Case Study in the Banking Industry. 2019 14th Iberian Conference on Information Systems and
Technologies (CISTI), 1–6. https://doi.org/10.23919/CISTI.2019.8760733
Rubino, M., Vitolla, F., & Garzoni, A. (2017). How IT controls improve the control environment. Management Research Review, 40(2), 218–234.
https://doi.org/10.1108/MRR-04-2016-0093
Standing, C., Guilfoyle, A., Lin, C., & Love, P. E. D. (2006). The attribution of success and failure in IT projects. Industrial Management & Data Systems, 106(8), 1148–1165. https://doi.org/10.1108/02635570610710809
Stoel, M. D., & Muhanna, W. A. (2011). IT internal control weaknesses and firm
performance: An organizational liability lens. International Journal of Accounting
Information Systems, 12(4), 280–304. https://doi.org/10.1016/j.accinf.2011.06.001
Szajna, B. (1996). Empirical Evaluation of the Revised Technology Acceptance Model.
Management Science, 42(1), 85–92. https://doi.org/10.1287/mnsc.42.1.85
van der Aalst, W. M. P., Bichler, M., & Heinzl, A. (2018). Robotic Process Automation.
Business & Information Systems Engineering, 60(4), 269–272.
https://doi.org/10.1007/s12599-018-0542-4
Wallace, L. G., & Sheetz, S. D. (2014). The adoption of software measures: A technology acceptance model (TAM) perspective. Information & Management, 51(2), 249–259. https://doi.org/10.1016/j.im.2013.12.003
Whittaker, B. (1999). What went wrong? Unsuccessful information technology projects.
Information Management & Computer Security, 7(1), 23–30.
31
Appendix I
Interview report
Date March 31st, 2020
Time 14:00 – 14:30
Interviewees Compliance and Security Manager Senior IT Internal Auditor
Subject Requirements of the artefact
Purpose of the meeting
The goal of this meeting is to gather more information from the organisation and determine the requirements of the artefact. After the scope and problem definition were identified, this meeting is used to check this scope. For a model which is used to select the right IT controls, the usability is vital. This results in questions about the information available within the organisation and how easy it can be obtained. Besides the usability and validity of the solution, the requirements to reach this are a talking point during the meeting.
Questions
The questions for this meeting are related to the requirements of the solution. Answers to these questions are used in the development of the artefact. The requirements determine what aspects are allowed and valid in the model. Besides the question shown below, during the meeting other question might come up. Some of the question which were selected before the interview:
• How was the selection done of the IT control for the first RPA implementation?
• Is the problem definition this paper will work with, considered as a problem by the organisation?
• What kind of information about the IT controls is available in the organisation and how accessible is this?
32
Outcome of the meeting
The short meeting gave some new insights and ideas which are used in the rest of this paper. To further scope the project and get a better idea of the possibilities, the meeting was helpful. First there was a small explanation of the controls within the organisation. Checks are performed and when a control does not align with the narrative, this is reported in the SOX audit report. There are three options why a control does not align. Either there is a mistake in the system, or in the narrative or the last option when there is a problem in the overall design of the control framework. With RPA a robot would monitor or check the situation and report any mistakes. An important document for internal auditing is the narrative of the control. This document fully explains the control and all the information related to the control. For example, the number of systems involved, and which versions of these systems exists. SOX requires an organisation to have these complete narratives as they help in covering the risks related to IT systems.
With the information in the narratives, the model could have a solid basis. The steps in the model need the information which is available for the control. One factor which was considered before the meeting, was the factor of time spend on the control. However, when asked during the meeting, this characteristic was not reported as a single number. The narratives contain more information like the accepted deviations in the process or the number of steps. For example, the number of steps is between one and eight separate steps.
33
Appendix III
Interview report
Date May 18th, 2020
Time 16:00 – 16:30
Interviewee Compliance and Security Manager
Subject Feedback on the artefact
Purpose of the meeting
The goal of this interview is to receive feedback on the first example of the artefact and create some new ideas for the development of the artefact. The information, which is used in the design process, needs some validation by the firm. This way the correctness of the artefact can be validated, and it give the opportunity to make some changes to the artefact. Any feedback from the session will be used for the artefact and results in the iteration of the presented artefact at the time of this meeting. During the interview to idea is to find out the following points:
• Validity within the organisation, • Usability of the artefact,
• Completeness of the steps in the artefact.
Questions
The short meeting is used to get some first feedback from the organisation about the artefact. This feedback is used in the loop to make changes towards the designed artefact. The meeting is in the form of an unstructured interview, where some of the questions are added for the clarity. To meet the targets set in advance of the interviews, some of the questions are added below.
• Does the designed artefact have elements which are not viable within the organisation? • Can the artefact be understood without more information from the researcher?
34
Outcome of the meeting
The first presented model showed logical steps for the interviewee and it gave a nice starting point for the development of the second version. Some points of attention were raised in the meeting and are used in the artefact design chapter of this paper. The major problem with the first model was the lack of optimisation of the IT control. This was not clear of the early model, so a new step is included to accommodate to the need of process optimisation. During the meeting, the importance of process optimisation was explained, as a process which runs inefficient will not have a robot that provides the benefits as it should. Another important aspect during the meeting was the change in the control frequency. Where some of the controls used run monthly, a robot changes the design of the process and the frequency towards a daily schedule. The given example was normally the monthly controls needed 40 FTE, but this was reduced to 30 minutes daily by a software robot.
Besides the selection of the robots, a new challenge faced by the organisation is the re-usability of the robots. Where pilot now runs in one department based within the subsidiary, the company has the notion to further implement the robots across several parts of the firm. So, in the selection process, followed by the design of the robot, it becomes important to select and create a robot which has the potential to run in other parts of the organisation as well. This is an important point of attention and means that the model might need a more generic approach, so it can follow the slight differences between the subsidiary and headquarters for example. To help with this process, the new robots start to work with cluster of information. These clusters give the robot the opportunity to collect the data faster and better, without the need to access all the different systems. As part of the optimisation of the control, the clusters speed up the process and give a more efficient procedure.
35
Appendix III
Interview report
Date June 8th, 2020
Time 17:00 – 18:00
Interviewee Global Innovation Specialist (Finance Shared Services)
Subject Validation of the artefact
Purpose of the meeting
The goal of this interview is to externally validate the model by another organisation. The artefact was checked within the case organisation, but to provide some information about the generalisability it helps to external validate the model. For the validation, a different kind of firm is used. This firm is a leading diary multinational and they use RPA. The questions used in the meeting are listed below. There is a distinction between questions about the organisation and about the model. The questions about the organisation are used to detect similarities and differences compared to the case organisation. For the questions about the model, the goal is to validate the usability of the model within the interviewed company. This helps in generalising the model, as this would mean the model has the potential to used for different organisations. Before the questions are asked about the model, the model is explained. The information discovered from the meeting, is used to evaluate the model and this is added in the conclusion of the paper.
Questions
The questions were not presented to the interviewee before the meeting. During the interview, the questions about the organisation were asked first. After that part of the interview, the selection model was explained, followed by the questions regarding the model. The interview was conducted in Dutch, but the questions in this paper are translated to English for clarity.
Questions regarding organisation
• How is the organisation working with RPA right now? • Which processes are automated through RPA?
• How are these processes selected?
36
Questions regarding artefact (selection model)
• What is the first impression of the model?
• How is this model, with minor adjustments, applicable to the organisation? • Which modification are required to make the model functional?
• What elements are you missing in this model?
• Which steps in the model are essential with regards to RPA?
Outcome of the meeting
The interviewee is working with RPA on two sides within the company. He is creating the robots and assisting in optimisation of processes. This makes the interviewee someone with hands-on experience and he knows how RPA fits within an organisation. This company uses RPA for their administration processes, like for example invoices and inventory management. To find processes which are potentially automated with RPA a step by step approach is used. First there is the intake at which the process is examined and checked with some criteria. The process must be manual, high volume of data and rules based. After some consideration, this idea is sent towards an acceptance board. This board looks at the selection and start to work on creating acceptance within the organisation. The process owner must see the importance of the automation and people need to learn to work with the robot. From experience they noticed that without creating acceptance, the robot was not used after some time. The interviewee is the only person who can make changes to the robot when this is necessary. By doing so, the organisation prevents the large creation of unfunctional robots. Before the robot is build, the process gets some optimisation. As an example, he gave the variation within the process. When the process flow contains a lot of variation, the process is not working optimal and needs optimisation first. Once the robot is created and functional, the process owner can activate it and the interviewee makes small adjustments when necessary. He noticed that people got more time to think, now the robot was doing time consuming work. They started to think about the processes and try to come up with suggestions themselves for new robots on other processes.
37 became clear that some of the steps in the model are not related to the kind of process. The first step of selecting processes with human interaction and a rules-based set-up of the process and the optimisation of processes was important without considering the kind of process. The choice between check and monitor was not relevant for the organisation, because this step is specific for IT controls. Next was some comment about the frequency. Besides the frequency of the task, the volume should be relevant as well. This was not part of the model and could be important. When a control is checked only once a year but requires a lot of data, it could be helpful to automate several steps in this process with RPA. He acknowledged the fact that a yearly run of a robot would not work in practice. Some time is required to make modifications to the robot, due to updates in the underlying software. The number of steps was not relevant for the interviewed organisation either, because the organisation uses the time spend on a process as a major factor. They take the cut-off point at 650 hours on a yearly basis. When a process takes that much time, RPA could be a nice tool to use for automation. This number was not scientifically based, and more on experience. A robot might be a lot cheaper than an human, however licences and server capacity are still required for a robot to function. Therefore, the selection between the process is made. After some explanation that the case organisation in this paper does not record the time spend on a control, the interviewee agreed with using number of steps to account for the factor of time. The step of accepted deviations might be more applicable to controls than other business processes. When a process in the organisation has a lot of variation, the process needs some optimisation first. To much variation and the robot cannot work with the information.
