8 Backward Scheduling Mistakes That Break Just-in-Time Plans

Backward scheduling fails quietly: a job either schedules forward without complaint, or takes the forward fallback and ships late while everything on screen looks normal. None of that is the engine misbehaving. Each case is a documented rule doing its job on data that says something other than what you meant. These are the eight backward scheduling mistakes worth designing out before you make promises against a just-in-time plan in EDGEBIC by User Solutions.

For what backward scheduling does, read backward scheduling explained. For the setup procedure, how to schedule a job backward from its due date.

Mistake 1: No Real Due Date

Symptom. The job is set to Backward and schedules forward with no message.

Cause. Backward means "finish by this date". Without a real due date there is no target, so the job goes forward. Placeholder and empty dates do not count as real deadlines.

Fix. Give it a genuine due date. The order dialog requires one when the direction is Backward, so this usually only appears on orders created through an import or edited before the direction was set.

Mistake 2: An Artificially Late Cut Off Date

Symptom. A job that should fit comfortably reports that it does not fit, and takes the forward fallback.

Cause. On a backward job, the start date means "do not start before", and its label changes to Cut off Date for exactly that reason. It is a floor. Setting it to a future date because the order was entered late, rather than because material genuinely arrives then, removes working days the job needed.

Fix. Leave the cut off date at today unless something real forces a later floor. This is the single most common cause of a doesn't-fit result, and it is entirely self-inflicted.

Mistake 3: Leaving the Doesn't-Fit Setting on Silent

Symptom. Jobs ship late and nobody was warned.

Cause. The default behaviour accepts the forward fallback and saves the run immediately. The information is not hidden (the affected jobs still carry their projected lateness), but nothing interrupts you to point at it.

Fix. Switch the Options setting to show the popup as soon as backward jobs carry customer promises. The run then computes everything and saves nothing until you choose, and each affected job is listed with the reason it did not fit, its full forward window and its projected lateness. The setting is read fresh on every run, so the change applies immediately. Until you switch it, the Days Late column after each run is your only signal.

Mistake 4: Pinning a Target Start Date

Symptom. A job set to Backward behaves like an anchored job, planning around a pinned operation instead of right-aligning to the due date.

Cause. A pinned target date outranks the backward setting. A date pinned by hand is treated as a harder constraint than the due date, so the job takes the constraint path described in the anchor scheduling example rather than the backward path.

Fix. Do not pin target dates on backward jobs. Use the cut off date to move the earliest allowed start. This is precisely why the doesn't-fit popup's start edits change only the ordinary floor.

Mistake 5: Expecting a Reschedule to Re-align Backward

Symptom. A backward job is rescheduled after a delay and comes back forward, starting immediately rather than pulling back toward the due date.

Cause. Backward decides where a job is born. A job that already has a schedule reschedules forward from its resume point, and is never re-right-aligned to the due date on a later run. That is deliberate: re-pulling a planned job toward its due date churns the plan for no operational gain, and once actuals exist, "start as late as possible" is meaningless anyway.

Fix. Accept it, or genuinely re-birth the job: clear its schedule completely while it has no actuals, then schedule it again. In practice most planners accept the forward reschedule and manage the promise instead.

Mistake 6: A Wrong Product Lead Time

Symptom. Either the job finishes a day earlier than expected for no visible reason, or lateness figures disagree with what people believe about the shop.

Cause. Backward reserves the product's lead time out of the plan: it targets the due date minus that lead time so the delivery tail lands on the due date. A brand new product carries a default of one calendar day, not zero, so a tail can appear that nobody configured. An inflated value steals production days; a missing one makes every screen understate lateness by exactly the tail.

Fix. Set the lead time honestly per product. Zero when the item is ready as the last machine stops, the real cure or inspection or freight time otherwise. The mechanism and worked arithmetic are in end item lead time, item start versus job end.

Mistake 7: Confusing Delivery Lead Time With Procurement Lead Time

Symptom. A purchased component's supplier lead time is entered on the finished product, and every job for that product develops a long delivery tail.

Cause. Two different fields with similar names and opposite directions. A material step's lead time is inbound: it draws that step's bar backward from the point of need so the buyer can see when the order had to be placed. End item lead time is outbound: it delays the finished item becoming deliverable.

Fix. Keep procurement time on the material step and delivery time on the end product. They are never interchangeable, and swapping them produces a plan that is wrong in both directions at once.

Mistake 8: Fixing the Front Slack

Symptom. A planner sees empty days before a backward job on machines that were free and drags work earlier to "use the capacity".

Cause. The slack in front is the entire point of backward scheduling. It is why material is bought later and why work in progress ages less.

Fix. Leave it. Dragging work into it converts a backward job into a forward one by hand and loses the benefit that motivated the setting. The system already knows the difference: an idle window in front of a backward job is exempt from the idle-gap anomaly check, because it is intentional just-in-time slack. The general question of which gaps deserve attention is covered in idle gaps in the schedule.

Mistake 9: Expecting a What-If Scenario to Simulate Backward

Symptom. A scenario built to test an extra shift or a skipped step returns a forward-looking plan for a job you set to backward, and the comparison looks wrong.

Cause. Scenario what-ifs simulate forward. The direction is carried on orders and on quotes, and a scenario's simulation order does not inherit it.

Fix. Use scenarios for the questions they answer well, which is relative comparison: does adding a shift, boosting a work center, or removing a step shorten this job, and by how much. Read the absolute dates from the real backward run rather than from the scenario. For a customer-facing promise on a backward job, quote it as a backward quote, where the requested date is treated as the finish-by date.

The Bonus Mistake: Flipping Direction Mid-Execution

Symptom. A job with recorded work is switched from Forward to Backward, or the reverse, and reporting starts disagreeing with the plan.

Cause. The engine tolerates the flip, because actuals force forward regardless. Reports that classify jobs by direction do not: they read the field, so a mid-execution flip changes which checks apply to that job.

Fix. Leave the field alone once work has started. The user interface locks it once actuals exist for exactly this reason.

The Checklist Before You Promise

One habit sits behind the whole list: decide the direction when the order is created, not after it has been scheduled. Backward applies to a job's first schedule, so a direction set late is a direction that will not take effect until the job is cleared and rebuilt. Setting it during order entry, alongside the due date it depends on, removes five of the eight failures above before they can happen.

Run through it once per new backward product and the failure modes above stop appearing. Pull-based planning has been taught for decades by bodies such as ASCM, and the discipline it demands is unchanged inside a finite capacity scheduler: an honest due date, an honest floor, and an honest tail.

For the run-level mistakes that affect every direction, see scheduling run mistakes. For the general comparison of the two directions, see forward versus backward scheduling.

Bring your promised orders and we will find which of them can honestly be scheduled just in time. Contact US for a working session, or start at the EDGEBIC product overview.