如何制作 SOP 流程图
如何制作 SOP 流程图：一张图只画一条程序，步骤编号，判断点写明判定标准，并有一个纳入变更控制的已批准版本。附一个完整的事件管理示例。
SOP 流程图就是把标准作业程序画成流程：步骤有编号，能让人在压力下照着执行；判断写明标准；并且只有一个已批准的版本。
简而言之
- 一张图只画一条程序。两个起点意味着两份 SOP。
- 步骤要编号，并且短到可以在压力下念出声来。
- 每个判断都写明判定标准，或者指名由谁裁定。
- 升级路径与重新打开的路径要画出来，而不是心照不宣。
- 只有具备已批准版本、负责人和复审日期，SOP 才算受控。
SOP 与普通流程图的区别在哪里
SOP 流程图被阅读的场景，和普通流程图完全不同。流程图是在会议上看的；SOP 是凌晨两点由一个从没处理过这类情况的人打开的，他只需要知道下一步该做什么。这个差别决定了每一个设计选择：步骤要短，要编号，以便在电话里念出来；判断上要写明标准；除非由指名的角色来裁定，否则不留任何靠自由裁量的分支。
把范围限定在一条程序上。SOP 流程图最常见的缺陷，是三条程序挤在同一页上，结果长到没人愿意再打开。如果您的图有两个起点，或者其中一段只适用于某一个团队，就把它拆开。SOP 之间互相引用几乎不花什么成本；一份二十页、没人读的 SOP 才是真正的成本。
SOP 的另一半是控制。没有批准记录、没有版本号、没有复审日期的程序只是一份建议——在受监管的环境里，一份没有版本控制的 SOP 本身就是一项审计发现。下面的示例是一条事件管理程序，包含重大事件分支、SLA 违约升级路径和重新打开的回路，并附有从同一批行生成的程序正文。
以流程图呈现的 SOP
一条分四个阶段搭建的事件管理程序。下方带编号的程序正文与图表来自同一批行。
先记录，再诊断
发现、记录影响、分类并定级。SOP 要从阅读它的人真实所处的那一刻开始——对于事件来说，那一刻是还没有人知道哪里出了问题的时候，所以记录排在诊断之前。
在严重程度判断处分支
“重大事件？”把程序一分为二：宣告重大事件、开启应急会议桥、通知相关方——或者继续由一线做初步诊断。这个判断的标准应当写在判断本身上，因为它是由当班的人在时间压力下做出的。
按规则升级，而不是凭感觉
二线调查、一次明确的 SLA 检查并带有违约升级分支，然后恢复服务并与用户确认。请注意重新打开的路径：用户未确认的修复会退回诊断，而不是抱着侥幸心理关闭。
结案，并把学到的东西反馈回去
填写结案说明，然后判断根本原因是否仍不明确——如果仍不明确，就建立一条问题记录。在“服务已恢复”处就结束的 SOP，恰恰丢掉了那个能阻止同一事件再次发生的产出。
运作方式
把范围限定在一条程序上
用一句话写出触发条件：“发现或收到报告的事件”。如果触发条件需要一个“或”，而它涵盖的是一种确实不同的情形，那就是第二份 SOP。让每张图只画一条程序，才能让它短到可以在紧急情况下被打开。
把步骤写成指令
动词在前，一步一个动作，直接对执行的人说：“记录事件及其影响”，而不是“事件被记录”。被动语态会藏起负责人，而步骤没有负责人的 SOP，正是两个人做同一步、第三个人一步都不做的原因。
把判定标准写在判断上
“重大事件？”旁边需要一个定义——受影响用户数、服务等级、收入影响，用您所在组织实际采用的口径。用步骤的备注字段写这条规则。没有标准的判断，会被每一个读图的人以不同方式做出，而“标准”这两个字也就没有意义了。
补上升级路径与重新打开的路径
画出 SLA 即将违约时会发生什么、修复没有奏效时会发生什么、平时负责这件事的人不在时会发生什么。人们查阅 SOP 正是为了这些路径。每一条要么汇回主流程，要么以自己的终止点结束。
分配泳道，再与值班团队一起走一遍
把每一步放进执行它的角色所在的泳道——服务台、事件经理、二线——并和将来要用它的人一起通读。问他们会在哪里犹豫。每一次犹豫，都是一个缺少判定标准或需要拆分的步骤。
批准它、给它版本，并设定复审
把图表送进审批流程，让当前版本带有审核人和日期，并加上复审触发条件：任何一次重大事件之后，以及至少每年一次。在 QueryChart 里，批准记录与变更历史与图表放在一起，因此“三月份生效的是哪个版本”是有答案的。
应避免的错误
一份其实是三份的 SOP
两个起点，或者其中一段只适用于某一个团队，都说明这张图应该拆开。篇幅正是让 SOP 在最需要的那一刻没被打开的原因。
没有标准的自由裁量
“严重就升级”不是标准作业程序。写下阈值，或者指名由谁裁定——只有这两种方式能让判断可重复。
没有异常路径
顺利路径是大家本来就知道的。一份略去 SLA 违约、重新打开和负责人缺席的 SOP，恰恰在最需要它的地方保持沉默。
没有版本控制
没有已批准的版本和变更历史，就没有人能说明出事时哪条程序在生效——在受监管的环境里，这本身就是一项审计发现。
制作您自己的 SOP 流程图
把事件管理示例打开为您自己的图表，或者从空白开始，把您的程序写进各行里。
相关指南
常见问题
SOP 与流程图有什么区别？
SOP 是执行某项具体任务的受控指令：有编号、有负责人、经过批准、受版本控制，写给真正动手的人看。流程图是工作如何流动的图示，通常横跨多个角色，而且可能只是描述性的，并不具强制力。把 SOP 画成流程图可以兼得两者——图表的可读性加上程序的控制属性——前提是批准记录与版本历史一并跟上。
SOP 应该做成流程图还是文字？
两者都要，而且出自同一个来源。流程图在压力下更容易照着走，也让分支上的缺口显现出来；文字则承载图表放不下的细节，例如精确的字段取值或安全警示。真正的失败模式是把它们当作两份独立文档来维护，因为它们会逐渐脱节。让程序正文与图表从同一批行生成，改动其中一处就等于两处都改。
SOP 流程图应该多长？
短到能以可读的字号放进一屏——实际上大约十五到二十五个步骤。超过这个规模，就找一个自然的交接点，把它拆成两条互相引用的程序。长的 SOP 并不更严谨，只是更不容易被打开；而没人打开的 SOP，提供的控制力和完全没有 SOP 一样多。
SOP 由谁批准？
流程负责人，加上对该程序所控制的风险负责的人——通常是质量、合规或该服务的负责人。就程序而言，关键在于批准记录挂在某个具体版本上，并带有姓名和日期，这样过去任何一个时间点上哪份文本有效都不会含糊。正是这条记录，把一份文件变成受控文档。
