Production scheduling software
Production scheduling software
Production scheduling software decides which job runs on which machine and when. Before comparing products, it is worth knowing what you are actually replacing: in most plants this size, the real schedule is a spreadsheet a planner rebuilds every week, and it is winning for reasons worth understanding.
What is production scheduling software?
Production scheduling software decides which job runs on which machine, in what order, and when. The useful version schedules against finite capacity, meaning it knows how many machines, people and hours actually exist, rather than assuming the plant can absorb whatever the order book contains.
That distinction is the whole category. Most ERP systems plan to infinite capacity: they work backwards from a due date and tell you when an operation should start, without asking whether four other jobs already need that machine on Tuesday. The dates look authoritative and the floor knows they are fiction.
Finite capacity scheduling, sometimes sold as advanced planning and scheduling, does ask. It holds a model of your machines, your people and your constraints, and produces a sequence that could actually happen. Products in this space include PlanetTogether, Asprova, Oracle's scheduling tools, and the APS modules sold alongside SYSPRO, Epicor and Infor.
This page is written for manufacturers between roughly fifty and five hundred people. If that describes you, there is something worth saying before any of those names matter.
What are you actually replacing?
A spreadsheet. In almost every plant this size, the real schedule is a file a planner maintains by hand, rebuilt most weeks. Every comparison of production scheduling software measures products against each other. The incumbent is not a product, and it is winning.
That file is treated as an embarrassment. It should be treated as a specification.
Somebody built it because the system in front of them could not do the job and the work still had to go out of the door. It holds the exceptions: the customer who always reschedules, the press that needs a longer changeover on Mondays, the operator who is the only one certified for a particular weld. None of that is written anywhere else.
Here is what usually happens next. A scheduling product gets bought. Everyone agrees this time the spreadsheet goes away. Eighteen months later the planner is maintaining it again, because the new system cannot express the Monday changeover either, and the work still has to go out of the door.
So before evaluating anything, read the file. Properly. It is a requirements document that took five years to write and cost nothing, and it is the single most valuable artefact in this entire decision.
What does a schedule need to know, and where does that live now?
Six things: due dates, operation times, machine capability, changeover times, labour availability and informal priority. Your ERP reliably holds the first. The rest live in a spreadsheet, in somebody's head, or nowhere at all, and that is the real constraint on any scheduling project.
| What a schedule needs | Where it lives today | Why that matters |
|---|---|---|
| Which jobs are due when | The ERP | The one thing the system reliably knows. |
| How long each operation really takes | Nowhere, or badly wrong | Standard times were set once, often years ago, and nobody has revisited them. This is the data finite scheduling depends on most. |
| Which machine can run which job | Somebody's head | The planner knows the old press cannot hold tolerance on thin stock. It is written down nowhere. |
| Changeover time between jobs | Somebody's head | Sequence dependent and rarely captured. Running similar jobs together is most of the gain available on a shop floor. |
| Who is in tomorrow | A different spreadsheet | Labour constraints are usually outside the scheduling system entirely. |
| Which customer will escalate | The planner, entirely | The informal priority that overrides the formal one. No system models it and every plant runs on it. |
The second row is the one that sinks projects. Finite capacity scheduling multiplies your operation times across every job in the plan. If those times were set when the work was quoted and never revisited, the software will produce a confident, precise, wrong schedule, and it will produce it faster than the spreadsheet did.
The fifth row matters more on a small team than the tables suggest. A plant with forty people often has one person certified for a particular process, and a scheduler that models machines perfectly while treating labour as unlimited will cheerfully plan two jobs that both need that person at the same hour. Ask about it specifically.
The last row is the one nobody models. Every plant has an informal priority order that overrides the formal one, usually involving which customer escalates fastest. No scheduling engine represents this, and any system that cannot be overridden in thirty seconds will lose to one that can.
Why does the ERP's scheduling module get abandoned?
Five reasons, and only one is about features. It schedules to infinite capacity, the rules cannot express reality, rescheduling is slower than replanning by hand, the data underneath is wrong, and it cannot be changed when the business changes.
| Reason | What it looks like | What happens next |
|---|---|---|
| It schedules to infinite capacity | The ERP says eleven jobs can run Tuesday because it never asks how many machines exist. | The planner stops trusting the dates and rebuilds them by hand. |
| The rules are too rigid to express reality | No way to say this operation needs the same operator as the previous one, or that this material needs a day to acclimatise. | The exceptions move to a spreadsheet, and then the exceptions become most of the schedule. |
| Rescheduling takes longer than scheduling | A machine goes down at 10am. Re-running the plan takes forty minutes and produces something nobody believes. | Everyone reverts to the whiteboard for the rest of the week. |
| The data underneath it is wrong | Standard times from 2019, routings that skip the deburring step everyone actually does. | The output is precise and incorrect, which is worse than a rough estimate. |
| It cannot be changed when the business changes | A new cell, a new shift pattern, a new customer with different rules. | A change request goes to a reseller, waits, and the spreadsheet fills the gap meanwhile. |
The fourth row is worth dwelling on because it is the one a buyer can check before spending anything. Pull ten recent jobs, compare the hours booked against the standard times in the system, and look at the spread. A consistent small gap is tolerable and can be corrected with a multiplier. A wide and unpredictable spread means the standards are not describing the work at all, and every plan built on them inherits that noise.
The third row deserves attention because it is about speed rather than capability. A scheduling system is used dozens of times a week, usually in a hurry, usually because something broke. If re-running the plan takes forty minutes, it will be used once a week at best and the real decisions will be made on a whiteboard. Responsiveness is a feature, and it is rarely on anyone's requirements list.
Should you buy, fix, or build?
Fix the data first in most cases. The ERP's scheduling module is often adequate and the problem is the routings and times feeding it. Buy an APS product when the data is sound and the constraints are genuinely complex. Build when your rules are unusual enough that no product expresses them.
| Option | What it means | Right when |
|---|---|---|
| Fix the data, keep the ERP | Routings and operation times corrected, scheduling module reconfigured | The ERP's module is adequate and the real problem is the data feeding it. Cheapest by a wide margin and the most commonly correct answer. |
| Buy an APS product | A dedicated scheduling engine alongside the ERP | You have accurate data, genuinely complex constraints, and enough volume that optimisation pays. Expect an integration project either way. |
| Build around what you have | A scheduling layer that reads the ERP and encodes your actual rules | Your constraints are unusual enough that no product expresses them, and the planner's spreadsheet already proves what the logic should be. |
| Change nothing yet | Write down what the planner does, first | Nobody can describe the current rules. Until they are written, every option above is a guess with an invoice attached. |
We build software, so the honest disclosure is that the fourth row and the first row both cost us a project. We would still start there. A plant that corrects its routings and operation times often finds the existing module becomes usable, and that outcome costs a fraction of anything else on this page.
The case for buying is real when the volume justifies optimisation: many jobs, many machines, sequence dependent changeovers, and data clean enough to trust. The case for building is narrower than vendors of custom software usually admit, and it is strongest when the spreadsheet already demonstrates logic no product can express.
Why do scheduling projects fail?
Five failure modes: buying before the data is right, modelling constraints nobody enforces, replacing the planner instead of arming them, ignoring changeover sequence, and having no owner after go live.
| Failure mode | What it looks like | What prevents it |
|---|---|---|
| Buying before the data is right | Finite scheduling multiplies whatever operation times you give it. Wrong times produce a confident wrong plan. | Audit a sample of routings against reality before signing anything. |
| Modelling constraints nobody enforces | Six months spent encoding rules that the floor overrides daily anyway. | Watch a week of actual decisions before deciding which constraints are real. |
| Replacing the planner rather than arming them | A system that produces a schedule nobody can override loses to a spreadsheet somebody can. | Optimise for a plan the planner can adjust in thirty seconds. |
| Ignoring the changeover sequence | Scheduling by due date alone, when grouping similar setups is where the hours actually are. | Capture changeover matrices even roughly. Rough and present beats precise and absent. |
| No owner after go live | Shift patterns change, a cell is added, nobody updates the model. | Name who maintains it, and make routine changes a form rather than a support ticket. |
The third row is the cultural one and it decides adoption. A schedule is a negotiation between what the system thinks and what the planner knows. Systems that treat the planner as the problem get worked around within a month. Systems that make the planner faster get used.
The fourth is where the money usually hides. On a shop running similar parts, sequencing to group changeovers frequently recovers more hours than any optimisation of the job order itself. Capturing a rough changeover matrix, even on paper, is often the highest return week of work available.
MRP, APS or MES: which do you actually need?
MRP plans what to buy. APS plans what runs where and when. MES records what actually happened. Most plants asking about scheduling have MRP in their ERP, no APS, and no reliable floor data, which means the missing piece is often the measurement rather than the planning.
| Category | What it answers | What to know |
|---|---|---|
| MRP | What to buy and when, from demand and lead times | Nearly every ERP has it. It plans materials, not machine time, and it assumes infinite capacity. |
| APS | What runs where and in what order, against real capacity | The category this page is about. Sits beside the ERP and schedules finitely. |
| MES | What is happening on the floor right now | Execution and data capture rather than planning. Feeds the schedule with reality. |
| Shop floor data capture | Job start, job finish, downtime, scrap | Often the missing prerequisite. Without it, nobody knows how long operations really take. |
The fourth row is the one bought last and needed first. Finite capacity scheduling is arithmetic performed on operation times. If nobody is capturing when jobs actually start and finish, those times are estimates made at quoting, and the schedule inherits every one of their errors.
This is why the sequence we recommend sometimes looks backwards. Capture a few weeks of real job times, compare them to the standards, and only then decide whether you have a scheduling problem or a data problem. Plants that skip this step frequently buy an optimiser and discover it optimised against fiction.
There is a reasonable counter argument: full shop floor data capture is itself a project, and waiting for it can delay scheduling by a year. The compromise that usually works is to measure one cell or one product family by hand for a month. That is enough to tell you whether your standards are roughly right or badly wrong, and badly wrong is the only answer that changes the decision.
What should you test in a demonstration?
Five things, and none of them is a feature list. Your own three worst jobs, a machine breakdown at ten in the morning, a sequence dependent changeover, a manual override, and adding a new machine. Every product demonstrates well on sample data.
| Test | Why it separates products |
|---|---|
| Your own three worst jobs | Not sample data. The one with the special sequence, the one that always slips, the one needing the certified operator. |
| A machine breakdown at 10am | Ask them to reschedule live and time it. If it takes forty minutes it will not be used in a hurry, which is when scheduling matters. |
| Sequence dependent changeover | Give them your changeover matrix, however rough, and ask to see grouping. Many products cannot do this and few volunteer it. |
| A manual override | Ask the planner to move one job and watch what happens to everything else. Thirty seconds is usable. Five minutes is not. |
| A new machine added | Who does it and how long. If the answer involves a support ticket, the model will drift out of date within a year. |
Send your three worst jobs in advance. How a vendor responds to that request tells you a great deal before the demonstration even happens. Some will ask good questions about your constraints. Some will explain why your examples are unusual, which is a preview of every conversation you will have during implementation.
The breakdown test is the one most worth insisting on. Scheduling systems are used hardest on bad days, and a tool that produces a beautiful plan on Monday morning but cannot respond on Wednesday afternoon will be abandoned by Thursday. Time it with an actual clock.
One more worth adding if you run mixed work: ask to see a job that needs two scarce resources at once, such as a specific machine and the only certified operator. Products that model machines well often model people badly, and on a small team that is where the schedule actually breaks.
What does production scheduling software cost?
Licensing is rarely the largest line. Correcting routings and operation times, integrating with the ERP, and the time of the people who understand the plant usually exceed it. Any quote that covers only the software is describing a fraction of the project.
Published figures in this category are inconsistent and mostly vendor supplied, so rather than add another number, here is the structure of where the money goes.
The data work. Auditing routings, correcting standard times, capturing changeover matrices. Unglamorous, frequently the largest line, and almost never in a proposal because it is work the customer is assumed to have already done.
The integration. Reading jobs and routings from the ERP, writing the sequence back, keeping the two in step when something changes on either side. If a proposal does not name your ERP, it has not been scoped.
Your own people. The planner who understands the constraints is the person the plant can least spare, and this project needs several weeks of their attention. Budget it honestly or the project stalls waiting for them.
The year after. Shift patterns change, cells are added, a new product family arrives with different rules. If every change is a support ticket, the model drifts and the spreadsheet comes back.
The number worth asking every vendor for is the total first year cost including data work, integration and training, for a plant of your size and complexity. A vendor who gives a range and explains what moves it is telling you something useful. One who quotes only a licence fee is telling you something as well.
How do you know whether it worked?
Five measures, and on time delivery is the slowest of them. Setup hours per week, planner time spent scheduling, schedule adherence and expedite frequency all move sooner and tell you more about whether the system is actually being used.
| Measure | What it is | Why it matters |
|---|---|---|
| On time delivery | The number the business already cares about | Slow to move and influenced by everything else, so useful over quarters rather than weeks. |
| Setup hours per week | Time lost to changeovers | The fastest signal that sequencing improved. Often the single largest recoverable number. |
| Planner hours spent scheduling | How long the weekly rebuild takes | Easy to measure, immediately felt, and the one that tells you whether the tool is actually being used. |
| Schedule adherence | How closely the floor followed the plan | If this stays low the schedule is not believed, which is a different problem from a bad algorithm. |
| Expedite frequency | How often a job jumps the queue | Counts the informal priority nobody modelled. Rising numbers mean the plan does not reflect reality. |
Record all five for a month before anything changes. Almost nobody does, and without a baseline every later claim about improvement is an argument rather than a measurement. It costs a spreadsheet and ten minutes a day.
The one to watch most closely is planner hours. If the weekly rebuild took six hours before and takes five after, the tool is not being used as intended, whatever the schedule quality looks like. If it drops to one, you have your answer regardless of what happened to on time delivery that quarter.
Schedule adherence deserves a note too. A low number after go live usually means the floor does not believe the plan, and that is a constraint modelling problem rather than a software problem. It is also the most common reason a technically sound implementation quietly fails.
Does the right answer depend on what you make?
Yes, more than on company size. A job shop needs sequencing and changeover grouping. Repetitive production needs flow and batching. Engineer to order needs engineering capacity modelled, not just machines. Process manufacturing breaks assumptions a discrete scheduler makes everywhere.
| If your work is | Meaning | What the scheduler must be good at |
|---|---|---|
| Job shop, make to order | Every job different, routings vary | Sequencing and changeover grouping. Due date promising matters more than throughput. |
| Repetitive, high volume | The same things, many times | Line balancing and flow. Changeovers are fewer and larger, so batching decisions dominate. |
| Engineer to order | Designed then built, each one unique | Capacity for engineering, not just machines. The drawing office is usually the real bottleneck. |
| Process, batched | Mixed and measured rather than assembled | Tank and vessel availability, cleaning between batches, shelf life. A discrete scheduler fits badly. |
| Mixed mode | More than one of the above | Honesty about which mode dominates. Most products are genuinely good at one and adequate at the rest. |
The third row is the one that surprises people. In engineer to order work the machines are rarely the constraint. The drawing office is. A scheduling system that models every machine perfectly and ignores engineering capacity will produce plans that are optimistic in exactly the way your business already is, which helps nobody.
The fourth row is the expensive mismatch. Process manufacturing involves vessels that must be cleaned between incompatible batches, materials with shelf lives, and yields that vary. Forcing that onto a scheduler built for discrete parts produces a model somebody has to fight weekly. If you make paint, food, chemicals or anything with a formulation, say so in the first minute of every vendor conversation.
Say the mode out loud early. A vendor who claims equal strength across all of these is giving you a sales answer, and you will discover which one they are genuinely good at during implementation rather than during selection.
What actually changes on the floor?
Three things, in roughly this order: fewer changeovers because similar jobs run together, fewer expedites because the promise dates are believable, and a planner who spends the morning deciding rather than rebuilding. On time delivery moves later, and more slowly than anyone expects.
Changeovers first. This is usually where the recoverable hours are, and it moves within weeks of a working sequence. On a shop running related parts, grouping similar setups frequently recovers more time than any improvement to job ordering, which is why the changeover matrix matters more than the optimisation algorithm.
Then expedites. When dates come from a schedule that accounts for real capacity, sales stops promising things the floor cannot do, and the informal priority queue shortens. This one is cultural as much as technical and takes a quarter or two to show.
Then the planner's week. The rebuild that took most of Monday becomes an adjustment that takes an hour. That time goes back into the decisions a person is better at than software: which customer to call, which job to split, which promise to renegotiate early rather than late.
What does not change immediately is on time delivery, and anyone promising otherwise is overselling. It is influenced by supply, quality, absence and a dozen other things scheduling does not touch. It is the right number to care about and the wrong number to judge the first quarter by.
One honest caution. If the plant currently runs on heroics, a schedule that is merely accurate can feel like a downgrade, because it makes visible how much was never going to fit. That visibility is the point, and it is uncomfortable for a few weeks before it becomes useful.
How would Voliom approach this?
Two weeks reading the planner's spreadsheet and auditing a sample of routings against reality, then a recommendation that is often smaller than the project you asked about. Where we do build, it reads your ERP and encodes the rules that currently live in one person's head.
Read the file first. We sit with whoever maintains the schedule and work through it line by line. What is this column for. Why is this job always moved. The output is a written set of scheduling rules you own, and it is useful whatever you decide next.
Audit the data before recommending software. We take a sample of routings and compare the standard times to what actually happened on recent jobs. If they are materially wrong, no scheduling product will help you until they are fixed, and we will say so before quoting anything larger.
Where we build, we build around the ERP, not over it. The system of record stays where it is. The scheduling layer reads from it, applies your rules, and writes the sequence back. You are not migrating anything.
The planner can override it in thirty seconds. That is a design requirement rather than a feature. A schedule nobody can adjust is a schedule nobody uses, and we would rather ship something slightly less optimal that gets used daily.
If the honest answer after two weeks is that your manufacturing scheduling software is fine and your routings are not, that is the recommendation you will get. It happens often enough that we price the first phase to stand alone.
What should you do before calling anyone?
Three things, all free. Export the planner's spreadsheet and keep a copy. Time ten real operations against their standard times. Then write down the five rules the planner applies that exist nowhere in the system.
Keep a copy of the spreadsheet. Not a screenshot, the file with its formulas. If the planner leaves, that file is the only record of how your plant schedules, and plenty of companies have discovered that the hard way.
Time ten operations. Pick jobs that ran recently, compare actual to standard, and note the gap. If the gap is routinely over about twenty percent, your scheduling problem is a data problem and no purchase will fix it.
Write down five rules. Ask the planner what they know that the system does not. You will get answers like the old press cannot hold tolerance on thin stock, or this customer gets priority regardless of the due date. Five is enough to show whether a product could express them.
That exercise costs a week of part time attention and it changes every subsequent conversation, including the one where a vendor tells you their product handles everything. You will know precisely which two things to ask them to demonstrate.
One more thing worth doing, and it is free. Sit beside the planner on a Monday and watch the rebuild without helping or asking questions. Note every time they pause, every time they open another file, every time they telephone somebody to check something. Those moments are the constraints that exist nowhere in writing, and an hour of watching surfaces more of them than a week of interviews.
Most businesses are surprised by what that hour reveals. The step everyone complains about is rarely the one consuming the time, and the step consuming the time is often a lookup in a document that could be automated in an afternoon without buying anything at all.
FAQ
Common questions
What is production scheduling software?
Production scheduling software decides which job runs on which machine, in what order, and when. The version worth buying schedules against finite capacity, meaning it knows how many machines, people and hours exist. Most ERP modules plan to infinite capacity, which is why their dates are often treated as fiction on the floor.
What is the difference between finite and infinite capacity scheduling?
Infinite capacity scheduling works backwards from a due date without asking whether the machine is free, so it can place four jobs on one machine at the same time. Finite capacity scheduling holds a model of real resources and produces a sequence that could actually happen. Most ERP scheduling modules are the former.
Do we need separate scheduling software, or will our ERP do it?
Often the ERP is adequate and the data feeding it is not. Before buying anything, compare standard operation times against what recent jobs actually took. If the gap is routinely over about twenty percent, fixing the routings will do more than any purchase, and it costs a fraction as much.
Why does the planner still use a spreadsheet?
Because it holds the exceptions the system cannot express: sequence dependent changeovers, machine capability limits, the customer who always escalates. That file is not a failure of discipline. It is the only written specification of how your plant actually schedules, and it should be read before anything replaces it.
How much does manufacturing scheduling software cost?
Scope decides it and any number before a conversation is a guide. The pattern worth knowing is that licence cost is rarely the largest line. Correcting routings and operation times, integrating with the ERP, and the time of the people who understand the plant usually exceed it, and those are the lines most often missing from a quote.
How long does a scheduling implementation take?
A data audit and a written set of scheduling rules is commonly two to four weeks. A working scheduling layer for one production area is usually eight to sixteen weeks after that. The variable is almost never the software. It is how long it takes to get accurate operation times and to extract rules from the people holding them.
Can scheduling software handle sequence dependent changeovers?
Some can and many cannot, so it is the first thing to test in a demonstration. Grouping similar setups is frequently where the recoverable hours actually are on a shop running related parts. Ask every vendor to demonstrate it with your own changeover matrix rather than their sample data.
Will this replace our planner?
No, and a system designed to is the kind that gets worked around within a month. A schedule is a negotiation between what the system calculates and what the planner knows about today. The practical test is whether a planner can override the plan in about thirty seconds. If not, they will go back to the spreadsheet.
Can you integrate with our existing ERP?
Usually yes, and we ask which system you run and whether it exposes an API before quoting rather than after. The scheduling layer should read from your system of record and write the sequence back, so nothing migrates and the ERP stays authoritative.
Keep exploring
Related services
- Manufacturing softwareShop floor, scheduling and ERP gaps
- Systems integrationReading and writing your ERP
- Manufacturing software guideWho writes the rankings, and why
- Application modernizationWhen the system itself is the problem
Let's talk
Tell us what you're building.
Get a free 30-minute strategy call. You'll leave with a clear plan, a realistic estimate and our honest opinion, whether or not you work with us.
- Email usmail@voliom.com