跳转至

课程 6.5 - SOP 执行标准

场景

“SOP 存在,但没人真正使用”

团队有一份 Incident 响应 SOP 存在文件夹里。真实事故发生时,不同 Dealer 用不同步骤,升级不一致,还遗漏了关键证据。

问题不是 SOP 不存在,而是它没有被设计成真正能用的运营工具。

学习目标

  • 理解并应用适合实时运营的 SOP 设计原则。
  • 识别强 SOP 的核心组成。
  • 用事故复盘改进 SOP。
  • 避免过于模糊或过于复杂的流程。

SOP 设计框架

目的 适用范围
适用范围 触发条件 / 使用时机
触发条件 分步操作
操作步骤 升级 / 权限
升级要求 所需证据
证据记录 关闭 / 交班
关闭标准 复盘 / 改进

核心 SOP 组件

组件 核心问题
目的 这个 SOP 为什么存在?
范围 包含什么,不包含什么?
触发条件 团队什么时候应该使用它?
角色 谁负责跟进、谁复核、谁批准、谁获得授权执行?
步骤 必须按什么顺序执行?
证据 需要记录哪些数据、日志或截图?
升级 什么时候升级,升级给谁?
关闭 什么条件代表事项完成?
复盘 SOP 如何根据真实事件继续改进?

好 SOP 的特点

好的 SOP 应该:

  • 对 Junior Dealer 足够清楚。
  • 在压力下足够短、可执行。
  • 足够具体,减少理解偏差。
  • 关联实际系统、告警和责任人。
  • 在真实 Incident 和系统变更后更新。

示例:报价异常 SOP

触发条件:
价格尖刺、陈旧报价或报价源价格不一致。

立即检查:
1. 确认产品和时间戳;
2. 对比平台 Tick、报价源及独立参考来源;
3. 检查报价处理与过滤日志;
4. 识别受影响订单;
5. 根据影响范围带证据升级;
6. 持续监控报价与成交;
7. 记录初步分类和后续跟进。

持续改进循环

真实 Incident 事件后复盘
事件后复盘 识别 SOP 缺口
SOP 缺口 更新 SOP
SOP 更新 团队培训
团队培训 桌面 / 现场演练
演练验证 后续 Incident 检验

实战训练

Dealer 可以通过正式复盘和批准流程提出 SOP 改进建议;正式 SOP 的修订、批准和发布由指定负责人完成。

真实场景

报价异常 SOP 存在,但事故中不同 Dealer 用不同步骤。

Dealer 应该看的证据

SOP 版本、触发条件、步骤、证据要求、升级人、关闭标准、复盘记录。

错误示范

SOP 写得太长或太抽象,实际压力下没人用。

正确处理

把 SOP 写成短、清楚、可执行的步骤,并根据真实 Incident 更新。

总结

SOP 只有在真实场景中能够指导一致行动时才有价值。有效 SOP 应简短、清楚、可执行,明确证据和权限边界,并根据真实 Incident 与复盘结果持续改进。

完成标准

  • 能说明本课的核心风险或操作目的
  • 能指出需要查看的系统、数据或证据
  • 能说明正确的升级或处理方式
  • 能在模拟或实际指导场景中按流程处理