后台产品同学在设计后台时,会发现一般后台的各个功能模块总结起来有两大类型:功能类、流程类。在设计功能或流程前都需要预判不同的使用角色对应不同权限,设计流程前则还得思考最基本的工作流原理。
用户权限是设计后台普适的基本管理功能,设计系统时几乎都需要考虑权限问题。后台系统在面对不同部门不同岗位的人员时,如何区分授权?在考虑前端不同身份的用户访问时(如普通用户、普通会员、超级会员),如何自动判断权限?工作流则是设计流程需要具备的基本理论,一个完整的流程会会包含哪些节点动作?节点是否可自主配置?
本文主要总结后台设计的基石:RBAC和workflow。
RBAC
1、什么是RBAC
RBAC(Role-Based Access Control)基于角色的访问控制。这是从传统的权限模型基础上,改进而来并且相当成熟的权限模型。这里强调三个要素:用户、角色、权限。用户与角色是多对多关系,角色与权限是多对多关系。
传统模型中无角色概念,直接为用户赋上权限,一是导致配置权限相当麻烦,二来无法快速为多个用户批量删除权限。用户—角色—权限多对多的关系,解决了这些问题。
关键元素:
- 用户:成功认证并登录系统的操作员(主体:who)
- 权限:访问资源的许可(how)
- 角色:权限的集合体
- 资源:引入这第四个概念,包括系统菜单、页面、按钮等(what)
主体(who)如何通过权限(how)访问资源(what resource)。
权限是用来访问资源的,为用户赋予权限,则可访问资源;在权限基础上,将权限打包为一个权限集合—角色,如财务经理角色,则为用户赋上财务经理角色,用户可访问财务经理角色下的资源集合。
2、RBAC模型解读
根据RBAC的复杂度不同,可分为RBAC0,RBAC1,RBAC2,RBAC3.最常用的为RBAC0.
(1)RBAC0模型
将一个或多个权限挂到角色下,在将一个或多个角色赋予用户,权限与角色的关系,角色与用户的关系,均是多对多的关系。
场景。为财务经理岗建立财务经理角色,将对账、付款审批、回款确认等权限配置在财务经理角色下,则公司再更换财务经理人员,只需每次为新来的财务经理配置财务经理角色。
为客户经理建立客户经理角色,客户管理、客户查询、抢单等权限配置在客户经理角色下,适应于公司流动性高且占比庞大(多的甚至上千人)的客户经理群体,若某个权限不适宜配置给客户经理,直接在角色中删除即可,无需分别对每个人进行权限删除。
(2)RBAC1模型
引入继承概念,一个角色可以从另一个角色继承许可权。角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系允许角色间的多继承,受限继承关系则进一步要求角色继承关系是一个树结构。
场景。适用于角色之间的层次明确,如总经理与副总经理,业务部门如总经理–团队经理–业务员。也适用于用户分级管理,初级用户只能使用部分功能,中级用户能够使用更多功能。
(3)RBAC2模型
加入了角色的访问控制。规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
包括静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic DSD(Dynamic Separation of Duty)。
- 互斥角色 :同一用户只能分配到一组互斥角色集合中至多一个角色,支持责任分离的原则。案例:在审计活动中,一个角色不能同时被指派给会计角色和审计员角色。
- 基数约束 :一个角色被分配的用户数量受限;一个用户可拥有的角色数目受限;一个角色的权限数目受限。案例:如VP类角色不可随意分配给多个用户。
- 先决条件角色 :指要想获得较高的权限,要首先拥有低一级的权限。案例:先有副总经理全下,才能有总经理权限。
- 运行时互斥 :例如,允许一个用户具有两个角色,但不可同时激活这两个角色。
(4)RBAC3模型
RBAC1+RBAC2的集合体。即支持角色间的继承关系,又支持角色间的责任分离关系。一般无需如此全面负责的模型。
3、关于一般角色、数据角色、成员角色
角色一般可拆分为一般角色、数据角色、成员角色。
- 一般角色:可见功能菜单页、功能操作按钮、数据字段,均可通过颗粒度较细的权限,去组合成一般角色。
- 数据角色:指可查询的数据范围。同一个一般角色,如查看客户数据,大区总监能看到整个大区的数据,上海分公司经理只能看到上海客户数据。上级组织职能看到下级组织员工负责的数据,而不能看到其他平级组织及其下级组织的员工数据等。
- 成员角色:新建成员即自动赋予的角色,即普通用户均有的常规权限,无需再手动配置。
4、常见的常规管理功能
(1)用户管理
用户按架构新建在对应的组织上。一般挂到机构→部门(一级部门–二级部门)下。
对于公司内部管理系统,管理用户的前提,是需要合理的组织架构,只有支持组织架构的灵活配置,才能进一步支持组织内人员的增删调整。
(2)角色管理
所有角色的管理功能。新建角色时,可将角色建立在某级机构或机构及以下,代表此角色只能适用此级别或此级别以下级别。
(3)菜单管理(有的后台叫栏目管理)
支持自主配置菜单一级二级,支持新增菜单、修改菜单、删除菜单,更改菜单(修改菜单名、菜单顺序等),每个菜单对应一个权限。
(4)组管理
用户所属组,用于配置统一组同一部门用户。有了用户组,在新建角色时,可直接将角色赋予某个组,则进入此组的人员自动获得对应角色。
workflow
一个业务流程包含多个环节的审批确认关系,按照业务流程,将各个节点串接起来,即时工作流。系统实现各个节点的自动流转,解决手工处理工作流程的低效和失误,提高工作效率的同时,还可通过线上直接流程状况进行实时跟踪,实现业务流程流转的自动化。
1、工作流常见的路由方式
(1)串行路由
按顺序一个步骤接着一个步骤走流程:
案例:入职流程,人力专员提交——HRBP审批——人力总监审批,顺序走完流程。
(2)并行路由
同时可以执行多个不同的节点:
(3)条件路由
满足条件后导向一个节点,不满足条件的导向另外一个节点。
案例:流程提交满足XX模式,则走A节点,不满足则走B节点。
(4)分支路由
分支路由平行分支出多条线路,多条线路之间是并行的关系。
案例:付款申请,提交后判断,对公付款走对公审批,对私付款走对私审批。
(5)合并路由
并行的多路分支集结到一个点的路由方式,前序分支节点全部都经过处理,最终才到汇合节点处理
案例:多个申请项目,同一天提交到终审岗审批。
(6)循环路由
下一步返回到原来的任意一个步骤,这之间形成的回路就是一个循环路由。
案例:发起的流程,条到某岗位后,再流转到自己确认,再提交。
(7)自由跳转
这种是很特殊的路由方式,在流程实际运行时跳出原来定义的线路,自由跳转到任意的步骤。
案例:满足某个条件,则自动跳过某个岗位,无需此岗位再审批。
2、常见节点动作
- 提交:每个节点的人将流程提交至下手岗位。
- 回退:可退回到某个节点继续流转,退回到发起岗,或退回到前手岗。
- 撤回:节点执行完后、下一节点执行前,可以收回进行修改然后再提交。
- 取消/撤销:流程发起人执行取消流程。
- 中止:流程提前结束,当前节点之后的其它节点不再执行。
- 审批:表单中的某个字段,用于填写审批意见。
- 会签:通常用于审批后给相关的人签字确认,需要签字确认。
- 知会:指定的人知道有这个流程这么回事,并能查看流程,不需要签字确认。
- 加签:审批时,可以征求另一人或多人的意见,然后再回到原审批人。
- 跳签:跳过接下来的一个或连续的多个节点,直接到指定的节点执行。
- ……
3、上报关系
每个节点提交后,下一节点将有谁审批?一般会为对应岗位的人员配置对应的节点。但若涉及到分公司或分地区审批,则需要设计上报关系。
上报关系支持灵活配置前一岗与后一岗的对应关系。如北京分公司的审批,提交到财务审核时,只能提交到北京财务部。合作公司的审批,只能提交到综合财务部。此时就需要提前配置上报关系,北京分公司——北京财务部;合作公司—-综合财务部。各个部门均可配置对应上报关系,包括财务,人力,业务等。
最后,为用户配置某个财务部的权限,则其仅可接收特定对应的上报关系的审批申请。如权限为综合财务部用户,仅可收到合作公司提交的申请单。
BRAC和流程节点,在设计过程中,还需考虑其灵活性。
如操作员入职流程完毕后,自动赋予其岗位对应角色权限,当然这可通过对用户组分配角色实现。当操作员调岗时,根据调岗的跨度大小,自主确定是否更改权限或删除权限。流程节点在系统中可根据对应业务,后台预备支撑性较强的节点变量,支持前台配置,由管理员自主根据对应业务流程,配置相应的流转节点。