aPaaS层自定义审批流产品设计
本文作者从工作项目实践出发,总结了审批流程自定义结构化设计的相关经验,供大家一同参考和学习。
审批流应用业务场景众所周知,不多做赘述。
企业规模扩张,流程变革都会引起企业内部审批流程调整,很多传统2B企业也都会因此具有流程再造,IT系统重构的需求,因此笔者主要谈谈平台自定义审批流程产品设计。
面向用户:企业IT系统管理员/系统实施人员/高级业务人员
基于以上场景可知,我们设计自定义审批流的初衷,是为了解决企业审批流程发生变更时,大规模、高成本的IT系统重构。因此设计审批流程自定义配置产品,方便企业IT运维/系统实施/高阶业务人员,通过可视化界面快速、高效的配置或者修改审批流程。
产品结构化设计
1. 审批流基本信息管理
该部分主要用于审批流程基本信息管理,其中需要重点说明的是:
(1)关联业务
这里主要是设置审批流程是基于哪个业务下发生的,如果是平台已有业务,可以直接进行关联。
如果这里审批流需要独立自定义相关的业务描述,可以通过自定义表单的形势实现,表单设计属于另一个主题,不在这里赘述。
(2)生命周期
如前面所讲,审批流随时可能会发生变更,但是历史审批流已产生历史数据,因此不能直接删除,这就需要对审批流进行生命周期管理,“禁用”的审批流程在前台是不可见、且不可操作的,但是基于该审批流所发生的历史数据是可查询的。
2. 可视化审批流程配置
可视化流程配置,按照节点属性分类设置,分为三部分:
(1)开始节点
(2)审批节点
其中重难点包括节点和节点之间的连接过程:
- 上个节点和下个节点是一对一节点,即为下个节点是单个节点;
- 上个节点和下个节点是一对多节点,即为下个节点是分支节点;
- 如果节点之间最终需要交汇合并,那么也可能在节点之间需要插入空节点,用于分支节点中某个节点可以跨节点到达下一个节点。
(3)结束节点
以上三部分主要用于审批流程属性配置,每一个过程都必不可少,定义的属性粒度足够细致,前台审批流程灵活性就会越高。
其中可抽象的重点能力模块有:
- 触发条件设置:定义触发条件,基于某种条件可以触发某种事件;
- 条件设置组件:选择对象下的字段,设置字段条件;
- 触发执行事件设置:定义触发事件,当满足触发条件时,执行触发事件。
触发事件组件:
触发器的应用场景比较多,此处可以封装成独立的触发器功能。
其他细节此处不做一一赘述,如果有描述不清楚的地方,欢迎大家随时讨论。
3. 审批流权限
企业数据涉及很多企业机密信息,因此2B产品有一个很重大的课题,就是权限设计(此处后面可以专题讨论),因此审批流也不例外。
其中需要重点关注的:
- 操作权限是只有当前节点的审批人,还是也要授权给管理员?
- 审批流查看权限,因为前面讲到,审批流都是关联业务进行的,因此是不是默认继承业务的数据查看权限?还是可以更精细的进行权限控制?
此处需要根据业务场景进一步设计,当然也欢迎大家能有更多探讨。
产品交互设计
大家应该都比较熟悉使用Visio等工具画业务流程,为了减少用户交互操作的培训,笔者也希望能够采用这种交互的方式来实现审批流程的配置过程。大致结构可参考下图:
以上,是笔者根据自己的经验总结的审批流程自定义结构化设计,仅代表个人观点,欢迎大家深入探讨,碰撞出更多火花。
本文由 @椰子 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
审批发起人为什么要分为那三种类型,这三种类型分别对应什么场景?
把钉钉的审批流程配置一遍就晓得了
干货,不错
棒,学习了
干货