在构建企业的 “业务流程架构” 时，经常会听到以下的观点：

1）“业务流程” 可以分为 “业务流”、“审批流” 两大类。

2）“业务流程架构” 中只包含 “业务流”，而 “审批流” 不出现在 “业务流程架构” 中。

3）“审批流” 是 “业务流” 的下一级流程，如果 “业务流” 是 L4，那么 “审批流” 就是 L5。

EBPM 方法论认为，上述说法是不准确的。

在概念和功能上确实可以分离出所谓的 “业务流” 和 “审批流”，但 “业务流” 和 “审批流” 仅是一条完整 “业务流程” 的不同部分。对于一条完整的 “业务流程” 而言，“业务流” 和 “审批流” 是紧密协作、顺序或交替进行的，并不是独立存在的。

01—什么是 ”业务流“ 和 ”审批流“

1. 业务流

“业务流” 关注 “做事”，是完成一项具体业务事项的过程。“业务流” 是一系列创造价值的 “业务活动” 的集合。

业务流的目标：产生达成价值主张的成果。例如：填写报销单、提交采购申请、撰写项目计划、开发软件功能。

业务流的参与者：通常是业务事项的完成人，包括业务事项的发起者和执行者（如工程师、采购员等）。

业务流的特点：侧重于描述 “如何正确地完成工作”，通过完成工作事项输出价值项。

2. 审批流

“审批流” 关注 “决策”，是对某个业务事项的请求进行决策。“审批流” 是对 “业务事项” 进行审查、评估并做出决定（比如：通过、拒绝、退回修改）的一系列 “业务活动” 的集合，是一种 “控制” 机制。

审批流的目标：控制风险、确保合规或达标。

审批流的参与者：通常是拥有决策权的管理者或业务专家（如部门经理、财务总监、法务等）。

审批流的特点：对工作事项进行价值判断，包括 “是否有价值”（比如：这件事是否被批准）和 “价值是否达成期望”（比如：这件事的完成结果是否达标）。

02—业务流程、业务流、审批流的关系

“业务流程” 描述了完成一件业务事项的完整过程，其中描述如何 “做事” 的部分就是 “业务流”，描述如何 “决策” 的部分是 “审批流”。

上图所示是一条完整的《采购付款流程》，由 “业务流” + “审批流” + “业务流” 三段构成。

第一段是 “业务流”，由三个 “业务活动” 构成，分别是<提交采购付款申请>、<执行三单匹配>、<确认进项税发票>。

第二段是 “审批流”，由两个 “业务活动” 构成，分别是<财务经理审批付款申请>、<财务总监审批付款申请>。

第三段是 “业务流”，由一个 “业务活动” 构成，是<完成款项支付>。

从上述示例可以看到， 并不存在割裂且独立存在的 “业务流” 和 “审批流”。“业务流” 和 “审批流” 是一条完整 “业务流程” 中不可分割的不同部分。

在一条完整的 “业务流程 ”中，“业务流” 和 “审批流” 是相互 “触发” 的关系。“业务流” 产生了一个结果，触发了 “审批流”。比如，员工填写完报销单（这是业务活动），点击 “提交” 后，触发了一段 “审批流”。“审批流” 审批的对象，正是 “业务流” 输出的结果，也就是通常所说的 “价值项”。

“审批流” 的结果会驱动后续 “业务流” 的走向。比如：

审批流通过-> 业务事项状态变为 “已批准”，触发付款（下一个业务流）。

审批流拒绝-> 业务事项状态变为 “已拒绝”，流程结束。

审批流退回修改-> 业务事项状态变为 “待修改”，退回给发起人，继续业务流（修改申请单）。

综上，可以这样描述“业务流程”、 “业务流” 和 “审批流” 的关系：一个完整的业务流程 = 业务流（做事） + 审批流（决策） + 下一个业务流（执行决策结果）。

03—不存在只有 “审批流” 的 “业务流程”

由于“审批流”是对“业务流”的输出结果进行“决策”，因此逻辑上不存在一条完全没有“业务流”的“审批流”。 因为它违背了“审批流”存在的根本目的 ：“审批” 总是针对某个具体 “业务事项” 的，而这个 “业务事项” 的创建和产生过程一定是“业务流”。

在“审批流”的定义中就包含了 “对某个事项的请求进行决策”这个内涵，而这个 “事项的请求” 能够被提交上来，必然经过了一个创建的过程，无论这个过程多么简短，其都是“业务流”。

即使是口头请示：员工向老板口头说 “老板，我想请假三天”。这句口头请示，就是最原始的 “业务活动” - 业务信息的创建和传递。

即使在纸上签个字：一份已经打印好的文件，请领导签字批准。而产生 “文件” 的过程是 “业务流”。

04—实操中为何感觉存在独立的 “审批流”

那么，为什么在实操中总会有人觉得确实有独立存在的 “审批流” 呢？EBPM 方法论认为，那是由以下两个原因造成的。

1）“审批流” 很复杂，流程设计人员改用非流程图的形式来描述 "审批流”

还是以前文提到的《采购付款流程》为例，如上图所示，当 “审批流” 的环节很多时，流程设计人员觉得画流程图的形式比较繁琐，所以就简化了上述流程图。如何简化呢？

上图所示是流程设计人员经常采用的一种简化方式。将复杂的 “审批流” 简化为一个环节，称为 “XX审批子流程”，然后用一段文字描述审批流。

为了给这种简化赋予合理的学术色彩，给出了如下说明：“审批流是L5” 是 “L4 业务流” 的下一级，我们只画到 L4，所以用一个 “子流程” 符号代表 “审批流”，细节就不描述了。考究点的，会用一段文字来描述一下这个 “子流程”，偷懒的就只保留一个 “子流程” 符号了。这里必须强调，如果只保留一个 “子流程” 符号，没有配上文字说明，那么这条 "业务流程” 的描述是不完整的，是缺失的。可以认为，这条 “业务流程” 没有完成设计，是一个半成品。

上图所示仍然是上文提到的《采购付款流程》，不同的采购品类、不同的金额需要走不同 “审批流”，上图下方所示的《采购付款审批授权表》描述 了“审批流” 的具体规则。事实上，上图所示的表中仅描述了支付 “设备” 采购款的 “审批流”。可以想象，描述了所有采购品类的《采购付款审批授权表》会更为复杂。如果将《采购付款审批授权表》中的规则画成流程图，会是极其庞杂的！有时人工甚至无法画出流程图来。常见的处理方法就是上图所示的，将复杂的 “审批流” 简化为一个环节，称为 “XX审批子流程”，然后挂上一张《采购付款审批授权表》。

同样，为了给这种简化赋予合理的学术色彩，给出了如下说明：“审批流是 L5” 是 “L4 业务流” 的下一级，我们只画到 L4，所以用一个 “子流程” 符号代表 “审批流”，细节就不描述了。这里也必须强调，如果只保留一个 “子流程” 符号，没有挂上《采购付款审批授权表》，那么这条 “业务流程” 的描述是不完整的，是缺失的。可以认为，这条 “业务流程” 没有完成设计，是一个半成品。

在实操中，很多企业的流程图和授权表是分开描述和维护的，甚至还是不同的人维护的，这是典型的 “两张皮” 现象，人为的将一条完整 “业务流程” 的描述割裂成不同的互不关联的两个“文件” 或者 “模型”。这种做法应坚决杜绝，必须在同一个流程模型中完整描述这两部分信息，简单来说就是《采购付款审批授权表》必须直接关联到 “XX审批子流程” 这个符号上。

2）“审批流” 会单独在 OA 系统中运行

还是以上图所示《采购付款流程》为例，《采购付款审批授权表》中描述的 “审批流” 逻辑，常常会单独落到企业的 OA 平台上，并且命名为《采购付款申请流程》。即 OA 平台上的《采购付款申请流程》不包含一前一后两段 “业务流”，即不包含：

“业务流一”：<提交采购付款申请>、<执行三单匹配>、<确认进项税发票>。

“业务流二”：<完成款项支付>。

此时，在 OA 平台上 “肉眼可见” 的存在一条名为《采购付款审批流程》的流程，但在流程管理人员构建的 “业务流程架构” 中却找不到这样一条流程。在 “业务流程架构” 中只有《采购付款流程》。这又如何解释呢？

EBPM 方法论认为正确的理解如下：

1）“业务流程” 包含 “业务流” 和 “审批流”。

“业务流程” 可以分类 “业务流”、“审批流” 两大类这句话是错的，正确的理解应是：一条完整的 “业务流程” 中可能会包含 “业务流” 和 “审批流”。

2）“审批流” 不是 “业务流” 的下一级。

对照上图所示的 APQC 流程框架，“L3:业务流程” 的下一级是 “L4:业务活动”，而 “L4:业务活动” 的下一级是 “L5:业务任务”。“业务流” 和 “审批流” 都属于 “L4:业务活动”，“业务流” 是执行类的活动；“审批流” 是决策类的活动。

在流程图中用一个符号代表 “XX审批子流程”，而不采用流程图的形式描述 “审批流” 的细节，只是流程图的一种建模方法，是一种绘制流程图的技术手段，这并没有改变 “审批流” 和 “业务流” 共同构成一条 “业务流程” 的实质。只不过是用一个图符加一段文字或者一张表来描述 "审批流” 而已。

还是以上图所示《采购付款流程》为例，不同的 “业务活动” 会在不同的 “IT 系统” 中完成。不能因为中间有一段流程是在 OA 系统中运行，就认为有一段独立存在的流程。不然，上图所示的《采购付款流程》就可以拆分为以下四个独立存在的流程了：

ERP 中的《采购付款申请及三单匹配流程》

增值税发票综合服务平台中的《确认进项税发票流程》

OA 系统中的《采购付款审批流程》

财务管理系统中《款项支付流程》

EBPM 方法论认为不能这样进行拆解，即不能将《采购付款流程》拆分成上述四条流程。

总之，在我们构建的 “业务流程架构” 中，L3 流程清单中只应存在《采购付款流程》这条流程；而《采购付款流程》的下一级就是流程图中的所有活动，包括 “业务流” 和 “审批流”；绝不能由于一组 “活动” 在不同系统中运行，就拆成上述四条流程。OA 系统中的《采购付款审批流程》本质上与财务管理系统中的《资金支付功能模块》、ERP中的《三单匹配功能模块》没有区别。