1. ERP Implementations: A Material Change to the System of Internal Control VASBO Winter Conference February 6, 2015

2. Agenda  Our View of Risk  Enterprise Resource Planning (ERP) Opportunities  ERP Risk and Requirements  Establishing System Requirements  Selecting a Vendor  Top 10 ERP Risks and a Few Failures  Assessment Criteria  Control Maturity Assessment  Procedures (High Level)  Go or No Go Decision Criteria  Segregation of Duties (optional)  Tips and Recommendations  Questions 2

3. Missing Opportunities, Missing Objectives, Errors and Losses Occur Primarily Because…  Unseen risk - blindsided  Unmanaged risk  Controls being relied upon, failed Note that implementing an Enterprise Resource Planning (ERP) system or other business systems may increase the chances of Organizations getting blindsided by unintended consequences. 3 Our View of Risk 39% of all projects are successful 43% are delayed 59% experience cost overruns Source: The Standish Group (2013) The Standish Group (2013)

4. Many organizations are deploying a number of strategic high profile, capital intensive IT or business projects. Large IT Project Failure Stats:  A 2012 McKinsey study revealed that 17% of IT Projects budgeted at $15m or higher go so badly as to threaten the company’s existence  More than 40% of these projects fail  The Standish Group examined 3,555 IT Projects over 9 years that had labor costs of $10m or more  Only 6.4% were successful  52% were either over budget, behind schedule or didn’t meet user expectations 4 Our View of Risk (cont.)

5. ERP Opportunities  The planned changes and implementation of an ERP are intended to improve the Organization’s enterprise risk management including:  Improving the Organization’s ability to meet its operational, financial reporting and compliance objectives.  Creating efficiencies (including cost savings) in managing Organization’s business.  Effectively safeguarding shareholder/taxpayer assets and demonstrate sound financial stewardship. 5

6. ERP Risk and Requirements  Change in Enterprise Business Systems aka ERP – the implementation of an ERP system covers most, if not all, significant business cycles and represents a material change to the Organization’s system of internal control.  Risk – Change in ERP also increases the Organization’s exposure to unintended consequences affecting many enterprise risk areas e.g., inefficiency, error and fraud until the control environment matures on the new system.  Audit Requirements – Auditing standards require External Auditors to consider changes to a client’s system of internal control. Therefore, the auditor should validate the effectiveness of key IT general controls (ITGCs) to obtain comfort over the information technology systems that house, transport, store, and transform data for reliable financial reporting. 6

7. Establishing System Requirements  Functional Requirements – Business processes that users expect to be fully, or at least partially, automated by the new system. These would include such things as three-way match, reasonableness tests for salary increases, automated purchase order management and automated budgetary performance monitoring.  Technical Requirements – Capability of the system to conform to and complement protocols inherent in the technology infrastructure. Examples would include compatibility of access control methodology with Windows Active Directory and functionality supporting seamless transition to disaster recovery mode. Also, consideration for cloud computing.  Operational Requirements – Capability to support day-to-day functions of business unit users, including certain automated workflow, user-friendly query capabilities, comprehensive audit trail of user activities and flexible reporting capabilities 7

8. How To Define Requirements  Form a task force with representatives from all stakeholder groups – this is not just an IT project  Define Requirements at a granular level  This is a bottom-up process  Make sure the Requirements reflect the real world  Make sure that the Requirements look to, and accommodate for, future growth, expansion and change 8

9. Selecting a Vendor  Experience in your Industry  Public vs. Private  Experience with organizations your size  Experience with your organizations IT infrastructure  References/Referrals  Talk to your peers  Do they meet all of your defined Requirements?  If not, what acceptable alternatives are available from this vendor?  Can they meet the defined Requirements with minimal customization?  Customizations often times = more $$$ 9

10. Selecting a Vendor (cont.)  Are third party integrators available?  Certified integrators by system  What are the vendor/integrators training capabilities?  Contract requirement  What is the total cost of implementation and fee arrangement?  Contract requirement 10

11. Top 10 ERP Risks and a Few Failures 1.A good plan or just a plan 2.Lack of alignment of ERP with business processes 3.Part time project management 4.Underestimating resource requirements 5.Decentralized decision making 6.Project complexity 7.Lack of in-house skills 8.User resistance and customization 9.Insufficient testing 10.Not enough user training  Hershey – in1999, SAP R/3 kept $100m in sales from on time delivery.  Nike – in 2000, $400m upgrade in supply change ERP lost $100m sales, 20% stock drop, class action lawsuit.  DC Govt – currently undergoing their 2 nd attempt with their 3 rd integrator at an ERP implementation 11

12. Assessment Criteria  Control Frameworks/Approaches to implement systems  COBIT Framework for ITGCs including SDLC  ISO/IEC 12207 Software Life cycle processes  IEEE (Standard setter)  PMBOK (Standards issued by Project Management Institute)  Control Maturity Models (CMM)  CMMs are used to assess control maturity for control areas using a control framework as applied to the ERP project.  We recommend tailoring the CMM to best suit the client’s needs. 12

13. Control Maturity Assessment  Municipalities – recommend using 3 levels 13

14. Procedures (High Level)  Review and test the following:  ERP Project Plan and Milestones against COBIT 4.1 SDLC  ERP Project Risk assessment and evaluation criteria affecting “go” or “no go” decisions  Future state internal control design  Conference Room Pilots (CRP)  Training  Systems Acceptance Testing (SAT)  Systems Integration Testing (SIT)  User Acceptance Testing (UAT) and training  Interface Testing  Data Conversion Testing, Data Migration & System Cutover  Key report testing  Defects, issues, errors and remediation  Business cycle transaction walk-throughs and expected results  Mock financial close testing (Monthly and Annual) 14

15. GO or NO GO Decision Criteria  Training (% complete)  Testing (% complete)  Issues/Defects log – P1, P2, P3 etc.  Issues/Defects log (% complete)  System’s environmental readiness  Data conversion  Change management  System requirements  Human capital  Communication plans  staff, customers, vendors, business partners etc. 15

16. Segregation of Duties (optional)  Segregation of Duties (SOD) and system based logical access controls  Review and inspect evidence of ERP project team’s self- assessment procedures to determine future state internal control design requirements.  Review internal control design for planned pre “go-live” user provisioning, periodic access review, configuration change management for authorization levels and workflow routing such as, purchase requisitioning. 16

17. ERP Opportunities  The planned changes and implementation of an ERP are intended to improve the Organization’s enterprise risk management including:  Improving the Organization’s ability to meet its operational, financial reporting and compliance objectives.  Creating efficiencies (including cost savings) in managing Organization’s business.  Effectively safeguarding shareholder/taxpayer assets and demonstrate sound financial stewardship. 17

18. Tips and Recommendations  Ensure “Test” environment reflects expected production environment.  Use of cloned production data vs. dummy data  Just because it worked in “Test”….  Performance is slow….  Risks/Rewards with “train the trainer” approach…  Procurement cycle internal controls (highest risk)  Matching controls, GL coding etc…  ERP Module inter-dependencies  Key report testing…  Mock financial close training and testing…  “We have a workaround for that…”  Post go live production support plan (60 days starting when?)  Anticipating ERP Project team and internal employees turnover… 18

19. Questions Contact: Neal W. Beggan | Principal – Risk Advisory Services nbeggan@cbh.com | 703.584.8393 Cherry Bekaert LLP cbh.com 19