流程映射工具
process-mapper
为内部运营负责人提供 BPMN 风格的业务流程文档记录、瓶颈检测和周期时间分析。
目的
内部运营工作通常面临三种重复出现的失效模式：
1. 隐性流程 —— 步骤仅存在于口头传承的经验中，导致移交环节出现遗漏，入职培训耗时数周。
2. 不可见的等待 —— 任何业务流程的大部分耗时都花在队列/等待/审批上，而非实际工作；团队往往优化了错误的阶段。
3. 局部优化 —— 忽略了 Goldratt 的约束理论；在非约束阶段增加资源，却无法获得整体提升。
本技能可生成记录在案的流程图，识别工作等待点，并利用确定性逻辑（而非 LLM 的直觉）明确指出约束点。
使用场景
- 记录新的业务流程（采购申请、供应商入职、员工入职、事件移交、费用报销、客户入职、理赔裁定）。
- 现有流程“太慢”，但没人能指出瓶颈所在。
- 正在衡量周期时间，但未衡量增值比，导致团队无法判断流程是健康的还是充满浪费的。
- 跨职能移交出现工作丢失，且根因不明。
工作流
五个确定性步骤：
1. 采集 (Intake)。将流程捕获为 JSON 文件，每个阶段为一个条目：包含 name（名称）、owner（负责人）、type（类型：value-add 增值 | wait 等待 | rework 返工）、duration_minutes_p50（P50 耗时/分钟）、duration_minutes_p90（P90 耗时/分钟）。使用 assets/process_template.md 及其 JSON 骨架。
2. 映射阶段 (Map stages)。运行 process_documenter.py 生成 ASCII 泳道图 + 标准化 JSON 产出物。泳道图按负责人区分，使跨职能移交变得可见。
3. 衡量周期时间 (Measure cycle time)。运行 cycle_time_analyzer.py 计算总 P50、总 P90、增值比 (VA%) 以及基于利特尔法则 (Little's Law) 的吞吐量预估。判定标准：VA% > 25% = 健康 (HEALTHY)，10–25% = 典型 (TYPICAL)，< 10% = 浪费严重 (WASTE-HEAVY)。
4. 检测瓶颈 (Detect bottlenecks)。运行 bottleneck_detector.py 并指定相应的 --profile（saas / services / manufacturing / healthcare）。输出为排序列表，包含严重程度（CRITICAL / HIGH / MEDIUM）、根因假设以及针对每项发现的一项建议行动。
5. 给出建议 (Recommend)。将瓶颈列表与周期时间判定相结合；根据 Goldratt 的“所有环节均服从于约束”原则，针对每个约束点建议一项单一的干预措施。
不要建议优化非瓶颈阶段。
脚本
scripts/process_documenter.py — 读取流程 JSON 文件，进行验证，并以 Markdown 格式输出基于文本的 BPMN 风格泳道图（按所有者分泳道，阶段标注类型 + 持续时间）。同时输出一个用于下游工具的标准化 JSON 产物。仅使用标准库。--sample 参数可打印一个包含 6 个阶段的采购申请示例。
scripts/bottleneck_detector.py — 应用三条确定性检测规则：(a) 阶段 P50 > 增值阶段平均值的 2 倍，(b) 等待状态占比 > 总周期的 40%，(c) 返工占比 > 15%。阈值可通过 --profile 调整，因为 SaaS、服务业、制造业和医疗业的“正常”等待比率各不相同。输出为包含严重程度、假设和行动方案的排序列表。
scripts/cycle_time_analyzer.py — 计算总 P50 和 P90 周期时间、增值比 (VA%)、等待比、返工比，以及基于利特尔法则 (Little's Law) 的吞吐量估算 (WIP / 周期时间)。根据精益准则：VA% > 25% = 健康，10–25% = 典型（大多数非制造流程处于此区间），< 10% = 浪费严重。
快速示例
# 为内置的 6 阶段采购申请示例渲染 BPMN 风格泳道图 + 标准化 JSON
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 架构) — 系统可靠性 SLO / 错误预算 / 消耗率告警。Process-mapper 关注的是*业务流程*周期时间，而非系统可用时间。
- c-level-
- 项目管理技能 —— Jira / Confluence 工单工作流工具。流程映射器负责的是流程*设计*，而非工单*追踪*。
强制性问题库 (Matt Pocock 质询法)
在调用工具之前，编排者（或 /cs:grill-bizops）需引导用户逐一回答以下问题，每次仅提出一个问题，并提供建议答案 + 权威引用。严禁打包提问。
1. “对于前三个耗时最长的阶段，你拥有的是实测的周期时间（cycle times），还是仅为估算值？”
建议：坚持要求实测数据。
权威引用：Goldratt 1984 (*The Goal*) —— 优化基于估算的瓶颈往往会误触错误的约束条件。
2. **“你正在映射的是*当前*流程 (as-is) 还是*预期*流程 (to-be)？”**
建议：先映射 as-is。在识别出瓶颈后再设计 to-be。
权威引用：Rother & Shook 1999 (*Learning to See*) —— 价值流映射必须始终从当前状态开始。
3. “团队之间的交接点在哪里？每次交接的等待时间是多少？”
建议：记录每个交接点及其等待时间的中位数。
权威引用：Reinertsen 2009 (*Principles of Product Development Flow*) —— 交接时的等待时间是最大的隐形成本。
4. “每个阶段的批次大小 (batch size) 是多少？”
建议：尽可能将批次大小推向 1。
权威引用：Anderson 2010 (*Kanban*) —— 批次大小与周期时间的波动呈 1:1 正相关。
5. “每个阶段的返工率 (rework rate) 是多少？”
建议：明确将其显现化；返工循环应包含在映射图中。
权威引用：Pyzdek (*Six Sigma Handbook*) —— 在服务流程中，隐藏的返工占据了总周期时间的 30-50%。
采用深度优先引导。在问题 1-3 得到解答前，不要提出问题 4。在所有 5 个问题全部确认后，依次调用 process_documenter.py $\rightarrow$ bottleneck_detector.py $\rightarrow$ cycle_time_analyzer.py。
