原来已经写过一篇关于权限系统的文章，涉及到各种类型的权限管理（B端产品权限设计，别踩了坑才想起我）。今天讲一个比较垂直的，基于 RBAC 设计的 EHR 系统的权限设计过程，方便更多小伙伴参考。
为什么要写权限设计？讲一下背景：
接手了 EHR 系统权限设计相对简单，是直接采用用户+权限的模式。在项目初期能快速的完成场景需求，但随着业务的发展，薪酬计算、入离职审批、各种行政&人事通知，这种模式越来越不能满足需要了，而且研发每次调整，也是花费不少时间，也是非常的麻烦。
注：EHR 系统：即人力资源管理系统，通常包括员工管理、薪酬核算、入离职审批、绩效系统等，主要是通过自动流程，减少人力化部门的工作量。
所以就开始做权限的升级。正好星球群的小伙伴也想了解下设计过程，我就简单介绍下。做权限系统的目的很简单：维护方便，权限清晰。我们基于经典的权限模型 RBAC（Role-based Access Control）的思想设计，来优化下 EHR 的权限系统。
我就以实际项目的进展，来看 项目在不同阶段，怎么设置权限的。
01简单的权限管理：用户-权限HR 项目刚开始只有一个「员工花名册管理」，只有两个角色，人事管理+HRBP，总的人数不超过 10 个。
权限有新增/批量导入员工信息、修改和查看员工信息。人事管理有增删改查权限，HRBP 只能查看。
原来的产品经理，得到的需求很简单，就是只做员工管理，也没有想到，EHR 项目会变成一个集员工管理、薪酬核算、入离职审批、绩效管理为一体的大工程。
所以前期就简单的做了：用户 - 权限。
这种方式，适合小工程和小团队，并且不复杂的业务，研发和管理员能快速的进行配置，完成业务需求。02引入角色概念：用户-角色-权限接下来 EHR 系统进入了发展期，薪酬核算、社保核算等功能列入开发计划，用户也逐步增多，并且有一定的流动性。
团队每加入一个小伙伴或有转岗，就需要研发同学协助配置一系列权限，每次发布新功能，也都需要研发初始化一波权限，
特别是 EHR 的产品和研发同学，是没有线上系统权限的，一旦发生因为权限配置遗漏，导致某些员工不能正常使用新功能，我们都无法知晓。还有薪酬模块，HRBP 和人事管理需要权限隔离，是不能查看的。
现在的权限模型开始升级，尝试使用 RBAC 权限模型，在用户和权限中，加上角色的概念。
新增了角色：HRBP、人事管理、薪酬管理员、社保专员等。
由于员工薪酬和社保信息，属于公司机密，只能由薪酬管理员和社保专员有查看、修改的权限，在权限的基础上，增加了「薪酬密码」功能，权限+薪酬密码，双重认证才能查看薪酬等隐私内容。
上线后新员工入离职、调岗等，只需要配置下角色就可以了。
03细分化：用户-（组织+角色）-权限随着EHR 系统模块增加，新增了如部门助理、IT、行政、团队负责人等等角色，分工也更加清晰。有些角色是不需要登录 EHR 系统，但需要收到系统通知，越来越多的消息，反而成了业务团队的负担。
- 比如说原来 HRBP 可能负责一个大的业务团队，现在要负责大团队下 2、3 个小业务线。
- 入离职流程要通知对应团队的部门助理、it 等
- 某些员工具备多角色，如员工 A 是部门助理，但又负责内部系统权限管理员，除了要收到每个月本部门的员工生日等提醒，还有负责关闭离职员工的内部系统权限。
04权限设计：权限树+权限点权限管理可以分为权限树和权限点。比如说「员工信息管理」是个权限树，包含增加、修改、删除等权限点。
功能权限通过对角色的权限树进行修改来实现。需要注意的一个问题是，要定义好权限的最小粒度。如果要实现每一个权限的控制，相当于每一个权限对应功能都需要做封装。大的页面权限是必备的，但是有一些权限是可以封装在一起，比如说「添加员工」和『批量导入员工信息』，这些是需要产品考虑的。权限的具体设计，不做重点说明。05小结以上就是简单的 RBAC 权限设计，尽管是基于 EHR 系统，但万变不离其宗，都是基于RBAC 的3 个关键元素：用户 – 角色 – 权限。实践出真知，多看多学多做，才能成为自己的能力的一部分。
END
司马特小分队已经更新了 110+篇产品相关原创文章，并且在星球成立了「B 端产品经理之家」。
星球汇集190+来自教育、医疗、电商等领域的小伙伴，每天都有产品话题讨论，还有行业专家答疑解惑。
以下是星球的服务内容，我们还会定期汇总星球精华、系列实战文章，回复『星球』，加入「B 端产品经理之家」后免费获取。
往期精彩回顾
当你提一个需求的时候，开发说实现不了
全面解析：就诊预约应如何设计？
产品市场策略：高屋建瓴还是基层垒起？