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

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

A 1-day data quality audit reveals whether your OEE and CMMS numbers reflect reality. A practical protocol that any plant can run.
Manufacturing Data Quality Audit: How to Find Out If Your OEE Numbers Are Lying
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 5-15% error on cycle counts, much higher 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: A manufacturing data quality audit is a structured check of whether reported data matches ground truth. The simplest version takes one day: pick a line, compare reported OEE inputs (cycle counts, downtime, reasons) against PLC logs, video, and in-person observation for a single shift. Most audits find meaningful errors. The findings drive the data quality improvement program. 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: 5-15% error when manually entered. Under 1% when from PLC.

Downtime totals: 10-30% under-reported. Micro-stops missed; brief stops not logged.

Reason codes: 30-50% misclassified. "Other" overused; wrong categories selected.

Parts: 10-20% under-reported. Parts pulled without logging.

Labor hours: 20-40% error. Estimated rather than tracked.

These are typical ranges. Individual plants vary.

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's OEE module supports audit workflows: raw vs computed data side by side, automated discrepancy detection, and trend reporting on data quality metrics over time.

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

Related reading

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.

Najnowsze wiadomości z naszego bloga

Zdefiniuj swoją mapę drogową niezawodności
Sprawdź swój potencjalny zwrot z inwestycji: zarezerwuj prezentację na żywo
Zdefiniuj swoją mapę drogową niezawodności
Klikając przycisk Akceptuj, wyrażasz zgodę na korzystanie z plików cookie podczas uzyskiwania dostępu do tej witryny i korzystania z naszych usług. Aby dowiedzieć się więcej o tym, jak pliki cookie są używane i zarządzane, zapoznaj się z naszą Polityką prywatności Polityka prywatności i Deklaracja plików cookie