编辑导读:权限系统可以从字面上理解,赋予不同用户不同的权限,比如管理员可以增删账户,普通员工只能读写数据。本文作者以钉钉为例,拆解权限系统和工作流,希望对你有帮助。

以钉钉为例,拆解权限系统和工作流插图

在B端产品从0到1设计的过程中,有一些基础内容是绕不开的,比如人员系统、账号系统、权限系统、工作流系统等等。但是这些系统也相对成熟,可以玩出花的地方也不多,对于这部分我们倒可以占据后发优势,去学习行业内的产品是怎么做的。

这里给大家提供一个思路,SaaS的产品经理可以试着从非竞品找到设计灵感。我们这篇文章主要聊一下权限系统和工作流,单从这两个通用模块来看,感觉OA系统有比较不错的心得。我们以钉钉为例做一个权限系统和工作流部分的拆解,也算对平时工作的一个总结。

01 权限系统,RBAC(Role-Based Access Control)

权限系统可以从字面上理解,赋予不同用户不同的权限,比如管理员可以增删账户,普通员工只能读写数据。常规权限系统设计会用到RBAC模型,基于角色的访问控制模型。在没用到这个RBAC模型的情况下,用户会和权限直接绑定。

以钉钉为例,拆解权限系统和工作流插图(1)

(用户-权限)

这个对于简单系统是非常易懂的,对于人员变动不大的系统也是可以直接上手使用的。但是当有人员变动或者权限变动的时候,问题就出来了。以上图为例,小路离职,索大升职,享有小路的全部权利,这个时候会产生比较大的变动。而根据RBAC,那么就会有三层结构,用户-角色-权限。通过升维解决低维灵活度不够的问题。RBAC会是下面这个样子。

以钉钉为例,拆解权限系统和工作流插图(2)

(用户-角色-权限)

小路可以是管理员,也可以是组长,然后小路具有管理员和组长的所有权限。如果小路离职了的话,索大可以和管理员进行绑定,再和组长绑定。这时候角色和权限的关系是不需要改变的。

RBAC还有很多的变体,比如互斥角色、比如角色具有上下级关系,可以参考《RBAC权限系统分析、设计与实现》这个博客。

我们看看钉钉的实现方式。

以钉钉为例,拆解权限系统和工作流插图(3)

(钉钉子管理员列表页面)

以钉钉为例,拆解权限系统和工作流插图(4)

(钉钉子管理员编辑页面)

以钉钉为例,拆解权限系统和工作流插图(5)

(钉钉子管理员添加人员页面)

这是钉钉后台的管理系统,在子管理员页面里会有添加管理组,添加管理组人员,设定管理组的管理员,设置权限等。管理组会有一些默认的管理组,也可以由用户新增。操作顺序可以是:

以钉钉为例,拆解权限系统和工作流插图(6)

(钉钉子管理员页面流程)

钉钉产品已经非常庞大了,作为一个平台产品,这边的权限主要是针对不同应用的访问和使用。钉钉的管理组就像一个角色,而成员就代表着用户,最后为角色配置权限。引入角色对用户和权限进行解耦的好处是,任何员工的离职入职,都不会影响到角色和权限直接的关系。而管理要做的,只是把人丢到对应的管理组即可。

钉钉对于这部分的管理是一步到位的,完成了用户-角色-权限的配置。如果想要条理更清晰一些,可以先完成角色和权限的映射配置,再往角色里添加人员就可以了。

除了用户- 角色- 权限这种形式,还可能出现更为复杂的问题。

比如权限的冲突,小路有两个角色,一个角色是管理员,一个角色是组长,组长有开除员工的权限,管理员没有开除员工的权限,那么小路最后应不应该有开除员工的权限?

这里可以考虑给角色加上优先级,出现冲突了以优先级高的角色所对应的权限为主。

再比如,角色组的问题。一个角色可以对应分配权限,而由角色构成的集合应该也可以被分配权限。如下图:

以钉钉为例,拆解权限系统和工作流插图(7)

(用户-角色-权限,用户-角色组-权限)

举个例子:

  • 用户:小路、小山、索大
  • 角色:项目经理、前端工程师、产品经理
  • 角色组:钉钉项目组
  • 权限:项目进度管理、项目组聊天窗、产品原型设计、产品开发

钉钉项目组作为角色组,可以由项目经理、前端工程师、产品经理这几个角色组成,角色组有自己的权限,角色也有自己的权限,用户还是和角色绑定,用在角色组里会有角色组的对应的权限,也会有角色对应的权限。

这里基于用户-角色-权限这个父类可以派生出很多子类。这部分角色没有处理好的话,很可能会影响到第二部分说的工作流,钉钉在这里设计的相对完善。

02 工作流,BPM(Business Process Management)

工作流也可以划分为五个阶段,分别是:

  • 业务流程发掘(Business Process Discovery)
  • 业务流程设计(Business Process Design)
  • 业务流程执行(Business Process Execution)
  • 业务流程管理维护(Business Process Administration)
  • 业务流程最优化(Business Process Optimization)

我们产品里常用到的是申请和审批,属于业务流程的设计。

工作流里所涉及到的角色有:申请发起人、审批人、抄送人、执行人。

根据业务情况还会涉及到条件分支,比如报销金额超过100W,需要总经理批,低于1000元,上级领导批就可以;请假时间超过30天需要人力主管批,低于3天直线主管批就可以等等。

我们看一下钉钉的工作流。钉钉的工作流是通过可视化编程做的,其实和之前说的低代码属于同一类产品,钉钉的工作流设计和低代码平台氚云、明道云等等非常像。对于钉钉布局低代码也可以从这看到必然。

以钉钉为例,拆解权限系统和工作流插图(8)

(钉钉工作流页面)

以钉钉为例,拆解权限系统和工作流插图(9)

(钉钉工作流添加节点页面)

我们以钉钉的请假审批为例,可以看到钉钉的请假工作流是包含分支节点的,能够进行申请条件的判断。这个流程应该是基于activity的框架进行完善的。这里面会有一张请假表单按照设定好的工作流进行流转,涉及到表单引擎部分的内容我们这边不拓展。我们重点关注流程设计。

钉钉的设计,是可以动态添加审批、抄送、执行、分支节点的。这个按字面意思大家应该能理解。其实我想说的是,在设计流程的时候有一个非常重要的原则。就是流程的复用性。

来看一个问题。

比如,小路是研发部一部的员工,小山是研发部二部的员工,索大是研发部三部的员工,三个部门是平行部门,他们各自领导不一样。那么小路,小山,索大三个人的请假流程应该怎么设计?

这里会用到我们说的流程复用性的原则,三个人部门平行,即使三个人领导不同,审批他们的人不同,但是三个人应该是共享一套流程的。可能是:发起人—>直线领导—>HR—>结束。所以在流程设计的时候要想实现流程的复用,其实并不是一件简单的事情。

钉钉给出的设计思路其实是比较接地气也能解决问题的,大家也可以对比看看企业微信,两家产品在审批人选择这部分交互是比较类似。我们具体来看一下。

  • 指定人员:指定具体的人,钉钉限制了20个人。这部分要慎用,一旦流程指定到具体的人,一个是复用性变差,第二是一旦有人离职,容易造成流程的崩溃。
  • 发起人自选:在发起人提交申请时,自行选择一个人批复。这种情况很适用于请假半天,需要有人知道就好的情况,不是很重要的申请可以这么设计。
  • 连续多级主管:这个功能比较好用,也可以直观理解。小路是一个研发工程师,小山是下路领导,索大是小山领导。当选择多级主管的时候,级数选择2,那么下路的申请会顺着report line一直到索大那边。
  • 部门主管:指定某个部门的领导,比如请假要指定到HR主管,报销要指定到财务主管。
  • 直属主管:指定到个人的直接上级。
  • 表单内部门控件对应主管,表单内部门控件对应角色:这里我放在一起说,这部分功能是比较处理复杂情况的时候需要用的,比如表单内部门控件对应角色,小路是研发部一部的部长,小山是研发部的前端工程师,索大是研发部产品经理。但是部门有一个助理角色,帮助部长处理事务的,这个助理不是岗位,是角色。索大是研发部一部的助理。所以当要指定到角色的时候,就可以通过表单内部门空间对应角色指定到一个虚拟的角色,而不是实际的岗位。这边比较绕,而且没有特别好的描述。所以我说钉钉这块比较接地气,但是很能解决一些实际需求。
  • 角色:虚拟设置的角色,供指定,指定角色的好处,和前文说的RBCA是一样的,角色是一个抽象,可以带来更好的拓展性和灵活性。
  • 发起人自己:这个没什么好说的,可能表单流转过程会有某个时刻需要流回自己手里。
  • 表单内的联系人:这个也是一个灵活性比较高的功能,是指表单内有控件出现了联系人,在这个位置可以选为当前节点的执行人。

这一块对比下来,钉钉思考的情况比较全面,所以这部分内容对于需要设计流程的B端产品来说,是非常好的学习案例。

自己做了一些流程的工作,这里说说感受。

因为要把定义流程的工作交给用户,那么用户可能会设计出现各种奇奇怪怪的业务流程,而B端产品要能支持这些流程,一定是要有非常高的灵活度和非常极致的抽象。

所以这部分内容其实考验产品经理的三个能力:对于业务需求的抽象能力、对于产品落地交互的具象能力,以及咨询里说的MECE熟练度。而市面上做的好的产品是提供了落地实现的,这也是能节约我们大量时间的环节。

啰嗦一句,就是借鉴的过程,需要弄清原产品背后的逻辑。比如钉钉里的选择人员,为什么要给这么多选项,我们自己的产品需不需要这么多选项?这些都是要自己思考清楚的。

03 权限系统和工作流存在要素重叠

把权限系统和工作流放在一起写,是因为二者会有一些重叠关系。认真看文章的小伙伴应该发现了,角色这个词是贯穿这两部分的。我们看看如果一个B端产品,需要从0到1设计这两部分会是怎样?

以钉钉为例,拆解权限系统和工作流插图(10)

(权限系统-工作流的设计流程)

我们创建的角色,可以作为权限系统里去分配权限,也可以在工作流里作为审批的执行人。角色本质是一层抽象,抽象的好处就在于能够解耦用户和权限,解耦用户和审批人。抽象会带来更多的复用性。

04 最后

B端产品在设计权限和工作流的时候,非常建议大家去看看钉钉、企微这些OA系统。审视OA产品,会发现OA系统对于权限,角色,工作流,玩的很明白,是非常好的学习方向。

飞书的审批功能目前看起来比企微和钉钉的审批要弱化一些,这和产品定位也有一些关系,飞书强在效率提升,钉钉强在办公管理,企微强在关系链接,产品的基因会决定产品功能。

但是相信有钉钉、企微的先行探索,飞书也是能快速赶上的,毕竟存在后发优势。

现在SaaS是一个很火的领域,C端产品从0到1的设计产品的机会越来越稀少,SaaS的产品经理会有更多机会能够从0到1设计产品。在这个过程中,工作流和权限系统几乎不可或缺。

大家之后工作中,可以借鉴这些做的比较成功的产品,看看这些甚至连间接竞品都算不上的产品,学习他们的强势,发挥自己的后发优势,节约时间去更快的迭代产品。