Most mid-size FMCG plants schedule in one of two places. The ERP’s MRP run, which assumes the lines have unlimited hours. Or a spreadsheet that one person understands, built over years, that assumes whatever that person remembers. Both produce a plan the floor cannot make, which the replanning article describes from the Tuesday-afternoon end.
The textbook answer is an advanced planning and scheduling system. The textbook answer also costs a year of implementation and a budget that needs board approval, which is why most plants that looked at it still have the spreadsheet.
This article is about what finite-capacity scheduling actually is, what a plant of this size actually needs from it, and why the gap between the spreadsheet and the APS project is where most multi-line plants should land.
Finite-capacity scheduling means the schedule cannot load more work onto a line than the line has hours to run. If the week’s orders need 134 hours and the line has 120, something has to move: an order to another line, a shift added, a due date renegotiated. The plan that comes out is one the line can physically make.
Infinite-capacity planning does not ask the question. It takes each order, backs it off from its due date by the standard run time, and places it on the line. If the standards say 118 hours and the line really needs 134, it produces a plan for 118 and calls it feasible; if the standards themselves add up to 134, it still produces a plan for 134. Either way the planner discovers the problem when the line is fourteen hours behind, usually on Tuesday.
Material requirements planning, the planning engine inside almost every ERP, is infinite-capacity by design. It was built to answer “what materials do we need and when”, and it answers that well. It was not built to answer “can the lines do this”, and most plants that run their schedule from MRP have never noticed that it does not.
The spreadsheet is finite in the sense that the planner knows the line has 120 hours. It is infinite in every other sense: the run times are standards, the changeovers are a fixed number, nothing updates when the floor diverges, and the knowledge of what is possible lives in one head.
Finite scheduling is only as good as what it knows about the lines. The honest specification is short, and almost none of it lives in the ERP.
Six of those seven are operations data: they come from the floor, not from the ERP. That is why ERP-based scheduling is infinite by default, and why bolting a scheduling module onto the ERP without a source of floor data produces a finite schedule built on standard assumptions.
Four rungs. Each one does something the one below cannot, costs more, and breaks somewhere specific.
The spreadsheet. Flexible, fast to change, understood completely by one person. It has no feedback from the floor, no measured rates or changeovers, no way to handle a second planner, and it dies when its owner leaves or goes on holiday. It is where most plants are, and it is better than people admit, because the person who built it knows the lines.
MRP in the ERP. Consistent, auditable, integrated with orders, materials and finance. Infinite-capacity, blind to changeovers, running on standard rates, re-run nightly or weekly. It produces the order book; it does not produce a schedule the floor can run. Plants that believe they schedule in the ERP are usually scheduling in the spreadsheet and confirming in the ERP.
A finite scheduler fed from the floor. Takes orders and due dates from the ERP; adds demonstrated rates, the measured changeover matrix, maintenance windows, routing and live line state; produces a plan each line can make and replans it when a line diverges. Setup is days per line once the floor data exists. It does not do multi-site supply allocation, demand planning or network inventory optimization. For a single plant or a few plants with their own lines, this is the rung that fixes the Tuesday problem.
A full APS suite. The term APS covers two kinds of product. Plant-level APS tools are detailed finite schedulers, the same rung as above. Network APS suites plan across a supply network: which plant makes what, where inventory sits, how demand signals flow into the master plan, constrained optimization across the whole network. That is the rung meant here. Typically many months to implement and a budget that needs a board paper. It does things a plant-level scheduler cannot, and a company with a network of plants sharing supply and demand genuinely needs one. A six-line plant does not, and a network suite deployed at a six-line plant usually ends up running on the same standard rates and fixed changeovers as the MRP, because nobody fed it the floor data either.
The APS is not the wrong tool. It is the wrong rung for most of the plants that get sold it, and the right rung for the networks that do not buy it because the plant-level problem was never solved first.
| Plant characteristic | Spreadsheet | MRP only | Finite scheduler | Full APS |
|---|---|---|---|---|
| Single plant, lines mostly dedicated to products, changeovers trivial | Adequate | Adequate | Overkill | Overkill |
| Single plant, lines interchangeable, changeovers significant | Breaks | Breaks | Right rung | Overkill |
| Single plant, bulk-constrained with a pack line behind it | Breaks | Breaks | Right rung | Overkill |
| Two or three plants, each with its own lines, little shared supply | Breaks | Breaks | Right rung, one per plant | Usually overkill |
| Network of plants sharing supply, demand allocation across sites | Breaks | Breaks | Necessary at plant level | Right rung above it |
| Several planners who must work the same plan | Breaks | Adequate for orders | Right rung | Right rung |
The honest outcome for a mid-size FMCG plant, interchangeable lines, significant changeovers and one or two planners, is the third rung, with the ERP kept as the order source and the system of record. The APS question only arises when the plant is one node in a network that needs allocating, and even then the plant-level scheduler is what feeds the APS the truth about what each site can make.
The word alarms the IT lead, and it should not. A finite scheduler integrates with the ERP in exactly two directions. Orders, quantities and due dates come from the ERP. Planned start and finish per order go back. Confirmations, materials and finance flow the way they always did, through the ERP, untouched.
The scheduler does not replace the ERP and does not want its data model. It replaces the spreadsheet that currently sits between the ERP and the floor, and it does so with floor data the ERP never had. For the IT lead, that is a smaller and safer change than a planning module inside the ERP would be, because nothing in the system of record changes; a plan is produced from it and written back to it. The master data stays where it is.
The six-line plant used across this series: two planners, the ERP’s nightly MRP run, and a spreadsheet one of the planners has maintained for five years.
The MRP plan. For a representative week, MRP placed orders on line 3 that needed 118 hours at standard rates and changeover times, inside the 120 available, so nothing looked wrong. Capacity requirements planning, where it is switched on, reports the same 118: it can show an overload, but only one the standards can see. At demonstrated rates the orders needed 134. The spreadsheet planner absorbed the difference the usual way: a hopeful rate on two SKUs, a changeover entered at the 25-minute standard, and a Saturday shift pencilled in by Wednesday.
The finite schedule. With the demonstrated rates from the demonstrated-rate article and the measured matrix from the sequencing article, the same orders needed 134 hours on line 3, and the scheduler said so on Friday rather than on Wednesday. It then did three things. It resequenced line 3 by the matrix, removing three changeovers and about three hours. It rerouted SKU E to line 4, where the format demonstrably runs 23% faster, which took 17 hours off line 3 and added 14 to line 4, which had them. And it flagged one remaining order that would finish six hours after its due date; the planner moved it to the following Monday with the customer’s agreement, because the customer service team could see the problem on Friday instead of being told on the following Tuesday.
Line 3 closed the week planned at about 114 hours against 120, with six hours of visible contingency, part of which a rung-2 replan used on Wednesday. No Saturday shift. No APS project. Four weeks to set up, most of which was the four weeks of measurement the demonstrated rates needed. The spreadsheet was retired at the end of the second month, and its owner became the planner who runs the matrix.
The figures are illustrative; the shape is what the third rung does: the over-commitment is visible before the week starts, the fixes are a sequence and a routing change rather than overtime, and the one real conflict reaches the customer early enough to be a conversation.
The scheduling module of Fabrico’s manufacturing performance platform (MES, OEE, CMMS & AI) is the third rung, built to be fed from the same platform’s floor data.
Finite by construction. The scheduler cannot load a line beyond its available hours net of maintenance windows. Where the orders need more than the line has, it shows the conflict and the options rather than issuing a plan that cannot be made.
Fed from the floor. Demonstrated rates per SKU per line and the measured changeover matrix come from the OEE module; bulk constraints and planned maintenance come from the same system; live line state drives replanning on the ladder. A plant without measured rates yet runs the scheduler on its existing estimated times from day one and replaces them with measurements SKU by SKU as the data arrives; estimated times are a fully supported way to operate, not a stopgap.
Orders in, plan out. Orders, quantities and due dates come from the ERP; planned start and finish go back. The ERP stays the system of record and the master data does not move.
Priced by margin. With the selling price and margin entered once per SKU, the financial impact module shows each candidate schedule as margin as well as hours, so a conflict is resolved by what it costs rather than by which order shouts loudest.
Insights on the constraint. The AI actionable insights distinguish a constraint that is a planning choice from one that is a bad actor, a slow format or a bulk cycle, and route the second kind to the people who can remove it, with the value attached.
What it is not. It is not a multi-site network optimizer and it is not a demand planner. A company allocating demand and supply across a network of plants needs an APS for that layer, and Fabrico sits under it as the plant-level truth about what each site’s lines can actually make, which is the input an APS most often lacks. For the single plant or the small group with its own lines, the plant-level scheduler is the whole answer, and the APS project can stay un-started.
What is finite-capacity scheduling? Scheduling in which a line cannot be loaded with more work than it has hours to run, so that conflicts between demand and capacity are resolved in the plan rather than discovered on the floor. It requires knowing the lines’ real rates, changeover times, maintenance windows and routing options.
What is the difference between MRP and APS? MRP, the planning engine inside most ERPs, calculates material requirements by backing orders off their due dates and assumes infinite capacity. An APS plans and schedules against finite capacity. The term covers both plant-level detailed schedulers and network suites that plan across sites and the supply network, often with demand planning. A plant-level finite scheduler fed from the floor does the capacity part for one plant without the network layer.
Do I need an APS? If you allocate demand and supply across a network of plants, probably yes, for that layer. If you run one plant or a few plants with their own lines, you need a finite scheduler fed from the floor, and a network suite deployed at plant level will usually end up running on the same standard rates and fixed changeovers as the MRP it replaced.
What does an APS cost? Typically a multi-month implementation and a six- to seven-figure budget including licensing, integration and consulting, varying widely by vendor and scope. A plant-level finite scheduler is set up in weeks per plant, and most of that time is the measurement of rates and changeovers it needs.
Can you do finite scheduling in Excel? Up to a point, and many planners do. The limits are no feedback from the floor, no measured rates or changeover matrix unless entered by hand, no replanning when a line diverges, and dependence on one person. It works until the plant has interchangeable lines, significant changeovers or a second planner.
What is the difference between planning and scheduling? Planning decides what to make, how much and roughly when, usually weekly or monthly, from demand. Scheduling decides the sequence and timing of orders on specific lines, by shift, against the lines’ real capacity. Most plants plan in the ERP and schedule in a spreadsheet; the finite scheduler replaces the spreadsheet.
If the schedule comes from the MRP run or a spreadsheet, nobody has seen the hours it is loading onto each line against the hours the lines have. Four weeks of measured rates and changeovers will show the gap, and one week scheduled finite will show what closes it without a new system of record.
The fixed-scope pilot does that on one line: six weeks, demonstrated rates per SKU and the measured changeover matrix captured with an industrial sensor and hub installed with your team, and in the readout a representative week scheduled finite against the current plan, with the over-commitment in hours, the sequencing and routing changes that remove it, and the three highest-value interventions. The fee is fixed and credited in full against a first-year subscription if you roll out. The pilot runs on Fabrico’s manufacturing performance platform (MES, OEE, CMMS & AI), which connects machine data, OEE and loss analysis, production scheduling, SKU-level output value and maintenance in one system, so the finite schedule is fed by the floor, not by standards.
Request a demo or read how the scheduling module works with your ERP as the system of record.
Login
Blog
