The Most Expensive System Is the One Your Team Stops Using

There is a version of ERP investment that has very little to do with the needs of the business and quite a lot to do with the ambitions of the people who approved it. More modules, more integration, more visibility. The system becomes a statement of intent rather than a tool people use.

The problem is not capability. It is adoption. A system that captures more than your team is willing to maintain produces worse data than a simpler one they use consistently.

The optimum level of complexity

Every business has a level of system complexity that is appropriate to what it does. Below it, you are flying partially blind. Above it, you are generating admin burden without generating better decisions.

Finding that optimum requires answering three questions.

What does the business actually do?

A business managing bespoke engineered projects across multiple clients has fundamentally different information needs from a property portfolio or a site services operation. When leading an ERP integration workstream following an acquisition, four operating model gaps required mapping before a single configuration decision was made: how time was captured, how procurement worked, how materials were tracked, and what project controls the business needed. Each represented a point where a single system design would have failed one side of the business.

A property business, by contrast, needs rent reconciliation, compliance tracking, and a monthly cashflow view. A spreadsheet and an AI subscription at under £20 a month handles that reliably. Adding an enterprise ERP to that business would not produce better decisions. It would produce a more expensive maintenance burden.

How does data need to connect across functions?

Where multiple systems coexist, the information architecture connecting them matters as much as the systems themselves. In project-controlled environments, consistent reference coding across document management, cost tracking, and the programme schedule creates a reporting view that no single system can replicate on its own. A package of work carries the same reference code through all three, so performance can be read across all three simultaneously. Without that architecture, every report is a manual reconciliation exercise.

This is not an argument for more software. It is an argument for thoughtful data design, which can often be achieved within simpler tools if the underlying structure is right.

Are you recording data or driving decisions?

The clearest signal that a system has overshot is when data is collected but nobody acts on it. When a reporting function exists but the outputs sit unread, or when the team spends more time entering data than using it, the admin burden has exceeded the value delivered. That is the point to simplify, not add.

Why ERP projects tend to overshoot

The people scoping an ERP project are rarely the people who will use it every day. The gap between what is specified and what is practical tends to widen during implementation, and by the time the system goes live, the design has often settled on a level of complexity that works for the team that built it and creates friction for everyone else.

The businesses that get this right treat the operating model conversation as the first deliverable, not an input to a system selection. They understand what they are trying to report on before they decide which system will report it.

How PeakRatio helps

PeakRatio works with founder-led SMEs on the operational infrastructure decisions that determine whether a business scales cleanly or accumulates friction. That includes helping businesses identify the right level of reporting capability for their current stage, and the system architecture that delivers it without creating admin burden that erodes the value.

If your business is growing into a system question, visit PEAKRATIO to find out how we approach it.