Somewhere in your business, an order is waiting. It might be sitting in a queue in the ERP, or it might be sitting in a spreadsheet because entering it into the system takes too long. Either way, the transaction is not moving, and that is a decision your software is making for you.
If your ERP feels slower than it did five years ago, it probably is. Not in the way a slow website feels slow. More in the way a lift feels slow: nobody times it, but everyone takes the stairs. I have spent more than 13 years advising UK businesses on ERP, and the first question I ask in a system review is always the same. When did the system start feeling heavy? The answer is never "this week". It is always gradual.
In this guide
The quiet symptoms
Slow ERP is easy to miss because the symptoms look like normal business friction. Watch for a cluster of these rather than any single one:
- The month-end close has drifted. It used to take three days. Now it takes six, and the last day is always a scramble. Close cycles lengthen quietly, one task at a time.
- Reports time out or run overnight. If the daily sales report has to be scheduled for 2am because it blocks everyone during the day, the data platform is struggling.
- People rekey between systems. The ERP cannot talk to the new ecommerce platform, so a person copies orders across. Every hour spent rekeying is an hour the system has outsourced to a human.
- Screens stall on common actions. Stock lookups, customer searches and invoice postings that used to be instant now pause. Small pauses add up to a wasted afternoon a week per person.
- The spreadsheet layer is growing. When key figures are only trusted in Excel, the ERP has stopped being the system of record for the decisions that matter.
None of these triggers an alarm. That is precisely why the problem compounds. Nothing fails loudly. The system just absorbs time, and time is the input your team never gets back.
How to measure the drag
Before changing anything, measure. A two-week baseline costs nothing and gives you a comparison point for every future decision. Track these five numbers:
| Metric | Where to look | Warning sign |
|---|---|---|
| Order entry time | Average time to create and confirm an order | More than double the figure from two years ago |
| Close cycle length | Days from month end to signed-off accounts | Lengthening for two consecutive quarters |
| Report runtime | Time to produce the ten reports finance runs most | Any report that needs scheduling after hours |
| Rekeying hours | Time spent moving data between systems by hand | More than a day a week across the team |
| Workaround count | Number of live spreadsheets feeding the ERP | More than five, or growing month on month |
Once you have the baseline, you can put a number on the drag. That number is what turns an uncomfortable feeling into a business case.
A 230-person manufacturer in the Midlands ran an ERP deployed in 2004. The close took six working days, and two accountants spent three of them rekeying figures from a logistics portal. My baseline showed 41 hours a week of manual workaround across finance and sales admin, roughly two full-time jobs. The system reported no errors. That was the problem: it had not failed, it had simply asked people to absorb its limitations. The figures convinced the board to fund a replacement programme that would pay for itself inside three years.
Why it creeps up on you
ERP slowdowns are rarely caused by one event. They accumulate from four directions:
- Customisation debt. Every bespoke screen and patch from the last decade carries weight. Old customisations break quietly as the core product changes, and they are the first thing to slow a system down.
- Data volume. Ten years of transactional history, duplicated customer records and archived batches make every search, report and stock calculation work harder than it should.
- Integration sprawl. Each new tool bolted on over the years adds sync jobs, error queues and manual reconciliation. The ERP becomes a hub for software it was never designed to talk to.
- Thinning skills. The people who configured the system have moved on. What is left is a system that only two people in the building understand, and they are both too busy to maintain it properly.
All four feed each other. More data makes customisations slower. Slower processes force more integrations. More integrations mean more workarounds. Left alone, the loop only tightens.
The compounding effect
The drag is not a flat cost. It compounds, because every year of delay adds another layer of workaround on top of the last. The real financial picture, including licence fees, maintenance and the wages spent on manual processing, is covered in the real cost of running software you have outgrown. And there is a point where the system stops being an asset altogether, which I have written about in the day your ERP becomes a liability.
The UK context matters here. The Office for National Statistics productivity measures show how slowly output per hour has grown across British industry over the past decade. For individual businesses, the gap between the firms that remove friction and the firms that absorb it is exactly where that national story comes from. Central government has taken the same problem seriously enough to publish guidance on preventing technical debt and legacy systems, and the same logic applies to a mid-size manufacturer as to a department.
A starting point, not a project
You do not need to launch an ERP project to start. Take four steps this quarter:
- Run the two-week baseline. Use the five metrics above. Get numbers, not impressions.
- List every live workaround. Name the spreadsheet, the person who maintains it, and what the ERP fails to do that the spreadsheet covers.
- Freeze new customisation. No more patches to a product you may not keep. Route requests through a short review.
- Put a price on the drag. Multiply rekeying hours and close days by fully loaded salary. That is the number to argue with.
If the number is small, tuning the current system may be the right answer. If it is large, you have the evidence to plan an ERP change without disrupting daily operations. Either way, you are deciding from data instead of from the slow creep of another year.
Frequently asked questions
How can I tell if my ERP is slowing the business down?
Measure transaction response times, report runtimes, the length of the month-end close, and how many hours staff spend rekeying data or using spreadsheets to work around the system. If any of those have worsened over two years, the ERP is likely part of the drag.
Is a slow ERP a sign that I need a new system?
Not always. Performance tuning, database maintenance, hardware upgrades and removing old customisations can restore speed. If the slowdown comes from outgrown business processes, unsupported software or missing functionality, replacement is usually the better answer.
How long does a typical ERP performance review take?
A focused review takes two to four weeks. You measure transaction and report performance, map workarounds, review customisation debt and interview key users, then compile a baseline you can compare against after any change.
Can we speed up the system we already have instead of replacing it?
Sometimes. Indexing, archiving old data, upgrading infrastructure and removing obsolete customisation can help. But when the bottleneck is business process or product design rather than hardware, these fixes only delay the decision.
The honest summary: your ERP is not failing, it is coasting, and coasting is expensive. Measure it this quarter, price the drag, and then decide whether to tune it or replace it. The next year will pass either way.
