What an Over-Estimate Warning on a Step Actually Means

A warning that a finished step consumed more hours than planned is a pointer, not a verdict, and it has three quite different causes that demand three different responses. Reading an operation over estimate hours flag correctly is mostly a matter of ruling out the boring explanation before reaching for the interesting one.

The flag lives on the step's progress card in the Actual Live view, the routing diagram mode that overlays live progress on every node of a job. Each card carries a status badge, the hours logged against the hours planned, a progress bar, and a time range. When a step finishes having used more hours than the plan allowed, the card adds the overrun in hours. See the Actual Live screen explained.

Notice what the flag is not. It is not an interruption during the run, and it is not a judgment about anybody. It is a small piece of arithmetic the screen does for you so that a supervisor reviewing a job does not have to compare two columns in their head.

The Three Causes

The order in that table is the wrong order to investigate in. Work it bottom-up. Rule out bad data first, because it is the cheapest to check and the most embarrassing to act on. Then decide between a bad day and a bad standard, which is almost always answered by looking at whether the overrun recurs.

Ruling Out Bad Data First

Three checks, and none of them take long.

Look at the Source column. In the Log Actuals grid, each day of the operation shows where its value came from. Days that carry the auto-filled badge were written by the system from the plan, typically because somebody accepted the prompt warning that prior work centers had no actuals logged. An overrun sitting on top of backfilled days is not evidence of a slow run; it is evidence that a guess got treated as a measurement. See the auto-filled actuals badge explained.

Look at the punch history. The history drawer shows every punch and every edit, with who and when, filtered by run, setup, down time, or edits. A duplicated day, a punch left running over a weekend, or a supervisor correction that went the wrong way all appear here. See reading the kiosk punch history drawer.

Confirm the hours landed on the right step. Hours are recorded per operation, meaning per work center per day, and hours typed against the wrong work center produce a matched pair of errors: an overrun on one card and an unexplained underrun on another. If a neighboring step's card looks suspiciously light, you have probably found the answer without leaving the screen.

One special case deserves naming here because supervisors meet it often and misread it. A step whose card sits on Running forever, with all its hours logged, is not overrunning. Its planned hours are simply higher than what was really needed, and it never got an explicit end stamped. See an operation shows running forever.

Telling a Bad Day From a Bad Standard

Once the data is trustworthy, the question narrows to one: does this overrun recur?

A single job that ran long while the last five did not is a bad day, and the punch record usually names it. Pauses carry a reason from four categories, so a machine pause points at maintenance, a material pause points at purchasing or the upstream step, a quality pause points at engineering, and a waiting pause points at scheduling or supervision. That taxonomy is the whole reason a mandatory reason on every pause is worth the tap. See what a pause with a reason record is worth.

Scrap is worth a glance in the same pass. Scrap pieces are counted separately from good pieces, each with its own reason, and only good pieces feed the plan's produced quantity. So a run that made twenty good parts and scrapped four consumed hours the plan never budgeted for, and the overrun is real without anybody having been slow. See good, scrap, and rework counts explained.

A step that overruns by roughly the same margin on every job for the same product is a different animal entirely. That is not a bad day repeated; that is the plan carrying a number that has never been true. No amount of rescheduling will fix it, because rescheduling faithfully applies the standard it was given.

Split the Recurring Gap Into Setup and Run

When you have concluded the standard is wrong, resist changing the total. Find out which half of it is wrong, because they have different fixes and different owners.

Setup and run are separated all the way down. The terminal times each changeover phase individually, from teardown through fixture, tools, first article, quality hold, and run-off, and only run time counts toward the operation's production hours. So a recurring overrun sits in one of two places, and the punch data tells you which. If phase times consistently exceed the routing's setup figure, the changeover standard is the problem: see how setup phases become setup variance. If setup lands on target and the run hours are consistently over, the per-unit figure is the problem, which means the cycle time or the pieces-per-hour rate on the step.

The rate is worth checking directly, because it is also what converts between hours and pieces when actuals are logged. A step whose rate has drifted away from reality produces overruns and awkward piece counts at the same time. See how hours and pieces convert on the floor.

The Parallel Sibling Exception

One case will send you chasing a number that was never independently reported, so it is worth recognizing on sight.

A routing step that runs on parallel work centers appears as two rows: the primary and its sibling. Only the primary is ever logged. The sibling's dates mirror the primary one to one and its hours scale by the configured factor, automatically, on every save. Edit the sibling directly and the next save anywhere on that job overwrites it from the primary again.

So an overrun showing on a sibling is not a separate finding. It is the primary's overrun, multiplied by the factor, and investigating the sibling's machine will lead nowhere. Find the primary row, diagnose the overrun there, and the sibling follows. See why a parallel step's actuals follow the primary.

The related check is whether the factor itself is right. If the primary is on target and the sibling reads consistently over, the factor may be claiming the parallel machine is faster or slower than it really is, which is a routing question rather than a floor one.

Why an Underrun Deserves the Same Review

The flag only fires one way, which creates a blind spot worth managing deliberately.

An inflated standard costs you continuously and silently. Every job for that product reserves capacity the shop never uses, which pushes other work later, extends quoted lead times, and makes the plant look busier than it is. Nothing warns you, because a step finishing early looks like success on every screen.

The card still shows it: a complete step sitting at a low percentage of its planned hours. Add that to the same review you do for overruns and you will usually find that a shop's standards are wrong in both directions, and that the inflated ones have survived longer precisely because nobody was annoyed by them.

Note also that the job-level view can conceal both. The Actual Live header strip reports the job's logged hours against its estimate, so a step that overran by four hours and a step that came in four hours light produce a job that looks exactly on plan. The per-step cards are where the offsetting errors separate out.

Turning It Into a Habit

A review that happens is worth more than a review that is thorough. Two practices carry most of the value.

Look at completed steps once a week, not once a quarter, and start with any card carrying the overrun flag. Ask the three questions in order: is the data real, does it recur, and which half of the standard is wrong. Most cards resolve in under a minute.

Then write down what you changed and why. A routing standard that gets corrected without a note gets argued about six months later, and the argument usually ends with the number being put back. The overrun flag will keep pointing at it either way, which is the useful thing about a system that measures against your own claims.

For the wider plan-versus-actual picture these single steps roll up into, see from kiosk punch to plan versus actual variance.

The takeaway

An over-estimate warning tells you where to look and nothing more. Rule out backfilled days, duplicated punches, and hours on the wrong step before you conclude anything; then let recurrence decide between a bad day and a bad standard, and let the setup and run split decide which number to change. Give underruns the same attention, because they cost more and complain less. Explore the platform at EDGEBIC, see the upgrade path in RMDB to EDGEBIC, and read on in the Actual Live screen explained and how punches roll up into daily actual hours.