Skip to the lesson
CivOps AI Academy · M03Scheduling and Dispatch: Finite-Capacity Scheduling on Your Own Platform
0%

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 typeTypical exampleWhat limits it
machineA press, a mixer, a sawIts open hours and its rate
lineA packing line treated as one unitThe slowest step on the line
labor_poolFour welders on first shiftHeads available and skills
toolA die, a fixture, a mouldOnly one job can hold it at a time
vesselA tank or kettleBatch size and cleaning between batches
work_centerA group of similar machinesThe 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.

Run minutes of an operationFour boxes: 96 units, an effective rate of 48 an hour from a rate of 60 and an efficiency factor of 0.8, 2 hours, and 120 run minutes. Quantity96 unitsEffective rate60 × 0.8 = 48 an hourHours96 ÷ 48 = 2 hoursRun minutes2 × 60 = 120Quantity ÷ (rate per hour × efficiency factor) × 60 = run minutesOn the nameplate rate alone the same job looks like 96 minutes: 24 minutes of promise the machine cannot keep.
Run minutes on the seeded case. 96 units at an effective 48 an hour take 2 hours, which is 120 minutes. The nameplate rate alone would say 96.

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.

Infinite and finite capacityTwo timelines from 08:00 to 18:00. The first lets job B overlap job A on one machine. The second places jobs A, B and C one after another before the shift ends at 17:00 and marks job D late. 08:0009:0010:0011:0012:0013:0014:0015:0016:0017:0018:00Infinite capacity: the chart only drawslane 1Job Alane 2Job B, same machineFinite capacity: one machine, one job at a time, inside its open hoursMachineJob AJob BJob Cshift ends 17:00Job D does not fit: marked late, with the reason
The same machine, two ways. Above, the chart lets job B overlap job A. Below, jobs run one at a time inside the open hours, and the job that does not fit is marked late with the reason.

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.

Exercise · Run the infinite-capacity test on your own schedule20 minutes

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

  1. PlanetTogether: APS frequently asked questions. https://www.planettogether.com/faq
  2. SYMESTIC: what is an APS system. https://www.symestic.com/en-us/what-is/aps-system
  3. ISA: ISA-95 series of standards (enterprise-control system integration). https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
  4. 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.

RuleShort forWhich job goes firstGood at
EDDearliest due dateThe one due soonestKeeping the worst lateness small
SPTshortest processing timeThe shortest jobFinishing the most jobs soonest
CRcritical ratioLowest of (time left to due date) ÷ (work left)Showing which job is most at risk
FIFOfirst in, first outThe earliest release dateFairness 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.

Dispatch rules on the seeded caseTwo timelines from 08:00 to 14:00. Earliest due date runs P, Q, R and R is one hour late. Shortest processing time runs Q, R, P and P is three hours late. 08:0009:0010:0011:0012:0013:0014:00EDDPQREarliest due date first: R ends 14:00, due 13:00. Total lateness 1 hour.SPTQRPShortest processing time first: P ends 14:00, due 11:00. Total lateness 3 hours.Due times: P 11:00, Q 12:00, R 13:00. Both rules finish at 14:00 and have two of three jobs on time.
Two rules on the same three jobs, drawn to scale. Both finish at 14:00 and both get two jobs on time, but EDD is 1 hour late in total and SPT is 3 hours late.

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.

The setup matrixTwo small tables of changeover minutes between product family A and family B. Seed 1 has A to B 30 and B to A 60. In the test A to B is changed to 90. Seed 1 (aps_setup_matrix, attribute family)to Ato Bfrom A0 min30 minfrom B60 min0 minThe test: A to B becomes 90to Ato Bfrom A0 min90 minfrom B60 min0 minSetup depends on the pair: going A to B costs a different time from going B to A.
The setup matrix for the seeded case. A to B costs 30 minutes and B to A costs 60. In the test later in this chapter, A to B is changed to 90.

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.

Same four jobs, two ordersTwo timelines from 08:00 to 18:00. Running families A, B, A, B needs 120 minutes of setup and ends at 18:00, after the shift closes. Running A, A, B, B needs 30 minutes of setup and ends at 16:30. 08:0009:0010:0011:0012:0013:0014:0015:0016:0017:0018:00Order J1, J2, J3, J4 (families A, B, A, B)J1 A30J2 B60 minJ3 A30J4 BSetup 30 + 60 + 30 = 120 minutes. J4 ends 18:00, an hour after the shift closes.Order J1, J3, J2, J4 (families A, A, B, B)J1 AJ3 A30J2 BJ4 BSetup 30 minutes. The last job ends 16:30, inside the shift.shift ends 17:00
Same jobs, different order, drawn to scale. Alternating families costs 120 minutes of setup and runs an hour past the end of the shift. Grouping them costs 30 minutes and finishes at 16:30.

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.

A locked operationTwo timelines from 08:00 to 14:00. Without a lock EDD runs P, Q, R. With Q locked from 10:00 to 11:00, R runs first from 08:00 to 10:00 and P runs from 11:00 to 14:00. 08:0009:0010:0011:0012:0013:0014:00No lockPQRQ lockedRQ lockedPEDD alone: R is one hour late.Q is pinned at 10:00 to 11:00. R takes the gap before it; P does not fit there and ends 14:00, three hours late.Run it again on the same input: the same plan, with Q where the planner put it.
Q is locked at 10:00 to 11:00. R fills the gap before it, P no longer fits ahead of Q and ends at 14:00, three hours late. Running again gives the same plan.

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.

Exercise · Predict the seeded cases before any code25 minutes

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

  1. Fabrico: what is advanced planning and scheduling (APS). https://www.fabrico.io/blog/what-is-advanced-planning-and-scheduling-aps/
  2. PlanetTogether: APS frequently asked questions. https://www.planettogether.com/faq
  3. SYMESTIC: what is an APS system. https://www.symestic.com/en-us/what-is/aps-system
  4. ISA: ISA-95 series of standards (enterprise-control system integration). https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
  5. 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.

Scenario to dispatchFour steps: a draft scenario, a copy, a compare of KPIs and publish. Publishing archives the old plan, writes events to the outbox and makes the dispatch list appear. Draft scenarioinputs and a ruleCopycreated_from_id setComparesix KPIs side by sidePublishone transactionOld plan archivedonly one published at a timeEvents in the outboxaps.scenario.publishedaps.job.late_predictedDispatch listoperators see their areaA published scenario is read-only: change it by copying it.
From draft to dispatch. Copy to try, compare to decide, publish to hand over. Only one scenario is published at a time, and the old one is archived in the same step.

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.

The module's tablesEleven aps_ tables in three groups: master data (resource, capability, resource capability, calendar exception, setup matrix), scenario (scenario, job, scheduled operation, constraint, KPI) and feedback (adherence). Below them are the spine tables they point at. Master dataaps_resourceaps_capabilityaps_resource_capabilityaps_calendar_exceptionaps_setup_matrixScenarioaps_scenarioaps_jobaps_scheduled_operationaps_constraintaps_scenario_kpiFeedbackaps_adherenceSpine tables the module points at, never recreatescore_equipmentcore_calendarcore_itemcore_personcore_reason_code
Eleven tables in three groups. Master data describes what can be scheduled, the scenario group holds the plans, and adherence records what happened. The spine tables at the bottom are shared with every module.
TableHoldsPoints at
aps_resourceSchedulable resource, capacity, efficiency factor, bottleneck flagcore_equipment, core_calendar
aps_capability, aps_resource_capabilityWhat operations require; what a resource can do, at what rateeach other
aps_calendar_exceptionDowntime, extra shifts, holidays per resourceaps_resource
aps_setup_matrixChangeover minutes (and cost) between attribute valuesaps_resource
aps_scenarioA draft, published or archived version of the scheduleitself (created_from_id), core_person
aps_job, aps_scheduled_operationOrders to schedule; operations placed on a resource with times and a lockaps_scenario, core_item, aps_resource
aps_constraintMaterial, labor skill, tool, max wait, precedence, batch or custom limitsaps_scenario
aps_scenario_kpiThe six comparison values per scenarioaps_scenario
aps_adherenceActual start and end against plan, with a reason codeaps_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.

Exercise · Check your tables against the specification20 minutes

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

  1. PlanetTogether: APS frequently asked questions. https://www.planettogether.com/faq
  2. 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.

Nameplate and measured ratesTwo pairs of bars to scale. A nameplate rate of 60 an hour against a measured 48 an hour, and 96 minutes for 96 units on the nameplate against 120 minutes in practice. Rate (units an hour)Nameplate60Measured: 60 × 0.848Time for 96 units (minutes)Scheduled on nameplate96What the machine takes120The 24-minute gap is a promise the schedule cannot keep.
The same order, two answers, drawn to scale. On the nameplate rate 96 units take 96 minutes. At the measured 80 percent they take 120.

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.

KPIDefinitionRead it as
Schedule adherenceOperations started within tolerance ÷ operations scheduledIs the floor running the plan?
On-time delivery (planned)Jobs finishing on or before due ÷ jobsDoes the plan meet its dates?
Changeover hoursSum of setup time per period and resourceIs the sequence saving time?
Bottleneck utilisationLoad ÷ available time on constraint resourcesWhere 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.

The adherence loopSix boxes in a loop: the published schedule, the dispatch list, start and finish taps, adherence rows, reasons and measured rates, and capacity updated for the next schedule. Published scheduleaps_scenarioDispatch listone card per operationStart and Finish tapson the operator's phoneCapacity updatedefficiency_factor, with sourceReasons and ratesreason codes, measured outputaps_adherence rowsactual times, deviationThe next run of the scheduler uses what the floor really did, not what the nameplate says.
The loop. What the floor does is recorded, explained with reason codes, compared with the measured output, and used to correct the efficiency factor for the next run.

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.

Exercise · Replace one nameplate rate with a measured one25 minutes

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

  1. ISO 22400-2:2014, Key performance indicators for manufacturing operations management: definitions and descriptions. https://www.iso.org/standard/54497.html
  2. SYMESTIC: what is an APS system. https://www.symestic.com/en-us/what-is/aps-system
  3. 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

Choose one answer for each question, then submit. You will see the right answer and why for every question.

1. What does a finite-capacity scheduler never do?
2. A machine has a rate of 60 units an hour and an efficiency factor of 0.8. How long does an order of 96 units take?
3. Which source should the efficiency factor of a bottleneck resource come from?
4. Backward scheduling answers which question?
5. Three jobs wait for one machine: P takes 3 hours (due 11:00), Q takes 1 hour (due 12:00), R takes 2 hours (due 13:00), all released at 08:00. Under EDD, when does R finish and how late is it?
6. On the same three jobs, why does SPT give a worse total lateness than EDD?
7. Why does a setup matrix store minutes for a pair of values rather than one number per product?
8. Seed 1 has four 120-minute jobs (A, B, A, B), A to B 30 minutes and B to A 60, in a shift from 08:00 to 17:00. What does running them in the order A, B, A, B do?
9. Why must a locked operation keep its place when the scheduler is re-run?
10. What is the rule for a published scenario?
11. Operators press Start and Finish on a phone with no signal, and the app sends the same tap twice. What is the result?
12. 80 operations were scheduled and 68 started within the tolerance. Which KPI is 85 percent?