Why "More Data" Is the Wrong Fix for Operational Gaps

"We need better data." Notice, the next time you hear this sentence in a leadership review, how fast the whole room nods along. It might be the most common sentence spoken in operations meetings anywhere in the world, and one of the least questioned. Something isn't working, the current explanation for why feels thin, and the room reaches almost automatically for the same fix: more data, one platform, a single source of truth. It sounds responsible. It sounds like the answer a serious leadership team is supposed to give. Across plants in several countries and more industries than most would expect to have in common, it's usually the wrong diagnosis, more often than not. It's worth understanding why the wrong diagnosis feels so right in the moment.

The comfort of asking for more datalinkshare

There's a reason "we need more data" is everyone's first instinct, and it isn't laziness or a lack of rigor. If anything it's the opposite. Asking for more data is comfortable in a way the real answer rarely is. Nobody in the room has to say a decision has no clear owner. Nobody has to admit an escalation rule got quietly abandoned two years ago during a reorganization, and that no one revisited it because nothing catastrophic had yet forced the question. And no two departments have to sit across a table and admit they've never actually agreed on what a shared term means, even though both have been reporting it with total confidence for years.

Those are uncomfortable things to say out loud in a room full of peers who will remember you said them. "We need better data" asks nobody to admit anything personal or organizational. It turns what is, underneath, an ownership gap or a governance gap into a technology project, and technology projects feel fundable and fixable in a way ownership gaps simply don't. You can put a data platform on a project charter. You can't easily put "our escalation process quietly died and nobody noticed" on a project charter, even though fixing the second one is usually cheaper, faster, and a lot closer to the actual pain everyone's feeling.

So the data warehouse gets commissioned. The single source of truth initiative gets a budget line, a sponsor, a steering committee that meets monthly to review a Gantt chart. A year or two later, when the new platform finally goes live, on time even if you're lucky, the same operational surprise happens again, almost exactly as before. The room ends up a little more confused than it was at the start, because now there's genuinely better data. Cleaner, faster, more accessible than before. And the underlying problem is still sitting there, completely unmoved, just better lit.

This arc plays out often enough that it no longer surprises anyone who has watched it closely. What's actually worth sharing is what separates the organizations that break the pattern from the ones that keep repeating it, because the difference is smaller and more available than most people expect. It usually comes down to whether anyone actually stopped to ask what specific decision the data was supposed to serve, before signing off on the budget for a platform that would take a year or more to build.

Three questions that expose whether data is really the constraintlinkshare

Before committing budget to a data project, it's worth spending twenty minutes testing the real diagnosis instead of accepting the comfortable one. Three questions do almost all the work; some version of them has come up in dozens of these conversations, in plants and boardrooms that otherwise had very little in common.

open_in_full

First: can you point to the specific decision that failed, and name who was actually supposed to make it? Not a department, not a function, not "operations." A role, a person, someone you could call on the phone right now and ask what happened.

Second: did that person actually have the information they needed when the decision needed to be made, even if it wasn't perfect or complete? Or did the failure happen somewhere else entirely, in an escalation that never fired, an approval that sat unopened in someone's inbox for four days, a handoff between two teams that neither one fully considered its own responsibility?

Third, and this is the one that does the most diagnostic work: if you handed that same person perfect, flawless data tomorrow, would the exact same failure be structurally prevented from happening again? Or would it just become a better informed version of the identical gap, because the actual problem was never really about the quality of the information at all?

If the honest answers point cleanly to missing or incorrect information, the person had authority, had a clear role, was ready to act, and simply didn't have what they needed, then you likely do have a genuine data problem, and it deserves to be solved properly. But if the answers keep circling back to missing ownership, a broken handoff nobody quite owns, or an escalation rule everyone assumed still existed but nobody could actually describe with confidence, more data won't fix what's actually broken. You'll have spent real money making a decision gap more expensive to maintain, and dressed it up as progress.

What a rapid diagnostic looks like insteadlinkshare

A rapid diagnostic doesn't need to become its own formal exercise, complete with a steering committee that mirrors the one it's trying to avoid. It needs a week, maybe two at the outside, a handful of structured interviews with the people who sat closest to the actual failure, and one simple, almost stubborn discipline: trace the specific incident backward, step by step, until you find the precise point where it actually went wrong. Not where it became visible to leadership. Where it actually went wrong. Those two points are often different, sometimes by weeks, and the gap between them is usually where the real learning lives.

This is best thought of as reconstructing a chain of custody. Someone made a decision, or failed to make one, at a specific moment, based on specific information, with specific authority or the lack of it. Walking that chain backward, conversation by conversation, almost always surfaces the actual break far more precisely than reviewing the aggregate data ever could, because aggregate data smooths over exactly the kind of specific, one time judgment call that tends to be where things actually go sideways.

This kind of diagnostic produces something a large data project structurally can't: a short, specific, ranked list of what actually needs to change, ordered by how much it would have prevented the original failure had it already been fixed. Some items on that list might genuinely turn out to be data gaps, a field that wasn't captured, a system that didn't talk to another system. Most, more often than not, turn out to be about ownership, escalation, or a shared definition nobody had actually agreed on, however long everyone had been using the term as if they had.

When more data genuinely is the answerlinkshare

None of this means data investment is never warranted. That would be just as lazy a conclusion as the one being argued against here. Some organizations do have real, structural data problems. Master data that simply doesn't reconcile across systems no matter how clearly you name the decision it's meant to serve. Interfaces that silently drop or corrupt information somewhere in transit, with nobody the wiser until the numbers stop making sense. Historical records too thin, too inconsistent, or too recently digitized to actually support the decision at hand.

When any of those is the real constraint, the rapid diagnostic is exactly how you find that out. Cheaply, in two weeks, before the budget is committed. Not expensively, eighteen months into a platform build, when the sunk cost makes it much harder to admit the diagnosis was wrong from the start.

The delivery problem that turned out to be an org chart problemlinkshare

A leadership team wanted to commission a year long data warehouse initiative, aimed squarely at chronic delivery reliability problems that had been frustrating customers and internal teams alike for the better part of two years. The instinct made sense on paper. Deliveries were unpredictable, the existing reporting was fragmented across systems, and a unified platform felt like the obvious, responsible next step.

Before committing to that scope, a two week diagnostic was agreed as due diligence before the larger spend. It consisted of a handful of interviews with people in planning and dispatch, and a disciplined tracing of the last dozen missed deliveries back to their actual origin point, rather than the point where leadership first noticed them.

The pattern that emerged wasn't a data gap at all, and it surprised more than a few people in the room when it came out. It was an escalation rule between planning and dispatch, a specific, previously well understood protocol for what happened when a shipment was at risk of missing its window, that had quietly stopped being followed after a reorganization roughly two years earlier. Nobody had decided to abandon it. It had simply fallen through the cracks of an org chart change, the way a shared responsibility often does when the two people who used to informally coordinate it end up reporting to different managers with different priorities.

Fixing it took one workshop, a written and formally agreed escalation protocol, and a short trial period to make sure it actually held under real conditions. The year long data platform was never built, because the problem it had been proposed to solve had already been solved, in full, for the cost of two weeks of interviews and one afternoon workshop. That engagement stands out even now, mostly because of how close the organization came to spending a genuinely large sum solving a problem that, underneath the surface, had nothing to do with data at all.

Test the diagnosis before funding the curelinkshare

A data project is an expensive thing to be wrong about, in both money and, often the more painful cost, time. Every month spent building a platform aimed at the wrong root cause is a month the actual problem continues uninterrupted, quietly compounding, while everyone's attention and budget is focused elsewhere.

Before the next data initiative gets a budget line in your organization, spend the twenty minutes, or if the stakes are higher, the two weeks, actually testing whether the real gap sits in the data itself or in who owns the decision the data is meant to serve. A short diagnostic is dramatically cheaper than a data platform built on a diagnosis nobody stress tested first, and it has the added benefit of being fast enough that you'll know within weeks, rather than years, whether you've actually found the real problem.

If you want a simple starting discipline, try this the next time someone in your organization says "we need better data." Ask them to name the specific decision the data would change, and who currently owns it. If the answer comes quickly and specifically, you're probably looking at a real data gap. If the answer gets vague, or turns into a description of a process rather than a person, you've likely just found your actual diagnosis, and it isn't the one on the original slide.

A habit worth building into every leadership reviewlinkshare

The organizations that get best at this over time don't treat the three question test as a one time exercise reserved for big, contentious decisions. They fold it quietly into the normal rhythm of how they run reviews. Whenever a number gets challenged, whenever a result surprises someone, the first question isn't who has the wrong data. It's what decision was this supposed to inform, and did that decision actually have an owner.

open_in_full

It's a small discipline, almost invisible in the moment, but it changes the character of the whole review over time. Arguments about whose spreadsheet is correct get shorter and rarer, not because anyone bought better software, but because the room has quietly gotten better at asking the question underneath the question. That habit, more than any platform, is usually what actually protects an organization from spending its next budget cycle solving the wrong problem all over again.

Disclaimer

Industry situations in this chapter are composite illustrations unless explicitly attributed to a public source. They are not claims about any particular company, plant, vendor, or incident. External standards, research, and public case studies should be verified before publication. Implementations must be validated against local safety, quality, cybersecurity, regulatory, contractual, labour, privacy, and data-governance requirements. AI recommendations and autonomous actions should remain within clearly defined human authority, operational controls, and tested recovery procedures.

#SupplyChainManagement #ManufacturingLeadership #RootCauseAnalysis #SteelIndustry #OperationsExcellence #ProcessImprovement #PlantManagement #DecisionMaking #Industry40 #BusinessDiagnostics