Standard and Variant in Process Documentation
Standard and Variant in Process Documentation is the convention by which a workforce function documents one generic process and records every country-, site- or vendor-specific exception against it as a variant, rather than maintaining a separate copy of the process per location. It matters because a function formed from several regions or predecessor organizations typically holds the same process in five or six local versions that differ in a handful of steps, and a standard that copies the process per location cannot be compared across regions, cannot be certified once, and cannot be automated; unmanaged local variation is the main reason process comparability is lost.[1] The convention is part of Process Standardization and is applied at the L2 step table of Process Decomposition (L0–L3), where a step whose value is legitimately local is marked SET LOCALLY and the local value is held in the variant register.
The convention adopts the distinction made in the operating-model literature between standardization, where the process runs the same way everywhere, and integration, where the processes share data,[2] and treats variants as the explicit, bounded cost of standardization that a global function accepts and governs through a named process owner, the mechanism the process-enterprise literature identifies as the precondition for a standard process to hold across business units.[3] Older operating standards for resource optimization centers handled the same problem by listing accommodated variations with an expiry date each; the register below generalizes that rule to four classes of variation and a retirement condition for every row.
Why variants exist
A workforce process varies legitimately for four classes of reason, and the register records which class a variant belongs to because the class determines who may approve it and how long it may stand.
| Class | Example | Who approves | Typical review |
|---|---|---|---|
| Statutory | Working-time, rest-break and predictability-pay rules; co-determination rights of a works council over the start, end and weekly distribution of working time in several European jurisdictions[4] | the function head, on legal advice | when the law changes |
| Contractual | A client contract that dedicates agents, fixes a service construct, or forbids overflow; a vendor contract that prices a different unit | the placement and vendor lead | at contract renewal |
| Structural | A site with no night shift; a channel with no real-time state; a platform that cannot emit an event the standard assumes | the process owner | when the structure changes |
| Transitional | A unit migrating from a predecessor organization that still runs its old step until a dated cut-over | the standards committee | at the stated expiry, never extended silently |
A fifth category, local preference, is not a variant class. A step that a site runs differently because it always has, with no statutory, contractual, structural or transitional reason, is a compliance finding under step 3.2 of the Process Standardization Lifecycle, not a variant.
What is recorded
A variant is a row in the variant register of the parent standard, keyed to the steps it modifies.
| Field | Rule |
|---|---|
| Variant ID | V-nnn, issued by the standards committee
|
| Process and steps | the generic process (its card) and the L1 or L2 steps the variant modifies; a variant may modify several steps, and each step it modifies is listed |
| Scope | the countries, sites, vendors, channels or client contracts the variant applies to, named as classes where the standard is published outside the function |
| Class | statutory · contractual · structural · transitional |
| The difference | what the step does differently, in the same active voice and ownership form as the generic step |
| Owner | a seat, never a name; the seat accountable for the local value |
| Approved by | the approving seat for the class, and the date |
| Expiry or review | transitional variants expire; the others carry a review date |
| Automation effect | whether the variant blocks, parameterizes or does not touch an automation candidate flagged at L2 |
The generic process itself does not change when a variant is added. Its L2 row for the affected step carries the mark SET LOCALLY — <seat> from Process Shells for a Workforce Standard, which tells a reader that a value exists, that it is local, and where to find it. Thresholds, calendars and system names are never written into the generic step, which keeps the generic process certifiable once and keeps the variant register as the single place where local reality is held. The quality-management requirement that documented information be controlled is the reason a per-site copy fails: when six copies exist, none is the controlled one.[5]
The variant test
Before a committee admits a variant, the author answers four questions in order. The questions are the same for every class.
- Does the generic step fail here, or does the site simply prefer another way? Preference is not admitted.
- Can the difference be expressed as a parameter of the generic step (a different threshold, calendar, approver tier) rather than a different step? A parameter is marked SET LOCALLY and needs no variant row.
- If a different step is required, does it change the step's owner, its inputs or outputs, or its position in the flow? Only then is it a variant; otherwise it is an L3 work-instruction difference, held in the local job aid.
- What would retire the variant? Every row names its retirement condition, even when the condition is "the statute changes".
The test is deliberately asymmetric. It is easy to add a parameter and hard to add a variant, because every variant is a branch that an automation rule must carry and that the overseer, the seat that verifies a released rule's output, must verify separately.
Variants and automation
Standardize Before You Automate places process standardization ahead of automation because a rule cannot be written against a process that runs six ways. The variant register is how the sequence survives contact with real operations: an automation candidate flagged at L2 is released for the generic step first, then for each variant whose automation effect field reads parameterizes, and never for a variant whose field reads blocks until the variant is retired or the rule is rewritten. The catch rate, the proportion of a rule's known errors that the verification step detects, is published per class of action and per variant as Human Gates and Number Grades requires, not per process, because a rule that is right everywhere but one jurisdiction is wrong in that jurisdiction every day.
Worked example
A generic schedule-build process publishes schedules fourteen calendar days before the first shift. Three local differences arrive. In one jurisdiction a statute requires publication twenty-one days ahead with predictability pay for later changes: statutory, a parameter of the publication step, SET LOCALLY, no variant row. In a second, a works council must receive the draft schedule and may object within five working days: statutory, a new decision step between build and publish, a variant row with the works-council liaison as owner and the function head as approver. For a unit migrating from a predecessor organization that still builds on its old platform, schedules are exported and re-keyed by hand: transitional, a variant row with an expiry at the platform cut-over date and an automation effect of blocks against the publication-automation candidate until then.
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™ the convention is a Level 2 practice: a function that cannot say which of its local differences are variants and which are preferences has not standardized, whatever its documentation count. At Level 3 the register's automation effect field becomes the release list for rules by jurisdiction. At Level 4 the register is read by the placement engine as a constraint class, so that work is not placed where a variant forbids the construct.
See Also
- Process Standardization — the hub this convention belongs to
- Process Decomposition (L0–L3) — where SET LOCALLY marks are placed
- Process Shells for a Workforce Standard — the shell marks and the catalog
- Process Standardization Lifecycle — the acceptance gate and compliance step
- Anatomy of a ROC Standard — the parent standard that holds the variant register
- Labor Law and Scheduling Compliance — the statutory class in detail
- Union Environments and WFM — co-determination and collective agreements
- Standardize Before You Automate — why the sequence runs standard, then rule
References
- ↑ Davenport, T. H. (2005). "The Coming Commoditization of Processes". Harvard Business Review 83(6), 100–108.
- ↑ Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Harvard Business School Press, chapter 2.
- ↑ Hammer, M., & Stanton, S. (1999). "How Process Enterprises Really Work". Harvard Business Review 77(6), 108–118.
- ↑ Betriebsverfassungsgesetz (German Works Constitution Act) §87(1) No. 2 and No. 3: the works council has a co-determination right over the start and end of daily working time, its distribution across the week, and temporary changes to customary working hours. English translation at gesetze-im-internet.de.
- ↑ International Organization for Standardization. ISO 9001:2015 Quality management systems — Requirements, clause 7.5 (documented information). iso.org.
