process-mapper

process-mapper

面向内部运营负责人的 BPMN 风格业务流程文档、瓶颈检测和周期时间分析。

目的

内部运营工作经常受到三种问题的影响：

1. 流程隐性化——步骤只存在于团队的经验知识中，因此交接会出问题，新员工也需要数周才能上手。
2. 等待不可见——任何业务流程的大部分历时都是排队、等待或审批时间，而非实际工作时间；团队因此优化了错误的环节。
3. 局部优化——忽视了 Goldratt 的约束理论；资源被投入到非约束环节，却没有任何收益。

此工具可生成流程图，找出工作等待的位置，并通过确定性逻辑明确指出约束环节，而非依赖大模型直觉。

适用场景

• 记录新的业务流程（采购受理、供应商入驻、员工入职、事件交接、费用报销、客户入驻、理赔审核）。
• 现有流程「太慢」，却没人能说清瓶颈在哪里。
• 团队在测量周期时间，却没有计算增值率，因此无法判断流程是否健康，或是否充斥浪费。
• 跨职能交接导致工作遗漏，且根本原因不明。

工作流

五步确定性流程：

1. 收集信息。 将流程保存为 JSON 文件，每个阶段包含一条记录：name、owner、type（value-add | wait | rework）、duration_minutes_p50、duration_minutes_p90。使用 assets/process_template.md 及其中的 JSON 框架。
2. 绘制阶段图。 运行 process_documenter.py，生成 ASCII 泳道图和规范化的 JSON 文件。泳道按负责人划分，让跨职能交接一目了然。
3. 测量周期时间。 运行 cycle_time_analyzer.py，计算总 P50、总 P90、增值率（VA%）和 Little 定律的吞吐量估算。判定标准：VA% > 25% = 健康，10–25% = 典型，< 10% = 浪费严重。
4. 检测瓶颈。 使用适当的 --profile（saas / services / manufacturing / healthcare）运行 bottleneck_detector.py。输出按优先级排序的清单，包含严重程度（CRITICAL / HIGH / MEDIUM）、根因假设，以及每项发现的一条建议措施。
5. 提出建议。 综合瓶颈清单与周期时间判定结果，依据 Goldratt 的「让一切服从约束」原则，建议一项专注于约束环节的干预措施。不要建议优化非约束环节。

脚本

scripts/process_documenter.py — 读取并验证流程 JSON，然后以 Markdown 输出基于文本的 BPMN 风格泳道图（按负责人划分泳道，阶段标注类型和时长）。同时输出供下游工具使用的规范化 JSON 文件。仅使用标准库。--sample 会打印一个包含 6 个阶段的采购受理示例。

scripts/bottleneck_detector.py — 应用三条确定性检测规则：(a) 阶段 P50 > 增值阶段平均值的 2 倍；(b) 等待状态占总周期的比例 > 40%；(c) 返工占比 > 15%。由于 SaaS、服务业、制造业和医疗保健领域的「正常」等待比例各不相同，阈值会根据 --profile 调整。输出按优先级排序的清单，包含严重程度、假设和措施。

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

快速示例

# Renders a BPMN-style swim-lane diagram + normalized JSON for the built-in 6-stage procurement-intake example
cd business-operations/skills/process-mapper && python3 scripts/process_documenter.py --sample

参考资料

• references/lean_six_sigma_canon.md — TIMWOOD 浪费、价值流图、约束理论、看板 WIP、利特尔法则。引用 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 和流程挖掘研究中总结的七种具体反模式。

假设

1. 用户可以提供各阶段的周期时间数据（即使只是粗略的 P50 / P90 估算）。如果无法提供，第一步应是为流程添加监测，而不是绘制流程图。
2. 此处的“流程”指包含明确阶段、可重复执行的业务工作流，而非一次性项目。
3. 用户有权处理瓶颈（或者可以将发现的问题提交给有权处理的人）。否则，输出就只是学术研究。
4. 阶段的 type 应如实填写：用户标记为“增值”的阶段，确实会从客户的角度改变工作产出。把等待误标为增值，是最常见的数据质量问题。

反模式

• 一次性绘制所有流程。 选一个。Goldratt：约束只有一个。
• 优化非约束环节。 如果第 4 阶段是瓶颈，加快第 2 阶段只会在第 4 阶段前堆积库存。所有环节都应服从约束。
• 将总周期时间误认为处理时间。 二者几乎从不相同；VA% 能揭示差距。
• 给受等待限制的流程增加人员。 增加人手无法解决等待问题；只有消除交接或批处理才能解决。
• 将返工视为独立问题。 返工循环应纳入流程图。隐藏返工会低估真实周期时间。

与以下内容不同

• business-growth skills — 外部销售流程、潜在客户漏斗转化、客户成功留存。Process-mapper 面向内部运营。
• engineering/slo-architect — 系统可靠性 SLO / 错误预算 / 消耗速率告警。Process-mapper 关注的是业务流程周期时间，而非系统正常运行时间。
• c-level-advisor (COO / CEO) — 从战略层面确定要改进哪些流程。Process-mapper 是完成该优先级决策后使用的战术工具。
• project-management skills — Jira / Confluence 工单工作流工具。Process-mapper 关注流程设计，而非工单跟踪。

强制提问库（Matt Pocock 式追问训练）

在调用工具之前，协调器（或 /cs-grill-bizops）会逐一向用户提出以下问题，并为每个问题提供推荐答案和权威来源引用。切勿将问题打包提出。

1. “你有最长的 3 个阶段的实测周期时间，还是只有估算值？” 推荐：坚持使用实测数据。 权威来源：Goldratt 1984（《The Goal》）——基于估算值优化瓶颈，往往会持续针对错误的约束下手。

2. “你要梳理的是当前流程（现状），还是计划中的流程（目标状态）？” 推荐：先梳理现状。识别出瓶颈后再梳理目标状态。 权威来源：Rother & Shook 1999（《Learning to See》）——价值流图始终从当前状态开始。

3. “团队之间的交接发生在哪里？每次交接要等待多久？” 推荐：记录每次交接及其等待时间中位数。 权威来源：Reinertsen 2009（《Principles of Product Development Flow》）——交接等待时间是最大的隐性成本。

4. “每个阶段的批量大小是多少？” 推荐：尽可能将批量大小降至 1。 权威来源：Anderson 2010（《Kanban》）——批量大小与周期时间方差 1:1 相关。

5. “每个阶段的返工率是多少？” 推荐：明确列出返工率；返工循环应纳入流程图。 权威来源：Pyzdek（《Six Sigma Handbook》）——隐性返工会使服务流程的总周期时间增加 30-50%。

按深度优先的顺序推进。问题 1-3 尚未回答前，不要提出问题 4。全部 5 个问题确认后，依次调用 process_documenter.py → bottleneck_detector.py → cycle_time_analyzer.py。