审批流设计(OA 系统)
编辑导语:对具备一定规模的公司来说,OA是非常常见且致力于提高效率的一套系统。本文对OA系统中审批流模块设计展开分析,笔者拆解了详细的流程步骤,并对设计过程中的一些问题进行了思考总结,希望能够给你带来些启发。
审批流,是OA 系统的最核心模块,大部分的功能模块都会和审批流关联,一个好的审批流管理方案,能极大减少产品和研发的工作量。
审批流管理,包括以下 3 个模块:角色管理、审批关系管理、审批方案管理。通过审批方案聚合了角色、审批关系、以及审批规则,形成一套符合业务流程的审批流,基于具体的场景,走不同的人员审批。
01 员工角色管理
员工角色是审批流中的基础,能很大程度上减轻审批流维护成本。从结构上分为 3 个部分:员工基本信息、角色管理和审批等级。
员工基本信息是不变的(一般由 EHR 系统维护),可以读取 EHR 系统中的数据,确保员工信息的准确。
角色管理分为角色名称和员工管理的团队范围,举例:张三是市场部和销售部的 HRBP,那张三的角色是HRBP,管理的部门「市场部」、「销售部」,当这两个部门有属于 HRBP 的审批信息,就都会通知到张三。
一个员工可以有多个角色和多个管理部门,一个角色也可以包括多个员工,这样的好处,是如果有员工入离职或调岗,不需要修改审批流,只需要在角色中增加或减少员工即可。
02 审批关系管理
审批关系管理,是即默认审批流,分为「汇报关系管理」、「汇报类型管理」和「审批等级」。
1. 汇报关系
是一个标准的树状结构,每个员工都会有唯一的主汇报人,但会有虚线汇报和特殊汇报关系,比如 HRBP 除了向 HR 部门 VP 汇报之后,还会向负责的业务部门 VP 虚线汇报。
2. 审批等级
审批是根据审批内容,来判断需要到那个层级的管理者审批的。
举例:请假 1 天直属 leader(1 级审批人) 和团队负责人(2 级审批人)就可以结束审批,休假 3 天以上,就需要通过部门负责人(3 级审批)审核。
审批等级的好处,是在配置审批流的时候,可以根据审批条件,精准的判断可截止的审批层级。
一图胜千言,可以看下这个结构图。
03 审批方案管理
前两个模块,都是为了审批方案做的基础工作。真正使用到业务中的,就是审批方案。
以财务用款审批方案为例,看如何设计审批方案。
举例
- 用款需要员工发起,最终是审批人是财务
- 如果是金额小于等于 1000 元(部门 A 金额小于等于 2000 元),需要直属 leader 审批,或者至少是 2 级审批人审批通过;
- 金额大于 1000 元(部门 A 金额大于2000 元),小于 1w 元,需要财务 BP 和部门 VP 审批通过
- 金额大于等于 1w,需要 CFO 审批
- 以上都审批完成后,最后通知财务打款
从上面的例子可以看出,审批方案分为审批规则和审批流。
1. 审批规则
业务规则:不同的业务审批流,都会有特殊的规则判断,比如财务、考勤、行政采购、人事转正等,我大致列了一些常用的规则字段。
- 财务:金额(参考上面例子);
- 考勤:休假类型和天数,如事假、年假、产假等;
- 行政类:有采购数量和采购价格等,如超过 5000 元采购申请,需要主管审批
- 人事类:如转正流程,有职级判断,比如说 P7 以上转正要 VP 审批等
特殊情况还会根据部门,走不同的审批流程,这里要基于业务场景来考虑
但也要留意一下特殊场景,比如说审批人缺失,可以跳过这个环节继续审批,直接终止审批,或者跳转到某个具体的人来处理这个事情。
2. 审批方式
包括依次审批、协同审批,以及仅通知。
- 协同审批:适合某个角色中,有多个成员,只需要一个人同意或拒绝就可以完成审批。
- 依次审批:当存在多个步骤,每个步骤中有多个审批人的时候,需要所有人都审批通过,才能进入下一步。
当某一个人或角色,仅仅告知审批结果的,可以选择仅通知方式。
如下图,某一个没有分支条件的参考示例。
3. 可结束审批节点规则
做这个的目的是避免很小的流程,就走很长的审批,比如说金额小于 1000 的,到 2 级审批人就可以结束审批,但较大金额的比如超过 10w的用款,则只能 CFO 审批结束。
4. 审批流设置
这个对产品经理来说,就是一个流程图,相对简单,只要审批规则、审批方式等提前定义好,这就是最简单的配置。
04 总结
审批流是 OA 的核心模块,一个灵活的审批流管理方案,不仅仅能满足 OA 系统,还能对外输出给其他系统,作为系统内部审批流来实现,比如 EHR 的绩效审批等。
#相关阅读#
#专栏作家#
司马特小队,公众号:司马特小分队,人人都是产品经理专栏作家。8年+互联网资深产品经验,多年B端产品管理经验。具有多个从0到1的大型B端产品的孵化、重构、迭代经验;主要教授产业互联网产品相关的硬核知识点。
本文原创发布于人人都是产品经理,未经许可,禁止转载
题图来自Unsplash,基于CC0协议。
太浅了 真正要做一个系统 这点知识是不够的
同意。不说业务上的会签、或签的抽象概念,就是排他、并行网关设计,或者连 BPMN 等背后的一些基本引擎概念都没提到,一直在表层做文章。后续需求改动时,研发改动成本会很大。
想请问下大佬
为什么需要做默认审批流呢?
您好,能向您请教个问题吗
如果员工角色不固定,是处于流转状态,那么,怎么设计请假审核的审批流呢?
比如住院医师,在医院住培期间,每个科室可能待1-3个月不同的时间,每次在不同科室请假时,会涉及到不同科室管理者审批!
我觉得可参考钉钉的请假 由员工自动选择审批人 抄送人
受教
你好能请教你一个问题么?
一个审批流,开始状态是 “草稿” 发起人可编辑删除 , 如果审批人审批驳回后状态是定义一个“驳回”状态还是直接打回“草稿”状态,如果定义一个”驳回“ 状态 又让发起可以编辑删除?
考虑下,什么情况下需要删除?是不是删除本身就是个伪需求呢?
不太懂审批流背后的业务背景,作者能介绍下这个审批流相关的业务背景吗?
感觉这个是有两种情况:
1、填写的申请内容有问题,审批人驳回,要求修改申请信息。当通过驳回的动作线回到申请人环节,申请人应该是有权限修改申请表单的信息。
2、审批人不同意此次申请,当驳回后,申请人可通过”取消申请“动作线,结束掉本次申请。申请人能不能修改申请信息,并没有什么影响,因为在实际正常操作下,当审批人不同意驳回后,申请人即使修改也无意义。
是否可以在审批人审批的时候增加操作,根据实际情况判断,是【退回修改】或者【拒绝】,如果是退回修改的话,可以支持申请人重新编辑再次提交审批;如果是拒绝的话,则显示拒绝状态,发起人这边仅可查看,不可以有其他操作。
很好的总结,谢谢大佬分享
感谢
感谢,非常有用