OEE data collection methods fall into three tiers, paper clipboards, operator tablet entry, and automated PLC or sensor capture, and they differ most in how they handle small stops. Paper misses them entirely, tablets miss the short ones, and only machine capture counts them all.
The OEE formula needs five inputs, and the formula is only as honest as the worst-collected one. Two plants can run the identical calculation and report OEE ten points apart purely because of how they gathered the numbers. This guide walks the three collection tiers, shows exactly where each one lies, especially about minor stops, and gives you a method for choosing and combining them. It is about the mechanics of capture; for the sensor-versus-clipboard cost-benefit case, that trade-off is its own topic. Run the numbers you collect through the OEE calculator to see the difference source makes.
What data does OEE actually need?
OEE needs five inputs, and each degrades differently depending on how you capture it:
- Planned production time from the schedule and written exclusion rules. Easy to get right; just keep it stable.
- Downtime and changeover minutes every unplanned stop and every setup. This is the input plants get most wrong, because short stops evaporate from memory.
- Ideal cycle time the true best rate per product, set once and defended.
- Total count every unit the machine made, good or bad.
- Good count first-pass good units only; rework and scrap do not count.
The counts and the downtime are where collection method decides accuracy. Planned time and ideal cycle are set at a desk and rarely mis-captured. So the real question of OEE data collection is: how do you get honest counts and honest stop data off a running machine?
Notice that two of the five inputs are decisions and three are measurements. The decisions, planned time and ideal cycle, you can get right once and lock. The measurements, downtime, total count, good count, are captured hundreds or thousands of times a shift, and every capture is a chance for error to enter. That asymmetry is why the collection method matters so much more than the arithmetic: you are not making one measurement, you are making thousands, and the method decides how many of them are wrong.
How do the three collection methods compare?
They trade cost against truth, and the truth they lose is almost always the same: the short stops. The table lays out the tiers.
| Method | How data arrives | What it misses | Latency |
|---|---|---|---|
| Paper clipboard | Operator writes stops and counts at shift end | Minor stops, most reason detail, real timing | Hours to days |
| Operator tablet | Operator taps stops and reasons as they happen | Sub-minute stops; anything during a busy run | Minutes |
| Automated (PLC/sensor) | Machine signals counts and stops directly | Reason codes, unless operator adds them | Seconds |
Read that middle column carefully. Every method captures the 40-minute breakdown. What separates them is the 30-second jam that happens forty times a shift, the minor stops and idling that live in the performance factor. Paper never sees them. A tablet catches them only if the operator has a free hand and the discipline to log a stop that is already over. Machine capture sees every one, because it measures the gap between good parts and does not care whether a human noticed.
Where does each method lie about small stops?
Each tier lies in a predictable direction, and knowing the direction lets you correct for it. Paper collection inflates OEE by making minor stops vanish from the record: with no short stops logged, availability looks strong, and the lost output reappears as a mild, unexplained speed loss nobody investigates. It is the most flattering method and the least actionable.
Tablet collection lies less but still lies. It captures stops the operator chooses to log, which biases toward slower, more memorable events and against the fast ones that happen mid-run when both hands are busy. It also imports recall error, a stop logged three minutes after it ended gets a rounded, guessed duration. The reason codes are gold, though: a human knows why the line stopped, which a sensor does not.
Automated collection tells the truth about timing and counts and stays silent about cause. A PLC knows a stop of exactly 34 seconds began at 09:14:22; it does not know a carton was crushed. Left alone, automated capture produces a perfect record of stops labeled "unknown," which is precise and useless. This is why the honest answer is rarely one tier, it is a combination.
There is a subtler failure worth naming: the flattering method also hides its own improvement. A plant on paper that installs sensors often sees its reported OEE drop five to ten points on day one, not because the line got worse but because the small stops finally became visible. Teams unprepared for that drop sometimes blame the new system and revert to the number that felt better. Understanding that the honest number is lower, and that the drop is the point, is half the battle of changing collection method.
What is the best OEE data collection setup?
The best setup pairs automated capture for the numbers with operator input for the reasons. Let the machine count parts and time every stop; let the operator tag the significant stops with a cause from a short, curated list. You get the sensor's honesty about how much and the human's knowledge of why which is the combination the improvement work actually needs. Neither alone is enough: counts without reasons cannot be prioritized, and reasons without honest counts cannot be trusted.
How do you choose and roll out a collection method?
You match the method to the machine's importance and the decision speed you need, then start at the constraint. The working sequence:
- Rank machines by leverage. The constraint and the two or three machines that take turns being it deserve automated capture. A rarely-limiting machine can live on simpler collection or none.
- Decide the decision cadence. If the crew needs to react within the shift, paper is disqualified, its latency is hours. Live reaction needs near-real-time data, which means machine capture.
- Wire counts and stop timing to the source. Take part-complete and run signals from the PLC, a counter, or a sensor so counts and durations are not a matter of memory.
- Curate a short reason-code list. Ten to fifteen causes, floor language, no "other" as an escape hatch. A tablet or button lets the operator tag the stops that matter.
- Reconcile against reality weekly. Cross-check the automated count against a physical count and the good count against the production report. Fix drift early, before anyone stops trusting the number.
- Expand only after the constraint is solid. Prove the setup on the bottleneck, then extend the pattern. Instrumenting everything at once buries the signal.
Two facts that frame why capture method, not arithmetic, drives OEE accuracy:
- Minor stops are formally a performance loss in the six big losses that trace to Seiichi Nakajima's TPM work, meaning any method that fails to capture them does not lower OEE honestly, it just relabels the loss as slow running. The taxonomy is documented at OEE.com's six big losses reference.
- The gap between measured and actual runs economy-wide: the Federal Reserve's G.17 release put U.S. manufacturing capacity utilization at 75.7% in May 2026 and a plant that cannot see its own small stops cannot tell how much of its own gap is fixable.
How often should OEE data be collected?
As often as you intend to act. A monthly OEE number is an autopsy, useful for trend, useless for today. A per-shift number is a scoreboard the crew can respond to at handover. A live number is a tool the team can act on while the shift is still running and the lost minutes still count. Collection frequency, not just accuracy, decides whether OEE is a report or a control. Pairing live capture with a machine monitoring feed and a simple downtime tracking template for the reason side covers both halves.
This is the practical argument for wiring the calculation to the source. Lines that read counts and stops straight from the equipment, the way Harmony computes true OEE from PLCs and sensors and layers operator reason codes on top rather than relying on end-of-shift estimates (see the platform), remove the collection games entirely and get the small stops paper would never see. Start from the full method in the OEE calculation and once your data is honest, judge the result against what counts as a good OEE score.