How Shop Floor Actuals Close the Plan-vs-Actual Loop

A shop floor actuals feedback loop is what keeps a schedule honest after it leaves the printer: real start times, daily run hours, and finished pieces flow back into the next planning run, so the plan works from where each job actually is rather than where it was supposed to be. EDGEBIC by User Solutions records those facts next to the plan instead of on top of it, which turns a static schedule into one that corrects itself every time the floor reports in.

This post covers why the loop matters to the numbers you care about, how the capture works, and what the outcome looks like in weeks rather than theory. For the underlying data model, see shop floor actuals tracking. This post sits under the EDGEBIC results guide.

The Schedule That Degrades Into a Wish List

A schedule that is never told what happened is optimistic by Tuesday and fiction by Friday. Every plan assumes each job started on time and ran at rate. The floor knows better, because a job that started two hours late and lost an hour to a tooling problem is already off the printed dates, and nobody upstream knows until it ships late.

The cost is not one late job. It is that the planner ends up defending dates the floor stopped believing days ago, so the shop quietly reverts to running from memory and a morning stand-up. The scheduling software becomes a report nobody acts on. That is the failure the feedback loop exists to kill, and it is the same failure described in what an unreliable schedule actually costs you.

What the Loop Captures

An operation in EDGEBIC carries four separate pieces of reality, captured independently:

The per-day split is what makes the loop work. An operation planned for eleven hours across two days is stored as a row per day, not a single total. A reschedule needs to know that Monday's six hours are locked to Monday and only the balance is still owed. A weekly total cannot express that, which is why spreadsheet tracking never closes the loop properly.

Two guard rails apply at every entry point. An actual end must be later than the actual start, so an inverted pair is refused before it can corrupt downstream planning. And an actual start is written once, so a planner's early stamp is not overwritten by the first kiosk punch.

Three Doors, One Model

Reality reaches the schedule three ways, and they all write the same append-only history:

• The kiosk. A touch terminal bound to one machine. Each tap opens or closes a punch, and timestamps come from the shared clock, so operators never type times. The full workflow lives in the shop floor guide.
• The planner grid. The Log Actuals dialog, one row per calendar day, with columns for scheduled hours, actual hours, and pieces. This is how a shop with no terminals runs the loop.
• Manual entry at the terminal. The same day grid, reached from the kiosk, for a shift that could not tap as it went.

Because there is no second-class path, you can start with the grid on day one and add kiosks later without changing anything about how the schedule consumes the data. See how actuals flow into the schedule for the mechanics.

Where the Accuracy Comes From

The value shows up on the next run. When you reschedule, the engine reads each job's actuals, preserves everything already completed, and plans only the remaining work forward from where the shop actually is.

Consider a five-operation job where the first two operations are logged complete and the third is half done. The reschedule locks operations one and two on their real dates, resumes operation three from its logged progress, and schedules operations four and five from that resume point. Nothing that happened moves. Nothing that has not happened is assumed to have gone perfectly. See how a reschedule uses last night's actuals for the step-by-step, and what is planned vs actual hours for the variance view that results.

That resume-from-reality behavior is also what makes the delivery numbers move. A promise date built on where a job truly stands is a date you can defend, which is the mechanism behind improved on-time delivery.

What Changes in the First Month

The loop pays back in stages, and the sequence is predictable:

1. Week one: the floor starts punching or the lead starts filling the grid. The first plan-versus-actual overlay appears, and it is usually uncomfortable, because it shows the drift the old process hid. The operations sitting behind plan are a finite investigation list rather than an adherence percentage.
2. Week two: reschedules stop throwing away progress. Operators notice that completed work stays put, and the argument about "the computer moved my job again" ends.
3. Weeks three and four: the dates on the board start matching what the floor sees, so people begin acting on the schedule instead of on memory. That is the moment the software starts earning its keep.

The heritage behind this pattern belongs to the User Solutions line EDGEBIC succeeds. GE Railcar went from 30% to 90% on-time delivery on scheduling discipline of exactly this shape: a plan that reflects reality is a plan people follow.

What the Loop Cannot Do

It cannot capture what nobody records. If a shift skips its punches, that operation is invisible to the next run, and the plan inherits the gap. The loop is only as good as the reporting habit, which is why the kiosk is designed to make a punch faster than a paper traveler.

It cannot fix bad routings. If an operation is planned at four hours and always runs at seven, actuals will expose it, but closing that gap is an estimating and process decision, not a scheduling one. The variance view points at it; a human fixes the standard.

It cannot move completed work, and that is intentional. Actuals are immutable once logged. If a bad entry lands, a planner corrects it explicitly rather than the next run silently overwriting it. See why actuals are immutable.

Want to see your own drift on one screen? Bring a week of production reporting to a demo and we will overlay plan against actual on your jobs.