Finite vs Infinite Capacity in Practice: What Actually Changes

Finite and infinite capacity differ in one practical way: infinite capacity planning tells you whether you are overloaded, while finite capacity scheduling tells you when each job actually finishes. Infinite capacity lets every job start the moment it is released and stacks unlimited work onto a work center, which is fast but fictional. Finite capacity respects that a machine runs one job at a time, queues contested work, and hands each operation a start and finish the floor can actually hit. EDGEBIC by User Solutions schedules finite by default, and understanding what changes between the two models is the difference between a promise you can keep and a date that slips every week.

The textbook contrast is covered in the generic guide to finite vs infinite capacity scheduling. This post is about what the two models do differently on a real floor, with numbers.

What infinite capacity actually produces

An infinite capacity model treats each work center as if it had unlimited parallel lanes. Release ten jobs to a single mill and the model happily starts all ten at once, because it never asks whether the mill can be in ten places at the same time. The output is a load profile: total hours demanded per period versus total hours available. That profile is genuinely useful for one thing, spotting an overloaded week before you accept the order that causes it.

What infinite capacity cannot do is give you an executable schedule. Its completion dates assume zero queue time, so they are always the earliest arithmetic possible, never the earliest achievable. On a busy floor the gap between those two is where every missed delivery lives.

What finite capacity does instead

Finite capacity scheduling places one operation, consumes that machine time, then places the next operation against whatever time is left. Two jobs that both want the same mill on Monday do not both get Monday; the higher-priority job claims it and the second job queues behind it. The result is a set of dates that already account for the wait every job experiences in a real queue.

This is why finite dates are later than infinite dates and also why they are trustworthy. The finite engine is not being pessimistic. It is showing you the queue that already exists on your floor, the one infinite planning hides. Once that queue is visible you can act on it, which is why finite scheduling shrinks lead times rather than stretching them.

A worked example: three jobs, one work center

One work center, one instance, one 8-hour day shift. To keep planning realistic you define the shift as the 6.4 hours the machine really delivers rather than a fictional 8, since that is where headroom belongs. Three jobs arrive Monday morning, each needing 10 run hours:

Infinite capacity starts all three Monday 08:00. Each is 10 hours of work, so at face value each "finishes" partway through Tuesday. The report shows all three on time. Nobody on the floor believes it, because there is one machine.

Finite capacity sequences by priority and start date, then queues:

Thirty run hours divided by 6.4 planning hours per day is about 4.7 days of elapsed time. MO-A hits its Tuesday due date; MO-B misses Wednesday by a day; MO-C misses Thursday by a full day. The finite model just told you, on Monday, that two of three orders are already late. That is a decision you can act on: add a shift, offload MO-C to an alternate work center, or renegotiate a date. The infinite model gave you nothing to act on because it reported success.

The schedule-at-utilization dial is where the two models meet

Even a finite schedule has to decide how many of a shift's clock hours are truly plannable. Nobody runs a machine 100 percent of every shift; there are micro-stops, tool changes, and breaks. EDGEBIC exposes this as a per-job schedule-at-utilization percentage. At 80 percent on an 8-hour shift, each instance offers 6.4 hours a day to the finite engine. Set it to 100 percent and you have quietly recreated the infinite model's optimism inside a finite run, and your dates will drift. This dial is covered in depth alongside how multi-shift allocation fills capacity.

When infinite still earns its place

Infinite capacity is not wrong, it is just a different question. Reach for it when you want a fast, months-out sanity check: is October broadly overloaded, or is there room to take on the new contract? You do not need a sequenced schedule to answer that, and running the full finite engine over a rough forecast would be slower than the answer deserves. The discipline is to never confuse the rough-cut load profile with a promise. The moment you quote a date to a customer, that date should come from the finite run, not the infinite one.

Why the finite model is the honest one

A finite schedule respects the same reality your operators live in: one job at a time, per instance, inside real shifts, minus holidays and downtime. When it says a job finishes Friday, that date already includes the queue behind it. This is the foundation the rest of the platform builds on, from searching forward in time for the next open capacity to keeping a shared bottleneck fed. It is also why finite scheduling was the model behind the schedules User Solutions built for operations from GE Railcar, which moved from 30 percent to 90 percent on-time delivery, to the US Navy carrier Nimitz with its 26,000-plus scheduled tasks. Those results came from planning against real capacity, not wished-for capacity.

The full pipeline, from the finite placement rules to the optimizer that sits on top of them, is laid out in the scheduling engine guide. To watch the finite model queue your own jobs and surface the dates you can actually promise, see EDGEBIC on your data.