Why ERP Implementations Fail: UNBIASED (3 of 6)

Why ERP Implementations Fail: UNBIASED (3 of 6)

in Blog Article by Jeff Hare

The definition of insanity is doing the same things over and over again but expecting different results”. I am writing this six-part article series about Why Implementations Fail – to help you avoid a failed or a ‘less than optimal’ implementation. In part 1 and part 2 we have covered the following two topics: 

  1. Software is often released before it is mature 
  2. System integrators rarely propose a complete ERP implementation 

If you missed either or both articles, I encourage you to do so.  

The Six Biases in ERP Implementations 

To achieve a successful ERP implementation, you must overcome these six common biases: 

  1. Software is often released before it is mature 
  2. System integrators rarely propose a complete ERP implementation 
  3. System integrators do not understand the complex compliance and cyber security requirements for today’s modern systems 
  4. Compliance and cyber security requirements are often misunderstood by software engineers 
  5. SaaS application software providers tend to be greedy with system storage because it affects their margins 
  6. Auditors are often not trained on the specifics of the ERP system they are auditing. 

Why Compliance and Cybersecurity are Overlooked 

The primary goal of a system integrator is to help your organization go-live, on time, with the agreed upon functionality. Most are experts at implementation methodology and the functionality they are implementing. So, what are the complex compliance and cyber security requirements facing management as you implement and maintain your ERP system?  

If you are a publicly traded company subject to Sarbanes-Oxley requirements or similar requirements in your country, compliance is not optional. There are also commonly one or more data privacy regulations, such as GDPR or CCPA, that need to be considered. 

No ERP implementation is the same, which means a cookie cutter approach to implementation, and configuration – or management’s requirements – will not work.  

In our experience, the traditional risk advisory approach to identifying, mitigating, and managing risks is broken. Most risk advisory firms provide very little, if any, training for their teams on risks specific to a given ERP system, even those for which they are providing advisory services. This often means the risk population is incomplete [Read More on this topic here and here] 

The primary system implementation firms get even less training than their risk advisory counterparts related to risks and controls. Securing the system is left to the risk advisory teams, which causes most implementations to fail compliance and cyber security requirements. 

In some implementations, management attempts to be the risk advisory team, by not hiring an external risk advisory partner.  

Commonly, implementations lead to one or more Significant Deficiencies from external auditors. 

 There are two types of Significant Deficiencies that we are often engaged to address after go-live – usually identified by management or external auditors.  

If you are not familiar with what a “Significant Deficiency” is, here is the definition from the PCAOB: 

A Significant Deficiency is a deficiency, or a combination of deficiencies, in internal control over financial reporting that is less severe than a material weakness, yet important enough to merit attention by those responsible for oversight of the company’s financial reporting. (link) 

Two types of Significant Deficiencies are especially common. 

The first is related to role design, where users are overprovisioned (people have unauthorized access to too much) or have access to override controls. The ability to override controls can be from many sources such as: 

  • Improperly designed workflows 
  • Ability to disable workflows or change the workflow design 
  • Ability to override workflows via conversion processes, interfaces process, APIs, web services, and changes to configurations on which the workflow design depends 

The second most common Significant Deficiency is related to Change Management. This control deficiency is characterized by a poorly designed Change Management process resulting in: 

  • A lack of clarity about what is / is not subject to the change management process 
  • End users or unauthorized IT users having access to configurations that are subject to the change management process 
  • Changes being made where no ticket is logged and/or approved 
  • Lack of documentation for the testing of the change 
  • Unauthorized changes  

SaaS ERP Systems and the Cybersecurity Blind Spot 

Switching to the topic of cyber risks for SaaS applications, I’ll refer you to our article on this topic (link). 

As of the writing of this article, we are the only firm that is helping management identify, mitigate, and manage risks for these internet-facing applications. Traditional cyber security firms do not have the deep domain expertise required to understand the risks in each of the major ERP systems which include: 

  • SSO configurations 
  • MFA configurations 
  • Password configurations 
  • Administrative access via roles and privileges 
  • Authentication methods 
  • Firewall configurations 
  • Phishing vulnerabilities 

Many organizations also fail to monitor key logs or integrate them into a SIEM system, which makes it nearly impossible to detect suspicious activity in real time.  

For SaaS applications, management and auditors are relying solely on the SOC 2 report from the software provider. In the SaaS environment, Identity and Role Design is the new perimeter as we discuss in this article (Why Identity and Segregation of Duties Are the New Perimeter), as SaaS applications are internet facing, and therefore, there is no true ‘perimeter’.  

Beyond this, management has not identified a population of changes nor implemented any quality assurance over their change management process (IT governance). One of our most common recommendations to management is to develop and document IT governance processes and verify they are being followed by having a robust IT quality assurance function. We rarely see this implemented during a project, let alone after the system has gone live. 

Why You Need a Separate Risk Advisory Firm  

We have covered the main complex compliance and cyber security requirements facing your organization in today’s ERP systems. You are probably asking, are there firms that can provide the necessary resources? Should you hire a large system integrator like a Big 4 firm or another large international system integrator? There are pros and cons to this. Generally, we find the larger the firm, the less quality the resources and the more turnover. 

However, I would like to address why we believe that you shouldn’t hire the same firm to be your system integrator AND your risk advisory firm. The team acting as your risk advisory firm needs to help management decide if your implementation is ready to meet all compliance and cyber security requirements. The risk advisory firm should be your independent check and balance versus your system integrator that asks the questions: 

  • Have we identified and documented our compliance and cyber security requirements? 
  • Have we addressed the risks and implemented proper controls? 
  • Are we prepared to defend management’s assessment of risk, control design, and operating effectiveness of our controls to our auditors and regulators? 

Your risk advisory firm should be advocating for your organization by helping management throughout the project – from requirements, to design, to testing, to go/no go decision.  

Let’s say you hire a risk advisory from a large SI and hire the same firm to do your implementation work. If your core SI team has not done the work required to prepare for a successful audit, do you think their risk advisory peers are going to tell you that their colleagues haven’t held up their end of the bargain? To expect the risk advisory team to throw their peers under the bus is the same as asking the fox to watch the hen house. 

Presumably, you have read one or more of the case studies of failed ERP implementations. In every failed implementation, either management willingly decided to go live with too much risk or did not fully understand the risks at hand. 

Because of the inherent conflict of interest between the SI practice and the risk advisory practice, we do not recommend these being the same firm. 

Final Thoughts: Rethinking How You Choose Partners  

Tying this back to the central theme of this article – System integrators do not understand the complex compliance and cyber security requirements for today’s modern systems. 

We have long advocated for management to choose a different risk advisory firm from the core system integrator. However, this is not normally the case. Management often buys into the notion that there will be synergies and lowers costs because of having the same firm do the work. While this is often not true, it makes for a good story for the Sales folks from these large SIs. 

The net result on most projects is that the fox is hired to watch the hen house, and the project does not fully address the complex compliance and cyber security requirements. 

The right solution is to hire a risk advisory firm that is different from your core system integrator. Additionally, it is critical that the risk advisory firm you hire has expertise in the system you are implementing. 

If you would like to discuss this approach in more detail, contact us at sales@erpra.net to schedule a consultation. 

Share this post:
ERPRA Become Our Partner

Please select your preferred datasheet and download it: