Manufacturing Data Quality Audit: How to Find Out If Your OEE Numbers Are Lying

Key takeaways

• Data quality audit = a structured check of whether the data feeding OEE, CMMS, and other reporting matches ground truth.
• One-day audit protocol: pick a line, compare reported data against PLC log + video + in-person observation for a single shift.
• Most audits find measurable error on cycle counts and much larger error on reason codes.
• The audit is uncomfortable to run because it exposes problems. It is also the only way to know if the numbers are real.
• Findings drive the data quality improvement program for the next quarter.

Short answer: Start small, with one line, one shift, three independent sources of truth, and a ranked list of what to fix. See also Plant Floor Data Quality.

Why run an audit

Reported data has three quality risks:

• Accuracy. Does the reported value match ground truth?
• Completeness. Are events being missed?
• Timeliness. Is the data captured when the event happens or hours later?

Without an audit, plants assume these are fine. They usually are not.

The one-day audit protocol

1. Pick a line. One representative line for one shift.
2. Capture ground truth in parallel. PLC raw log, video of the operator/equipment, observer in person.
3. Compare to reported data. What the OEE platform / CMMS shows for the same window.
4. Identify discrepancies. Cycle count mismatches, missing downtime, wrong reason codes, late timestamps.
5. Calculate error rates. Per data type (cycle count, downtime, reasons, parts, labor).
6. Identify root causes. Manual entry, threshold settings, missing instrumentation, training.

What audits typically find

Cycle counts: manual end of shift entries drift from the real count, while PLC counts are usually close to exact once the counting signal is checked.

Downtime totals: under-reported, because micro-stops and brief stops never get logged.

Reason codes: the least reliable field, with "Other" overused and wrong categories selected.

Parts: under-reported, because parts are pulled without logging.

Labor hours: estimated rather than tracked.

The size of each gap varies by plant. Your own audit gives you the real percentages; record them as the baseline for next quarter.

What to do with the findings

1. Rank errors by impact. Which errors most affect OEE, MTBF, cost reporting.
2. Address the worst first. Usually cycle count automation or reason code taxonomy.
3. Set targets. Cycle count error under 2%, downtime under-report under 5%.
4. Re-audit quarterly. Trend the error rates.

Common findings

1. Cycle counts manually entered at end of shift. Almost always wrong. Automate from PLC.

2. Reason code "Other" rate above 10%. Taxonomy is missing categories.

3. Downtime threshold set too high. Micro-stops missing. Lower the threshold.

4. PMs marked complete on paper but not actually done. Compliance metric is inflated.

5. Work orders closed with placeholder labor hours. Cost reporting noisy.

How to make the audit non-threatening

The audit can feel like inspection. Frame it as system improvement:

• "We are auditing the data flow, not the operators."
• "Findings help us fix the system that asks operators to do impossible data entry."
• "The goal is cleaner numbers we all trust, not blame."

Operators often welcome the audit when framed this way, they know the data is dirty and have wanted someone to address it.

Common mistakes

1. Audit without follow-up. Findings without action produce cynicism.

2. Audit only when something has gone wrong. Routine audits catch problems before they cause failures.

3. Audit only one data type. Cycle counts may be clean while reason codes are noise. Audit broadly.

4. Treating findings as personal failures. The system caused the dirt; the system must be fixed.

How a modern OEE platform supports audit

A modern OEE platform exposes audit-friendly data: raw PLC logs available alongside computed metrics, reason code timestamp vs event timestamp, automated discrepancy detection between operator and PLC counts.

Fabrico supports this kind of audit in practice: machine signals come straight from the PLC, so cycle counts and stoppages do not depend on manual entry, and where computer vision is installed, each stoppage is linked to video of the moment, so reason codes can be checked against what actually happened.

See how Fabrico captures this automatically, explore OEE for manufacturing or book a demo.

Related reading

• Plant Floor Data Quality
• Manufacturing Data Lake vs Data Warehouse
• Quality by Design vs Quality by Inspection
• OEE for Batch Manufacturing

Frequently asked questions

How often should I run a data quality audit?

Quarterly is typical. After major changes (new equipment, new product, new operators), run a focused audit.

Who should run the audit?

Cross-functional team: operations, maintenance, IT, quality. Single-function audits miss cross-cutting issues.

How much error is acceptable?

Highly use-case dependent. For OEE driving improvement decisions: under 5% error on cycle counts and downtime.

What if the audit finds bigger problems than expected?

Common. Treat as an opportunity. The audit is the path to cleaner data.

Can software audit the data automatically?

Partly. Discrepancy detection between sources can be automated. Root cause identification usually needs humans.