业务流程检查·瓶颈与等待
把一张「流程步骤表」当成体检单：在优化流程之前，先看清楚它是不是要素齐、等待少、能追溯。
本技能读一份流程步骤表 CSV，用确定性规则做三件事：
- 算流程时长：总处理时长、总等待时长、增值时间比（处理时长 ÷ 总周期时长）；
- 找瓶颈：处理时长占比最高的步骤、等待时间最长的步骤；
- 查结构：由「依赖步骤」列构图，检测依赖成环。
输出是一份可定位、分严重度的问题清单（P1–P13）+ 统计 + 结论——是规则，不是感觉。
执行原则
- 先算账再找瓶颈。 用脚本统计总处理/等待时长与增值时间比，指出瓶颈步骤与最长等待；不要用肉眼扫表后凭印象说「这里慢」。
- 列名自动识别。 靠候选关键词匹配列角色，未识别到步骤名称列就报错说明；不要手工改写用户的 CSV 去迁就脚本。
- 阈值按需调整。
--bottleneck-ratio/--manual-ratio/--approval-max/--value-ratio按业务调完再下结论；不要把默认经验值当成通用标准。 - 只报不改。 输出分级清单与建议，规则命中只是提示；不要替用户决定砍哪个环节，也不做排队仿真与吞吐预测。
何时使用
CRITICAL: 只要用户要盘一条业务流程、找瓶颈，或判断流程步骤表要素是否齐备，就必须使用本 skill，即使看起来可以用别的方式解决。
- 用户要「盘一条流程」：采购申请、入职办理、工单流转、报销审批、开票对账、客户开户等业务闭环。
- 觉得某条流程「太慢」但说不清卡在哪，需要先把瓶颈和等待指出来。
- 上会/优化/系统化之前，先给流程文件做一次结构化自查（要素缺不缺、有没有异常分支、审批是不是太多）。
- 想把口头描述或零散的表格整理成可被检查、可被评审的流程清单。
不适用：需要精确仿真排队的产能测算（请用「座席与人力测算」）；项目型/创造性工作的工时估算；单次性的临时任务。
何时不该使用
| ✅ 使用 | ❌ 不用（改用什么） |
|---|---|
| 有一张流程步骤表 CSV，要做体检 | 要精确仿真排队与产能测算——用 capacity-plan（座席与人力测算） |
| 找瓶颈步骤、最长等待、依赖成环 | 要检查运维手册步骤可执行性——用 runbook-lint |
| 上会前给流程文件做结构化自查 | 要排班与工时合规检查——用 roster-lint |
| 算增值时间比，判断等待占比 | 要判断流程背后的组织决策对错——只报事实与建议 |
| 按阈值调参后的静态规则检查 | 项目型/创造性工作的工时估算——不适用 |
易混淆场景
| 用户说的 | 实际意图 | 正确路由 |
|---|---|---|
| 「流程太慢了，帮我看看」 | 要定位卡点 | 先算时长与增值比，先说瓶颈与最长等待 |
| 「这张表对不对」 | 要要素自查 | 跑脚本，按 P1–P13 报清单 |
| 「要不要砍掉这一步」 | 要决策建议 | 只给数据与提示，不替用户拍板 |
| 「加了人会不会快」 | 要产能测算 | 说明不做仿真，转 capacity-plan |
| 「审批太多了吧」 | 要审批层级判断 | 报 P8 并给出层级数，由业务定 |
怎么用
python3 scripts/process_lint.py 流程步骤表.csv
python3 scripts/process_lint.py 流程步骤表.csv --bottleneck-ratio 0.4 --manual-ratio 0.6
python3 scripts/process_lint.py 流程步骤表.csv --json
python3 scripts/process_lint.py --sample # 内置「问题流程」样例，P1–P13 全部命中
python3 scripts/process_lint.py --clean # 内置「规范流程」样例，应 0 问题
可调阈值：--bottleneck-ratio（默认 0.35）、--manual-ratio（默认 0.50）、--approval-max（默认 3）、--value-ratio（默认 0.10）。
输入格式
UTF-8（兼容带 BOM）的 CSV，第一行是表头。列名可自动识别，无需与下表完全一致，只要包含候选关键词即可（按最长匹配消歧）：
| 列角色 | 候选列名关键词 | 说明 |
|---|---|---|
| 步骤序号 | 步骤序号 / 步骤编号 / 编号 / 序号 | 可选，用于依赖列按序号引用 |
| 步骤名称 | 步骤名称 / 环节名称 / 步骤 / 环节 / 活动 / 任务 | 必需 |
| 负责角色 | 负责角色 / 负责岗位 / 负责人 / 角色 / 岗位 | |
| 输入 | 输入 / 投入 | |
| 输出物 | 输出物 / 输出 / 产出 / 交付物 / 成果 | |
| 处理时长 | 处理时长 / 处理时间 / 作业时长 / 时长 | 数字，可带单位 |
| 等待时长 | 等待时长 / 等待时间 / 排队时长 | 数字，可带单位 |
| 使用系统 | 使用系统 / 系统 / 工具 / 平台 | |
| 是否手动 | 是否手动 / 手动 / 人工 | 是/否、y/n、true/false |
| 是否审批 | 是否审批 / 审批环节 / 审批 | 是/否 等 |
| 异常分支 | 异常分支 / 退回分支 / 退回 / 异常 | 有内容即视为存在异常路径 |
| 依赖步骤 | 依赖步骤 / 前置步骤 / 依赖 / 前置 | 可用序号或名称，多个用「、，;/ 」分隔 |
| 时限（SLA） | 时限 / 时效 / 目标时长 / 服务承诺 / SLA | 用于 P9 判断是否约定了时限 |
时长写法：裸数字按分钟；支持 30分钟、45min、1.5小时、2h、1天（=1440 分钟）、1周。单元格里出现多个数值时取第一个（含单位）。
示例：
步骤序号,步骤名称,负责角色,输入,输出物,处理时长,等待时长,使用系统,是否手动,是否审批,异常分支,依赖步骤,时限
1,受理申请,受理岗,客户需求,受理单,10,5,工单系统,否,否,资料不全退回,,4小时
2,资格审核,审核岗,受理单,审核结论,20,10,工单系统,否,是,不通过退回,1,1天
规则码表
| 码 | 名称 | 触发条件 | 严重度 |
|---|---|---|---|
| P1 | NO_OWNER | 步骤无负责角色 | 中 |
| P2 | NO_OUTPUT | 步骤无输出物 | 中 |
| P3 | NO_INPUT | 非起点（有前置依赖）步骤无输入 | 低 |
| P4 | LONG_WAIT | 等待时长 > 处理时长（排队积压） | 低 / 中 |
| P5 | BOTTLENECK | 单步骤处理时长占全流程比例 > 阈值 | 中 / 高 |
| P6 | NO_EXCEPTION_PATH | 全流程无任何异常/退回分支 | 中 |
| P7 | MANUAL_HEAVY | 手动步骤占比 > 阈值 | 中 / 高 |
| P8 | APPROVAL_LAYERS | 审批环节数 > --approval-max |
中 / 高 |
| P9 | NO_SLA | 无时限（SLA/时限）列或全部为空 | 中 |
| P10 | DEP_CYCLE | 「依赖步骤」构成循环依赖 | 高（悬空依赖为低） |
| P11 | VAGUE_STEP | 步骤名空泛（「处理」「跟进一下」等，或单字） | 低 |
| P12 | TIME_MISSING | 时长缺失、非数字，或未识别到处理时长列 | 中 / 高 |
| P13 | LOW_VALUE_ADDED_RATIO | 增值时间比 < --value-ratio |
中 |
输出指标说明
- 总处理时长 / 总等待时长 / 总周期时长：总周期时长 = 总处理时长 + 总等待时长；无法解析的时长不参与统计（会被 P12 单独点名）。
- 增值时间比（VA%）：处理时长 ÷ 总周期时长。办公类流程普遍偏低，越低说明时间越多花在等待与搬运上；这是「该优化哪里」的第一判断。
- 瓶颈步骤：处理时长占全流程处理时长比例最高者，超过阈值即报 P5。只优化瓶颈，别优化非瓶颈——加速非瓶颈步骤只会让它在瓶颈前堆积。
- 最长等待：等待时长最大的步骤，是消除积压时最该先动的地方。
- 依赖成环：由「依赖步骤」列构图，出现环即 P10（高）——环意味着流程没有唯一执行顺序；引用了不存在步骤则报同码低严重度提示。
输出示例
=== 业务流程体检报告 ===
步骤数：10 ｜ 识别到的列：步骤序号、步骤名称、负责角色、输入、输出物、处理时长、等待时长……
—— 流程时长统计 ——
总处理时长：335 分钟（约 5.6 小时）
总等待时长：3600 分钟（约 60.0 小时）
总周期时长：3935 分钟（约 65.6 小时）
增值时间比：8.5%（处理时长 ÷ 总周期时长）
瓶颈步骤：第 3 行「处理」处理 180 分钟（约 3.0 小时），占处理时长 54%
最长等待：第 6 行「财务复核」等待 1800 分钟（约 30.0 小时）
问题合计 16 项：高 2 · 中 11 · 低 3
结论：存在高风险问题，建议优先整改
—— 高风险 ——
[P5] 瓶颈步骤：第 3 行「处理」占全流程处理时长 54%
· 说明：该步骤处理 180 分钟……超过阈值 35%
· 建议：聚焦约束点：拆分该步骤、并行处理或消除其上游积压……
[P10] 依赖成环：复核确认 → 补正 → 复核确认（第 10 行）
· 说明：步骤之间存在循环依赖，正常流程无法确定唯一执行顺序
· 建议：打破环：明确其中一个步骤为起点，或把循环依赖改为并行/迭代回路并明确退出条件
加 --json 输出结构化结果（含 issues、counts、verdict、metrics），便于二次处理。
退出码：0 = 未发现高风险项；1 = 存在高风险项，或输入错误（文件为空/只有表头/无法读取/未识别到步骤名称列）。
交付约定
- 先跑脚本拿结果，原样引用其中的增值时间比、瓶颈步骤与问题条数，不要凭印象补写。
- 交付三段：结论（问题条数 + 主瓶颈）→ 分级清单 → 时长统计表。
- 报告短板而不仅列问题：优先说「瓶颈在哪、等待最大在哪」，再谈补字段这类要素问题。
- 只报事实与建议，不替用户做「该不该砍流程」的经营决策。
边界与免责
- 只做基于步骤表的静态检查：不仿真排队、不预测吞吐、不做因果归因；时长口径完全取决于用户填写的数值。
- 阈值是通用经验值，不同业务差异大，请用
--bottleneck-ratio/--manual-ratio/--approval-max/--value-ratio按需调整。 - 「增值时间比」把全部处理时长视为增值时间，与精益里严格的「客户愿意付费」定义略有差异；本技能用于快速体检，不替代价值流分析的细致判断。
- 规则命中不等于错误，只是提示；最终以业务判断为准。
安全与合规说明
- 脚本只读输入 CSV，不写文件、无网络请求、无凭据读取、无
subprocess/eval/exec/os.system。 - 本包为开源改编作品，来源与改动见
来源与许可.md，遵守 MIT 许可证（LICENSE.md）。
依赖
仅需 Python 3.12+（代码兼容 3.8+ 写法），全部使用标准库，无需联网、无需安装第三方包。
