OEE is only as accurate as the data that feeds it. A downtime event logged as "unplanned stop" with no reason code, a speed loss recorded as zero because no one measured it, or a quality reject count that was estimated rather than counted — each produces an OEE number that looks credible but means nothing. The most common reason OEE programmes fail is not a lack of sensors or software: it is inconsistent data collection at the shift level. This checklist standardises what every operator and shift leader must record, when they must record it, and how reason codes must be applied — so the OEE number your dashboard shows reflects what actually happened on the line. Deploy it in OxMaint to enforce consistent data collection across all shifts and generate a real-time OEE dashboard that maintenance and production can trust.
1. Shift Start Data Setup
Every shift starts with a known baseline. Without confirming the scheduled rate, the planned product, and the counter reset position, every OEE calculation for that shift is built on assumptions. Five minutes at shift start produces reliable data for the entire shift.
2. Downtime Event Logging
Availability is the most impactful OEE component in most food and FMCG operations — and it is the most commonly under-recorded. Stops under 2 minutes are rarely logged. Stops that span a shift boundary are split inconsistently. Planned stops are sometimes logged as unplanned. Each of these creates systematic bias in the Availability number.
3. Speed Loss and Performance Data
Performance loss — running below rated speed — is the hardest OEE component to capture manually and the most commonly understated. A line running at 85% of rated speed all shift logs zero downtime events but loses 15% of its output. Without a recorded actual rate, Performance defaults to 100% in the OEE calculation and the loss disappears.
4. Quality and Reject Data
Quality in OEE is calculated as good units divided by total units started — not as a defect rate. Any unit that does not meet specification on first pass is a Quality loss, even if it is reworked and eventually shipped. Rework must be counted as a first-pass Quality loss; it should not be silently added back to good count.
5. Shift Handover Data Reconciliation
Shift handover is the most critical data quality checkpoint in the OEE cycle. Data that is ambiguous, incomplete, or estimated at handover degrades the accuracy of every shift that follows. A structured handover that takes 5 minutes prevents hours of data cleaning at month-end.
6. Downtime Reason Code Reference
Consistent reason coding is what turns downtime data into actionable maintenance intelligence. A dataset where 40% of stops are coded "Other" cannot identify top failure modes, cannot calculate MTBF, and cannot prioritise maintenance spend. Every stop must use a specific code from this list.
