SOP的设计与落地 - ZSS心得记录

1 背景

一个公司要有两本书：

一本书是红皮书，是公司的策略，即作战指导纲领；

一本书是蓝皮书，即SOP，标准作业程序，而这个作业程序一定要做到细化和量化。

—— 余世维

做业务的人，张口必提SOP。可是每个人说的“SOP”并不是一个东西，下面的内容是一次内部研讨会上，参会人员对于SOP的定义：

JX：用户不同时间点应该卡点完成的事项，必完成项。SOP是底线并不是标准。
KV：是一个标准，标准化流程。是保底线的，是必须要完成的。规范地按这个执行，用户会有一致的体验。
CH：是一个标准化的服务体验交付。
JL：可快速掌握的服务流程。SOP应该是进步的。 KY：用户在SPARK Math学习的轨迹、成长地图。 ZS：法典，员工动作、培训、质检、系统建设的依据。

另一个有趣的点是，在我司产研的需求清单上，似乎永远都挂着起成这种名字的需求：

新版SOP
SOP系统化
SOP迭代v1.0
SOP优化
…

每个人都知道SOP的重要性，此文档的目的是能够让大家统一认知，说一样的话，有一样的目标。

蓝皮书or白皮书？

上述引用的余世维的描述中，他提的是“蓝皮书”，但实际上白皮书的说法更适用，如下引自维基百科：

“皮书”与颜色词组合成一个固定短语，以其封皮颜色而名。各色皮书根据颜色不同，一般都具有不同的含义([1])：

白皮书：白皮书是最早使用“皮书”一词的，因最早用白色羊皮作封面而得名。专门用于发表政府的重要文件和报告，一般非政府组织不能使用白皮书形式进行发布([2])。

蓝皮书：一般用于专家或专业机构对某领域的年度研究报告，蓝色代表客观描述

黄皮书：一般用于专家对某领域中的问题所作的分析和预测，黄色代表警示和注意

绿皮书：一般用于专家对人民生活领域所作的分析报告，绿色代表人民生活的品质

黑皮书：一般用于对某领域发表的批评或批评性阐述

橙皮书：橙皮书一般带有预警，需要引起注意的内容

红皮书：红色有威胁、警戒的意思，一般用于关于危机警示的研究报告

2 什么是SOP

Standard Operation Procedure，标准作业程序。将某一事件的标准操作步骤和要求以统一的格式描述出来，用来指导和规范日常的操作，以达到保证质量和一致性的要求。

注意，这里的P是Procedure，而不是Process！！！

Process和Procedure的区别如下：

着眼点不同：
- Process着眼于整体，是一个整体的、宏观的概念。
- Procedure着眼于细节，是一个局部的、微观的概念。
含义不同：
- Process指的是过程、变化过程，强调的是一种动态的变化。
- Procedure指的是步骤、程序，强调的是固定的，已经成为常规的动作要求。

SOP的精髓，就是对程序中的关键控制点进行细化和量化。

2.1 SOP的起源

SOP最早起源于18世纪的手工作坊，后来1940+的美国军事工业希望以标准化的工作流程来确保生产的高效率和标准化。因为当时的制造业的生产规模不断扩大，分工也越来越明确，为了加速管理及生产的顺畅度，就不再用过往学徒制、口耳相传的教导方式，而是将所有的步骤化为纸本，改为更系统化、可随时回溯及翻阅的参考指南。再后来SOP逐渐在其他领域得到应用，成为了公共管理、企业管理等领域中必不可少的一种管理工具。

SOP的发展历程经历如下几个阶段：

初级阶段：主要应用于传统的制造业、医疗卫生、消防、航天航空等。
中级阶段：SOP逐渐从部门级扩展到企业层面，管理对象由流程规范向全面规范转变。
高级阶段：被纳入到企业的核心管理体系中。

2.2 SOP是什么？不是什么？

SOP是一种程序
- 是过程的描述
- 不是结果的描述
- 不是制度
- 不是表单
SOP是一种作业程序
- 是操作层面的程序，是实实在在的，具体可操作的
- 不是理念层面的事情
SOP是一种标准化的作业程序
- 标准化有最优化的含义
- 不是随便写出来的
SOP不是单一的，而是一个体系

2.3 SOP是一个60分 or 80分 or 90分的要求？

SOP能让一个60分能力的员工做出80分成绩的工作。

60分是及格的工作，一个合格的员工凭借个人的能力，应该能将工作做到60分。如果连60分都做不到，那就是招聘或者是员工培养出现了问题。

80分为良好，60分→80分，是SOP达成的效果，它能让员工有符合预期的标准化的产出。

80分→90分，需要员工更多的主观能动性，面对不同的用户需求进行差异化的服务。

2.4 SOP的意义和弊端

2.4.1 SOP的意义

提高工作效率
1. 简化工作流程并节约时间
保障工作质量
1. 减少错误
2. 保持服务体验的一致性
促进协作和沟通
1. 建立指挥系统
2. 轻松转移工作
3. 进行有效的知识管理

2.4.2 SOP的弊端

流程固化，缺乏创新。我们特别容易落入两个极端：一方面，要求员工严格按照SOP执行动作，那么员工就容易陷入无脑执行的境况，很难做得更好进行突破创新；另一方面，允许并鼓励员工发挥主观能动性，又担心会因此而失去控制。前者会让流程固化缺乏创新，后者会让SOP只停留在纸面。
制定、维护成本高昂。关于制作：制定SOP绝对不是拍脑袋，而是要：理顺用户历程、梳理用户需求、明确业务关键指标、明确相关方业务流程、思考可落地性…会耗费大量的人力，制作成本很高。关于维护：外部环境一直都在变化，用户需求一直都在变化，产品也一直在迭代，一个版本的SOP很难一直使用，这就需要有一套运维机制，持续升级迭代。那么就需要持续投入人力在这上面，监控数据、监督执行、整理并发现问题，也会耗费一些成本。
更新周期长，应用难度大。SOP涉及到业务的各个分支环节，且前后会存在耦合，与其他相关业务方也会存在耦合，更新的时候需要考虑调研清楚；且内容修改完成到落地之间，需要考虑系统、培训、质检、数据的适配性调整，所以更新周期长，应用难度大。

3 好的SOP

3.1 好的SOP的评价标准

体系化设计，有全景有架构
面向过程，具象可落地
追求普遍情况下的最优

3.2 如何产出好的SOP

3.2.1 从模块到动作

好的SOP的评价标准第1项，为：“体系化设计，有全景有架构”。

做SOP时，不要直接一头扎入细节，应该先想整体，再想局部。先想宏观上整个业务链路有哪几大模块，再细化思考每个模块下应该执行什么动作。

不追求大而全，先抓一级流程和承载竞争力的子流程。

3.2.2 基于场景设计

好的SOP的评价标准第2项，为：“面向过程，具象可落地”。

做SOP之前要先有场景清单，用这个场景清单推导出来有哪些流程，基于实际的场景，更容易让SOP落地。

“场景清单”是指围绕业务目标，尽可能描述全和描述清楚各种具象化的业务场景、包括要解决的具体问题和期望诉求，为后续流程和方案的设计提供比目标更加具体的输入；场景清单的内容有：主场景、分支场景、场景描述、服务对象、用户诉求、管理诉求、运营诉求、发生频次、现有IT支撑情况、当前痛点等属性。

3.2.3 每个步骤都有其目的

好的SOP的评价标准第3项，为：“追求普遍情况下的最优”。

在SOP的每个模块，都应该有明确的衡量指标；SOP内的每个步骤，都应该指向该模块的衡量指标。对于每个步骤，都应该反问自己：这个步骤是否必要？不做会有什么影响？

3.2.4 清晰的呈现

把作业过程用流程图画出来，流程图有助于形象化过程，并将那些容易被忽视的细节显现化。

内容注意事项：

直接描述，不要用第一或第二人称。
用主动语态而不是被动语态。
避免模糊用词，不要出现“应当”、“最好”、“可以”等词语。
用特定描述，例如，用“每天”，而不是用“定期”；直接写明“红色”，而不是用“彩色”。

3.2.5 充分的测试

测试第一轮：自己校验检查。

测试第二轮：找一位运营同事帮你查看

测试第三轮：找一位普通员工帮你查看

3.2.6 分清楚现状和未来、理想和现实

在设计流程时，特别容易混淆以上两组概念。需要对齐，聊的是现状还是未来；理想还是现实，

3.2.7 要有明确的交付物

一定要阐明流程中每个步骤的交付物或者是期望达成的目的/效果是什么。

没有明确的上下游交付物的流程只是徒有其表。

3.2.8 持续迭代/优化/简化

流程/机制并不是一劳永逸，要持续迭代/优化/简化。

3.3 SOP每个模块要包含哪些内容

3.3.1 流程说明

介绍这一模块/阶段的业务意义、主要目标、主要业务项。

3.3.2 流程图

以流程图的形式，介绍每个环节的关键事项及逻辑关联。

如果这一模块/阶段中包含了用户/订单等的不同状态，可以附上状态机。

3.3.3 操作规程

如果说流程图是核心动作的概括，那么操作规程就是操作规范的详细描述，详细介绍每个动作的细节要求。

3.3.4 FAQ

介绍这一模块的常见问题及其解决方案。

3.3.5 重点总结

以上内容，尤其是流程图及操作规程，内容含量巨大，所以可以将上述内容中的重点事项以精炼的语言进行总结，帮助员工划重点。

3.3.6 案例分享

正向或者负向的案例，帮助员工理解应该怎么做/不应该怎么做。

3.4 SOP Check List

为保证SOP符合上述标准及要求，特列出此Check List，在每个模块都需要按此表自查。

序号	项目	备注
1	有流程说明，介绍这一模块/阶段的业务意义、主要目标、主要业务项。
2	以流程图的形式，介绍每个环节的关键事项及逻辑关联。
3	有重点事项清单
4	SOP内的每个步骤，都应该指向该模块的衡量指标，如果删掉会怎样？	如果删掉会怎样？
5	阐明流程中每个步骤的交付物或者是期望达成的目的/效果是什么。是否是不能被删掉的。
6	直接描述，不要用第一或第二人称。
7	避免模糊用词，不要出现“应当”、“最好”、“可以”等词语。
8	用特定描述	例如，用“每天”，而不是用“定期”；直接写明“红色”，而不是用“彩色”。
9	讲的是现状、现实。	分清楚现状和未来、理想和现实
10	找一位运营同事帮你查看	避免惯性思维
11	找一位组长帮你查看	看是否能落地

SOP设计Check List

4 如何让SOP落地

4.1 培训

单次培训时长要控制在不超过1h，原因是一个人的注意力集中时间不会超过1h。

应该有个简版的概要，不要一上来就给员工发一本很复杂的书，看不懂。

培训、运营、基层管理者，三个角色的内容必须是一模一样的，否则员工会不知道怎么做。

入职的时候讲概要，讲What，要求员工必须按要求去做；入组后3个月内，逐个模块拆解，讲清楚Why。

4.2 质检

先检查关键的环节有没有做，再检查每个环节的重要的点做没做。

可以利用AI质检，这种技术在市面上比较成熟，很多家都有做。

5 SOP工单

5.1 SOP工单的结构

SOP工单是利用CRM内的一个重要功能模块，利用工单的形式辅助员工完成SOP要求员工完成的动作，它包含如下内容：

5.2 工单的几个关键时间点

工单生成时间：工单创建的时间点
工单期望处理时间：
1. 每个工单有个预期处理时效，工单创建时间/处理时间 + 预期处理时效 = 工单期望处理时间。
2. 在期望完成时间前仍然未被处理，应该给员工一个较强的工单超期未处理提醒。
3. 预约下次跟进时，工单期望处理时间会随之后延。
4. 注意，这里是期望处理时间，而并不是期望完成时间。
工单自动关闭时间：
1. 每个工单处理的ddl，如果超过这个时间仍然未被处理完成，工单就会被自动关闭掉。
预约下次跟进时间：
1. 有些工单并不能一次性被处理完毕，有可能需要后续继续处理，那么可以预约下次跟进。
2. 预约的下一次处理的时间就是预约下次跟进时间。
3. 从预约下次跟进时起，到下次跟进时间止，如果此工单没有被进一步处理，那么需要给员工弹出较强的提醒。

5.3 工单的状态机

5.3.1 不含【期望处理时间】的工单状态机

5.3.2 含【期望处理时间】的工单状态机

总结下来，状态有：

A：已生成，待处理
B1：处理中，未到下次约定时间
B2：处理中，已到下次约定时间
C：已逾期，未处理
D：已完成
- D1：处理时间内的已完成
- D2：处理时间外的已完成
E：超期自动关闭

5.4 工单工作台

需要提供工具给到员工，让他们清晰地看到当前需要处理的工单量，并可以下钻下去迅速展开工作。

在待办任务部分，每个分数：

分子：A+B2+C
分母：A+B1+B2+C

6 关于流程图

6.1 画流程图的工具和流派

流程图就是用直观的图像来展示一系列相互串联的活动，主要的工具和流派有5个：

6.1.1 流图表-Flow Chart

流图表（Flow chart）由美国国家标准协会（ANSI）制定，就是我们在 Visio 或者 PPT 里看到的那些流程符号，画出来的流程图直观、简单，不过没有标准化的符号属性定义；通常用于对流程建模的严谨性和体系性要求不高的情形。

6.1.2 事件驱动流程链-Event-driven Process Chain

IDS Scheer是一家成立于1984年的BPM软件及咨询公司，它被认为是BPM行业的奠基者。它建立了ARIS（Architecture of Integrated Information Systems）框架。

在ARIS框架中，定义了EPC(Event-driven Process Chain)，它能够用来描述业务流程图。

EPC认为流程是由一系列事件触发的，并且针对事件的行为又将引发新的事件，流程表现为“事件-功能-事件”串接。EPC 的主要元素是：事件（Event）、功能（Function）、组织单元（Organization Unit）、信息（Data）以及称为“规则（rule）”的逻辑运算符（包括“与”，“或”和“异或”）。ARIS 在欧洲普及度较高，尤其是使用 SAP 的大公司。

官网：https://aris.com/

6.1.3 统一建模语言-Unified Modeling Language

由国际技术标准组织OMG（对象管理小组）维护，这是一套做软件开发的系统分析的建模标准化符号，主要用于描述信息系统开发的需求，包括用例、时序、类、状态/活动、部署、组件、实体-关系等，也常用来画流程。

官网：https://www.uml.org/

6.1.4 集成定义语言-IDEF

由美国政府和军方在 70 年代开发，是一套包括十几种不同用途的建模规范族，从功能建模到数据、仿真、面向对象的分析/设计以及信息收集等，这是最早的流程图规范，不过看起来非常不直观，普通业务人员很难看懂。

6.1.5 业务流程模型和标记-BPMN

由业务流程管理标准化协会 BPMI创建的标准，后来加入了国际技术标准组织OMG 成为 OMG标准之一。BPMN目前是业务流程建模的行业事实标准，它提供了丰富的符号集，即可使用少数符号用于面向流程梳理的描述性建模，也可用于工程性目的、较为复杂的流程建模，或者用于流程挖掘后的流程可视化展示，目前最新版本是 BPMN 2.0。

官网：https://www.bpmn.org/

6.2 流程要画到什么颗粒度

“流程画几级”这个问题，本质是用流程图表达业务流程，要到什么颗粒度细度，或者说如何定义每级细度的标准的企业业务含义是什么？

目前流程分级并没有一个统一的标准，在参考文档中看到的主要有两种分级方法：分解法（分层分级）、分类法（分类分级）。

6.3 分解法：分层分级

流程分层分级的套路以ARIS为代表，其思想是：

在顶层设计上：通过价值链等方式进行粗颗粒度的归类
在中低层：将具体的流程，按照细节程度从粗到细地分解。

这样能够形成粗颗粒度与细颗粒的的嵌套。

6.3.1 流程之间的3种关系

以下图为例，流程之间有三种关系：

流程链接关系：

流程/流程组有顺序的或逻辑的关联关系，这种关系是水平的，关联性可以不是很强，例如价值链的各个环节就是流程链接关系；

流程变体：

某一个特定的流程/流程组可能根据一些变量，为了完成同样的工作，衍生出多个的流程形态，例如，同样是客户订单交付，对不同性质客户和不同产品类型及其供应链形态，分别适用按单配置（CTO）、按单组装（ATO）、按单制造（MTO）等模式——我朋友说的“业务场景”，可能表达的就是流程变体的意思；

流程分解：

一个流程中的某个活动被打开，由更细的流程来详述，这个流程就可以分解出一个或多个子流程，这就形成了流程的层级关系，高层次的颗粒度粗，低层次的颗粒度细。

6.3.2 三层五级-3 Layers 5 Levels

ARIS流程模型具有上下分解、水平分段的功能：Hierarchical Decomposition & Horizontal Segmentation

企业总体流程模型的建模的顺序既可以从上往下（从粗往细分解），也可以从下往上（从细到粗汇总）。这样使得 ARIS 的流程模型既可以拆成一小段一小段地看，又可以把相关联的流程横向纵向地全部连起来展示，可以形成一个蔚为壮观的流程图。

纵向的从粗到细分解，并没有一定之规，有些人认为应该是三层，也有些人认为最多可以到七层。通常，ARIS将企业级流程层次分为三层（Layer），而每层可以再细分级（Level）。

Layer：
- Layer1-Conceptual-概念性-业务模式视角
- Layer2-Process-流程性-业务如何运营的结构
- Layer3-Procudure-规程性-具体活动任务的细节
Level：
- Level1-Enterprise Map-企业地图
- Level2-Process Area Maps-流程领域地图
- Level3-Main Process Models-主流程模型
- Level4-Process Models-流程模型
- Level5-Activity Models-活动模型

6.3.3 概念层的建模方法-增值链法-VAD

Value Added Chain Diagram，简称VAD，显然这是一个业务模式和业务领域的概念表达，主要用于宏观的业务设计，它并不是用来指导具体业务运营的。

6.3.4 流程层的建模方法-事件驱动流程链-EPC

Event-Driven Process Chain，EPC

ARIS 提供了几十种流程相关的业务和信息模型，包括流程、组织、产品/服务、数据、系统等，最常用的就是本章提到的 VAD、EPC 和 FAD三种，而如果你要做一个真正称得上“业务流程”、可以指导实际运营管理的企业级流程模型的话，其他模型都可以不用，但是 EPC 是必须用的。我认为在这个流程描述颗粒度上，用 EPC 流程图展示的流程才叫“流程”，或者说是狭义上的“流程”。一个 EPC 图里包括了构成流程最主要的几个元素：

Event 事件：流程的开始触发、过程中状态和结束的产出。
Function 功能：代表流程中的一个动作，或称任务task或者是活动activity
Resource 资源：跟动作相关的数据、文档、软件系统的功能、组织单元和岗位角色
Rules 规则：流程走向的逻辑判断

尽管流程间存在横向连接或者纵向分解，分解的目的只是为了便于阅读，纵向分解的每级流程上的功能/事件/规则的定义都是一样的，从这个角度上说，基于上述建模规则建立的流程就是流程，并不存在有不同类型、不同定义规则的流程——就像父亲是人，儿子也是具有同样生理特征的人，不是就变成其他物种了，所以我说只要是EPC 画的流程，无论是几级流程，都是“流程”。

6.3.5 规程层的建模方法-功能分配图-FAD

Function Allocation Diagram

对于 EPC 上的每一个功能（function），或者说是任务（task），如果要进一步描述其细节，可以适用“功能分配图（Function Allocation Diagram ，简称FAD)

需要注意的是，并非所有的流程信息或者每层流程图都必须在ARIS中进行图形化、结构化建模，无论是粗的流程组定义、概念想法、需求定义，还是流程活动的详细描述、作业指导等，可以在文本格式或者其他格式的文档中描述。用户可以将这些文档链接到相关ARIS对象上，所以即使没有直接对其建模，各种信息源可以链接到模型架构中，这样，ARIS就成为一个以结构性流程为框架的、完整的企业信息存储库。

6.4 分类法：分类分级

另一种套路并不特别强调流程的横向分段和纵向分解的关系，只是提供了一个分类分级的层级结构，让用户可以将一个个离散的流程装进这个分类框架里。这个套路的代表就是美国生产与质量协会的流程分类框架（以下简称：APQC PCF），供应链SCOR 模型也是这个套路。

7 SOP与BPM的区别与联系

MBA智库内：

对于BPM的定义是：将生产流程、业务流程、各类行政申请流程、财务审批流程、人事处理流程、质量控制流程及客服流程等70%以上需要两人以上实施的任务全部或部分由计算机处理，并使其简单化、自动化的业务过程。

对于SOP的定义是：将某一事件的标准操作步骤及要求以统一的格式描述出来，用来指导和规范日常的工作。

两者的区别是：

1 关注焦点不同：BPM关注于企业内一系列活动或事件的全面管理，涉及到流程的分析、模型的建立、任务的调度、资源的分配、评测、再优化等。而SOP更聚焦于某个具体的细节过程，指导日常的工作。

2 范围不同：BPM会涉及到跨部门跨岗位的协作，它更关注于整个企业内部的流程优化和效率提升。而SOP一般不会涉及到跨部门，它主要是某部门某项活动的连续步骤描述。

3 文件层级不同：在ISO体系文件中，流程文件属于二级文件，而SOP属于三级文件，是流程文件的下级文件。流程文件下面可以有SOP，也可以没有。

两者的联系是：

目标：虽然他们关注的目标和层级不同，但都是为了提高企业的运营效率和质量。

协作：虽然SOP更侧重于某一具体过程的标准化，但它也需要与其他部门或岗位进行协作，以确保整个流程的顺畅运行。

持续改进：无论是SOP还是流程管理，都需要不断地进行改进和优化。