实战篇:B端权限管理
本篇以笔者做过的一个复杂项目为例,讲讲进行权限管理的实战总结。
一、项目背景
本次项目是为某研究院搭建一套信息化系统,包括统一用户管理平台、CSS系统、CRM系统、两套LIMS系统。
其中统一用户管理平台由客户IT部门管理,决定哪个用户能够登录哪个系统。
CRM系统由内部管理人员、商务、内勤、办公室、财务等人员使用,用于客户管理和内部管理,需要实现很多跨部门协同的功能,而且是以上各系统中使用人员和范围最广的一个系统。
以下分析均以CRM系统为例:
- 信息化基础:该研究院IT基础薄弱,目前只有GLP实验室管理系统。
- 组织架构:该研究院组织架构较为复杂,包括总部和子公司。部分人员交织在一起,而且组织机构还在不断调整中。
二、权限管理实战
在具体项目中,我们按照【梳理组织架构 – 确定权限管理设计框架 – 开展具体的产品设计 – 梳理角色权限和数据权限 – 初始化配置 – 根据客户需要进行调整】的顺序,去实现合适的权限管理。
1. 梳理组织架构
对客户实际组织架构和业务情况进行了解梳理,总结如下:
- 其中财务部归总部管理,财务部管理所有下属子公司和业务部门的费用、风险控制。子公司一为独立法人公司,但部分员工、资产和资质仍归属总部。
- 子公司一签署的合同主体既有独立法人公司的,又有总部的。但子公司一的员工、资产和资质将逐渐从总部剥离。
- 子公司二为独立法人公司,签署的合同主体、授信均为本公司。
- 业务一部归总部管理,签署的合同主体、授信均为总部。
- 子公司一、子公司二、业务一部的业务数据要进行隔离。
2. 确定权限管理设计框架
通过对组织机构的梳理,并通过用户访谈对业务进行了深入的理解,我们总结出:
- 该系统需要对各子公司和业务部门的客户数据和业务数据进行隔离;
- 各子公司和业务部门均有销售经理、办公室经理、商务、内勤、办公室几个角色,而且通过了解,同角色的人员所负责的事项都是相同的;
- 有一些特殊的权限管理需求:例如商务、内勤只具有本人的业务单据权限,但可以查看操作所属法人公司的到账、授信、客户余额等数据。
可以看出,传统的权限管理模型显然不能满足该系统的权限管理需要。如果使用传统的RBAC模型,也存在多个角色重复创建、无法管理数据权限的问题。
因此,我们确定在CRM系统上,应该使用基于RBAC的扩展模型。通过岗位管理用户在系统中的功能权限和数据权限,以满足客户需求。
3. 开展具体的产品设计
(1)用户管理
1)用户列表、查询
用户列表页展示用户名(即用户在系统中的账号名)、姓名(用户实际姓名)、电话、邮箱、状态、部门、岗位等有价值的信息。
同时具备编辑、启用、分配岗位功能。
2)用户新增、编辑、删除
本项目中,用户的新增、删除均通过统一用户管理平台进行,并分配系统级权限。
各系统中自行编辑、分配权限。
用户的字段包括登录邮箱、手机号码、姓名、用户名、部门、性别等字段,其中姓名和部门为必填项。
3)禁用
如果出现用户离职的情况,可以将用户禁用,不可登录系统,防止业务数据流失。
4)分配岗位
可以为用户分配相应的岗位,用户与岗位的关系是一对多。
(2)组织机构管理
1)组织机构列表、查询
左侧为组织机构,可以编辑组织的层级关系。
右侧为该组织机构下的岗位列表,可以对岗位进行查看、编辑、删除、分配角色和数据权限、分配用户的操作。
2)新增、编辑部门
点击组织机构右侧的“+”按钮,可新增子部门。
填写部门编码、部门名称、部门类型、公司类型。默认新增部门为所选部门的子部门。
其中,公司类型是这个项目的特殊需求,与客户业务相关,正常权限管理一般不需要这个字段。
3)删除部门
点击部门右侧的“删除”图标,可以删除该组织节点。
(3)角色管理
1)角色列表
左侧为角色列表,右侧为角色对应的功能权限。功能权限可以根据客户需求,可以细致到按钮级,也可以只管理到页面级别。
2)角色新建
点击“新建角色”按钮,输入角色编码、名称和备注。
其中,如果有特殊的权限需求,一般要与角色编码挂钩,这种情况下角色编码需要与技术团队约定规则,不可随意变更。
3)分配功能权限
点击左侧的角色名称,可以在右侧列出的功能列表中,对该角色分配相应的功能权限。
(4)岗位管理
1)岗位列表
在岗位列表页可查看岗位名称、岗位编码和部门。并可对岗位进行查看、删除、编辑、分配角色和数据权限、分配用户的操作。
2)新建岗位
点击左侧的组织机构,即可创建该组织节点下的岗位,部门默认为左侧所选的组织节点。
填写岗位名称、岗位编码、选择部门。岗位编码同角色编码,若有特殊权限需求,要与开发制定相应的规则,不可随意变更。
3)岗位详情
点击“查看”按钮,可以查看岗位详细信息和具有该岗位的人员列表。
4)分配角色和数据权限
为岗位分配其角色和数据权限。
岗位和角色之间是多对多的关系,一个岗位可以具有多种角色,一种角色也可被赋予多个岗位。
数据权限本次项目上做的非常冗余、用户体验极差,给每个角色又配置了相同的名称和数据权限,即“职能”,系统管理员还不能编辑岗位职能。(我也不知道当时产品和开发咋想的哈哈哈)
通常来说,应当直接分配数据权限:本人、本部门、本部门及下级部门,简单明了。
另外,若组织机构比较复杂,可以加上“法人公司”的数据权限,往上追溯离用户最近的法人公司。用户即具备法人公司下的业务数据权限。
5)分配用户
点击“分配用户”按钮,可将岗位分配给用户。用户与岗位是多对多的关系。
4. 梳理角色权限表单
通过组织机构分析和产品设计,我们已经抽象出可以使用CRM系统的角色。
这时就需要产品经理梳理角色权限表单,目的有二:
- 测试阶段需要初步验证业务流程是否可以正常进行;
- B端客户对系统一般不太熟悉和了解,让用户梳理角色权限是不太可能的。因此在上线前我们往往会初始化角色权限,用户只需要在后续使用中进行调整即可。
角色权限表单可参考下图:
5. 梳理数据权限
对各岗位的数据权限进行梳理,若存在无法通过系统配置的特殊权限需求,需要与开发沟通,通过代码写死或者约定一定的规则,用角色编码或岗位编码实现。
例如:本项目上,商务人员、内勤人员的客户和委托单数据权限为本人,但是对于循环授信、到账公告和客户余额,他们又需要查看和使用其所属法人公司的数据。
6. 系统上线、试运行
系统上线时,需要对角色权限进行初始化配置,并通过用户培训和配置文档将配置规则教给客户。
上线试运行期间,可以由运维人员协助客户对实际业务的新情况调整权限配置,在过程中让客户IT人员逐渐熟悉权限配置规则。
在使用过程中,客户也必然会提出一些新的特殊权限的需求,这时候需要产品进行评估,根据对现有权限框架的影响决定是否变更。
最后,权限管理体系下的用户登录有两种方式:
- 用户登录时,仅能选择一个岗位,其在系统中可查看和操作的功能和数据均为该岗位的功能权限和数据权限;
- 用户使用一个账号登录,登录后具有其所有岗位的全集功能和数据权限。这种情况下,在权限配置时,一定要特别注意角色的静态互斥和动态互斥。
PS:对于特殊权限,大家有何高见欢迎评论指教,感谢!
本文由 @夏至 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
这句话“可以为用户分配相应的岗位,用户与岗位的关系是一对多。”用户和岗位是一对多,不是多对多吗,一个岗位只能属于一个用户?有点困惑。也是对岗位的理解不太能想明白,是用户组的概念吗
类似财务部、绩效部等职能部门,需要查看销售公司一和销售公司二的的订单数据,这个权限设计是否还适合呢
看完对组织架构和权限的关系清晰了很多哈,好棒
可以直接删除角色吗?如果可以直接删除那么角色管理里面的用户所队形的权限是否也随之消失
角色删掉了,拥有这个岗位-角色的用户,应该也会失去被删掉的角色所关联的权限。
角色是否能删除,可以根据业务实际情况,分出不能删的基础角色 和可以删的拓展性角色吧。。
为什么不直接在角色上加入数据权限,而是再引入一个岗位
职位 、汇报线 和实际工作在实际工作中是不一致或者交叉的
我理解是通过岗位关联组织结构,而角色没有关联组织结构?
同问,销售属于岗位还是角色,为角色分配权限后那么该角色下的所有用户也分配了,角色可以有很多用户,岗位也可以有很多用户,不知道岗位存在的意义,请解惑!
是的,加一个岗位,相当于多了一层关系,开发工作量更大。从文章描述来说,确实看不出岗位的作用。就算要数据隔离,其实角色本身就够了。
一般的系统设计中,不会引入岗位,引入岗位会让权限体系更为复杂,但并不是岗位没有作用;岗位的引入可以解决集中复杂的业务场景:
1、一个多岗的情况下,该用户不同岗位的上级查看不同的数据;
2、下级向上级汇报工作;
3、离职员工工作数据的继承
等
解决了我很多问题
分配角色和职位中,数据权限,不能和部门用同一个字段。因为某部门下的人员可能需要他的上级数据权限
按理应该要拆分开,即使同一部门,默认权限可能相似,但部分人员可能会拥有特殊的权限
是的,数据权限一般是本人、本部门、本部门及下级部门之类的,跟部门/角色使用同一个字段是不合理的。向上的数据权限一般不是通用需求,可以通过团队或者具体单据的权限去特殊处理。
貌似以当前这种维度来构建权限管理不利于后期的使用和维护。我觉得以公司为维度来搭建,其中用户列表页增加公司筛选,用公司、岗位、角色三个维度来关联用户权限和数据权限,这样在对某个公司进行统计或者其他的时候都比较清晰,不会混在一起
您说的公司是指组织机构的维度吗?
您好,看了您的文章受益匪浅,但是有两点还有些疑问,能和您再请教一下吗?
1、数据查看权限分成本人、本部门、本部门及下级部门,这里您说冗余且体验感差,想问一下这样设置是有什么坑吗?
2、岗位和角色如何配合使用,能具体讲解一下吗?
如果可以,希望能添加您的微信具体咨询一下可以吗?
来,一起讨论下权限管理。加个微信13628331823
1、数据查看权限说的“冗余”是指项目上我们产品把数据权限跟岗位绑定死了。分成本人、本部门、本部门及下级部门是没有问题的。
2、不同的权限模型适用场景可以看这篇,人人社区不让发
https://mp.weixin.qq.com/s?__biz=MzIzNjY3NzEyMw==&mid=2247483682&idx=1&sn=8e45340d19fff4bf338beee5ee27f325&chksm=e8d5704edfa2f9580a2e31513d701346b63c517724cf5e2aab1f115b7c8a75c90988fe045ee7&token=221420451&lang=zh_CN#rd
很赞
貌似也可以直接用户对应角色,不用中间加一层“岗位”对应关系
三层权限模型适用场景也很多,但是在这个案例里面不太适合呢。因为这个案例的组织机构复杂,数据权限要求很细,如果用户直接对应角色,数据权限管理在灵活性和可扩展性上都会比较受限
需要的,有些系统中叫复合角色
这个是什么意思?是类似于多个role集合成一个新的role???
复合角色的定义是怎样的?它具体是为了解决什么问题(是解决某个角色拥有多个层级的权限问题吗?)
感谢,受教了!
角色与岗位有什么区别啊?请教一下
角色是功能权限的合集,岗位可以理解成角色和组织机构(数据权限)的合集。
关于权限管理我总结过一篇文章,但是人人社区不让发,希望对你有帮助~
https://mp.weixin.qq.com/s?__biz=MzIzNjY3NzEyMw==&mid=2247483682&idx=1&sn=8e45340d19fff4bf338beee5ee27f325&chksm=e8d5704edfa2f9580a2e31513d701346b63c517724cf5e2aab1f115b7c8a75c90988fe045ee7&token=221420451&lang=zh_CN#rd
之前纠结了好久,功能权限好控制,数据权限真的是一个用户一个需求,看来复杂需求时,岗位来控制数据权限还是需要的,多谢!
先马了 后面再看