Chapter 1 · Resources, calendars and rates
Finite capacity: a schedule that can be run
A schedule is a promise about what will run where and when. This chapter covers the master data that makes the promise honest: the resources, their open hours, what they can do and how fast, and the arithmetic that turns a quantity into minutes.
20 min6 resource types1 formulaWorked case: 96 units
By the end of this chapter you can
- Say what an advanced planning and scheduling (APS) module does and where it sits between planning and the floor.
- Describe a resource with its calendar, capabilities, rates and efficiency factor.
- Compute the run minutes of an operation and tell finite from infinite capacity scheduling.
What the module does
Production scheduling turns demand and released orders into a plan that says which operation runs on which machine, line, crew or tool, and when. Vendors call software that does this advanced planning and scheduling (APS) [1][2]. This module replaces the APS tools and scheduling boards a business pays for today, from dedicated products such as PlanetTogether, Siemens Opcenter APS (Preactor), Asprova and DELMIA Ortems to the Smartsheet, monday.com or Excel boards many planners fall back on, by building the same core on your own platform.
The standard that frames the job is ISA-95 Part 3 (IEC 62264-3), which describes the detailed production scheduling activity and its information flows between planning above it and execution on the floor below [3]. In this module's boundary, material requirements calculation belongs to the module that plans materials (M12), and recording what actually happened belongs to the execution module (M04). Scheduling sits between them: orders in, a feasible plan out, and the floor's actual times coming back.
Resources, calendars and rates
Everything the scheduler places work on is a resource. The module library uses six types, and a resource usually points at a piece of equipment already in the spine.
| Resource type | Typical example | What limits it |
|---|---|---|
| machine | A press, a mixer, a saw | Its open hours and its rate |
| line | A packing line treated as one unit | The slowest step on the line |
| labor_pool | Four welders on first shift | Heads available and skills |
| tool | A die, a fixture, a mould | Only one job can hold it at a time |
| vessel | A tank or kettle | Batch size and cleaning between batches |
| work_center | A group of similar machines | The group's combined hours |
Each resource has a calendar of shifts, and calendar exceptions that change it for a stretch of time: unavailable, planned maintenance and holiday take time away; overtime adds it. A resource also lists the capabilities it has (cut, mix, fill) with a rate per hour and a preference that says which resource to try first when several can do the same job. The efficiency factor scales the rate to what the resource really achieves: 0.8 means it delivers four fifths of its rated output. One resource can be marked a bottleneck, the one that limits what the whole area can make.
From quantity to minutes
The run time of an operation is the quantity divided by the effective rate, then turned into minutes. The seeded case used through this module has one machine with a rate of 60 an hour and an efficiency factor of 0.8, and four jobs of 96 units each.
Finite and infinite capacity
An infinite-capacity schedule places every order where its due date says and never checks whether the resource has room. Drawn as a Gantt chart (a bar chart with a row for each resource and time running left to right) it looks like a plan, but it can show two jobs on one machine at the same moment, or a day longer than the shift. A finite-capacity schedule never loads a resource beyond what its calendar holds [2][4]. When a job cannot fit, it says so and gives the reason, instead of drawing it anyway.
Scheduling can run two ways. Forward scheduling places each job as early as it can start, which answers "when can it finish?". Backward scheduling places each job as late as it can while still meeting the due date, which answers "when must it start?". When backward scheduling needs a start before the resource opens, the dates cannot all be met, and the job is marked infeasible.
You need: One week of your current schedule as the planners print or export it, and the shift times of one machine
Use a real week, and the machine the planner calls the busiest. Leave customer names out of anything you save.
Outcome: A short table of three machines with work minutes, open minutes, any overlap, and a verdict on whether your current schedule is finite.
Knowledge check
A machine has a rate of 50 units an hour and an efficiency factor of 0.8. How many minutes does an order of 200 units take?
Knowledge check
Which describes an infinite-capacity schedule?
References
- PlanetTogether: APS frequently asked questions. https://www.planettogether.com/faq
- SYMESTIC: what is an APS system. https://www.symestic.com/en-us/what-is/aps-system
- ISA: ISA-95 series of standards (enterprise-control system integration). https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
- Fabrico: what is advanced planning and scheduling (APS). https://www.fabrico.io/blog/what-is-advanced-planning-and-scheduling-aps/
Chapter 2 · Choosing the order
Sequence, setups and locked operations
Capacity says what fits. Sequence says in what order. This chapter covers dispatch rules, the setup matrix that makes the order matter, and the lock that keeps a planner's decision from being undone by the next run.
25 min4 dispatch rules1 setup matrix2 seeded cases
By the end of this chapter you can
- Apply earliest due date and shortest processing time to a small case and compare the lateness.
- Use a setup matrix to choose the order of jobs that minimises changeover time.
- Explain why locked operations must survive a re-run, and what the scheduler does when a lock cannot be honoured.
Dispatch rules
A dispatch rule is a sort order: when several jobs wait for one resource, which goes first? The production-planning body of knowledge the specification points to (the ASCM/APICS CPIM material) covers dispatching rules alongside lot sizing and capacity planning [5], and APS tools build their sequencing on rules like these [1]. The module implements four as sort keys.
| Rule | Short for | Which job goes first | Good at |
|---|---|---|---|
| EDD | earliest due date | The one due soonest | Keeping the worst lateness small |
| SPT | shortest processing time | The shortest job | Finishing the most jobs soonest |
| CR | critical ratio | Lowest of (time left to due date) ÷ (work left) | Showing which job is most at risk |
| FIFO | first in, first out | The earliest release date | Fairness and simplicity |
No rule wins every measure. Take one resource and three jobs (the seeded case has exactly one capable resource, so the scheduler has no other machine to choose and the results below hold), all released at 08:00: P takes 3 hours and is due at 11:00, Q takes 1 hour and is due at 12:00, R takes 2 hours and is due at 13:00.
Run backward on the same case and the plan needs P to start at 07:00, an hour before the shift opens. The scheduler must mark P infeasible and say why. It is better to tell the planner the dates cannot all be met than to draw the chart anyway.
Setups make the order matter
On many resources the time to change over depends on what ran before. A paint line moving from light to dark loses little; dark to light needs a long clean. The module stores this in a setup matrix: for a resource and an attribute of the product (the seeded case uses a family, A or B), the minutes to change from one value to another, and optionally a cost. The first job on a resource needs no setup. The setup minutes are written on the operation when it is placed, so changing the matrix later never rewrites a published schedule.
Seed 1 has four jobs of 96 units on one machine (again the only capable resource), 120 minutes each, in a shift from 08:00 to 17:00. J1 and J3 are family A; J2 and J4 are family B. Run in the order they arrive, the machine changes over three times.
The sequencer tries each job as the first, builds the rest by always taking the job with the smallest setup from the one just placed (ties go to the earlier due date, then the lower job number), and keeps the order with the smallest total setup. If two starting jobs give the same total setup, it keeps the one with the lower job number: starting from J1 or J3 both give 30 minutes in Seed 1, so J1 wins. Then it records the result as scenario KPIs: total setup hours (0.5), makespan (8.5 hours, from the start of the first job to the end of the last), on-time share and utilisation.
Locked operations
Planners override the machine: a customer is waiting, a tool is only free at 10:00, a supervisor has promised a crew. If the next run of the scheduler moves those operations, the planner's work is lost and trust goes with it. An operation marked locked keeps its resource and times in every re-run. Everything else is planned around it. A lock that falls in a closed period, or overlaps another lock, is refused with the reason.
Two further properties matter. The scheduler must be deterministic: the same input gives the same plan, so that a difference between two runs always has a cause. And when the cases get hard, a constraint-programming solver (a program that searches for the best plan among all the plans that satisfy your rules) can be added as an option; OR-Tools CP-SAT, named in the specification, is a free, open-source one. Rules stay the default because they are fast and easy to explain. If the bottleneck is known, the Theory of Constraints option (drum-buffer-rope) schedules around it first and lets the rest follow.
You need: Paper or a spreadsheet; this chapter's seeded cases
Do this before your agent writes a scheduler. Your predictions become the tests it must pass.
Outcome: A one-page prediction sheet with the run minutes, both Seed 1 orders with their setup and end times, the A-to-B-90 result, and Seed 2 under EDD, SPT and with Q locked.
Knowledge check
On one resource, job X takes 4 hours and is due in 10 hours; job Y takes 1 hour and is due in 2 hours. Which goes first under EDD, and which under SPT?
Knowledge check
Why is the setup time stored on the operation when it is placed?
Knowledge check
A planner locks an operation, then the scheduler is run again. What must happen?
References
- Fabrico: what is advanced planning and scheduling (APS). https://www.fabrico.io/blog/what-is-advanced-planning-and-scheduling-aps/
- PlanetTogether: APS frequently asked questions. https://www.planettogether.com/faq
- SYMESTIC: what is an APS system. https://www.symestic.com/en-us/what-is/aps-system
- ISA: ISA-95 series of standards (enterprise-control system integration). https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
- ASCM: APICS CPIM, Certified in Planning and Inventory Management. https://www.ascm.org/learning-development/certifications-credentials/cpim/
Chapter 3 · From draft to dispatch
Scenarios, publishing and the data
A planner needs to ask "what if?" without touching the plan the floor is running. This chapter covers scenarios, the publish step that hands a plan to the floor, the eleven tables behind it, and the events that connect it to other modules.
20 min11 aps_ tables1 published at a time2 events published
By the end of this chapter you can
- Copy a scenario, change an input and compare the six scenario KPIs side by side.
- Say what publishing does in one transaction and why a published scenario cannot change.
- Name the module's tables, their groups and the spine tables they point at.
Scenarios
A scenario is a version of the schedule with its own horizon, jobs, constraints, objective weights and solver. Its status is draft, published or archived. APS tools commonly let planners compare what-if scenarios [1][2]. The planner copies a scenario to try a change (a different rule, an extra shift, a rush order), re-runs it, and compares. The copy records where it came from in created_from_id, and the original is not touched.
Compare shows six values per scenario, stored as scenario KPIs: on-time percentage, total lateness in hours, total setup in hours, utilisation percentage, makespan in hours and work in progress count. The scenario's objective weights say how much each of lateness, setup and utilisation counts when the sequencer chooses between plans.
Publishing
Publishing makes one scenario the plan the floor works to. It happens in a single transaction so that nothing is half done: the route first refuses a scenario with any resource loaded beyond capacity, then sets the status to published with the time and the person, archives the previously published scenario, writes the status history, and leaves two kinds of event in the outbox (the spine table where a module leaves events for other modules to pick up): aps.scenario.published, and one aps.job.late_predicted for each late job.
A published scenario is read-only. The database refuses any change to its jobs, operations, constraints or KPIs, and allows only one published scenario at a time. To change the plan, copy it, change the copy and publish that: the old plan stays on record. The operator's dispatch list is then simply the published scenario's operations for their area in start order, shown as one card each with the item, quantity, resource, planned start and end and any setup.
The data model
The module adds eleven tables with the prefix aps_, each with the standard columns every spine table has (id, tenant_id, created_at, created_by, updated_at, updated_by, row_version, archived_at, ext). It points at the spine for equipment, calendars, items, people and reason codes, and never keeps its own copy.
| Table | Holds | Points at |
|---|---|---|
| aps_resource | Schedulable resource, capacity, efficiency factor, bottleneck flag | core_equipment, core_calendar |
| aps_capability, aps_resource_capability | What operations require; what a resource can do, at what rate | each other |
| aps_calendar_exception | Downtime, extra shifts, holidays per resource | aps_resource |
| aps_setup_matrix | Changeover minutes (and cost) between attribute values | aps_resource |
| aps_scenario | A draft, published or archived version of the schedule | itself (created_from_id), core_person |
| aps_job, aps_scheduled_operation | Orders to schedule; operations placed on a resource with times and a lock | aps_scenario, core_item, aps_resource |
| aps_constraint | Material, labor skill, tool, max wait, precedence, batch or custom limits | aps_scenario |
| aps_scenario_kpi | The six comparison values per scenario | aps_scenario |
| aps_adherence | Actual start and end against plan, with a reason code | aps_scheduled_operation, core_reason_code |
The database does the checking it can. Allowed values (a resource type, a job status, a constraint type) are check constraints; codes are unique per business; an exception cannot end before it starts. PostgreSQL's constraints and row-level security do this work for you.
You need: A SQL console on your branch database, the eleven aps_ tables, and the specification's column list
Use a local or branch database, never the live one. Your agent can write the statements; you read what they return.
Outcome: A short list of schema differences (ideally none) and four refusals you saw the database make.
Knowledge check
What does publishing a scenario do in the same transaction?
Knowledge check
A planner wants to see what an extra Saturday shift would do without touching the running plan. What should they do?
References
- PlanetTogether: APS frequently asked questions. https://www.planettogether.com/faq
- FitGap: PlanetTogether overview. https://us.fitgap.com/products/011934/planettogether
Chapter 4 · Keeping the promise honest
Measured capacity, adherence and KPIs
A schedule is only as good as the capacity data under it. This chapter covers measured performance against nameplate, the adherence loop that brings the floor's actual times back, the KPIs that show whether the schedule works, and what to bring across from an old tool.
20 min4 KPIsOEE-fed factors3 pitfalls
By the end of this chapter you can
- Explain why efficiency factors must come from measured OEE, not nameplate.
- Define schedule adherence, planned on-time delivery, changeover hours and bottleneck utilisation.
- Describe the adherence loop and name the three pitfalls the module is built to avoid.
Garbage capacity data, broken promises
Scheduling has no regulation of its own. The risk is credibility: if the capacity data is wrong, the schedule promises dates that cannot be kept, and the floor and the customers learn to ignore it. The main cause is scheduling on the rate printed on the machine's plate instead of the rate it achieves.
Overall equipment effectiveness (OEE) is availability (run time divided by planned production time) times performance (actual output rate divided by ideal rate) times quality (good units divided by all units), one of the KPIs ISO 22400-2 defines [1]. In this module the efficiency_factor on a resource is fed from measured OEE over the same planned time the calendar models. Planned maintenance is already an exception on the calendar, so it must not be counted twice. The factor records where it came from (the source, the period and the date) in the resource's ext field. If it has not been measured, say so and treat the resource as a known risk; do not guess.
The four schedule KPIs
ISO 22400-2 defines key performance indicators for manufacturing operations management, including schedule-related ones such as allocation and utilisation [1]. The module reports four every week and compares them between the old plan and the new.
| KPI | Definition | Read it as |
|---|---|---|
| Schedule adherence | Operations started within tolerance ÷ operations scheduled | Is the floor running the plan? |
| On-time delivery (planned) | Jobs finishing on or before due ÷ jobs | Does the plan meet its dates? |
| Changeover hours | Sum of setup time per period and resource | Is the sequence saving time? |
| Bottleneck utilisation | Load ÷ available time on constraint resources | Where is the limit, and is it over 100 percent? |
Decide the tolerance in minutes that counts a start as on time before you collect any numbers, and write it down. Otherwise it will be chosen afterwards to make the result look right.
The adherence loop
When the schedule is published, each operator sees the operations for their area on a phone. Start and Finish are two large buttons; each tap records the time on the phone and is sent with a row id made on the phone. Start inserts the adherence row with that id and Finish updates the same row, so a repeated Start adds nothing and a repeated Finish returns success without a second write (the tap is idempotent: sending it twice has the same effect as once). The server, not the phone, computes how many minutes the start deviated from the plan. A supervisor gives a reason code to each start that missed the tolerance. If an execution module is installed, its completed-run events can feed the same table.
Where a resource consistently starts or finishes later than planned, compare its measured output with the factor you set, update the factor with a new source and period, and run again. A factor never changes without a recorded measurement.
Three pitfalls, and bringing data across
- Infinite capacity disguised as a Gantt chart: test it by finding an overload; a property-based test (hundreds of random cases checked against one rule) should find none.
- Nameplate instead of measured rates: check that every bottleneck resource has a measured source recorded.
- No locked operations: planner overrides vanish at the next run, so test that locked operations keep their place.
Incumbent tools rarely hold history worth migrating beyond adherence data. Bring over resources, routings and open orders from your ERP or MRP export, keep the old export as a record, and compare against it for a full week before you switch. Check the old tool's cancellation terms from your own account page, and cancel only after the cutover works and the export is safe.
You need: Planned time, run time, total count and good count for one bottleneck resource over a week, from your counters or a hand tally
Pick the resource that limits your area. If you have an execution system, take the figures from it; if not, a tally kept by the operator for one week is enough.
Outcome: One efficiency factor from measured data, its source recorded, and the minutes of difference it makes to a typical order.
Knowledge check
Why must the efficiency factor on a bottleneck resource come from measured OEE?
Knowledge check
A week's data: 80 operations scheduled, 68 started within the tolerance. What is schedule adherence?
References
- ISO 22400-2:2014, Key performance indicators for manufacturing operations management: definitions and descriptions. https://www.iso.org/standard/54497.html
- SYMESTIC: what is an APS system. https://www.symestic.com/en-us/what-is/aps-system
- ISA: ISA-95 series of standards (enterprise-control system integration). https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
Chapter 5 · 12 questions · 80% passes
Final assessment
Twelve questions across the element. Score 80% (10 of 12) to pass. Your LMS records your score and each answer; you can review the chapters and try again.
15 min12 questions≈ 15 minutesRetake allowed
Your result
CivOps AI Academy
Scheduling and Dispatch: Finite-Capacity Scheduling on Your Own Platform
Element M03 complete · Learner
Your LMS records this completion. For the CivOps Foundation certificate, finish the Foundation Course at https://civops.io/learn.