findscripter 何时使用
当一名运营负责人（BizOps/COO/流程改进 Owner）需要做以下事情时使用本技能：
- 把一条可重复的内部业务流程（采购申请、供应商/员工入职、事故交接、报销、客户开通、理赔审核等）用 BPMN 风格的泳道图文档化。
- 已知流程"太慢"但说不清瓶颈在哪一阶段。
- 已在测周期时间，却没测增值比（VA%），判断不出流程是健康还是充满浪费。
- 跨职能交接频繁掉单、根因不明。
核心洞察：办公流程的总耗时里，绝大部分是排队/等待/审批时间，而非真正在做事。瓶颈用确定性规则点名，不靠 LLM 直觉。
不该用的边界（务必先判断再决定是否调用）：
- 销售漏斗、线索转化、客户成功留存等对外增长动作 —— 本技能只管内部运营流程。
- 系统可靠性 SLO / 错误预算 / 燃尽告警 —— 那是系统正常运行时间，不是业务流程周期时间。
- 战略层面"该先修哪条流程"的优先级决策 —— 本技能是优先级定下来之后的战术执行工具。
- 一次性项目，或 Jira/Confluence 工单跟踪 —— 本技能做流程设计，不做工单追踪。
- 用户连阶段级周期数据（哪怕是粗略 P50/P90 估值）都给不出 —— 那么第一步应是去埋点测量流程，而不是画图。
步骤
确定性五步流，三个脚本仅依赖 Python 标准库：
- 录入（Intake）。 把流程写成一个 JSON 文件，每个阶段一条记录，字段：
name、owner、type（value-add|wait|rework）、duration_minutes_p50、duration_minutes_p90。顶层还需process_name与wip（在制品数量，供 Little 定律用）。 - 绘制阶段图。 运行
process_documenter.py，产出 ASCII 泳道图 + 规范化 JSON 工件。泳道按 owner 分行，跨职能交接一目了然。 - 测周期时间。 运行
cycle_time_analyzer.py，计算总 P50、总 P90、增值比 VA%、等待%、返工%，以及 Little 定律吞吐估算（WIP / 周期时间）。判定：VA% > 25% = 健康（HEALTHY）；10–25% = 典型（TYPICAL，多数非制造流程落在此区间）；< 10% = 浪费严重（WASTE-HEAVY）。 - 检测瓶颈。 运行
bottleneck_detector.py并指定--profile（saas / services / manufacturing / healthcare），产出按严重度（CRITICAL / HIGH / MEDIUM）排序的清单，每条含根因假设 + 一条推荐动作。 - 给建议。 把瓶颈清单与周期判定结合，依 Goldratt"一切服从于约束"原则，每次只推荐一个聚焦约束点的改进动作。绝不建议优化非约束阶段。
指令
模板与三脚本配套使用（先填模板的阶段表，再翻译成 JSON）：
python3 scripts/process_documenter.py --input my-process.json
python3 scripts/bottleneck_detector.py --input my-process.json --profile saas
python3 scripts/cycle_time_analyzer.py --input my-process.json --profile saas
process_documenter.py：读取并校验流程 JSON，输出 Markdown 泳道图（按 owner 分行，阶段标注 type + 时长）及下游可用的规范化 JSON。--sample可打印一个 6 阶段采购申请示例。bottleneck_detector.py的三条确定性规则：- R1： 某阶段 P50 > 2× 增值阶段均值 → 阶段瓶颈。
- R2： 等待态占总周期 > 40% → 交接瓶颈。
- R3： 返工占总周期 > 15% → 质量瓶颈。
- 阈值随
--profile调整：manufacturing 容忍的等待最少（wait≤30%、返工≤10%、倍数 1.8），services（≤50%/15%/2.5）与 healthcare（≤55%/12%/2.5）因人工/监管环节容忍更高，saas 为默认基线（≤40%/15%/2.0）。
- type 三类定义（Lean 正典）：
value-add= 从客户视角真正改变工作产物、客户愿意为之付费（多数阶段并非增值）；wait= 排队/闲置/等人，是办公流程周期膨胀的最大来源；rework= 修复上游缺陷而存在，Six Sigma 视其为上游质量问题。
示例
一条采购申请流程的典型阶段（节选 JSON）：
{
"process_name": "采购申请",
"wip": 12,
"stages": [
{"name": "提交申请", "owner": "申请人", "type": "value-add", "duration_minutes_p50": 15, "duration_minutes_p90": 30},
{"name": "等待经理审批队列", "owner": "经理", "type": "wait", "duration_minutes_p50": 480, "duration_minutes_p90": 1440},
{"name": "等待财务复核", "owner": "财务", "type": "wait", "duration_minutes_p50": 720, "duration_minutes_p90": 2880},
{"name": "返工——缺供应商 W-9", "owner": "申请人", "type": "rework", "duration_minutes_p50": 120, "duration_minutes_p90": 360}
]
}
跑下来两段 wait 合计远超处理时间，VA% 很可能落入 WASTE-HEAVY；R2 触发交接瓶颈，约束点是审批队列，建议是移除交接/取消批处理，而非给等待型流程加人。
注意事项
- 一次只映射一条流程。 Goldratt：约束是单点。同时画十条会稀释注意力。
- 不要优化非约束阶段。 若阶段 4 是瓶颈，加速阶段 2 只会在阶段 4 前堆积在制品。一切服从于约束。
- 别把总周期时间当成处理时间。 二者几乎从不相等，VA% 揭示这道鸿沟。
- 别给等待型流程加人。 等待时间不靠堆人头解决，靠移除交接或批处理。
- 别把返工当独立问题。 返工环路属于流程图的一部分；藏起来会低估真实周期时间。
- type 标注必须诚实。 把"等待"错标成"增值"是最常见的数据质量失败。
- as-is 优先。 先映射现状流程，识别瓶颈后再画 to-be 目标流程（Rother & Shook《Learning to See》）。
- 能用真实数据就别用估值。 从工单系统（Jira/ServiceNow/Zendesk）拉阶段时长；估值仅供首轮，做任何变更决策前须替换为实测值。
互见
first-principles-thinking：在质疑"流程为何如此"、拆解约束根因时配合使用。
本条采编自 alirezarezvani/claude-skills（MIT 许可）。