殊途同归各有千秋：两种审批流解决方案.docx

《殊途同归各有千秋：两种审批流解决方案.docx》由会员分享，可在线阅读，更多相关《殊途同归各有千秋：两种审批流解决方案.docx（4页珍藏版）》请在第一文库网上搜索。

1、殊途同归，各有千秋：两种审批流解决方案审批流是企业中高频业务场景。实现审批流的方法很多，最常见的有两种抽象:1) BPM方法工作流引擎。虽然BPM的完整概念是商业业务流程，但是多数开发者把BPM结合国内情况，收敛了 BPM的范围，核心约束在：表单+流程的范围，或更缩小到自定义表单+自定义审批流程的范围。BPM的核心是：基础表单，步骤执行人，去向或者去向逻辑。2)层级审批方法更本土化的抽象逻辑，形象描述为：一层一层逐级审批。层级审批的特点是，没有步骤的去向概念，而是抽象定义为是和否两个分支：是：继续下一级别审批否：直接结束审批BPM方法的资料很多，开源资源也非常丰富，这里不再赘述。我们来谈谈更加

2、贴近本土用户使用习惯的层级审批实现方案。首先，我们回归到基础场景，以非常典型的单据订单审批为例，剖析层级审批的设计逻辑。审批的基础业务数据：订单+订单明细+ （应收计划）。这里的应收计划很容易在业务角度忽略，实际上，审批订单的核心指标是三个：1 .价格2 .交期3 .应收（计划回款）如忽略应收数据，则可能会造成大量账期拖延的应收，甚至于带来坏账风险。在我们开发人员看来，应收数据只不过是基础审批中多了一部分数据而已，关系也不复杂，并不需要花这么多篇幅来阐述。实际不然，多数业务管理系统的技术后台并不弱，UI也很现代，但是一旦融入业务运行，就会发现缺胳膊少腿，业务逻辑支离破碎。我们在用户这里学到这样

3、一句话：UI漂亮有什么用？我要跑通业务！当业务管理系统融入了企业的生产运营环境，就会发现：业务顺畅高于一切！说了半天，回归业务。用户希望是一组以订单为中心的业务数据参与审批，并在审批过程中不要被步骤审批人修改原始数据，且没有经过审批的订单，不允许被执行，不应该纳入销售类统计。那么我们总结为： 一组数据参与审批锁定参与审批的数据不允许在过程中随意修改 没有经过审批的数据不得继续执行，且不得纳入统计（这是很多用户在用了 BPM审批流之后，再用超兔的审批流，忽然发现轻松很多的原因之一。在数据层，直接用业务表本表发起审批，并通过审批状态实现业务执行约束和统计约束）审批的层级：层级，审批人。和BMP相比

4、，这里抽象简化了很多内容，因为简化所以在配置审批流时非常简单，只需要两个参数层级和审批人。因为其弱化了步骤去向的概念，用审批的要义：否决即中止，避免了设置步骤去向（并不是说步骤去向没有价值，而是由步骤组成流程时，步骤去向必须是完整的闭环，虽然有校验逻辑，但是步骤去向仍然是一个看似简单，实际容易出错的参数）。否决后怎么办？既然层级审批是否决自动中止，申请人希望根据否决意见修改原始数据后继续审批可以吗？可以，被抽象为重新发起审批。在这个过程中，原始业务数据被允许修改的同时，会保留上次参与审批的数据快照，比对是否意见做了合理修改。这里有几个要点： 步骤只有层级和审批人 任1可一步否决即中止，不再继续 允许申请人在否决后修改业务数据重审，并自动做好数据快照比对扩展： 审批人角色扩展，支持上下级关系类的动态角色金额分支的扩展（最高频分支，覆盖中小企业审批流分支95%的场景）自定义动作（在审批步骤中，可以通过代码插件实现特殊的业务动作）综上，我们完整分析了层级审批流的解决方案。从第一视觉上，它没有BPM看起来更花俏，但是在业务层却远比BPM更实用，更便捷。