Nobody decides to run their business on scattered systems. It accumulates: a CRM chosen in one era, an accounting package in another, a quoting tool someone bought on a card, and the spreadsheets that quietly glue it all together. Each decision made sense at the time. The estate they add up to serves nobody.
The direct costs are easy to list: licence fees, duplicate data entry, the hours lost to re-keying. The expensive costs are the ones that never appear on an invoice.
The question tax
In a connected business, a question like "which customers renew next quarter, and what are they worth?" is a report. In a scattered one, it's a project: an export from one system, a lookup against another, an afternoon of someone's time, and an answer that's stale by the time it's assembled.
Organisations adapt to this the way people adapt to a slow commute: they stop noticing. Decisions quietly narrow to the questions that are cheap to answer, and the ones that matter most (retention, margin by segment, capacity) get answered rarely, and with least confidence.
The version-of-the-truth problem
When the same fact lives in three systems, the systems will disagree: not occasionally, structurally. A customer's renewal date is amended in one place and nowhere else; a price is updated in the quoting tool but not the ledger. Every discrepancy costs a reconciliation, and every reconciliation erodes trust in all three numbers.
The tell is behavioural: before anyone acts on a figure, they check it against their own spreadsheet. Once that habit sets in, the organisation isn't really using its systems. It's using private copies of them.
The key-person dependency
Scattered estates run on institutional knowledge: the person who knows which export to run, which fields lie, which workaround keeps month-end moving. That knowledge rarely survives a handover, and it never appears in a risk register until the person who holds it resigns.
What centralising actually means
The fix is not one giant system that does everything. Those programmes carry their own well-documented failure modes. It means one governed core that holds the facts the business runs on, with the surrounding tools connected to it rather than competing with it.
Done in phases, the work pays as it goes: the highest-value data first, the noisiest reconciliation retired early, integrations replacing re-keying one process at a time. The end state isn't a single monolith. It's an estate that behaves like one system, because the facts only live in one place.
- One governed record for each fact the business depends on
- Integrations doing the copying that people do today
- Reports drawn from the system, not assembled around it
- Institutional knowledge captured in software, not individuals
Where to start
Not with a platform selection. Start by mapping where the facts actually live (every system, every spreadsheet, every private copy) and what each one feeds. The map is usually revealing enough to set the sequence on its own: the reconciliation that consumes the most time, the dependency that carries the most risk, the question the board keeps asking that takes a week to answer.
That map is a discovery exercise, and it's how we begin every centralisation engagement, because the plan it produces is worth having whoever does the building.
