Backward Scheduling in EDGEBIC: Just-in-Time Without the Risk

Backward scheduling places a job as late as capacity allows, so its last operation finishes just in time for the due date rather than as early as possible. The slack moves to the front of the job: material is bought later, work in progress ages less, and the item is ready when the customer needs it rather than sitting in finished goods. EDGEBIC by User Solutions treats backward as an opt-in choice per order, with an automatic forward fallback whenever the just-in-time plan cannot be honoured.

This post explains the concept, the trade-off, and the rules that decide when the setting actually applies. For the general push versus pull comparison, forward versus backward scheduling covers the category, and just-in-time manufacturing covers the wider discipline this belongs to.

The Picture

FORWARD (default, push):
  start ──►[S1][S2][S3]· · · · · · · · · · ·│ due date
           work front-loaded, slack at the end

BACKWARD (pull, JIT):
  start │· · · · · · · · · · ·[S1][S2][S3]──► due date
         slack deliberately in front, work right-aligned

Same hours, same machines, same routing. The work simply sits at the opposite end of the window.

The Trade-Off, Stated Honestly

Forward minimises risk at the cost of inventory. Backward minimises inventory at the cost of slack. Neither is universally correct, which is why the direction is a field on the order rather than a philosophy imposed on the plant. Most shops end up with a mix, and that is the intended outcome.

Backward Is Opt-In, With a Safety Net

Two design decisions make backward safe to adopt gradually.

It is per order. A site default pre-selects the direction on new orders and quotes, and any order can be switched individually. Existing orders are untouched when you change the default.

It never fails where forward would have worked. If the just-in-time plan cannot fit between the job's earliest allowed start and its due date, the whole order rolls back and schedules forward instead. A partly placed backward attempt leaves nothing behind: every row it added is removed before the forward pass runs. You always get a plan.

What happens next is a setting. Either the run accepts the forward fallback silently and saves, or it holds the entire run without saving anything and shows you the jobs that did not fit, with their forward window and their projected lateness, so you can decide. The procedure for both is in how to schedule a job backward from its due date.

What Beats the Backward Setting

Setting a job to backward does not guarantee a backward plan. Five rules resolve in a fixed order, and the higher ones win:

Two consequences are worth internalising.

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: pulling a job that is already planned back toward its due date would churn the plan for no operational gain.

Do not pin a target start date on a backward job. Pinning one promotes it to an anchored job under rule 1, and it stops being backward at all. If you need to move a backward job's earliest allowed start, move the ordinary start floor instead.

A missing due date also sends the job forward. Backward means "finish by this date", so the date is not optional, and the order dialog requires it when the direction is backward.

Same Capacity Rules, Different Search Direction

Every placement in either direction goes through the same allocator, so shifts, holidays, downtime, utilization percentages, machine instances and one-job-per-day rules are enforced identically. Backward changes exactly one thing: where in the calendar the search starts. Instead of looking forward from an earliest start, it looks backward from a deadline.

Two mechanics follow from that:

• Deadlines cascade from placed work, not from arithmetic. Each operation's deadline is the earliest actual start among the operations it feeds, so when capacity forces a step later than the ideal, the constraint ripples correctly to everything upstream, including through joins.
• Placements are verified, not assumed. After an operation is placed, the engine re-checks the handoff composition (queue time, overlap, transit) against the deadline it had to meet. If the composed finish overshoots, the placement is undone and retried against a tighter deadline. When it still cannot converge, the whole order falls back to forward.

That estimate-then-verify loop is why a backward plan holds up under the same handoff rules as a forward plan rather than quietly violating them.

The Lead Time Reservation

One detail explains most first-day surprises. A backward job does not aim its last operation at the due date. It aims at the due date minus the product's lead time, so the delivery tail lands on the due date instead of past it.

Take a job due Friday July 17 with a two day product lead time. The engine treats the due date as end of Friday, subtracts two days, and requires all machining to finish by Thursday July 16. The two day tail then carries the job to a delivery-ready date of Friday July 17, and Days Late reads zero.

Without that reservation, every backward job would be born exactly as many days late as its lead time. The full mechanics of the split, including how lateness is judged consistently on every screen, are in end item lead time, item start versus job end.

What Changes on the Shop Floor

The scheduling change is one field. The operational changes are worth planning for:

Material arrives later. A right-aligned job needs its material at the new, later start. That is the saving, and it is also the new exposure: a supplier slipping two days now hits a job with no downstream slack. Keep the job's earliest allowed start honest about material reality rather than optimistic.

Work in process ages less. Parts spend fewer days sitting between operations, which reduces damage, loss and the rework created by design changes landing mid-flight.

Finished goods stop accumulating. The item is ready close to the ship date rather than weeks before it, so the space and the cash stay free.

Disruption becomes visible immediately. With no slack after the last operation, a breakdown on a backward job threatens the promise the same day rather than eating a buffer quietly. Some planners read this as a downside. It is closer to a feature: the plan tells you about the problem at the moment it happens instead of two weeks later.

Backward on Quotes

The direction is not limited to live orders. A quote carries the same choice, and for a backward quote the customer's requested date is treated as a finish-by date rather than a target start. The simulation then answers a different and more useful question: not "how early could we build this" but "how late can we start and still deliver on the day you asked for".

Because quote simulation runs the same engine against the real committed capacity and writes nothing, you get a promise date grounded in the plant as it is actually loaded. The EDGEBIC quoting guide covers the wider workflow.

The Slack in Front Is the Feature

A backward job leaves visible empty days before it starts, sometimes on machines that were entirely free. This is the feature, not idle waste, and it is the thing most likely to prompt a well-meaning planner to "fix" the plan by dragging work earlier.

The system knows the difference too: 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 are deliberate is covered in idle gaps in the schedule.

Keeping Backward Promises Honest

Two habits are worth adopting on the day you turn backward on.

Enable the review prompt. With the default setting, a new backward job that cannot make its due date is rescheduled forward and saved silently, late where it lands. The information is on the grid, but nothing asks you to look at it. The alternative setting holds the entire run without saving and lists every affected job, which is the version you want once backward jobs carry customer promises.

Watch the backward promise check. The anomaly report flags any backward-direction job whose plan ends after its due date, which catches both the silent fallback and a plan that drifted late afterwards. It is a two-line report to read and it closes the loop that the direction field opens.

Where to Go Next

• To turn backward on and run it, see how to schedule a job backward from its due date.
• For the lead time split and how lateness is judged, see end item lead time, item start versus job end.
• For the failure patterns, see backward scheduling mistakes.
• For the direction it inverts, see forward scheduling explained.

Just-in-time discipline is old and well understood, and bodies such as ASCM have taught pull-based planning for decades. What changes when it sits inside a finite capacity scheduler is the honesty: a right-aligned plan that respects real shift hours either fits or tells you it does not, before you promise anything.

Bring three jobs with real promised dates to a demo and we will schedule them backward against your calendar, including the ones that do not fit. Contact US to arrange it, or start at the EDGEBIC product overview.