Wiki:Packs/Process Decomposition

Pack
ID	CP-OPS-001
Name	Process Decomposition
Domain	OPS
Blocks	1 instruction + 3 reference
Version	1.0
Source	Process Decomposition (L0–L3) · Incident Management for Contact Centers · Capacity Planning Cycle

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–4 as Markdown files and upload them as project knowledge. 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).

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.

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.
   Mark unknown fields TBD explicitly. 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.

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 filled or explicitly TBD.

## 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.

Notes

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.