You Don't Know How Many Screws You Have

They don't know how many screws they buy.

It sounds like a joke, but it isn't. It's the most concrete way to describe a company where information exists but doesn't talk to itself. Where data is scattered, hidden between departments, versions, and tools. And where the outcome is always the same: if nobody can find it, trust it, and use it, it may as well not exist.

The problem isn't screws. Screws are the funny example. The real problem is that basic operational knowledge is fragmented. And that fragmentation has an uncomfortable consequence, organizations can produce endless reports and still be unable to answer simple questions with confidence; especially the ones that affect costs and timelines.

In these environments, the same pattern repeats. There are multiple numbers for the same question, because the "truth" lives in too many places: different ERPs, databases, spreadsheets, internal tools, and improvised pipelines. Dashboards could exist, but trust doesn't. Answering something simple isn't a query; it's a meeting. Not because people are incompetent, but because the data becomes distributed and invisible. Not actively hidden, just structurally unreachable across boundaries.

This is easy to understand when you've seen how large organizations evolve. Departments start behaving like nations: clear borders, their own language, local incentives, and very little interoperability. Sometimes we call it bureaucracy. Sometimes we call it "alignment". The label doesn't matter, the effect does. Each part can function, but the whole can't explain itself.

Culture makes it worse. The "official" spreadsheet appears, nobody can fully audit, and everyone defends because it keeps their world moving. At that point, the conversation degrades. It stops being about what's happening and becomes about who is right. Data turns into a shield, a weapon, or a form of power.

The cost of this isn't only financial, it's an invisible tax paid in slow decisions and constant friction. Decisions get delayed because every number comes with doubt, and decisions get worse because they're made from partial views. Time is spent reconciling sources instead of solving real problems. And the irony is that all of this happens in companies that "have data". They have plenty of it. What they don't have is what matters: response capability.

This is where it helps to puncture a common myth: BI is not dashboards. Dashboards can be useful, but they can also be a perfect mask. They can create the feeling of control without fixing anything underneath. The argument moves from spreadsheets to charts.

BI is response capability. The ability to answer quickly, consistently, and confidently the questions that affect costs and timelines. And that capability doesn't come from "connecting sources." It comes from a contract.

The "single source of truth" is often imagined as a centralized system: a warehouse, a lakehouse, a tool. But in practice, what's missing is earlier than technology. What's missing is agreement. A data contract, whether anyone calls it that or not, answers the boring but fundamental questions. What exactly does this metric mean? Who owns it? Where does it come from? What transformations does it go through? What quality threshold makes it usable for decisions?

Without that contract, centralizing data just centralizes chaos. You don't get clarity; you get industrialized confusion. With a contract, visualization stops being decoration and becomes an interface for something stable.

The "screws" line works because it exposes the difference between storing information and having operational knowledge. Data without use is worthless. But worse than that, data without a shared contract doesn't just fail to help, it actively creates noise, debate, and hidden costs.

If an organization can't answer how many "screws" it has (whether those screws are literal parts, costs, or timelines), then it doesn't have a BI problem. It has a design problem, boundaries, ownership, and agreements. And no amount of visualization fixes that.