How can IT user controls be replaced by RPA within an organization?

(1)

How can IT user controls be replaced by RPA within an

organization?

A Design Science-Based Study

University of Groningen Faculty of Economics and Business

June 22, 2020

Thesis MSc. Accountancy & Controlling

General Information

Student name: Sandra Top

Student number: S2713683

Address: Amstelbestpad 6b, 1096GC Amsterdam

Phone number: 0637386379

Email: s.j.top.2@student.rug.nl

Supervisor: J.A. Emanuels, F.J. Bos

(2)

2

How can IT user controls be replaced by RPA within an

organization?

ABSTRACT

In recent years, automation has become more and more important within practice. Here, robotic process automation (RPA) offers great potential, saving costs and time while improving the accuracy within the activities it replaces. Internal control may benefit greatly from RPA, automating a variety of controls. I have tested how IT user controls, which is part of internal control, can be replaced by RPA within an organization. As RPA is a new technology, theoretical evidence on the implementation of RPA is lagging. However, RPA has successfully been applied within practice. By taking a design-science based research approach in conducting my research, I have contributed to the balance between theory and practice, conducting a case study to validate the designed artefact. I have performed a case study at an organization active in the sectors of Feed, Food, and Fuel Ingredients. By performing this case study, I have been able to bring theoretical evidence on RPA and IT user controls into practice.

While testing my artefact, I have assessed both the technical usability of the artefact, as its practical usability. Following the Technology Acceptance Model (TAM), I have reflected on the user acceptance of the artefact by testing its practical usability. The technical usability on the other hand reflects whether IT user controls can in essence be replaced by RPA, taking human preferences out of the equation. Results show that there is great potential for RPA to replace IT user controls, provided the following: data used in the control needs to be standardized, no human judgment is needed in the process, and the artefact needs to generalizable. In addition, while the software bot can carry out a process, the final responsibility and accountability lies with the one previously responsible for the IT user control.

Keywords: Internal Control, IT User Control, Robotic Process Automation, RPA, Design

(3)

3

Ⅰ Introduction

‘Automation will become central to business strategy and operations’ (Forbes, 2018). Following the automation of processes, it has been expected in 2018 that both jobs will be lost, as new jobs will be created. Organizations will invest in structures and frameworks in order for automation to work, and one in ten startups will work with more digital workers than human ones in the future (Forbes, 2018). A core aspect in this flow towards smarter automation is the evolution of robotic process automation (RPA). An article of Forbes in 2020 explicitly states that ‘RPA offers impressive cost and efficiency savings as well as accuracy improvements, and while it doesn’t necessarily reduce a company’s headcount, it can free up employees to do more creative, interesting work that enhances company value’. The potential of the robotic process automation in business is evident. However, the growing use of robotic process automation calls for an understanding of the technology’s risk and opportunities by internal audit leaders (Gardner, 2019). The advent of RPA has the potential to disrupt the traditional audit model (Moffitt et al., 2018), but in what way can RPA reach this potential, and can RPA be used in the real world?

RPA is defined by the Institute of Electrical and Electronics Engineers as ‘A preconﬁgured software instance that uses business rules and predeﬁned activity choreography to complete the autonomous execution of a combination of processes, activities, transactions, and tasks in one or more unrelated software systems to deliver a result or service with human exception management’ (IEEE Corporate Advisory Group, 2017). RPA is a specific type of software, mimicking how a human being would carry out a repetitive task within a process, thereby carrying out this task more quickly and accurate than humans (Lhuer, 2016). The purpose of a RPA tool is to reduce the burden of the huge amount of repetitive, simple tasks on employees’ (Lacity & Willcocks, 2016; Aguirre & Rodriguez, 2017), freeing humans to execute more complex tasks (PwC, 2017c).

‘Central to RPA implementation are internal controls, or the ability to implement mechanisms that ensure reliable reporting, compliance with relevant regulations, and risk mitigation and governance’ (Kokina & Blanchette, 2019). Internal controls are seen as ‘the processes and procedures implemented within a business organization to provide reasonable assurance that control objectives are met’ (Romney & Steinbart, 2018). Internal control may benefit greatly from the use of RPA, by automating a variety of controls. For example, access related controls, segregation of duties, and exception reporting are suitable for automation by RPA (Devarajan, 2018). However, when implementing RPA within an organization, one must also take into account the internal controls and specific governance mechanisms concerning RPA, which is still often insufficient (PwC, 2017d).

Therefore, RPA must be understandable through the lens of internal controls.

Romney and Steinbart (2018) make the segregation between general controls and application controls, when categorizing internal controls. ‘General controls make sure that an organization’s control environment is stable and well managed’, where ‘application controls

(5)

5 prevent, detect, and correct transaction errors and fraud in application programs’ (Romney & Steinbart, 2018). However, in Dutch academic and professional literature, the division is made between general controls, application controls and user or IT user controls (in Dutch, gebruikerscontroles). User controls are defined as controls which are manually controlled by users of the automated data processing, whether supported by output of the system itself or not (Verkuijlen et al., 2007; van den Hoff, 2016). With IT user controls, the reliability of the output is established, subsequent to using this output of the system. In this study, I will focus on the IT user controls.

So far, the potential of RPA is clearly stated in both scientific literature as in renowned articles. However, RPA is a new sort of software, where the scientific (theoretical) evidence of RPA is not evolving as fast as the change in the technology (artefacts) (Baskerville, 2018). Technological evolution generally precedes and drives scientific evolutions (Mokyr, 2002), as the evolution of science is slow (Kuhn, 1996), where the evolution of technology can be rapid (Arthur, 2009; Ridley, 2015). Therefore, a balance between the science (theory), and technology (artefacts) needs to be found, providing a generalization and deeper understanding of these technological improvements, by design studies (Baskerville, 2018). This study contributes to finding this balance, by making use of the design science-based research.

Design science-based research, the scientific study and creation of artefacts (Johannesson & Perjons, 2014) is an innovative, practical, and scientific research method, which has the potential to bridge the gap between the scientific and technological evolution. Results flowing from design science-based research should be original and well founded, relating to both the design science activities and adding value to an existing knowledge base (Johannesson & Perjons, 2014). The design science-based research has its roots in engineering and the sciences of the artificial, focusing on ‘how things ought to be in order to attain goals, and to function’ (Simon, 1996). The objective of the design is to change an existing situations into a preferred one (Simon, 1996). To be able to reach the preferred situation, an artefact is created and the change in the situation by use of the artefact is evaluated (Hevner et al., 2004). The artefact created is ‘an object, made by humans, with the intention that it is used to address a practical problem’. The visualization of the artefact can be quite diverse. The artefact can be a model, construct, method, or an instantiation (March & Smith, 1995; Hevner et al, 2004; Johannesson & Perjons, 2014). The creation of the so-called artefact will be as it is developed and used by people with as goal the solving of practical problems of general interest (Johannesson & Perjons, 2014). The artefact designed in the study, will be explained in detail in the methodology in section Ⅲ, designed in section Ⅳ, and demonstrated in section Ⅴ.

The focus of the contribution in the study is on the reliability and implementability of the artefact within a specific organization, where the creation of the artefact solves an important problem, adding value to the business environment (Hevner et al., 2004). The selection, implementation and evaluation of the artefact within the organization of choice, is at the center of the research, as the knowledge deriving from the artefact is expected to lead to both technological as scientific contributions.

(6)

6 As RPA is a new sort of software, it is critical to acknowledge the degree of user acceptance of this software. User acceptance is a critical factor for any successful implementation, as the users of the new software need to be inclined to use the software in their work (Nikou & Economides, 2017). ‘Research on the adoption of innovations also suggest a prominent role for perceived ease of use’ (Davis, 1989). Whether or not a new sort of software will be accepted, relies on the usability of the technology, as applied in the Technology Acceptance Model (TAM) by Davis (1989). The Technology Acceptance Model will be used to assess the practical usability of the artefact created in the methodology, and will be explained further in section Ⅱ, the theoretical background.

As stated above, the potential of RPA is known in the literature. However, the actual usability of RPA for the benefit of internal controls within an organization is not clear. The organization selected for the research will be introduced in section Ⅲ, the methodology, where the choice for the organization is clarified. As internal controls itself are too broad a concept to investigate, the focus will be on IT user controls and the replaceability of IT user controls by RPA specifically, within an organization.

Therefore, the research question guiding the research is:

‘How can IT user controls be replaced by RPA within an organization?’

By limiting the scope to IT user controls instead of internal controls, this study focusses specifically on what replacing IT user controls by RPA entails for a specific organization. By questioning both technically as practically, which actions within IT user controls can be replaced by RPA, this study contributes to the empirical research. These contributions will extend the knowledge on the design-science based research, the implementability of RPA, and the knowledge of IT user controls.

The division of the study is as follows. The next section provides a theoretical background. In section III, the research methodology, the introduction of the case of interest, the problem and requirements of the artefact, and the artefact itself is given. In section Ⅳ, the design and development of the artefact are explained . In section Ⅴ, the results are given, following a demonstration of the artefact. The study concludes with an evaluation of the artefact in section Ⅵ, discussing the results and providing a conclusion of the study.

(7)

7

Ⅱ Theoretical background

The central object within this study is IT user controls. Therefore, I start by giving a theoretical background of IT user controls, which is a category within internal controls. To be able to get an understanding of IT user controls, it is essential to realize what IT user controls are part of.

COSO (1992) defines internal control as:

‘A process, effected by an entity’s board of directors, management and other personnel, designed to provide reasonable assurance regarding the achievement of objectives in the following categories:

 Effectiveness and efficiency of operations  Reliability of financial reporting

 Compliance with applicable laws and regulations’

Internal control is sufficient if reasonable assurance is present that the organization’s objectives and goals will be met in an efficient and effective way (Fadzil et al., 2005; KPMG, 2016). When developing an internal control system within an organization, it is essential to gain a ‘thorough understanding on information technology its capabilities and risks’ (Romney & Steinbart, 2018). In addition, an understanding is needed on how to use information technology, such as robotic process automation, to achieve an organization’s control objectives. In this study, the division is made between general controls, application controls and user/ IT user controls, when categorizing internal controls. Here, IT user controls are used especially for the assessment of replacement by RPA.

IT User Controls

IT user controls are set in place, especially to monitor the accuracy, completeness and validity of the output of a system, such as reconciling data from different programs or systems (Verkuijlen et al., 2007). IT user controls control for the output of the system specifically. Due to fallibility of people and possible wrong intentions, IT user controls are considered to be less reliable and should therefore be monitored more strictly internally (van den Hoff, 2016). When IT user controls can be automated, by for example robotic process automation, there is potential to increase the reliability of IT user controls.

When robotic process automation is implemented to replace IT user control, there is a call for internal controls to assess whether the software bot performs as intended. It is essential that the software bot maintains the ‘completeness, accuracy, and integrity of data’, throughout its lifecycle (KPMG, 2018). When software bots are used to replace aspects of internal control, the replacement needs to be performed in the right manner. Therefore, it is of great importance to clarify what RPA is at its core, and how an organization can implement RPA in their organization, to be able to replace IT user controls.

(8)

8

Robotic Process Automation (RPA)

Robotic Process Automation is a technique, enabling automating the way people interact to carry out routine business processes, using multiple systems and by following simple rules to make decisions (Deloitte, 2017). It uses new software tools to transform a handmade process into an automated process (Rozario & Vasarhelyi, 2018). An essential part of the RPA tool is the RPA tool language, which the software bot needs to understand and is able to follow (Gartner, 2019). The software bot interacts with different systems, such as processing option systems. The bot can collect and update data from these systems, by ‘imitating manual screen-based manipulations’ (Mendling et al., 2018). The RPA bot is seen as ‘a digital worker, using

its own computer station, username, and password, which is similar to an human employee’

(Kokina & Blanchette, 2019).

The implementation of RPA comes both with possible added value and potential drawbacks, which are the following:

RPA is only applicable for well-defined processes, with mature tasks which are repeated in high volume (Moffit et al., 2018). It is required that the data is compatible with RPA software (Huang & Vasarhelyi, 2019). Within these tasks the outcome needs to be predictable, which results in less risks. Contrariwise, RPA should not be applied for complex and subjective tasks, which require human judgment and/or have uncertain outcomes. As RPA enables to carry out a task more quickly and accurate than a human being (Lhuer, 2016), efficiency increases, and costs are reduced, while maintaining a higher quality of the output (Deloitte, 2018a). The higher level of accuracy when using a software robot results from the standard manner in performance of the tasks carried out by the robot, free of bias of variation (PwC, 2017c). When RPA is used instead of a human worker, the potential of human error is reduced (Deloitte, 2018b). The digital worker will work rational, taking emotions and subjectivity out of the equation, where a human worker cannot always do so.

In addition to the value that RPA may add, a new technology such as RPA may bring its own risks. An intrinsic risk of implementing RPA, is the possibility of its failure. Statistics prove that 30 to 50% of projects of RPA do fail (EY, 2017; Hindle et al., 2018). Even though the implementation of RPA is relatively easy, appropriate controls for the implementation of RPA may not be in place and/or are not monitored. Next, it takes time to implement RPA in the right way (PwC, 2017a,2017b,2017c). The internal control over financial reporting, such as the controls over IT, may change following the implementation of RPA. Failing to consider the effects of these changes may result in internal control activities that do not suffice no more in the new situation (Deloitte, 2018b).

Moving Towards the Implementation of RPA Within an Organization

Essential to the implementation of RPA and the transition caused by RPA, is to have a plan of action (Lacity et al., 2015; Seasongood, 2016; Moffitt, 2018). Before selecting a process, suitable for the automation of RPA, entire end-to-end processes which may be candidate for RPA need to be mapped out. Processes which are suitable for RPA all have the following characteristics: the automation of the process is logical, the process is mature, data concerning

(9)

9 the process is available, and automation of the process will add value to the business. Then, the process best suitable for automation can be selected (Seasongood, 2016). Gaining an understanding of the process is essential, visualizing the process step by step. (Rozario & Vasarhelyi, 2019).

Any process consists of data, which are facts that are collected, recorded, stored, and processed by a system (Romney & Steinbart, 2018). However, the data collected can come from different sources and labels, even though the label connected to the data represents the same object (Moffitt, 2018). One program, report, or file may refer to an object as costs, while another report refers to the same object as expenses, creating an inconsistency in the data labelling (Moffitt, 2018). Therefore, the data needs to be standardized, which is Audit Data Standardization. The standardization of the data is a condition for RPA software, as RPA software may not be able to understand that the meaning of costs and expenses is the same (Huang & Vasarhelyi, 2019). After standardizing the data, the implementation stage of RPA begins (Huang & Vasarhelyi, 2019). A prototype is made, testing whether the artefact functions as envisioned (Moffitt et al., 2018). Then the prototype is tested.

Based on the stage of prototyping and experimenting, the process will be evaluated, and feedback can be given. The process before implementation of RPA will be compared with the process including the implementation of RPA, to be able to assess the effectiveness of implementation. Depending on this effectiveness, the artefact may be adjusted, ‘until the RPA software performs the procedure as expected’ (Huang & Vasarhelyi, 2019).

When researching a new sort of technique as RPA, it is of importance that the research method fits the subject under research. RPA is by definition practical, as it is a technique applicable for processes within an organization. This brings opportunities for new research visions, such as design science research. Next, when implementing a new sort of technique, one needs to take into mind what drives someone to either accept or decline the new technique. The following section of the theoretical framework dives into the research in design science and the acceptance of new technologies by its users.

Theoretical Insights in Applying new technologies Research in Design Science

Design science research brings both the practical relevance and the scientific precision towards information systems research (Baskerville et al., 2018. Design science research (or DSR) seeks to broaden the horizon of human and organizational capabilities, by providing models and guidelines for researchers, enabling the creation, improvement and evaluation of innovative artefacts (Hevner et al., 2004; Beck et al., 2013). The artefact is the core of the research (Baskerville, 2018). The artefact is seen as a model, method, construct, or instantiation, which is created for a practical purpose by humans (March & Smith, 1995; Goldkuhl, 2002; Baskerville, 2018). Wang and Hannafin (2005) emphasize the systematic and flexible nature of the methodology of design science-based research: the methodology is continuously analyzed, adjusted, and improved, based on the collaboration of researchers and practitioners in real-world settings. This leads to design principles and theories which depend on the specific

(10)

10 context, seeking a solution to a real-world problem (Kuechler and Vaishnavi, 2008). As DSR includes ‘the creation of an innovative construct that has not existed before and can be used to serve human purposes’ (Beck et al., 2013), it can be said that DSR is both innovative on scientific contributions as practicality.

The design science research methodology, as stated in Johannesson and Perjons (2014) and Peffers et al. (2018), consists out of a series of activities which are also followed in this study: first, a problem will be selected, and motivation will be given concerning this choice. Then the problem will be defined and requirements or objectives concerning a solution for this problem will be given. Thirdly, an artefact will be designed and developed. The center of the fourth activity is the demonstration of the artefact. Finally, the artefact will be evaluated, and its results will be communicated. In section Ⅲ, the series of activities of the design science methodology are described and explained in detail, as applied in this study.

Acceptance of New Technologies by its Users

When implementing a technique as RPA, its user acceptance plays a big role. Whether or not the user accepts RPA, depends on different factors which have to be considered when testing and validating the implementation of RPA within an organization. Nikou and Economides (2017) state that user acceptance is a critical factor for the successful implementation of any information system. The rate in which a specific system develops depends predominantly on the ‘struggle between rapid technological change and natural barriers to a new product or service acceptance’ (Lai, 2016; Lai, 2017).

The Technology Acceptance Model (hereafter TAM), which finds its origin with Davis et al. (1989), attempts to explain and predict why users sometimes accept and sometimes reject information systems (Bernadette, 1996). The TAM, based on the psychological interaction of a user with technology, also addresses how users then use the information technology (Nikou and Economides, 2017). Within the TAM, the distinction is made between the perceived usefulness (PU) and the perceived ease of use (PEOU) (Davis et al., 1989; Lai, 2017; Nikou & Economides, 2017).

Davis et al. (1989) defines the perceived usefulness as ‘the degree to which a person believes that using a particular system will enhance his or her job performance’. The perceived ease of use is defined as ‘the degree to which a person believes that using a particular system is free of effort’. People are inclined to use an application when they believe it will help them perform their job better and with more ease. Thus, performance benefits from using the application, need to outweigh its effort (Davis, 1989). The aim of the TAM is to assist researchers and practitioners in their research as to why a particular technology or system will be accepted or not by its users (Lai, 2016).

Based on the TAM, I make the assumption that when the benefits do not outweigh the effort one has to put in this new application, the application will not be accepted by the user. Therefore, I include the user acceptance in my research, making the research twofold.

(11)

11

Ⅲ Methodology

Research Methodology

The design science research methodology is followed in the study. Design science has its roots in engineering and the sciences of the artificial, focusing on how things ought to be, in order to reach goals and being able to function (Simon, 1996). Following design science, an existing situation is changed in order to get to a preferred situation. In this study, the steps that are stated in Johannesson and Perjons (2014), are followed, which are:

1. Explicate problem

2. Define Requirements

3. Design and develop artefact

4. Demonstrate Artefact

5. Evaluate artefact

Before the problem is identified, one needs to be in an environment where an internal control problem can arise. Therefore, I first need to select an organization where the design science research methodology can be applied. The selection of the organization is found below. The main reason for choosing a design science-based research methodology is that DSR is concrete and uses some form of utility as primary research goal (Gill et al., 2013). It includes creating an ‘innovative construct that has not existed before and can be used to serve human purposes’ (Beck et al., 2013). Therefore, it is said that DSR is very practical and looking towards the present and future instead of the past.

To be able to apply the design science research methodology, one needs to keep an open mind. As the methodology is by definition practical, I depend within my research on others. An organization needs to be willing to participate in the study, where I depend on the people with whom I communicate.

Introduction Case Study – Darling Ingredients Inc.

Darling Ingredients (for short, DI) is a company with an interest in the global growth platform for the development and production of sustainable natural ingredients from edible and inedible bio-nutrients (Darling Ingredients, 2019). DI has a variety of processing operations in over 200 locations, having a presence in 5 out of 6 continents. DI is active in the pharmaceutical, food, pet food, fuel, bio-energy, fertilizer, and foodservice industries. Darling’s business operates in three reportable operating segments, which can be defined as: ‘Feed Ingredients, Food Ingredients, and Fuel Ingredients’ (Darling Ingredients, 2019).

As DI is active in multiple industries and multiple continents, it must comply with all applicable health, safety, and environmental laws and regulations. The Headquarters of DI are in Irving, Texas. Therefore, DI must comply with SOX regulations as well.

DI has multiple production facilities within the Netherlands, the location in Son, located in Noord-Brabant being by far the largest. At the location in Son, both the production as all administrative activities are done, amongst other the compliance and security of the company its internal control.

(12)

12 The decision to choose DI for the study is because of the ability to do a case study at DI, the availability of resources, the opportunity to apply RPA at internal controls of the company, and the easiness of communication.

Applying the Design Science Research Methodology

In the study, the steps are used in the following way.

First, an organization of interest is selected and explored regarding their internal controls and applicability of RPA within their organization. Here, Darling Ingredients, fits the picture perfectly. Then, a specific internal control problem or challenge within DI is defined, by means of in-depth semi-structured interviews with employees in Internal Audit/Security & Compliance functions. The focus is on internal control procedures that can be supported or even replaced by RPA.

After the internal control problem is specified, the demands and constraints regarding a solution for the problem are determined. The basis for these demands and constraints comes from internal control literature, prior knowledge on RPA applications, and from knowledge obtained from reliable third parties who have substantive knowledge on the subject.

Then, a solution, in academic research known as an artefact, is designed and developed. This artefact is seen as a general design methodology or framework for this type of controls. In that way, the framework can be used for likewise controls. Subsequently the artefact, and its contribution, is tested. This testing phase, also known as the validation of the artefact, will be done both internally at DI, as externally. For the external validation, an organization which has to comply with SOX as well, is selected. This organization is active in private equity, which is another sector than DI. However, the organization has to comply with SOX, and has IT User controls which may be suitable for automation by RPA.

Because of the external validation, the generalizability of the artefact can be assessed. Post-validation of the artefact, the artefact and its contributions are evaluated.

The creation of the artefact has, considering RPA, the following requirements:

The process for which the artefact is created, must have a repetitive nature. This means that the implementation of RPA replaces tasks that humans would have carried out frequently. Next to this, the implementation of RPA has got to be involved with electronic processing of data, where multiple programs or systems within the organization must be used.

Problem and its Requirements

The focus of the research is on designing a method to be able to replace IT user controls by RPA, especially how one can use RPA within a process to replace manual activities. DI has provided a Risk Control Matrix, where the different IT General/IT application controls are stated. Whether a specific IT user control is suitable for the replacement by RPA is another research topic of great interest. Due to the scope and time frame of this research, a focused approach is however necessary. Therefore, I have decided to only investigate designing a method for the automation of IT user controls by RPA.

(13)

13 I have selected the change management of JD Edwards processing options as an IT user control that may (partly) be replaced by RPA, as the IT user control to be analyzed and be at the center of the design of the artefact. This IT user control meets the requirements as stated above. The IT user controls has a repetitive nature, is involved with electronic processing of data, and multiple programs or systems are used to do so. The IT user control replaces or supplements application controls by changing settings within an application, and matches data from multiple source files. The user of this IT user control deals with red flags that emerge through the system, acting on the situation.

IT user controls are analyzed to enable to explain and show how IT user controls can be replaced by RPA. This is done by taking a specific IT General/IT Application Control and then looking at the IT user control dealing with this control.

The control ID of the specific control used to validate the design method is ITCM.02A.03. This control ID stands for the change management of JDE processing options. The application used for this control is JD Edwards.

The control description of the specific control states that IT management generates a listing of all JD Edwards SOX 1(application control related) processing option settings on a monthly basis. This list is reviewed to ensure that each change is appropriate and whether the values are still in line with the related application control. The frequency of the listing is and the control is manual with a detective nature. Additionally, the risk level of the control is stated as ‘high’ and the control has a key significance.

The motivation to select the IT user control concerning ITCM.02A.03 is twofold. The manual check AS-IS, is time consuming while little to no changes are expected. However, for SOX purposes, the check is mandatory. Next, when the check is done once a month, this check does not cover the risk of someone changing the configuration within the month and changing it back before the check is performed. Automating the process, would eliminate this risk.

The Artefact

The artefact arises in the last three steps of the design science-based methodology.

In phase three, the artefact is designed/ developed. In design science, four types of artefacts are identified, where I use a method as an artefact. Johannesson and Perjons (2014) define a method within design science as an expression of ‘prescriptive knowledge by defining guidelines and processes for how to solve problems and achieve goals’. There is no one best way how to design

1_{The Sarbanes-Oxley Act (SOX) ‘requires top management to establish, maintain, and regularly evaluate the}

effectiveness of internal control over financial reporting’ (Ge & McVay, 2005). The SOX (2002) has four principal areas, which are ‘corporate responsibility, increased criminal punishment, accounting regulation, and new protections. The primary goal, and the core of SOX is to ‘improve audit quality and reduce fraud on a cost-effective basis’, strengthening the position of the auditor against fraud and theft at public companies (Coates, 2007). Section 404 of the Sarbanes-Oxley Act (SOX) emphasizes the importance of internal control, requiring external auditors to express their opinion on the effectiveness of client’s internal controls over financial reporting (Ashbaugh-Skaife et al., 2008; Defond et al., 2016; Cheng et al., 2019).

Concerning internal control within an organization, the Sarbanes-Oxley sets strict(er) requirements to which an organization has to comply, which means that for the organization used in the research, these strict(er)

(14)

14 a method. This involves the creativity of the person who designs the method and for what specific problem it is used. I use this creative freedom in the design of the artefact.

Specifically, a method is created, describing how RPA can be used to replace IT user controls within a process. This is seen as a guide or a manual that can be further validated and improved in future research.

Then, a prototype manual is made, making use of the IT user control concerning ITCM.02A.03. I start with an AS-IS manual, demonstrating how the IT user control is used by its user in the current situation. Based on the AS-IS manual, the artefact itself is designed, which is manifested as the ‘Prototype TO-BE Manual’.

This manual is used in the implementation phase. There are two dimensions which are assessed, making the implementation phase twofold. Both the technical dimension and the practical dimension of the artefact are tested. The technical dimension focusses on whether the design of the artefact does not have any flaws. The practical dimension, also known as the user validation, is analyzed, by submitting the manual to other employees at Darling Ingredients who have an understanding of RPA and IT user controls.

In this way, I can assess whether these employees who have not participated in the process of designing the manual, can understand the manual.

(15)

15

Ⅳ Artefact Design and Development

Setting up the Interviews

Getting into contact with the right people at DI is essential for the test phase of the artefact, assessing both the accuracy of the manual as its manageability.

The right people need to have an understanding of the IT user controls, used for the demonstration of the artefact. In consultation with the IT Compliance and Security Manager (direct contact within DI), I have decided to conduct semi-structured interviews with four employees whom are working in different departments and have different functions within the company.

Interviewees Function

1 IT Compliance/Security Manager (direct contact at DI) 2 IT Compliance/Security Officer

3 Senior IT Internal Auditor 4 Application Specialist

The Application Specialist has the most detailed and technical view on the artefact, where the Senior IT Internal Auditor looks at the artefact from an auditor’s perspective. The IT Compliance/Security Manager and Officer will look at the artefact from the perspective of the user of the artefact. I have decided to select these interviewees, as their different perspectives on the artefact, broadens the view on the technical and practical usability of the artefact in the demonstration section.

By interviewing the interviewees, I have tested both the technical accuracy of the manual, as verifying the manageability of the manual.

I have spoken multiple times with some of the employees, where the following moments and subjects were key moments in the development and validation of the artefact.

Interview Date Duration Type of

Interview

Subject Function

1 31-3-2020 One hour Unstructured Selecting IT user control

IT Compliance/Security Manager

2 17-4-2020 45 minutes Semi-structured Steps IT user control

2 1-5-2020 45 minutes Semi-structured Steps IT user control

IT Compliance/Security Officer 3 11-5-2020 One hour Semi-structured Validating

Artefact

IT Compliance/Security Officer 4 18-5-2020 One hour Semi-structured Validating

Artefact

5 19-5-2020 One hour Semi-structured Validating Artefact

Senior IT Internal Auditor 6 19-5-2020 One hour Semi-structured Validating

Artefact

Application Specialist

In validating the artefact, each interview was approximately one hour. I have set up the interviews in three sections: the (visualization of the) manual AS-IS, the technical usability of the (visualization of the) manual TO-BE, and the practical usability of the (visualization of the)

(16)

16 manual TO-BE. The interviews took place at a time when both I as the interviewees were obliged to work from home, as the timing of the interviews has been during the COVID-19 virus. As a result, in the time frame of March - June 2020, the offices of DI and the University of Groningen were in lockdown. Therefore, there was no possibility to conduct the interviews face-to-face. Instead I conducted the interviews via Microsoft Teams, where I was able to speak and see the interviewees and they vice-versa me. In this way, the non-verbal aspects of the interviews were not totally lost. However, with two out of the four interviews, I was not able to have visual contact with the interviewee. This could possibly result in a loss of information what could have been received through non-verbal contact. Starting with the (visualization of the) manual AS-IS, I have verified whether I have visualized the process in the right way. This first step is one that may never be disregarded, as getting an understanding of the starting point of a process, is essential to improve the process. Then, I assessed the technical accuracy of the (visualization of the) manual and TO-BE.

Then, I moved on to the practical usability of the manual. Even though the manual may be technically correct, this does not essentially mean that one will also use the manual in real life. Therefore I have assessed whether one would actually be inclined to use the manual. The set-up of the topics discussed during the semi-structured interviews can be found in Appendix A.

Situation AS-IS (Prototype before Validation)

Together with the IT Compliance and Security Manager and Officer, the different steps and options within the process of IT user controls concerning ITCM.02A.03. are walked through. A prototype of the visualization of these steps is found below (Figure 1). Based on this prototype, possible strengths and flaws in process are visualized. The first aspect of the process flow where clarity must be provided, is the starting point. In the AS-IS process, a listing is generated on a monthly basis, of all JD Edwards SOX processing option settings by IT management. The IT Compliance and Security officer of DI explicitly states:

‘The starting point is the extract of all JDE processing options settings for the respective applications which are considered critical for the financial statement process

(17)

17 Figure 1- Prototype Process Flow of the IT user control concerning ITCM.02A.03 AS-IS

Instead of merely sending an extract of the changes to the IT Compliance and Security Manager of DI, a setup of how the application functions is sent. This is the starting point of the process flow, and the first step in the following manual. Next, clarity is wanted on the steps in the process flow, where judgment is needed. When assessing the e-mail sent by IT management, the process flow can either be as expected and intended or can be not as

expected and intended (step 4a/b of Figure 2). It is of importance to assess why a process flow is or is not as expected and intended. The IT Compliance and Security Officer says:

(18)

18

‘We as a company have defined in our narratives a set of internal controls for SOX purposes which define how the applications should be set-up, so management is in control of the

transactions that flow through this process’

The narrative is effectively working when the processing option of the application enforces that all purchase orders have to be approved. The check is explicitly on whether the approval functionality is activated in the processing option extract. If the configuration is not correct, this means the following according to the IT Compliance and Security Officer of DI:

‘When a configuration is not correct, this means that orders do not have to be approved and orders can go through without another person reviewing what is being purchased. As a result,

there is higher risk of unauthorized purchases being processed by the system’

When a deviation is found, this needs to be assessed. A deviation in the process ITCM.02A.03 is defined by DI as: ‘implementations and changes that are introduced in the production environment that are not fully tested, accurate, complete, approved, or meeting the needs of IT and/or the business units, thereby jeopardizing system functionality and data integrity’. The next tradeoff in the process flow where I need to indicate clarification, is the reason why the narrative is not in line (step 7b of Figure 2). As seen in figure 2, either a genuine mistake can be made, or one can have requested a change. Considering the distinction why the narrative is not in line, the IT Compliance and Security Officer says the following:

‘A mistake is made when the processing options are updated incorrectly by accident. The narrative can also be not in line, when consultants change the processing options, not considering the impact this change has on the process, and not taking into account the

narrative itself’.

As seen in Figure 2, there are three aspects in need of additional clarification, which I give by making three annotations, which are found in Figure 3.

(19)

19 Figure 2- Prototype Manual AS-IS - IT User Controls concerning change management of JDE processing options

(20)

20

Situation TO-BE (Prototype before Validation)

The starting point of the situation TO-BE is to make a visualization of the preferred situation. I have visualized the preferred situation by making an improved process flow, which is found below (Figure 4). This preferred process flow, is used in the design how to automate IT user controls by RPA, making a TO-BE manual. This TO-BE manual is the artefact, describing the preferred situation.

In the manual, the different steps are clarified (Figure 5). When automating the IT user control concerning ITCM.02A.03, I make the assumption that the last step in the manual cannot be automated. The user of the IT user control, is responsible for the assessment, whether the configuration is correct. That specific employee can be held accountable for her/his decisions. Therefore, I find it irresponsible and unfeasible at this moment, to automate this explicit decision, as the decision requires human judgement.

Within the design of the artefact, I have made the following choices which need clarification. The process is of the IT user controls is not started by a listing, generated by IT management. The process starts, when the artefact is implemented at DI. From there on, the process will flow continuously, with a check when the critical application is not configured as intended. Here the following question arises: What happens when the critical application is configured as intended? If this is the case, I add an activity where an e-mail will be sent to the employee responsible for the IT user control. This will be done automatically, by the RPA bot, at the end of the month.

As seen in the manual in Figure 5, step 12 and 14 involve human activity. Human judgment is needed in step 12 and 14. I have given clarification about the human activity in Figure 6. The manual below, is tested in the demonstration stage of the artefact, both on its technical as practical usefulness.

(21)

21 Figure 4- Prototype Process Flow of the IT user control concerning ITCM.02A.03 TO-BE

(22)

22 Figure 5- Prototype Manual TO-BE- IT User Controls Concerning Change Management of JDE Processing Options

(23)

23 Figure 6- Notes following the Prototype Manual TO-BE

(24)

24

Ⅴ Demonstration of the Artefact

As stated in the methodology, the division is made between the (visualization of the) manual AS-IS, and the technical and practical usability of the (visualization of the) manual TO-BE. In the results, the distinction between these three aspect is made.

Manual and Visualization of the Manual AS-IS

All interviewees state that the process AS-IS, is manageable in the form of the manual. The IT Compliance and Security Officer states that the process works well for automation by a bot, as there is not much room in the process for failure. The aspect of judgment within the process, is determined upfront, by setting the narrative. All exceptions are stated in the PDF narrative. Therefore, it is clear from the start what can be specified as exception reporting and when something is out of the ordinary. At its core, the process compares the reality (processing option) with the norm (narrative), and conclusions are drawn from the comparison.

Concluding from the interview with the IT Compliance and Security officer and the Senior IT Internal Auditor, it is essential to state what the narrative is, and that the narrative is the norm. Next, it is of importance to specify that the manual and the visualization of the manual are about the internal controls and the functionality of the application.

Within the process, there can be an exception as stated in the PDF narrative. However, all the exceptions are not stated in the Excel narrative. The IT compliance and Security officer says the following about this:

‘You don’t count the exceptions within the Excel narrative. The macro Excel is set up in such a way, that when there is an exception, there is automatically a pass. When there is no exception, but something is out of the ordinary, we need to act on it and investigate what is

going on’

Considering the check of what went wrong in real time, compared to the narrative, the Senior IT Internal Auditor explicitly states the following:

‘At the moment that there is a genuine mistake, you need to correct the application. You do need to log a ticket then. Otherwise someone is changing something back to how it is supposed to be on the background, without logging it. You need to let this process run through the change management process. So, you only know there is a requested change at

the time there is a ticket’

The Application Specialist agrees with this distinction. He points out the ticket system, where a change request has the option ‘Normal, Standard, and Emergency’. He emphasizes the following:

‘When making a change to the object, we need a change request. There is no way for me to change something in the production without the requested change’

(25)

25 This distinction is essential in the manual and visualization of the manual AS-IS. As I had not added this step in the prototype stated in the methodology, I need to make an adjustment in the manual and visualization of the manual AS-IS.

Next to the technical accuracy of the manual AS-IS, the practical usability of the artefact needs to be assessed. When asking about the opinion of the AS-IS manual and the understandability of the manual, the IT Compliance and Security Officer of DI states that the manual is understandable. He can read it and understand the different steps within the manual without having to study the manual.

Also, the generalizability of the Manual AS-IS needs to be determined. The IT Compliance and Security Officer says the following about the generalizability of the manual:

‘The manual AS-IS is generalizable, as the steps within the different IT user controls are very much alike. One always tests whether the reality is in line with the norm. Therefore, the steps

within the control are the same for likewise controls’

The IT Compliance and Security Managers agrees on the front of generalizability. She also makes a contribution to the motivation of creating an automated process, as the process AS-IS, is time consuming. From the perspective of internal audit, the manual is understandable as well. The Senior IT Internal Auditor in under the impression that the AS-IS manual can now technically work at DI, as DI has to comply with SOX. Because of the SOX aspect, DI needs to follow manuals, process flows, narratives etcetera. When a manual states the steps one has to follow, internal audit is able to check on those steps followed by the management, as management needs to be in control following SOX.

The Application Specialist makes one last commenting note which should be taken into account. Within the manual, all options need to be specified. There has to be no need for judgment after following the manual. This results in a fine line between a detailed manual, and a generalizable manual. While the manual should explain all possibilities, these possibilities still need to be able to be applied within likewise controls.

Based on the input from the four interviewees, I have improved the manual and visualization of the manual AS-IS, which are found in figures 7 and 8. Here, I have added the steps from the manual, in the visualization of the manual as well.

(26)

26 Figure 7- Visualization of the Validated Manual AS-IS

(27)

27 Figure 8- Validated Manual AS-IS (Artefact)

Technical Usability of the Manual and Visualization of the Manual TO-BE

The first step within the prototype manual, is one that technically would not suffice. Continuous monitoring by the software bot is no possibility yet within Darling Ingredients, according to the IT Compliance and Security Officer, Manager, and the Senior IT Internal Auditor. As to why this is no possibility, the Senior IT Internal Auditor says the following:

‘The robot has to use an extract. This extract has to be downloaded to excel, to perform the check. The bot is configured to perform certain checks. These checks are written out in the

(28)

28

Excel set up file (Excel narrative). The bot then needs to continuously download the extract and compare this with the narrative. Therefore, the bot cannot monitor continuously’

Therefore, I adjust the starting point of my manual from continuous monitoring by the software bot, to frequent monitoring by the software bot. The exact frequency depends on the capacity of the system and its application. According to the Application Specialist and the IT Compliance and Security Manager, daily would be a possibility, as long as the extract is downloaded before the software bot runs the control. The extract has to be made on the same day as when the software bot runs the control.

The Application Specialist says the following about the download of the extract:

‘The download of the extract needs to be scheduled before the robot will do the check, otherwise the robot will check with outdated information’

Following the prototype of the Manual TO-BE, the Application Specialist has made some adjustments which are needed for the manual to technically work. First, the software bot needs to open the Excel narrative first. This is needed for the software bot to be able to state whether the process configuration is going as intended or not. Then the set up narrative needs to be checked. Whether the process configuration is going as intended or not, is stated in the output file of the Excel narrative. The improved Manual BE, a visualization of the Manual TO-BE, and the complementary notes to the manual TO-TO-BE, are found in figures 9, 10, and 11.

As to the e-mail which is send to the user of the IT user control, having to act on the suggestion made by the software bot, there are mixed signals between the interviewees. The IT Compliance and Security Officer says that making someone responsible for the final human check is not a necessity, as one can rely on the software bot:

‘Signing off at darling is more to show that someone looks at it. Therefore, when a robot would perform the check, this would work too’

Therefore, the person responsible for the IT User Control, can lean on the work of the software robot, assuming that the software bot is set up accurately.

However, when a robot is responsible for the IT User control and has the final say in the IT User Control, you cannot hold anyone responsible over the decision a software robot has made. This creates a possible issue within the Security and Compliance of the organization. Additionally, the Application Specialist states that giving the software bot the responsibility to both assess and act on why the narrative is not in line, is still a bridge too far. He indicates that there are millions of tickets within the ticket system used for creating a change within the process or narrative. At the time there is no standardized way of logging a ticket in the ticket system by an employee of DI. For the software bot to make more than a suggestion, the software bot has to memorize all the millions of possibilities within the ticket system to describe the reason why a ticket is logged. As the software bot can only read standardized texts, it is no possibility yet to act on all tickets logged in the ticket system.

(29)

29 The next step of interest, is the adjustment of the narrative. The Senior IT Internal Auditor detects the following risk:

‘When you adjust the narrative, the excel file of the narrative needs to be adjusted too. Thus, when you adjust the narrative, both the PDF as the Excel narrative needs to be adjusted. When one of the narratives is not adjusted, the narratives are no longer aligned, creating a

flaw in the process’

According to the IT Compliance and Security Manager, the Senior IT Internal Auditor, and the Application specialist, the manual can technically be used for likewise controls. They explicitly see it working for IT user controls which concern SOX within DI, as business controls that do not concern SOX, do not need a narrative.

The IT Compliance and Security Manager sees the possibility of sharing the manual with new employees within the team and Internal Audit, as the biggest advantage of using the manual. In this way, Internal Audit gains an understanding of how the process technically works, without having to verbally explain it.

(30)

30 Figure 9- Visualization of the Validated Manual TO-BE (Artefact)

(31)

31 Figure 10- Validated Manual TO BE (Artefact)

(32)

32 Figure 11- Complementary Notes Manual TO-BE

Practical Usability of the Manual and Visualization of the Manual TO-BE

The assessment of the user acceptance of the manual, is of great importance for this study. In order to draw conclusions as to whether users accept the manual, the practical usability of the manual is assessed. Likewise the technical perspective, continuous monitoring of the processing option is still a bridge too far for the practical usability. As an extract needs to be downloaded from JDE, every time the software bot runs the IT user control, the frequency of the download can never reach continuous monitoring. Every download takes between 3-5 minutes, where an extract of 19 applications needs to be downloaded, with a maximum of one download a day. Next, the software bot can only run outside of office hours, making that a higher frequency than daily is no possibility in the near future.

However, when the frequency from the IT user controls is upscaled from a check once a month, to an automated check once a day, this will increase the level of comfort considering the IT User control, tremendously. The Senior IT Internal Auditor states the following:

‘Even if you test once a day, you still lean for the rest of the day on change management. But when you test once a week or once a day, the comfort level will increase tremendously’

The IT Compliance and Security officer states that he intends to use the manual, because of the elimination of risk, coming from the human actions. However, this motivation can be limited, when the amount of costs to implement and keep the software bot running, is high.

(33)

33 Another aspect which increases the motivation to use the manual, is that using the manual will save a lot of time for the user of the manual. Two of the business objectives and benefits after automation of selected business processes are ‘time saving for JD Edwards Process Owners’ and ‘time saving of manual compliance reviews’. Therefore, it is said that saving time is a big motivation for users to accept the manual.

The IT Compliance and Security Manager also states that she is likely to use the manual:

‘Within Darling Ingredients, we tend to document everything anyway. When there is a manual and a visualization of the manual by for example a diagram, I will be likely to use it and let

my team use it too’

The biggest possible advantage and disadvantage of the usage of the manual, is the degree to which the manual is kept up to date. When manual is kept up to date, the IT Compliance and Security Manager is inclined to use it. However, when the manual is not up to date, the IT Compliance and Security Manager will most likely stop using the manual when the version is outdated. This is a condition that arises from the interview with the IT Compliance and Security Manager.

The Application Specialist sees the manual to be used for management and perhaps internal audit specifically.

On the aspect of job performance, there is no conclusive opinion among the interviewees. The IT Compliance and Security Officer expects that implementing a generalizable manual will not have a lot of added value. He believes that employees will likely get lazy.

‘Right now, the user of the IT user control needs to think about a lot of things within the process and needs to check a lot of boxes. When the narrative is not in line with the processing option, (s)he needs to make adjustments/correction in all necessary systems. When

the process gets automated, they do not have to do that anymore a they will be stopped by the software bot soon enough’

However, the Manager of IT Compliance and Security and the Senior IT Internal Auditor do not believe that the implementation of RPA will make employees lazy. They believe that a manual makes the job easier and more efficient. The Application Specialist also suspects an increased level of job performance, saying the following about the subject:

‘I would say that I would need less time to confirm or check things. The software bot will take over some manual time-consuming tasks, making my job easier as well’

According to the Senior IT Internal Auditor, the manual can be free of effort.

‘When the manual and the visualization of the manual are put on SharePoint (Intranet DI), where everyone can find the manual easily, the ease of effort is increased’

(34)

34 From the internal audit perspective, the design is certainly an improvement to the way the internal auditors performs her work right now. Implementing the manual will improve the quality and frequency of the IT user control. The Senior IT Internal Auditor says the following about the practical usability of the manual:

‘From an internal audit perspective, we are a company that has to comply with SOX. The management needs to be in control, not the internal auditor. When management shows that this is the manual they work with, then I will also work with this manual for all my activities. I

need from management to show that they are in control over the process’

Thus, management needs to be able to say for every process, how they are going to approach it. Next, management needs to assure that they are in control. Another condition that the Senior IT Internal Auditor and the Application Specialist state, is that the manual needs to be able to be applied in every situation. The manual needs to state all exceptions. Every situation needs to be described, and there needs to be a check as to whether the description of the situation is complete. When not all situations are described, management should be aware of it.

External Validation of the Artefact

In order to assess whether the artefact, can also be used in different circumstances, I have validated the artefact externally. By testing the artefact externally, the reliability of the artefact is improved, and suggestions can be made for future research.

In the selection of the organization usable for the external validation of the artefact, I have set a number of conditions. The artefact deals with the alignment of the real situation, compared to the situation as it is ought to be (the narrative). Therefore, I deem it necessary that the organization of choice has to comply with the SOX regulations. Next, the organization of choice has to have IT user controls, which are suitable for RPA. Third, I have made the decision that the organization used for the external validation of the artefact, may be active in another sector than that of DI.

Based on the conditions I have set before the selection of the organization, I have selected an organization that is active in the financial services industry, which has to comply with the SOX regulations. The organization is active in the private equity sector, dealing with investments on a global scale.

The process under external validation has to do with the purchase and disposal of investments. The first step within the process, is a listing of propositions and a selection of the procedures which are performed by the investment team. If the decision is made to continue carrying on with the investment, the investment team has to do its due diligence. Then a proposal considering the investment is sent to two other teams. Next, the documentation of the investment has to be done. Concluding, there will be an outflow of cash when the new investment is done.

Within the process, multiple systems are used, and the frequency of the process is of a sufficient level, making the process perfectly suitable for external validation of the artefact.

(35)

35 To validate the artefact externally, I use the process flow of the IT user control and the narrative of the IT user control of the private equity organization. I have assessed the artefact which I have created and spotted some points to which more attention has to be paid. I have assessed the artefact on its technical usability, following the questions in Appendix A. Following the assessment of the technical usability, I have come to the following suggestions:

The narrative which the organization uses, needs to be translated to an Excel set up of the narrative, to use the artefact. As the narrative is now, the software bot is not able to read the narrative.

The second step in which an adjustment has to be made, is step 7b of the artefact, questioning whether a ticket of a requested change is available. In every step of the narrative of the process, a form needs to be made up. The wording of ‘ticket’ within the artefact, will create an error when applying the artefact to this IT user Control.

The process under external validation, has multiple roles and responsibilities, making more than one person responsible for the entire process. For the process to quality for the artefact, the process needs to be cut up in parts, where just one person is responsible for the process.

Under external validation, the need for standardized data becomes even more visible. The narrative needs to be standardized for a software bot to read it, and the explicit wording within the artefact, narrative, and actual process flow needs to be aligned.

(36)

36

Ⅵ Discussion and Conclusion

Evaluation of the Artefact

The focus of the research has been on designing a method, how IT user controls can be replaced by RPA within a process. An organization has been selected to perform the case study at, which is Darling Ingredients. Darling Ingredients’ headquarter is based in the United States, where the requirements following the Sarbanes-Oxley act of 2002 apply. Therefore I have had to take into account the SOX requirements concerning internal control. A specific process has been selected to analyze the IT user control and to build the artefact. The motivation to select the IT user control for automation has been twofold, limiting risk and the saving of time.

Based on the theoretical background and the practice that follows, I can say that the artefact created in this study has great potential. How one will apply the manual is up to personal preferences, but the technical applicability does suffice within DI. By automating IT user controls which have to comply with SOX requirements, I have limited the risks within the process, and reduced time the user needs to execute the IT user control.

Following the validation of the artefact, the following adjustments and conditions arise. A risk within the process cannot be eliminated completely, as continuous monitoring by the software robot is no possibility yet at DI. DI works with a downloaded extract of the processing options, comparing this extract to the narrative. This extract needs to be downloaded, before the check is performed and on the same day as the check, to ensure that the bot works with the right data.

Next, an assumption has been made in the design of the artefact, that does not work in practice. The assumption of the correction or adjustment the software bot makes, is based on the logged tickets in the ticket system when requesting a change or correcting a mistake. The tickets in the system are however not logged in a standardized way, which is necessary for the software bot read the ticket (standardization of data). The software bot can make a suggestion of what to do at most.

Another aspect within the manual where a risk can arise, if when someone does not adjust both the PDF narrative and the Excel narrative, when adjusting the narrative. Both the narratives have to be adjusted in order to be aligned. While the Excel narrative is used by the bot, the PDF narrative states all the exceptions under exception reporting. Thus, the PDF narrative gives clarification on the exception in the Excel narrative.

Next, I have looked at the practical usability of the manual. Here, the biggest motivation to either use or not use the manual, is the degree to which the manual is kept up to date. An outdated manual loses its additional value, as the user cannot work with an outdated manual. Another condition that arises from the interviews, it the applicability of the manual in all possible situations. All exceptions need to be addressed, so as that no human judgment is needed while using the manual. If and when not all situations are described, the user of the IT user control should be aware of it, so that (s)he can act on it.

How can IT user controls be replaced by RPA within an organization?

How can IT user controls be replaced by RPA within an

organization?

A Design Science-Based Study

How can IT user controls be replaced by RPA within an

organization?

ABSTRACT

Table of Contents

Ⅰ Introduction

Ⅱ Theoretical background

Ⅲ Methodology

Ⅳ Artefact Design and Development

Ⅴ Demonstration of the Artefact

Ⅵ Discussion and Conclusion