erp implementation risk - rsmus.com · “inventory actual does not match what’s in our new...

©2015 RSM US LLP. All Rights Reserved. ©2016 RSM US LLP. All Rights Reserved.

ERP IMPLEMENTATION RISKKari Sklenka-Gordon, Director at RSMNational ERP Risk Advisory Leader

March 2017

©2015 RSM US LLP. All Rights Reserved.

Speaker

• 18+ years working with SAP and other ERPs

• 16+ years in security, controls, risk & IT governance

• 10+ years in public accounting

• Team member of 35+ ERP implementations

2

Kari Sklenka-GordonNational RSM ERP Risk Advisory Leader


Agenda

• ERP implementation success factors• ERP implementation risk overview• ERP implementation risk deep dive

− Risk assessment approaches− Risk mitigation approaches− Case studies

• Organizational accountability view of ERP implementation risk

• Summary

3


ERP IMPLEMENTATION SUCCESS FACTORS

4


ERP implementation success factors

5


What are ERP implementation success factors?

• Pre planning activities such as:• Resource strategy (vendor led/ or internal) • ERP software selection• ERP implementation vendor selection &

contract signing• Selection of ERP deployment methodology

• ERP effectively designed to meet the needs of the business• Future state technology landscape including interfaces• Adequate infrastructure to meet performance demand• Awareness of any new software functionality releases• Business Continuity Planning/ Disaster Recovery

• Correct data classification, cleansing, mapping, migration

• Regulatory requirements /controls (SOX, PCI, FDA, etc.)• Data privacy / European union general data protection regulation• Utilization of new ERP to support controls automation• Security roles designed free of segregation of duties conflicts• Cybersecurity related controls / COBIT controls

• Effective communication between the project team and everyone else on the project or in the business

• End‐user training aligned to security model designed

• Post‐go‐live support addresses needs

• 3rd party SLA’s adequate to support new ERP

• Balancing of other company priorities that could impact project team members

• Accurate business requirements documented

• Accurate business requirement mapping to new ERP capabilities

• Testing of business requirements

• General project governance activities:• Budget/ appropriate capitalization

of costs/ timeline


ERP IMPLEMENTATION RISK OVERVIEW

7


What went wrong?

“The implementation cost twice as much as the original budget”

“We didn’t see the realized value of the ERP implementation afterwards”

“We failed our SOX controls, resulting in a material weakness”

“Users didn’t have the access to do their job after go-live”

“Duplicative customers are found in the new ERP system”

“We rushed through the implementation to meet initial goals, which resulted in a system with a lot of problems at go-live”

“Inventory actual does not match what’s in our new ERP”

8

ERP Implementation failure rate is 75% ‐ Gartner


What is ERP implementation risk?

9


Typical ERP Implementation project phases

10

Planning

Design

Build & validate

Deployment

Post go‐live

• Business case and purpose for new ERP• Select ERP• Determine budget & timeline• Determine implementation strategy

• Fit gap‐analysis• Business requirements • Data cleansing• Future state IT landscape (interfaces)• Controls Design• Security role structure design

• Configure/Code system• Perform testing (unit, system, integration, UAT, performance, controls, security)• System role design• End‐User Training Development

• System freeze• Cut‐over activities (data migration, final configurations for go‐live, etc.)• End‐user training• Go‐live

• Run‐state operational use of new ERP• Regulatory controls testing


Impact of risk factors at each ERP implementation phase

11

Risk occurs during each phase of an ERP implementation

Planning Design Build &Validate

Deployment Post‐go‐live

Project governance X X X X X

Business requirements X X X X X

Data X X X X X

Regulatory requirements, security, controls X X X X X

Organizational change management X X X X X

Operations X X X X X

ERP Implementation Phases


Where do we find ERP implementation risk?

0%

5%

10%

15%

20%

25%

30%

ProjectGovernance

Regulatory,Security &Controls

Data Technology BusinessRequirements

OrganizationalChange

Management

Operations

ERP Implementation Risk

12


Assessing ERP implementation risk findings

• If possible, use your company’s ERM risk score card

• If your company does not have an ERM practice, design a risk score card that works for your culture, regulatory requirements, company size, financial size, and nature of the implementation− Most score cards use the 1-5 scoring system

• When issues are identified, risk should be viewed as − impact to project and − impact to COMPANY after go-live before assigning a risk

rating• Communication of issues are best illustrative using

a heat map13


ERP IMPLEMENTATION RISK DEEP DIVE

14


ERP implementation risk: Project governance

15


Case Study: Project governance risk

Issue:• Midway through the ERP implementation,

COMPANY thought they were getting less than they signed up for from their implementation vendor. They sited communication issues, delays, and budget overages.

16


Case study: Project governance risk

17

Risk identification

method

Results Possible risk mitigation strategies

• Vendorcontract assessment

• Health check assessment

• COMPANY signed‐up for implementation tasks they shouldn’t have been responsible for, because those responsibilities typically were vendor responsibilities.

• Vendor was not accountable for tasks it should have been responsible for.

• There was a lack of a project plan with dependencies. The project plan that existed was aggressive.

• COMPANY pushed go‐live out one quarter, renegotiated the remaining contract with the implementer, and go the project back on track.

• ImplementationStrategy & Deployment Methodology Review

• Vendor Contract Review

• Project Plan Review


18

ERP implementation risk: Business requirements


Case study: Business requirements risk

Issue:• Significant amount of testing exceptions found

during end-user testing just before go-live. Caused project go-live to be delayed.

19


Case study: Business requirements risk

20

Risk identificationmethod


• Performed a project Health Check

• Resources from the COMPANY didn’t have a good understanding of COMPANY business requirements

• Resources from the implementation vendor, didn’t have a good understanding of the ERP

• Fit‐Gap analysis, design documents, process flows, narratives, and other critical documents were not fully completed, but testing was being performed on the system.

• Although the timeline overall appeared to be on schedule, 90% of the completed tasks had serious quality issues that would directly impact the testing phase.

• Project go‐live date was reset for a future date

• Project documentation strategy assessment

• Project plan assessment

• Project implementation strategy assessment

• Project resource assessment


ERP implementation risk: Data

21


Case study: Data risk

Issue:A material misstatement was found from inventory and sales being incorrectly under and over stated several years after an ERP implementation.

22


Case study: Data risk

23

Risk identification method Results Possible risk mitigation strategies

• Key report controls testing for data accuracy and completeness

• Client data was incorrectly mapped from a non‐ERP system to ERP for an implementation

• No evidence was retained of the user signed off of the mapped data

• Data errors resulted in a material weakness

• Assessment of data cleansing, migration, testing strategies


ERP implementation risk: Regulatory requirements, security & controls

24


Case study: Regulatory requirements risk

Issue:Data was deleted after an ERP go-live resulting in a material misstatement.

25


Case study: Regulatory requirements risk

26


• Post‐go‐live SOX controls assessment

• A critical setting in an ERP was not enabled after go‐live.

• Data deletion programs were run.

• Accountants had been running the data deletion programs to eliminate journal entries because of its easy of use.

• Resulted in a material misstatement

• Pre‐go‐live checklist of critical controls

• Immediate assessment of critical controls post‐go‐live


Case Study: Regulatory requirements risk

Issue:• FDA shut down a plant location after finding that

users were not using the new ERP system as documented.

27


Case Study: Regulatory requirements risk

28



• Post‐go‐live FDA validation assessment performed by FDA

• Company upgraded their ERP system with all critical business tasks moved from manual excel/post it note based, to system based

• Change management and training was not clear to users in how they would do their job in ERP post‐go‐live. Users continued using manual outside the system processes even though training documentation supported new in system processes

• FDA performed a post‐go‐live audit and found tasks being performed out‐side the system, not inline with new training documentation resulting in fines and shut down of operations for a period of time

• FDA validation risk assessment prior to go‐live

• Project plan review for adequate time for end user training


Case Study: Controls risk

Issue:• After company went live with new ERP, it only

leveraged automated system functionality for 10% of the business process controls. Industry comparison for the same industry and same ERP was more around 50-60%.

29


Case Study: Controls risk

30



• Post‐go‐live controls design assessment

• Upon further assessment of the automated process controls, it was noted that standard functionality was not enabled for the controls because they were not called out as business requirements

• COMPANY later improved controls automation landscape to 50%, but the cost was more significant than it would have been had the controls been designed during the project

• Business process risk assessment

• Controls design assessment during the project design phase

• Controls operation assessment during the project validation/testing phase


Case Study: Security controls risk

Issue:COMPANY had several unmitigated security segregation of duties issues identified by their external auditors after go-live. COMPANY had a GRC tool installed and didn’t think they had any segregation of duties issues not mitigated.

31


Case Study: Security controls risk

32



• Post‐go‐livesecurity controls assessment by external auditors

• Rules Assessment Analysis by internal auditors

• COMPANY selected a new GRC tool AFTER the go‐live of their new ERP

• COMPANY did not perform a security rules assesmsent and just enabled the vendor’s out of the box rules

• The rules assessment analysis reveled custom functions, over 150 missing standard functions, not added to the rules

• To resolve the new additional security issues, the security roles had to be redesigned on a newly implemented ERP after go‐live

• Implement GRC tool during the implementation before the security roles are built

• Perform a GRC tool security and SOD rules assessment to identify missing non‐standard security transactions


ERP implementation risk: Organizational change management

33


Case study: Organizational change management risk

Issue:ERP was upgraded. After go-live, end-users were complaining the security in the system wasn’t correct. The help desk was over loaded with requests for changes.

34


Case study: Organizational change management risk

35



• Post‐go‐live security assessment

• Several security changes occurred close to the time the end‐users were being trained.

• The end‐user training was not adequately updated to reflect those changes. So the end‐users were not aware of the security changes and the impact to their role as compared to how they performed their role in the old ERP system

• Upon further assessment, it was determined the security was designed appropriately, it was the end‐user training that needed to be enhanced, updated and the end‐users than retrained

• Project plan assessment

• End‐user training development strategy assessment

• Future state security model understanding and assessment


ERP Implementation Risk: Operations

36


Case Study: Operations risk

Issue:IT environment was complex with lots of interfaces. A virus hit the entire system, 6 months after an ERP was implemented to support the financials. IT took the system off-line until virus was removed. When systems were brought back on-line, data was restored from the day prior to the virus hitting.Several weeks of financial data were overwritten and lost after the incident.

37


Case study: Operations risk

38


• Post security vulnerability assessment

• Client off‐shored most IT support to several 3rd party vendors.

• Critical bath programs were never identified

• Batch program ownership was not clearly documented before off‐shoring the IT support responsibility.

• Investigation found that the back‐up batch programs stopped working properly the week before the virus had hit. When the new system was restored, the batch programs were pointing to empty folders of data that had been over‐written upon the restore.

• Data was unable to be retrieved since it was over written.

• Financial audit issues were a result of the incident

• Critical batch programs identified

• 3rd party SLA’s containingcritical system ITGCs such as batch program monitoring


ERP Implementation Risk: Technology


Case Study: Technology risk

Issue:• Initial interface budget was for 10. Mid-way

through the project, a total of 250 interfaces were identified. Building and testing the additional interfaces significantly increased the implementation cost, and reset the planned go-live.

40



41



• Assessment of the future state technology landscape compared to current state

• Review of business process flow charts identified the interfaces

• The future state technology landscape was missing a lot of interfaces because the current IT system landscape documents had not been kept up to date

• COMPANY incurred additional budget costs before go‐live to design and test the interfaces forgotten about

• The go‐live of the project was delayed

• Current state technologylandscape review prior to signing new software contract

• Good business flow chart documentation prior to starting the implementation



Issue:Implemented ERP total project cost, was close to three times the initial budget and it was taking a significant amount of unplanned resources to keep the system up and running.

42



43



• Post‐implementation security & controls risk assessment

• A post‐implementation review conducted demonstrated that custom security t‐codes were twice as much as should have been there. Also the most basic automated controls were not enabled

• During the implementation the client was told often that standard functionality didn’t exist to meet their requirements.

• This uncovered that the implementers either didn’t have the skills or understanding of the standard system functionality and had falsely guided the client that they needed “custom” development to “standard” ERP functionality, or they guided the client to implement the custom functionality to increase their fees.

• Turned into a lawsuit with implementers

• Security & controls design assessment

• Security & controls operating assessment


ORGANIZATIONAL VIEW OF ERP IMPLEMENTATION RISK ACCOUNTABILITY

44


Future State Controls (CFO/IA)

Typical organizational view of ERP implementation risk(governance, risk, controls and security)

45

Regulatory ITGCs including

Project Development

ITGCs RegulatoryIT‐Dependent

Manual

RegulatoryIT Sensitive

Access and SODs

Implementation Project Governance Risk

(Project Leader/Business/ CIO)

Business Process Risk Assessment to identify risk and key control

objectives

Regulatory Manual Business

Controls

Project Governance

IT Security Governance Risk ERP Security, Cyber Security

(CISO/CIO/CFO) Software Vendor Contract

GRC Technology Optimizations

(CFO/IA/ERM/CIO)

ERP GRC tool usage

Data analytics techniques and tools

Non‐Regulatory

ITAC/ Automated Process Controls

Critical infrastructure cybersecurity controls and IT operations security

controls

Security Vulnerability Management

Security design model alignment

with new HR job titles

Data

Regulatory ITAC/

Automated Process Controls

TechnologyOrganizational Change

Management

Business Requirements

Implementation Success Factors

Regulatory (i.e. SOX, PCI, FDA) controls

business process risk assessment

Operational ITGCs


SUMMARY

46


In summary

• Project risk can happen at any point of an ERP implementation life cycle, including before the project starts

• Project risk cannot always be prevented but it can be identified, monitored, and mitigated before it results in significant post-go-live issues

• Project risk is real and can directly impact investment dollars before and after and implementation

47


This document contains general information, may be based on authorities that are subject to change, and is not a substitute for professional advice or services. This document does not constitute audit, tax, consulting, business, financial, investment, legal or other professional advice, and you should consult a qualified professional advisor before taking any action based on the information herein. RSM US LLP, its affiliates and related entities are not responsible for any loss resulting from or relating to reliance on this document by any person.

RSM US LLP is a limited liability partnership and the U.S. member firm of RSM International, a global network of independent audit, tax and consulting firms. The member firms of RSM International collaborate to provide services to global clients, but are separate and distinct legal entities that cannot obligate each other. Each member firm is responsible only for its own acts and omissions, and not those of any other party. Visit rsmus.com/aboutus for more information regarding RSM US LLP and RSM International.

RSM® and the RSM logo are registered trademarks of RSM International Association. The power of being understood® is a registeredtrademark of RSM US LLP.

© 2016 RSM US LLP. All Rights Reserved.

RSM US LLP

AddressCityPhone

+1 800 274 3978www.rsmus.com

erp implementation risk - rsmus.com · “inventory actual does not match what’s in our new...

Documents