Your ERP Project Is Failing (You Just Don't Know It Yet)
How to spot the drift before you hit cutover
You’re mid-ERP. Money’s spent, everyone’s knackered, and you can’t quite prove it’s going wrong… but you can feel it.
That’s the dangerous bit. ERP can fail without a big bang and an error message. It fails quietly, then becomes the reason teams keep a separate spreadsheet and route workflows around the system instead of through it.
If you’re in that limbo, don’t default to blaming the software. In practice, the problems can be self-inflicted. You can have a great system and a great SI, and still end up with something that technically works but nobody trusts because it doesn’t reflect how the business actually runs.
The quiet failure pattern
The first sign you’re off track is when the project starts optimising for sign-offs instead of outcomes. Milestones get ticked off, demos look slick, but nobody can walk a real order through the full flow without wincing.
The internal tell is confidence. If every test reconciliation is throwing up surprises, and confidence in the system is evaporating, that’s not teething issues. That’s a project that might not recover.
This is why brands without an in-house ERP operator get caught out. Each partner can genuinely deliver their slice, but if you haven’t got enough internal expertise you don’t know how to challenge it.
And the ugly truth is the in-between bits are where things break. Orders moving from your ecommerce platform into ERP, being picked in the warehouse, and landing back into finance is the chain where issues hide. A missing field, a misaligned mapping, a forgotten checkbox, and suddenly your operation breaks in a place nobody owns.
So if your project status looks green but your team’s behaviour is screaming red, listen to the behaviour. Workarounds aren’t coping mechanisms; they’re your warning system.
The stuff that actually derails go-live
If you’ve effectively outsourced decision-making to your vendor and your SI, you’re already late. Training isn’t the same as confidence, and confidence doesn’t appear by magic. It shows up when someone inside the business has the authority and experience to push the system further, and to keep pushing when it gets uncomfortable.
The pitfall here is thinking you can buy capability. You can’t. You either bring in an in-house operator early, or you choose partners who transfer knowledge rather than hoard it, and you set that expectation from day one.
The next sign is capacity theatre. Everyone says they don’t have time, but the real issue is you haven’t made room for the work.
You can’t implement something like ERP by squeezing it in around the edges. That’s not a time problem. That’s a capacity problem.
If your finance lead is meant to redesign the close, run UAT, and still hit month-end with a skeleton team, you’re not running an implementation. You’re setting yourself up to cut corners, miss issues, and then pay for it later.
Then there’s data. Not data in the abstract. Your product data, your SKUs, your attributes, your categorisation, the stuff merch and product dev live and die on.
If data is incomplete, outdated, or inaccurate, the outputs are useless. And if you’ve got no clarity on who owns that data across the business, you’ll end up duplicating entry, arguing about definitions, and migrating a mess with a nicer UI.
The pitfall is leaving product data clean-up as an IT workstream you’ll get to later. You won’t. You’ll hit cutover, discover items don’t behave properly, and you’ll be trying to fix it at the exact moment the business needs stability.
Timeline pressure is the other classic. Vendors will happily sell you speed, and the business will happily attach go-live to a milestone because it feels decisive. The cost of that decisiveness lands on you when quality gets traded away to hit a date.
Missing a vendor’s deadline is frustrating. Missing your own readiness is catastrophic.
If you’re hearing “can we go live in 90 days,” you’re asking the wrong question. The right question is what needs to be true for you to go live in 90 days.
That shift matters because it forces the awkward conversation. If sponsor attention, capacity, integrations, and data readiness aren’t there, the answer isn’t cross your fingers. The answer is to move the date.
Testing is where all of this gets exposed. If UAT is mostly happy-path clicking, you’re setting yourself up for the sort of failure that doesn’t even throw an alert.
Integrations can fail quietly. Orders can stop flowing, postings can be incomplete, and you won’t know until someone reconciles properly and realises things don’t tie out. That’s when the panic starts, because you’re now debugging while customers are waiting and finance is trying to close.
That’s why end-to-end testing beats vendor sign-offs when you’re testing whether your business can trade. You’re not testing modules, you’re testing whether your business can trade.
And don’t kid yourself that some functions can join later. If finance isn’t engaged during implementation, then relies on the ERP for reporting, you can end up with the data wrong because the system didn’t meet their needs and nobody caught it in testing.
By the time you realise, it’s not a quick fix. With a large volume of inaccurate records, you’re into a long slog that could’ve been avoided by involving the right teams from the start.
Why talking to someone who’s done this matters
The difference between a successful project and a rescue mission usually comes down to whether someone in the room knows where the skeletons are buried.
Not theoretical skeletons. The actual ones. The integration that looked fine in the demo but breaks under volume. The data migration that passes validation but lands finance with a reconciliation nightmare. The cutover plan that works on paper but collapses when your warehouse team is still picking orders.
This is what Commerce Thinking’s ERP practice exists for. We’re former brand-side operators from companies like Gymshark, Liverpool FC, and Burberry who’ve run these projects, lived through the mistakes, and know what good looks like when the pressure’s on.
We’re not here to sell you more config or extend timelines. We’re here to tell you what’s actually going to break before it does, challenge the bits that don’t make sense, and make sure your team can own the system when we leave.
Because the goal isn’t dependency. It’s capability. If you need us six months after go-live to run a routine process, we’ve failed.
If you’re mid-project and starting to feel that unease, or you’re about to kick off and want to avoid the traps, talk to us. We know what a good project looks like because we’ve built them. And we know what a struggling project looks like because we’ve rescued them.
If you’ve got that sinking feeling
ERP doesn’t solve problems. People do.
If you’re mid-project and you’ve got that feeling, treat it as a signal. You’ve still got time to fix the fundamentals, make room, clean the data, and force end-to-end ownership before the system becomes a very expensive spreadsheet generator.
You don’t need deeper config. You need broader context, the kind that understands how your teams actually work, not how the process map says they should. If you don’t bake that context into design and testing, you’ll go live and still be arguing about why merchandising missed PO lock dates or why a landed cost update has just blown up reporting deadlines.
None of this is about perfection. It’s about reality.