Shop-floor data capture: what gets recorded, by whom, and what it is for

Start from the decision, then work back to the field

The only defensible reason to capture something is that a decision depends on it. Downtime by cause supports maintenance priority. Scrap by operation supports where to put engineering effort. Actual run time against standard supports capacity and quoting. Serial or lot identity supports containment when something goes wrong. Work through each proposed field and name the decision it feeds and the person who makes it; anything without an answer gets dropped. This exercise usually halves a proposed data set and rescues the operator time that would have gone into filling it in.

Record at the event, not at the end of the shift

Data reconstructed from memory at shift end is systematically wrong in a predictable direction: short stoppages vanish entirely, durations round to convenient figures, and causes drift toward whatever is easiest to write. Since accumulated small stops are frequently the largest loss in a plant, that reconstruction erases exactly the thing worth seeing. Capture has to happen where the work is and when the event occurs, which means the recording point must be within a few steps of the machine and take seconds. If it takes longer, operators will batch it, and no amount of instruction changes that.

Reason codes only work if a tired operator can tell them apart

Long code lists with overlapping definitions produce data that looks precise and is not: everything lands in the first plausible entry or in the catch-all. Keep the list short, make the categories mutually exclusive in plain language, and use terms from the floor rather than from an engineering document. Review where codes actually land after a few weeks — a category taking a suspicious share of events is either badly defined or sitting at the top of the list. Adding a code should require removing one, or the list grows until it stops discriminating between anything.

Capture the exception, assume the norm

Recording every good unit individually is rarely justified outside regulated or serialised production. A more economical arrangement assumes the process ran as planned and requires entry only when it did not: a stoppage, a reject, a parameter outside limits, a material substitution. That approach concentrates operator effort on the informative events and keeps the routine invisible. It carries one obligation — the assumed norm has to be verified periodically, or a process that quietly stopped conforming produces a clean record for months while making defective product. Periodic verification means a supervisor confirming, on a set rhythm, that the assumed condition still holds — a sample count, a parameter check, a walked observation of the operation running.

Who owns the data, and why operators stop caring

Capture degrades fastest where the data flows upward and nothing comes back. If the only visible use of a downtime record is a manager questioning a shift's performance, the recording adapts accordingly and the plant loses its own instrumentation. The counter is showing the floor what their data produced: the machine that got fixed, the tool that was replaced, the code that dropped out of the top of the list. Give the supervisor ownership of their area's data quality, review a sample with them, and treat implausible records as a process fault to correct rather than a discipline matter.

Frequently asked questions

How much operator time should data capture take per shift?

Little enough that nobody weighs recording against production. In practice that means a handful of seconds per event and no routine end-of-shift paperwork beyond a short handover. When capture starts costing meaningful production time, the plant faces a real choice: automate the collection, cut fields, or accept that the record will be filled in casually. Pretending an operator will do both jobs well under schedule pressure produces the worst outcome, which is data that exists and is wrong.

Should we capture data manually before automating collection?

Usually yes, because manual capture forces the plant to decide what it actually needs and to define its reason codes in language the floor accepts. Automating an undefined data set produces high-volume noise. A manual period also exposes which events are genuinely worth recording and which nobody ever looks at. Once the definitions are settled and being used, moving collection to sensors or terminals removes effort without changing the meaning of what is being counted.

What do we do about data we know is unreliable?

Say so, and stop making decisions on it until it is fixed. Publishing a figure everybody privately distrusts is worse than publishing nothing, because it invites decisions the plant will later reverse. Trace the specific failure — a code nobody understands, a terminal too far from the machine, a shift that books everything at the end — and fix that mechanism. Then rebuild the series from the point of the fix rather than trying to salvage the corrupted history.