Download

1. BACKGROUND

1.1 Linkage to ISACA Standards

1.1.1 ISACA IT Audit and Assurance Standards, as well as certain IT Audit and Assurance Guidelines, have direct relevance to the IT audit and assurance professional’s work on enterprise resource planning (ERP) systems or ERP system implementation projects.
1.1.2 For example, in accordance with standard S6 Performance of Audit Work supervision of the performance of ERP-related audit and assurance work by subordinate IT audit and assurance professionals or other staff for the IT audit and assurance professional must be subject to sufficient appropriate supervision by the IT audit and assurance professional.
1.1.3 Further, in those circumstances where the IT audit and assurance professional is requested or required to be involved in non-audit or non-assurance roles associated with the ERP systems or implementation project, in addition to the IT Audit and Assurance Standards and Guidelines related to S2 Independence and G12 Organisational Relationships and Independence, the IT audit and assurance professional should review and appropriately consider the applicability of the ISACA Standards for IS Control Professionals.
1.1.4 If the ERP application will be in scope, ISACA’s IT Audit and Assurance Guideline G14 Application System Reviews should be reviewed.
1.1.5 If the IT audit and assurance professional is to be involved from an audit or assurance or a non-audit or non-assurance perspective in the business process re-engineering (BPR) activities associated with the implementation and use of an ERP system, ISACA’s IT Audit and Assurance Guideline G26 Business Process Re-engineering should be reviewed.
1.1.6 If any component of the ERP system is outsourced to a third party, ISACA’s IT Audit and Assurance Guidelines G4, Outsourcing of IS Activities to Other Organisations and G16 Effect of Third Parties on an Enterprise’s IT Controls should be reviewed.
1.1.7 In addition to the pronouncements of ISACA’s Professional Standards Committee, its Knowledge Board has or has had a number of projects and deliverables, which are available through the ISACA web site (www.isaca.org) and may be of interest to the IT audit and assurance professional, depending on the specific ERP product and other resources being used.

1.2 Linkage to COBIT

1.2.1 Selection of the most relevant material in COBIT applicable to the scope of the particular audit is based on the choice of specific COBIT IT processes and consideration of COBIT’s information criteria. The process and control objectives to be selected and adapted may vary depending on the specific scope and terms of reference of the assignment.
1.2.2 This guideline has been drafted to avoid limiting its application to a particular brand of ERP. It has also been drafted to cover all aspects of an ERP’s use within an enterprise. Therefore, the guideline can be linked to all four COBIT domains, Plan and Organise, Acquire and Implement, Deliver and Support, and Monitor and Evaluate.

Should a particular audit project be limited by its project charter to one aspect of a particular ERP in a particular business entity then, of course, the applicable COBIT domains and business processes would be correspondingly limited. To illustrate this, the following two examples are provided. These are not intended to be exhaustive and the particular scope of an audit might reasonably alter which processes ought to be included.

Example 1. An Audit/Review of the Planning and Acquisition of an ERP
Plan and Organise:

• PO1 Define a strategic IT Plan
• PO2 Define the information architecture
• PO3 Determine the technological direction
• PO4 Define the IT processes, organisation and relationships
• PO5 Manage the IT investment
• PO6 Communicate management aims and direction
• PO7 Manage IT human resources
• PO8 Manage quality
• PO9 Assess and manage IT risks
• PO10 Manage projects

Acquire and Implement:

• AI1 Identify automated solutions
• AI2 Acquire and maintain application software
• AI3 Acquire and maintain technology infrastructure
• AI4 Enable operation and use

Monitor and Evaluate:

• ME3 Ensure compliance with external requirements

Example 2. An Audit/Review of a Mature ERP System
Plan and Organise:

• PO4 Define the IT processes, organisation and relationships
• PO5 Manage the IT investment
• PO7 Manage IT human resources
• PO8 Manage quality
• PO9 Assess and manage IT risks

Acquire and Implement:

• AI2 Acquire and maintain application software
• AI3 Acquire and maintain technology infrastructure
• AI4 Enable operation and use
• A/6 Manage changes

Deliver and Support:

• DS1 Define and manage service levels
• DS2 Manage third-party services
• DS3 Manage performance and capacity
• DS4 Ensure continuous service
• DS5 Ensure system security
• DS6 Identify and allocate costs
• DS7 Educate and train users
• DS8 Manage service desk and incidents
• DS9 Manage the configuration
• DS10 Manage problems
• DS11 Manage data
• DS12 Manage the physical environment
• DS13 Manage operations

Monitor and Evaluate:

• ME1 Monitor and evaluate IT performance
• ME2 Monitor and evaluate internal control
• ME3 Ensure compliance with external requirements

1.3 Need for Guideline

1.3.1 ERP systems, which evolved out of manufacturing resource planning systems for the manufacturing industry, use data from a wide range of business areas to provide cross-departmental management and process information. The term ‘ERP’ is no longer about just planning, rather it refers to core critical business processes of an enterprise. Despite principal usefulness of the concept, ERP system implementations can fail to deliver expected results if not adequately managed and controlled. Further, there are emerging trends and changing technologies that support expanded use of ERP systems (e.g.,, web-enabled customer interfaces), which will increase the importance of the security and control consideration for ERP.
1.3.2 The audit of an ERP system requires the IT audit and assurance professional to have specific knowledge and an understanding of the complex features and integrated processes built into and required for the successful implementation, use and control of specific vendor products.

1.4 Application of Guideline

1.4.1 When applying this guideline, the IT audit and assurance professional should consider its guidance in relation to other ISACA standards and relevant guidelines. The guideline is written as generic, rather than a product-specific, guidance. The IT audit and assurance professional will need to consider and adapt the guidance depending on the ERP system and other products/procedures being used.
1.4.2 This guideline sets out information and suggests how the IT audit and assurance professional should comply with the ISACA Standards and COBIT when involved in the audit or review of an ERP system or ERP system implementation project.

2. ERP SYSTEMS

2.1 Definitions

2.1.1 ERP is used, first, to denote the planning and management of resources in an enterprise. Second, it denotes a software system that can be used to manage whole business processes, integrating purchasing, inventory, personnel, customer service, shipping, financial management and other aspects of the business. An ERP system typically is based on a common database, various integrated business process application modules and business analysis tools.

2.2 Risks and Control Challenges for Implementation of ERP Systems

2.2.1 ERP systems are implemented to support the operations of an enterprise and, to be successful, must be fully integrated into all the significant processes and procedures that together enable the enterprise to work effectively. Given the integrated nature of ERP systems, they can further add to the enterprise’s risks or challenges related to:

• Industry and business environment
• User or management behaviour
• Business processes and procedures
• System functionality
• Application security
• Underlying infrastructure
• Data conversion and integrity
• Ongoing maintenance/business continuity

2.2.2 The risks associated with the implementation and ongoing use of an ERP system cannot be determined or controlled by review of application or technical risks in isolation, but must be considered in conjunction with the business process control objectives of the enterprise being served. The challenge to the IT audit and assurance professional is, therefore, obtaining an understanding of the business and regulatory environment in which the enterprise operates and being skilled in the identification of quantifiable application or technical risks and less quantifiable procedural or behavioral risks.
2.2.3 Typically, in a large enterprise where the quantity of data processed by the ERP system is extremely voluminous, the analysis of patterns and trends proves to be extremely useful in ascertaining the efficiency and effectiveness of operations. Most ERP systems provide opportunities including specific tools for such extraction and analysis. The use of data analysis tools within the ERP system can assist the IT audit and assurance professional throughout the ERP system’s life cycle (i.e., pre- and post-implementation).

2.3 BPR and ERP Implementation

2.3.1 BPR and ERP implementation projects can be thought of as being independent initiatives. In theory, each project could exist within an enterprise without the other. In practice, they are often both in process at the same time in an enterprise and are influenced by and dependent on each other in a myriad of complex relationships, often including common design for key business processes. An ERP might be selected to replace an existing system, and the execution of a BPR may be delayed. A BPR might be in place but terminated prior to completion, and an included ERP implementation might continue.
2.3.2 BPR and ERP implementations are often at different stages of their development. A BPR project may be started and several months into the project when it is concluded that an ERP is required to support the new processes, an acquisition project commences. Similarly, a business decision might have been made to acquire a new IT system and choose an ERP system. During the implementation process it may be recognised that the ERP would enable a business reengineering and a BPR initiative’s commencement.
2.3.3 The IT audit and assurance professional’s primary focus should be with an ERP implementation. However, concurrent BPR may introduce new risks to the implementation process and often change existing risks, e.g.:

• The changes proposed by BPR may require the people affected to behave in a different manner and may engender support, concern and/or even hostility within an enterprise. This may be transferred to the ERP implementation project.
• BPR may drain enterprise resources from the ERP implementation.
• Even if the above two risks have no effect on the ERP implementation, unfamiliarity with new processes introduced by BPR might lead to inadequate process description and suboptimal configuration of the ERP system.
• BPR and ERP may not be well integrated, leaving, at best, suboptimal performance and unnecessary expenses.
• Using ERP as a ‘change lever’ may distract from BPR. With new, more powerful technology there is a temptation to adopt a process simply because the new technology can do it, rather than because it is the optimum business process.

2.3.4 The common steps when performing BPR, with special attention to those steps where IT can have a strong effect, are as follows:

• Analysis phase—The existing processes, the information and the IT systems currently in use are analysed and, the processes that need to be reengineered are identified. As the use of information and IT can be the levers for dramatic changes in the enterprise’s processes, the IT audit and assurance professional can provide useful contributions in the early stages of the BPR process.
• Redesign phase—The new processes are redesigned, new information or new ways to use existing information are searched, and the blueprint of the new business system is defined. The to-be model of the new workflow, how the new information is to be shared across functional areas of the business and the new IT system specifications, can be areas for IT audit and assurance coverage.
• Transformation phase—The migration strategy is developed, and the migration action plan is created and then executed. The transformation of the IT systems, the introduction of new information and new technologies, and the discarding of old information and IT systems can be areas for IT audit and assurance coverage.

2.4 Application and Use of COBIT

2.4.1 COBIT can be applied in many ways while reviewing ERP systems. The relevance of the various control objectives will differ from enterprise to enterprise, as will the needs of the enterprise’s control structures. However, a good beginning to applying COBIT during the review would be to address the management IT concerns regarding enterprise packaged solutions (refer to the ISACA publication Implementing and Continually Improving IT Governance). The Gartner Group has identified some specific concerns of management regarding ERP systems, including:

• Failure to meet user requirements
• Failure to integrate
• Incompatibility with technical infrastructure
• Vendor support problems
• Expensive and complex installations

2.4.2 Relevant control objectives that have been identified by ISACA can be used to address the previously mentioned concerns. In addition, the IT audit and assurance professional also could draw up engagement-specific control objectives and engagement-specific audit and assurance procedures for these specific control objectives.

3. ACHIEVING EFFECTIVE COMPLIANCE WITH IS AUDITING STANDARDS

3.1 Introductory Comments

3.1.1 For the IT audit and assurance professional’s initial exposure to, or role in, an ERP system or ERP system implementation project, ISACA’s IT Audit and Assurance Standards and Guidelines are very relevant and should be considered and appropriately adhered to by the IT audit and assurance professional. The IT audit and assurance professional would be well served to complete a thorough review and analysis of these standards and guidelines within the context of the planned role or work on an ERP system and related initiatives.
3.1.2 For purposes of this guideline, only certain of the more relevant IT Audit and Assurance Guidelines are specifically referenced. ERP systems provide various opportunities for the IT audit and assurance professional and provide risks for management that need to be addressed with care and planning. The planning stage for an ERP system or implementation review is critical to a successful audit and sign-off.
3.1.3 The audit of an ERP system or implementation calls for a strategically different approach by the IT audit and assurance professional. ERP systems integrate diversified business processes and, accordingly, may be implemented in conjunction with the conduct of a BPR project. As part of this reengineering, critical control procedures, once used to protect the finances and operations of an enterprise, may be changed or eliminated, resulting in entirely new control structures/procedures and related risks.
3.1.4 For ERP systems or implementation projects, the IT audit and assurance professional must also reengineer the way audits are performed. Risks will have undergone a transformation with regard to the intensity, diversity and the means through which they can occur. These risks arise, to some extent, due to the integrated program logic and business process functions inherent in ERP software products. Additionally, many of the legacy controls will no longer be applicable, and as such, the IT audit and assurance professional will need to identify the new control structure.
3.1.5 In planning an IT audit of an ERP system, the IT audit and assurance professional should give serious consideration to dividing the audit into sections and auditing the sections sequentially. The audit of a whole ERP system is a considerable undertaking and may strain IT or other audit and assurance resources.

3.2 Audit Charter

3.2.1 The audit charter of the IT audit function may need to be modified as a result of an enterprise’s decision to implement an ERP system. For example, BPR considerations associated with effective implementation of an ERP system could require the IT audit and assurance professional’s scope of work or relationships with other audit functions (e.g., financial, operational) to be expanded and more closely integrated (e.g., through a joint or collaborative audit and assurance initiative).
3.2.2 The planned scope for audit by the IT audit and assurance professional should be defined in accordance with the IT audit charter.
3.2.3 It is imperative that the enterprise’s senior and system management fully understand and support the IT audit and assurance professional’s role(s) as it relates to the ERP system or implementation project. The IT Audit and Assurance Guideline G5 Audit Charter, should be reviewed and considered within the context of the ERP system and related initiatives of the enterprise, as shown in the following figure.

3.3 Independence

3.3.1 If the IT audit and assurance professional is to perform or be responsible for non-audit and non-assurance roles associated with the ERP system or an ERP system implementation project, IT Audit and Assurance Guideline G17 Effect of Non-audit Role on the IT Audit and Assurance Professional’s Independence should be reviewed and adhered to appropriately.
3.3.2 If the IT audit and assurance professional is to have a non-audit and non-assurance role in an ERP system or related initiatives, the IT audit and assurance professional should also review and appropriately adhere to ISACA’s Standards for IS Control Professionals.

3.4 Competence

3.4.1 The IT audit and assurance professional’s long-term audit and assurance strategies and plans for an enterprise using ERP systems should include aspects that will support the ongoing development and maintenance of IT audit and the IT audit and assurance professional’s competence as it relates to ERP. This would include enhancements to the level of skills and knowledge and continuing professional education (S4).
3.4.2 If an IT audit and assurance professional does not have the required skills to undertake an IT audit of an ERP system or implementation project, the IT audit and assurance professional should consider contracting the audit to a qualified IT audit and assurance professional. It would be appropriate to include in the contract a requirement for knowledge transfer.
3.4.3 Skills for auditing an ERP system implementation can be acquired through ERP audit or product training on the job experience and by participating in ERP areas or audit and assurance groups.
3.4.4 Specific product-related training and experience (i.e., terminology for specific ERP products may be different or mean different things) can be acquired through hands-on use and inquiry or observation. Background interviews or briefing by IT management, technical staff and users responsible for the system can assist the IT audit and assurance professional in understanding the security, control and processing features or risks of the specific ERP system.
3.4.5 The appendix to this guideline provides further guidance on how to address competency gaps.

3.5 Planning

3.5.1 At the outset of an IT audit of an ERP system or ERP system implementation project, the IT audit and assurance professional should invest sufficient time and effort gathering background knowledge and understanding of the enterprise’s existing/planned deployment and gaining control of the ERP system and related resources. The IT audit and assurance professional would achieve this through product research, direct inquiry of management and other staff, and document review procedures.
3.5.2 More specifically, the appendix provides a general overview of the elements of, and basic questions on, an ERP system implementation that the IT audit and assurance professional may need to consider.
3.5.3 Although ERP systems and implementations are likely to be more integrated and complex than other business systems that the IT audit and assurance professional may have encountered, they involve many organisational management, environmental, application, control considerations and risks similar to the more traditional systems and implementation projects.
3.5.4 It is of particular note that the areas in which an IT audit and assurance professional might be involved during the audit of an ERP project cover all aspects of an enterprise’s operations. The complete audit of an ERP system will, therefore, require a broad skill set that is unlikely to be found in one person or one audit and assurance discipline. It is vitally important that the correct mix of audit and assurance skills are involved in an ERP audit or review. Audit skills and/or resources from financial, operational and regulatory areas may be needed to complement the IT audit and assurance professional’s skills.
3.5.5 It is important during planning to consider which, if any, of the ERP processes are extended to the web. With many enterprises extending business over the web via enterprise portals and web-based applications on new mobile computing tools, the IT audit and assurance professional must determine if the ERP system being audited fits into this category (i.e., intranet, extranet or Internet). This will affect the performance of audit and assurance work and may extend the boundaries of the ERP system.
3.5.6 IT audit and assurance professionals should obtain reasonable assurance that management is aware of, and satisfied with, the scope of the audit and assurance work to be performed.

3.6 Performance of Work

3.6.1 The IT audit and assurance professional can use various tools and techniques to audit an ERP environment to address entire populations, flag potential risks and efficiently perform a review. Often the initial design of controls for an ERP system falters over time. Combine this with an evolving environment in which the ERP system not only interfaces to non-ERP systems, but also may serve as a web-enabled environment where the boundaries of the processes extend beyond the ERP system itself, and it becomes apparent that tools and techniques should be considered for:

• Data mining and analysis—ERP products ordinarily come with robust audit and assurance-related reports, and where these do not exist, third-party tools may be used to identify and analyse critical data or samples.
• Separation of duties analysis/authorisation analysis—Information is not restricted to disparate departmental systems, rather the integrated nature of an ERP system results in a high level of risk around security and access privileges. Business rules can be used to identify cases in which potential security concerns are flagged for review.
• Workflow/report delivery—Workflow within ERP systems can be utilised to deliver exception reports to key individuals for analysis and review. Given that the information is available in real time, root-cause analysis is much less complex and corrective business measures can be initiated.
• Upgrades/control intelligence—ERP product suppliers continue to invest in research and development leading to new or enhanced functionality, not to mention ongoing corrections to existing functionality. It is vital the enterprise, including the IT audit and assurance professional, remain current on the ERP system’s latest functionality, capacity management and control capabilities. Tools exist to stay abreast on the technical control settings that are available within the ERP system, whether it is part of the original implementation or an upgrade.

3.6.2 An audit of an ERP system could provide assurance covering the area of process integrity. Specific matters to consider include the following:

• Identify control objectives for processes being implemented.
• Identify and assess potential business risks and financial risks in the processes being implemented.
• Develop and design the most effective and efficient ways of controlling these risks (which implementers generally do not focus on or do not have the expertise to develop).
• Perform an independent analysis of key business activities, comparing enterprise processes to leading practices and recommending process improvements.
• Provide assurance that the controls within ERP systems are appropriate and effective.
• Review the interfaces feeding into ERP systems from non-ERP systems (including legacy, web based and mobile computing applications).
• Perform audit and assurance tests focusing on business processes and internal controls. Many enterprises reengineer business processes during ERP implementation.
• Review business continuity plans and provide reasonable assurance that they have been tested.

3.6.3 An audit of an ERP could provide assurance covering the area of application security. Specific matters to consider include the following:

• Review standard ERP parameters, including application controls, authorisations and standard security configuration.
• Assess application security to allow processing in an efficient and controlled manner, while protecting valuable data.
• Assess configuration decisions to help provide reasonable assurance of the integrity of business processes and application security.
• Review design documentation for appropriate security and control.
• Assess the security administration process to provide reasonable assurance that the access granted is appropriately identified, evaluated and approved.
• Many business processes may be extended out over the intranet, extranet or Internet. Provide reasonable assurance that security processes appropriately address these risks.

3.6.4 An audit of an ERP system could provide assurance covering the area of infrastructure integrity. Specific matters to consider include the following:

• Identify the potential configuration and security risks for the infrastructure components (i.e., hardware, operating system, database management software, networking hardware, Internet, intranet) supporting the application software package.
• Review the ability of the enterprise’s IT infrastructure to support its practices and future operational goals.
• Identify internal system architecture issues that may cause performance, availability or data integrity challenges.
• Review business recovery plans and provide reasonable assurance that they have been tested.

3.6.5 An audit of an ERP system could provide assurance covering the area of implementation integrity. Specific matters to consider include the following:

• Provide reasonable assurance of a smooth transition to the new ERP environment, with minimal effect on employees and without any loss in confidence as to the integrity, security and accuracy of data.
• Identify potential risks connected with the transfer of data from the legacy systems to the new production environment and interfaces with other systems.
• Test and assess the functionality, controls and readiness before go-live.
• Assess data quality.
• Assess data conversion and integrity strategies and control procedures.
• Assess testing plan(s) for completeness and for appropriate security and integrity.
• Confirm that testing has involved the intended user community and that the new ERP owner is satisfied that user acceptance is complete.
• Provide independent review of training for completeness of business process and security considerations.
• Provide post-implementation review of the effectiveness of the control and security environment and the overall management of the implementation process.
• Assess exception reporting.

3.6.6 The auditing of the ERP implementation can be carried out any time in the life cycle of the project by auditing what has been done until that time and what is planned for the future. Ideally the audit would involve review either on a continuous basis or at several points during the project’s life cycle. To this end, the IT audit and assurance professional needs an audit and assurance framework that addresses the most critical implementation areas where often major risks are hidden, for instance:

• Project management
• Quality management
• Benefit management
• Risk management
• Change managementv

3.6.7 Project management consists of four phases:

• Management planning—When the project is initiated, a management plan is developed and proposed, the benefits are agreed to, and the project’s scope and structure re defined.
• Project implementation—Throughout the course of the project, the key project management activities—work planning, resource management, project control, project reporting and communication—are conducted.
• Project completion—The project should have a predefined and easily identified end point to which the ERP system moves for live operations following the implementation phase.
• Derivation of benefit—After implementation, the management of the project changes in nature and transfers to the business owner who is responsible for ensuring that the required changes to user behaviour are introduced and benefits are obtained.

3.6.8 The project management of an ERP system does not differ significantly or fundamentally from the management of any other large software project. The same concepts apply in the audit of the management of an ERP system implementation:

• Perform an assessment of executive sponsorship and top management support.
• Perform an independent review and analysis of project management activities.
• Independently assess project planning and control as well as quality assurance.
• Provide management the findings regarding resolution of project issues, including time or budget overruns, functionality gaps, and staffing and skill requirement mismatches, as well as other issues relevant to the management of the project.

3.6.9 Quality management, which should be an integral part of all software projects, should not be concerned solely with the quality of the project deliverables, but should cover all activities and deliverables of the ERP projects, such as project planning, design documentation, specifications, procedures, training materials and implementation plans. The quality assurance, which should be carried out as an independent function inside the project organisation, should not be considered an audit and assurance activity. On the other hand, during the ERP system implementation, it is essential to audit the effectiveness of the quality management and the quality assurance.
3.6.10 The business case and the associated benefit realisation plan are the key focal points for the audit of benefit management. They should identify:

• The business objectives of the project and the expected benefits to be achieved. The benefits (both quantitative and non-quantitative) should be specified clearly in a benefits register. The quantified benefits should be broken down into identifiable and measurable elements.
• The planning for the realisation of the benefits and their correlation with the change management of the business processes
• The control procedures, to provide reasonable assurance of the benefits achievement

3.6.11 A benefit management audit that is conducted before the start of the ERP system implementation has the potential to yield significant benefits for a successful ERP project. A benefit realisation review should be conducted some time after the project is completed (typically 18 months).
3.6.12 Risk management is more than just the management of project risks, it is also the management of the risks that the ERP project may place on the business. The IT audit and assurance professional should be concerned with different types of risk management:

• Risk management relevant to the business processes to be reengineered
• Risk management associated with the project management; the project risks can be either:
   – Inherent, which result from the nature of the project objectives and scope
   – Acquired, which result from the selected methodologies, tools, technique, skills and experience that are applied to the project and to risk management
• Information security management during the system implementation
• Information security management that is planned for after go-live, i.e., during the system operations
• Management of the risks introduced by systems that are external to the ERP project and the risks that the ERP project can cause to third parties. Therefore, the IT audit and assurance professional should have an enterprise approach that transcends a narrow focus on the specific ERP project.

3.6.13 Organisation realignment, communication, project marketing and personnel training are the key activities for successful project management. The IT audit and assurance professional should also evaluate, in addition to the previously mentioned activities, the correlation of change management with the other critical implementation areas, especially benefit management (with regard to the benefits to achieve) and risk management (with regard to the potential resistance to change and the information security that is associated with the authorisation of persons according to their newly defined roles). Benefits derived from an ERP implementation ordinarily require that new processes to be designed into the functionality provided by the application, prior to implementation, and that users change their behaviour to suit the newly designed processes after implementation. Audit of the derivation of business benefit, therefore, will continue after the traditional ERP project has been closed.

3.7 Reporting

3.7.1 The reporting processes for stating audit opinion and/or providing audit comment on an ERP project are not inherently different from any other audit and assurance reporting processes. Some, or all, of the following reporting mechanisms may be appropriate:

• Regular summary reports to ERP project management meetings or steering committee meetings (perhaps as agenda items)
• Maintenance of a project log, tracking audit and assurance issues for clarification or control points for resolution
• Formal reports of audit and assurance opinion and outstanding issues at defined stages in the project life cycle

4. EFFECTIVE DATE

4.1 This guideline is effective for all IT audits beginning 16 September 2010.

APPENDIX

ERP Knowledge and Skill Requirements

General Elements of and Questions on ERP System Implementation

The following figure illustrates the general elements of ERP system implementation.

• What ERP product and modules are or will be used?
  - How are or will the modules be interlinked (such as, data flow across the modules)?
• What database management product(s) are or will be used?
  - How is/will the ERP system be configured with the database management system (DBMS)?
• What operating system product(s) are or will be used?
  - How have or will each be configured/implemented and controlled?
• To what level is the ERP system web-enabled?
  - What processes are being extended to the web?
• What interfaces or linkages exist/will exist to non-ERP systems internal or external to the enterprise?
• How have or will each function be controlled?
• To what extent have or will ERP functionality and controlling roles or responsibilities be centralised or decentralised?
• How was or will data integrity be controlled and tested by management during the conversion of data from old or non-ERP systems during the ERP implementation?
• To what extent was or will business processes reengineering take place during the ERP implementation project?
  - If not, why not and when will it take place?
• If so, what changes are implemented and why?
• How do the ERP and BPR projects have agreeing, common process designs?
• What IT hardware and network resources are or will be used, and how will they be configured and managed?
• To what extent are the ERP management and technical support roles and responsibilities integrated or separated from other related IT support (such as, database administration, operations)?
• What will the controls be over the change management processes for:
  - ERP application modules
  - ERP core system
  - DBMS
• What is the operating system?
• What changes will be made to address BPR?
• Other non-ERP system linkages or interfaces
• What are or will be the access security policies and standards, and who will be responsible for ongoing management control and support?
• What processes are being adopted to provide reasonable assurance that acceptance of the ERP system and transfer of ownership to user management is complete?