权限管理”。有的朋友对权限管理理解的很透彻，有些朋友对一些概念模糊不清。这里总结了一些常见的误区，可供大家参考。

1. “普通用户有删除功能吗”

权限实际上是功能权限和数据权限的组合，像“删除”操作是一个功能操作权限，需要把“删除”赋予给某个用户，该用户才能有这个操作权限。如这样一个场景：企业IT管理员为系统定义角色，给用户分配角色。

给新员工陈颖赋予“业务经理”角色，“业务经理”具有“新增客户单位”、“查询客户单位”、“修改客户单位”权限。此时张颖能够进入系统，则可以进行这些操作。

2. “普通用户能查看订单数据吗”

以上举例，局限于功能访问权限，还有一些数据权限的权限管理，如：陈颖是浙江区域的“业务经理”，所以她只能够查看本区域的客户单位，而不能查看到其它地区的客户单位。甚至考虑到业务经理之间的竞争，系统可以控制更细粒度级别的数据权限，即普通业务经理的角色只能看到自己维护的客户单位，而不能查看其他人员的客户单位。软件系统的权限管理其实是与线下实际管理策略相对应的。

有些企业本身制定和实施了严格的规章制度，那么软件系统的权限管理就可以帮助企业更好的贯彻制度的实行，提高整体的运行效率和数据的安全。相反有些企业实际线下没有明确的经营策略，存在着管理风险和员工之间的不正当竞争，寄希望于软件系统的权限规范，但是实施过程中会有很多阻力。

3. “这不就是用户管理系统吗”

这是将用户管理系统当做权限管理系统，其实权限基本都是基于角色的，用户分配了对应的角色后，则会拥有对应的权限。而用户管理系统，只是将用户管理起来。

从控制力度来看，可以将权限管理分为两大类：

1. 功能级权限管理；
2. 数据级权限管理。

从控制方向来看，也可以将权限管理分为两大类：

1. 从系统获取数据，比如查询订单、查询客户资料；
2. 向系统提交数据，比如删除订单、修改客户资料。

“权限管理”是B端产品的基础功能，B端产品经理不可避免会遇到权限设计的相关问题，行业里已经很成熟。虽然它不是核心业务功能，但却牵一发而动全身，需要产品经理根据具体业务使用场景来设计。

通常情况下我们所说的“权限”，包括“功能权限”和“数据权限”，“功能权限”指用户登录系统后能看到哪些模块，操作哪些按钮，企业中的由于用户拥有不同的角色，分工职责不尽相同。

比如常见的CRM系统，销售人员和财务人员由于处理的业务不同，登录系统后，看到的功能模块也不尽相同；而同样都是财务人员，因为职位等级不同，拥有的操作功能也可能不同。

尤其是针对删除或者撤销的功能权限的控制。比如“删除”的操作，不会随意提供给一个普通员工。而数据权限指的是用户在某个模块里能看到哪些范围的数据，比如A业务经理只能看到自己的客户数据，但是A的业务总监可以查看到各个区域业务员的客户数据，

4. 功能权限中按角色访问控制设计

其基本思想是，对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合，每一种角色对应一组相应的权限。

一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。

这样做的好处是，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可。而且角色的权限变更比用户的权限变更要少得多，这样将简化用户的权限管理，减少系统的开销。一般情况下的角色权限时相对稳定的，而用户则因为时间的变化而需要获取相关新的权限。

基础模型：用户与角色是多对多的关系。一个用户可以拥有若干角色，一个角色也可以赋予若干用户。但并不意味着角色之间的关系互斥与否。

在企业的后台管理系统中，通常包含多种管理模块，有针对供应商的模块、客户的模块、财务人员的模块、统计管理人员的模块。为了避免内部信息的交叉传播，以及操作人员可能存在的误操作行为，我们就可以通过此种基于角色的访问控制模型，为后台的操作者设置多种角色，并为每个角色赋予不同的业务权限，精确到对应菜单模块的控制，甚至是相应的按钮权限。

这样就可以让销售同事只能查阅和修改供应商管理模块，无法查阅公司的财务信息。而财务同事也只能查阅和修改财务报表相关的管理模块，无法查看公司的订单汇总，不同岗位各司其职，互不干扰。

对于小型的企业，当一个人既负责销售部，又负责运营部时，就可以为其赋予销售人员、运营人员两个角色，这样他就拥有这两个角色的所有权限，即可以访问这两个模块的内容。但是公司规模越大，对每个岗位的权责要求也更为细致，角色之间可能会有相应的组合关系。有必要理清楚岗位，职务，职位，权限，角色。

毫无疑问：权限是这些概念中的最细粒度的一个东西，而角色是一组权限的集合。岗位是职位的同义词，他们的侧重点不同。

职务才是被大家忽略的一个概念：具体定义不是很清晰，但他是某一业务中某一角色应当承担的责任或者说应该负责的事。

一个职位一般来说有多个职务，比如说我们的经理助理这么一个“职位”可能要负责的事情可能有很多类，如：协助安排经理的日程，对下面呈上来的某类报告做初步审理等等一条条。这些被我们认为梳理出来的一条条的东西就是职务 – 他在当前职位上需要担负的义务。

大家初期容易将岗位抽象成一个角色，但是最终发现这个角色可能粒度太粗或者是不宜重用，这个时候就应该梳理一下每个职位的职务，以职务为单位抽象成角色，这样才能制定出更细粒的角色。

当然职位由于他是我们看的见摸得着的，所以直接将职位映射成角色是非常简单清晰没有异议的，而职务就不同了，他需要产品人员深入理解客户的业务，这样才能根据客户的业务情况梳理出一个业务职务体系，这个过程必然会很辛苦。

5. 关于功能权限设计的几点Tips

1. 如果项目初期不需要权限管理，一定记得提醒开发同学，预留相关接口。
2. 功能权限设计，也包括页面权限和接口权限，这一点没有经验的产品同学可能注意不到，需要保证没有该模块功能权限的用户直接输入页面地址或调用接口时，也无法访问。
3. 一个页面完成一件事，避免页面交互方式太复杂，无法划分功能权限。
4. 功能权限与数据权限有时可以通过模块进行转换。