The Number That Left the Floor Isn't the Number on Your Dashboard

Here's a question most food manufacturers haven't sat with directly.

When you look at a production figure on your dashboard, how confident are you that it reflects what actually happened on the floor? Not approximately. Not directionally. Exactly.

For most operations, the honest answer is: reasonably confident, most of the time. Which is another way of saying: not entirely, and never completely sure when it drifted.

That uncertainty isn't random. It has a structure. And once you see the structure, the decisions being made from imperfect data stop feeling like a technology problem and start feeling like a system design problem. Which is exactly what it is.

#The journey a number takes

Follow a single production figure from the moment it's generated to the moment it informs a decision.

It starts on the floor. A line completes a run. Someone counts the output, or reads a meter, or checks a batch ticket. That number exists, accurately, for exactly one moment: the moment it's observed.

Then it moves.

First stop is the clipboard or the paper log. The number gets written down. Handwriting varies. Conditions on the floor vary. The person writing it might be moving fast, managing two things at once, working in a noisy environment with a pen that's running out. The transcription is usually right. Not always. Optimistically, about 95% of the time.

Second stop is the spreadsheet. Someone takes the paper log and enters the numbers into a system. Another human hand. Another opportunity for a digit to shift, a row to be entered in the wrong place, a number to be read incorrectly from handwriting that wasn't clear. The spreadsheet is more organised than the paper. It's also one step further from the source. Realistically, about 90% accurate at this point.

Third stop is the report. The spreadsheet gets pulled into a reporting format. Someone cleans it up, standardises the layout, fills in missing fields, makes it presentable for whoever is going to read it. Each of those steps is a judgment call. Each judgment call is a place where the number can shift again. By the time the report is finished, accuracy is sitting around 85%.

And then the report reaches the decision maker.

"I asked our operations manager once how confident he was in the weekly production figures. He said about 80 percent. I asked why not higher. He said because by the time they reach me they've been through four people and I know something changes every time."

Four people. Something changes every time. That's not a failure of process. That's the predictable outcome of a system where data moves through humans.

#The decisions don't know the data is wrong

Here's what makes this genuinely costly.

The decisions made from that 85% accurate report don't carry a confidence interval. They don't come with a footnote saying "based on data that may have drifted 15% from actual." They get made the same way they'd be made from a perfectly accurate report, because the person making them has no way of knowing where the number came from or what happened to it along the way.

Procurement orders get placed based on production figures that are slightly off. Inventory positions get committed against stock levels that haven't been verified since someone entered them into a spreadsheet three days ago. Customer delivery dates get confirmed against a capacity plan built on yield figures that were accurate when they left the floor and approximate by the time they informed the plan.

Each individual decision is reasonable given the information available. The problem is the information available is already wrong before anyone starts reasoning from it.

This compounds. A procurement decision made from a 15% degraded production figure creates an inventory position that's slightly off. That inventory position feeds next week's production plan. That production plan drives the following week's customer commitments. By the time the original error surfaces as a real operational problem, it has travelled through multiple downstream decisions and the original source is almost impossible to identify.

"We had a persistent inventory variance for months. When we finally traced it back, it started with a data entry error in a spreadsheet six weeks earlier. One wrong number, six weeks of compounding decisions built on top of it."

One wrong number. Six weeks of compounding decisions. That's not an edge case. That's what happens when data moves through people regularly enough that small errors become structural.

#Why the people aren't the problem

It's worth being direct about this because the instinct, when accuracy problems surface, is to address them through people. Better training. More careful data entry. Additional verification steps.

These interventions don't work, or rather, they work temporarily and then regress. Because the problem isn't the people. It's the design.

A system that requires a human to transcribe a number from a physical observation to a paper form, from a paper form to a spreadsheet, and from a spreadsheet to a report, is a system that will degrade data at every step. Not because the humans are careless. Because the system was designed with humans as the connective tissue between observation and record, and humans introduce variability by definition.

The solution isn't to make the humans more accurate. It's to remove them from the data transfer steps where accuracy matters most and where their involvement adds the most risk.

Capturing data at the source means the number that happens on the floor is the number that enters the system. One event. One record. No transcription. No intermediate step. No opportunity for the number to change between observation and dashboard.

The people on the floor aren't replaced. They're freed from being data transfer mechanisms so they can do the work that actually requires human judgment.

#What source capture actually changes

When data is captured at the source, the accuracy curve doesn't degrade. It stays flat.

For example, 500 units produced. 500 units in the system. 500 units on the dashboard. 500 units informing the procurement decision, the inventory position, the capacity plan, the customer commitment.

The same number, all the way through, because it was never handed off to a person to carry.

The downstream effect is significant. Procurement decisions built on accurate production figures are better procurement decisions. Inventory positions that reflect actual stock levels rather than last Tuesday's spreadsheet entry support more reliable customer commitments. Capacity plans built on real yield data rather than approximated weekly figures generate schedules that hold up rather than requiring constant manual revision.

None of this requires the team to work differently on the floor. It requires the system to work differently in how it captures what the team is doing.

"The first week we had real-time production capture I kept refreshing the dashboard because I wasn't used to trusting it. By week three I stopped second-guessing the numbers. That was a different way of working."

A different way of working. Not because the operation changed. Because the data finally reflected it accurately.

#The question worth sitting with

Take the most important production metric you look at every week. The one that drives your biggest decisions.

Trace it backward. Where does it start? How many steps does it take to get from the original observation to the number on your report? How many of those steps involve a human transferring it from one format to another?

Count the steps. Estimate the accuracy at each one. Then ask honestly whether the decisions being made from that number are being made from data you can actually trust.

The answer to that question is where the data design conversation starts.

Ready to see what your operation looks like when the number on the dashboard is the number that happened on the floor?

Book a demo at book a demo. We'll show you exactly where your data is travelling through people right now and what changes when it doesn't have to.