Imagine a scene that plays out so often, in so many countries, that it could be drawn from memory alone. It's the second Tuesday of the month. Ten or twelve people are in a conference room, or dialed into a call, for the monthly operations review. Someone pulls up a slide showing finished goods inventory, or on time delivery, or yield. Pick the metric, it honestly doesn't matter which one. And someone else, staring at a different spreadsheet on their own laptop, says quietly, "That's not what I have."
That's the meeting, for the next fifteen minutes. Planning has one number. The warehouse has a slightly different one. Finance has a third, built for its own working capital purposes, that doesn't match either. Nobody in the room is lying. Nobody built their number carelessly. Each version made complete sense to the team that built it, for the purpose that team had in mind. But three defensible numbers walked into the same room, and now everyone is negotiating whose reality is correct before a single decision actually gets made.
That room shows up on three continents. In steel plants, in chemical plants, in fast moving consumer goods operations, with finance directors and plant managers and CIOs who couldn't otherwise be more different from one another. And the sentence that follows the argument is remarkably consistent. We need better data. We need a single source of truth. Once everything's in one dashboard, this stops happening.
One may nod along with that sentence. It sounds responsible. It sounds like the mature, disciplined thing to say in a room full of peers. It takes a surprising number of these meetings, across a surprising number of industries, before the pattern underneath it becomes hard to ignore: the organizations that said this sentence most confidently were, disproportionately, the ones that had already tried to fix it with more data, and were now sitting in the exact same argument, just with a more expensive dashboard behind it.
Why more data feels like the safe answer, and why it usually isn't
Here's why "we need more data" is such an attractive diagnosis, and it's worth saying with real sympathy for everyone who reaches for it. It's nobody's fault. It doesn't require a single person in that room to say, out loud, in front of their peers, that a decision has no clear owner. It doesn't require anyone to admit an escalation path was quietly abandoned two reorganizations ago and nobody noticed, because nothing bad had happened yet to force the question. And it doesn't require two departments to sit down and hash out that they've been using the same word, "available," "committed," "on time," to mean two different things for years, without ever colliding hard enough to discover it.
Getting better data sidesteps all of that. It converts an uncomfortable organizational conversation into a comfortable technology project. Technology projects have vendors, timelines, budgets, steering committees. They feel fundable in a way that "nobody in this room actually owns this decision" does not. You can put a data warehouse initiative on a project plan. You cannot really put "admit the escalation rule died in 2019" on a project plan, even though the second one is usually cheaper, faster, and a lot closer to the actual problem.
So the organization commissions the data warehouse. The single source of truth initiative gets a budget line, a steering committee, a name with "2.0" or "unified" somewhere in it. Eighteen months and a meaningful chunk of capital later, the same argument happens in the same meeting. The dashboards are genuinely better. The data is genuinely cleaner. And the room is a little more bewildered than before, because now there's better data, and the problem is still there, staring back at everyone from a nicer looking screen.
None of this is meant as cynicism about data investment. That point deserves its own return, because some organizations really do have a data problem, and it's worth solving properly when they do. It's worth saying plainly, because too many capable, well intentioned teams have spent a year and a large budget solving the wrong problem with real skill, and avoiding that outcome matters more than watching it happen for the hundredth time.
What a decision is actually made of
The plants where this argument genuinely stops, not gets papered over for a quarter, but actually stops recurring, share something specific. At some point, someone in the room stopped asking what data do we need and started asking a narrower, less comfortable question. What decision is this data actually for?
That's a different question, and once you sit with it, it turns out to have a fairly specific shape.
A real decision needs four things, best pictured as load bearing walls. Take one away and the rest doesn't really stand, no matter how good everything else looks. You need an owner: one person, or one clearly defined role, accountable for actually making the call. Not a committee, because committees are wonderful at diffusing responsibility until nobody in the room feels it land on them personally. You need evidence: a specific, agreed set of inputs that owner is entitled to trust, which is a very different and much smaller set than everything that happens to be measured somewhere in the business. You need authority, meaning the owner can actually act on what the evidence tells them without pausing to collect three more signatures first. And you need a consequence, something observable that changes in the world because the decision got made, which also happens to be how you'd eventually know if it had been the wrong one.
Most of the arguments about whose number is right are really arguments happening in the complete absence of this structure. Three functions each built a defensible version of a metric for their own legitimate purposes, and now everyone's trying to use all three versions to make a decision that, and this is the part nobody says out loud, no single person or role actually owns. The number isn't broken. The decision underneath it was never assigned to anyone in the first place.
A twenty minute test for which problem you actually have
You don't need a consulting engagement to test this. You need about twenty minutes and the number your teams argue about most.
Ask four questions in order, and resist the urge to answer any of them vaguely.
- Who is actually supposed to act on this number? Not "the planning team," but which specific role, named.
- What would that person concretely do differently at different values of the number? If it were ten percent higher, would anything real actually change, or is the number just informational?
- Does that person currently have the authority to act on what it tells them, without needing further sign off from somebody else?
- And what actually happens on the shop floor or in the warehouse if that person acts on bad information versus no information at all? Is the downstream consequence specific, or is it fairly abstract?
If those four questions produce clean, specific answers, and the number is still wrong at the end of it, you have a genuine data problem, and it's worth fixing properly without hesitation. Typically, though, that's the less common outcome. More often, the questions expose something else entirely. Nobody is quite sure who acts on the number, or the person who's nominally supposed to act doesn't actually have the standing to do so without collecting sign offs that quietly dilute the decision back into the committee it was supposed to escape in the first place. That's a decision problem wearing a data costume. No dashboard, however elegant, fixes that. You can buy the best reporting layer on the market and still have nobody empowered to use it.
What actually changes once the decision is named
The shift, when it happens, is almost anticlimactic, which is exactly why it's so easy to underestimate beforehand. You're not building anything new. You're not commissioning a platform. You're doing something that sounds almost too simple to be the answer: naming who owns the call, agreeing what they're allowed to trust, and confirming what they're actually allowed to do about it.
But the effect on the rest of the organization is wildly out of proportion to how small that step sounds. Once a decision has a named owner, something strange happens to all the reporting infrastructure that had quietly grown up around the unowned version of it. A large share of it turns out to be unnecessary. People stop needing to see every competing version of the number, because they're no longer each privately, informally trying to make a decision that was never actually assigned to them. The reconciliation meetings shrink. The "that's not what I have" moment stops happening, not because the data got better, but because there's now exactly one person whose version counts, and everyone else's version quietly turns back into useful context instead of a competing claim to truth.
Leadership teams have cut a standing monthly reconciliation exercise from forty five minutes to functionally zero purely by doing this. No new system, no new headcount. Just a decision that finally had an owner where before it had three well meaning departments each partially holding the pen.
The steel producer with three dashboards
Here's how this played out at a mid sized steel producer, a shape that keeps repeating, with small variations, across a dozen other plants since.
They had three near identical dashboards tracking finished goods inventory. One was maintained by planning, built to support the production schedule. One belonged to the warehouse team, built around physical stock movement and space allocation. One had been built by finance, for its own working capital and cash flow visibility. All three were accurate, in the sense that each one correctly measured what it had been designed to measure. None of them agreed with each other, because "finished goods inventory" meant something subtly different to each team. Planning counted things at the point of production completion. The warehouse counted at the point of physical receipt. Finance's timing followed yet another convention tied to invoicing.
Every month, the leadership review opened the same way. Ten to fifteen minutes reconciling why the three numbers didn't match, a ritual so familiar that people had started timing their coffee refills to skip it. Only after the reconciliation would anyone get to an actual decision, usually about how much finished stock to release against a pending customer order.
The instinct in the room, understandably, was to commission a fourth dashboard. A single, unified, "true" inventory view that would finally settle the argument. A different question got asked instead: who actually decides, on a given day, how much finished stock gets released against a customer order? Not which system shows the number. Who makes the call.
It took some digging to get a clean answer, because the honest answer was "it depends, and sometimes three people weigh in before it happens." It was named properly: a single planning role, given a clearly defined evidence set (one agreed inventory figure, sourced consistently, at one agreed measurement point), and the explicit, standing authority to release stock against an order without needing a second sign off from either the warehouse or finance.
Once that was settled, something clarifying happened. Two of the three dashboards turned out to be almost entirely irrelevant to that specific decision. They weren't wrong. The warehouse dashboard remained genuinely useful for space planning, and finance's view stayed useful for cash forecasting. They simply weren't for this decision, and had never needed to be. The monthly reconciliation ritual disappeared within two review cycles, not because anyone rebuilt the underlying data, but because nobody needed to argue over three versions of a number that had never actually been tied to a single decision. Finance and the warehouse kept their own views for their own purposes. The planning role kept the one version that mattered for stock release. Everyone was, quietly, relieved.
Before you commission the next data project
None of this is meant as an argument against ever investing in data, because that would be its own kind of oversimplification, and a dishonest one. Some organizations genuinely do have a real, structural data problem. Master data that doesn't reconcile across systems no matter how carefully you name the decision behind it. Interfaces that silently drop or corrupt information in transit. Historical records too thin or too inconsistent to support the decision at hand even once ownership is completely clear. When that's the actual constraint, fixing it properly, with real investment, is exactly the right call, and no amount of decision naming will substitute for it.
The point isn't that data investment is always wrong. It's that it's worth testing, cheaply, which problem you actually have before the budget gets committed, because the two problems get fixed in completely different ways, at completely different costs, on completely different timelines, and only one of them requires new technology at all.
Where to start, this week
If you want to try this before your next review meeting rather than after it, here's the smallest version worth trying. Pick the one number your teams argue about most reliably. You already know which one it is, it's the one that makes people sigh slightly when it comes up on the agenda. Before the meeting, spend twenty minutes with the four diagnostic questions above, ideally with the two or three people who actually touch that number. Write down the answers plainly, even the uncomfortable ones. If you find a clean owner, clear evidence, real authority, and an observable consequence, good, you likely have a genuine data question worth investing in. If you find a gap instead, an owner who isn't sure they're the owner, an authority that quietly needs two more approvals than anyone admits to, name that gap out loud in the next review, before anyone reaches for a new dashboard to paper over it.
The next time a number gets disputed in your review meeting, try naming the decision before you order the data. The argument, more often than not, was never really about the data at all. It was about a decision nobody had gotten around to actually assigning, dressed up very convincingly as a technology gap.
#SupplyChainManagement #ManufacturingLeadership #DataDrivenDecisions #SteelIndustry #OperationsExcellence #DigitalTransformation #PlantManagement #DecisionMaking #Industry40 #DataStrategy