ERP IMPLEMENTATION RISK - PDF Free Download

Speaker Kari Sklenka-Gordon National RSM ERP Risk Advisory Leader 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

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? 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 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 General project governance activities: Budget/ appropriate capitalization of costs/ timeline 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 Accurate business requirements documented Accurate business requirement mapping to new ERP capabilities Testing of business requirements Effective communication between the project team and everyone else on the project or in the business End user training aligned to security model designed 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

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 ERP Implementation failure rate is 75% Gartner 8

What is ERP implementation risk? 9

Typical ERP Implementation project phases Planning Business case and purpose for new ERP Select ERP Determine budget & timeline Determine implementation strategy Design Build & validate 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 Deployment System freeze Cut over activities (data migration, final configurations for go live, etc.) End user training Go live 10 Post go live Run state operational use of new ERP Regulatory controls testing

Impact of risk factors at each ERP implementation phase ERP Implementation Phases 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 Organizational change management X X X X X X X X X X Operations X X X X X Risk occurs during each phase of an ERP implementation 11

Where do we find ERP implementation risk? 30% ERP Implementation Risk 25% 20% 15% 10% 5% 0% Project Governance Regulatory, Security & Controls Data Technology Business Requirements Organizational Change Management Operations 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 map 13

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 Risk identification method Vendor contract assessment Health check assessment Results 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. Possible risk mitigation strategies Implementation Strategy & Deployment Methodology Review Vendor Contract Review Project Plan Review 17

ERP implementation risk: Business requirements 18

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 Risk identification method Performed a project Health Check Results 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 Possible risk mitigation strategies Project documentation strategy assessment Project plan assessment Project implementation strategy assessment Project resource assessment 20

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 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 23

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 Risk identification method Results Possible risk mitigation strategies 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 26

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 Risk identification method Post go live FDA validation assessment performed by FDA Results 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 Possible risk mitigation strategies FDA validation risk assessment prior to go live Project plan review for adequate time for end user training 28

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 Risk identification method Post go live controls design assessment Results 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 Possible risk mitigation strategies Business process risk assessment Controls design assessment during the project design phase Controls operation assessment during the project validation/testing phase 30

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 Risk identification method Post go live security controls assessment by external auditors Rules Assessment Analysis by internal auditors Results 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 Possible risk mitigation strategies Implement GRC tool during the implementation before the security roles are built Perform a GRC tool security and SOD rules assessment to identify missing nonstandard security transactions 32

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 Risk identification method Post go live security assessment Results 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 Possible risk mitigation strategies Project plan assessment End user training development strategy assessment Future state security model understanding and assessment 35

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 Risk identification method Results Possible risk mitigation strategies Post security vulnerability assessment Client off shored most IT support to several 3 rd party vendors. Critical bath programs were never identified Batch program ownership was not clearly documented before offshoring 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 3 rd party SLA s containing critical system ITGCs such as batch program monitoring 38

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 golive. 40

Case Study: Technology risk Risk identification method Assessment of the future state technology landscape compared to current state Review of business process flow charts identified the interfaces Results 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 Possible risk mitigation strategies Current state technology landscape review prior to signing new software contract Good business flow chart documentation prior to starting the implementation 41

Case Study: Technology risk 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

Case Study: Technology risk Risk identification method Postimplementation security & controls risk assessment Results 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 Possible risk mitigation strategies Security & controls design assessment Security & controls operating assessment 43

ORGANIZATIONAL VIEW OF ERP IMPLEMENTATION RISK ACCOUNTABILITY 44

Typical organizational view of ERP implementation risk (governance, risk, controls and security) Business Process Risk Assessment to identify risk and key control objectives Regulatory (i.e. SOX, PCI, FDA) controls business process risk assessment Future State Controls (CFO/IA) Regulatory ITAC/ Automated Process Controls Non Regulatory ITAC/ Automated Process Controls Regulatory IT Sensitive Access and SODs Regulatory IT Dependent Manual Regulatory Manual Business Controls Regulatory ITGCs including Project Development ITGCs Operational ITGCs GRC Technology Optimizations (CFO/IA/ERM/CIO) ERP GRC tool usage Data analytics techniques and tools 45 Implementation Project Governance Risk (Project Leader/Business/ CIO) Software Vendor Contract Project Governance Implementation Success Factors Organizational Change Management Business Requirements Data Technology IT Security Governance Risk ERP Security, Cyber Security (CISO/CIO/CFO) Critical infrastructure cybersecurity controls and IT operations security controls Security Vulnerability Management Security design model alignment with new HR job titles

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

RSM US LLP Address City Phone +1 800 274 3978 www.rsmus.com 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 registered trademark of RSM US LLP. 2016 RSM US LLP. All Rights Reserved.