5 Ridiculously Expensive Mistakes
Companies Make When Upgrading Their ERP;
and how to avoid them.
Over the past 20-years, I’ve implemented industrial technologies (databases, ERP’s, asset management solutions, etc…) in 87 countries. In the beginning, even multi-billion dollar operations were still struggling with DOS-style interfaces and manual integration teams. Thankfully, technology has gotten better, integrations have grown tighter, interfaces have become easier, etc…
However, the ease of use has lulled tech leaders in more complex industries – especially industrial and manufacturing verticals – into an expensive sense of overconfidence when upgrading or replacing their core ERP systems.
My team at RigServ usually gets called in after a company gets stalled out during an already over-budget ERP implementation. So this past December, I polled my team and clients across our Europe, Middle East, Asia and North America sites to retroactively examine where the most expensive mistakes occurred.
These ERP implementations included projects like:
- Replacing a legacy ERP with IFS
- Upgrading multiple SAP modules
- Transitioning from SAP to Oracle during a company merger
- Merging a JD Edwards / Lawson / Legacy “Frankenstein stack” with IFS
Here are the common hotspots that burned up their ERP implementation budgets.
The Problem
Poor planning during the starting phases of an ERP implementation can cause significant project derails, leading to painful cost over-runs and extended implementation lead times.
In fact, according to the Technology Evaluation Centers (TEC) – an impartial advisory firm that does in-depth analysis on business software for the manufacturing, professional services, retail, utilities, and distribution industry – states that, on average, ERP implementation lead times take 30% longer than expected.
Not only that. Studies from TEC researchers confirm something that we’ve experienced first-hand while working with our clients: average budget over-runs can go from 3-4 times beyond expected. And in some cases, half of ERP implementations fail.
The good thing is all three resource-consuming scenarios can be prevented by planning correctly and by not skipping any of the implementation steps because all play a crucial role and have a reason for being.
A major lesson we’ve learned throughout 7+ years of working with clients is that they usually underestimate the importance of effective ERP implementation planning and just want to kickstart the process as soon as possible. Naively ignoring all the problems implementing an ERP without the proper planning can spawn.
That said, ERP implementation planning should be given the attention and priority it demands, regardless of whether you’re interested in upgrading, updating, or implementing a brand-new ERP system in your organization. ERP implementation shall not be skipped by any means unless you want to solve more problems than the ones you already have, and that is the reason you want to implement a new ERP in the first place.
Some vendors won’t tell you this, but a lack of effective planning can lead to a massive hike in the Total Cost of Ownership (the costs of having the ERP system and all its integrations running, even if you don’t use them) due to unnecessary CRIMs, which are tailored-to-your-business personalizations and configurations added to your live ERP system, based on your day-to-day operational needs.2
Without being aware of it, you could be adding unnecessary training time for your team and confusing complexity to your ERP system. All because of deficient planning.
The Solution
- Estimate the time investment required for the implementation and add some padding to maneuver in case something unexpected occurs because it’s likely to happen.
- Consider what CRIMs do you really require/need, how much it will cost to implement and maintain them running in your organization—keeping in mind how your organization might change in the next 5 to 10 years down the road.
- Follow Global best practices and the IFS standard methodology.
The Problem
Because of the vast range of ERP options available in the market, it’s more than likely that the two organizations have completely different ERP systems and integrations.
Therefore, one primary element to keep in mind is the modules you will need to establish smooth business communication with third-party companies that support your operations, such as vendors, partners, financial institutions, and suppliers.
Not considering business allies vital for your operations could lead to not adding the necessary modules and integrations you need to collaborate with them effectively.
On top of that, the former could heavily slow down your day-to-day operations, leading to less overall productivity amongst your employees.
And also, not having the suitable modules and integrations could force your staff to perform time-consuming manual labor and deal with the uncertainty of not having accurate data in real-time when they need to make decisions on the fly.
Preventing you from effectively tracking and optimizing your supply chain processes.
The Solution
Ask your ERP implementation team to help you thoroughly assess your supplier relationship needs, so they can design a customized solution for your organization that would work for every business scenario you could encounter.
The Problem
Prototyping the ERP solution and running User Acceptance Tests are not steps added to the implementation process to bulk up the client’s project invoice.
Running these tests is crucial for preventing (and foreseeing) catastrophic mistakes later on during the implementation process.
Building a Solution Prototype allows the project team to assess if the general scope and the solution specifications align with the clients’ business needs.
However, prototype confirmation goes way beyond that. It’s actually when the initial ERP system prototype is designed and stress-tested in day-to-day business scenarios to see if it has all the required functionality and specifications the client will need to implement in the live version of the ERP system. (CRIMs are determined and planned during this phase.)
Prototype Confirmation and Solution Acceptance Tests work together.
Once the ERP solution prototype is built, the client and the project team organize workshops to simulate day-to-day business scenarios with actual data and designated roles for staff members. All the former to detect overlooked gaps that the project team or the client did not initially contemplate.
The goal of all the former is to gather feedback from involved staff members before the project team cements the final version of the ERP solution—seeking to account for every detail needed to add to the final live version.
If you want to know more about our ERP implementation methodology, I suggest reading the IFS implementation methodology because our methods are closely aligned with theirs.
The Solution
- Running an assessment of the ERP solution with prototype mapping, make the core process owners review it. After the former is done, document and identify gaps in the system (between company needs and CRIMs). Generate a report with the former information.
- Adjust the CRIMs so they fill the gaps identified in the previous step and make sure they cater to the organization’s needs.
- As a final step, to make sure if further changes are needed or not. Run a User Acceptance Test (UAT) and an Operational Readiness Test (ORT).
The Problem
I talked about testing the ERP system prototypes on the last point and said it was necessary. But now, I want to mention why it’s so essential for the client to run ORTs.
The main reason is that upgrading, updating, and implementing a brand new ERP system forces your organization to change, and with the need to change comes the need to train your staff on the use of new systems and functionalities.
So when the project team runs ORTs in the form of operational simulation workshops, you can detect beforehand how much training your staff will need.
The Solution
Do not skip Operational Readiness Tests. They can help you significantly reduce your staff’s training costs and time investment significantly.
The Problem
Because of our globalized business landscape, more and more companies — small to big operations — are starting to implement ERP systems to unify and decentralize all their day-to-day operational and transactional business data.
Nowadays, an ERP system isn’t a nice to have—it’s a must, especially for organizations with too many moving parts, e.g., industrial, manufacturing, and production companies.
Not having an ERP system can cause major headaches to the people involved in your business processes.
Some of the issues lacking an ERP system can cause is:
- Every department uses different software solutions that don’t interact smoothly with other dependencies in your business, making it difficult to send, receive and report data between your departments.
- Not having all your data in one place makes decision-making difficult, painfully slow, and biased because you can’t visualize all the data you need beforehand.
- Your inventory count can be inaccurate and even have outdated information.
- Dealing with compliance, financial reporting, and giving efficient IT support to your staff turns into a nightmare.
The Solution
Install an ERP system that suits your business needs as soon as possible, with the help of experts that care about your business, are mindful of your budget, and have a proven track record carrying out successful ERP implementations in many industries.
Rule of thumb – plan harder, expect mistakes, and get help (at least during the planning phase).
If you have any questions – or if there’s anything I missed – comment below or contact me here.
Citations
- https://www3.technologyevaluation.com/research/article/erp-software-facts-stats-and-lessons-learned.html
- https://www.ifs.com/nl/-/media/assets/2017/12/07/ifs-implementation-methodology.pdf
- https://www.erp-information.com/erp-modules.html
- https://www.erpfocus.com/erp-supplier-integration.html
- https://www.cgsinc.com/blog/why-you-cant-afford-to-put-off-implementing-an-erp-system-here
- https://www.erpfocus.com/erp-supplier-integration.html
