Failed ERP implementations happen and more often than most vendors or consultants want to admit.
Gartner predicts that more than 70% of ERP implementations will fail to meet their original business objectives. They also claim 25% of those failures will be catastrophic. That’s some seriously strong language (and a warning). Panorama Consulting puts the failure rate for manufacturing environments even higher. And "failure" doesn't always mean the project gets cancelled. Sometimes failure looks like a system that technically works but doesn't do what you needed it to do. Sometimes failure looks like a go-live that happened on schedule but left half the organization scrambling to build workarounds for processes that were never accounted for.
ERP “failures” are going to happen, but they almost never happen because the software is bad.
They happen because of process problems. Someone missed something in the gap analysis. Testing was signed off on without actually being tested (rigorously, with real data, under real conditions). A parallel test was never completed to stress the system before cutover. You relied too heavily on outside consultants who didn't understand your customer-specific processes. You failed to identify a requirement that seemed obvious to the people doing the work but never made it onto a requirements document.
Those are all human failures dressed up as technology failures…And they're entirely preventable.
But that's not what this article is about.
Rather, this article is about what happens after. Because once the ERP fails,
the reasons become secondary. Yes, you need to know why it happened (and
quickly, so you can mitigate the damage), but now you've got more than failed
processes and systems to deal with.
You've got a staff morale problem…
You made all the speeches. You told your people how much good this project was going to bring. How it would relieve their workloads. How reporting would be easier. How they'd finally have visibility into the data they'd been asking about for years. But the outcome is the opposite.
People are scrambling to do the most basic functions. They're inventing workarounds on the fly for processes that were missed or data the system wasn't configured to capture. If they're in sales operations, they're also playing a PR role, defending delays and mistakes to customers who don't care whose fault it is. They just want their order. These issues are costs, and are more than just financial.
When you promise transformation and deliver chaos, you lose something that takes a long time to rebuild. Trust. Confidence in leadership. Belief that the next initiative will be any different.
And it gets worse…while your staff is drowning, your customers are noticing. Orders are late. Invoices are wrong. Someone on your team is on the phone explaining (again) that "we're working through some system issues." Your best customers might give you grace. Your marginal ones might not.
So what do you do? You go into triage mode. Not one mode, three.
First, software triage. What's broken? What's the minimum viable state to keep the business running? What can be fixed now, what requires a workaround, and what needs to be escalated immediately? You need your sharpest people on this, and they need to be empowered to make decisions without waiting for committee approval.
Second, people management. I want to start by stressing that now is Not the time for assigning blame or finger pointing. Your staff is stressed, frustrated, and (justifiably) angry. Some of them warned you this would happen and were ignored. Some of them are working 14-hour days trying to hold things together. You need to acknowledge the situation directly. No spin. No "challenges we're working through." The situation is bad, and pretending otherwise insults the people living it. Tell them what you know, what you're doing about it, and what you need from them. And then back it up with action. Making decisions about people’s positions (if need be) can come after you have worked through the issues.
Third, customer management. This is where your relationships get tested. If you've built goodwill over the years, now is when you spend it. Pick up the phone. Don't send an email blast. Talk to your key accounts directly. Own the problem. Don't blame the software or the consultants. From their perspective, you made a decision that affected their business. Take responsibility and give them a realistic timeline for resolution.
None of this is easy, but All of it is necessary. Dare I add, this is something you should be planning for in advance! A potential failure should be part of your project plans. Think of it like a mini version of Disaster Recovery / Business Continuity plan. A playbook, a framework, a checklist, something you can turn to in the unfortunate even that you have some level of failure instead of having to try and triage on the fly.
You probably won't get all of it right. You'll over-promise on the fix timeline. You'll underestimate how long staff morale will take to recover. You'll may even lose a customer or two.
But the alternative is worse. Not taking charge and addressing this problem head on, pretending things are fine, letting the chaos continue without clear leadership, hoping it works itself out would be adding insult to injury.
Software can be “fixed”, the data can be
cleaned up, the processes can be re-mapped.
The question is…can you hold the
organization together while you do it?
Suggestions and best practices to avoid ERP Implementation failure coming in Part
2.
________________________________________________________________________________________________________________
Raphael Savastano is the founder and principal consultant of ROFONIC LLC. With 25+ years in IT, 16 years in leadership, including 8 years as CIO scaling technology for a global manufacturer from M to 0M. He now helps growing companies get executive-level technology and operations leadership without the full-time cost. Want to know where your technology actually stands? Take the Founder’s IT Reality Check →
