Tier I ERP systems are generally more robust, complex, and as a result, more difficult to implement than Tier II counterparts. SAP implementations, in particular, get a bad rap because of the large, high-visibility companies that have tried and failed to implement SAP. Marin County is the most recent example of a company that failed with its SAP implementation. In addition, the media has covered the SAP failures of Hershey, Waste Management, and Shane Company in great detail in recent years.
So what is it about SAP and other Tier I ERP implementations that make them so risky and subject to failure? First of all, it is important to debunk the myth that SAP or other Tier I ERP implementations are more likely to fail than Tier II or SaaS counterparts. Our research data shows that there is very little correlation between specific software packages and their failure rates. In other words, different ERP vendors do not have materially different levels of ERP implementation success and failure.
Which brings us to a second point: while it does matter what software you choose in that you want a solution that fits your specific business needs, you are just as likely to experience problems if you don’t handle the implementation correctly. Even an ERP system that is a perfect fit for your organization isn’t going to be implemented smoothly if appropriate measures aren’t taken. In our work as expert witnesses in ERP lawsuits, we have found that mistakes and failure points are fairly consistent across various ERP systems and have very little to do with the software itself.
Having said all of that, there are some things that make SAP, Oracle eBusiness Suite, and other Tier I ERP solutions more difficult and risky. The good news is that those risks can be mitigated once you understand them.
Top 3 SAP Implementation Risks
- Complexity. As we’ve outlined in our Clash of the Titans report comparing SAP vs. Oracle, both leading ERP vendors are complex compared to Tier II counterparts. They both have extremely broad, deep, and integrated functionality designed for a variety of industries, which is generally a good thing, but it’s very easy to get tangled up in the web of complexity. One change to a single aspect of your master data can have profound impacts on your end-to-end business process flows. This can be overwhelming, especially if your implementation team doesn’t have the necessary technical and functional experience.
- Degree of Change. Most companies that implement SAP or Oracle EBS are not migrating from one robust and sophisticated ERP system to another; instead, they are going from fairly primitive business processes and business software to something much more powerful. Think of a 16-year-old that is just learning to drive: he isn’t going to handle a high-performance racing vehicle well if he hasn’t even mastered driving a Ford Focus. Most companies drastically under-estimate just how big the change is going to be from a technical perspective, but more importantly, from a business process perspective.
- Flexible Business Processes. SAP and Oracle EBS have tremendous amounts of functionality and potential configuration variations. Both products have powerful configuration and integration tools, which means that implementing companies have a world of possibilities at their fingertips. However, the configuration of the software doesn’t matter at all if the business operations and its people can’t adopt the new processes. For this reason, generic and transactional-based training materials do very little to get employees comfortable with the systems. As a result, the business processes typically don’t integrate well with the software, and vice versa.
SAP Implementation Risk Mitigation Strategies
- Organizational Change Management. If I had to pick one single biggest reason why SAP, Oracle, and Tier I ERP implementations fail, it would hands down be because there was not enough focus on organizational change management. Basic core team training is one thing, but how are people going to adapt to the multitude of changes they’re facing: in addition to a new ERP system tool, they have new business processes, new job descriptions, new roles, new data structures, new access to information, and new reports to work from. While these new things have noble purposes, they can actually cause the implementation to fail if they are not handled appropriately. Your organizational change management strategy should include organizational and job design, process gap analysis, detailed business process testing, employee communications, and benefits realization, all in addition to basic training.
- Business Process Integration. New business processes need to be well-defined before your Oracle or SAP consultants hit the ground to start configuring. Otherwise, the tail will be wagging the dog and you will have technical configuration people making decisions on how to run your business rather than your internal operational experts. Once these business processes have been defined in detail, you will provide a clear blueprint for the technical consultants to build to. These business process definitions should also act as the foundation for business process and system testing, organizational gap analysis, security roles and profiles, and a host of other key project activities.
Although these are just two risk mitigation strategies, you will be ahead of most companies if you effectively manage both during your SAP implementation, Oracle implementation, Microsoft Dynamics implementation, or other Tier II ERP implementation initiatives.
