Process Inventory for a Workforce Function
Process Inventory for a Workforce Function is the convention by which a workforce function lists every process it runs, in six pillars, and maps each process to the section of its own standard that owns it and to the external certification item that audits it. It matters because a function formed from several predecessor organizations typically knows its processes as practice rather than as a list, and a standard that cannot say how many processes it owns cannot rank a documentation queue, cannot be mapped to a certifier's requirements, and cannot tell whether a new request is a new process or a step of one it already holds. The convention is part of Process Standardization; it is the inventory beneath the function catalog of Anatomy of a ROC Standard, discovered at the standards committee's first sitting as Process Shells for a Workforce Standard describes.
The inventory is a taxonomy, not documentation: it says which processes exist and where each sits, as a process classification framework does without prescribing how any process runs;[1] how a process runs belongs to its generic process card and to Process Decomposition (L0–L3). A process that appears in two lists under two names is documented twice and then drifts, the failure one owner per process is meant to prevent.[2]
Six pillars, eleven sections, nine items
The function catalog of Anatomy of a ROC Standard has eleven sections, §3.1 to §3.11; the COPC Standard places its process requirements in nine items under its Processes category.[3] The inventory sits between the two.
| Pillar | Function sections | COPC item | What the pillar owns |
|---|---|---|---|
| Forecasting | §3.1 forecasting · §3.2 capacity planning | Forecasting, Staffing and Scheduling | the demand and supply outlook at every horizon; the requirement; the gap; the lock; accuracy governance |
| Scheduling | §3.3 scheduling | Forecasting, Staffing and Scheduling | the schedule of record from build to retirement; time-off allotment; flexible-workforce administration; activity codes |
| Real-time | §3.4 real-time performance and automation · §3.6 incident management | Forecasting, Staffing and Scheduling (its real-time requirement) · Corrective Action | the operating day; levers; adherence; alerts and escalation; incidents and their learning loop |
| Work placement | §3.7 work placement · §3.10 routing and the capability layer | Vendor Management | the placement decision through the gate; the scorecard cycle; sourcing under uncertainty; loans and trades; routing change control |
| Continuity interface | the continuity wire, which leaves from §3.6 | Business Continuity | the ROC side of the wire: crisis trigger and re-plan, placement under duress, judgmental forecasting in crisis, platform degradation and buffer staffing, skill-mix review |
| Cross-cutting | §3.5 intake and the register · §3.8 reporting and analytics · §3.9 data definitions and governance · §3.11 business improvement | Managing Change · Compliance · Reporting and Data Integrity | the standard's own change control; the weekly forecast-vs-actual review; compliance review; report publication; the data audit and the registers' change control |
The six pillars extend the three-pillar architecture of WFM Processes with the work a global function adds: placement across nodes, the wire to a continuity function, and governance that belongs to no single pillar. The data definitions section (§3.9) has its own hub, Workforce Data Definitions Framework, which the cross-cutting cards GP-605 and GP-606 defer to.
What is a process and what is not
Three rules decide whether a candidate enters the inventory.
A lens is not a process. The capability layer of §3.10 is a way of seeing the estate, which node can do what at what cost; it has no trigger, cadence or product of its own, so it has no card. The processes are the placement decision that reads it (GP-401) and the change control that alters routing (Vendor Change Control for Routing). The Definitions Register is likewise an instrument every card reads; only its change control is a process.
Business continuity is a partner function. Continuity owners own preparedness and the activation decision; the workforce function owns the wire, a trigger and a product, as Integrated Global Resource Optimization Center settles it, so the continuity pillar inventories only the ROC side of it. Contact Center Security is likewise a link, not a process of this function.
Vendor management is not a function. By the catalog rule on Anatomy of a ROC Standard, every section carries a vendor paragraph stating what differs when the node is a partner, so supplied work is the same process on another node, and the scorecard review is a process of the placement function (GP-402). A separate vendor-management function would bolt vendor forecasting, scheduling and incidents onto every core process as exceptions.
The intake screen
A request arrives through the function's single intake door (Work Intake for Planning and Analytics Teams) and is screened by the standards committee at the catalog check of the Process Standardization Lifecycle, with four questions in order:
- Importance by volume. How much depends on the process (a service commitment, a cost line, a statute, a client contract) and how often it runs; a process low on both stays practice and enters the deferred log with the reason. The same screen ranks the first wave on Process Shells for a Workforce Standard.
- Already catalogued? Does a card exist under another name, or is the request a step of a process the inventory holds? The question separates a process with its own trigger and cadence, such as the weekly rolling reforecast (GP-103), from a re-run of another process's steps under a new name; the shell page's worked example struck a predecessor organization's "weekly reforecast" because it proved to be the latter, a re-run of the forecast build. A yes becomes a modify request.
- New or modify? A new card, or a change to an existing card.
- Major or minor? A major change alters the L1 flow, ownership, or the profile's trigger, scope, authority tier or class, and reopens L0 approval; a minor change alters L2, L3 or another profile field and is recorded in the revision history, the rule the process profile on Process Decomposition (L0–L3) states.
The product is a queue position or a deferred-log row; nothing is refused silently, because a request that vanishes returns under a new name and the second question then fails.
Four process types
Every card is read as one of four types; the type decides which L3 form its job aids take (Runbooks, Playbooks and Work Instructions) and the cadence of their review.
| Type | Trigger | Typical L3 form | Example |
|---|---|---|---|
| Operations | a calendar, a shift or an interval boundary | work instruction | the monthly capacity cycle; report publication |
| Break/fix | a degradation past a written entry condition | runbook, with a playbook where options exist | platform degradation; incident management |
| Change | a request through the change-control board | the change record and a work instruction per step | routing change control; standards change control |
| Method of procedure | a dated, rarely repeated event executed to a script | runbook with verification and rollback at every step | a client portfolio's cut-over to the shared calendar; a platform instance consolidation |
The fourth type takes its name from telecommunications operations, where a scripted, verified, reversible sequence is the instrument for a one-time change that cannot be rehearsed; a change-type process is the governance around such sequences.
The inventory
Twenty-nine generic process cards, by pillar, classed in the catalog's vocabulary. Where an existing page documents the method at L1 and L2, the card defers to it and carries only the profile, variants, L3 register and automation candidates, as Monthly Capacity Planning Cycle (generic process) does. The local card id (P-nnn) is assigned at deployment and never appears here.
Eleven earlier pages already serve as generic processes, carrying an L1 and in most cases an L2; no card duplicates them, and the committee catalogs each as a conversion. Under forecasting (§3.1): Three-Step Forecast Build, Forecast Lock Process and Forecast Collision Calendar. Under scheduling (§3.3): Activity-Code Consistency. Under incident management (§3.6): Event, Incident and Problem in Contact Centers (definitions), Contact-Center Incident Severity Matrix (controls), Incident Management for Contact Centers (the twelve-step process) and, shared with §3.11, Post-Mortem and RCA for Workforce Operations (the learning loop). Under routing (§3.10): Call-Sharing Models and Cost Allocation and Vendor Change Control for Routing. Under intake (§3.5): Work Intake for Planning and Analytics Teams.
Nine COPC items: seven map, two do not
Seven of the nine items map directly: Forecasting, Staffing and Scheduling to the first three pillars; Managing Change to GP-601 and the change-control board; Corrective Action to Post-Mortem and RCA for Workforce Operations and GP-602; Vendor Management to GP-402 and the vendor paragraph of every section; Business Continuity to GP-501, the ROC side of the wire; Compliance to GP-603; and Reporting and Data Integrity to GP-604, GP-605 and GP-606 with The Definitions Register.
Two map to no card, deliberately. Transaction Monitoring belongs to the quality function (Quality Management): the workforce function consumes its outputs (a handle-time shift after a scripting change arrives as an event in the collision calendar) but owns no monitoring or calibration process. Technology Management belongs to systems administration and the change-control board: Systems Administration for WFM Platforms holds platform configuration to the standard, and the toolset section names capabilities rather than products, so no process here is bound to a system. A function that places either in its inventory documents another function's process, and the second screening question fails at the first audit.
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™ an inventory with an owner per row is the entry move of Level 2, where Process Shells for a Workforce Standard places cataloging; at Level 3 it is read as the automation candidate list, pillar by pillar, and the mapping to the certification items lets conformance be stated per function rather than per audit finding.
See Also
- Process Standardization — the hub this convention belongs to
- Anatomy of a ROC Standard — the eleven-section function catalog the pillars map to
- Process Shells for a Workforce Standard — the shell, the catalog row and the first-wave screen
- Decision Authority Tiers in Workforce Operations — the authority tier each card's profile names
- Runbooks, Playbooks and Work Instructions — the L3 forms the four process types take
- COPC Standard — the certification items
References
- ↑ APQC. Process Classification Framework (PCF), Cross-Industry, version 7.3. APQC, Houston. Category 7.0, Develop and Manage Human Capital.
- ↑ Hammer, M., & Stanton, S. (1999). "How Process Enterprises Really Work". Harvard Business Review 77(6), 108–118.
- ↑ COPC Inc. COPC CX Standard, Release 8.0, Category 2.0, Processes. copc.com.
