Schedule Maintenance (generic process)

Schedule Maintenance (generic process) is the generic process card, GP-202, for the process that keeps a published schedule current between its publication and the operating day: receiving time-off requests, shift swaps, planned overtime and voluntary time off, and one-off exceptions; testing each against coverage, fairness and the rule set; approving or declining it; and writing every approved change as a new version of the schedule of record. The method is documented in full on Schedule Maintenance, which carries the five event types, the lead-time boundary that separates maintenance from intraday adjustment, the coverage-impact test and the version-control discipline, and it is not restated here. This card carries what a function needs in addition to the method in order to catalog, localize, certify and automate the process: its L0 profile, its known variant classes, the L3 job aids a localizing team must write, and the sub-steps flagged as automation candidates. It is part of Process Standardization and sits under the scheduling section of the function catalog in Anatomy of a ROC Standard.

The process is typically the highest-volume one in the scheduling pillar by event count [A] and the one most often run by hand, which is why its candidates are among the first a standards committee releases. It is also where two Level 2 failures that the method page names occur: approving a change without a coverage test, and measuring adherence against the schedule as first published rather than the version active.

Process profile

The profile extends the L0 identity fields of Process Decomposition (L0–L3) with the process-level facts a standards committee needs before any step is drawn. Local values are held by the deploying function and marked SET LOCALLY.

Field	Generic value
Card	GP-202 · local card id assigned by the standards committee at deployment
Class	strategic, in the catalog's four-class vocabulary (strategic · real-time · both · supporting): a planned process with lead time; a request inside the lead-time boundary is not this process but GP-302's
Trigger	the handover of the version active at the close of the exception window of GP-201; then each event as it arrives, until the lead-time boundary passes it to GP-302
Cadence	continuous within the period; a daily maintenance pass is typical [A]; the lead-time boundary is a parameter (the method page's rule of thumb is one day, SET LOCALLY)
Scope in	the five event types: time-off requests against the allotment, swaps, planned overtime offers, voluntary time off offers, exceptions; the coverage-impact test; approval; the version write; the fairness queues; the maintenance log
Scope out	the build and publication (GP-201); the allotment the time-off requests draw on (GP-203); self-scheduled claims and the open-shift pool (GP-204); same-day change (Real-Time Schedule Adjustment and GP-302); the adherence measurement itself (Adherence and Conformance)
Inputs	the active schedule version; the requirement and the reforecast for the period; the time-off allotment and balances; the fairness queues; the rule set in force; the event requests
Outputs	an approval or decline with reason per event; a new schedule version per approved change; the maintenance log by event type; the fairness-queue state; the handover to the real-time function at the boundary
Upstream	GP-201; GP-203; GP-103 for the coverage test's demand side; the HR partner for balances and protected leave
Downstream	GP-303, which reads the version active; GP-302 at the boundary; payroll for approved overtime; GP-602, which reads the log as a signal of build quality
Resources	a scheduling system with version history; a request portal; the allotment and balance ledger; the fairness queues; the rule register. Platforms are named at L3, never here
Decision points	does the change pass the coverage test at the standard the function sets; is it within the allotment and the balance; is it within the rule set; who is next in the fairness queue; is a request inside the boundary (then it is not this process)
Authority tier	approvals inside the rule set and the allotment at tier 1 (the scheduler seat inside guardrails); a change that breaches the coverage band or exceeds the allotment at tier 2; planned overtime that binds cost, and any mandatory overtime, at tier 3; a change to the rule set itself at tier 4 through GP-601
Risk and compliance flags	protected leave is a legal determination, never a capacity decision; a swap must leave rest, maximum-hours and skill rules satisfied; overtime offered out of the contractual order is a grievance; a change inside a notice period may carry a premium; adherence measured against a stale version is a false number
Variant-prone steps	the approval tier for each event type; the order of the overtime and voluntary-time-off queues; the swap restrictions; the lead-time boundary; the response-time commitment
Automation candidates	six L2 sub-steps (listed below)

L1 and L2

The L1 event cycle and the L2 decomposition of each event type are on Schedule Maintenance, and a deploying function copies both into its own artifacts through Wiki:Packs/Process Decomposition, filling the columns the method page leaves open (the owning seat per event type, the ticketing code, the coverage standard, the approver, the response-time commitment) and never leaving the lead-time-boundary row blank, because that row is the line between this card and GP-302.

Variants

The known variant classes for this process, recorded per Standard and Variant in Process Documentation:

• Statutory. Rest, maximum-hours and break rules are parameters of the rule-set test and take no row. A change premium inside a notice period is a parameter of the approval step, SET LOCALLY. Protected leave is handled by the generic exception path and takes no row; the determination belongs to the HR partner. A jurisdiction whose works council co-determines temporary changes to customary working hours, overtime among them, inserts a consultation step before any planned overtime is offered; the works-council liaison owns it, the function head approves the variant, and it takes a row.
• Contractual. A collective agreement that fixes the overtime order (equalization, seniority or inverse seniority) and the swap restrictions (same classification, no resulting overtime) parameterizes the queue and the swap test; no row. A client contract that forbids voluntary time off on dedicated staff is a constraint-register entry, SET LOCALLY.
• Structural. A unit whose scheduling system holds no version history writes versions to a dated export; the version step is varied with a review date at each cycle until a system with history exists. A back-office channel with a daily rather than an interval requirement runs the coverage test at the day level; a parameter, no row.
• Transitional. A unit migrating from a predecessor organization that still approves requests by email keeps its path under a row with an expiry at the portal cut-over, and an automation effect of blocks against the first three candidates below until then.

L3 register

A localizing team writes these job aids against the method page's L2; names only, the content is the function's. The coverage standard the test is run at, the lead-time boundary and the response-time commitment are L3 values, SET LOCALLY, and each decline reason is an L2 row of its own.

Job aid	Anchored to	Form
The event-type register: definitions, approver tier, response-time commitment	all event types	work instruction
The lead-time boundary and the handover to the real-time function	classification step	work instruction; see Real-Time Schedule Adjustment
The coverage-impact test: standard, inputs, pass band	coverage test	work instruction; demand side on Reforecast and Rolling Forecast Methodology
The time-off request path against the allotment and the balance	time-off events	work instruction; allotment on GP-203
The swap verification checklist: skill, rest, hours, coverage, contractual order	swap events	work instruction
The planned overtime and voluntary-time-off offer procedures and their queues	overtime and VTO events	playbook; method on Overtime and Voluntary Time Off (VTO) Management
The exception path for protected leave and hardship	exception events	runbook
The version write and the maintenance log layout	every approved change	work instruction; see Adherence and Conformance
The weekly read of the log as a build-quality signal	log review	playbook; feeds GP-602

Automation candidates

Flagged at L2 per the method on Process Decomposition (L0–L3); released per class of action on a published catch rate per Human Gates and Number Grades, never on a maturity label.

1. The coverage-impact test: computed on every request before a human sees it, so that the Level 2 failure of approval without analysis cannot occur; the first candidate because it is arithmetic on the active version and the reforecast, every other candidate depends on it, and its catch rate is the easiest to publish.
2. Swap approval within the rule set: a swap whose skill, rest, hours and coverage tests all pass is approved without a human read. It ranks after the test because it adds the rule set to the arithmetic, and the catch rate is published from the declined-then-overturned cases, which take a cycle to accumulate.
3. Time-off auto-approval within the allotment: a request inside the allotment, the balance and the notice horizon is approved on receipt; a request outside any of them is routed, not declined. It ranks after swap approval because it reads the balance ledger, a second system of record, so its catch rate needs a ledger reconciliation sample first.
4. Overtime and voluntary-time-off offers: the gap is computed from the schedule and the reforecast, the offer is distributed in the queue order the rule set fixes, and acceptances are written to the version; the decision to open an offer stays with tier 3 until the proposal's catch rate is published. It ranks after the approvals because an error in queue order is a grievance, which is counted outside the function and later.
5. The version write and the log entry: mechanical once a change is approved. It ranks fifth not for difficulty but because its catch rate can only be published once the approvals above produce the changes it writes.
6. The weekly log summary by event type: assembled for GP-602, not decided. It ranks last because its errors are errors of classification, caught only when the review reads the log.

Mandatory overtime is never a candidate: it compels a person and, in a unionized unit, follows the procedure the agreement fixes, as Union Environments and WFM describes. The protected-leave determination is never a candidate: it is a legal finding about an individual. Nor is a decline of a request that passes every test: the only remaining ground is judgement, a tier-2 act with a stated reason.

Maturity Model Position

Four scales on this wiki use the word level; the launch page states which is which. On the WFM Labs Maturity Model™, as Schedule Maintenance positions it, a function whose maintenance is handled by hand or by email, with no coverage test on a request and no version control, is at Level 2; one with the coverage-impact test on every request, a version per change and fairness queues is at Level 3, and has the coverage-impact test (candidate 1) in place whether or not released on a published catch rate; one whose maintenance is automated for most event types and pool-aware, with the offers agent-proposed within the queue order and the maintenance data feeding the next build, is at Level 4.

See Also

• Process Standardization — the hub and the inventory this card belongs to
• Schedule Maintenance — the method: event types, the lead-time boundary, version control
• Schedule Build and Publish (generic process) — the card that hands the schedule to this one at window close
• Time-Off Allotment Planning (generic process) — the allotment the time-off path draws on
• Overtime and Voluntary Time Off (VTO) Management — the offer mechanics
• Real-Time Schedule Adjustment — the process on the other side of the boundary
• Adherence and Conformance — why the version active is the measurement reference
• Union Environments and WFM — the contractual queue orders and swap restrictions
• Standard and Variant in Process Documentation — how the variants above are recorded
• Wiki:Packs/Process Decomposition — the pack that localizes this card (CP-OPS-001)