process-mapper

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

process-mapper

BPMN-style business process documentation, bottleneck detection, and cycle-time analysis for internal-operations leaders.

BPMN风格的业务流程文档、瓶颈检测及周期时间分析工具，专为内部运营负责人打造。

Purpose

用途

Internal-operations work suffers from three recurring failure modes:

Implicit process — the steps exist only in tribal knowledge, so handoffs drop and onboarding takes weeks.
Invisible waiting — most of the elapsed time on any business process is queue / wait / approval time, not actual work; teams optimize the wrong stage.
Local optimization — Goldratt's Theory of Constraints is ignored; resources are added to non-constraint stages, gaining nothing.

This skill produces a documented process map, identifies where work waits, and points the constraint out by name with deterministic logic — not LLM intuition.

内部运营工作存在三个常见的失效模式：

隐性流程——流程步骤仅存在于员工的经验性隐性知识中，导致交接遗漏，新员工入职耗时数周。
隐形等待——任何业务流程的大部分耗时都用于排队/等待/审批，而非实际工作；团队往往优化了错误的环节。
局部优化——忽略了Goldratt的约束理论，在非约束环节增加资源，却毫无收益。

本工具可生成标准化的流程地图，识别工作等待的环节，并通过确定性逻辑而非大语言模型直觉明确指出约束环节。

When to use

使用场景

Documenting a new business process (procurement intake, vendor onboarding, employee onboarding, incident handoff, expense reimbursement, customer onboarding, claims adjudication).
An existing process is "too slow" but nobody can name the bottleneck.
Cycle time is being measured but value-add ratio is not — so the team can't tell whether the process is healthy or waste-heavy.
Cross-functional handoffs are dropping work and root cause is unclear.

记录新的业务流程（采购申请、供应商入职、员工入职、事件交接、费用报销、客户入职、理赔审核）。
现有流程“太慢”但无人能指出瓶颈所在。
已在测量周期时间，但未计算增值比——导致团队无法判断流程是否健康或存在大量浪费。
跨职能交接时出现工作遗漏，且根因不明。

Workflow

工作流程

Five-step deterministic flow:

Intake. Capture the process as a JSON file with one entry per stage:
```
name
```
,
```
owner
```
,
```
type
```
(
```
value-add
```
|
```
wait
```
|
```
rework
```
),
```
duration_minutes_p50
```
,
```
duration_minutes_p90
```
. Use
```
assets/process_template.md
```
and its JSON skeleton.
Map stages. Run
```
process_documenter.py
```
to produce an ASCII swim-lane diagram + a normalized JSON artifact. The swim-lane separates lanes by owner so cross-functional handoffs become visible.
Measure cycle time. Run
```
cycle_time_analyzer.py
```
to compute total P50, total P90, value-add ratio (VA%), and a Little's-Law throughput estimate. Verdict: VA% > 25% = HEALTHY, 10–25% = TYPICAL, < 10% = WASTE-HEAVY.
Detect bottlenecks. Run
```
bottleneck_detector.py
```
with the appropriate
```
--profile
```
(saas / services / manufacturing / healthcare). Output is a ranked list with severity (CRITICAL / HIGH / MEDIUM), root-cause hypothesis, and one recommended action per finding.
Recommend. Pair the bottleneck list with the cycle-time verdict; recommend a single constraint-focused intervention per Goldratt's "subordinate everything to the constraint" rule. Don't recommend optimization of a non-constraint stage.

五步确定性流程：

信息收集：将流程以JSON文件形式记录，每个环节包含以下字段：
```
name
```
（名称）、
```
owner
```
（负责人）、
```
type
```
（类型：
```
value-add
```
|
```
wait
```
|
```
rework
```
）、
```
duration_minutes_p50
```
（P50耗时，分钟）、
```
duration_minutes_p90
```
（P90耗时，分钟）。可使用
```
assets/process_template.md
```
及其JSON框架。
环节映射：运行
```
process_documenter.py
```
生成ASCII泳道图+标准化JSON产物。泳道按负责人划分，跨职能交接环节一目了然。
周期时间测量：运行
```
cycle_time_analyzer.py
```
计算总P50、总P90、增值比（VA%）以及基于Little定律的吞吐量估算。判定标准：VA% >25%=健康，10–25%=正常，<10%=严重浪费。
瓶颈检测：运行
```
bottleneck_detector.py
```
并指定合适的
```
--profile
```
参数（saas / services / manufacturing / healthcare）。输出为排序后的列表，包含严重程度（CRITICAL / HIGH / MEDIUM）、根因假设及每个发现对应的建议行动。
优化建议：结合瓶颈列表与周期时间判定结果，根据Goldratt的“所有环节服从约束环节”原则，仅推荐针对约束环节的干预措施。不得建议优化非约束环节。

Scripts

脚本说明

scripts/process_documenter.py
— Reads a process JSON, validates it, and emits a text-based BPMN-style swim-lane diagram in Markdown (lanes by owner, stages annotated with type + duration). Also outputs a normalized JSON artifact for downstream tools. Stdlib only.

--sample

prints a 6-stage procurement-intake example.

scripts/bottleneck_detector.py
— Applies three deterministic detection rules: (a) stage P50 > 2× mean of value-add stages, (b) wait-state % > 40% of total cycle, (c) rework % > 15%. Thresholds adjust by

--profile

because SaaS, services, manufacturing, and healthcare have different "normal" wait ratios. Output is a ranked list with severity, hypothesis, action.

scripts/cycle_time_analyzer.py
— Computes total P50 and P90 cycle time, value-add ratio (VA%), wait %, rework %, and a Little's-Law throughput estimate (WIP / cycle time). Per Lean canon: VA% > 25% = HEALTHY, 10–25% = TYPICAL (most non-manufacturing processes land here), < 10% = WASTE-HEAVY.

scripts/process_documenter.py
——读取流程JSON文件并验证，输出Markdown格式的文本化BPMN风格泳道图（按负责人划分泳道，环节标注类型+耗时）。同时输出标准化JSON产物供下游工具使用。仅依赖Python标准库。使用

--sample

参数可打印包含6个环节的采购申请示例。

scripts/bottleneck_detector.py
——应用三项确定性检测规则：(a)环节P50耗时>增值环节平均耗时的2倍；(b)等待状态占总周期的比例>40%；(c)返工占比>15%。阈值会根据

--profile

参数调整，因为SaaS、服务、制造和医疗行业的“正常”等待比例不同。输出为排序后的列表，包含严重程度、假设及行动建议。

scripts/cycle_time_analyzer.py
——计算总P50和P90周期时间、增值比（VA%）、等待占比、返工占比，以及基于Little定律的吞吐量估算（WIP / 周期时间）。根据Lean理论：VA% >25%=健康，10–25%=正常（大多数非制造流程处于此区间），<10%=严重浪费。

References

参考资料

```
references/lean_six_sigma_canon.md
```
— TIMWOOD wastes, value-stream mapping, Theory of Constraints, Kanban WIP, Little's Law. Cites Womack & Jones, Rother & Shook, Goldratt, Ohno, Liker, Pyzdek, Anderson.
```
references/bpmn_essentials.md
```
— Pools, lanes, gateways, events, message flows, common notation mistakes. Cites the OMG BPMN 2.0 spec, Silver, Allweyer, Freund/Rücker, OASIS, ISO/IEC 19510:2013.
```
references/bottleneck_anti_patterns.md
```
— Seven specific anti-patterns drawn from Goldratt, Kim et al., Spear, DORA, Deming, and process-mining research.

```
references/lean_six_sigma_canon.md
```
——TIMWOOD八大浪费、价值流映射、约束理论、Kanban WIP、Little定律。引用Womack & Jones、Rother & Shook、Goldratt、Ohno、Liker、Pyzdek、Anderson的著作。
```
references/bpmn_essentials.md
```
——池、泳道、网关、事件、消息流、常见符号错误。引用OMG BPMN 2.0规范、Silver、Allweyer、Freund/Rücker、OASIS、ISO/IEC 19510:2013标准。
```
references/bottleneck_anti_patterns.md
```
——源自Goldratt、Kim等人、Spear、DORA、Deming及流程挖掘研究的7种具体反模式。

Assumptions

假设前提

The user can provide stage-level cycle-time data (even rough P50 / P90 estimates). If they cannot, the first step is to instrument the process — not to map it.
"Process" here means a repeatable business 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). Without that, the output is academic.
Stage
```
type
```
is honest: a "value-add" stage labeled as such by the user really does change the work product from the customer's perspective. Mis-labelling waiting as value-add is the most common data-quality failure.

用户能够提供环节级别的周期时间数据（即使是粗略的P50 / P90估算值）。若无法提供，第一步是为流程添加监控——而非绘制流程地图。
此处的“流程”指具有离散环节的可重复业务工作流，而非一次性项目。
用户有权针对瓶颈采取行动（或可将结果提交给有权限的人）。否则输出仅具学术价值。
环节
```
type
```
标注真实准确：用户标注为“value-add”（增值）的环节确实从客户视角改变了工作成果。将等待环节误标为增值环节是最常见的数据质量问题。

Anti-patterns

反模式

Mapping every process at once. Pick one. Goldratt: the constraint is a single point.
Optimizing the non-constraint. If stage 4 is the bottleneck, speeding up stage 2 just builds inventory in front of stage 4. Subordinate everything to the constraint.
Mistaking total cycle time for processing time. They are almost never the same; VA% reveals the gap.
Adding people to a wait-bound process. Wait time is not solved by more headcount; it's solved by removing the handoff or batch.
Treating rework as a separate problem. Rework loops belong in the process map. Hiding them understates true cycle time.

一次性绘制所有流程：只选一个流程。Goldratt指出：约束环节是单一节点。
优化非约束环节：若环节4是瓶颈，加快环节2只会在环节4前堆积工作。所有环节都需服从约束环节。
将总周期时间等同于处理时间：两者几乎从不相等；增值比可揭示其中差距。
为受等待限制的流程增加人员：等待时间无法通过增加人力解决；需消除交接环节或批量处理。
将返工视为独立问题：返工循环应纳入流程地图。隐藏返工环节会低估真实周期时间。

Distinct from

与其他工具的区别

business-growth skills — external sales motion, lead-funnel conversion, customer-success retention. Process-mapper is internal operations.
engineering/slo-architect — system-reliability SLOs / error budgets / burn-rate alerts. Process-mapper is business-process cycle time, not system uptime.
c-level-advisor (COO / CEO) — strategic prioritization of which processes to fix. Process-mapper is the tactical instrument used after that prioritization decision.
project-management skills — Jira / Confluence ticket workflow tooling. Process-mapper is process design, not ticket tracking.

业务增长类工具——面向外部的销售流程、线索漏斗转化、客户成功留存。process-mapper聚焦内部运营。
工程/SLO架构工具——系统可靠性SLOs / 错误预算 / 消耗率告警。process-mapper针对业务流程周期时间，而非系统可用性。
C级顾问（COO / CEO）工具——战略层面优先确定需优化的流程。process-mapper是该优先级决策后使用的战术工具。
项目管理工具——Jira / Confluence工单工作流工具。process-mapper是流程设计工具，而非工单跟踪工具。

Forcing-question library (Matt Pocock grill discipline)

强制问题库（Matt Pocock grill discipline）

Before invoking the tools, the orchestrator (or

/cs:grill-bizops

) walks the user through these questions one at a time, with a recommended answer + canon citation. Never bundled.

"Do you have measured cycle times for the top-3 longest stages, or only estimates?" Recommended: insist on measured data. Canon: Goldratt 1984 (The Goal) — optimizing estimated bottlenecks reliably attacks the wrong constraint.
"Are you mapping the current process (as-is) or the intended process (to-be)?" Recommended: map as-is first. To-be after bottleneck is identified. Canon: Rother & Shook 1999 (Learning to See) — value-stream mapping starts with the current state, always.
"Where do handoffs occur between teams, and how long does each handoff wait?" Recommended: log every handoff with median wait time. Canon: Reinertsen 2009 (Principles of Product Development Flow) — wait time at handoffs is the largest invisible cost.
"What's your batch size at each stage?" Recommended: drive batch size toward 1 wherever possible. Canon: Anderson 2010 (Kanban) — batch size correlates 1:1 with cycle time variance.
"What's the rework rate per stage?" Recommended: surface it explicitly; rework loops belong in the map. Canon: 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. After all 5 are locked, invoke

process_documenter.py

→

bottleneck_detector.py

→

cycle_time_analyzer.py

in sequence.

在调用工具前，协调者（或

/cs:grill-bizops

）需逐个引导用户完成以下问题，并提供推荐答案+经典理论引用。不得批量提问。

“你是否拥有前3个最长环节的实测周期时间，还是仅为估算值？” 推荐答案：坚持使用实测数据。理论引用：Goldratt 1984年著作《目标》——针对估算的瓶颈进行优化，往往会错误地攻击非约束环节。
“你正在绘制的是当前流程（现状）还是预期流程（目标态）？” 推荐答案：先绘制现状流程。确定瓶颈后再绘制目标态流程。理论引用：Rother & Shook 1999年著作《学习观察》——价值流映射始终从现状开始。
“团队之间的交接发生在哪些环节，每次交接的等待时间是多久？” 推荐答案：记录每一次交接及其中位等待时间。理论引用：Reinertsen 2009年著作《产品开发流程原则》——交接环节的等待时间是最大的隐性成本。
“每个环节的批量处理规模是多少？” 推荐答案：尽可能将批量规模降至1。理论引用：Anderson 2010年著作《Kanban》——批量规模与周期时间波动呈1:1相关。
“每个环节的返工率是多少？” 推荐答案：明确披露返工率；返工循环应纳入流程地图。理论引用：Pyzdek《六西格玛手册》——隐性返工占服务流程总周期时间的30-50%。

按深度优先原则推进。在问题1-3未回答前，不得提问问题4。所有5个问题确认后，依次调用

process_documenter.py

→

bottleneck_detector.py

→

cycle_time_analyzer.py

。