What Are Production Hours in Shop-Floor Tracking?

Production hours are the hours a job is credited with as real work on the shop floor: run time plus rework time, with setup, pause and downtime recorded separately so they never inflate the job's worked hours. The distinction sounds administrative and is one of the most consequential decisions in shop-floor data capture, because a single blended hour figure cannot answer how long the work took, what the changeover cost, and what interrupted the shift. In EDGEBIC by User Solutions the operator terminal keeps those categories apart from the moment a tap lands, and only the productive part reaches the job.

How it works

At the terminal, work is captured as punches. A punch is one uninterrupted stretch of a single state on one job at one machine, and the state is what determines where the time lands.

Timestamps come from the shared clock at the moment each tap lands, so nobody types times during normal operation. The elapsed clock advances on its own during a run, and the piece counters are there to tap. Those counters only increment during a run punch, which is itself part of the discipline: pieces cannot accrue while a machine is in setup or paused, because no pieces are being made.

Pauses require a reason before the pause opens, chosen from a small fixed set of categories covering machine, material, quality and waiting, then narrowed to a specific reason. That requirement is what makes downtime analysis possible at all, and it is the reason the categories are deliberately few. The vocabulary is covered in what is a reason code in production tracking.

The setup side is broken down further. A changeover advances through named phases rather than being one undifferentiated block, and each phase's time is recorded separately so setup variance can be analyzed by phase rather than in aggregate. See what is a setup sub-phase in changeover tracking.

Scrap follows the same principle applied to output rather than time. The day's piece figure counts good pieces only, and every scrap piece carries a reason of its own, so a heavy-scrap day reads as full run hours against a reduced good count instead of quietly looking like a slow day.

A concrete example

Tuesday at a mill, one operator, one job. Work starts at eight with a changeover: the operator taps through the phases in order, twelve minutes on the first, then six, fifteen, eight, five and four. At ten to nine the last phase closes, the run punch opens, and because nobody had recorded it yet, the operation's actual start is stamped at that moment.

At quarter past ten a part gauges oversize. The operator taps scrap, picks the quality category, then the specific dimensional reason. The scrap counter reads one; the good counter is unaffected.

At half past eleven a coolant alarm sounds. The operator taps pause, picks the machine category and the coolant reason. Forty minutes later they resume, and a fresh run punch opens.

By twenty to four, twenty good pieces have been tapped in over the day and the operation is complete. The shift handoff summary reads setup 0.9 hours, run 5.9 hours, down 0.7 hours, twenty good against one scrap, with the coolant pause listed among the recent pauses.

The job is credited with 5.9 production hours. The 0.9 hours of setup is real work that really happened, and it is reported as setup rather than as job hours. The 0.7 hours of downtime is real too, attributed to the machine. Three numbers, three questions answered. A single blended 7.5 hours would have made the job look slow, the changeover look free, and the coolant failure look like nothing at all.

How EDGEBIC uses it

The productive part flows straight into the planner's view of the operation. Daily actual hours appear on the job grid, in the actuals dialog, on the live progress cards, and in progress reports, and they sit beside the plan rather than overwriting it, so plan against reality stays comparable. The comparison itself is described in what is planned vs actual hours.

The non-productive parts feed their own surfaces: setup phase times into setup-variance reporting, pauses and downtime into downtime reporting and the shift handoff summary that the oncoming shift reads.

Three habits protect the split:

• Pick the honest pause reason. Tapping the waiting category for a broken spindle sends maintenance nowhere, and the four-category taxonomy only earns its keep when it is used truthfully.
• Punch as you go rather than typing totals afterwards. Manual day entry exists as a fallback and cannot reconstruct the phase-level detail that live punches carry.
• Correct a forgotten punch rather than living with it. A punch left open overnight does not corrupt production hours, but it does distort that phase's elapsed record. Corrections happen in the punch history with a required reason and are kept forever alongside the original, as described in what is a punch adjustment.

Where this matters most is the next scheduling run. Completed work is frozen where it actually happened and only the remaining hours are re-planned, so a truthful hour split is what lets the plan restart from where the plant really is rather than from where the plan wished it were.

The takeaway

Production hours are the productive slice, run and rework, kept clean by pushing setup, pause and downtime into their own buckets with reasons attached. That one separation is what makes changeover analysis, downtime analysis and honest job costing possible from the same capture, and it is also what stops an operator's numbers from carrying a fault they did not cause. To see the split in a working plan, explore EDGEBIC, and if you are arriving from the older Resource Manager lineage, the move from RMDB to EDGEBIC maps the equivalents. For neighboring shop-floor terms, read what is a punch type in shop floor tracking and what is a shop floor kiosk.