Stuart Totterdell
Technical Director
Walk the floor of a mid-market manufacturer, distributor, or field service business on a Tuesday afternoon and ask people how they actually do their jobs. Then ask leadership how the ERP is performing, and you will get two completely different answers.
Leadership will tell you the system went live eighteen months ago, that the modules are in place, and that the business is "on the ERP." The warehouse supervisor will show you a shared spreadsheet that actually drives picking. The planner will open a desktop file that holds the real lead times. Purchasing will admit they raise orders in the system after they have already agreed them by email, because that is the only way the numbers look right at month end. You are not running an ERP. You are paying for one.
The implementation vanity metric
Go-live gets treated as success: licences are paid, training sessions were held, the project steering group signed off, and somewhere there is a slide that says the ERP is fully implemented. But fully implemented is not the same thing as used.
In most mid-market estates we see, a significant share of licensed modules barely appear in daily work. Advanced planning sits idle while someone rebuilds a capacity sheet every Monday morning. Quality management is paid for while non-conformance actually lives in a shared drive. CRM or project modules exist because they came bundled into the deal, not because anyone changed how sales or delivery genuinely operates. The vendor invoice does not care about any of this - you pay for seats, modules, and support whether the floor uses them or not, and that is not a software problem. It is an adoption and IT and process strategy problem that leadership keeps mislabelling as an ERP problem.
Why the floor abandoned the system
People do not invent spreadsheets for fun. They invent them because the official process is slower, less trustworthy, or missing a field that genuinely matters on the line.
Sometimes training was a one-day dump at go-live that was never refreshed when roles changed. Sometimes support tickets take a fortnight while the workaround is available within the hour. Sometimes the configuration still matches the process that was workshopped two years ago, rather than the process the business now runs after a product-line change, a new warehouse, or an acquisition that nobody ever remapped. The result is a shadow operating system, where the ERP becomes little more than a compliance layer - the place invoices must land, where stock must eventually get adjusted, where auditors expect to look - while the real decisions happen elsewhere. Inventory accuracy drifts, costing goes soft, and planning becomes storytelling, until someone finally asks why the ERP "does not work" and the honest answer is that the business simply stopped working inside it.
Unused modules are a renew-versus-replace signal
When renewal season arrives, the conversation often jumps straight to features and platforms - which cloud suite, which vertical pack, which partner - and that is the wrong opening question entirely. The first question should always be utilisation.
If half of what you already pay for sits unused, replacing the platform will not fix adoption on its own. You will simply buy a new set of modules, run another training programme, and recreate the same pattern: leadership declares victory, and the floor quietly rebuilds its spreadsheets underneath it. The renew-versus-replace decision should start with an honest map of what is actually used, what is paid for and ignored, and which workarounds have quietly become load-bearing. That map is usually uncomfortable, because it tends to show that the expensive parts of the stack are underused while the cheap, informal tools have become mission-critical. Until you face that squarely, every vendor demo is theatre.
Training and support failure is not a soft issue
Boards treat training as a project line item, but ops managers experience it as the actual difference between a system that sticks and one that gets quietly abandoned. If new starters learn from a colleague's personal workbook rather than the ERP process itself, adoption tends to die within a year of go-live. If power users leave and nobody owns the configuration knowledge they carried, the system freezes in whatever state it was left. If support becomes a black hole of ticket ping-pong, people simply stop raising tickets and start building escapes instead.
This is not culture fluff - it is operational risk with a licence bill attached. An ERP renewal conversation that ignores training, ownership, and support quality is not really a technology decision at all. It is a bet that a different logo will magically produce different behaviour.
Simplify before you spend
The practical move is neither to defend the current ERP forever nor to panic into a replacement programme - it is to simplify what you are actually asking the core system to be. Strip the estate back to the processes that must live in the ERP for control, finance integrity, and inventory truth, and fix those so they are genuinely used. Retire or pause modules that only exist because they were bundled into the original quote, and put orchestration and business automation around the edges wherever the floor has already proven the need through its own spreadsheets - order intake handoffs, status updates, exception routing, reporting extracts.
That sequence matters, because if you replace first, you simply migrate unused complexity into a new contract. If you simplify and adopt first, you discover whether the current platform can actually carry the load with a thinner, clearer footprint, and you enter any renewal or change conversation with evidence rather than frustration.
The uncomfortable test for leadership
Ask three questions at the next operations review. Which licensed modules have fewer than a handful of weekly active users, and why are you still paying for them? For the five most critical operational workflows, where does the truth actually live - the ERP, or a file someone quietly maintains? And if you turned off the unused modules tomorrow, what would actually break in the business versus what would only break in the licence schedule?
If the answers come back vague, you do not have an ERP strategy. You have a subscription and a story. You are paying for capability the business does not use, while the people who keep the operation moving work around the very system you insist is the backbone. Fix adoption and scope before you rewrite the contract - otherwise the next platform will simply be another unused ERP with a fresher invoice attached.
