Anchor Scheduling vs Plain Backward Scheduling

Anchor scheduling pins one bottleneck operation to a target start date and builds the rest of the routing around it, while plain backward scheduling right-aligns the entire order to its due date. Both involve scheduling backward, which is why they get confused, but they pin at different points and for different reasons. Anchor pins in the middle of the routing to protect a constraint; backward pins at the end to time the whole job to delivery. EDGEBIC by User Solutions implements both, and when a job carries instructions for both, the anchor wins, because a pinned constraint is a harder commitment than a due date.

Two backward passes that are not the same

The word "backward" hides a real difference. Plain backward scheduling takes the whole order and places every step as late as feasible so the last step ends at or before the due date. The slack sits in front. This is the just-in-time posture covered in forward vs backward scheduling.

Anchor scheduling is a Theory of Constraints technique. It does not care primarily about the due date. It cares that the plant bottleneck never starves. So it pins the bottleneck operation to a planner-chosen target start date, schedules the upstream steps backward so they finish just in time to feed that pin, and schedules the downstream steps forward from the pin through to completion. The pin sits in the middle of the routing, not at the end.

How anchor mode fires

Anchor scheduling activates only when two conditions are both true. You mark the work center as a bottleneck, and you set a target start date on that step's schedule row. The flag alone does nothing; the target date alone on a non-bottleneck step still anchors but with smaller safety buffers. Both together give the full Theory of Constraints treatment.

When it fires, the engine first validates the constraint by computing a load factor for every work center in the routing, demand hours divided by daily capacity. If the anchor really is the tightest resource, it earns the large demand-proportional buffers; if not, it gets small fixed ones. Then it splits the routing around the anchor and schedules in both directions.

A worked anchor example

Two hundred precision shafts through a five-step routing. The heat-treat oven is the bottleneck, single instance, long cycle. The planner sets a target start of Monday 07:00 on the oven step.

The load check confirms the oven dominates:

HeatTreat: (0.10 x 200 + 2) / (8 h x 1) = 2.75   <- highest, genuine constraint
Lathe:     (0.08 x 200 + 1) / (8 h x 2) = 1.06
Mill:      (0.05 x 200 + 0.5) / (8 h x 1) = 1.31
Grind:     (0.06 x 200 + 0.5) / (8 h x 2) = 0.78

With buffers off, the schedule is tight:

Anchor  HeatTreat: Mon 07:00 to Tue 05:00 (22 h)
Backward Mill (11.5 h):  starts Sun 19:30, feeds the oven just in time
Backward Lathe (19 h):   starts Sat ~00:30
Forward  Grind (12.5 h): Tue 05:00 to Tue 17:30
Forward  Inspect (4 h):  Tue 17:30 to Tue 21:30

The oven starts exactly at the planner's target. The lathe and mill are back-calculated to their latest acceptable starts so they finish just in time, and the downstream steps chain forward. No capacity is wasted at the constraint. Turn on the optional buffers and the engine adds a constraint buffer before the anchor (half the upstream content), a shipping buffer after it, and a feeding buffer on the step that directly feeds it, trading lead time for protection against upstream variation.

Plain backward, by contrast

Plain backward scheduling would take the same job and right-align the whole thing to the due date, without singling out the oven. Each step's deadline comes from its successors' actually placed starts, so capacity-forced moves ripple upstream through joins correctly. There is no priority escalation for the constraint, no constraint buffer, no forward pass from a mid-routing pin. It is the right tool when no single resource dominates and you just want the order to land on its due date with minimal inventory ahead of it.

Why the anchor wins when both apply

If a job is both anchored and marked backward, the engine takes the anchor path. A target start date is a user-placed constraint that is harder than the due date, and the anchor path already performs its own backward-then-forward split around the pinned step. Running a whole-order backward pass on top of that would fight the pin. This is also why setting a target start date on any schedule row silently converts a backward job into an anchored one on the next run. The full precedence chain is anchor, then actuals, then planner pins, then backward, then forward.

Choosing between them

Anchor a job when a specific bottleneck must start at a known time and everything else should subordinate to keeping it fed; that is the Theory of Constraints discipline. Use plain backward when there is no dominant constraint and you want the whole order timed just in time to the due date. If you are not sure which resource is your constraint, start with identifying your production bottleneck, and see how the engine keeps a shared constraint fed across many jobs in how finite capacity scheduling handles a shared bottleneck. The full engine pipeline, including the direction-precedence rules, lives in the scheduling engine guide. Pin your own constraint and watch the routing rebuild around it in EDGEBIC.