Advanced planning and scheduling: what a schedule has to satisfy

It assumes you know your process and have never bought scheduling software.

Production scheduling constraints a real line has to satisfy

Start with the constraints, because the software is only interesting to the extent that it can represent them. A machine runs one job at a time, and the time to go from the job it is running to the next usually depends on which two jobs those are. Light colour to dark is a wipe; dark to light is a purge and a clean. That is sequence-dependent setup: the setup time is a property not of an operation but of a pair of operations on a particular resource, since the same colour change costs one thing on a large press and another on a small one, and on some lines it also depends on machine state. It is the constraint most often missing from the system of record, which is why a plan out of ERP so often looks like a sorted list rather than a sequence.

Then the constraints not attached to one machine, which on plenty of lines bind harder than the setup matrix does. A die, a mould or a test rig can only be in one place at a time, so two cells that could each run the order cannot both run it. A qualified operator is the same kind of scarce object: three people on shift and one certified for the weld class means that class has a capacity of one. Compressed air, an oven or a crane binds across an area, so two jobs that individually fit may not fit together.

Material availability is a hard precondition and a soft input. The order cannot start before the component arrives, but the arrival date is a promise from a supplier with its own reliability. The schedule should therefore show which orders depend on a delivery that has not yet landed, so that the exposure is visible on the plan rather than averaged into a lead time and discovered on the morning the material fails to arrive.

Calendars carry more than people expect. Shift patterns differ by area rather than by plant: heat treatment runs through the night while assembly does not, and a Friday changeover that cannot be finished before the shift ends will be done twice. Maintenance windows, holidays and the annual shutdown are periods where a resource exists on the asset list and is not available to production.

And there are process rules that have nothing to do with capacity. Curing, drying, cooling and quarantine impose minimum waits between operations, and often maximum ones too: cure for at least four hours, coat within twenty-four, use the mixed adhesive inside its pot life, wash the part before flash rust forms. A scheduler that understands minimum waits but not maximum ones will quietly produce plans that scrap material. Some pairs of operations must be consecutive because the part cannot be left part-finished; some batches must be built to a tank size rather than to a demand quantity.

Why the MRP run produces dates nobody can hit

MRP is doing something genuinely useful, and it is not scheduling. It explodes demand through bills of material, nets against stock and open orders, offsets by a fixed lead time per item, and tells you what to make or buy and roughly when to start. To do that across thousands of parts, it assumes capacity is available whenever the arithmetic asks for it.

That assumption fails quietly. Two orders both want the press at ten o'clock and MRP places both there. The lead time offset is a number set once, an average of queue, run and move time under conditions that no longer apply, and changeovers are either absent or hidden inside it as a flat allowance that does not depend on sequence. The result is arithmetically consistent and physically unachievable, which is worse than being wrong, because it looks correct in the system.

The floor absorbs the difference. Someone re-sequences by hand, usually well, using knowledge that lives in one or two heads, and the plan becomes a suggestion. Everything derived from it inherits the error: promised delivery dates, purchasing timing, staffing, the capacity number quoted to sales. When a planner responds by inflating lead times, the protection is real and so is the cost, because inflated lead time is work released early, which becomes work in progress sitting between stations.

The spreadsheet that replaces those dates is a genuine improvement with a ceiling. It works because the planner holds the changeover matrix and the tooling conflicts in his head, and it fails on scale, on his holiday, and on the question of what breaks if this order is accepted.

What finite-capacity scheduling changes

Finite-capacity scheduling turns the question around. Instead of asking when an operation should start if nothing is in the way, it places operations onto resources that already have work on them, respecting setups, calendars, tooling and precedence, and reports the dates that fall out. The dates become an output rather than an input.

The consequences are practical. The sequence on each resource is explicit, so the setup matrix can be exploited: where setup is a material share of available capacity, grouping compatible products recovers changeover hours without capital. Whether that is your situation is one number you can measure this week, and worth measuring first, because on a line with five-minute changeovers and a material problem the sequencing recovers almost nothing. Bottlenecks become visible as loads rather than as opinions. Because the plan is constrained, adding an order shows what it displaces, which is what makes a credible delivery promise possible.

It also changes release. An infinite-capacity plan releases work as early as the offsets allow; a finite plan releases when the constraint can take it, which pulls work in progress down and shortens the distance between making a defect and finding it. None of it is free: the model has to be maintained, and is only as honest as the times in it.

Planning, scheduling and dispatching are three different jobs

Conflating these is the most common reason a scheduling project produces something nobody uses. Planning works in weeks and months. It answers whether demand is feasible in aggregate, whether a second shift is needed in March, what to commit to suppliers. The unit is a family and a week; more precision would be false, because the demand is not precise either.

Scheduling works in hours and days. It answers the sequence on each resource for the next shifts, with the setups that sequence implies, and it is what APS most specifically means.

Dispatching works in minutes. It answers what the operator at this cell starts next, given the stop, the failed first-off, the material that did not arrive. It belongs in whatever the operator actually looks at — an MES terminal, a dispatch list, a sequence taped to the machine — and what matters is that it sits close to the work and is allowed to deviate from the schedule, because reality gets a vote.

The failure mode is using one tool at the wrong altitude: scheduling to the minute three weeks out, or planning capacity from a dispatch list. The other is forbidding deviation at the dispatch layer, which makes the system an obstacle and guarantees it gets worked around.

What data an APS needs: routings, cycle times, changeovers

A scheduling engine is a calculation over your master data. If the data is decorative, the output is decorative and confident.

Routings have to reflect how the part is really made, including alternates. If a job can run on three machines but the routing names one, the scheduler queues work there and reports a bottleneck you do not have. If a routing omits an operation that always happens — a deburr, an inspection, a wait for cooling — every date is short by that much.

Cycle times have to be measured rather than inherited. Standard times in most ERP systems were entered at go-live and reflect a tool and an operator that may no longer exist. You do not need perfect times, only times whose error is small and unbiased: a route where every operation is optimistic by the same margin compounds into a schedule a shift wrong by the end of the week.

Changeover times are the data most often missing entirely, and the most valuable. A full matrix of every product pair is rarely maintainable. What works is grouping products into families by what actually drives the setup — colour, material, tool, temperature, width — and defining times between families, with exceptions only where they matter. Expect to hold that family-to-family matrix per resource group rather than once for the plant, because the same transition rarely costs the same on two different machines.

Current work in progress is the part people forget. A schedule for tomorrow starts from the state of the floor tonight: what is part-finished, where it is, what is set up on each machine. If that state is typed in at shift end from a paper sheet, the scheduler is optimising a factory that existed hours ago.

Bad data announces itself. One resource is always saturated and everything else idle, which usually means routings funnel to it artificially. Planners override the same orders every day, which means a constraint is missing from the model. Jobs are confirmed in batches at the same minute, which means the confirmations are retyped later and the start times are fiction. The instinct is to tune the engine; the cause is almost always the master data.

How to judge a schedule

On-time delivery is the outcome that matters, measured against the date given to the customer rather than the most recently revised internal one, or the number will improve while the customer's experience does not.

Total changeover hours per week is the cleanest measure of whether the sequencing is doing work, and it is directly convertible into capacity.

Work in progress and flow time say whether the plan is releasing sensibly. A schedule that improves on-time delivery by flooding the floor with early releases has moved the problem into the aisles.

Schedule adherence — how much of what was planned for a shift was actually run, in the planned sequence — is the honest measure of whether the plan is believable. A schedule with excellent theoretical metrics that the floor stopped following before lunch is a document.

Utilisation is the trap. Keeping every machine busy on a non-constraint produces inventory, not throughput, and a line loaded near its ceiling everywhere has nothing left to absorb variability, so queues grow non-linearly and lead times get worse as the utilisation number improves. Watch it at the constraint and largely ignore it elsewhere.

Rescheduling policy and schedule nervousness

An engine that can re-plan in seconds invites constant re-planning. Resist it. If the sequence changes every time anything moves, the floor learns that the plan at eight is not the plan at ten, and reverts to running whatever seems sensible. That instability is called nervousness, and it destroys trust faster than a mediocre schedule does.

The usable pattern is a frozen horizon and a policy. Inside the window the sequence does not change except for genuine blockers, so setups already begun are not wasted; beyond it, re-optimisation is allowed. The rule of thumb is to re-plan no more often than the frozen window is long, and to set that window from two things you can observe in the area: how long a setup takes, and how often a genuine blocker arrives. A machine shop with hour-long jobs and a tool clash most days will freeze a few hours and re-plan every shift; a process plant running week-long campaigns will freeze days. Either way, the scheduled runs are supplemented by event-triggered ones for a machine failure, a missing delivery or an urgent order.

Two things make the policy work. The exception list has to be explicit: what counts as a reason to break the freeze, and who may authorise it. And when the schedule does change, the supervisor has to be able to see why, because an unexplained change reads as the software being unreliable.

Where APS sits next to ERP and MES, and who decides what

ERP owns the commercial and material world and is the source of what has to be made and by when. APS owns the sequence, taking demand and material from ERP, constraints from its own model, and floor state from execution. MES owns execution and the record of it, and it is also the sensor for APS, without which the scheduler is blind to the present.

The loop only closes if it runs both ways: APS to MES is the schedule, MES to APS is what really happened. A daily file of confirmations is enough to plan tomorrow and not enough to re-plan this afternoon.

Ownership needs to be written down before go-live, because the arguments are predictable. Who may change a due date. Who maintains the changeover matrix and cycle times, on what review cycle. Who may override the sequence at the cell, and whether the override is recorded. Which system is authoritative when ERP and the scheduler disagree about what is on hand. Leaving these implicit is the usual reason a technically sound implementation stalls.

Running an evaluation that tells you something

A vendor demonstration on vendor data proves only that the software runs. Judge it on your plant instead; the exercise is cheap if you scope it.

Pick one area with real constraints — significant setups, shared tooling, competing orders — rather than the whole plant, and take a past period of four to eight weeks for which you know what was run and what was late. Give the candidate the master data you have today, not a version cleaned for the test, because the state of your data is one of the things you are measuring.

Then ask it to reproduce a schedule for that period and compare. Does the model represent your constraints, or does it need the awkward ones simplified away. Does it handle maximum waits as well as minimum ones, if your process has a shelf life or a pot life in it. How much changeover time does its sequence use against what you actually spent, and what does it say about the orders you delivered late. Then run the scenarios that matter: the bottleneck down for two days, an urgent order mid-week, a delivery a week late.

Then sit a planner in front of it for an afternoon. The question is not whether the engine is clever but whether a human can see why it made a decision and adjust it without fighting the tool; a scheduler nobody can argue with is a scheduler nobody will use. Ask what maintaining the model costs when a product, a machine or a setup time changes, and in how many places. Most schedules degrade not because the engine was wrong but because nobody owned the model after the project ended.

Where Meta Smart Factory fits

Meta Smart Factory's APS and MRP modules do the finite-capacity part of this, against a constraint model covering sequence-dependent setups, shared tooling, operator qualification and per-area shift calendars, with scenario runs for the disruptions above. Because they sit in the same platform as the MES module, there is no overnight file hand-off between execution and the scheduler, so floor state is as current as your confirmation points and your operators' reporting discipline make it. That is a condition, not a detail: if half the confirmations are entered at break and the manual assembly step has no scan point, the architecture does not rescue you. Deciding where those points sit is implementation work, not a by-product of it. The ERP seam for orders, bills of material and confirmations is part of the same job.

The parts that decide whether any of it works are not ours to supply: measured cycle times, a changeover matrix somebody owns, routings that match how the part is really made, and a written rescheduling policy. If you are early in this, the useful first step is not a demo but the historical comparison described above, on one constrained area, with your data as it stands.