Most businesses can answer thousands of questions instantly.
Stock levels. Transaction history. A client's last invoice. These are one-system questions — one click, one database, instant answer.
The question that stalls an organisation is the one that crosses two systems. Not because the data doesn't exist — it almost always does. But because it lives in a CRM here, a finance system there, a procurement tool somewhere else, and a spreadsheet that someone built three years ago that nobody fully owns anymore. Each one holds part of the picture. None of them were designed to talk to each other.
The result is that answering the most commercially important questions in a business often requires days of manual work — cross-referencing, chasing colleagues, copying data between systems — and the answer is already out of date by the time it arrives.
Key Takeaways
- The questions that genuinely stall a business are almost always cross-system questions — and the data needed to answer them almost always already exists, just not in one place
- Four common scenarios: a supplier doubles their price, two companies merge, maintenance work intersects with safety-critical residents, a client turns out to be a counterparty in another deal. Same root cause every time
- The cost is real and recurring — days or weeks of manual reconciliation, decisions made under pressure on partial information, conflicts that surface late or never
- AI doesn't fix this. It magnifies it. Models reason from whatever data they're given; if the data is fragmented and inconsistent, the outputs will be too
- Only 7% of enterprises say their data is completely ready for AI (Cloudera / HBR Analytic Services, October 2025). Connected, consistent data is now a commercial prerequisite, not a technical luxury
Here are four situations where that disconnect becomes a real problem.
When a supplier doubles their price
A manufacturer sources components from dozens of suppliers. One of them — a cable used across multiple product lines — announces a significant price increase. The immediate commercial question: how exposed are we?
To answer it, someone needs to know which products use that cable, which of those products depend on it exclusively, and which have an alternative supplier they could switch to. That information exists — in a product database, a procurement system, and a supplier management spreadsheet that three different people maintain.
Pulling it together takes days. By the time the analysis is done, the procurement decision has already been made under pressure, based on partial information.
The data existed. The answer didn't.When two companies become one
An acquisitive business completes a deal. The press release talks about synergies and combined capability. What it doesn't mention: the acquired company has a different CRM, a different product catalogue, and a different way of defining a "customer."
The integration question that follows — which clients exist in both businesses? Where are the supplier overlaps? Which contracts conflict? — typically takes months of manual reconciliation. It gets done in spreadsheets, which means no version control, no audit trail, and a very real chance that something important gets missed in the process.
When maintenance and safety intersect
A utility company schedules routine maintenance on a substation — a job that requires a temporary power cut to the surrounding area. Standard procedure.
What isn't standard: knowing whether any of the affected households has a critical power dependency. A resident on home oxygen. Medical equipment that cannot afford an interruption. That information might exist somewhere in the organisation — but it isn't typically connected to the asset record for that specific substation.
With the right data structure, that link is explicit. The maintenance record surfaces everything that would be affected — including a flag, a name, a contact number. The team knows what they're walking into before they act, not after.
The difference between those two outcomes isn't more data. It's data that connects.
When a client is also a counterparty
A financial services firm has a client in their wealth management book. That same client is also a director of a company that has just become a counterparty in a corporate transaction the same firm is advising on for another client.
Does anyone flag that? In most firms, no — because client records, counterparty records, and live deal records live in separate systems with no line between them. The conflict sits there, invisible, until someone eventually surfaces it manually. Or doesn't.
Why this matters more right now
Each of these is a business problem that happens to have a data cause. But they're becoming more urgent for a specific reason: AI.
AI systems are only as reliable as the data they reason from. When a model is fed data that lives in disconnected silos — different definitions, conflicting records, no single agreed version of a customer or product or counterparty — the outputs reflect that. The model doesn't know the data is inconsistent. It draws conclusions from whatever it's given.
The organisations that get real commercial value from AI over the next few years won't necessarily be the ones with the best models. They'll be the ones where the data underneath those models is connected, clean, and consistent — so that when a question crosses systems, there's a real answer waiting.
Most aren't there yet.
Which of these scenarios resonates most with what you see in your industry? I'm curious whether the supply chain and M&A examples are more universal, or whether the financial services conflict scenario is one that comes up more than people admit.
