渊远流长的工作流--第16篇
用日志记录“开源软件”的诞生
【点亮星标】----祈盼着一个鼓励博主开源地址：
工作流定义
工作流诞生于企业管理和办公自动化的需要，它是针对日常工作中的业务流程管控而产生的一个概念。目的是将工作步骤分解成的任务，根据一定的原则和逻辑来完成这些任务并加以监控，从而实现更加有效的业务流程管理、更加规范的业务制度执行。
工作流不是审批流
看了工作流的定义，可能你认为已经懂了或者你认为还很抽象，没关系，我们先来探讨一个常见的理解误区：工作流就是审批流。既然说了是误区，那这个理解肯定就是错误的。只是很多人在接触工作流时往往都是通过OA里面的审批流，所以才有了这个误区。当然审批流肯定是属于工作流，但它只是工作流的一个应用。
下面我们再次回到工作流上，其实这是两个词的组合，一个是工作、一个是流程，所以从特点上已经表露无遗。首先它得是要完成的一个工作，一定是企业对人的一个管理要求，喝水它不是工作。其次这个工作必须要经历一个流程才能做完，并且在过程中要发生数据的变化，也就是说流程中必须要做点什么影响它。比如说上班打卡，它就不是流程，不需使用工作流。
到此，我想大家应该已经比较清晰为什么工作流不是审批流，因为审批只是我们日常工作中的一项工作而已，其他的工作只要涉及流程，它也是工作流，可以使用工作流系统实现管控。
工作流的应用
（1）主业务流程：订单、采购、合同审核、供应链管理、仓储管理等
（2）行政管理类：出差申请、加班申请、请假申请、用车申请、各种办公用品申请、日报周报等
（3）人事管理类：员工培训、绩效考核、工资发放流程、职员招聘等
（4）财务相关类：收付款、发票管理、费用报销、计划预算等
（5）客户服务类：客户信息管理、客户投诉、售后服务等
（6）特殊服务类：ISO管理流程、质量管理流程、进出口报关流程、物流跟踪处理流程等
举个栗子
上面说了很多工作流可应用的场景，下面我们就来找一个典型的案例来分析一下整个处理过程。以计划预算的制定为例来讲解。正常每个公司都会在年底制定一套计划预算来管控第二年的收入和支出，以保证按计划完成一年的目标。一般流程如下：
（1）公司一般会制定一个顶层的规则，包括预算上限、预算事项和科目、预算制定的颗粒度等，然后下发。
（2）公司的所有部门会根据公司制定的规则以及部门内部自己的规划制定一个部门预算，包括：人力、行政、财务、信息、业务等各个部门。
（3）制定完成后，上报上级领导审批，并通过几轮商议并敲定。
（4）各部门的预算确定后，会有专人汇总预算并核对公司的规则，接着交给董事会审批。
（5）审核后，会有专人负责重新下发给各部门以及内部发文通知。
计划预算这个例子，比较典型，因为它包含了审批、包含了业务处理、甚至包含了不同系统的协作。由此可见，涉及到使用工作流的场景往往是业务或逻辑复杂场景，工作流适合帮助企业把复杂的事情变得简单，把逻辑梳理的清晰有序。
工作流系统如何实现
由于篇幅原因，下一篇文章我会具体介绍工作流的框架，以及如何整合部署。本篇我就先用自己的语言总结一下，要实现一个工作流引擎都需要哪些功能。
（1）流程图，不管是使用通用的工作流引擎还是自己开发，我们一定首先需要指定流程，指定流程的方式多种多样，可以采用配置的形式，也可以直接通过画流程图的方式（最终也会形成一个可数据化的流程xml）。不管用什么方式这一步是核心，告诉系统你的流转过程。
（2）数据库，所有的流程信息、节点信息、任务信息、历史信息、用户信息都必须存储于数据表中，每一个操作也会直接反馈给表中的数据。
（3）任务的使用，任务是一个重要的概念，流程流转的是任务，我们无需记录任务的具体内容，这是业务系统需要考虑的事情，我们只需要记录任务的流转过程即可。可以给任务做个分类，分为人工执行的和系统自动执行的。
（4）流程变量，这个概念也同样的重要，因为没有一个流程是绝对固定的，它的流转分支以及逻辑判定必须是动态的才有意义。而动态也就意味着必须在流程启动时才能确定某些数据的值，这个值的传入就必须要通过流程变量实现。
（5）历史记录，每一个已经流转完成的流程都需要详细的历史记录，这是必须的，可以排除风险并确定责任。
（6）可调用的工具类或接口，流程中执行的每一个操作：启动、终止、通过、退回，都需要用户手工或系统自动触发，所以要提供所有可执行的API。
在很多开源的流程引擎框架里，并没有考虑太多的国内的使用需要，所以我们在设计或客户化我们的工作流系统时，要考虑到各种特殊情况。比如：撤回、终止、回调等。
后记
如果您对我们正在做的开源软件感兴趣，欢迎各种形式的合作，作为贡献者或直接加入我们！让我们一起打造一套开源的企业级信息化解决方案。
【码云】或【GitHub】搜索“赤龙ERP”点击星标，亦可加入我们！ 让我们从小开始做点伟大的事！