编辑导语：实现审批流最常见的两种方法是“BPM方法”和“层级审批方法”，后者更加贴近本土用户使用习惯。本文作者以订单审批为例，剖析层级审批的设计逻辑，一起来看一下吧。

审批流是企业中高频业务场景。实现审批流的方法很多，最常见的有两种抽象：

1）BPM方法

工作流引擎。虽然BPM的完整概念是商业业务流程，但是多数开发者把BPM结合国内情况，收敛了BPM的范围，核心约束在：表单+流程的范围，或更缩小到自定义表单+自定义审批流程的范围。BPM的核心是：基础表单，步骤执行人，去向或者去向逻辑。

2）层级审批方法

更本土化的抽象逻辑，形象描述为：一层一层逐级审批。层级审批的特点是，没有步骤的去向概念，而是抽象定义为是和否两个分支：

• 是：继续下一级别审批
• 否：直接结束审批

BPM方法的资料很多，开源资源也非常丰富，这里不再赘述。我们来谈谈更加贴近本土用户使用习惯的——层级审批实现方案。

首先，我们回归到基础场景，以非常典型的单据——订单审批为例，剖析层级审批的设计逻辑。

审批的基础业务数据：订单+订单明细+（应收计划）。这里的应收计划很容易在业务角度忽略，实际上，审批订单的核心指标是三个：

1. 价格
2. 交期
3. 应收（计划回款）

如忽略应收数据，则可能会造成大量账期拖延的应收，甚至于带来坏账风险。在我们开发人员看来，应收数据只不过是基础审批中多了一部分数据而已，关系也不复杂，并不需要花这么多篇幅来阐述。

实际不然，多数业务管理系统的技术后台并不弱，UI也很现代，但是一旦融入业务运行，就会发现缺胳膊少腿，业务逻辑支离破碎。我们在用户这里学到这样一句话：UI漂亮有什么用？我要跑通业务！当业务管理系统融入了企业的生产运营环境，就会发现：业务顺畅高于一切！

说了半天，回归业务。用户希望是一组以订单为中心的业务数据参与审批，并在审批过程中不要被步骤审批人修改原始数据，且没有经过审批的订单，不允许被执行，不应该纳入销售类统计。

那么我们总结为：

• 一组数据参与审批
• 锁定参与审批的数据不允许在过程中随意修改
• 没有经过审批的数据不得继续执行，且不得纳入统计（这是很多用户在用了BPM审批流之后，再用超兔的审批流，忽然发现轻松很多的原因之一。在数据层，直接用业务表本表发起审批，并通过审批状态实现业务执行约束和统计约束）

审批的层级：层级，审批人。和BMP相比，这里抽象简化了很多内容，因为简化所以在配置审批流时非常简单，只需要两个参数——层级和审批人。

因为其弱化了步骤去向的概念，用审批的要义：否决即中止，避免了设置步骤去向（并不是说步骤去向没有价值，而是由步骤组成流程时，步骤去向必须是完整的闭环，虽然有校验逻辑，但是步骤去向仍然是一个看似简单，实际容易出错的参数）。

否决后怎么办？既然层级审批是否决自动中止，申请人希望根据否决意见修改原始数据后继续审批可以吗？可以，被抽象为重新发起审批。

在这个过程中，原始业务数据被允许修改的同时，会保留上次参与审批的数据快照，比对是否意见做了合理修改。这里有几个要点：

• 步骤只有层级和审批人
• 任何一步否决即中止，不再继续
• 允许申请人在否决后修改业务数据重审，并自动做好数据快照比对

扩展：

• 审批人角色扩展，支持上下级关系类的动态角色
• 金额分支的扩展（最高频分支，覆盖中小企业审批流分支95%的场景）
• 自定义动作（在审批步骤中，可以通过代码插件实现特殊的业务动作）

综上，我们完整分析了层级审批流的解决方案。从第一视觉上，它没有BPM看起来更花俏，但是在业务层却远比BPM更实用，更便捷。

本文由 @糨酱紫 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议