Hours filled in from memory never match the post-calculation

Short answer. You record shop floor hours reliably by putting the registration at the source: the operator starts and stops a work ticket on the order itself, via a scanner, tablet or touchscreen at the machine. Not afterwards from memory on a slip of paper. Only then do the hours land on the right order and does your post-calculation add up.

Hours filled in from memory at the end of the day are an estimate. Not a measurement. The operator no longer remembers exactly how long that one changeover took, so he rounds it off to eight hours and spreads it across the orders he worked on by feel. That feels harmless, but it is exactly the point where your post-calculation collapses.

Why filling in after the fact breaks your numbers

The problem is not that people lie. The problem is that memory is not a measuring instrument. A day on the shop floor consists of switching between orders, waiting for material, changeovers, quality control and a breakdown in between. Ask about it afterwards and you get a smoothed-out distribution that happens to add up to eight hours.

Those hours then flow into your post-calculation. And here is what happens: because moving around, waiting time and changeovers are not registered separately, one order looks more profitable than it was and another looks more loss-making. You just do not know which one. So you base your next quote on numbers that may or may not be right per order, without seeing the difference. That is how you structurally price wrong.

Registration belongs at the source, on the order

The solution lies in where and when you register, not in remembering better. The hours have to be created at the moment the work happens, tied to the work ticket of that specific order.

In practice it works like this: the operator scans the order ticket and his own badge at the machine, or taps the operation on a touchscreen. At that moment the timer starts on that order. When he moves on to the next operation, the previous one stops automatically and the new one starts. The GET job time tracking describes this principle clearly: working time is distributed across orders, and those distributed hours are directly the input for post-calculation and invoicing. No intermediate step, no memory, no retyping.

This is where registration at the source and post-calculation per order connect. One delivers the measurement, the other uses it.

First the process, then the technology

Before I build anything, I look at what is actually being registered now and why. In many manufacturing companies, registration rules have grown over the years. Ten activity codes are tracked, of which three still actually end up in a report, planning or invoice. The rest is ballast that scares off the operator and pollutes the data.

A useful rule of thumb: if an activity makes no difference to reporting, planning, invoicing or post-calculation, you usually do not need to register it separately. Cut those rules and registration becomes faster, so people actually do it. That is not a reason to build nothing. It is the reason what you build gets used. Registration that feels like an extra action on top of the work gets skipped or invented afterwards, and then you are back to square one.

Where an off-the-shelf package gets stuck

An MES connects your shop floor to your office systems and registers orders, operations and status in real time. Innovaware explains that an MES sits between your ERP and the machines: the ERP determines which orders are made, the MES drives the process on the floor. For a straightforward production flow, such an off-the-shelf package covers the bulk of cases.

But off-the-shelf packages cover the happy path. They assume that an operator works on one order at a time, that changeovers have a tidy code of their own, that a rush job does not break the planning. Your shop floor knows the exceptions: the operator who watches three machines at once, the extra work that has to go onto a different order halfway through, the hours that belong distributed across a parent order and three sub-orders. That is where the off-the-shelf package runs dry, and it still ends up on a paper slip that someone types in at night.

That is where I build. Not a new time-tracking package, but the integration and logic that catch your exceptions: a scan flow that can handle multiple orders at once, rules that automatically book extra work onto the right sub-order, a hand-off to your ERP and cost calculation so nobody retypes anything. The calculation and the registration have to happen. The only question is whether the off-the-shelf package makes them add up for your situation, or whether a layer is needed in between.