如何编写SOP
编写一个标准操作程序，命名其触发器、所有者、决策标准、异常路由和所需记录。遵循有效的事件响应示例。
要编写 SOP，请定义其开始和结束时间，在每个步骤中放置一个可观察的操作，指定执行该操作的人员，说明每个决策的标准，并确定证明已完成操作的记录。
简而言之
- 在编写步骤之前定义单个触发器、结果和责任所有者。
- 每个编号步骤使用一个可观察操作，并命名执行该操作的角色。
- 为决策制定标准并为每个结果写出路线。
- 命名每个控制点生成的记录。
- 为已发布的 SOP 提供所有者、批准、版本和审核触发器。
为从事这项工作的人写作
从一个程序和一个读者开始。事件响应人员需要在轮班期间遵循的顺序，而不是部门政策的描述。列出开始工作的事件、结束工作的结果以及负责每个操作的角色。如果第二个触发器需要不同的路由，则可能需要单独的 SOP。
首先起草普通路径，然后询问工作人员在输入丢失、超过阈值或第一次尝试失败时做什么。将决策写成具有可测试标准的问题。 “如果需要则升级”使得最重要的选择未定义； “当响应期限面临风险时升级”为工作人员提供了适用的规则。
下面的事件示例使这种区别显而易见。其重大事件决策改变了路线，其 SLA 检查触发升级，其未解决的原因分支生成问题记录。相同的行可以被解读为图表或过程文本。创建 SOP 流程图的配套指南重点介绍图表符号；本指南重点关注 SOP 必须包含的说明和证据。
处理事件的程序
跟踪事件从发现到结束的整个过程。过程视图使用与 QueryChart 图相同的步骤。
定义进入条件
该程序在检测到事件时开始。记录影响和优先级会在任何人开始调查之前创建记录。
陈述决策规则
重大事件问题将紧急响应与常规诊断分开。可用的 SOP 说明谁做出了决定以及他们使用了什么证据。
处理截止日期和失败的修复
SLA 分支指定何时升级。如果无法确认修复，路线将返回诊断，而不是结束未解决的事件。
关闭有证据
关闭注释和未知原因的问题记录使得在立即响应结束后可以审查结果。
运作方式
设定边界
为触发写一句，为完成状态写一句。指定流程所有者和将使用 SOP 的角色。使用不同的触发器拆分过程，而不是将它们隐藏在一个文档中。
采访做这项工作的人
请他们回顾一下最近的一个案例。按实际顺序记录操作，包括他们检查的内容以及他们使用的系统或表格。在发出 SOP 之前，将该账户与现有政策进行比较。
写下编号的、可观察的动作
每个步骤都以动词开始，并将其分配给一个角色。将“确保适当处理”替换为实际检查、行动和记录。每个步骤保留一个操作，以便可以在不重新编号整个段落的情况下对其进行修改。
写下决定和例外情况
将每个“如果”变成一个问题，定义其标准并描述每个结果。包括拒绝的、不完整的和重试的路线。在 QueryChart 中绘制这些分支，以检查是否没有分支在没有下一个操作或结束的情况下停止。
审核、批准、发布
让从业者根据真实案例测试这些步骤，并让责任所有者批准发布的版本。记录版本并审查触发器，然后从使用地点撤回被取代的副本。
应避免的错误
编写政策而不是指令
诸如“事件必须立即处理”之类的规则并没有告诉响应者该做什么。将规则放入策略中，并将操作、时间和记录写入 SOP 中。
将例外情况留在记忆中
仅当所有输入都到达并且第一次修复成功时才起作用的过程在有人最需要它的时候失败了。在批准之前测试缺失的输入和失败的修复。
打开事件 SOP 示例
检查过程和图表视图中的步骤，然后将其调整为您自己的响应流程。
相关指南
常见问题
SOP 应该包括什么？
包括目的和范围、触发器、所有者、编号操作、决策标准、例外路由、所需记录、批准、版本和审核触发器。确切的文档包装可能会有所不同；该过程必须保持可执行。
SOP需要流程图吗？
不。短的线性过程可以用作编号文本。当决策、循环或交接使得散文中的路线难以遵循时，流程图会有所帮助。保持文字和图表一致。
谁应该批准 SOP？
负责的流程所有者应在执行工作的人员测试后批准发布的程序。文档控制者可以管理编号和分发，但这并不能取代所有者对指令的批准。
