零代码核心模块之二:工作流

0 评论 3087 浏览 16 收藏 11 分钟

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

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

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

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

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

工作流业务场景示例

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

一、审批流

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

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

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

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

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

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

简道云流程设计

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

审批流操作及状态关系

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

状态下的操作

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

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

二、工作流

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

常见如 :需求管理,问题管理,缺陷管理。

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

事项生命周期管理

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

工作流设计

三、业务流

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

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

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

软件系统架构

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

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

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

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

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

API接口编排设计

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

低代码平台框架

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

题图来自 Unsplash,基于 CC0 协议

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!