Finite capacity scheduling (FCS) produces production schedules that respect the actual capacity of machines, labor, materials, and tools rather than assuming infinite capacity is available at every resource. The schedule it produces is feasible: work orders are sequenced on specific resources at specific times, accounting for setups, parallel resources, calendars, and constraints.
The alternative infinite capacity scheduling, which is how most ERP MRP runs work produces a plan that assumes any quantity can be made in any period. The plan looks feasible on paper but typically isn't executable on the shop floor without significant manual adjustment. Schedulers and supervisors spend their day reconciling the MRP output with what the plant can actually do.
This page covers how FCS works mathematically, where it pays back versus where it's overkill, and what implementation actually involves.
Horizon's FCS module covers discrete and process manufacturing with native handling of sequence-dependent setups, parallel resources, resource calendars, batch size constraints, and material availability. The scheduling engine uses a combination of constraint programming and metaheuristics, selected based on problem size and refresh cadence.
The integration with upstream supply planning is direct: the FCS schedule consumes the production plan from supply planning and produces a feasible schedule. Material requirements feed back to procurement so raw material orders reflect the actual scheduled consumption, not the period-aggregate from MRP.
For schedule changes during the shift (unplanned downtime, material shortage, urgent order), Horizon supports real-time re-scheduling that respects work-in-progress and updates only the affected portion of the schedule rather than rebuilding from scratch.
The honest scope: Horizon's FCS is built for discrete and process manufacturers with 1-10 plants and routings of moderate complexity. Companies needing semiconductor fab scheduling, refinery scheduling, or extremely specialised process structures often need specialised tools. We'll be explicit about that fit in early conversations.
Most ERP MRP runs treat capacity as infinite by default. The reason is mathematical: MRP was designed in the 1970s to compute material requirements, not optimize against constraints. Finite capacity math is more complex and computationally expensive. The trade-off in early MRP was: produce a plan that's mathematically tractable, accept that it may not be feasible, and let humans reconcile.
That reconciliation is where the cost lives. A typical mid-size discrete manufacturer running infinite-capacity MRP has 1-2 schedulers who spend 60-70% of their time adjusting MRP output to match real capacity sequencing work orders, splitting batches, expediting around constraints, identifying which orders to slip when capacity is short. This work isn't visible in cost accounting but consumes significant skilled labor and produces inconsistent results (one scheduler's adjustments aren't the same as another's).
The second hidden cost is in execution. Infinite-capacity plans that don't account for sequence-dependent setups produce schedules with more changeovers than necessary. Plans that don't account for parallel resources don't load the shop floor effectively. The net effect is typically 10-20% lower OEE (Overall Equipment Effectiveness) than what FCS would produce on the same resources.
The third hidden cost is in customer service. Infinite-capacity plans that promise orders the shop floor cannot actually deliver create a chronic gap between sales commitments and production reality. The result is missed promises, expedites, and customer service degradation that the ERP never sees because the data layer is decoupled from physical execution.
FCS is a constrained optimization problem. The inputs are:
The scheduler computes a Gantt chart each work order's start and end time on specific resources that satisfies all constraints and optimizes the objectives.
FCS uses several method families, often in combination:
The right method depends on the size of the problem and how often the schedule needs to refresh. A schedule refreshed daily can use slower, more optimal methods. A schedule refreshed every shift may need faster methods that sacrifice some optimality.
