Wiki:Packs/Process Decomposition

From WFM Labs
Pack
ID CP-OPS-001
Name Process Decomposition
Domain OPS
Blocks 1 instruction + 4 reference
Version 1.1
Source Process Decomposition (L0–L3) · Incident Management for Contact Centers · Capacity Planning Cycle · Process Shells for a Workforce Standard · Process Standardization Lifecycle
Planning-week block Day 2 afternoon (process shells; the catalog); Day 4 morning (the standard's owners and dates)

A deployable Claude project setup for producing L0–L3 process decompositions: the four-artifact documentation standard described at Process Decomposition (L0–L3). Copy Block 1 into a project's custom instructions; save Blocks 2–5 as Markdown files and upload them as project knowledge. Version 1.1 adds Block 5, the L0 card as a shell with marked placeholders, for a function cataloging its processes before it has documented them (Process Shells for a Workforce Standard). See Wiki:Packs for how packs work.

When to use it

Use this pack when a process needs documenting to an auditable standard — a cover sheet with owners and approvals, a one-page flow, a full step table, and a job-aid register — or when an existing pile of procedure documents needs converting into one navigable tree. The pack produces the four files; pair it with a spreadsheet or diagramming tool for final formatting. It is not for process improvement work (measure first) or for taxonomy work across many processes (that is a classification framework's job). In a planning week it serves the Day 2 afternoon block, producing the function catalog and the L0 cards as shells with "skeleton until" dates, and the Day 4 morning return, when the standard is issued with an owner and a date per section.

Block 1 — project instructions

You are a process documentation assistant producing L0-L3 process decompositions
per the framework in `framework.md`. The worked example in
`sample-incident-management.md` shows the target quality; `workbook-layout.md`
specifies the spreadsheet layout when the user wants Excel output. When the
user is cataloging processes that are not yet documented, produce the L0 as a
shell per `process-shell.md`.

For any process the user brings, produce four artifacts, in this order:

1. **L0 — Document identity.** Interview for: procedure name, organization,
   document type, category, owner, document home, abstract (2-3 sentences,
   purpose and scope only — no steps), authors/reviewers/approvers, keywords.
   An empty block of a shell carries one of the three marks in
   `process-shell.md` (SHELL, SET LOCALLY, NOT INVENTORIED), each with its
   seat and, where the mark takes one, its date; TBD is for an unknown L2
   cell and for a card kept outside a standard. Start the revision history
   at v1.0.
2. **L1 — Process flow.** Elicit the major steps: integers 1..n, each with a
   name, a type (Activity or Decision), an owner, and routing. Decisions are
   questions and get their own numbers. Draw iteration as explicit loops.
   Target 10-15 steps; challenge the user if outside that range.
3. **L2 — Step table.** Decompose each L1 step into sub-steps numbered L1.n
   with the 15 columns in `framework.md`. Every row gets an owner and a
   duration ("Continuous" is legal for monitoring). Dependencies may reference
   either level and may state alternatives ("3.1 or 4.5"). Decision branches
   are L2 rows ("If yes, proceed to step 11"). Note which attributes are
   constant per step — they merge in the workbook.
4. **L3 — Documentation register.** Every document named in the L2
   "Applicable Documentation" column gets a register row: name, contents,
   anchor to the parent standard. Thresholds, screenshots, and named systems
   belong at L3, never at L2 — flag violations.

Rules:
- Build in order L0 → L1 → L2 → L3; do not skip ahead. L0's abstract settles
  scope before any step is drawn.
- One question at a time when interviewing; propose drafts and let the user
  correct, rather than asking for everything up front.
- If two owners claim one step, or a decision has no decider, or a named job
  aid does not exist — surface it as a finding, not a footnote. Surfacing
  these is half the method's value.
- Emit each level as its own Markdown file: L0-cover.md, L1-flow.md,
  L2-step-decomposition.md, L3-register.md.
- Keep company-specific systems in the user's artifacts; keep them OUT of any
  content the user marks for publication.
- Never fill a method block or an abstract for a process you have not been
  shown; write the shell mark with its seat and date instead.

Block 2 — framework.md

# The L0-L3 Process Decomposition Framework

One process, four artifacts, each for a different reader, joined by exact
cross-references.

## L0 — Document identity (a form)
Identity: procedure name · organization · document ID · document type ·
category/sub-category. Custody: owner · document home · filename ·
publication date · expiration date. Abstract: 2-3 sentences, purpose and
scope only. People: authors · peer reviewers · approvers. Findability:
references · keywords. Change control: revision history (Version · Name ·
Description of Change · Date). Every field is filled or explicitly marked:
TBD for an unknown field, and in a standard's shell one of the three marks
in `process-shell.md` instead.

## L1 — Process flow (one page, drawn)
Major steps only, integer-numbered, each with name + owner. Decisions are
diamonds phrased as questions with their own numbers. Iteration drawn as
loops. 10-15 steps is healthy. Readable in thirty seconds.

## L2 — Step table (15 columns)
1 L1 Step ID · 2 L1 Step Name · 3 Step Description (L2 summary) ·
4 L2 Step ID (L1.n) · 5 L2 Step Name/Short Description (the narrative
column) · 6 Dependent Steps (L1 or L2; alternatives allowed) · 7 Tools
Used · 8 Ticketing Code · 9 Step Owner (Group & Function) · 10 Ticket
Status · 11 Applicable Documentation (THE L2->L3 JOIN KEY) · 12
Notification Required? (Group, Function & Verbiage) · 13 Approval
Required? · 14 Approvers · 15 Step Duration (Continuous is legal).

Conventions: merging means constant (parent-step columns merge across a
step's rows; merged attribute = does not vary). Decision steps: question
in the L1 row, branches as L2 rows.

## L3 — Job aids and work instructions
The documents column 11 names: escalation charts, matrices, diagrams,
walkthroughs. Each anchors to a parent-standard section. Thresholds,
screenshots, named systems live here — never at L2. L0-L2 stay stable;
L3 revises often.

## Above L0: the parent standard
One document owns all of a function's processes, gives each a section,
holds shared material (definitions, severity models, escalation codes,
glossaries). A decomposition is the drill-down of one section.

## Build order
L0 (forces scope) → L1 (owner in the room) → L2 (one step at a time) →
L3 (mostly exists already; name and anchor it).

Block 3 — sample-incident-management.md

# Worked Example — Incident Management (generic, contact center)

## L0 (abridged)
Incident Management · Resource Optimization Center (ROC) · Break-Fix ·
Abstract: define the process for managing incidents to return service
levels to normal — ticket, diagnose, act, monitor, communicate through
resolution, post-mortem, and RCA follow-up.

## L1 — twelve steps
1 Identify Incident -> 2 Send Initial Messaging -> 3 Ticket Created?
(Yes: 5 / No: 4) -> 4 Create a Ticket -> 5 Set Severity / Verify
Correlation / Send Notification -> 6 Conduct Fault Analysis -> 7 Take
Corrective Action -> 8 Monitor the Fix (Resolved: 9 / Not: loop to 6) ->
9 Close the Ticket -> 10 Owned by the ROC? (Yes: 11 / No: 12) ->
11 Conduct Post-Mortem (Sev 1) -> 12 Monitor RCA Actions -> End.
Owner throughout: ROC Real-Time Team.

## L2 flavor (step 1 of 12; the full table runs 34 rows)
1.1 Monitor IVR analytics (volume vs pattern, self-service rate,
time-in-IVR) · 1.2 Monitor service levels and queues (speed/severity of
decline, calls in queue, longest holding) · 1.3 Monitor resource levels
(unplanned shrinkage, tool outages) · 1.4 Monitor external feeds
(weather, news) · 1.5 Monitor communications from network ops, centers,
vendors. All: owner ROC Real-Time Team, duration Continuous, doc "Job
Aid: Escalation Codes".

## Fixed diagnostic frame (step 6)
Four causes: poor line adherence · actual volume differs from forecast ·
scheduled line differs from arrivals · handle time longer than forecast.
Corrective actions pull three levers: volume (demand) · resources
(supply) · handle time.

## Two classification schemes, kept separate
Severity 1-5 classifies the INCIDENT (thresholds, notification windows,
update cadence, resolution SLAs — values set locally). Escalation codes
Blue/Green/Yellow/Red/Black classify the STAFFING STATE (triggers,
actions, approvals). They intersect (Red requires a ticket) but are not
the same instrument.

## L3 register (names)
Escalation Codes · Severity Matrix · Ticket Creation Table (SR vs MD
ticket classes, LOQ sets) · Real-Time Cause-and-Effect Diagram ·
Corrective Action Table · Incident Lifecycle Record (8 facts: start,
detected, engaged, impact, probable cause, mitigation, diagnosed,
repaired) · RCA Process · Work Instruction: Incident Ticketing.

Block 4 — workbook-layout.md

# Spreadsheet Layout for a Decomposition Workbook

Four sheets (plus an Instructions sheet in blank templates):

## Sheet "L0 Cover" — a form, not a table
Black title bar "Level 0 Decomposition". Label:value pairs two per row
(grey labels, bold): Procedure Name / Organization / ID; Document Type /
Owner / Publication Date; Category / Document Home / Expiration;
Sub-category / Filename. Then: Abstract (merged block), Authors + Peer
Reviewers, Approvers, Keywords, Revision History table (Version, Name,
Description of Change, Date).

## Sheet "L1 Flow" — the drawing spec
Columns: Step # · Step Name · Type (Activity/Decision) · Owner · Routes
To ("Yes: 5 / No: 4" for decisions). Highlight decision rows. The
flowchart is drawn from this table in any diagramming tool.

## Sheet "L2 Steps" — the 15-column table
Header row grey; freeze panes below it. Merge columns 1-3 and 9
vertically across each parent step's rows; merge any other
per-step-constant attribute. Widest column: 5 (the narrative).

## Sheet "L3 Register"
Columns: Document (as named in L2 col 11) · What it contains · Anchor
(parent-standard section).

Formatting carries meaning only through merges and the decision
highlight; no other color semantics.

Block 5 — process-shell.md

<!-- Derived from [[Process Shells for a Workforce Standard]] and [[Process Standardization Lifecycle]]; figures marked [estimated] are judgment, not measurement; numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. -->
# The L0 Card as a Shell

Use this file when the user is cataloging processes before documenting them:
the function's standard must be issued with an owner and a date against every
section on a fixed day, and the process inventory is not yet complete.

## Definition

A **shell** is an L0 card whose identity fields are filled, whose method
block is empty, and which carries a **skeleton-until** date. The standard
fills what it can fill on the day it is issued; the lifecycle fills the rest.
A placeholder without an owner and a date is not a placeholder; it is a
blank. Every empty block of a shell carries exactly one of three marks; that
is the one rule for an empty block of a shell. `Process Decomposition (L0-L3)`
requires every L0 field to be filled or explicitly marked TBD; a shell refines
that mark rather than replacing it, because the marks say who fills the block,
by when, and whether anyone should. TBD stays with an unknown cell of the L2
step table and with a card kept outside a standard; inside a shell, use the
marks.

## The three marks

| Mark | Meaning | Who fills it | Rule |
|---|---|---|---|
| `SHELL — owner <seat> · fill by <date>` | the lifecycle will fill it | the seat named, by the skeleton-until date | missing the date is a compliance fact, reported at lifecycle step 3.2 |
| `SET LOCALLY — <seat>` | the standard does not fill it; a node or estate does | the node, at deployment | thresholds, system names, notification values; row structure stays the standard's |
| `NOT INVENTORIED — <seat> · by <date>` | the process is asserted by a heritage, not confirmed | the standards committee, at its first sitting | allowed for one sitting only; then it is a shell or it is struck |

## Which blocks the standard fills, which the inventory fills

| Block | Field | Standard fills at issue | Inventory fills (lifecycle step) | Empty mark |
|---|---|---|---|---|
| Identity | ID (`P-nnn`) · process name · function · class | yes | — | — |
| Custody | owner (a seat) · document home (the standard's section) · publication and expiry (the standard's) | yes | — | — |
| Custody | lifecycle status | `Shell` | every step | — |
| Custody | wave rank · skeleton until | yes | re-ranked by the committee | — |
| Abstract | purpose and scope, 2–3 sentences, no steps | never | 1.2 Author | `SHELL — owner <seat> · fill by <date>` |
| People | approvers | as seats | — | — |
| People | authors · peer reviewers | never | 1.2 / 1.3 | `SHELL — owner <seat> · fill by <date>` |
| Findability | references · keywords | — | 1.2 | `SHELL — owner <seat> · fill by <date>` |
| Method | L1 flow · L2 step table · L3 register | never | 1.2 to 2.1 | `SHELL — owner <seat> · fill by <date>` |
| Controls | gate response · conditions · catch rate | — | 2.1 / 3.1 | `SHELL — owner <seat> · fill by <date>` |
| Change control | revision history | `v0.1 · shell created · <date>` | every step | — |

The abstract and the method block are never filled by the standard: the
abstract is where two heritages discover they meant different things by one
name, and it must be written by the owner. A shell with a standard-written
abstract has had its scope settled by someone who does not own it.

## Class

Every function and every card carries one class: `strategic`, `real-time`,
`both`, or `supporting`. Vendor governance is not a class and not a
function: each card carries a **node attribute** (which nodes it runs on)
and, where a partner node is involved, a **vendor paragraph** (what differs
at a partner node).

## The catalog row (the standard's §2)

| Section | Function | Class | Owner (seat) | Skeleton until | Cards beneath |
|---|---|---|---|---|---|
| §3.n | <function> | strategic · real-time · both · supporting | <seat> | <date> | the shells, or `NOT INVENTORIED — <seat> · by <date>` |

## Lifecycle status vocabulary (write exactly these)

`Shell` · `1.1 approved` · `1.2 authoring` · `1.3 in peer review` ·
`2.1 submitted` · `2.1 approved` · `2.1 conditionally approved` ·
`2.1 not approved` · `2.2 deploying` · `Live` · `3.1 under review` ·
`Certified L<n>` · `Expired`. Conversion of an existing package is a shell
whose status reads `Shell (conversion)`.

## The first wave

The committee ranks; the room fixes one constraint: *the processes the first
agent team will run stay in the first wave.* The first wave is small enough
to pass the acceptance gate inside the first-quarter front-load; everything
else takes a quarter-end skeleton-until date.

## Worked example (illustrative; the example's dates, not a rule)

| ID | Process | Function (class) | Wave | Skeleton until | Status |
|---|---|---|---|---|---|
| P-001 | Short-term forecast build and lock | forecasting (both) | 1 | Tue 30 Jun 2026 | 1.2 authoring |
| P-006 | The monthly capacity cycle | capacity planning (strategic) | 6 | Wed 30 Sep 2026 | Shell |
| P-008 | Incident lifecycle | incident management (real-time) | 8 | Thu 31 Dec 2026 | Shell (conversion) |

Request to approval for P-001 took 30 calendar days [C] against a nominal
20 [estimated].

## Refuse

- To fill a method block or an abstract for a process the user has not
  described; write `SHELL — owner <seat> · fill by <date>` instead.
- To put a person's name in any owner, author, reviewer or approver field;
  seats only.
- To set a value marked `SET LOCALLY`.
- To leave any empty block unmarked.

Usage notes

Sizing. Block 1 is about 440 words and loads with every message; Blocks 2–5 total about 1,950 words and are retrieved as needed; Block 5 is the largest at about 1,030.

Output. The pack emits Markdown; the workbook layout in Block 4 lets the output transfer to Excel by hand or by script. The sample is fully generic — adapting it to a local operation means substituting named systems, filling local severity values, and re-anchoring the L3 register to the local parent standard.

Shells. Block 5 is for cataloging before documenting. A shell is not a substitute for the four artifacts; it is the L0 with its method block marked and dated, and the lifecycle on Process Standardization Lifecycle fills it. The pack refuses to fill an abstract or a method block for a process it has not been shown, to name a person against a seat, or to set a value the standard leaves to a node.

Drift. Blocks 2–5 derive from the five source articles in the infobox. A material change to any of them is the trigger to regenerate the affected block and bump the version.

Scope. Nothing in the pack is specific to any organization.

Change history

Version Date Change
1.0 2026-09-04 First release: instruction block plus three reference files (framework, worked example, workbook layout)
1.1 <publish date> Block 5 process-shell.md added (the L0 card as a shell, the three placeholder marks, the catalog row, the lifecycle status vocabulary); Block 1 gains one routing sentence, one rule bullet, and the single empty-field rule (the three marks, each with its seat and date, for an empty block of a shell; TBD for an unknown field elsewhere), and Block 2's L0 line is aligned to it; Source gains the two planning-week process pages; planning-week block named

See also

Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Wiki:Packs/Process_Decomposition&oldid=4740"