用户角色与权限矩阵的设计方法

权限设计的目标

权限体系要同时满足两个看起来矛盾的目标：

1. 能用：该看的人能看到，该操作的人能操作，不要到处卡住
2. 控住：不该看的看不到，不该改的改不了

设计不好，会出现两种情况：权限过松（数据泄露、误操作）或过紧（业务跑不动，到处找人开权限）。

角色设计的方法

不要按人配权限

按人配是最容易想到也最不可取的做法。100 个人配 100 套权限，人一变动就要重新配，且很难审计。

正确做法：按角色配，人挂角色。

从岗位出发设计角色

先列出企业的岗位，再把岗位映射成角色：

角色数量要控制

角色太多会难以管理。一般 8-15 个角色能覆盖绝大多数场景。

如果出现"张三比较特殊，给他单独建个角色"，说明角色划分有遗漏，应该回头调整角色定义，而不是新建角色。

权限矩阵的编制

权限矩阵是一张二维表：行是角色，列是功能点。

编制步骤

1. 列出所有功能点（从菜单和按钮出发，细化到按钮级）
2. 列出所有角色
3. 逐格确定权限（是/否/范围受限）
4. 找业务部门确认
5. 配到系统里测试

第 3 步要特别注意"范围受限"这种情况。很多权限不是简单的能/不能，而是"只能看自己部门的"。

数据权限和功能权限要分开

这是最容易被混淆的一点：

• 功能权限：能不能进入这个菜单、点这个按钮
• 数据权限：能看到哪些数据

同一个人可能是"有报工功能权限，但只能看自己的报工记录"。

设计时要分开考虑，系统实现时也是两套机制。

三个常见误区

误区一：权限越细越好

有的项目把权限细化到每个字段，结果配置量巨大，且业务一变就要改。

建议：功能权限细化到按钮级就够了。字段级权限只在少数敏感场景用（比如成本、工资）。

误区二：给管理者全权限

车间主任需要"审批"权限，但需不需要"修改历史数据"的权限？通常不需要。

权限要按最小必要原则给。给了多余的权限，出问题时无法追责。

误区三：忽略离职和调岗

员工离职后账号没停用，或者调岗后老权限没收回。

必须有定期审计机制：每季度导出一次账号权限清单，让部门负责人确认。

这是审计（尤其是信息安全审计）必查的项目。

特殊场景处理

代班

班组长休假，谁来审批？两个方案：

• 临时授权：给代班人加临时权限，到期自动失效
• 代理关系：设置"代理人"，代理人继承被代理人的权限

临时授权更好，因为边界清晰、易审计。

跨部门协作

需要看其他部门数据时，不要给全局权限，而是给"特定数据的查看权"。

外部人员

供应商、客户如需访问，单独建角色，且权限范围最小，通常只给"查看指定工单"的权限。

上线后的权限管理

权限管理不是一次性工作，需要机制：

• 权限申请流程：谁申请、谁审批、多久生效
• 权限变更记录：所有变更留痕
• 定期审计：每季度核对
• 离职联动：HR 离职流程里包含"停用系统账号"这一步

最后一条尤其重要。建议把"系统账号停用"写进 HR 的离职清单，否则一定会漏。

具体角色的权限配置界面和操作路径，[待补充：百华智造 MES 角色权限配置说明]。