Mitigating the Unique Risks of Accelerated ERP Implementations

download Mitigating the Unique Risks of Accelerated ERP Implementations

If you can't read please download the document

  • date post

    01-Dec-2014
  • Category

    Business

  • view

    313
  • download

    2

Embed Size (px)

description

The benefits of a rapid ERP implementation are enticing. Rather than spending months defining business processes and considering myriad features and options available in the software, ERP customers agree to accept standard, predefined business processes preconfigured by the system integrator. Due to the high cost and risks inherent in a major ERP implementation, rapid implementation approaches are now becoming more mainstream. This white paper discusses the implications from both a project risk management and internal controls perspective that must be considered and addressed by organizations embarking on this type of project. Related: http://www.protiviti.com/en-US/Pages/ManagingApplications.aspx http://www.protiviti.com/en-US/Pages/Application-Controls-Effectiveness.aspx http://www.protiviti.com/en-US/Pages/Application-Security-and-SoD.aspx http://www.protiviti.com/en-US/Pages/GRC-Implementation.aspx

Transcript of Mitigating the Unique Risks of Accelerated ERP Implementations

  • Mitigating the Unique Risks of Accelerated ERP Implementations

  • PRotIvItI MItIgAtIng thE UnIqUE RIsks of AccElERAtEd ERP IMPlEMEntAtIons 1

    IntroductIon

    For years, system integrators have sought to differentiate themselves in the enterprise resource planning (ERP) services space by marketing preconfigured industry templates and accelerated implementation methodologies intended to help greatly reduce the cost, complexity and duration of implementations.

    The benefits of a rapid ERP implementation are enticing, of course. Rather than spending months defining business processes and considering myriad features and options available in the software, ERP customers agree to accept standard, predefined business processes preconfigured by the system integrator. Often, implementation templates are tailored to specific industries, such as consumer packaged goods or life sciences, and are described as incorporating many business process or compliance requirements specific to those industries.

    Benefits of rapid implementation are driven through changes to traditional ERP implementation methodology. Due to the limited degree of customization, system integrators plan for much less time in the up-front design phase. In addition, the system integrator will plan limited time for building technical objects such as custom reports, forms and interfaces, since it is assumed the capabilities provided by the preconfigured solution are sufficient. Rapid ERP implementations also seek to compress the overall timeline by assuming that portions of critical streams of work, such as testing, training and data conversion, are executed in parallel.

    For years, many ERP buyers were skeptical of the purported benefits of accelerated implementation approaches. However, as the ERP market has matured, numerous success stories and case studies, illustrating the potential benefits of accelerated ERP implementations, have emerged. Due to the high cost and risks inherent in a major ERP implementation, rapid implementation approaches are now becoming more mainstream. But there are significant implications from both a project risk management and internal controls perspective that must be considered and addressed by organizations embarking on this type of project.

    ImplIcatIons For rIsk management and Internal controls

    Compressed Design Phase

    Historically, the early blueprinting stages of an ERP implementation have involved the design or re-engineering of business processes. Flow charts are often produced to provide a basis for documenting the functional and technical requirements necessary to implement the new processes. However, in an accelerated implementation model, the review of system requirements is dramatically shortened, as it is assumed the company will adopt standard, predefined business processes. Typically, the system integrator will perform demonstrations of the preconfigured processes, and it is assumed that, unless major gaps are uncovered, the process will be accepted as is.

    One side effect of a compressed design phase is the limited time available for thoughtful consideration of internal controls and compliance requirements. It is essential to note that some companies are mandated (by

  • PRotIvItI MItIgAtIng thE UnIqUE RIsks of AccElERAtEd ERP IMPlEMEntAtIons 2

    the Sarbanes-Oxley Act, the Federal Information System Controls Audit Manual, etc.) to manage financial risks and industry compliance regulations (the U.S. Food and Drug Administration, the International Traffic in Arms Regulations, etc.). Failure to deliver a system addressing the necessary compliance requirements can result in regulatory exposure and the need to perform significant rework after the new system is deployed. Unfortunately, business process owners are ill-equipped in the design phase to highlight gaps in requirements and controls because they are still in the process of learning the software. Additionally, the functionality demonstrations performed by the system integrator during a compressed design phase typically focus on core out-of-the-box functionality and do not address controls or compliance requirements. It is also difficult to understand the assumptions the vendor has made in its pre-configured solution regarding settings, features, and options in the software that may have internal controls impacts. Effective implementation of the three-way match control in SAP, for example, requires consideration of up to seven different parameters and tolerances in order for the system to work effectively. In a rapid implementation, it is likely the implementer has made assumptions about a number of these settings and perhaps, hundreds more.

    To mitigate the risk of an ERP solution with insufficient internal controls, it is important to have an advocate for internal controls (the controls team) aligned with and participating in the project. This team helps ensure that internal controls are considered and built into the ERP application across all business processes and technical components enabled by the ERP system. In smaller projects, internal audit may assume this role in a part-time, consultative capacity. On larger implementations, it is common to have an internal controls work stream composed of multiple dedicated resources.

    These resources work to develop a vision and an understanding of the end-state control environment, and collaborate with the implementation team to map and reconcile historical risks and controls to the to be business processes. These resources also play a key role in educating the business and the system integrator about the specific configurable features and options in the software that may be implemented to achieve control objectives. In addition, the controls team may be involved in responding to external auditors expectations with regard to business, financial reporting, and controls impacts resulting from an implementation. If possible, requirements for internal controls should be identified in the documentation produced by the ERP project team during the design phase, to help ensure it is accountable for delivering these controls in subsequent phases.

    Limited Process and Control Documentation

    In the past, flow charts and other documentation produced during an ERP system implementation often had value after the project. For example, these deliverables can provide a basis for updating an organizations financial compliance and audit documentation. However, this has proven to be less true with accelerated ERP implementations. System integrators typically bring generic flow charts and process documentation to an accelerated implementation, with limited expectations about tailoring it to a customers specific environment.

    The impact of this issue is that deliverables produced by the project may inadequately document the end-state business processes and associated risks and controls. Buyers of ERP systems therefore should clearly identify expectations about the creation and customization of system integrator-provided documentation in their contracts. The internal controls team on the project may need to assume responsibility for understanding the impact to compliance documentation and providing resources to make the necessary updates.

    To mitigate the risk of an ERP solution with insufficient internal controls, it is

    important to have an advocate for internal controls (the controls team) aligned with

    and participating in the project.

  • PRotIvItI MItIgAtIng thE UnIqUE RIsks of AccElERAtEd ERP IMPlEMEntAtIons 3

    Less-Structured System Testing

    Typically, on a traditional project, both functional and technical requirements are formally documented. This makes it possible to map requirements one by one to test scripts to ensure all requirements are adequately tested. Under this approach, internal control requirements, compliance requirements, negative testing, and other exception conditions can be called out as specific testable elements in the system (e.g., The system must provide a delegation of authority functionality for approval of purchase orders.). The mapping of these requirements to test scripts can provide management with some degree of assurance that the necessary functionality has been built and tested.

    However, Protivitis experience with accelerated, template-driven ERP implementations is that system integrators tend to employ a scenario-based testing approach rather than a requirements-based testing approach. Under the former, the project team defines and tests a number of business scenarios that are defined at a higher level (e.g., Create a Purchase Order). There is not an explicit mapping of business requirements to scenarios, and the completeness of testing is often left to the judgment of the consultants and business process owners.

    The drawback of a scenario-based testing approach is the increased risk that system functionality and internal controls are not fully tested. Functional testing of internal controls requires simulation of exception conditions and unusual business events that may be overlooked by the system integrator due to the compressed timeline and informal approach to testing. During one recent SAP implementation review performed by Protiviti, we noted that more than 70 percent of the system-based internal controls requirements identified by the business were not explicitly tested through the scenario-based testing approach employed by the system integrator.

    Mitigation of this risk involves tracking the ERP project teams implementation and testing of internal controls. The role of the controls team as it relates to addressing this risk includes:

    Mapping internal controls to the associated ERP test scripts developed by the implementation team.

    Reviewing the execution of ERP test scripts to help