Why ERP Implementation Consultancy Fails Before It Starts

You're the operations director or transformation lead at a mid-sized manufacturer, distributor, or process business. Your finance team has been pushing for an ERP system for 18 months. You've finally got budget sign-off. You've shortlisted three ERP implementation consultancy firms, run the RFP process, and you're about to sign a contract. Then you should stop.

Not because the consultancy is bad. But because you're about to pay them to solve the wrong problem.

Most ERP implementations fail not because the technology is broken or the consultants lack skill. They fail because nobody has actually mapped what your current system does — not what it's supposed to do, but what it actually does on Tuesday morning when the parts clerk overrides the allocation logic to ship a customer early.

That override isn't a bug. It's a process assumption. It's baked into your business. And until you've made it visible, explicit, and decided whether to keep it or change it, you cannot buy an ERP implementation consultancy engagement that will succeed.

The Gap Between How Systems Work and How Business Happens

I spent 8 years as VP of Operations before I started my advisory firm 4 years ago. I've now been embedded in 22 ERP transformations across manufacturing and distribution. In every single one that went over budget or missed go-live, the core failure was the same: consultants optimised for what the system could do, not what the business needed it to do.

Here's what happens. You bring in an ERP implementation consultancy. They're good at what they do. They map your current-state processes. They document 180 requirements. They recommend SAP or Oracle or NetSuite based on feature fit. Then — and this is the critical moment — they begin configuring the system to match your "current state."

But your current state isn't a process. It's a collection of workarounds.

In one automotive parts supplier, the demand planning team was manually overriding demand forecasts every Friday because they knew about a major customer's seasonal ramp that the demand sensing algorithm didn't see. They'd spent three years building intuition into that override. When the ERP implementation consultancy asked them to "formalise" it, nobody could articulate it. The team just said: "We know it when we see it."

The consultants then tried to build a rule set. It took 14 weeks. It cost $180,000. And it still didn't work because the real rule wasn't about the forecast at all — it was about the customer's political calendar, which nobody had documented.

What Actually Gets Bought

Here's what I've learned: most organisations don't hire ERP implementation consultancy to change their business. They hire it to codify their business into software form.

That's reasonable. But it's also the assumption that breaks most projects.

When you buy implementation consultancy, you're actually buying one of two things:

Type 1: Configuration consultancy. You know your processes. You want them automated faster and cheaper than building custom code. You need someone who speaks both your industry and the ERP platform's native language. You want them to say: "Your current weekly manual reconciliation can be a scheduled batch job — two weeks to build, $40K." This works. I've done this 8 times in the last 4 years. Average implementation 16 weeks, average overage 8%.

Type 2: Transformation consultancy. You know your processes don't work anymore. You want to redesign them while you implement new software. You need someone who will push back on "we've always done it this way" and ask whether you should do it that way. This also works. But it takes longer, costs more, and requires your CFO and COO to be aligned on why you're changing before you start. I've done this 6 times. Average implementation 28 weeks, average overage 4%. The overages were lower because everyone knew from week one that we were changing things, not just automating them.

The problem is you often think you're buying Type 1 and you're actually trying to do Type 2.

The Hidden Cost is Not in the Consultancy Fee

Two years ago I walked into a client site where they'd already spent $320,000 on an ERP implementation consultancy. The project was 14 weeks behind. The consultancy had delivered everything they'd contracted to deliver. But the business hadn't actually approved any of the changes they'd recommended because nobody had decided if they wanted those changes.

The consultancy was technically blameless. They'd done their job. But the engagement was failing because the client had never answered the question: "Are we automating what we have, or rebuilding how we work?"

I audited the backlog. There were 47 pending customisation requests. Estimated cost: $2.1M. Expected delivery: 6 months out. The client's CFO was now asking for a fixed-price guarantee nobody could give.

That's when I realised something: the cost of ERP implementation consultancy isn't the consultancy bill. It's the cost of discovering — in week 16, with 60% of your budget already committed — that your finance team's workflow doesn't fit the system because it was designed by people who no longer work here.

What You Actually Need to Do Before You Hire Consultancy

You need a single week. Not a month. One week. Five days, if your business is smaller.

Bring together the people who actually do the work, not the people who manage the people who do the work. The demand planner. The GL accountant. The person who books the shipments. The warehouse supervisor. The person who approves returns. Not in a formal requirements meeting. In a working session.

For one hour per day for five days, have them walk you through what they actually do. Not the procedure manual. The actual sequence of decisions and overrides and calls and email searches they perform.

Then ask one question: "If we had to redesign this from scratch with modern software, would you design it the same way?"

You will get three types of answers:

Answer 1: "No, this is stupid, we do it this way because of legacy system limitations that are gone now." — These are redesign opportunities. Mark them for change during implementation.

Answer 2: "Yes, because [actual business reason that's still true]." — These are things to automate as-is. Don't try to change them. Configuration consultancy solves this.

Answer 3: "I don't know, it's just how we've always done it." — These are the danger zones. You need to redesign these before implementation starts, not during it.

If you do this work first, here's what changes: when you hire ERP implementation consultancy, you're not asking them to figure out what your business does. You're asking them to build software to do a set of things you've already decided on. The scope is constrained. The timeline is realistic. The budget doesn't explode in month four because someone finally said "wait, what are we actually changing?"

When This Doesn't Work

I'll be direct: this approach fails if your executive team isn't aligned. If your CFO believes the ERP will force discipline on business units, but your COO wants to preserve flexibility, you'll fight about what gets redesigned from day one. This isn't a consultancy problem. This is a business problem that no consultant can solve by working harder.

It also struggles if you're in a genuinely complex business — deep supply chain networks, heavy regulated compliance, dozens of customer-specific workflows. The five-day working session won't be enough. You might need a dedicated three-week discovery before you buy implementation consultancy. That costs more upfront. But it's cheaper than discovering the gap in month five.

The Real Service ERP Consultancy Should Provide

This is where the consultancy you hire actually earns their fee. Once you've mapped your decisions, a good implementation consultancy will tell you which of those decisions are baked into the software platform you've chosen — and which ones will require customisation.

That conversation is where you find out whether you're looking at a 12-week, $300K project or a 32-week, $1.2M project. Not because the consultants are hiding costs. But because you finally have the information required to estimate.

I once had a client push back on my estimate and ask if they could get the system up in 10 weeks for $200K. I said yes. They could. But it would mean: no custom reporting (they'd have to live with what the ERP gave them), no integration to the legacy EDI system (customers would re-key orders), and no automation of the exception management workflow they'd identified in day three of the discovery.

They picked those three things to cut. Honest conversation. Honest timeline. Project landed on time, 3% under budget.

That only happened because we'd decided before implementation consultancy started what was actually being changed.

Where to Start

If you're six weeks from signing an ERP implementation consultancy contract and nobody in your organisation has articulated whether you're automating or redesigning, pause. Run a five-day working session with the operators. Document what you find. Then buy the consultancy.

You'll pay them less. You'll get a more accurate estimate. You'll hit your timeline. And you won't spend $2M on a customisation backlog that wasn't real six months earlier.

If you're already mid-way through an implementation and the backlog is growing, you need different consultancy — someone who will stop building and help you decide what actually needs to exist. That's a different conversation, and a different engagement.

You can post that problem on Symbrite — describe where you are in the implementation and what's broken — and connect with consultants who've actually navigated the gap between software capability and business decision-making. Not theoretically. In the actual rubble of a project that went sideways.

That's the consultancy that matters.

Ready to work with an expert?

Post your problem from AcumiSol and receive proposals from experts.