If you hang around people who’ve been through an ERP project, you notice they talk about it as if it were a traumatic experience. Lots of staring into the distance and lots of, “If I could do it over again…” Here’s a big, scary statistic that may seem odd coming from someone who wants to help you with this exact task: 55-75% of ERP implementations are considered failures. Now, that’s a wide range but that’s only because “failure” is tough to define in this case. An implementation can go live, but still be a failure. The statistic includes outright failures, failure to meet their stated goals, and budgetary failures.
Hopefully you haven’t run for the hills just yet. This is a good news, bad news situation. The good news: the horror stories are mostly avoidable. The bad news: most of the reasons ERP projects fail have nothing to do with the software and everything to do with human nature, planning, change management, and adoption. People tend to see these as purely a software implementation because they revolve around software. In reality, these projects are more about people and process than they are about software. In this post, I’m going to go through the major reasons that ERP implementations fail and what you can do to avoid the common missteps.
1. Starting with “we need ERP” instead of “we need X”
A lot of projects start with a vague sense of pain:
“QuickBooks is groaning.”
“The spreadsheet chaos is real.”
“We’ve outgrown this.”
Someone says, “We need an ERP.” And that becomes the goal. Not “we need to ship on time” or “we need inventory to be accurate” or “we need to stop quoting jobs on cocktail napkins.” Just “We need ERP.”
Six months later, your team is exhausted, you’re over budget, and nobody can tell you if the business is actually better. You got ERP but you didn’t get results.
A small manufacturer wants better scheduling and inventory control. In practice, the project team spends 80% of their time arguing about the chart of accounts and what the logo looks like on invoices. Go live arrives, AP is happy, but the shop floor is still running off the same whiteboard and the same “tribal knowledge” in the supervisor’s head. Technically, the project “succeeded.” Practically, nothing changed.
The fix: nail down 4-6 painfully specific goals before you even look at software. Outside of basic requirements that virtually every application will have, define requirements based on these goals.
“Reduce stockouts by 50%.”
“Cut order lead time by 5 days.”
“Stop retyping web orders by hand.”
2. Letting the software drive your processes (or vice versa)
There are two equal and opposite mistakes:
“We must customize the system to match every quirk of our current process from 2009.”
“We must do everything exactly the way the software does it out of the box, even if it makes no sense.”
Both are expensive.
Example one:
A job shop insists the new system must support their exact ten step paper traveler process, including the three steps no one can clearly explain. The vendor says, “Sure, we can customize that.” Months later, you have a fragile, over engineered monster that breaks every time you update the software.
Example two:
A distributor adopts the standard ERP process for returns, which was clearly designed for some giant enterprise with a legal department. Suddenly, what used to be a five minute “yeah, bring it back” turns into a mini project with forms, codes, and approvals. Customers and CSRs both hate it, but “that’s how the system works.”
The fix:
Protect the few processes that actually differentiate you (your secret sauce).
Be ruthless about simplifying or standardizing the rest.
And for the love of sanity, have someone in the room who can say “We only do it that way because the old system forced us to.” Because We’ve always done it this way is never a valid reason on its own.
3. Treating implementation like “IT will handle it”
ERP touches almost everything: quoting, orders, purchasing, inventory, production, shipping, invoicing, sometimes even HR and CRM. If your implementation team is basically “the IT person and whoever had the bad luck to be walking by,” you’re setting up a very expensive surprise party for the rest of the company.
The owner and IT lead run the project. They’re trying to be considerate, so they don’t “bother” people in operations, finance, and the warehouse until things are “mostly set up.” Go live week, the warehouse learns they’re supposed to use handheld scanners‚Ķ which no one ordered. Accounting discovers that their carefully tuned month end process has been replaced by something “streamlined” that does not actually produce the reports they need. Cue chaos, finger pointing, and a strong desire to set the server on fire.
The fix:
Put real users from each key area on the project team.
Give them time, not just a seat in the occasional meeting.
If the people who will live in the system do not help design and test it, they will 100% help kill it once it goes live.
4. Underestimating the “people and change” side
You can’t just flip a switch and assume people will happily drop their spreadsheets and habits and embrace the new world. Most will quietly do both systems “just in case” until someone makes it safe to let go.
The new ERP goes live. Officially, production is scheduled in the system. Unofficially, the production manager still maintains the old Excel schedule “because I don’t trust those numbers yet.” Purchasing continues to work from the old reorder point spreadsheet because “the planning screen is confusing.” Leadership assumes the ERP is running the show. In reality, the same old workarounds are in charge, and the ERP is mostly being fed after the fact so the books will tie out.
The fix:
Treat go live like a major change in how people do their jobs, not a software upgrade.
Explain the “why” clearly: what problems are we solving, and how will life be better when the dust settles?
Budget real time for training, hand holding, and cleanup.
Floor walking and “ask me anything” sessions the first few weeks do more for success than one big training day everyone slept through.
5. Thinking of go live as the finish line
A lot of ERP failures are really “we stopped too early” stories. The team limps to go live, declares victory, and crawls back to their day jobs. The rough edges never get sanded down. The second phase improvements never happen. Everyone just learns to live with the sharp corners.
A small company goes live with the basics: orders, inventory, invoicing. Reports are half baked, workflows are clunky, but it works “well enough.” Phase 2 is supposed to add real capacity planning, better dashboards, and a customer portal. But after go live, the project team dissolves. Six months later, the owner is asking, “Why don’t we have dashboards yet?” and everyone shrugs and points at each other.
The fix:
Plan for at least one “stabilization and improvement” phase after go live before you start.
Capture issues and ideas during the messy first weeks, then work through them systematically instead of accepting them as permanent.
ERP that is frozen on day one will age badly.
6. Fuzzy data and fuzzier decisions
“Garbage in, garbage out” is cliche for a reason. If your item master, customer list, pricing, and bills of material are a mess before ERP, you don’t get a brand new clean system by magic. You get a nicer interface wrapped around the same mess.
A company migrates five years of customers, items, and pricing into the new ERP without cleaning anything. You now have:
Three versions of the same customer.
Old part numbers that should have been retired.
Random price overrides baked in as “defaults.”
The first time someone tries to run a margin report, it looks like a crime scene. Cue the conclusion: “This ERP is wrong.” No, the data is wrong. The ERP is just finally telling you the truth, and it is not pretty.
The fix:
Treat data cleanup as a real workstream, not a side quest.
Decide what gets cleaned, what gets archived, and what you simply refuse to carry forward.
If it is not worth cleaning, it is probably not worth migrating.
7. Budgeting for software, not the whole journey
Finally, there is the classic: focusing on license or subscription costs and pretending everything else is “soft.” It is not. The real cost is usually time: your people’s time, plus implementation help, plus the process changes you make along the way.
You pick the cheaper ERP because the monthly fee looks friendlier. You cut implementation hours to save money. Training gets squeezed into lunch and learns. Nobody has time to build decent reports, so managers export to Excel and rebuild the old spreadsheets anyway. A year later, you are paying less per month but buying it back in wasted hours and frustration.
The fix:
Budget like this is a multiyear investment, not a onetime purchase.
Be honest about internal time. If your best people are “too busy” to be involved, you are either not ready or you need to adjust expectations.
So why do ERP implementations really fail?
Because too many projects chase software instead of outcomes. They protect bad habits, under invest in people, skip data cleanup, and declare victory at the first login screen.
If you flip that script-start with clear goals, involve the right people, simplify where you can, respect the change curve, and keep going after go live, you dramatically improve your odds. The tech matters, but it is the boring stuff around the tech that usually decides whether your ERP becomes the backbone of the business or just another expensive story you tell over beers.