为什么要写权限设计？讲一下背景：

接手了 EHR 系统权限设计相对简单，是直接采用用户+权限的模式。在项目初期能快速的完成场景需求，但随着业务的发展，薪酬计算、入离职审批、各种行政&人事通知，这种模式越来越不能满足需要了，而且研发每次调整，也是花费不少时间，也是非常的麻烦。

注：EHR 系统：即人力资源管理系统，通常包括员工管理、薪酬核算、入离职审批、绩效系统等，主要是通过自动流程，减少人力化部门的工作量。

所以就开始做权限的升级。正好星球群的小伙伴也想了解下设计过程，我就简单介绍下。

做权限系统的目的很简单：维护方便，权限清晰。我们基于经典的权限模型RBAC(Role-Based Access Control)的思想设计，来优化下 EHR 的权限系统。

我就以实际项目的进展，来看 项目在不同阶段，怎么设置权限的。

01

简单的权限管理：用户-权限

HR 项目刚开始只有一个「员工花名册管理」，只有两个角色，人事管理+HRBP，总的人数不超过 10 个。

权限有新增/批量导入员工信息、修改和查看员工信息。人事管理有增删改查权限，HRBP 只能查看。

原来的产品经理，得到的需求很简单，就是只做员工管理，也没有想到，EHR 项目会变成一个集员工管理、薪酬核算、入离职审批、绩效管理为一体的大工程。

所以前期就简单的做了：用户 - 权限。

这种方式，适合小工程和小团队，并且不复杂的业务，研发和管理员能快速的进行配置，完成业务需求。

02

引入角色概念：用户-角色-权限

接下来 EHR 系统进入了发展期，薪酬核算、社保核算等功能列入开发计划，用户也逐步增多，并且有一定的流动性。

团队每加入一个小伙伴或有转岗，就需要研发同学协助配置一系列权限，每次发布新功能，也都需要研发初始化一波权限，

特别是 EHR 的产品和研发同学，是没有线上系统权限的，一旦发生因为权限配置遗漏，导致某些员工不能正常使用新功能，我们都无法知晓。还有薪酬模块，HRBP 和人事管理需要权限隔离，是不能查看的。

现在的权限模型开始升级，尝试使用 BRAC 权限模型，在用户和权限中，加上角色的概念。

新增了角色：HRBP、人事管理、薪酬管理员、社保专员等。

由于员工薪酬和社保信息，属于公司机密，只能由薪酬管理员和社保专员有查看、修改的权限，在权限的基础上，增加了「薪酬密码」功能，权限+薪酬密码，双重认证才能查看薪酬等隐私内容。

上线后新员工入离职、调岗等，只需要配置下角色就可以了。

03

细分化：用户-(组织+角色)-权限

随着EHR 系统模块增加，新增了如部门助理、IT、行政、团队负责人等等角色，分工也更加清晰。有些角色是不需要登录 EHR 系统，但需要收到系统通知，越来越多的消息，反而成了业务团队的负担。

1. 比如说原来 HRBP 可能负责一个大的业务团队，现在要负责大团队下 2、3 个小业务线。
2. 入离职流程要通知对应团队的部门助理、it 等
3. 某些员工具备多角色，如员工 A 是部门助理，但又负责内部系统权限管理员，除了要收到每个月本部门的员工生日等提醒，还有负责关闭离职员工的内部系统权限。

这需要在原有的角色基础上，增加所属组织。当用户使用某功能的时候，根据角色和所属组织，来进一步约束。

上线后的效果：

1. 身兼数职的助理小姐姐虽然通知类消息也很多，但与其无关的都去掉了。

2. 权限更加收紧，HRBP 小姐姐也只需要管理负责的业务团队的事情。

04

权限设计：权限树+权限点

权限管理可以分为权限树和权限点。比如说「员工信息管理」是个权限树，包含增加、修改、删除等权限点。

功能权限通过对角色的权限树进行修改来实现。

需要注意的一个问题是，要定义好权限的最小粒度。如果要实现每一个权限的控制，相当于每一个权限对应功能都需要做封装。大的页面权限是必备的，但是有一些权限是可以封装在一起，比如说「添加员工」和『批量导入员工信息』，这些是需要产品考虑的。

权限的具体设计，不做重点说明。

05

小结

以上就是简单的 RBAC 权限设计，尽管是基于 EHR 系统，但万变不离其宗，都是基于 RBAC 的 3 个关键元素：用户 – 角色 – 权限。

作者：南南 把经历和经验分享给更多的产品经理，助力更多产品经理成长。