审批的本质是业务管控，包括但不限于规范员工行为及业务质量、提高企业运转效率等。本文作者对审批流的设计思路进行了分析，一起来看一下吧。

一、本质及意义

审批，本质是业务管控，包含但不限于规范员工行为及业务质量、提高企业运转效率、业务数据存档和溯源等。

审批，意义是提高企业运转效率，如果在审批之间，还需要不同角色私下反复沟通，本质上就失去了审批的意义。

二、内容组成

审批，可以理解为是一组消息。这一组消息当中会有：具体的文本、对应的附件、以及照片视频等。这些内容都是辅佐申请人去讲诉你需要申请的内容。

1. 参与角色

1）发起人

发起人，是整个审批流程的归属人。他最关心整个审批进展，因为在发起人的角度创建完审批事项后，可能还需要进入审批页面，完善后续附加信息、及时了解审批状态、催促审批人的审核、处理驳回意见等等。因此站在发起人的角度，审批需要尽可能详细的展示当前审批的状态、完整的审批流程、驳回信息的快速操作、成功信息的必要通知。

2）审批人

审批人，主要在审批过程做出决策。因此他更在乎的是审批申请内容的信息，比如审批的信息内容、直接的审批操作、多条审批的管理。

3）执行人

执行人，主要在审批后做出执行。在现实业务中发起人与执行人往往是同一个人。

4）抄送人

抄送主要起到通知与审批单(业务)相关成员的作用。例如：今天你需要申请事假，需要通知同部门的其他成员或者人力资源部门的相关成员。

2. 流程配置

审批当中，最主要的要素便是流程。各企业因组织架构，规章制度，员工管理方式的不同，往往会根据自身情况自定义符合管理需求的审批流程。那么下面主要介绍以下三类审批流程。

1）串行审批流

串行审批主要是指当一个审核节点通过后，才能进入下一个审核节点。如果节点驳回，则可以根据业务实际需要，配置驳回的返回路径，会有：驳回到发起人、驳回到上一个节点、或驳回之前任意一个节点重新审批。

2）并行审批流

并行审批是指一个审批节点存在多个角色同时审批，这里会存在两种情况。

1. 情景1：任何一个人审批通过，则可以进入下个节点，这也就是系统当中常说的 「或签」。
2. 情景2：所有审批人员通过，才能进入下个节点，这也是系统当中常说的 「会签」。

3）条件审批流

条件审批就是将企业当中的规章制度映射到实际的项目当中，通常就是某个审批内容会根据金额多少、实际数量等进而选择哪个角色进行审批。

比如销售人员在申请一个合同审批时，会根据合同金额的不同，审批人也会有所差异。当金额小于 8000 时，合同直接由财务专员进行审批，进而让流程进行快速审批。

当金额大于 8000 时，合同会由销售主管进行审批，让销售主管能够掌握企业的重要合同。

3. 审批表单

审批表单是一个简单且支持用户可配置的表单。因为现如今大多数 B 端产品都是以 SaaS 作为基础（如果是定制化产品，它的审批内容、流程也不会是固定不变的），这意味着审批表单需要为企业提供“DIY”的方式，通过表单提供不同的字段类型，去构建审批的实际要求。

比如在物流管理中，发起签收、支付、开票、服务费率设置的审批申请时，要求都会有所不同。例如在签收审批中需要对运输履约情况（装卸货单、回单、是否出现货损货差等）进行审核，而在支付审批中需要对支付金额、服务费等进行核对。以上业务表现出的复杂场景，也佐证了仅靠单一、固定的表单并不能满足实际的审核需求。

综上，在设计审批表单时应考虑“如何将审批与其他系统关联”并支持各类定制化的表单内容。

4. 执行业务动作的策略

上文可知，企业存在不同业务场景、特定的审批需求。在审批完成后，相应也存在不同的执行业务动作的策略。包括：自动执行，人工执行。

例如：在物流管理中，发起支付审批的发起人与实际执行支付运费的人不一致。此时企业可根据自身管理需求配置支付审批后由系统自动执行支付或指定执行人执行支付动作。

5. 通知渠道

通知渠道不隶属于审批流上下文，是审批流上下文中所对接的第三方系统。其作用是通知审批相关方审批结果并促使相关方快速做出判断及响应。通知渠道与企业工作沟通工具高度相关，包含但不限于：站内消息通知、短信通知、微信消息、钉钉消息等。

三、总结

审批的本质是提高企业运转效率。如果在审批之间，还需要不同角色私下反复沟通，就失去了审批的意义。且审批本身就是一个典型的 B 端产品从场景到需求，进而研发的功能，最后又回归场景，设计需要回归到真实场景，与业务相关联。