做系统权限的时候，很多人的第一反应是按岗位分。科长看什么、科员看什么、主任看什么，一套下来感觉很顺。真用起来问题就来了，有人调岗了权限没变，有人兼着两个岗位的活，还有临时负责人不知道该给什么权限。
根源在于，岗位是组织结构里的概念，权限是系统里的概念，两者有关系但不是一回事。
一、两者差在哪
岗位描述的是一个人在组织里的位置，比如综合科科员、业务一科科长。岗位相对稳定，跟着组织架构走，一年可能调整一次。
权限描述的是一个人在系统里能干哪些事，比如能录入客户、能审批两万以下的费用、能导出报表。权限跟着业务走，变化比岗位频繁得多。同一个岗位的三个人，因为分管范围不同，实际需要的数据权限可能完全不同。
如果把岗位直接绑成权限，会出现几种尴尬。一是同岗不同权的人被塞进同一个角色，权限只能取并集，结果所有人都多了权限。二是跨部门兼岗的人没法处理，只能给他开两个账号或者一个超级权限。三是调岗之后必须记得改权限，漏改就是隐患。
二、分开之后怎么设计
合理的做法是三层结构，人员、角色、权限，中间用角色做桥。
人员来自组织架构，有部门、岗位这些属性。角色是系统里定义的职能集合，比如合同录入员、合同审核人、报表查看者，一个角色对应一组具体操作权限。人员通过分配角色获得权限，一个人可以有多个角色，一个角色可以给多个人。
再加一层数据范围会更好用。同样是合同查看权限，科长看全科、科员看自己录的、分管领导看自己分管的。这层范围通常用规则来表达，比如本部门、本部门及下级、仅本人、自定义范围。有了这层，角色的数量能大幅减少，不用为每个部门都建一个角色。
三、人员变动要能自动跟着走
权限体系好不好，很大程度上看人员变动时省不省事。
新人入职，理想情况是人事系统里建了档，系统根据岗位自动分配基础角色，剩下的由部门负责人补充。调岗的时候，原来的角色自动取消，新岗位的角色自动加上。离职的时候，所有角色自动失效。
要做到这一点，需要系统跟人事数据打通，或者至少有一个定期同步的机制。做不到自动的，就要有一个人为的检查环节，比如每月核对一次人员与权限的对应关系。这个环节看着麻烦，但比出事之后再补救便宜得多。
四、几条实用的设计原则
权限给到最小。默认不给，需要什么开什么，而不是默认全给再收。这条在系统建的时候麻烦一点，但长期看省事。
敏感操作单独授权。删除、导出全量数据、修改已审核单据这类操作，不要混在普通角色里，单独设成需要额外申请或者由管理员临时开启的权限。
定期做权限盘点。每半年拉一份清单出来，看有没有权限明显不匹配的账号，有没有长期不登录却握着高权限的账号。这类账号是安全隐患的主要来源。
留好操作日志。任何权限变更本身也要记日志，谁在什么时候给谁加了什么权限。没有这份记录，权限是怎么多出来的就说不清了。