Finite Capacity Scheduling Software for Manufacturing
The complete operator-grade guide.
Schedule work only where capacity actually exists — machines, labor, tooling, pallets, outside processing. The single biggest lever for moving OTD out of the 60s without buying new machines.
Built with real job shops
Developed alongside discrete manufacturers running 20–200 machines — CNC, fabrication, mixed operations, including Boeing-tier suppliers.
Co-designed with planners
Every concept on this page was pressure-tested against live planners, schedulers, and shop-floor supervisors — not derived from generic SaaS playbooks.
Validated on the floor
Pallet pools, setup clustering, lights-out runs, outside processing, hot jobs — modeled from real machinist workflows, not theory.
What is finite capacity scheduling?
Finite capacity scheduling is the practice of sequencing manufacturing work orders against the actual, limited capacity of each resource — machines, operators, tooling, fixtures, and outside processing — rather than against an assumed unlimited capacity. Every operation is placed in a time slot only if the resource is genuinely available, so the resulting schedule reflects what the floor can actually run, not what the planner wishes it could run.
How it works
- •Every resource has a real calendar: shifts, holidays, planned maintenance, certifications.
- •Every operation declares the resources it consumes — machine, operator skill, fixture, gauge, outside partner.
- •The scheduler refuses to place an operation in a slot where any required resource is unavailable.
- •Overloads become visible — flagged as at-risk jobs with the named constraint — instead of silently absorbed.
- •Sequence decisions account for setup-dependent changeover, due-date pressure, and bottleneck protection.
Why it matters
Most ERP schedules use infinite capacity and quietly overload bottleneck work centers by 20–40%. Operators resequence by hand, planners chase status, and OTD collapses below 70%. Finite capacity scheduling forces the planning system to confront the real constraint — typically the single biggest lever for moving OTD from the 60s into the 90s without buying any new machines.
How Skody does it
Skody runs a finite capacity model that includes machine state, labor coverage, tooling, pallets, fixtures, and outside processing. Operations that cannot fit are surfaced as at-risk jobs with the specific constraint named, so planners can act before the shortfall reaches the floor. The schedule is recalculated continuously as the floor changes — no overnight snapshot.
Infinite vs finite: why the model itself decides whether your shop ships on time
Every production schedule is built on one of two assumptions: either resources are unlimited, or they are not. That single assumption decides whether the schedule reflects reality or decorates a wall.
Infinite capacity scheduling assumes any work center can absorb any amount of work. The ERP accepts every release, slots operations against earliest-need dates, and prints a sequence. If a planner releases 80 hours of work to a 40-hour machine, the system says yes. The infeasibility is silently transferred to the floor, where operators resolve it by picking whatever runs fastest and hoping the rest does not slip.
Finite capacity scheduling refuses that assumption. It treats each resource as a real, bounded calendar and places operations only where the resource is genuinely available. When work cannot fit, the system says so — naming the constraint, naming the at-risk jobs, and naming the time window. The planner now has a problem they can solve. The operator has a sequence they can run.
This is not a tuning knob. It is the structural choice that decides whether a schedule is a plan or a prediction.
Why your ERP cannot solve this no matter how it is configured
Most discrete-manufacturing ERPs — NetSuite, Epicor, JobBOSS, Global Shop, E2, ProShop, Made2Manage — ship with infinite capacity scheduling by default. A few sell an APS module that adds finite capacity, but it usually runs once per shift on a snapshot. By 9:30 a.m., the snapshot is wrong; by 11:00 a.m., it is fiction.
The deeper problem is architectural. ERPs were designed to manage transactions — receipts, issues, completions, invoices — not to model the live state of a factory. Their scheduling modules optimize for what was true at the moment of the run, not what is true now. That is fine for monthly close. It is fatal for a floor that changes every fifteen minutes.
Three concrete consequences:
- Overload is invisible until operators feel it. The schedule prints clean while the bottleneck is buried under twice its capacity.
- Promise dates drift from reality. Quoting against infinite capacity produces lead times the floor cannot meet, and the gap shows up as missed ship dates 6–8 weeks later.
- Planners become re-schedulers. They spend their day rebuilding the ERP plan in Excel, on a whiteboard, or in their head — because the system itself never produces a feasible one.
None of this is the ERP vendor's fault. ERP scheduling and finite capacity scheduling are different problems. A finite capacity scheduler reads from the ERP, respects its data, and does the job the ERP was never built to do.
Bottlenecks: the one work center that caps the whole factory
Eli Goldratt's Theory of Constraints stated it cleanly: a factory's throughput is set by its single most constrained resource. Every other resource is, by definition, either non-constrained or starved. Finite capacity scheduling makes this measurable instead of theoretical.
In a typical job shop, the bottleneck moves week to week. It might be the 5-axis on Monday, the 50-ton press on Wednesday, outside heat treat on Friday. A finite capacity model identifies the current bottleneck by load, holds the rest of the schedule to its rhythm, and prevents the rest of the floor from generating work-in-process that piles up in front of it.
Three rules that fall out of finite capacity scheduling once a bottleneck is named:
- Never starve the bottleneck. Upstream sequencing should keep its queue covered without overflowing it.
- Never overload it. If the bottleneck is at 100%, do not promise work past its next free slot.
- Protect its setup pattern. Setup-dependent changeovers on the bottleneck are the most expensive minutes in the building.
Routing conflicts and alternate paths
In a high-mix discrete environment, many parts can run on more than one machine. The routing in the ERP usually names a "primary" and "alternate" — but the alternate is rarely evaluated automatically. The result is a primary machine chronically overloaded while a secondary machine sits idle.
A finite capacity scheduler evaluates alternates as part of the placement decision: if the primary cannot accept the operation before its due date and an alternate can, the operation is routed to the alternate — with the changed setup time, the changed run time, and the changed downstream operation sequencing fully accounted for.
This is one of the largest, most invisible capacity gains in a typical shop. Many discrete manufacturers run their secondary equipment at 40–55% utilization while their primary equipment is at 110%. The constraint is not capacity. The constraint is the scheduling model.
Setup-dependent sequencing: the cheapest capacity in the building
On most CNC and fabrication equipment, the setup time between two jobs depends on which two jobs are sequenced together. Run a stainless job after a similar stainless job and the changeover is fifteen minutes. Run it after aluminum and the tool inspection, coolant flush, and fixture swap can stretch to ninety minutes.
Finite capacity scheduling that respects setup dependency clusters compatible jobs together. The capacity that appears is not new — it is hours that were being burned on avoidable changeover. In a busy shop, this typically reclaims 8–12% of spindle hours without any new machine, any new operator, or any new shift.
The math: 60 spindles × 14 hours/day × 10% reclaim = 84 extra spindle-hours per day. That is the equivalent of buying three additional CNCs every day, every shift, every week. It only requires that the scheduling model know about setup dependency — and then sequence accordingly.
A real example: 40-hour week, 80-hour release
A 120-machine job shop releases work for the week. The 5-axis cell has 40 hours of capacity. The planner releases 80 hours of work to it, because the ERP accepts the release without comment.
Monday morning the operators see the dispatch list. They run the easiest jobs first — short cycle times, familiar fixtures, no programming questions. The hot job, which has a setup dependency on a fixture currently on a different cell, sits until Wednesday. By Wednesday the customer is calling. The planner walks down, expedites it manually, and bumps three other jobs that were on time.
By Friday: the hot job ships late. The three bumped jobs ship late. Two more jobs that were waiting on the 5-axis ship late. One outside-processing partner gets a panicked call. The shop blames the operator. The operator blames the schedule. The schedule was never feasible. The OTD report shows 67% for the week, and the team has no idea what to fix because the system still says the plan was correct.
Run the same week through a finite capacity model: the scheduler refuses to slot the 80th hour on the 5-axis. The planner sees, on Friday afternoon, that next week's release exceeds capacity by 40 hours. The options are concrete — pull a job forward, push a job back, route to an alternate, add an overtime shift, or negotiate a date change with the customer. All five options are visible. The schedule that goes to the floor on Monday is feasible. OTD for the next week is 91%. Same shop, same machines, same operators. Different scheduling model.
See how Three Sigma uses finite-capacity scheduling in practice →
Infinite vs Finite Capacity
The two approaches produce fundamentally different floor behavior.
| Behavior | Infinite Capacity | Finite Capacity |
|---|---|---|
| Treats machines as | Unlimited hours | Real shift calendars |
| Bottleneck overload | Silently accepted | Flagged as at-risk |
| Promise dates | Optimistic, often missed | Tied to real capacity |
| Where the math runs | In the planner's head | In the scheduling engine |
| What operators see | 16 hours of work in 8 | A feasible sequence |
| Visibility into overload | No | Yes |
| Used in quoting | Lead times become fiction | Quote against real capacity |
ERP vs Traditional APS vs Skody
Where finite capacity scheduling actually lives in each architecture.
| Capability | ERP Scheduling | Traditional APS | Skody |
|---|---|---|---|
| Schedule source | Static work order list | Daily ERP snapshot | Live floor state |
| Capacity model | Infinite (assumed) | Finite (periodic) | Finite + labor + tooling + pallets |
| Replan frequency | Manual / MRP run | Once per shift | Continuous (event-driven) |
| Handles unplanned downtime | No | In next batch | Replan in seconds |
| Models outside processing | Manual offsets | Yes | Dynamic with partner calendars |
| Sequence-dependent setup | No | Configured | Yes |
| Pallet & lights-out aware | No | No | Yes |
| Live operator dispatch list | Static print | Daily print | Live, updates per replan |
| Implementation horizon | Already deployed | 6–18 months | 4–8 weeks |
How Skody implements finite capacity scheduling
Skody runs a finite capacity model purpose-built for discrete manufacturers. The model includes machine state, labor coverage and certifications, tooling and fixtures, pallets in FMS cells, outside-processing partner calendars, material readiness, and sequence-dependent setup time.
- Live data, not snapshots. The schedule reads from the ERP and MES continuously — not on a clock.
- Named constraints. Every at-risk job is flagged with the specific resource that cannot fit it, so the planner can act instead of investigate.
- Event-driven replan. When a machine goes down, a job finishes early, or a hot order arrives, the model recalculates the affected slice in seconds and publishes the new sequence to operator dispatch lists.
- 4–8 week deployment. No 18-month APS implementation. Skody connects to the ERP, ingests routings and constraints, and runs against a recent week of real orders as a calibration baseline.
Frequently asked questions
See finite capacity scheduling running on your data
Prepare a 30-minute demo against your work orders, routings, and constraints.
Prepare My Demo