工作流细分类为：审批流、工作流、业务流，其复杂度逐步上升。本文就这几个流程进行逐个拆解，以期给你一些启发，在业务流程中更加规范化。

工作流细分类为：审批流、工作流、业务流。

审批流：由发起人发起事项的审核，经相关人员共同确定，则该事项是否可继续执行的审核确认流程；常见场景如：请假、用车、报销、出差等。

工作流：某一个工作事项在多角色参与下，让事项得以最终实现，实现单事项的生命流程全管理；常见场景如：需求管理、缺陷管理、问题管理等。

业务流：实现完整的业务流程，一般包含多个工作流；常见场景如：产品开发管理、公司运营管理、学校产学研管理等。

工作流业务场景示例

审批流、工作流、业务流，其复杂度逐渐上升，以下进行逐步拆解。

一、审批流

审批流简单理解是一个事项，经过层层确认，最终确认能否执行。审批流主体信息主要包含：事项，审批人，审批记录，审批结果。

事项：描述清楚这个待审批的具体内容，如：请假需描述清楚请假人、请假类型、请假时间、请假原因，附注工作情况等。这个部分可以由表单实现。

审批人：是整个审批流中最核心的部分，设置流程节点及该节点处理人。

如：请假审批流设置为 直接领导、上级领导、人事、财务审批。存在特殊情况，在审批流因为表单填写某个具体内容不同而进行分支的情况。比如，请假超过3天要送总经理审核。

审批记录：记录审批人对表单的审批信息，包含审批人、审批时间、审批结果、审批意见，便于对流程审核过程进行跟踪、回溯。

审批结果：审批结果一般是通过或拒绝，通过则表示该事项可以执行，如：请假通过，则可以开心地进行休假；拒绝则表示该事项不可以执行，这种情况一般都有调整意见，修改之后，可以再次发起审批。

简道云流程设计

如图所示，为简道云审批流配置，设置审批流审核节点及节点属性。

审批流操作及状态关系

其中，审核1 到 审核N 到 审核(最后) 模拟整个审核过程，这是整个流程中最直观的操作，以及操作如何修改状态。可算作 审批流MVP（最小最有价值功能集）功能交互。

状态下的操作

基于整个审批过程，可对交互过程增加扩展功能，更为易用。审核过程卡在某一个环节时，支持“催办”；审核具体情况可通过“审核进度”跟进；某个明确具体原因错误只需要某个人处理，可以“指定回退”。

审批流主要表现，关键信息一致，不同人员查看信息的着重点不同，从而给予不同的审批结果。审批流引擎的实现，可以支持 请假、报销、用章、用车、出差、资产领用 等业务场景，是OA系统实现的核心支柱。

二、工作流

工作流简单表述为 事项经过多人分工处理，最终完成的业务情形。

常见如 ：需求管理，问题管理，缺陷管理。

示例：一个问题由提出人提出，由问题管理员完善并分派，由问题处理人处理，由质量相关人员验证，由问题提出人确认是否处理妥当。主要体现为一个事项的生命周期管理。

事项生命周期管理

因具体业务的区别，不同事项的生命周期不同；因具体业务执行团队的不同，相同事项在不同团队中也可能生命周期不同。事项针对不同生命周期，有不同的信息记录。如：问题分派时，需要记录分派人、分派时间、分派给哪个团队或哪个人员、分派意见；问题处理，主要记录处理人、处理时间、处理方法、后续注意事项等。

工作流设计

三、业务流

业务流简单表述则是多事项的流转，一个事项的处理，调启另一个事项待处理，最终整条链条的相关事项都处理完成。只是在实际情况中，同一类型事项会有多个，会存在每个事项都有在进行中的情况。

示例：简化的采购流程：库存管理 — 备货申请 — 采购订单 — 入库调整。报废、销售 会减少库存，新品入库 会增加库存，当库存低于警戒值时，需要发起备货申请，则是第一环节【库存管理 — 备货申请】；当备货申请审批通过时，生成采购订单，发起采购流程，则是第二环节【 备货申请 — 采购订单】；采购订单通过物流采购货品成功，进行入库，则会修改库存情况，则是第三环节【采购订单 — 入库调整】。

业务流 流转实际上就是系统本身的本质。

软件系统架构

按照业务主体的不同，经典系统组成完整的生态链。这就是 SRM、MES、QM、WMS、TMS、CRM、ERP系统来源。但是因为各个公司具体业务的不同，处理同一块业务的也会有不同。CRM系统可以是线索、商机管理系统，也可以是客户、协议、合同管理系统，但终归都整合的是客户关系管理业务。系统拆解有多种方式和角度，由业务流生成系统是其中一个角度，这个角度是 低代码模型驱动的视角来源。

这个角度离不开业务建模思维。一个个事项可以梳理为一个个对象，对象本身支持工作流全生命周期管理；而对象之间支持对象状态变化生成另一个对象，甚至多个对象。

示例：库存管理、备货申请、采购订单 都是一个个对象，对象本身支持增删改查；备货申请通过，也就是某个备货申请实例状态修改为已通过时，依据备货申请直接生成采购订单，并且同时可以生成一个信息对象实例，实现发送一条消息。

从低代码当前实现视角，可以拆解为：页面、数据、业务逻辑。这是低代码表单驱动视角来源，这个角度离不开API接口调用思维。一个系统可以拆解为一个个页面，备货申请列表页、备货申请添加页面、备货申请编辑页面、备货申请详情页面等等。数据库存储着一条条数据。

在备货申请编辑页面先回显备货申请信息，修改之后，再保存回数据库。页面和数据的互动，就靠业务逻辑来实现，要不要更新、要不要删除都是业务逻辑来实现。而在技术角度，业务逻辑就是一个个API接口。

API接口编排设计

在低代码平台详细拆解的路上，终于再向前一步走。权限、组织、用户 作为系统软件的基础，已完成拆解；表单、流程作为低代码页面重要展示部分，已完成拆解。

低代码平台框架