aPaaS层自定义审批流产品设计

5 评论 12759 浏览 138 收藏 7 分钟

本文作者从工作项目实践出发,总结了审批流程自定义结构化设计的相关经验,供大家一同参考和学习。

审批流应用业务场景众所周知,不多做赘述。

企业规模扩张,流程变革都会引起企业内部审批流程调整,很多传统2B企业也都会因此具有流程再造,IT系统重构的需求,因此笔者主要谈谈平台自定义审批流程产品设计。

面向用户:企业IT系统管理员/系统实施人员/高级业务人员

基于以上场景可知,我们设计自定义审批流的初衷,是为了解决企业审批流程发生变更时,大规模、高成本的IT系统重构。因此设计审批流程自定义配置产品,方便企业IT运维/系统实施/高阶业务人员,通过可视化界面快速、高效的配置或者修改审批流程。

产品结构化设计

1. 审批流基本信息管理

该部分主要用于审批流程基本信息管理,其中需要重点说明的是:

(1)关联业务

这里主要是设置审批流程是基于哪个业务下发生的,如果是平台已有业务,可以直接进行关联。

如果这里审批流需要独立自定义相关的业务描述,可以通过自定义表单的形势实现,表单设计属于另一个主题,不在这里赘述。

(2)生命周期

如前面所讲,审批流随时可能会发生变更,但是历史审批流已产生历史数据,因此不能直接删除,这就需要对审批流进行生命周期管理,“禁用”的审批流程在前台是不可见、且不可操作的,但是基于该审批流所发生的历史数据是可查询的。

2. 可视化审批流程配置

可视化流程配置,按照节点属性分类设置,分为三部分:

(1)开始节点

(2)审批节点

其中重难点包括节点和节点之间的连接过程:

  1. 上个节点和下个节点是一对一节点,即为下个节点是单个节点;
  2. 上个节点和下个节点是一对多节点,即为下个节点是分支节点;
  3. 如果节点之间最终需要交汇合并,那么也可能在节点之间需要插入空节点,用于分支节点中某个节点可以跨节点到达下一个节点。

(3)结束节点

以上三部分主要用于审批流程属性配置,每一个过程都必不可少,定义的属性粒度足够细致,前台审批流程灵活性就会越高。

其中可抽象的重点能力模块有:

  1. 触发条件设置:定义触发条件,基于某种条件可以触发某种事件;
  2. 条件设置组件:选择对象下的字段,设置字段条件;
  3. 触发执行事件设置:定义触发事件,当满足触发条件时,执行触发事件。

触发事件组件:

触发器的应用场景比较多,此处可以封装成独立的触发器功能。

其他细节此处不做一一赘述,如果有描述不清楚的地方,欢迎大家随时讨论。

3. 审批流权限

企业数据涉及很多企业机密信息,因此2B产品有一个很重大的课题,就是权限设计(此处后面可以专题讨论),因此审批流也不例外。

其中需要重点关注的:

  1. 操作权限是只有当前节点的审批人,还是也要授权给管理员?
  2. 审批流查看权限,因为前面讲到,审批流都是关联业务进行的,因此是不是默认继承业务的数据查看权限?还是可以更精细的进行权限控制?

此处需要根据业务场景进一步设计,当然也欢迎大家能有更多探讨。

产品交互设计

大家应该都比较熟悉使用Visio等工具画业务流程,为了减少用户交互操作的培训,笔者也希望能够采用这种交互的方式来实现审批流程的配置过程。大致结构可参考下图:

以上,是笔者根据自己的经验总结的审批流程自定义结构化设计,仅代表个人观点,欢迎大家深入探讨,碰撞出更多火花。

 

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

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 审批发起人为什么要分为那三种类型,这三种类型分别对应什么场景?

    回复
  2. 把钉钉的审批流程配置一遍就晓得了

    来自四川 回复
  3. 干货,不错

    回复
  4. 棒,学习了

    来自四川 回复
  5. 干货

    来自北京 回复