1 Enriching Process Models for Business Process Compliance Checking in ERP Environments Martin Schultz Chair for Information Systems, University of Hamburg, Hamburg, Germany Abstract. In enterprise resource planning (ERP) environments the audit of business process compliance is a complex task as audit relevant context information about the ERP system like application controls (ACs) need to be considered to derive comprehensive audit results. Current compliance checking approaches neglect such information as it is not readily available in process models. Even if ACs are automatically analysed with audit software, the results still need to be linked to related processes. By now, this linking is not methodically supported. To address this gap this paper presents a method to automatically enrich process models with audit relevant information about ACs. The method consists of three phases: process model construction, automated analysis of ACs, and model enrichment. It utilizes two existing artefacts and combines them to provide a comprehensive basis for compliance checking. Moreover, the enriched process models can support auditors in conducting process audits in ERP environments. Keywords: Compliance Checking, Application Controls, BPM, ERP. 1 Introduction Since recent financial scandals (Enron 2001, MCI WorldCom 2002, Parmalat 2003, Satyam 2009, HRE 2011 or Olympus 2011) organisations face the challenge to manage compliance to a steadily increasing number of rules and regulations in their everyday business operations. The rules they have to comply with range from voluntary norms and standards (e.g. ISO 9000, COBIT) to directives imposed by active legislations (Sarbanes-Oxley Act, 8th EU directive). For instance, Lickel (2007) counted over 118,000 new rules in the USA since 1981 . There are regulations that are relevant for specific industries or sectors (e.g. pharmaceutical, utilities, financial sector) and others - including regulations for financial reporting that apply to all companies. All these compliance rules significantly influence the way organisations design and execute their business processes . They constitute boundaries and an organisation has to ensure that its business processes stay within these boundaries . Not surprisingly, practitioners and researchers dealing with business process management (BPM) pay growing attention to compliance aspects . Nowadays, organisations extensively rely on information systems (IS) to support and automate their business processes. Especially enterprise resource planning (ERP) J. vom Brocke et al. (Eds.): DESRIST 2013, LNCS 7939, pp , Springer-Verlag Berlin Heidelberg 2013
2 Enriching Process Models for Business Process Compliance Checking 121 systems and accounting information systems (AIS) are widely used to process and store thousands and millions of business transactions each day. In this environment, embedding controls in the underlying IS is a reasonable approach to enforce compliance during the enactment of business processes , , . Today s ERP and AIS offer diverse customizing settings to configure such automated controls, termed application controls (ACs) . For example, particular process steps like approvals of business transactions can be enforced during process execution or automated checks are implemented to prevent duplicate entering of invoices. These ACs allow organisations to comprehensively control their business processes and ensure compliance to several regulations in a cost-effective way , . ERP systems can be customized to such an extent that almost no deviation from a designed process is possible , . But, configuring ERP systems in a strict way impairs process flexibility that companies need in today s competitive markets . At worst, over-controlled systems lead to shadow processes or feral systems circumventing existing controls , . However, less-strictly configured ERP systems allow undesired behaviour that deviating from the designed process. Therefore, processes need to be constantly monitored whether they comply with defined rules. This monitoring activity is related to the audit domain . For audits of business processes compliance the ERP system of an organisation plays a key role: 1) It stores audit relevant data (transactional data, master data, change logs) and make it electronically accessible to the auditor. 2) Relevant system settings can be reviewed providing insights to what extent the system configuration already enforces a compliant enactment of business processes. Auditing of business processes in an ERP environment is a complex task as not only the process flow itself has to be considered but also the underlying ERP system constituting the context in which a process is executed , , . Auditors have to combine expertise from both worlds: a fundamental understanding of business processes and profound knowledge of ERP systems. This is a major challenge in current audit practice especially regarding ACs. They are considered as an important aspect of business process compliance but are not are not explicitly modelled in process models. Against this background, the method presented in this paper aims at automatically enriching process models with audit relevant information about ACs configured in the ERP system supporting the business process under audit. The method combines two already existing IS artefacts. In a first step a process model is reconstructed based on accounting data stored in an ERP system . Secondly, relevant customizing settings are automatically extracted from the ERP system and interpreted in terms of ACs. These ACs are linked to the before constructed process model. This enriched process model constitutes an improved data basis for automated compliance checking techniques as it considers relevant context information about the ERP environment. By now, existing compliance checking approaches neglect this context information as it is not readily available in process models. Moreover, it supports auditors in conducting process audits in ERP environments. The remainder of this paper is structured as follows. The next section describes the related research work regarding BPM and compliance, auditing of process compliance, and process mining. Section 3 explains the applied research method. In section
3 122 M. Schultz 4 the developed method is presented in detail. The evaluation of the approach is outlined in section 5. The utility of our method is evaluated in a case study together with an organisation using SAP ERP. The paper closes with a conclusion and implications for future research work. 2 Related Work 2.1 Business Process Management and Compliance Today s organisations strive for a comprehensively formalizing and automating their business processes to cope with their complex and competitive environment. Hence, many organisations show growing interest in BPM as it provides methods to model, automate, optimize and monitor business processes , . For example, organisations increasingly make use of business process modelling languages (e.g. EPC, BPMN) to design and document their business processes . As regulatory requirements directly impact business process modelling, practitioners and researchers from the BPM domain increasingly take compliance aspects into account in recent years . Ensuring compliance of business processes is a challenging task: the number and complexity of regulations is increasing and the rules are subject to constant change. This calls for a holistic approach to manage compliance. Becker et al. (2012) define business process compliance management (BPCM) as [ ] the steady modelling, refinement, and analysis of business processes regarding the fulfilment of regulatory compliance . Ramezani et al. (2012) outline the interdependencies between BPM and Compliance Management (CM) and describes CM as a [ ] methodology to elicit, specify and formalize, implement, check and analyse, and optimize compliance requirements in organizations . However, considering compliance of business processes is not a new topic, especially not in the auditing and risk management domain. Here compliance is closely linked with the internal control system of an organization. According to COSO, internal control is broadly defined as a process designed to provide reasonable assurance regarding the achievement of objectives in three categories: 1) effectiveness and efficiency of operations, 2) reliability of financial reporting, and 3) compliance with applicable laws and regulations . It is a system of integrated elements like people, organisational structure, processes, and procedures and covers procedural (e.g. business processes, auditing, and monitoring) as well as structural aspects (e.g. policies, organisational structures/ roles) [13 p. 248], . In this context key concepts are control objectives and control means. A control objective describes a desired state of an organisation or a process and is associated with a recommended course of action that should be taken (control means) to ensure that a control objective is achieved . Control means may involve policies, procedures, practices as well as organisational structures. They are either process independent or directly integrated into a particular business process , , . For business processes supported by IS application controls are of high importance. ACs are the subset of internal controls related to business processes that are directly embedded in IS , , . They are activated and configured via customizing and can be categorized into input, processing, and output
4 Enriching Process Models for Business Process Compliance Checking 123 controls , , [23, p. 126]. Objective of this type of controls is to ensure completeness, accuracy, validity, and authorisation of transaction and data processing within an IS. Common examples include automated reconciliations, data entry validations and logical access controls. ACs provide an effective and efficient means to enforce compliance rules in business processes as they are in general less prone to error (especially human error) and more reliable than manual controls , . Moreover, they only need to be configured once - hence the cost of control does not depend on the number of transactions checked . Not surprisingly, calculations of business cases show that ACs are more cost-effective in the long-term leading to an increasing tendency to replace manual with automated controls , . 2.2 Auditing Compliance of Business Processes The audit of an organisation s regulatory compliance is usually a legal requirement, e.g. annual audits of the financial statements. As audit standards enforce an in-depth analysis of the organization s operation, business processes constitute a central audit object . Thereby, the auditor focuses on the system of internal controls the organization has implemented for their processes ( The auditor shall obtain an understanding of internal control relevant to the audit [ ] ). This approach is based on the assumption that well-designed and controlled business processes lead to regulatory compliance of an organisation, e.g. fairly presented financial statements , . Accordingly, all big audit firms consider process audits as an integral part of their audit approach , . The vast number of compliance rules and the complexity of business processes in today s organisations call for an automated support for audit tasks , . Hence, IS researchers have developed (semi-) automated, model-based compliance checking approaches: compliance rules are formally defined and applied to business process models and instances in order to determine whether they comply with the rules or not . These approaches can be subdivided into two categories: forward and backward compliance checking. Forward compliance checking techniques proactively verify compliance rules at design and/ or execution time of a process. Backward compliance checking techniques retrospectively detect non-compliant behaviour in process instances . Becker et al. (2012) present a comprehensive overview of forward compliance checking approaches . For a review of backward compliance checking techniques please refer to . However, compliance checking techniques mainly focus on the control flow of process models and/ or instances neglecting potentially relevant context information e.g. about related IS , , . In general, the context a process is embedded in is [ ] the combination of all situational circumstances that impact process design and execution [ ] . Rosemann et al. (2008) differentiate four types of context: an immediate, internal, external, and environmental. IS are on the immediate layer as they directly facilitate the enactment of a process . It is agreed, that many compliance rules can only be comprehensively checked by taking such pertinent context information into account , . There are a few approaches that consider the context of a process for compliance checking. Fundamental requirements for a comprehensive
5 124 M. Schultz support of semantic constraints in process management systems are discussed in Ly et al. (2012) and a framework for compliance support over the process life cycle is proposed . Van der Werf et al. (2012) link an event log of a process to its context that has to be described in a data model beforehand . Approaches that consider the data flow of a process for checking business/ compliance rules are presented in  and . The verification of access control properties based on a security annotated process model is outlined in Wolter et al. (2009) . However, these approaches do no comprehensively consider relevant context information about the IS the process is supported by. As ACs are executed inherently through the IS these controls are in general not explicitly modelled in a process model at design time and do not generate an entry in the event log of an IS. Therefore, AC-related information is not readily available on process model level and cannot be considered by compliance checking techniques. To close this gap the method presented in this paper automatically analysis ACs and enriches process models with the derived information. For automatically analysing the system settings of a SAP ERP system in terms of ACs, Alles et al. (2006) describe an approach in the context of continuous auditing (CA) . Our method presented here utilises a similar IS artefact presented in . It is a software prototype (ERP AuditLab) that enables an automated evaluation of ACs for audit purposes. However, both approaches do not link the gained audit results (e.g. status of AC) to the affected business processes. From an auditor s point of view, considering context information about ACs in process models unfolds its full potential especially when the underlying process model is also derived with a retrospective view on data stored in an information system. Therefore, our method utilizes process mining to determine such a model. This fits to general audit practices as process compliance is mainly checked ex post, e.g. during financial audit. However, the here presented method to enrich process models can also be applied to already existing process models. 2.3 Process Mining in Auditing Process mining is a research area combining data mining with process modelling and process analysis. The main goal is to [ ] discover, monitor and improve real processes (not assumed processes) by extracting knowledge from event logs readily available in today's (information) systems . Among others, it encompasses process discovery, conformance checking, organizational mining, model extension and repair . The data source for process mining is an event log containing a series of events recorded in an IS. Each event can be linked to a well-defined activity in a process and is related to a particular process instance/ case , . Process mining is a fairly well researched topic and associated techniques have matured over the last decade resulting in increasing interest from practice . More and more software tools are available, and process mining is applied in diverse industry sectors. For an overview of process mining techniques until 2008 please refer to . Also internal and external auditors working in an ERP environment can benefit from the capabilities process mining offers. Process mining facilitates full audits (instead of sample based) of business processes in an effective way based on data
6 Enriching Process Models for Business Process Compliance Checking 125 recorded independently of the auditee . However, applying process mining techniques to data stored in ERP systems is still a challenge. Common ERP systems (e.g. SAP, Oracle, and Microsoft) are not process-oriented even though they have built-in workflow engines. Data related to a particular process instance is stored across several tables without readily providing a process-oriented linkage or case identifier. Thus, selecting, extracting, and pre-processing of relevant data is not a trivial task . Van der Aalst et al. (2010) and Jans et al. (2010, 2011) describe different scenarios for process mining in an ERP environment from an audit perspective , , . The latter uses a preselected list of process activities to determine tables including relevant data. In contrast, financial process mining (FPM) which the here presented method utilises takes advantage of the specific structure of accounting data for reconstructing process instances of financial processes without preselecting relevant activities . Section 4.1 describes the approach in more detail. 3 Research Method The research presented in this paper follows the design science approach , , . The artefact is a method to automatically derive and enrich a process model with information about ACs based on ERP data. The relevance of the artefact results from the fact that it addresses a gap between process audits and IS audits prevalent in today s audit practices. It combines information from both audit areas in a structured way to enable a more comprehensive audit of business process compliance. There is a consensus in literature that evaluating the designed artefact is an essential step in design science research . Based on the framework presented in  a case study is selected as evaluation method . The artefact is applied to data from a productive system of an organisation to demonstrate that it feasibly works in a real setting. To evaluate the utility of the presented method from a stakeholder perspective, a group of six auditors reviews the enriched process model. 4 Integrating Process Models and Application Controls The here presented method consists of three phases: 1) A model of an accounting related process is automatically constructed from transactional data stored in an ERP system (section 4.1). 2) Audit relevant information about ACs is extracted from the ERP system (section 4.2) and 3) embedded in the process model (section 4.3). 4.1 Financial Process Mining (FPM) Today s ERP systems use a largely uniform data structure to store accounting data . An accounting document consists of a header and at least two associated items (debit and credit). In case open item accounting is used, each document item refers to the document header it was cleared by, e.g. a vendor invoice line item is linked to the corresponding payment document header. Using this data structure, FPM reconstructs the document flow representing the control flow of a particular process instance .
7 126 M. Schultz Such document references ERP systems are not limited to financial accounting. Also other processes can be covered, e.g. purchasing. Fig. 1 (a) illustrates an instance of a purchase to pay process. Each document contains an activity name, the SAP transaction code, a document number and a user id. This instance consists of four vendor invoices (DocNo 28017, 29991, 28038, 28037) that are cleared by three different payment documents. These payments refer to the same document settling open items on the bank clearing account. Only one invoice (DocNo 28017) relates to a goods receipt (DocNo 28016), a corresponding purchase order, and a purchase requisition document. Another invoice (DocNo 28037) is at least linked to a purchase order whereas the two remaining invoices (DocNo 29991, 28038) are just entered and paid without upstream purchasing activities. In contrast to this fairly simple example, other process instances can become rather complex. Fig. 1 (b) depicts an instance with 1,996 documents. Fig. 1. (a) Instance of a Purchasing Process (b) Complex Instance of a Purchasing Process These process instances serve as a data basis to derive a process model by applying process mining techniques. A pre-processing of the instances is necessary to apply conventional process mining algorithms because they expect a sequential, timestampbased event log as input. The instances constructed with FPM are graphs and therefore need to be mapped to a sequential event log structure, e.g. MXML . Enter Incoming Invoice (MB60) List Blocked Billing Documents (VFX3) Post Parked Document (FBVB) Automatic Payment (F110) Post with Clearing (FB05) Clear Vendor (FB1K) Post Document (FB01, FBR2) Create Purchase Requisition (ME51) Create Purchase Order (ME21) Enter Goods Movement (MIGO_GR) Enter Incoming Invoice (MIRO) Fig. 2. Simplified process model for transactions of the Trade Payable Domestic account
8 Enriching Process Models for Business Process Compliance Checking 127 Fig. 2 depicts a process model in the business process modelling notation (BPMN) created with the fuzzy miner . The model is derived from all process instances that have posted to a particular balance sheet account ( Trade Payables Domestic ) in the organisation of the case study throughout one financial year. The instance in Fig. 1 (a) is covered by the process model as all activities and links are included. Such models are enriched by our method with information about ACs. 4.2 Extracting Information about Application Controls As explained earlier, ACs are directly embedded in IS and configured by customizing settings. From an audit perspective there are two aspects that need to be considered during an audit of this type of controls. In a first step, it needs to be reviewed whether the AC is appropriately configured. The auditor checks this by reviewing the corresponding customizing settings. This audit step has to be done only once unless there are changes to the settings . However, this check does not reveal subsequent changes of relevant settings throughout the time period under audit . Hence, in a second step the auditor needs to review the change log of the customizing settings for non-compliant changes . As the customizing settings and the change log are electronically stored in database tables in the ERP system, an analysis software like the ERP AuditLab presented in  can facilitate the audit of ACs. It uses the remote function call mechanism (RFC) provided by the ERP system. Based on the extracted tables it constructs so called data objects, each representing the current settings of a particular AC. With the help of pre-defined rules and default values the settings are evaluated from an audit perspective and an audit result is automatically derived. For a detailed description refer to . Extending this technique to the audit trail of the customizing tables allows reconstructing not only the current status of an AC but also previous settings throughout the audit period. Doing so, the same rules and default values can be applied for the evaluation of former states. 4.3 Enriching Process Models with Application Controls As described in section 2.1, controls can be process independent or directly integrated into a particular business process , , . Process inherent application controls refer to the input, processing and output of a process. Process independent application controls do not relate to a specific processing phase in the IS but rather enclose the process as a whole and ensure that information is accurately and completely sent/received and protected from unauthorised access, e.g. reconciliations of data transfer between IS, segregation of duties (SoD) . In the audit domain, process inherent controls are considered as a specific type of process activity when it comes to process modelling , . However, as ACs are provided inherently through the IS these controls are in general not explicitly modelled as activities in a process model at design time. So they are not subject to forward compliance checking. At the same time, the execution of an AC itself do not generate an entry in the event log of the IS. Hence, considering this kind of controls in backward compliance checking and process mining is not possible. To close this gap three modelling patterns for process
9 128 M. Schultz inherent ACs are designed. These patterns are based on the control pattern presented in  and the point in time a control is performed. Within these patterns ACs are modelled as new activities to reflect the understanding of ACs in the audit domain and to make them available to control flow based compliance checking techniques: Preventive Control Pattern: The control ensures that a check routine is automatically executed in conjunction with a certain process activity. Only in case the check routine passes successfully, the activity can be completed. The check routine refers either to the processing logic of the activity or processed data objects. Example: On entering an invoice a check is executed indicating potential double invoices. Detective Control Pattern: The control ensures that a check is executed after a certain process activity is completed. If the check routine identifies an exception, a corrective action is taken. The check refers to data objects created or modified by the activity. Example: After processing a batch of invoices for payment the totals of invoice and payment amounts are compared. Required Activity Pattern: The control ensures that a certain activity (conditionally) occurs (or is absent) if an activity has been performed in the business process. Example: On entering a purchase order an approval step can be configured as a mandatory step depending on the value of the purchase order. Application Controls Pattern Preventive Control Detective Control Check for Activity A Activity A Check for Activity A passed not passed Activity A passed not passed Corrective Activity for A Required Activity Activity A Cond. true false Required Activity after A Fig. 3. Process fragments for process inherent application controls Fig. 3 presents these patterns modelled as process fragments in BPMN. Process fragments are reusable process structures or building blocks that can be inserted into an existing process model . To enable reuse the fragment needs to be specified on an abstract level. Preventive and detective control patterns are modelled as new activities (Check for Activity A). In case of a preventive AC the activity is added prior to the activity it refers to (Activity A). The process stops if the check is not successfully
10 Enriching Process Models for Business Process Compliance Checking 129 passed (Cancel End Event) and activity A is not completed. A detective AC is invoked after completing the activity it refers to (Activity A). Depending on the result of the check a corrective action is taken (Corrective Activity for A) or the next activity succeeding activity A in the original process model is executed. An application control complying with the required activity pattern adds an activity (Required Activity after A) directly succeeding the activity it refers to (Activity A). If applicable for the AC a condition can be added. These patterns and corresponding process fragments are now used to enrich an existing process model. Input for this enrichment is besides a given process model a repository of ACs provided by the IS under audit. Software like the ERP AuditLab described in section 4.2 can provide such a repository. For each AC a list of activities (functionalities of the IS) is maintained that invoke the particular AC. Additionally, the abstract pattern to which an AC corresponds is added to the AC repository. Auditors/ software suppliers can provide both details. SAP ERP provides among many others following three ACs. Similar ACs are also available in other ERP systems: 1. Double Invoice Check: Application Controls Pattern: Preventive Control Invoked by: Enter Incoming Invoice (MB60), Enter Incoming Invoice (MIRO), ( ) 2. 3-Way-Match: Application Controls Pattern: Preventive Control Invoked by: Enter Incoming Invoice (MIRO), ( ) 3. Approval for Purchase Orders: Application Controls Pattern: Required Activity Invoked by: Create Purchase Order (ME21), ( ) Following steps are performed for a given process model and AC repository: For each activity in the process model related ACs are derived. For each identified AC a compliance check is performed as described in section 4.2. All ACs that are not appropriately configured are disregarded. For each remaining activity-application control combination the corresponding abstract process fragment is instantiated with concrete values of the ACs (e.g. Check for A is replaced by Double Invoice Check) and added to the given process model. In case two or more ACs refer to the same process activity, the fragments are sequentially linked. In case an AC refers to more the one activity in the process, the fragment is added multiple times. Fig. 4 illustrates the resulting process model after applying these steps to the process model of the Trade Payable Domestic account given in Fig. 2. Based on such an enriched process model a more comprehensive automated compliance checking can be performed, especially regarding compliance rules validating the existence or absence of certain activities, e.g. purchase orders have to be approved (for an overview of control flow oriented compliance rules refer to ). To facilitate the interpretation of the process model by human auditors an annotation can be added to process fragments containing additional audit relevant information. Exemplarily, in Fig. 4 the date is added since when the AC is configured appropriately. This information is derived from the change log of the customizing settings.