Placement Decision Through the Gate (generic process)

From WFM Labs

Placement Decision Through the Gate (generic process) is the generic process card, GP-401, for the operating flow by which a workforce function turns a placement question into a recorded decision. A placement question is any ask that would result in a body of work sitting somewhere other than where it sits now, at any horizon. The flow runs from the intake door through the proposal written in the gate's terms, the constraint check, the sitting of the gate, the one-page output with its counterfactual sealed first, the function head's signature on the outcome as the function's advice, the node owner's decision, the ramp commitment, the naming of a monitoring owner and a mitigation trigger, and the filing that makes the decision recomputable. The gate's six tests (continuity · coverage floor · pooling penalty · contractual eligibility · language viability · service-construct fit) and five outcomes (pass · fail · fail unless a stated price is paid · pass until a stated date · cannot run, with the missing input named) are specified on Placement Engine Architecture, their decision instrument on Placement Rules and the Tenure Contract and their standing practice on The Placement Gate; none of that is restated here. This card carries the process around the gate: who does what, in what order, with what record. It is part of Process Standardization and sits under the work-placement section of the function catalog in Anatomy of a ROC Standard.

The card exists because the gate is a check, not a process. A function that has the six tests but no flow runs them when someone remembers, on proposals written in whatever terms arrived, and decides in the meeting that happened to be scheduled. The flow gives the check one door, one proposal form, one output, one signature and one filing. Its structural ancestor is the stage-gate review, in which a proposal is scored against stated criteria at a fixed point before resources are committed, and the gate's output rather than its discussion is what the organization carries forward.[1]

Process profile

The profile extends the L0 identity fields of Process Decomposition (L0–L3) with the 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-401 · local card id assigned by the standards committee at deployment
Class both, in the catalog's four-class vocabulary (strategic · real-time · both · supporting): the same flow serves a renewal eighteen months out and an overflow proposal for next week; only the readout target differs
Trigger a placement question reaches the intake door, or a recompute trigger fires against a recorded decision
Cadence on demand; typically two or three live questions a quarter in a function that has just adopted the gate [A]; a recompute pass monthly against the trigger list (SET LOCALLY)
Scope in every proposal that moves a body of work between nodes (a hub, a service center, a partner or automated capacity) at any horizon: renewals, overflow arrangements, new books, pool moves, automation absorbing a task type
Scope out the tests and their arithmetic (Placement Engine Architecture); the constraint register's upkeep; the routing change that executes a decision (Vendor Change Control for Routing); the vendor scorecard (Vendor Performance Review Cycle (generic process)); the shaping of a sourcing proposal before it reaches the door (Sourcing Decision Under Imperfect Data (generic process))
Inputs the ask as it arrived; the constraint register; the supply cards of the from-node and the to-node; the forecast and its lock for the body of work; the definitions register; the contract renewal calendar
Outputs the gate output page (six results, price or date, citations, counterfactual, the function's signed advice, the decision); the ramp commitment; the monitoring assignment and mitigation trigger; a recompute-log entry; a definitions-register row for every cannot-run
Upstream the intake door (Work Intake for Planning and Analytics Teams); the monthly clearing of surpluses against shortfalls (The Workforce Broker); the capacity plan (Monthly Capacity Planning Cycle (generic process)); the incident record via the continuity wire
Downstream routing and change control; the vendor review cycle (ramp milestones become scorecard rows); scheduling (the receiving pool's requirement); finance (the priced outcome); the recompute log
Resources the constraint register; supply cards; the queueing arithmetic for the coverage and pooling tests; the output page template; the recompute log. Platforms are named at L3, never here
Decision points is this a placement question; can the proposal be written in the gate's terms; did every test run; does the node owner accept, pay the price or decline; has a recompute trigger fired
Authority tier per the work-placement row of Decision Authority Tiers in Workforce Operations: tier 3 (the placement lead) sits the gate; tier 4 (the function head) signs the gate outcome as the function's advice; the node owner, who owns the body of work and never operates the node, decides outside the function's ladder and records a decline with its price; a proposal that changes the design of the network itself (a node opened or closed, a construct changed across the estate) goes to the executive sponsor
Risk and compliance flags a move that changes the jurisdiction of the work engages consultation obligations before it is committed; a move across a contract boundary is a commercial change; a decision filed without its counterfactual can never prove the gate's value or its redundancy
Variant-prone steps the consultation step where a jurisdiction requires it; the signature where a predecessor organization's sourcing committee still signs; the card-reading step where a node has no supply card
Automation candidates eight L2 sub-steps (listed below)

L1 flow

Fifteen steps, five decisions. Owners are seats.

  1. Receive the ask at the intake door. Is this a placement question? — intake owner. Yes → 2; no → the door's other routes.
  2. Write the proposal in the gate's terms: body of work, from-node, to-node, horizon, owner of the work, requester — placement analyst.
  3. Is the body of work labeled once across channels, and is every field filled? — placement analyst. Yes → 4; no → return to the door with the gap named (cannot-run applied before the tests; see Intent Normalization Before Work Placement).
  4. Seal the counterfactual: the proposal's owner writes what they would decide without the gate, before any test runs — node owner.
  5. Pull the constraint-register entries that bind the body of work, cited by identifier with strictness class and date — placement analyst.
  6. Read the supply cards of the from-node and the to-node — placement analyst.
  7. Sit the gate: run the six tests, one row per test with outcome, number and grade — placement lead (tier 3).
  8. Did every test run? — placement lead. Yes → 9; no → record cannot-run, name the missing input and its obtainer, open a definitions-register row, return a partial readout inside the readout target (SET LOCALLY).
  9. Assemble the one-page output: six results, every non-pass in one plain sentence with its number, the price or the date, the citations, the counterfactual, the decision field open — placement analyst.
  10. Sign the outcome as the function's advice; refer a network-design change to the executive sponsor — function head (tier 4).
  11. Does the node owner accept, pay the stated price, or decline? — node owner, outside the function's ladder. A decline carries its price; a priced acceptance is a purchase.
  12. Record the ramp commitment for an accepted move: time to fill, time to proficiency, the milestones between, the steady-state target, each tracked separately — placement lead with the receiving node's lead.
  13. Name the monitoring owner and write the mitigation trigger as an observable condition (a dated pass's date, a missed ramp milestone, a pool crossing its viability floor) — placement lead.
  14. File the page, the counterfactual and the ramp sheet; cross-reference every register entry cited — registers' steward.
  15. Has a recompute trigger fired against this decision? — placement lead, monthly. Yes → rerun from 5 with the sealed counterfactual carried; no → the decision stands.

L2 step table

The generic sub-steps. Thresholds, readout targets and platform names are L3 values and read SET LOCALLY. The join key names the L3 job aid in the register below.

Step Sub-step Owner (seat) Inputs Outputs Duration Automation candidate Documentation join key
1 1.1 Apply the labeling question; log the ask intake owner the ask class assigned; log entry minutes Y (logging) L3-401-01
2 2.1 Fill the six proposal fields placement analyst the ask; the body-of-work dictionary proposal in gate terms one sitting N L3-401-02
3 3.1 Check the label is one across channels; return to the door if a field is empty placement analyst the definitions register pass, or return note same day Y (lookup) L3-401-02
4 4.1 The proposal owner writes and seals the counterfactual node owner the proposal sealed record before step 5 N — never L3-401-03
5 5.1 Query the register for binding entries; flag lapsed dates and open disagreements placement analyst the constraint register cited entries with class and date minutes Y (query) L3-401-04
6 6.1 Read the two supply cards and carry each attribute's grade placement analyst supply cards card extract minutes Y (lookup) L3-401-05
7 7.1 Run continuity and construct fit from the register placement lead cited entries; the proposal two test rows one sitting N L3-401-06
7 7.2 Compute the coverage floor and the pooling cost placement lead volume, handle time, shrinkage, service target, each graded two rows with numbers and grades one sitting Y (arithmetic) L3-401-06
7 7.3 Read contractual eligibility and language viability from the register and the cards placement lead cited entries; card tenure and volume fields two test rows one sitting N L3-401-06
8 8.1 For each test that could not run, name the input and its obtainer; open a register row placement lead the test rows cannot-run rows; register rows same day N L3-401-09
9 9.1 Assemble the output page placement analyst rows, citations, counterfactual output page, decision open one sitting Y (assembly) L3-401-07
10 10.1 Sign the outcome as the function's advice; refer a network-design change function head the output page signed advice, or referral inside the readout target (SET LOCALLY) N — never L3-401-07
11 11.1 Record the decision; a decline carries its price node owner the signed page recorded decision inside the readout target (SET LOCALLY) N — never L3-401-07
12 12.1 Write the ramp commitment: fill, proficiency, milestones, steady state placement lead; receiving node lead the card's speed fields ramp sheet one sitting N L3-401-08
13 13.1 Name the monitoring owner; write the mitigation trigger placement lead ramp sheet; trigger list monitoring assignment minutes N L3-401-08
14 14.1 File and cross-reference registers' steward the completed page recompute-log entry same day Y (filing) L3-401-10
15 15.1 Walk the trigger list against open decisions placement lead trigger list; renewal calendar; card change log decisions to rerun monthly Y (detection) L3-401-10

Variants

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

  • Statutory. A jurisdiction in which moving work into or out of a site engages a works council's consultation right inserts a consultation step between the decision (11) and the ramp commitment (12); the works-council liaison owns it and the function head approves the variant. The obligation itself is a hard entry in the constraint register; the inserted step is the variant.
  • Contractual. A contract that forbids overflow, fixes a construct or dedicates a pool is a register entry read at step 5. The flow is parameterized by the register, so the entry is SET LOCALLY and takes no variant row; a fail or priced fail is the generic step doing its work.
  • Structural. A node with no supply card returns cannot-run on two tests every time. Step 6 is varied to read a declared interim sheet, reviewed at each monthly pass until a card exists.
  • Transitional. A unit from a predecessor organization whose own sourcing committee still signs placement decisions carries a second signature at step 10 under a variant row, with an expiry the standards committee dates.

L3 register

A localizing team writes these job aids against the generic L2; names only. Thresholds (the readout target, the bounds of a routine recompute) are marked SET LOCALLY in the L2 rows, and each decision branch is an L2 row of its own.

Job aid Anchored to Form
L3-401-01 The labeling question at the door and the question log step 1 work instruction
L3-401-02 The proposal form, the body-of-work dictionary, the return note steps 2 to 3 work instruction
L3-401-03 The counterfactual seal: who writes it, where it is held, who may open it step 4 work instruction
L3-401-04 The constraint-register pull: query, citation format, date and disagreement checks step 5 work instruction
L3-401-05 The supply-card read sheet step 6 work instruction
L3-401-06 The six-test workbook: the arithmetic rows, the register reads, the row format step 7 work instruction; arithmetic on Erlang C and Pooling Architecture in Service Workforces
L3-401-07 The output page template, the signature block and the decision record steps 9 to 11 work instruction
L3-401-08 The ramp commitment sheet and the mitigation trigger form steps 12 to 13 playbook
L3-401-09 The cannot-run readout step 8 runbook
L3-401-10 The recompute log and the trigger list with owners and sources steps 14 to 15 playbook

Automation candidates

Flagged at L2 per 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. The list is ranked by how easy a catch rate is to publish: the eight L2 rows marked Y, in order.

  1. The constraint-register pull (5.1): a deterministic query with a date check against a register that already carries identifiers; every error it can make is a mismatch the overseer can count.
  2. The supply-card read (6.1): ranks after the pull because a card attribute carries a grade the lookup must copy correctly, which adds one failure class.
  3. The coverage-floor and pooling-cost arithmetic (7.2): ranks after the reads because its catch rate depends on the inputs' grades as well as on the formula; the behaviour of Erlang-family calculations with pooled and split streams is well characterised,[2] and the overseer checks inputs and grades rather than arithmetic.
  4. The label check (3.1): ranks after the arithmetic because a label that is "one across channels" is a definitions-register judgment the lookup can only approximate until the register is complete.
  5. The output-page assembly (9.1): ranks after the label check because it composes the outputs of four earlier candidates and inherits every one of their error classes.
  6. The filing and cross-reference (14.1): ranks after assembly because a filing error is silent until a recompute needs the citation, which delays the catch.
  7. The question log (1.1): ranks after filing because the log is only as good as the labeling question the intake owner answered by hand before it.
  8. Recompute-trigger detection (15.1): last because its catch rate can only be published against a hand-kept trigger log, which the function builds for a quarter before anything is released; the renewal calendar, the card change log and the forecast version record are all observable once that log exists.

Three steps are never candidates. The counterfactual seal (4.1) is a stated human expectation recorded before the result is known; automating it would remove the one record by which the gate proves its value or its redundancy, the calibration logic of pairing an expectation with an observed outcome when no experiment is available.[3] The function head's signature (10.1) is the act that makes the page the function's advice rather than an analyst's worksheet. The decision (11.1) belongs to the node owner by principle 5 of Operating Principles for Work Placement: the function owns the method, the owner of the work owns the decision, every decline is recorded with its price. A hard constraint excludes and never lowers a score, so the fail outcome is computable; the choice to pay a price is a purchase and is not.

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 written constraint list that runs the check on some proposals is at Level 3; one that runs this flow routinely by hand, with all five outcomes, the counterfactual sealed first and the trigger list walked monthly, is at Level 4, as The Placement Gate states; one whose recompute runs on the trigger classes with the first three candidates above released on a published catch rate is at Level 5. The flow is certified by hand before any candidate is released, because a rule cannot be written against a check that runs six ways.

See Also

References

  1. ↑ Cooper, R. G. (2008). "Perspective: The Stage-Gate Idea-to-Launch Process — Update, What's New, and NexGen Systems". Journal of Product Innovation Management 25(3), 213–232.
  2. ↑ Gans, N., Koole, G., & Mandelbaum, A. (2003). "Telephone Call Centers: Tutorial, Review, and Research Prospects". Manufacturing & Service Operations Management 5(2), 79–141. doi:10.1287/msom.5.2.79.16071.
  3. ↑ Tetlock, P. E., & Gardner, D. (2015). Superforecasting: The Art and Science of Prediction. Crown. Chapter 3.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Placement_Decision_Through_the_Gate_(generic_process)&oldid=5498"