百木园
审批流是企业中高频业务场景。实现审批流的方法很多，最常见的有两种抽象：
1）BPM方法
工作流引擎。虽然BPM的完整概念是商业业务流程，但是多数开发者把BPM结合国内情况，收敛了BPM的范围，核心约束在：表单+流程的范围，或更缩小到自定义表单+自定义审批流程的范围。BPM的核心是：基础表单，步骤执行人，去向或者去向逻辑。
2）层级审批方法
更本土化的抽象逻辑，形象描述为：一层一层逐级审批。层级审批的特点是，没有步骤的去向概念，而是抽象定义为是和否两个分支：
- 是：继续下一级别审批
- 否：直接结束审批
BPM方法的资料很多，开源资源也非常丰富，这里不再赘述。我们来谈谈更加贴近本土用户使用习惯的——层级审批实现方案。
首先，我们回归到基础场景，以非常典型的单据——订单审批为例，剖析层级审批的设计逻辑。
审批的基础业务数据：订单+订单明细+（应收计划）。这里的应收计划很容易在业务角度忽略，实际上，审批订单的核心指标是三个：
如忽略应收数据，则可能会造成大量账期拖延的应收，甚至于带来坏账风险。在我们开发人员看来，应收数据只不过是基础审批中多了一部分数据而已，关系也不复杂，并不需要花这么多篇幅来阐述。
实际不然，多数业务管理系统的技术后台并不弱，UI也很现代，但是一旦融入业务运行，就会发现缺胳膊少腿，业务逻辑支离破碎。我们在用户这里学到这样一句话：UI漂亮有什么用？我要跑通业务！当业务管理系统融入了企业的生产运营环境，就会发现：业务顺畅高于一切！
说了半天，回归业务。用户希望是一组以订单为中心的业务数据参与审批，并在审批过程中不要被步骤审批人修改原始数据，且没有经过审批的订单，不允许被执行，不应该纳入销售类统计。
那么我们总结为：
- 一组数据参与审批
- 锁定参与审批的数据不允许在过程中随意修改
- 没有经过审批的数据不得继续执行，且不得纳入统计（这是很多用户在用了BPM审批流之后，再用超兔的审批流，忽然发现轻松很多的原因之一。在数据层，直接用业务表本表发起审批，并通过审批状态实现业务执行约束和统计约束）
审批的层级：层级，审批人。和BMP相比，这里抽象简化了很多内容，因为简化所以在配置审批流时非常简单，只需要两个参数——层级和审批人。
因为其弱化了步骤去向的概念，用审批的要义：否决即中止，避免了设置步骤去向（并不是说步骤去向没有价值，而是由步骤组成流程时，步骤去向必须是完整的闭环，虽然有校验逻辑，但是步骤去向仍然是一个看似简单，实际容易出错的参数）。
否决后怎么办？既然层级审批是否决自动中止，申请人希望根据否决意见修改原始数据后继续审批可以吗？可以，被抽象为重新发起审批。
在这个过程中，原始业务数据被允许修改的同时，会保留上次参与审批的数据快照，比对是否意见做了合理修改。这里有几个要点：
- 步骤只有层级和审批人
- 任何一步否决即中止，不再继续
- 允许申请人在否决后修改业务数据重审，并自动做好数据快照比对
扩展：
- 审批人角色扩展，支持上下级关系类的动态角色
- 金额分支的扩展（最高频分支，覆盖中小企业审批流分支95%的场景）
- 自定义动作（在审批步骤中，可以通过代码插件实现特殊的业务动作）
综上，我们完整分析了层级审批流的解决方案。从第一视觉上，它没有BPM看起来更花俏，但是在业务层却远比BPM更实用，更便捷。
给作者点赞，鼓励TA抓紧创作！
来源：http://www.woshipm.com/pd/5459799.html
本站部分图文来源于网络，如有侵权请联系删除。