如何制作 SOP 流程图
如何制作 SOP 流程图：一张图只画一条程序，步骤编号，判断点写明判定标准，并有一个纳入变更控制的已批准版本。附一个完整的事件管理示例。
运作方式
把范围限定在一条程序上
用一句话写出触发条件：“发现或收到报告的事件”。如果触发条件需要一个“或”，而它涵盖的是一种确实不同的情形，那就是第二份 SOP。让每张图只画一条程序，才能让它短到可以在紧急情况下被打开。
把步骤写成指令
动词在前，一步一个动作，直接对执行的人说：“记录事件及其影响”，而不是“事件被记录”。被动语态会藏起负责人，而步骤没有负责人的 SOP，正是两个人做同一步、第三个人一步都不做的原因。
把判定标准写在判断上
“重大事件？”旁边需要一个定义——受影响用户数、服务等级、收入影响，用您所在组织实际采用的口径。用步骤的备注字段写这条规则。没有标准的判断，会被每一个读图的人以不同方式做出，而“标准”这两个字也就没有意义了。
补上升级路径与重新打开的路径
画出 SLA 即将违约时会发生什么、修复没有奏效时会发生什么、平时负责这件事的人不在时会发生什么。人们查阅 SOP 正是为了这些路径。每一条要么汇回主流程，要么以自己的终止点结束。
分配泳道，再与值班团队一起走一遍
把每一步放进执行它的角色所在的泳道——服务台、事件经理、二线——并和将来要用它的人一起通读。问他们会在哪里犹豫。每一次犹豫，都是一个缺少判定标准或需要拆分的步骤。
批准它、给它版本，并设定复审
把图表送进审批流程，让当前版本带有审核人和日期，并加上复审触发条件：任何一次重大事件之后，以及至少每年一次。在 QueryChart 里，批准记录与变更历史与图表放在一起，因此“三月份生效的是哪个版本”是有答案的。
常见问题
SOP 与流程图有什么区别？
SOP 是执行某项具体任务的受控指令：有编号、有负责人、经过批准、受版本控制，写给真正动手的人看。流程图是工作如何流动的图示，通常横跨多个角色，而且可能只是描述性的，并不具强制力。把 SOP 画成流程图可以兼得两者——图表的可读性加上程序的控制属性——前提是批准记录与版本历史一并跟上。
SOP 应该做成流程图还是文字？
两者都要，而且出自同一个来源。流程图在压力下更容易照着走，也让分支上的缺口显现出来；文字则承载图表放不下的细节，例如精确的字段取值或安全警示。真正的失败模式是把它们当作两份独立文档来维护，因为它们会逐渐脱节。让程序正文与图表从同一批行生成，改动其中一处就等于两处都改。
SOP 流程图应该多长？
短到能以可读的字号放进一屏——实际上大约十五到二十五个步骤。超过这个规模，就找一个自然的交接点，把它拆成两条互相引用的程序。长的 SOP 并不更严谨，只是更不容易被打开；而没人打开的 SOP，提供的控制力和完全没有 SOP 一样多。
SOP 由谁批准？
流程负责人，加上对该程序所控制的风险负责的人——通常是质量、合规或该服务的负责人。就程序而言，关键在于批准记录挂在某个具体版本上，并带有姓名和日期，这样过去任何一个时间点上哪份文本有效都不会含糊。正是这条记录，把一份文件变成受控文档。