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

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

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

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

工作流业务场景示例

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

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

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

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

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

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

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

简道云流程设计

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

审批流操作及状态关系

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

状态下的操作

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

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

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

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

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

事项生命周期管理

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

工作流设计

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

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

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

软件系统架构

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

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

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

API接口编排设计

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

低代码平台框架

本文由@壹叁零壹原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。