How to Schedule Around a Bottleneck Work Center in EDGEBIC

Scheduling around a bottleneck work center in EDGEBIC takes two settings, not one: flag the resource as your constraint, then pin a target start date on the constraint operation for the job you care about. The flag identifies the resource. The target date activates anchor scheduling. EDGEBIC by User Solutions then plans everything upstream backward to feed that moment and everything downstream forward from it.

This is the configuration path. For the concept, read TOC anchor scheduling explained. For a job traced end to end with real dates, read the anchor scheduling walkthrough.

Before You Start: Know Which Resource Is the Constraint

Anchor scheduling assumes the identification step is already done. If you are guessing, you will anchor the wrong resource and get a worse schedule than plain forward planning would have produced.

Three signals usually agree, and when they do you can trust the answer: the resource with the highest ratio of demand hours to available hours, the resource with work waiting in front of it most of the time, and the resource everybody names when you ask which machine sets the pace. How to identify production bottlenecks covers the analysis in detail, including how to tell a genuine constraint from a temporary pile-up.

EDGEBIC gives you a fourth signal. When a job is anchored, the engine computes a load factor for every work center in that routing:

load factor = (run hours × quantity + setup) ÷ (shift hours × instances × utilization %)

A load factor above 1.0 means that resource needs more than a day's capacity for this job's work at this quantity. The highest number in the routing is the tightest resource for that job. If your marked constraint is not the highest, the engine notices and sizes its protective buffers conservatively rather than generously.

Step 1: Flag the Constraint Work Center

1. Open Work Centers.
2. Select the resource, for example Heat-Treat Oven 1.
3. Click Edit and set Is Bottleneck to yes.
4. Save.

Flag exactly one resource per routing. A routing with several bottleneck-marked work centers resolves to a single anchor anyway, so marking three produces an arbitrary winner rather than three anchors. If several resources genuinely contend for the title depending on the week, that is a capacity finding to act on, not a setting to over-configure. Multi-constraint scheduling covers that situation.

What this step does on its own: it drives display, it drives the load analysis above, and it decides whether protective buffers are sized proportionally to the job's work content or conservatively. It does not change a single date.

Step 2: Pin the Target Start Date

This is the step that activates anchor scheduling.

1. Open the Job View or the Gantt for the order.
2. Find the schedule row for the constraint operation on that job.
3. Set Target Start Date to the date and time the constraint must begin.
4. Save the row.
5. Run Reschedule or Generate Schedule.

The next run finds that target date, matches it to the routing step on that work center, and switches the whole job to the anchored path.

Two practical notes. First, the target date is per job, not per work center: you are saying "this job needs the oven Monday at 06:00," which is a scheduling decision that changes job by job. Second, dragging the constraint's bar on the Gantt can write the target date directly, which is often the fastest way to place a contested slot by hand. Configuration settings control exactly what a drag writes, so confirm your shop's settings before relying on that shortcut. Drag and drop rescheduling in EDGEBIC covers the drag behaviors and the safety prompts around them.

The new-job trap. Anchor detection looks for an existing schedule row carrying a target date. A job that has never been scheduled has no rows, so there is nothing to find and the run falls through to forward scheduling. Schedule the job once, then pin, then reschedule. From that point on the anchor fires on every run.

Step 3: Decide Whether to Enable Buffers

Anchor scheduling with no buffers is tight by design: upstream work is timed to finish exactly when the constraint needs it. That is easy to read and offers no protection against a bad morning upstream.

Turning buffers on inserts three cushions:

Buffers are off by default, which is the right starting point: run your first anchored schedule without them so the mechanism is legible, then enable them once you trust the plan and want the protection. The sizing arithmetic, including how a routing's own work content sets the buffer widths, is in TOC buffers and direction precedence.

One thing to know before you turn them on: buffers move upstream work earlier and add work in process. That is the trade, made deliberately, and it is worth it when the constraint starving costs more than the extra inventory.

Step 4: Verify the Anchored Plan

Four checks, in order.

Did the anchor actually fire? The clearest evidence is the shape of the plan: upstream operations placed backward from the constraint rather than forward from the release date, and downstream operations chained from the constraint's finish. If the plan still looks like plain forward scheduling, the target date is missing, the job had no prior schedule row, or the routing changed after the row was created so the work center no longer matches.

Did the constraint get its slot? The pinned operation's start should equal your target date, or sit at the next available window if another job already claimed that exact slot on a single-instance resource. Drift is visible, never silent.

Is the upstream feasible? Compare the last upstream operation's end date with the constraint's pinned start. If the end is later, the constraint starts with material that is not ready. EDGEBIC schedules faithfully rather than sliding the pin to make the plan look good, so this conflict shows up as dates you can act on. Your options are more upstream capacity, an earlier release, or a later pin.

Is the projected end acceptable? The engine computes a projected end date from the anchored plan and shows it beside the customer due date. The due date itself is never modified. Slack or lateness is the difference between those two numbers.

What to Do When the Anchored Plan Does Not Fit

The most useful thing an anchored plan produces is a clear statement of infeasibility, and it is worth knowing what to do with it rather than treating it as an error.

If the last upstream operation ends after the pinned start, you have three responses and no fourth.

Add upstream capacity. More instances, a second shift on the feeding work center, or an alternate machine for the operation that is running late. This is the right answer when the upstream shortfall is small and recurring.

Release the job earlier. Move the order's start date back so the upstream work has more calendar to land in. This is the right answer when the shortfall is large and the constraint slot is genuinely fixed by a customer milestone.

Pin the constraint later. Accept that the job cannot have that slot and place it in the next window you can feed. This is the right answer when the upstream capacity is committed to work that matters more.

The reason to look at this on every anchored job is that the alternative is discovering it on the shop floor. A constraint that starts without material does not run: it idles, and idle time at a constraint is output the plant does not get back. Fifteen seconds comparing two dates is cheap insurance.

If the same job shows the same shortfall week after week, that is not a scheduling problem. That is upstream capacity being genuinely insufficient to feed the constraint at the rate you are loading it, which is a capacity decision rather than a sequencing one.

Step 5: Live With It

Three ongoing behaviors matter once anchored jobs are in your normal cycle.

Two jobs, one slot. If a second job pins the same window on a single-instance constraint, the first job in the run order claims it and the second lands in the next open window. The drift is visible on the Gantt, which is your cue to reprioritize or add capacity rather than a fault to debug.

Started work stops being anchorable. Once the constraint operation carries actual dates, the anchor no longer applies to that job. The completed row is preserved exactly, on its original machine, and the remaining downstream work is planned forward from where the actuals ended. Completed work is never moved by a reschedule.

The constraint moves. Relieving a bottleneck creates a new one somewhere else. That is success, not failure, and it means moving the flag. Bottleneck migration covers how to see it coming.

Next Steps

Read bottleneck scheduling mistakes before your first anchored run: most of the confusion around this feature comes from a handful of specific configuration errors with distinctive symptoms. For how the anchored plan interacts with backward scheduling, actuals, and manual pins when several could apply at once, read TOC buffers and direction precedence. The complete guide to EDGEBIC shows where anchor scheduling sits in the wider platform.