process-mapper

---
name: process-mapper
description: Use when documenting an end-to-end business process (procurement, onboarding, incident handoff, claims) to map stages, find bottlenecks, and measure cycle time against value-add ratio.
category: Business Operations
version: 1.0.0
tools: []
---

# process-mapper

BPMN-style business process documentation, bottleneck detection, and cycle-time analysis for internal-operations leaders (procurement, onboarding, incident handoff, claims adjudication).

## Purpose

Internal-operations work fails in three recurring ways: implicit process (steps exist only in tribal knowledge, so handoffs drop and onboarding takes weeks), invisible waiting (most elapsed time on any business process is queue/wait/approval time, not actual work, so teams optimize the wrong stage), and local optimization (Goldratt's Theory of Constraints is ignored — resources get added to non-constraint stages, gaining nothing). This skill documents the process, locates where work waits, and names the constraint by deterministic logic, not intuition.

## When to use

Documenting a new business process; an existing process is "too slow" but nobody can name the bottleneck; cycle time is measured but value-add ratio is not, so the team can't tell healthy from waste-heavy; cross-functional handoffs are dropping work.

## Methodology

1. **Intake.** Capture the process as one entry per stage: name, owner, type (value-add / wait / rework), duration P50, duration P90.
2. **Map stages.** Produce an ASCII swim-lane diagram — lanes by owner — so cross-functional handoffs become visible, plus a normalized stage list.
3. **Measure cycle time.** Compute total P50, total P90, the value-add ratio (VA%), and a Little's-Law throughput estimate (WIP / cycle time). Verdict bands: VA% > 25% = HEALTHY, 10–25% = TYPICAL, < 10% = WASTE-HEAVY.
4. **Detect bottlenecks** using three deterministic rules, adjusted by industry profile (SaaS / services / manufacturing / healthcare have different "normal" wait ratios): (a) a stage's P50 > 2× the mean of value-add stages, (b) wait-state % > 40% of total cycle, (c) rework % > 15%. Rank findings by severity (CRITICAL / HIGH / MEDIUM) with a root-cause hypothesis and one recommended action each.
5. **Recommend** a single constraint-focused intervention per Goldratt's "subordinate everything to the constraint" rule — never optimize a non-constraint stage.

## Canon

- **Lean / Six Sigma / Theory of Constraints**: TIMWOOD wastes, value-stream mapping, Kanban WIP, Little's Law — Womack & Jones, Rother & Shook, Goldratt, Ohno, Liker, Pyzdek, Anderson.
- **BPMN essentials**: pools, lanes, gateways, events, message flows — the OMG BPMN 2.0 spec, Silver, Allweyer, Freund/Rücker, OASIS, ISO/IEC 19510:2013.
- **Bottleneck anti-patterns**: seven patterns drawn from Goldratt, Kim et al., Spear, DORA, Deming, and process-mining research.

## Assumptions

The user can supply stage-level cycle-time data (even rough P50/P90 estimates) — if not, instrument the process before mapping it. "Process" means a repeatable workflow with discrete stages, not a one-off project. The user has authority to act on bottlenecks or can route findings to someone who does. Stage type is honestly labeled — mislabeling waiting as value-add is the most common data-quality failure.

## Anti-patterns

- Mapping every process at once — Goldratt: the constraint is a single point.
- Optimizing the non-constraint — speeding up stage 2 when stage 4 is the bottleneck just builds inventory in front of stage 4.
- Mistaking total cycle time for processing time — VA% reveals the gap.
- Adding headcount to a wait-bound process instead of removing the handoff or batch.
- Treating rework as separate — rework loops belong in the process map or true cycle time is understated.

## Distinct from

Business-growth skills (external sales/retention) and SLO/reliability work (system uptime) are not this skill — process-mapper is internal, business-process cycle time. It is tactical documentation, distinct from C-level strategic prioritization of which processes to fix, and distinct from ticket-tracking project-management tools.

## Forcing-question library

Before analyzing, walk the user through these one at a time, each with a recommended answer and canon citation. Never bundle them.

1. **Do you have measured cycle times for the top-3 longest stages, or only estimates?** Insist on measured data — Goldratt 1984 (*The Goal*): optimizing estimated bottlenecks reliably attacks the wrong constraint.
2. **Are you mapping the current process (as-is) or the intended process (to-be)?** Map as-is first — Rother & Shook 1999 (*Learning to See*): value-stream mapping starts with the current state, always.
3. **Where do handoffs occur between teams, and how long does each wait?** Log every handoff with median wait time — Reinertsen 2009 (*Principles of Product Development Flow*): wait time at handoffs is the largest invisible cost.
4. **What's your batch size at each stage?** Drive batch size toward 1 wherever possible — Anderson 2010 (*Kanban*): batch size correlates 1:1 with cycle-time variance.
5. **What's the rework rate per stage?** Surface it explicitly — Pyzdek (*Six Sigma Handbook*): hidden rework drives 30–50% of total cycle time in service processes.

Walk depth-first — don't open question 4 before 1–3 are answered. Once all five are locked, proceed intake → map → measure → detect → recommend.