工作流系统(工作流设计)

编辑导读:权限系统可以从字面上理解，赋予不同的用户不同的权限。比如管理员可以添加或者删除账号，而普通员工只能读写数据。笔者以钉钉为例，拆解权限体系和工作流程，希望对你有所帮助。

在B端产品从0到1的设计过程中，有一些基本的内容是无法回避的，比如人事制度、账号制度、权限制度、工作流程制度等等。不过这些系统都比较成熟，我们能玩的地方不多。这部分可以利用后发优势，学习行业内的产品是怎么做出来的。

给大家一个想法。SaaS产品经理可以尝试从非竞争产品中寻找设计灵感。本文主要讨论权限系统和工作流。从这两个通用模块，感觉OA系统体验不错。我们以钉钉为例，拆解权限体系和工作流程，这也是我们平时工作的一个总结。

01权限系统，RBAC(基于角色的访问控制)

权限系统可以从字面上理解，赋予不同的用户不同的权限。比如管理员可以添加或者删除账号，而普通员工只能读写数据。传统的权限系统设计将采用RBAC模型和基于角色的访问控制模型。如果不使用这种RBAC模型，用户将被直接绑定到权限。

(用户权限)

这个简单的系统非常好理解，人员改动很小就可以直接用于系统。但当人事或权限发生变动时，问题就出来了。例如，上图显示，卢晓离职，达索升职，享有卢晓的所有权利。这个时候，就会有大的变化。根据RBAC的说法，将会有一个三层结构，用户-角色-权限。通过提高维度来解决低维度灵活性不足的问题。RBAC将会是这个样子。

(用户-角色-权限)

路径可以是管理员，也可以是组长，然后路径拥有管理员和组长的所有权限。如果吕霄离开，达索可以与管理员绑定，然后与团队领导绑定。此时，角色和权限之间的关系不需要改变。

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

我们来看看钉钉的实现。

(钉钉管理员列表页面)

(钉钉管理员编辑页面)

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

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

(钉钉经理页面流程)

美甲产品已经很大了。作为平台产品，这里的权限主要是针对不同应用的访问和使用。钉钉管理组就像一个角色，成员代表用户。最后，为角色配置权限。通过引入角色将用户和权限解耦的好处是，角色和权限的直接关系不会受到任何员工离职或入职的影响。管理层需要做的只是把人丢到相应的管理组里。

这部分的管理一步完成，完成了用户-角色-权限的配置。如果想更有条理，可以先完成角色和权限的映射配置，再给角色添加人员。

除了用户角色权限的形式之外，可能会出现更复杂的问题。

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

在这里，你可以考虑优先考虑角色。如果发生冲突，则以高优先级角色对应的权限为主。

再比如角色群的问题。可以为一个角色分配权限，也应该为一组角色分配权限。如下图:

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

例如:

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

钉钉项目组作为一个角色组，可以由项目经理、前端工程师、产品经理组成。角色组有自己的权限，角色也有自己的权限。用户仍然与角色绑定，在角色组中使用时，会有与角色组和角色对应的权限。

这里，许多子类可以基于用户-角色-权限从父类派生出来。如果这部分角色处理不好，很可能会影响到第二部分提到的工作流程，这里的设计是比较完善的。

02工作流，BPM(业务流程管理)

工作流程也可以分为五个阶段，即:

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

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

工作流中涉及的角色有:申请发起人、审批人、抄送人和执行者。

根据业务情况，也会涉及有条件的分支机构。比如报销金额超过100W需要总经理审批，低于1000元可以由上级领导审批。超过30天的休假需要人力资源主管的批准，少于3天的休假可以由直线主管批准，等等。

我们来看看钉钉的工作流程。钉钉的工作流程是通过可视化编程来完成的，但和前面说的低代码属于同一类产品。钉钉的工作流程设计与氚云、明道云等非常相似。钉钉布局的低码也由此可见一斑。

(钉钉工作流程页面)

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

以钉钉休假审批为例，我们可以看到，钉钉休假工作流包含分支节点，可以判断申请条件。这一过程应该在活动框架的基础上加以完善。会有一个请假表单按照设定的工作流程循环，这里不展开表单引擎的内容。我们专注于流程设计。

钉钉设计可以动态添加审批、抄送、执行、分支节点。你应该能从字面上理解这一点。其实我想说的是，设计流程的时候有一个很重要的原则。流程的可重用性。

看一个问题。

比如卢晓是第一个R&D部门的员工，萧山是第二个R&D部门的员工，达索是第三个R&D部门的员工，三个部门是平行部门。他们各自的领导都不一样。那么，我们应该如何设计Path、Hill和达索三个人的离开流程呢？

这里，我们将使用流程可重用性的原则。这三个部门是平行的。即使三个人的领导不一样，审批的人不一样，三个人也要共用一套流程。可能是:发起人->:直线领导->: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的产品。在这个过程中，工作流和权限系统几乎是不可或缺的。

工作后可以借鉴这些成功的产品，看看这些连间接竞争对手都算不上的产品，取长补短，发挥后发优势，节省时间更快迭代产品。

本文最初由@发布丠丠丠丠丠丠丠丠丠丠丠丠丠丠丠丠𰵀丠𰵀𰵀2000000

来自Unsplash的图像，基于CC0协议。