Standards Governance and Change Control (generic process)

From WFM Labs

Standards Governance and Change Control (generic process) is the generic process card, GP-601, for the recurring sitting by which a workforce function's standards committee governs the function's standard: tables the requests received since the last sitting, re-ranks the queue, sits the acceptance gate on the packages docketed for it, baselines what was approved and records the change, reads the sweep list of packages approaching or past expiry, and publishes the compliance report. The seven steps one package passes through are documented on Process Standardization Lifecycle and are cited here by their step IDs, never narrated; this card documents the sitting that runs that lifecycle for every package in the function catalog, so that the function has one holder of its standard and one record of what changed. It is part of Process Standardization, sits among the cross-cutting sections of the function catalog in Anatomy of a ROC Standard, and gives the governance structures on Workforce Management Governance and Change Management a process with owners, steps and a record.

The organizing idea is service management's: a change is controlled when one authority holds the baseline, every change is assessed, authorized and recorded, and the authority is a role rather than a person.[1] Here the authority is the change-control board, the standards committee sitting in that capacity, and the baseline is the function's standard with its catalog of packages. A standard with two holders has none; a single process owner is the precondition for a standard that holds across units.[2]

Process profile

The profile extends the L0 identity fields of Process Decomposition (L0–L3). Local values are held by the deploying function and marked SET LOCALLY. Authority tiers follow the cross-cutting row of Decision Authority Tiers in Workforce Operations.

Field Generic value
Card GP-601 · local card id assigned by the standards committee at deployment
Class supporting, in the catalog's four-class vocabulary (strategic · real-time · both · supporting): it serves every other process and changes none of their outputs directly
Trigger the sitting calendar; between sittings, a process-standard request through the single intake door (Enterprise Interconnection Plan), an expired package, or an odd case returned from lifecycle step 3.1
Cadence the board sits on a fixed calendar (SET LOCALLY; fortnightly while the first wave of packages is authored and monthly thereafter is typical [A]); the sweep runs on the standard's validation cadence, annually against the expiry
Scope in every package in the function catalog; requests classed new or modify; the queue and the deferred log; gate sittings; baselines and versions; variant admissions; the sweep
Scope out authoring and peer review (lifecycle steps 1.2 and 1.3, the process owner's); the content of any process; certification of the function at a conformance level, which the standard's validation clause assigns to the methodology steward; improvement of the work itself (Lean and Continuous Improvement Applied to WFM Processes); the definitions register's own change control (The Definitions Register)
Inputs the intake batch, each request with its six fields; the catalog with wave ranks and expiry dates; the gate checklist; the odd-case log and catch rate from lifecycle step 3.1; the variant register
Outputs the ranked queue; the gate response per package (approved · conditionally approved · not approved); the baselined version and its change record; the sweep list; the compliance report; the deferred log
Upstream the intake door; process owners (odd cases); the overseer (catch rates); the legal partner and the works-council liaison (statutory change); the placement function (a new supply node, that is a site, centre or partner, whose package must be localized)
Downstream the training lead (people track); the automation analyst (machine track); the function catalog and the pillar packs; every card's local copy; the executive issue register, by exception
Resources a catalog and queue register; a document repository with versions; the gate checklist; the board calendar; a change record. Platforms are named at L3, never here
Decision points which requests enter the queue; which are minor modifies; the re-rank; the gate response; go or no-go at deployment; certify or remediate at the sweep
Authority tier a minor modify to an L2 or L3 at tier 2 (the process owner); admitting a major change request to the queue at tier 3 (the standardization lead chairing the board); a version of the standard, which is what the gate issues, at tier 4 (the function head for a new package; the approvers named on the L0 for a modify); closure of a compliance finding at tier 4; a change to the standard's scope to the executive sponsor, by exception
Risk and compliance flags two copies of one process in circulation; an expired package still cited as the standard; a machine-track build on an L2 that has not passed the gate; a variant admitted on preference; the seat that led a migration certifying the standard it is measured against
Variant-prone steps the gate docket where a works council must see a change to working-time rules; the deployment calendar at a partner supply node; the sweep cadence where a client contract prescribes its own audit cycle
Automation candidates six L2 sub-steps (listed below)

L1 flow

The L1 is the sitting's agenda. Owner seats in parentheses, one per step. Decisions are questions.

  1. Table the intake batch: every request logged through the intake door since the last sitting, with its six fields (standardization lead).
  2. Screen and class the batch (lifecycle step 1.1): which requests enter the queue, which go to the deferred log with a review date, and which are minor modifies? (standards committee)
  3. Route each minor modify to its process owner for the light edit at tier 2, straight to the sweep (standards committee).
  4. Re-rank the queue: does the batch change the wave order, under the one constraint the function's leadership fixed, that the processes an agent team will run first stay in the first wave? (standards committee)
  5. Name the process owner and two peer reviewers, as seats, for each package newly queued (standards committee).
  6. Take the status report on packages in authoring and peer review (lifecycle steps 1.2 and 1.3) and record it on each L0 card (standardization lead).
  7. Sit the acceptance gate (lifecycle step 2.1) on the docket: is each package approved, conditionally approved or not approved? (approvers named on the L0)
  8. Baseline each approved package and write its change record (standardization lead).
  9. Hand each baseline to the two deployment tracks (lifecycle step 2.2) and set its go/no-go date (process owner).
  10. Table the odd cases and catch rates returned from lifecycle step 3.1: does any require a modify request into the next intake batch? (process owner)
  11. Take the sweep list: which packages expire inside the next cycle, and which have expired? (methodology steward)
  12. Check each flagged package for conformance (lifecycle step 3.2) against the conformance ladder the standard's scope clause names, which is the standard's own scale and not this card's maturity position: certified at a band, or remediation owned and dated? (methodology steward)
  13. Publish the compliance report and the catalog status; an expired package re-enters the next intake batch as a modify request (standardization lead).

L2 step table

The documentation join key is the key an L3 job aid, a ticket and a variant row cite. Thresholds and system names are L3 values.

Step Sub-step Owner (seat) Inputs Outputs Duration Automation candidate Documentation join key
1 Assemble the batch from the intake log; return an incomplete request to its requester standardization lead the intake log the batch before the sitting Y GP-601/1.1
2 Search the catalog by name and abstract for an existing package or shell behind each request standards committee the catalog match or no match minutes [A] Y GP-601/2.1
2 Score importance and volume on the function's two scales (SET LOCALLY); class new or modify, major or minor standards committee the request; the scales a screened, classed request one sitting N GP-601/2.2
3 Record the minor modify against the package with the process owner as editor standards committee a minor modify a routed edit minutes [A] N GP-601/3.1
4 Propose a re-rank from the scores and the dependency pulls (shared definitions, the agent team's first processes, supplied work) standardization lead scores; dependencies a proposed order before the sitting Y GP-601/4.1
4 Confirm the order under the leadership's constraint; publish the queue standards committee the proposal the ranked queue one sitting N GP-601/4.2
5 Fill the L0 people block and set the authoring window standards committee the queue the people block one sitting N GP-601/5.1
6 Record each package's authoring and review status on its L0 card standardization lead the owners' reports status rows minutes [A] N GP-601/6.1
7 Circulate each docketed package and the checklist; open the turnaround clock standardization lead the package a gate sitting five business days [E] N GP-601/7.1
7 Record the response; carry each condition on the L0 with owner and date approvers named on the L0 the checklist the gate response one sitting N GP-601/7.2
8 Issue the version; store the baseline; write the change record (what, why, who approved, effective date) standardization lead the approved package the baseline and record same day [A] Y GP-601/8.1
9 Hand the baseline to the training lead and the automation analyst; schedule the go/no-go process owner the baseline two track plans one sitting N GP-601/9.1
10 Draft a modify request for each odd case not already absorbed into the L2 process owner the odd-case log modify requests per review cadence Y GP-601/10.1
11 List packages by expiry; flag those expiring inside the next cycle and those expired methodology steward the catalog the sweep list before the sitting Y GP-601/11.1
12 Check each flagged package against the conformance ladder; record the band, or remediation with owner and date methodology steward the sweep list; the audit record the compliance report per validation cadence N GP-601/12.1
13 Publish the report; route expired packages into the next batch as modify requests standardization lead the report the published status same day [A] N GP-601/13.1

Variants

Recorded per Standard and Variant in Process Documentation:

  • Statutory. Where a works council co-determines working time, a package that changes a scheduling rule is presented to the council before the gate: a consultation step between steps 6 and 7, owned by the works-council liaison, with a variant row.
  • Contractual. A contract requiring notice before a process change at its supply node parameterizes step 9 with the notice period: SET LOCALLY, no variant row.
  • Structural. A function whose repository cannot hold versions runs a manual version log at step 8 under a variant row reviewed at each sweep.
  • Transitional. A predecessor organization's board that still approves its own packages holds a variant row with an expiry at the dated cut-over; after it, those packages enter the batch as modify requests.

L3 register

Job aid Anchored to Form
The intake form and its six fields step 1 work instruction
The importance-by-volume screen and its two scales step 2 work instruction
The queue register and the wave-rank rule step 4 work instruction
The gate checklist, the three responses and the turnaround clock step 7 work instruction
The version-numbering and baseline rule step 8 work instruction
The two-track deployment plan and the go/no-go record step 9 playbook
The odd-case intake and the "revised together" rule for specification and step table step 10 playbook
The expired-package runbook: what happens on the day a cited package expires steps 11 to 13 runbook

Automation candidates

Flagged at L2 and released per class of action on a published catch rate per Human Gates and Number Grades. The list is ranked by how easy a catch rate is to publish for the sub-step; each item after the first says why it ranks after the one before.

  1. The catalog check (2.1): a deterministic search whose misses are visible at the next sitting.
  2. The sweep list (11.1): a query on expiry dates, as deterministic as the catalog check, but its errors surface only at the validation cadence, so a catch rate takes longer to accumulate.
  3. The baseline and change record (8.1): clerical given a versioned repository; ranks after the sweep because a wrong record is found only when someone reads it.
  4. The intake batch (1.1): assembly from a log; ranks after the baseline because an incomplete request is caught by the requester's reply, not by a rule.
  5. The re-rank proposal (4.1): computed from scores and dependency pulls; ranks lower because the board's final order is the only measure of its error, and the board decides.
  6. The odd-case draft (10.1): a modify request drafted from the overseer's log; last because its error is a request the process owner declines, which is a judgment, not a catch.

The acceptance gate (7.2) is never a candidate: approval is a named seat's commitment to drive adoption and accept audit, and the documented-information discipline this process operationalizes requires documented information to be reviewed and approved.[3][4] Nor is the screen (2.2): importance is a judgment the board owns, and a rule that ranked it would move the judgment to the rule's author.

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™ a function with a chartered board, a ranked queue and a gate run by hand is at Level 2; one whose sweep, catalog check and baseline record run on a published catch rate and whose machine track builds from approved L2s is at Level 3; one whose L2 tables are machine-readable and whose conformance is checked against them automatically, as Process Decomposition (L0–L3) describes, is at Level 4.

See Also

References

  1. ↑ AXELOS (2019). ITIL Foundation: ITIL 4 Edition. The Stationery Office. The change-enablement practice and the change authority.
  2. ↑ Hammer, M., & Stanton, S. (1999). "How Process Enterprises Really Work". Harvard Business Review 77(6), 108–118.
  3. ↑ International Organization for Standardization (2021). ISO 10013:2021 — Quality management systems — Guidance for documented information. Geneva: ISO.
  4. ↑ International Organization for Standardization (2015). ISO 9001:2015 — Quality management systems — Requirements, clause 7.5. Geneva: ISO.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Standards_Governance_and_Change_Control_(generic_process)&oldid=5470"