Reading the Job Progress Header as a Supervisor

The five fields across the top of the Actual Live view answer five different questions, and treating any one of them as the job's status is the fastest way to draw a wrong conclusion. Job progress percent manufacturing figures are effort measurements, not date measurements, and a supervisor who understands that distinction gets more out of a ten-second glance than most people get out of a report.

The header strip sits above the routing diagram in the Actual Live mode of the Scheduled Job BOR tab. It carries a job progress percentage with a status badge, actual hours against estimated hours, the current step, a projected finish, and the due date. Below it, every step in the routing shows its own card. See the Actual Live screen explained for the surrounding screen.

What Each Field Answers

Read across that table and the design intent is clear. Two fields describe effort, one describes position, and two describe dates. They are separate because they answer separate questions, and the most common misuse is collapsing them into a single sense of "how the job is doing."

Progress Is Weighted by Hours

The job roll-up divides the actual hours logged across the job by the planned hours for the job. That is a defensible definition and it has one consequence worth internalizing: steps contribute in proportion to their planned hours, not in proportion to how much they matter.

A job with a twenty-hour machining step and a two-hour final inspection reaches ninety-one percent the moment machining is done. To the percentage, the job is nearly finished. To the customer, the job has not shipped and will not ship until an inspection that may not be scheduled until next week has run.

The reverse case is just as misleading. A job whose first operation is short and whose last operation is long can sit at fifteen percent while being entirely on track, because the long step is running now and will finish on time.

So the percentage is an excellent answer to "how much of the work is behind us" and a poor answer to "are we going to make it." For the date question, look at the date fields. See rolling a job's actuals up to the end product for how the roll-up is assembled.

Why 100 Percent Is Stricter Than It Looks

A job only reports an actual end, and reaches 100 percent, when all of its operations are done. Finishing one step early never flags the whole job complete, and completing the last physical step does not either if an earlier one was left open.

This is where supervisors most often find a discrepancy between the screen and the floor. The floor says the job is finished; the header says ninety-four percent. Almost always the cause is one of two things: an operation whose hours were logged but whose actual end was never stamped, or an early operation nobody reported at all because the job passed through quickly.

The step cards resolve it fast. An operation counts as done when its actual end is stamped or when its logged hours have fully covered the planned hours, so a card still showing Running with all its hours in place is the open one. See planned, in-progress, and completed work explained.

Chasing that down is worth the two minutes, because a job that never reaches complete keeps its operations in the pool of work the next reschedule considers.

Current Step Is the Field to Act On

Of the five, current step is the one that most often produces an action, because it is the field that catches reporting gaps.

The screen names the step the reported actuals say is running. If a supervisor standing in the cell can see that the floor is two operations further along than the header claims, the gap is not a display problem: nobody logged the intervening work. That matters immediately, because rescheduling plans the remaining work forward from the last logged position, so the next run will re-plan operations the shop has already finished. See how a reschedule uses last night's actuals.

The same check works in the other direction. If the header names a step further along than the floor has reached, somebody probably accepted a prompt that backfilled earlier steps from the plan, and the job's reported position is a guess rather than a measurement.

Current step is therefore the field to read first on any job you are worried about, before the percentage and before the dates. If it is wrong, the other four are built on sand.

The Two Date Fields Are the Promise Conversation

Projected finish sitting next to the due date is the comparison a supervisor and a customer actually care about, and putting them side by side means it takes no arithmetic.

One caveat keeps this honest. The Actual Live view is read-only monitoring: you can pan, zoom, and move cards around, and nothing you do there is saved or changes the plan. So the projection reflects the plan you already have, informed by the work that has been reported. It does not re-plan while you watch. If actuals have moved substantially since the last scheduling run, the honest sequence is to log, reschedule, and then read the projection.

That is not a limitation so much as a division of labor. Monitoring screens tell you what is; scheduling runs decide what will be. A screen that quietly re-planned as you looked at it would make the plan a moving target nobody had authorized. See why actuals are immutable in EDGEBIC for the same principle applied to history.

Why the Same Numbers Appear Everywhere

One reassuring property is worth knowing, because it saves arguments about which screen is right.

The job roll-up is a single set of values: the actual start taken from the first operation to begin, the actual hours and pieces summed across the job, and the percent complete from actual hours over planned hours. The header strip reads that roll-up. So does the Job View hours header with its total, actual, remaining, and percent figures, and so do the job progress report and the dashboards.

That means a discrepancy between two screens is almost never a calculation difference. It is a refresh difference: one screen was loaded before a save landed. Reload and they agree.

Two node types are worth knowing about because they behave differently in the routing diagram beneath the header. Material nodes track no actuals at all, so they never contribute hours in either direction. And the end product card derives its state from the steps feeding it rather than carrying its own hours, so it flips to complete when the last work center does. Neither is a gap in the data; both are nodes that were never going to have punches.

The Three Misreadings

Reading the percentage as a completion date. The most common by a distance, and the reason to keep customer conversations on the two date fields. A percentage answers a question about effort.

Reading a good Actual against Est as a clean job. The job-level comparison hides offsetting step errors. A step that overran by four hours and a step that came in four hours light produce a job that looks exactly on plan, and the two individual mistakes are worth more than the flattering total. Step cards flag finished steps that used more hours than planned, which is where those errors separate out: see what an over-estimate warning on a step means.

Reading a stalled percentage as a stalled job. If the percentage has not moved since yesterday, the first hypothesis should be a reporting gap, not a production problem. Check the current step, then check the punch history for the machine. A job running well and going unreported looks identical, on this header, to a job that has stopped.

A Ten-Second Routine

Give the header a fixed reading order and it becomes genuinely fast.

Current step first: does it match reality? Then projected finish against due: is there a date problem? Then the percentage and the hours: is the effort where it should be for that position? Then, only if something looked wrong, drop into the step cards to find which one.

That order works because it puts the field most likely to be wrong first, and because it separates the two questions a supervisor is usually being asked at the same time. Where is it, and will it be on time. The header answers both, in different places, on purpose.

The takeaway

The job progress header is five answers, not one status. Progress and hours measure effort and are weighted by planned hours; current step measures position and catches reporting gaps; projected finish and due measure the promise, against a plan that only moves when a schedule run happens. Read them in that order and the screen will rarely mislead you. Explore the platform at EDGEBIC, see the upgrade path in RMDB to EDGEBIC, and read on in how partial completions carry forward and the Actual Live screen explained.