课程 6.5 - SOP 执行标准¶
场景¶
“SOP 存在，但没人真正使用”¶
团队有一份 Incident 响应 SOP 存在文件夹里。真实事故发生时，不同 Dealer 用不同步骤，升级不一致，还遗漏了关键证据。
问题不是 SOP 不存在，而是它没有被设计成真正能用的运营工具。
学习目标¶
- 设计能支持实时使用的 SOP。
- 识别强 SOP 的核心组成。
- 用事故复盘改进 SOP。
- 避免过于模糊或过于复杂的流程。
SOP 设计框架¶
Purpose
→
Scope
Scope
→
触发条件 / 使用时机
Trigger
→
分步操作
Steps
→
升级 / 权限
Escalation
→
所需证据
Evidence
→
关闭 / 交班
Closure
→
复盘 / 改进
核心 SOP 组件¶
| 组件 | 核心问题 |
|---|---|
| 目的 | 这个 SOP 为什么存在？ |
| 范围 | 包含什么，不包含什么？ |
| 触发条件 | 团队什么时候应该使用它？ |
| 角色 | 谁执行、谁复核、谁批准？ |
| 步骤 | 必须按什么顺序执行？ |
| 证据 | 需要记录哪些数据、日志或截图？ |
| 升级 | 什么时候升级，升级给谁？ |
| 关闭 | 什么条件代表事项完成？ |
| 复盘 | SOP 如何根据真实事件继续改进？ |
好 SOP 的特点¶
好的 SOP 应该：
- 对 Junior Dealer 足够清楚。
- 在压力下足够短、可执行。
- 足够具体，减少理解偏差。
- 关联实际系统、告警和责任人。
- 在真实 Incident 和系统变更后更新。
示例：报价异常 SOP¶
Trigger:
Abnormal tick/spike, stale quote or inconsistent price source.
Immediate steps:
1. Identify symbol and timestamp.
2. Compare platform tick with 报价源 / independent sources.
3. Check quote-processing/filter logs.
4. Identify affected orders.
5. Escalate with evidence based on impact.
6. Keep quote and execution monitoring active.
7. Record classification and follow-up.
持续改进循环¶
真实 Incident
→
事件后复盘
Review
→
识别 SOP 缺口
Gap
→
更新 SOP
Update
→
团队培训
Train
→
桌面 / 现场演练
Test
→
Incident
实战训练¶
真实场景
报价异常 SOP 存在，但事故中不同 Dealer 用不同步骤。
Dealer 应该看的证据
SOP 版本、触发条件、步骤、证据要求、升级人、关闭标准、复盘记录。
错误示范
SOP 写得太长或太抽象，实际压力下没人用。
正确处理
把 SOP 写成短、清楚、可执行的步骤，并根据真实 Incident 更新。
总结¶
SOP 只有在真实场景中能够指导一致行动时才有价值。有效 SOP 应简短、清楚、可执行，明确证据和权限边界，并根据真实 Incident 与复盘结果持续改进。
完成标准¶
- 能说明本课的核心风险或操作目的
- 能指出需要查看的系统、数据或证据
- 能说明正确的升级或处理方式
- 能在模拟或实际指导场景中按流程处理