# Bo Process Optimization

识别业务流程中的瓶颈、等待、返工和交接浪费，设计可行的改进方案与衡量计划。适用于流程效率分析或工作流重设计。

- Repository: https://github.com/TencentCloud/Octop (11420 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add TencentCloud/Octop --skill bo-process-optimization -g -a claude-code -y`
Codex: `npx skills add TencentCloud/Octop --skill bo-process-optimization -g -a codex -y`
Cursor: `npx skills add TencentCloud/Octop --skill bo-process-optimization -g -a cursor -y`
Gemini CLI: `npx skills add TencentCloud/Octop --skill bo-process-optimization -g -a gemini-cli -y`

## Description

识别业务流程中的瓶颈、等待、返工和交接浪费，设计可行的改进方案与衡量计划。适用于流程效率分析或工作流重设计。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

<!-- 已为 Octop 改编。 -->

# 流程优化

从已知等待、返工和交接现象提出可行改进。用户只要 N 条建议时，直接写 N 个编号，不要另写瓶颈清单；每条只用必要依据加一个具体动作，观察、候选解释与建议不混成现行事实。

## 候选和建议

已知小问题可直接支持小改进，不必先假定其他管理措施缺失。材料只给了某角色或环节，不说明它是唯一关口，也不说明其他环节无人检查。原因未证实时用条件式核实问题，避免肯定句藏在“可能原因”标题下。

流程先后本身不能证明问题最早何时被发现、下一角色何时获知、退回期间是否可见或有无跟踪状态。没有这些证据时，不把“登记后才发现”“接单后才知道”写成现状；如确实影响建议，只提出对应的核实问题。标题和建议理由也要逐项对照原材料，不能靠“可能瓶颈”标题把无依据的肯定句变成假设。

例（虚构）：“部分报修退回补照片；值班长审核。”可建议“根据已有缺照片退回，在提交入口增加照片填写提示”；可问“需核实审核阶段是否有等待积压”。不能说值班长是唯一关口、其他人不检查或没有状态记录。

已有授权内的小改进直接提出；更改审批、职责和控制由有相应权限的角色评估，采纳前沿用原规则。样本数和已知原因保留；小样本只描述该样本，不代替长期总体结论。短建议不另列瓶颈表、重复总结或完整试点治理。

## 衡量方案

只有需要验证具体判断时才加记录方案。为声称的每个指标写出公式与最少字段，字段在能观察该事件的环节取得：

| 指标 | 足够的记录 |
| --- | --- |
| 两端间总历时 | 同一事项的起点、终点及其定义。 |
| 实际处理或纯等待时长 | 对应状态每次开始、暂停/退出、继续及结束的事件记录；分段相加。 |
| 某原因退回比例 | 同范围全部事项、逐件是否因该原因退回及原因口径。 |

例（虚构）：收单到交单减法只能得到总历时。加一个开工时间，只能拆成收单到开工、开工到交单两个区间；后一区间仍可能含停工、等待或交付延迟，不能称为纯加工时间。若要纯加工时间，建议每单记录加工状态的开始、暂停/继续和结束事件。未知是否中断不能默认为连续加工。

例（虚构）：只有退回次数能统计总退回频度，不能据此算“缺签名退回比例”；还需要退回原因和同范围总件数。若仅建议提示卡，无需顺带声称它会省时或消除返工。

方案的录入角色、未来终点来源未知，仅该方案说明待确认。复杂比较或用户要求实施时再展开基线、试点、周期和成功标准；任何收益估算均需资料或明确假设。