从合同审批流程出发，说说工作流引擎的设计原理

Posted 2021-03-29 泛在法治

“ 本文作者从一个合同审批流程角度对工作流的设计原理进行了介绍，供大家一同参考和学习。”

写这篇文章的意图并不是为成熟工作流引擎知识徒增一篇文章，也不是深入介绍JPBM、Aactivity等工作流引擎技术和数据库结构。而是因为当前转ToB的产品经理多了，但提及这块儿就很难深入。虽然有不少介绍工作流的文章，但大多是直接介绍BPM的体系，很少有文章从业务角度出发介绍为什么这样设计，下面我就试着从一个合同审批流程角度介绍工作流的设计原理，希望对大家有帮助。

01

—

工作流简介

工作流（Workflow），指“业务过程的部分或整体在计算机应用环境下的自动化”。是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。在计算机中，工作流属于计算机支持的协同工作（CSCW）的一部分。其主要解决的主要问题是：为了实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。说白了就是按照怎样顺序、做什么、由谁来做。

1993年工作流管理联盟(Workflow Management Coalition，WfMC)作为工作流管理的标准化组织而成立，标志着工作流技术逐步走向成熟。WfMC对工作流给出定义为：工作流是指一类能够完全自动执行的经营过程，根据一系列过程规则，将文档、信息或任务在不同的执行者之间进行传递与执行。工作流无论是减少人为操作，提供工作效率，还是优化线下业务流程，提高管理水平均有很大的帮助。

工作流经历了第一个阶段的“无纸化、重复工作、流程孤岛、系统孤岛、数据孤岛”过程，目前正在实现“智能化、效率质量提升、外部数据整合、消除信

02

—

合同审批流程

所有的信息化都是为了解决业务上需求，首先我们了解企业合同管理制度中审批流程是如何完成的。下面是一个比较通用合同审批流程图。

1. 首先所有可以起草合同并发起合同申请流程的人，即使合同承办人；

2. 合同承办人将合同提交其部分负责人（实际情况可能部长或副部长均要审批、或顺序审批、或任一审批即可）来审批，大部分还有内部审核人把关再提交其部门负责人；他们都有权退回（不合格需要修改）或驳回（彻底不签了）；如果承办部分负责人同意，可以选择相应的会签部分同步开始会签，如财务部、技术部等等。有些事必须选择，如涉及金额合同必须选择财务部。

3. 会签部门就更热闹了，三五个部分并行审批，部门内部有各自审批流程，而且均可以同意、退回，有的需要退回合同承办人，有的需要退回承办部门负责人。而且有的情况是全部同意才能算通过，有的是三分之二同意才能算通过。

4. 必须经过合同归口部门审核。一般是法律部或风险部，他们也需要退回，可能是审批过的任何一个节点，返回来的方式可能是从来一遍，也可以直接返回退回人。这里还有“是否重大合同”和“是否使用合同范本”的业务属性判断。

5. 根据业务业务类型和管辖范围，自动选择分管领导。根据授权情况判断合同流程是否到此终止，当然分管领导可以退回、驳回等。

6. 总经理可能会简单些，同意、退回、驳回。审批通过后自动触发用印或上报上级公司的审批流程。

这算是一个常规的大企业合同审批流程，如何利用信息化实现一份具体合同审批流程？简单，将每一步及其规则固化带代码中。如果换一份合同？如果换一种业务？如果规则变动？如果需要每个节点触发不同业务，显现不同信息？如果人员变动了？如何组织机构变动了？这个时候就需要我们抽取其中的共性，将其引擎化，能够通过配置实现系统的灵活性。

03

—

工作流引擎的设计

下面我们从业务的角度逐步抽象出工作流引擎的设计。遇到复杂问题一方面我需要按照第一性原理寻找最本质的需求，另一个更常规的思路就是分解，对问题进行分类分级处理，各个击破。其实，还有一种完全交个用户自己选择，如钉钉审批流程。但大型企业流程的作用除了提高效率，还需要减少人为操作、控制合规风险，完全交个用户选择的自由流程使用较少。

从上文的流程图中，可以简单抽取出流程、环节、连线、角色、组织等主要对象，还有一个就是与外部（业务）发生关系的接口。它们之间简单的关系就是流程由环节和联系组织，环节上有角色和组织属性，接口可以在连线上，也可以在环节上，下面一步步解释。

（1）流程分类（流程太多）

如果设计一个通用的工作流引擎，面对的各种业务流程、审批流程可以说成千上万，怎么办？首先想到的就是对流程进行分类，对相同类型的流程进行统一处理，降低流程需求复杂度和耦合度。目前业务操作不同进行分类的，如请假流程、报销流程、合同审批流程等等。

（2）自定义具体流程（一种流程还是太复杂）

如何合同审批流程，不同企业、不同种类，审批流程还是不一样。继续细分类别可以解决问题，但分到最后流程就需要多少个环节以及之间的关系是什么还是不确定，交个用户和运维人员搭建流程，由他们自己定义。 定义流程的名称、流程的环节、环节顺序（连线）、环节参与人员等。

（3）自定义具体环节（环节定义最复杂）

环节需要具体到做什么工作、谁来做、怎么做等，但这三个主要因素都是变量，做什么工作（即查看什么表单，同意、退回、驳回等），谁来做（通过组织、角色、群组框定出参与的候选人），怎么做（并行、串行等），这些都需要通过配置实现。另外，需要配置出发的其他业务事件等，如何合同审批完毕后自动生成合同编号。

（4）环节间的连线

上文提到在实际业务审批中，涉及金额的合同必须经过财务审批，说明流程的走向与业务属性发生了关系。因此，我需要设计在节点间连线上设置业务条件，或设计可以进行业务判断的节点，满足这种业务需求。

（5）流程实例（每个流程）

上面讲到的都是配置一种流程，即将审批制度步骤和规则放到系统中，但具体的一份合同审批流程信息即流程实例必须记录下来，一是为了留痕，再者就是流程审批中发生退回和返回需要用到这些数据，每个流程审批的业务唯一标识，每个环节实例需要记录谁在什么时间、什么意见等。

（6）流程版本（流程变更）

业务上流程变更了怎么办？这就需要对流程进行版本管理，可以实现流程变更前已经提交的流程，按照之前的版本继续进行，而流程变更后提交的流程按照最新版本进行。

（7）流程关联

本单位的流程审批完毕后，符合上报条件需要启动上级工作流程；合同审批流程中，每个会签部门内部的流程本身就比较负责，需要为会签部门搭建单独的审批流程，嵌入到合同审批流程中。以上两种情况就涉及到流程关联和子流程的问题，需要进行设计。

（8）流程设计器

以上的操作如果没有图形化支持，根本无法完成，因此，一个图形化的流程设计器是必须的。

这里只是简单介绍了一下工作的流程设计原理，还有很多复杂深入的需求和逻辑没有提到，但是有了框架和整体认识后，完全可以根据需求进行改进和设计。