EAM in ERP-1 - Additional Reference PDF

Preview

Summary

Additional Reference...

Description

JOURNAL OF INFORMATION SYSTEMS Vol. 19, No. 2 Fall 2005 pp. 7–27

Embedded Audit Modules in Enterprise Resource Planning Systems: Implementation and Functionality Roger S. Debreceny University of Hawai’i at Manoa Glen L. Gray California State University at Northridge Joeson Jun-Jin Ng Citigroup Private Bank, Singapore Kevin Siow-Ping Lee Ernst and Young, Singapore Woon-Foong Yau OCBC Bank, Singapore ABSTRACT: Embedded Audit Modules (EAMs) are a potentially efficient and effective compliance and substantive audit-testing tool. Early examples of EAMs were implemented in proprietary accounting information systems and production systems. Over the last decade, there has been widespread deployment of Enterprise Resource Planning (ERP) systems that provide common business process functionality across the enterprise. These application systems are based upon a common foundation provided by large-scale relational database-management systems. No published research addresses the potential for exploiting the perceived benefits of EAMs in an ERP environment. This exploratory paper seeks to partially close this gap in the research literature by assessing the level and nature of support for EAMs by ERP providers. We present five model EAM-use scenarios within a fraud-prevention and detection environment. We provided the scenarios to six representative ERP solution providers, whose products support ‘‘small,’’ ‘‘medium,’’ and ‘‘large’’ scale clients. The providers then assessed how they would implement the scenarios in their ERP solution. Concurrent in-depth interviews with representatives of the ERP providers address the issue of implementing EAMs in ERP solutions. The research revealed limited support for EAMs within the selected ERP systems. Interviews revealed that the limited support for EAMs was primarily a function of lack of demand from the user community. Vendors were consistent in their view that EAMs were technically feasible. These results have a number of implications for both practice and future research. These include a need to understand the barriers to client adoption of EAMs and to build a framework for integrating EAMs into firm risk-management environment.

7

8

Debreceny, Gray, Ng, Lee, and Yau Keywords: enterprise resource planning (ERP); accounting information systems; continuous audit; embedded audit modules.

I. INTRODUCTION mbedded Audit Modules (EAMs) are Computer Assisted Audit Tools and Techniques (CAATTs) that allow continuous monitoring of accounting information systems. EAMs are software applications embedded in host systems or linked to host systems to externally monitor such systems. EAMs are applications that continuously monitor flows of transactions, identify transactions that match certain pre-determined integrity constraints and, in the event of a constraint violation, alert the auditor and copy the transaction data to a file (Hall 2000, 271–273; Nagel and Gray 2000, 713). EAMs and other CAATTs are important pre-requisites to the adoption of continuous auditing (Alles et al. 2002; CICA/ AICPA 1998; Kogan et al. 1999; Rezaee et al. 2002; Vasarhelyi 2002). When the object of the continuous audit is capable of precise definition and clear and consistent measurement, EAMs can support the continuous audit process by appropriate monitoring of the accounting information system. The Sarbanes-Oxley Act Section 302 requirement that CEOs and CFOs certify the effectiveness of internal controls and the Section 404 requirement that management assess internal control over financial reporting have also added weight to the need for both management and external auditors to employ information technology, including EAMs and other CAATTs, to monitor internal controls (Ernst and Young 2002; PricewaterhouseCoopers 2002; Roth and Espersen 2003). There is, however, limited evidence of EAMs’ adoption, despite factors that would seemingly drive wide-spread adoption (Groomer and Murthy 1989; Hansen 1983; Jancura 1980). Vasarhelyi and Halper (1991) provided early evidence of feasibility of continuous system monitoring. The authors embedded EAMs in the high-volume transaction flows of a telecommunications enterprise. While Vasarhelyi and Halper (1991) demonstrated the feasibility of EAMs, they also articulated challenges to their development and implementation, including issues related to design and system resources because the EAMs require computer time to process, which, in turn, slows downs the transaction processes being monitored. While this overhead can be overcome by adding appropriate hardware and software resources, there are costs associated with these investments. An important development in corporate information systems over the last decade has been the widespread adoption of Enterprise Resource Planning (ERP) software (FEI 2001; PricewaterhouseCoopers 2003, 85). ERP applications manage end-to-end business processes, including sales and customer service, purchasing, inventory management and logistics, manufacturing, human resource management, and accounting. The unified data and process management of ERP systems have replaced traditional separate and disparate application systems managing core business processes. This process of consolidation and unification of accounting systems lowered a barrier to adoption of EAMs by providing a common data and technology foundation for monitoring business processes. Given the prevalence of ERP systems, it is surprising that there is no published research on the link between ERP systems and EAMs. In a review paper on the feasibility of continuous auditing, Alles et al. (2002, 135) note that ‘‘current versions of ERP systems neither include EAM nor provide any real continuous auditing capability.’’ This paper assesses the capability of ERP systems that are designed for medium to large enterprises to host EAMs for substantive testing or monitoring of control processes, and to assess the feasibility of implementing EAMs within the enterprise. The research follows a three-stage approach. First, we selected a set of representative ERP systems designed for enterprises of varying size. Second, we designed a set of test EAM alerts to

E

Journal of Information Systems, Fall 2005

Embedded Audit Modules in Enterprise Resource Planning Systems

9

support substantive testing, which were provided to each ERP provider for assessment and coding. Third, we conducted in-depth interviews with representatives of each ERP system provider to gain insights into key implementation issues in the adoption of EAMs within the context of the particular system. None of the studied ERP systems included tools explicitly designated as EAMs. However, the ERP systems embedded query tools that provided a continuum of EAM functionality. Some ERPs had minimal support for EAM functionality and required users to integrate external end-user tools or specially written programs. Alternatively, two ERP systems included a reasonably complete suite of tools for the construction of business alerts. While these tools were marketed as generic business process monitors, they mirrored the essential functionality of EAMs. The overall level of support for EAMs was low. There were significant technical barriers to the development of audit routines that operate continuously on the ERP systems. Results also indicated that auditors needed high levels of technical skills to implement EAMs within the tools provided by the ERP systems, further hampering likely adoption. These results provide insights as to why the adoption rate of EAMs is low. The results point to the need to strengthen support for EAMs within ERPs and lower the required human capital investment to implement EAMs in the query tools provided with ERPs. We suggest multiple methods to increase the rate of EAM adoptions. These include the development of generic EAM tools based on common metadata, perhaps built upon the eXtensible Business Reporting Language General Ledger taxonomy (XBRL-GL). The results are of value to internal and external auditors, ERP vendors and software developers, the XBRL community, and as a foundation for future research. The remainder of this paper proceeds as follows. Section II provides background information on ERP and EAMs, and develops the research questions addressed in the paper. Section III describes the research methodology used on this project, including descriptions of the ERP providers used in the study and the development of the embedded alerts. Section IV summarizes the research results for each ERP provider. Finally, Section V discusses conclusions based on the research, including key barriers to adoption of EAMs, that provide directions for future research. II. BACKGROUND Enterprise Resource Planning (ERP) Systems One of the most striking developments in business information systems over the last decade is the rapid and widespread adoption by medium- and large-scale organizations of ERP systems. These behemoths are generic software systems that facilitate an enterprise’s transaction processing requirements across its information supply chain. ERPs not only encompass traditional transaction processing but also elements of management support systems and knowledge management (Curran and Ladd 2000; Davenport 2000; Ptak and Schragenheim 1999). ERP systems typically employ a three-layer model (Best 2000) (see Figure 1). A data management layer employs a single or federated relational database management system. An application layer comprises of integrated application modules and analytical tools. Finally, end-users interact with the system via a presentation layer. ERP systems have been widely adopted. A survey of 433 large firms completed by the Financial Executives Institute (FEI 2001) showed that 35 percent of firms had completed implementation of ERP systems, with a further 19 percent of the respondents planning implementation within the next year. An average ERP system costs $11.5m and requires 19 months to implement (FEI 2001, 39). A single ERP system is typically capable of Journal of Information Systems, Fall 2005

10

Debreceny, Gray, Ng, Lee, and Yau

FIGURE 1 Integration of Embedded Audit Modules

ERP

Pre-ERP Presentation

Presentation

Presentation Embedded Audit Module

Embedded Audit Module

Application

Application Data Management

Application

Retrieving Data

Data Management

DBMS

managing the major information processing requirements of corporations in the acquisition and transformation of physical resources, including the appropriate marshalling of factors of production. Embedded Audit Modules (EAMs) Weber (1999) defines EAMs as ‘‘modules placed at predetermined points to gather information about transactions or events within the system that auditors deem to be material.’’ In the context of integration into an ERP system, ideally, an EAM would have the following characteristics: (1) an end-user environment that allows the auditor to establish a set of queries to test transaction integrity constraints either from a pre-defined suite of queries, the modification of the attributes of pre-defined queries, or by the creation of new queries by the construction of simple scripts; (2) a process for registration (embedding) and scheduling of these queries; (3) a method for running these queries against the flow of transactions for violations either continuously or temporally and (4) a capacity for reporting violations electronically (e.g., email) and (5) an ability to copy the transaction details of the violations to secondary storage. EAMs allow for the monitoring of auditable conditions reactively (continuously?), but on a timelier basis than do ‘‘after-the-fact’’ audit programs. EAMs can operate as compliance-testing or substantive-testing tools, with the potential to capture information about all transaction errors and control violations. If EAMs operated throughout the accounting period, the auditor would have information about the operation of controls (i.e., EAMs as compliance-testing tools), as well as information about actual transaction errors

Journal of Information Systems, Fall 2005

Embedded Audit Modules in Enterprise Resource Planning Systems

11

(i.e., EAMS as substantive-testing tools). Thus, EAMs can facilitate dual-purpose testing and constitute a simultaneous comprehensive compliance and substantive testing audit tool (Groomer and Murthy 1989). General Design Concerns One concern regarding EAMs is that poorly designed queries may result in high volumes of emails generated as the EAM fires. This could result in information overload with decrements to audit and auditor effectiveness. EAMs may also reduce system performance when executing a large number of complex alerts (Groomer and Murthy 2003; Murthy 2004). The suite of EAMs may also present significant technical and managerial challenges in addressing application and database security and controls (Groomer and Murthy 1989). EAM in the ERP Environment The first generation of EAMs typically required special coding and operated directly on the firms’ accounting data files (Groomer and Murthy 1989; Hansen and Messier 1983; Jancura 1980). In this pre-ERP two-layer environment, accounting data was usually stored in working and permanent data stores, using a variety of file managers and formats. In contrast, the ERP environment employs a three-layer model. A relational database stores transaction and security data at the first layer. The second layer consists of applications. The third layer, presentation, enables the end user to interact with the ERP. This added complexity raises many design issues for the builder of EAMs. For example, should the EAM monitor transactions at the application layer or at the data management layer? What are the implications that arise from the different systems of management and security that exist at the application and data management layers? Management of controls with the ERP system typically revolves around the role that a particular actor plays within the ERP system (senior accountant, payroll clerk, etc.). A particular actor has defined roles in the sequential processing of transactions. This transactional focus is likely to run counter to the needs of the auditor attempting to build an embedded audit query that monitors the totality of the control environment. The research questions for EAMs in the ERP environment that arise from this discussion are: ●

● ● ●

What functionality is provided by EAMs or other monitoring technology to support appositely designed embedded audit control monitoring or substantive testing procedures? How has the transition to the three layers of the ERP environment affected the design and management of embedded audit queries? What investment is required to configure and deploy EAM functionality in an ERP environment? Finally, what factors in EAM functionality would enhance or impede EAM adoption?

III. RESEARCH METHOD An extensive literature review did not identify any published research on EAMs in the ERP environment.1 Lack of prior research prompted an exploratory research approach. The primary objective of the research was to identify the level of support for EAMs within ERP systems. Developing an understanding of the nature and level of support for EAMs in ERP 1

Hunton et al. (2001) also note a surprising lack of academic research on the audit implications of ERP investments.

Journal of Information Systems, Fall 2005

12

Debreceny, Gray, Ng, Lee, and Yau

systems is a first step in researching the adoption and use of EAMs by internal and external auditors. If the support for EAMs were high, for example, research on EAMs would take a somewhat different path than if the reverse were the case. The research follows a three-staged approach. First, we selected a set of ERP systems that enterprises of varying size are likely to adopt. Second, we designed a set of test EAM alerts to examine each ERP solution’s ability to provide for EAMs for substantive testing. Third, we conducted interviews with representatives of each ERP system provider to provide the researchers with practical insight into key implementation issues in the adoption of EAMs. Target ERP Providers We requested cooperation from more than 20 ERP solution providers. Six providers agreed to participate. The ERP providers were, in approximate ascending order of size of organizations serviced by the provider: Frontstep, Scala, Industrial and Financial Solutions (IFS), Intentia, Oracle, and SAP. Figure 2 presents an overview of each company, including each firm’s industry focus, typical client size, and query language used within the ERP solution as well as compatible databases and operating systems for the ERP solution. FIGURE 2 EAM Development Process ERP Vendor

Industry Focus

Typical clients

Frontstep www.frontstep.com

Manufacturing

Scala www.scala.net

Distribution and manufacturing.

IFS www.ifsworld.com

Complex manufacturing, aviation, fleet management, and automotive

Small and Medium Enterprises Small to mid-sized subsidiaries of multinational corporations Medium companies

Intentia (Movex solution) www.intentia.com

Ten key industries including basic distribution, apparel, and food and beverage All industries

Oracle www.oracle.com SAP www.sap.com

All industries including 21 specialized industry solutions

Medium and large enterprises

Small to large Small to large

Journal of Information Systems, Fall 2005

Query Languages and Supporting Toolset Progress and MS SQL Server 2000

Compatible databases Progress

Compatible Operating Systems Windows and Unix

MS SQL Server 2000

MS SQL Server 2000

Windows

Oracle and other relational databases, Visual Basic (Windows based clients) Javascript and HTML (Webbased clients), Java, JScript, and ASP. Java

Oracle, PL/SQL, SQL

Windows and Unix

Oracle, DB2 and SQL

Platform independent

Oracle

Windows and Macintosh. Windows, Unix and Linux

Oracle, HTML, XML ABAP

DB2, SQL, Oracle

Embedded Audit Modules in Enterprise Resource Planning Systems

13

Development of Alerts We designed five test alert scenarios that would be a form of substantive testing to explore capabilities within the ERP systems to capture audit-relevant information. We adopted a quasi-forensic view of audit in developing the alerts. The test scenarios were based on purchasing cycle audit red flags (Albrecht and Albrecht 2004; Coderre 1998, Chapter 2; Davies and Huntington 2000). Each vendor was to demonstrate the capabilities of their solutions to simulate EAM-like alerts based on the scenarios. We presented the alert scenario to each vendor by first identifying the red flag, such as ‘‘significant increases/ reductions in charges by suppliers in the following period.’’ We developed a simulated fraud scenario to explain how specific red flags drawn from the information system could possibly signal fraud. For example, the purchasing manager may have recorded a lower amount of purchase discounts in the previous period resulting in an increase in discounts in the current period, or the purchasing manager may be trying to pocket the difference in discounts resulting in a decrease in discounts in the current period. Audit information relevant to the scenario was determined and the appropriate logic transcribed into simple pseudocodes based on the Structured Query Language (SQL) database query language. We provided this material to the respondents to program the EAM procedure. For example, the audit logic in this example is ‘‘Check for significant variances in the purchase price against the standard prices in a particular period. Report va...