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

工作流简介

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

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

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

1. 合同审批流程

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

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

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

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

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

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

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

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

2. 工作流引擎设计

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

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

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