审批流设计(OA 系统)

14 评论 45873 浏览 260 收藏 8 分钟

编辑导语:对具备一定规模的公司来说,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 审批方案管理

前两个模块,都是为了审批方案做的基础工作。真正使用到业务中的,就是审批方案。

以财务用款审批方案为例,看如何设计审批方案。

举例

  1. 用款需要员工发起,最终是审批人是财务
  2. 如果是金额小于等于 1000 元(部门 A 金额小于等于 2000 元),需要直属 leader 审批,或者至少是 2 级审批人审批通过;
  3. 金额大于 1000 元(部门 A 金额大于2000 元),小于 1w 元,需要财务 BP 和部门 VP 审批通过
  4. 金额大于等于 1w,需要 CFO 审批
  5. 以上都审批完成后,最后通知财务打款

从上面的例子可以看出,审批方案分为审批规则和审批流。

1. 审批规则

业务规则:不同的业务审批流,都会有特殊的规则判断,比如财务、考勤、行政采购、人事转正等,我大致列了一些常用的规则字段。

  • 财务:金额(参考上面例子);
  • 考勤:休假类型和天数,如事假、年假、产假等;
  • 行政类:有采购数量和采购价格等,如超过 5000 元采购申请,需要主管审批
  • 人事类:如转正流程,有职级判断,比如说 P7 以上转正要 VP 审批等

特殊情况还会根据部门,走不同的审批流程,这里要基于业务场景来考虑

但也要留意一下特殊场景,比如说审批人缺失,可以跳过这个环节继续审批,直接终止审批,或者跳转到某个具体的人来处理这个事情。

2. 审批方式

包括依次审批、协同审批,以及仅通知。

  • 协同审批:适合某个角色中,有多个成员,只需要一个人同意或拒绝就可以完成审批。
  • 依次审批:当存在多个步骤,每个步骤中有多个审批人的时候,需要所有人都审批通过,才能进入下一步。

当某一个人或角色,仅仅告知审批结果的,可以选择仅通知方式。

如下图,某一个没有分支条件的参考示例。

3. 可结束审批节点规则

做这个的目的是避免很小的流程,就走很长的审批,比如说金额小于 1000 的,到 2 级审批人就可以结束审批,但较大金额的比如超过 10w的用款,则只能 CFO 审批结束。

4. 审批流设置

这个对产品经理来说,就是一个流程图,相对简单,只要审批规则、审批方式等提前定义好,这就是最简单的配置。

04 总结

审批流是 OA 的核心模块,一个灵活的审批流管理方案,不仅仅能满足 OA 系统,还能对外输出给其他系统,作为系统内部审批流来实现,比如 EHR 的绩效审批等。

#相关阅读#

绩效系统设计(OA 系统篇)

从 0 到 1 搭建薪酬系统(OA 系统篇)

#专栏作家#

司马特小队,公众号:司马特小分队,人人都是产品经理专栏作家。8年+互联网资深产品经验,多年B端产品管理经验。具有多个从0到1的大型B端产品的孵化、重构、迭代经验;主要教授产业互联网产品相关的硬核知识点。

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

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 太浅了 真正要做一个系统 这点知识是不够的

    来自广东 回复
    1. 同意。不说业务上的会签、或签的抽象概念,就是排他、并行网关设计,或者连 BPMN 等背后的一些基本引擎概念都没提到,一直在表层做文章。后续需求改动时,研发改动成本会很大。

      来自上海 回复
  2. 想请问下大佬
    为什么需要做默认审批流呢?

    来自广东 回复
  3. 您好,能向您请教个问题吗
    如果员工角色不固定,是处于流转状态,那么,怎么设计请假审核的审批流呢?
    比如住院医师,在医院住培期间,每个科室可能待1-3个月不同的时间,每次在不同科室请假时,会涉及到不同科室管理者审批!

    回复
    1. 我觉得可参考钉钉的请假 由员工自动选择审批人 抄送人

      来自广东 回复
  4. 受教

    来自辽宁 回复
  5. 你好能请教你一个问题么?
    一个审批流,开始状态是 “草稿” 发起人可编辑删除 , 如果审批人审批驳回后状态是定义一个“驳回”状态还是直接打回“草稿”状态,如果定义一个”驳回“ 状态 又让发起可以编辑删除?

    来自浙江 回复
    1. 考虑下,什么情况下需要删除?是不是删除本身就是个伪需求呢?

      来自浙江 回复
    2. 不太懂审批流背后的业务背景,作者能介绍下这个审批流相关的业务背景吗?

      来自上海 回复
    3. 感觉这个是有两种情况:
      1、填写的申请内容有问题,审批人驳回,要求修改申请信息。当通过驳回的动作线回到申请人环节,申请人应该是有权限修改申请表单的信息。
      2、审批人不同意此次申请,当驳回后,申请人可通过”取消申请“动作线,结束掉本次申请。申请人能不能修改申请信息,并没有什么影响,因为在实际正常操作下,当审批人不同意驳回后,申请人即使修改也无意义。

      来自广东 回复
    4. 是否可以在审批人审批的时候增加操作,根据实际情况判断,是【退回修改】或者【拒绝】,如果是退回修改的话,可以支持申请人重新编辑再次提交审批;如果是拒绝的话,则显示拒绝状态,发起人这边仅可查看,不可以有其他操作。

      来自上海 回复
  6. 很好的总结,谢谢大佬分享

    来自四川 回复
  7. 感谢

    回复
  8. 感谢,非常有用

    回复