You are paying for a data system nobody actually uses

A client we worked with recently had an enterprise ERP system. Six-figure annual contract. Implemented over eighteen months. Mandatory for the whole company.

Nobody used it properly.

Sales logged deals in spreadsheets and copied them into the system at the end of the month. Finance ran budgets in Excel and manually reconciled them against system reports. Operations received updates on paper, transcribed them by hand, and sent manual reports to management. The ERP was technically live. In practice it was a gallery. Everyone walked past it on the way to their spreadsheet.

They ended up with three sources of truth, none of them authoritative. Numbers did not reconcile. Budgets were built from memory. Management reports took two days to produce and were already stale by the time they landed.

The ERP itself was not the problem. The gap between a system that exists and a system that runs the business was.

Going live is only the start

Most companies at a certain size make the same investment. They buy a CRM, an ERP, a data warehouse or a BI tool. They implement it. They announce it. Then they discover that a live system and a useful system are two very different things.

The gap shows up in predictable ways.

Employees keep parallel spreadsheets because the system is slower to update than a shared Excel file. Reports are produced manually because pulling them from the system requires skills nobody has time to develop. Decisions get made from memory or from last month's printout because the system does not surface current numbers in a usable format. The system gets used for compliance, audit trails and the things that absolutely require it. Everything else stays in email and spreadsheets.

The investment keeps compounding. The annual contract renews. The implementation partner charges for another round of training. And the spreadsheets keep running the business.

What this costs beyond the contract

The system contract is the visible cost. Everything around it is harder to see.

Finance runs a budget cycle. Two analysts spend three days pulling numbers from four different sources, reconciling discrepancies and building the final model in Excel. The output is a spreadsheet that took six days of analyst time to produce and will need to be rebuilt from scratch next quarter.

Operations receives a change from a supplier. Someone updates a spreadsheet. Someone else updates a different spreadsheet. A week later, two departments are working from different numbers and neither knows it yet.

Management asks for a revenue breakdown by region. The request goes to the data team, who pulls a report from the ERP, finds it does not match the sales team's CRM data, and spends a day reconciling before anything can be shared.

None of this shows up as a line item. It shows up as slow decisions, analyst time consumed by reconciliation, and a persistent background uncertainty about which number is correct.

Why the system does not get used

The usual explanation is adoption. People resist change. Training was insufficient. Change management was underinvested.

Sometimes that is true. More often, the system does not get used because it does not fit how the work happens.

An ERP designed for a manufacturing company with stable processes and clean master data works well in that context. The same system implemented in a company where processes change quarterly, data arrives from five external sources, and half the team works in the field on mobile devices works less well. The system requires the work to conform to it. The work does not conform. People go around it.

The same pattern appears in data platforms. A warehouse gets implemented. Models get built. A BI tool gets connected. Then the business keeps asking for Excel exports because the dashboard does not answer the specific question they have, in the format they need, with the granularity they expect. The platform is live. It is not running the business.

What a platform that runs the business looks like

A useful platform is built around the questions the business asks, rather than around the data that happens to be available.

A finance team that builds budgets from memory does so because the system does not give them current actuals, last year's comparables and variance analysis in one place, in the format their process requires. If it did, they would use it. The spreadsheet exists because it is faster than the alternative.

Start with the question. What does the finance team need to see to run the budget cycle without rebuilding it from scratch each quarter? What does operations need to see to catch a supplier change before it creates a discrepancy downstream? What does management need to see to make a resource decision without waiting two days for a report?

Those questions have specific answers. Build the platform to answer them. When it answers them faster and more reliably than a spreadsheet, the spreadsheet stops being necessary.

Audit the gap before retraining the team

When a platform is not being used, the instinct is to invest in adoption. More training, better documentation, a change management programme.

That investment is sometimes warranted. But start with a different question: does the platform answer what the business needs, in the format and at the speed the work requires?

If the answer is no, adoption work will not fix it. People are rational. They use the tool that does the job. If the spreadsheet does the job better than the platform, they will use the spreadsheet regardless of how many training sessions they attend.

Sit with the people who are not using the platform and understand what they need that it does not provide. That conversation usually reveals a short list of specific gaps. Some are configuration. Some are missing data sources. Others come from model logic that does not match the business definition. Almost none require replacing the platform.

A platform that runs the business does not have to be more expensive or more complex. It has to be built around the questions people ask, not just the data already available. The gap is usually smaller than it looks from the outside, and more fixable than the spreadsheet situation suggests.

If this pattern is familiar, a Data Platform Audit is designed to surface exactly that gap: what the platform provides, what the business needs, and what needs to change to close it.