工作的时候突然很想要怎么办（拆解权限系统和工作流）

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

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

01 权限系统，RBAC（Role-Based Access Control）

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

（用户-权限）

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

（用户-角色-权限）

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

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

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

（钉钉子管理员列表页面）

（钉钉子管理员添加人员页面）

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

（钉钉子管理员页面流程）

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

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

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

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

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

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

（用户-角色-权限，用户-角色组-权限）

举个例子：

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

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

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

02 工作流，BPM（Business Process Management）

工作流也可以划分为五个阶段，分别是：

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

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

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

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

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

（钉钉工作流页面）

（钉钉工作流添加节点页面）

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

来看一个问题。

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

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

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

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

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

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

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

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

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

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

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

（权限系统-工作流的设计流程）

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

04 最后

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

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

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

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

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

本文由 @忙里偷贤 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议