How Finite Capacity Scheduling Improves On-Time Delivery

On-time delivery improves when the promise date stops being an estimate and starts being a computed result. A finite capacity scheduler places every operation into hours that genuinely exist on a specific machine, so the completion date it reports is a date the plant can hit. EDGEBIC by User Solutions does that arithmetic on every run, then keeps doing it as actuals arrive, which is why the delivery number moves in two stages: first the promises get honest, then the sequence gets efficient.

This post takes the outcome apart: which mechanisms move on-time delivery, what the arithmetic looks like on documented examples you can recompute, and where the software runs out of power and hands the problem back to you. For the metric definition and how to calculate it, see the on-time delivery KPI guide. For the full results picture across every outcome, the EDGEBIC results guide is the pillar this post sits under.

Two Different Reasons Jobs Ship Late

Before mechanisms, a diagnosis, because the two causes need different fixes and shops routinely apply the wrong one.

Cause one: the date was never achievable. Someone promised four weeks on a job that needs six weeks of capacity at a work center already booked. Nothing on the floor can recover that. The job was late the moment it was quoted, and every expedite spent on it is a payment against a debt that was booked at order entry.

Cause two: the date was achievable and the sequence wasted it. The capacity existed. It got consumed in the wrong order, so a machine sat idle waiting for work that was queued behind a long job it did not need to wait for. This kind of lateness is invisible in a utilization average, because the average is fine. It shows up only when you look at the schedule as a sequence.

Most shops have both, in a mix they have never measured. Finite capacity scheduling attacks cause one by refusing to promise dates that capacity cannot support. Sequence-aware scheduling and optimization attack cause two.

Mechanism One: Promises Backed by Capacity That Exists

An infinite-capacity plan (the kind an MRP run or a spreadsheet produces) computes a date from lead time offsets, then flags an overload if too much work lands on one resource. The flag is the end of its involvement. Resolving the overload is a human's job, every day, for every overload.

EDGEBIC resolves it instead. Every operation is placed into a real slot on a real work center in a real shift, respecting instance counts, shift patterns, holidays, downtime, and the utilization percentage you configured. When three jobs need eighteen hours of paint booth time on a day that holds eight, the schedule does not report all three starting Monday morning. It reports what actually happens: one runs Monday, one spills into Tuesday, one runs Tuesday.

The honest plan is often longer than the plan it replaces, and that is the point. A longer date you can hit beats a shorter date you cannot. See finite versus infinite capacity scheduling for the underlying difference.

Where this pays fastest is the quote, because that is where the promise is made. EDGEBIC's quote simulation runs the identical scheduling engine against current committed capacity, so a quoted date is produced the same way the eventual schedule date will be produced. Nothing changes between promising and planning.

Mechanism Two: Sequence, Where the Arithmetic Lives

Here is the documented three-job case that makes cause two visible. Two work centers (a saw and a mill, one machine each), one day shift running 08:00 to 16:00 Monday through Friday, three jobs all released Monday at 08:00.

Scheduled one job at a time in due-date order (A, B, C), job A's six-hour cut occupies the saw all Monday morning while the mill sits idle. B's two-hour cut would have fed the mill by 10:00, but B never got looked at until A's whole routing was committed. Result: A on time, B two hours late, C late into Wednesday.

Re-sequenced so the shortest cut feeds the longest mill job first (B, A, C), the same three jobs on the same two machines produce a different outcome:

No overtime, no new machine, no faster cutting. Two of three jobs move from late to on time purely from ordering. This is the size of the prize that a load average cannot see, and it is why EDGEBIC's optimizer exists: three jobs you can reorder by eye, forty jobs across twelve work centers you cannot. The multi-run layer evaluates many complete alternative schedules and is clamped never worse than the schedule you already have; the mathematical solver layer goes further and reports a proven optimality gap, which on this example is a gap of zero (no better plan exists).

Mechanism Three: Protecting the Constraint

If one resource paces the plant, on-time delivery is decided there and nowhere else. EDGEBIC's anchor scheduling lets you designate that work center as the constraint, pin the constraining operation to a target start, then schedule upstream operations backward to feed it and downstream operations forward from it.

In the documented five-step heat treatment example (200 shafts through a lathe, mill, heat treat oven, grinder, and inspection), the oven carries a load ratio of 2.75 against the next highest at 1.31. Anchoring the oven at the planner's target of Monday 07:00 back-calculates the lathe and mill to their latest acceptable starts, so the constraint never waits for feed. With buffers enabled, a 15.25-hour constraint buffer and a 4.125-hour shipping buffer absorb upstream variation without moving the committed finish date. That is what turns a completion date into a commitment instead of an optimistic estimate.

Mechanism Four: The Promise Survives Reality

On-time delivery is lost in the week after the schedule is published, not the day it is published. A machine goes down, an operation runs long, an operator logs six hours where eight were planned.

EDGEBIC handles this by rescheduling from what actually happened. Completed work is preserved exactly and never moved by a reschedule, in-progress work is re-planned for its remaining hours only, and downstream steps cascade off the new reality. In the documented breakdown case, a mill fails on a Wednesday morning with 10.5 of its 31 planned hours already logged. The reschedule blocks that Wednesday, replans the outstanding 20.5 hours starting Thursday, cascades the grinder and inspection behind it, and lands the job two working days later than planned. The due date was Friday the 25th; the new finish is Thursday the 23rd. Still on time, and known within a run rather than discovered a week later.

The Arithmetic You Can Do on Your Own Plant

Three numbers, computable this week from data you already have:

1. Split your late jobs by cause. Pull the last quarter's late shipments. For each, ask whether the promised date was ever supported by capacity. The share that was not is your quoting problem. The rest is your sequencing problem.
2. Price a point of on-time. What does one point cost you in penalties, expedited freight, or retained business? That converts every mechanism above into money.
3. Count the recoverable ones. In the worked example, re-sequencing recovered two of three. Your ratio will differ, and the only way to find it is to schedule your real orders against your real capacity and compare.

The heritage evidence for what this discipline achieves at scale belongs to the User Solutions line that EDGEBIC succeeds: GE Railcar took on-time shipping from 30% to over 90%, and Technical Glass Products recorded a 4% capacity increase with a two-week lead time reduction. Those are documented outcomes of the scheduling discipline, not a forecast of yours.

What the Software Cannot Do Alone

Four honest limits, because a business case built without them will not survive contact with your plant.

It cannot create capacity. If your constraint needs 420 hours in a month that holds 400, no algorithm closes that gap. The scheduler tells you the truth early, in the capacity view and in the utilization report's overload rating, and then the decision (overtime, an alternate machine, a moved due date, a declined order) is yours.

It cannot fix wrong data. A schedule computed over an incorrect routing is precisely wrong. Hours per unit, setup times, and instance counts have to reflect the floor. EDGEBIC's anomaly checks catch structural problems, but they cannot know your mill really takes 1.8 hours per part when the routing says 1.5.

It cannot make actuals appear. The reschedule mechanism above only works if the floor logs what happened. Without actuals, the schedule slowly drifts back into fiction and the on-time number stops meaning anything.

It cannot control your suppliers. Material that arrives late makes a job late regardless of how good the plan was. Scheduling makes that visible sooner, which is worth something, but it does not move the truck.

Ready to see the split between your two causes? Bring a quarter of late orders and your capacity data to a demo, and we will schedule them against your real shifts. The number you care about is how many were recoverable.