Manufacturing Data Quality: Garbage In, Garbage Out

Manufacturing data quality is the degree to which a plant's data is accurate, complete, consistent, timely, valid, and free of duplicates, good enough to trust for a decision without checking it by hand first. When it is poor, every dashboard and AI built on top of it inherits the errors and presents them with a straight face.

The phrase "garbage in, garbage out" is old, but it has never mattered more. Plants are pouring floor data into analytics and AI at exactly the moment those tools are least forgiving of dirty inputs. A human reading a downtime log can silently correct for a mislabeled reason code; a model cannot. This is an honest look at where plant data goes wrong, how to measure it, and how to clean it without boiling the ocean.

What is manufacturing data quality?

Manufacturing data quality is a measure of whether your operational data is fit to use. It is not about having more data, most plants already drown in readings, but about whether the data you have can be trusted for the decision in front of you. A tag that reads 0 because a sensor died looks identical to a tag that reads 0 because the machine truly stopped. Only quality controls tell them apart. The plants that struggle most with analytics are almost never the ones without data; they are the ones whose data cannot be trusted, so every number gets re-checked by hand and every meeting relitigates whose spreadsheet is right.

Quality is measured across a small set of well-established dimensions. The concept was first formalized in 1996 by researchers Richard Wang and Diane Strong, and the industry has since settled on six that translate cleanly to a plant floor. Poor quality in any one of them is enough to make a number untrustworthy, which is why data quality is inseparable from the underlying data model and from the data silos that let the same fact drift apart across systems.

Why does AI fail on dirty data?

AI fails on dirty data because it cannot tell the difference between a real pattern and an artifact of a broken sensor. A person knows that the packaging line does not actually run at 0 and 300 units a minute in the same shift; a model just sees two data points and fits a line through them. The output looks authoritative, a clean chart, a confident recommendation, which makes bad data worse, not better, once AI is involved. The error is now laundered through a system people are inclined to trust.

The specific failure modes are predictable. Missing reason codes teach a model that most downtime is "unknown," so its top recommendation becomes useless. Duplicate stops double-count losses, so the AI over-prioritizes a machine that is actually fine. Timestamp skew between systems makes cause look like effect. None of these are exotic; they are the everyday texture of plant data, and they are exactly what an analytics or AI layer will amplify if no one cleans the input first.

There is a deeper reason the AI era punishes bad data harder than the dashboard era did. A dashboard is passive: a person looks at a suspicious chart, frowns, and goes to check the machine. An AI layer is meant to act, to trigger an alert, reprioritize a work order, or recommend a setting, often faster than a human reviews it. That shortens the distance between a bad input and a real consequence on the floor. The payoff for clean data rises in exact proportion to how much you let the system act on it, which is why data quality has quietly become the gating factor for whether AI is safe to trust at all.

What are the most common data-quality failures in plants?

A handful of failures show up in nearly every plant, and naming them is the first step to catching them.

• Missing tags. A sensor drops offline and its tag simply stops reporting. Downstream, the gap is often filled with the last value or a zero, both of which lie.
• Sensor drift. A gauge slowly wanders out of calibration, so readings degrade gradually rather than failing outright, the hardest error to spot, because nothing looks broken.
• Duplicate downtime reasons. "Jam," "jammed," "Jam - infeed," and "INFEED JAM" are four labels for one problem, so no Pareto chart can rank it correctly.
• Inconsistent units. One line logs pounds, another logs kilograms, and a rollup silently adds them together.
• Timestamp skew. Two systems' clocks differ by minutes, so events land out of order and cause looks like effect.

The duplicate-reason problem deserves special attention because it hides in plain sight. Free-text or loosely governed reason codes multiply until the same stop is recorded a dozen ways, and every count built on them is quietly wrong. Collapsing that mess into one governed taxonomy is often the single highest-return data-quality fix a plant can make, and it ties directly to honest downtime tracking and machine monitoring.

What does poor data quality actually cost?

The cost of bad data is rarely a line item, which is exactly why it survives budget after budget. It shows up first as rework: analysts and engineers spend hours reconciling numbers, hunting duplicates, and hand-correcting units before anyone can even start the real analysis. Industry studies of knowledge work consistently find that people burn a large share of their time finding, cleaning, and validating data rather than using it, and a plant floor is no exception.

The second cost is worse because it is invisible: decisions made on wrong numbers. A maintenance dollar spent on the wrong machine, a capital request built on a double-counted loss, a supplier blamed for scrap that came from a miscalibrated gauge. None of these show up as "data quality" in a report, but every one of them traces back to a number nobody could trust. The third cost is the slowest to appear and the hardest to undo, eroded trust. Once operators and managers learn that the dashboard lies, they stop looking at it and go back to their own spreadsheets, and the plant quietly returns to the silos the system was bought to eliminate.

How do you improve manufacturing data quality?

You do not fix data quality with a one-time cleanup; you fix it by building controls into how data is captured and moved. The steps below go from cheapest to most durable.

1. Profile what you have. Before cleaning anything, measure each dimension on your worst-behaved data set, count missing reason codes, list duplicate labels, check unit consistency. You cannot fix what you have not sized.
2. Govern the reason codes. Replace free text with one managed taxonomy, and map every legacy alias to a single code. This alone rescues most downtime analysis.
3. Validate at the point of capture. Reject out-of-range values, enforce required fields, and constrain formats when data is entered, not weeks later in a report.
4. Detect drift and dropouts automatically. Alert when a tag flatlines, goes stale, or wanders outside physical limits, so a dead sensor is caught in minutes, not at month-end.
5. Synchronize clocks and units. Put every system on one time source and one unit convention so events and totals line up.
6. Fix it upstream, once. When you find a bad source, correct it at the source rather than patching each report, a fix applied once at capture beats the same fix applied forever downstream.

By the numbers

The modern framework of data quality dimensions traces to Richard Wang and Diane Strong's 1996 study "Beyond Accuracy: What Data Quality Means to Data Consumers," which the industry has since distilled into the six dimensions used above (IBM: data quality dimensions). Advanced-technology adoption across U.S. manufacturing continues to trail the broader economy, with inconsistent and disconnected data among the recurring barriers documented in the Census Bureau's survey work (Census BTOS). Where Harmony fits: Harmony is an AI-native operating system for manufacturing that connects machines, ERP/MES/QMS software, and paperwork into one real-time layer, applying governance and validation as data is captured, so the numbers a plant acts on are clean before AI ever touches them. See the plant-tech context in what an MES does the plumbing in IIoT or how CLS unified its floor.