How Do You Know If The ERP Solution Is Actually Good?
Every steering committee I’ve sat on has, at some point, approved a “solution” without anyone in the room asking what “good” actually means. The vendor presents an option. It closes the gap on a slide. Everyone nods. Six months later the workaround is still running in a spreadsheet, the status report is green, and nobody quite remembers why that decision was made or whether it was ever right.I’ve stopped trusting “it solves the problem” as a sentence. It’s not specific enough to mean anything. Over twenty years of implementing, rescuing, and advising on ERP programs, I’ve come down to four tests I run before I call a solution good. None of them are about the software.
It understands the problem, not just its symptoms: A finance team can’t reconcile at month-end. The obvious “solution” is a new report, or a config change to the GL, or an extra approval step. But none of that means anything until you know why the reconciliation is breaking. Is it a data-entry timing issue between two modules? A chart-of-accounts design that made sense in 2019 and doesn’t anymore? A training gap on a team that turned over twice since go-live? A root-cause, constraints-first solution and a symptom-patch can look identical on a steering committee slide. They are not identical eighteen months later. The patch moves the failure point downstream and it resurfaces as a new incident with a new name, and the organisation congratulates itself for solving a problem it only relocated.
It has genuinely considered every option, not just the one the vendor is selling: Most ERP conversations start from “how do we configure the system to do this” and never leave that frame. That’s not evaluating options — that’s picking from whatever the vendor’s product roadmap already offers. A good solution has been tested against elimination (does this step need to exist at all, or is it a process the organisation inherited and never questioned), outsourcing (should a shared-services team or a specialist provider own this instead of an internal team fighting the system every month), and the human layer (is this actually a training and behaviour problem wearing a technology costume). I’ve watched councils spend six figures configuring an approval workflow that should have been deleted. Nobody asked the elimination question because the workshop was scoped as “configure the system,” not “should this exist.”
It’s been positioned so leadership actually understands what’s at stake: A solution can be technically correct and still die in a steering committee because nobody translated it into terms an executive can act on. “The integration between payroll and finance is unstable” gets nodded through and forgotten. “This instability is producing duplicate payments at a rate that will cost approximately $180,000 this financial year if unaddressed” gets funded. This isn’t spin. It’s the difference between a technical observation and a decision an executive can actually own. Part of building a good solution is doing the work to show its impact in the language the people who fund it use — risk, dollars, statutory exposure, community trust — not in the language of the system.
It has honestly considered the workarounds — and everyone knows they’re temporary: This is the one people get wrong most often, because it sounds cynical until you sit with it properly. Sometimes the right move isn’t the full fix. It’s a deliberate, creative workaround that buys time, reduces immediate pain, and lets the organisation keep functioning while the real solution gets built. A manual EOM reconciliation spreadsheet. A temporary dual sign-off outside the system. A stopgap that deflects the trigger point until root cause work can be resourced properly. There is nothing wrong with this — I’ve recommended it myself, more than once, when forcing a full rebuild mid-crisis would have caused more damage than the original problem.
The danger isn’t the workaround. The danger is what happens when nobody names it as temporary. A workaround that quietly becomes permanent stops being a bridge and starts being the new normal — and because it removes the pain that was forcing people to act, it removes the pressure that would have gotten the real fix funded. This is drift in its purest form: the organisation stops hurting, so it stops fixing, and eighteen months later the “temporary” spreadsheet is load-bearing infrastructure that three people understand and nobody documented.
A good workaround has an owner, a review date, and a written acknowledgment that it is not the solution. A workaround without those three things isn’t buying time. It’s spending the organisation’s future ability to notice the problem at all.
None of these four tests are about whether the system technically does what was asked. They’re about whether the organisation actually understood what it was solving, looked honestly at its options, made the stakes legible to the people who had to fund it, and was honest with itself about which parts of the fix were real and which parts were pain relief.
Most ERP programs I’ve been asked to rescue didn’t fail because the software was wrong. They failed because someone stopped at “it works” and never asked if it was good.
