流程瓶颈体检

给一条流程的运行数据做一次体检：先算清楚它到底慢在哪，再把它最容易出问题的地方逐条列出来。

与「流程文档检查」不同，本工具面向流程跑起来之后的实测数据——处理耗时、等待时间、返工次数、交接次数、周期波动、在制品（WIP）等。用确定性规则做三件事：

1. 周期分析：总周期时间（lead time）、处理时间（touch time）、等待时间、处理效率（touch ÷ lead）与各步骤占比；
2. 瓶颈识别：单步骤处理耗时占比过高、等待远大于处理、定位约束点（约束理论 TOC 思路）；
3. 流程质量：返工、交接、审批层级、串行/并行、负责人、时限（SLA）、重复步骤、周期波动、WIP 堆积、基线/度量与持续改进机制。

输出是一份可定位、分严重度的问题清单（F1–F18）+ 周期统计 + 评分结论——是规则，不是感觉。交付物 = 流程瓶颈报告 + 改进建议。

何时使用

• 某条流程「太慢」但说不清卡在哪，需要先用数据把瓶颈步骤指出来。
• 拿到了流程的运行记录（每步的处理耗时、等待时间、返工次数、交接、在制品等），想做一轮结构化体检。
• 流程优化 / 上会 / 系统化立项之前，先量化当前基线、定位约束点。
• 想比较几条流程或同一流程的前后变化（用评分与指标横向对比）。

不适用：需要精确排队仿真的产能测算（请用「座席与人力测算」）；项目型/创造性工作的工时估算；单次性临时任务；纯文档规范性检查（请用「业务流程检查·瓶颈与等待」process-lint）。

怎么用

python3 scripts/workflow_bottleneck_lint.py --file 流程数据.csv
python3 scripts/workflow_bottleneck_lint.py --file 流程数据.csv --json
python3 scripts/workflow_bottleneck_lint.py --file 流程数据.json
python3 scripts/workflow_bottleneck_lint.py --sample     # 内置「问题流程」样例，F1–F18 全覆盖

• 退出码：0 = 未发现问题；1 = 发现问题（或输入 / 用法错误）。
• 常用可调阈值（均可按业务口径覆盖）：--bottleneck-ratio（默认 0.30）、--wait-share（0.50）、--touch-min（0.25）、--rework-ratio（0.15）、--handoff-max（4）、--approval-max（3）、--serial-max（8）、--max-steps（12）、--manual-ratio（0.50）、--variance-ratio（1.5）、--wip-max（5）、--sla-coverage（0.50）。

输入格式

CSV（首行为表头，列名可自动识别）

列名无需与下表完全一致，只要包含候选关键词即可（按最长匹配消歧）；列顺序不限，大小写、空格差异兼容。

时长写法：裸数字按分钟；支持 30分钟、45min、1.5小时、2h、1天（=1440 分钟）、1周。

流程元数据（可选）：以 # 开头的行会被当作流程级元数据（# 键: 值），用于基线（F15）与持续改进（F18）判定，例如：

# 流程名称: 客户开通（高效流程）
# 基线周期(分钟): 480
# 复盘与改进: 每季度 PDCA 复盘
步骤序号,步骤名称,负责角色,处理耗时,等待时间,返工次数,是否审批,是否并行,是否手动,耗时p90,时限
1,受理申请,受理岗,30,5,0,否,否,否,34,1小时
2,资料校验,审核岗,30,5,0,否,否,否,33,1小时

JSON（等价写法）

{
  "process_name": "客户开通",
  "baseline_cycle_minutes": 480,
  "improvement": "每季度复盘 PDCA",
  "steps": [
    {"name": "受理申请", "owner": "受理岗", "touch": 30, "wait": 5,
     "rework": 0, "approval": false, "parallel": false, "manual": false,
     "p90": 34, "sla": "1小时"}
  ]
}

规则码表

> 规则是启发式的：命中只代表「可能有问题」，需结合业务判断。

输出指标说明

• 总周期时间（lead time） = 处理时间合计 + 等待时间合计；无法解析的时长不参与统计（会被 F13 单独点名）。
• 处理效率（touch / lead） = 处理时间合计 ÷ 总周期时间；越低说明时间越多花在等待上，这是「该优化哪里」的第一判断。
• 瓶颈步骤 = 处理耗时占比最高的步骤（TOC 约束点）。只优化瓶颈，别优化非瓶颈——加速非瓶颈只会让它在瓶颈前堆积。
• 交接：优先用「交接次数」列；无该列时按「相邻步骤负责人是否变更」推断。
• 周期波动：用「耗时 p90」与「处理耗时」之和的比值衡量；无 p90 数据时该项不参与判定。

输出示例（节选）

=== 流程瓶颈体检报告 ===

流程：报销审批（演示）　｜　文件：流程数据.csv
步骤数：13

—— 周期分析 ——
总周期时间（lead time）：9685 分钟（约 161.4 小时）
处理时间合计（touch time）：325 分钟（约 5.4 小时）
等待时间合计：9360 分钟（约 156.0 小时）
处理效率（touch / lead）：3.4%
瓶颈步骤：第 12 行「补正材料」处理 200 分钟（约 3.3 小时），占处理时间 62%（TOC 约束点）
最长等待：第 12 行，等待 2880 分钟（约 48.0 小时）

问题合计 19 项：高 7 · 中 8 · 低 4
评分：0/100　结论：较差

—— 高风险（7 项）——
【高】[F1] 瓶颈步骤未识别　（定位：第 12 行「补正材料」 / 处理耗时字段）
    · 说明：第 12 行「补正材料」处理 200 分钟（约 3.3 小时），占全部处理耗时的 62%，
            超过阈值 30%——这是明确的约束点，需优先处理。
    · 建议：先用测量数据定位约束点：补齐处理耗时；对占比过高的步骤做拆分、并行或消除上游积压……
【高】[F2] 等待占比过高　（定位：整个流程 / 等待时间字段）
    · 说明：等待时间合计 9360 分钟，占总周期时间的 97%，超过阈值 50%。
    · 建议：压缩等待：并行化审批、设 WIP 上限、把前置条件就绪后再进入下游……

加 --json 输出结构化结果（含 metrics、counts、score、verdict、findings），便于二次处理与接入 CI。

评分口径

得分 = max(0, 100 − (高风险×15 + 中风险×5 + 低风险×2))。

分数只是相对参考，用于横向比较不同流程或同一流程的前后变化，不代表流程的真实健康度。

与 process-lint（办公效率）的差异

两个工具都叫「流程/瓶颈」相关，但看的对象不同，建议配合使用：

一句话：先用 process-lint 把流程「写规范」，再用本包把它「跑顺」——前者查文档，后者查数据。二者规则码、判据、输入侧重均不重叠。

边界与免责

• 只做基于运行数据的静态规则检查：不仿真排队、不预测吞吐、不做因果归因；结论完全取决于用户填写的数值。
• 阈值是通用经验值，不同业务差异大，请用上面列出的命令行参数按需调整。
• 「处理效率」把全部处理耗时视为增值时间，与精益里严格的「客户愿意付费」定义略有差异；本工具用于快速体检，不替代价值流分析的细致判断。
• 规则命中不等于错误，只是提示；最终以业务判断为准。样例为构造的演示数据，人名与流程均为虚构。

安全与合规

• 纯标准库 Python，只读输入文件，不写文件、无网络请求、无凭据读取、无 subprocess / eval / exec / os.system；输入按 UTF-8（含 BOM）读取。
• 本包为开源改编作品，来源与改动见 来源与许可.md，遵守 MIT 许可证（LICENSE.md）。

上游署名

本技能改编自开源项目 alirezarezvani/claude-skills 的 business-operations/skills/process-mapper/（作者 Alireza Rezvani，MIT License，Copyright © 2025）。上游 HEAD：19392f7a08264ed00486a251f5b2098321771f94，获取日期 2026-10-11。本包代码完全重写（三脚本整合为一），详见 来源与许可.md。

依赖

仅需 Python 3.8+（代码兼容 3.8+ 写法），全部使用标准库，无需联网、无需安装第三方包。