|电商后台设计:审核流


文章结合具体业务场景对电商后台设计中的审核功能的设计逻辑展开了梳理说明 , 并对相关问题展开了分析 , 希望通过此文能够加深你对电商后台设计的认识 。
|电商后台设计:审核流
本文插图

在工作中有许多的业务场景都涉及到审核功能 , 如请假条、加班申请、采购单等 。 既然有这么多场景都在使用审核 , 那能不能将审核功能单独设计成公共模块进行复用呢?这个肯定是可以的 , 下面我就带大家来分析一下审核功能 。
01 审核单的组成
下图是一张常见的请假单申请单 , 如果我们根据操作内容来划分 , 可以分出两个区域:业务表单区和审核表单区 。
|电商后台设计:审核流
本文插图

  • 业务表单区:业务表单区主要填写具体业务所涉及的内容信息 。
  • 审核表单区:审核表单区主要是审批人填写审核意见的区域 , 根据我们常见的审核单模板 , 可以观察到不同的审核单审批区域的可操作性内容基本一样 , 主要包含审核人、审核意见、审核状态 。
02 参与角色
审核中主要有两个角色参与其中:发起人和审核人:
  • 发起人:业务内容的创建人 , 整个审核流程的起始 , 基本操作功能包括提交审核、取消、根据审核意见修改业务表单等 。
  • 审核人:根据业务内容完成意见评审的人 , 基本操作功能包含通过、驳回、撤销、填写审核意见等 。
03 审批操作
单就审核表单来说 , 它提供的功能相对简单 , 主要有以下几个:
  • 提交审核:发起人针对当前业务发起申请进入审核流程 , 是整个审核流程的起点 , 通常由发起人手动提交 , 也有根据条件自动判断进行提交的 。
  • 通过:审核人根据业务内容做出的决策 , 满足条件则【通过】 , 审核流进入下个审核节点或结束 。
  • 驳回:与【通过】相对 , 审核人根据业务做出决策 , 不满足条件则【驳回】 , 审核流回到上个审核节点或起始节点 。
  • 撤销:审核人在完成评审后 , 在下一个(通过)或上一个(驳回)节点的审核人未作出评审前 , 可以通过【撤销】撤回评审意见 , 再次修改评审内容 。
  • 取消:发起人由于自身原因 , 在整个审核流程未完全完成时 , 主动取消了审核申请回到业务表单编辑节点 。
04 审批模型
1. 串行审批
串行审批主要是指当一个审核节点通过后 , 才能进入下一个审核节点 。 如果驳回 , 则驳回到上一个节点、或之前任意一个节点或者业务表单编辑节点 。
|电商后台设计:审核流
本文插图

2. 并行审批
并行审核是指一个审批节点同时存在多个对象可以同时审核的情况 。 当其中一个、多个或全部审核通过 , 才能进入下一个审核节点 。 如果驳回 , 通常其中一个对象驳回 , 就认为当前节点被驳回 , 其它的情况很少使用 , 如多个对象驳回、全部对象驳回 。 具体通过或驳回需要根据业务场景而定 。
|电商后台设计:审核流
本文插图

3. 混合审核
混合审核通常是指包含了串行审批和并行审批的方式 。 如下图中 , 整个流程是一个串行审核方式 , 而其中一个节点则是并行审批方式 。
|电商后台设计:审核流
本文插图

对于上面的几种方式分析后 , 可以看出 , 一个审核流通常是由多个审核节点组成 ,每个节点内最主要的任务是找到对应的审核人并作出相应的意见反馈 。


推荐阅读