实战干货：EHR系统的权限设计

司马特小分队 2023-07-25 10:09:26

原来已经写过一篇关于权限系统的文章，涉及到各种类型的权限管理（B端产品权限设计，别踩了坑才想起我）。今天讲一个比较垂直的，基于 RBAC 设计的 EHR 系统的权限设计过程，方便更多小伙伴参考。

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

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

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

所以就开始做权限的升级。正好星球群的小伙伴也想了解下设计过程，我就简单介绍下。做权限系统的目的很简单：维护方便，权限清晰。我们基于经典的权限模型 RBAC（Role-Based Access Control）的思想设计，来优化下 EHR 的权限系统。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、细分化：用户-（组织+角色）-权限

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

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

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

上线后的效果：

身兼数职的助理小姐姐虽然通知类消息也很多，但与其无关的都去掉了。
权限更加收紧，HRBP 小姐姐也只需要管理负责的业务团队的事情。

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

权限管理可以分为权限树和权限点。

比如说「员工信息管理」是个权限树，包含增加、修改、删除等权限点。功能权限通过对角色的权限树进行修改来实现。需要注意的一个问题是，要定义好权限的最小粒度。如果要实现每一个权限的控制，相当于每一个权限对应功能都需要做封装。大的页面权限是必备的，但是有一些权限是可以封装在一起，比如说「添加员工」和『批量导入员工信息』，这些是需要产品考虑的。权限的具体设计，不做重点说明。