「功能」权限设计=功能权限+数据权限

很多企业管理的中使用的软件 , 基本上都离不开“权限管理” 。有的朋友对权限管理理解的很透彻 , 有些朋友对一些概念模糊不清 。这里总结了一些常见的误区 , 可供大家参考 。
「功能」权限设计=功能权限+数据权限
文章图片

文章图片

1. “普通用户有删除功能吗”
权限实际上是功能权限和数据权限的组合 , 像“删除”操作是一个功能操作权限 , 需要把“删除”赋予给某个用户 , 该用户才能有这个操作权限 。如这样一个场景:企业IT管理员为系统定义角色 , 给用户分配角色 。
给新员工陈颖赋予“业务经理”角色 , “业务经理”具有“新增客户单位”、“查询客户单位”、“修改客户单位”权限 。此时张颖能够进入系统 , 则可以进行这些操作 。
2. “普通用户能查看订单数据吗”
以上举例 , 局限于功能访问权限 , 还有一些数据权限的权限管理 , 如:陈颖是浙江区域的“业务经理” , 所以她只能够查看本区域的客户单位 , 而不能查看到其它地区的客户单位 。甚至考虑到业务经理之间的竞争 , 系统可以控制更细粒度级别的数据权限 , 即普通业务经理的角色只能看到自己维护的客户单位 , 而不能查看其他人员的客户单位 。软件系统的权限管理其实是与线下实际管理策略相对应的 。
有些企业本身制定和实施了严格的规章制度 , 那么软件系统的权限管理就可以帮助企业更好的贯彻制度的实行 , 提高整体的运行效率和数据的安全 。相反有些企业实际线下没有明确的经营策略 , 存在着管理风险和员工之间的不正当竞争 , 寄希望于软件系统的权限规范 , 但是实施过程中会有很多阻力 。
3. “这不就是用户管理系统吗”
这是将用户管理系统当做权限管理系统 , 其实权限基本都是基于角色的 , 用户分配了对应的角色后 , 则会拥有对应的权限 。而用户管理系统 , 只是将用户管理起来 。
从控制力度来看 , 可以将权限管理分为两大类:功能级权限管理;数据级权限管理 。
从控制方向来看 , 也可以将权限管理分为两大类:从系统获取数据 , 比如查询订单、查询客户资料;向系统提交数据 , 比如删除订单、修改客户资料 。
“权限管理”是B端产品的基础功能 , B端产品经理不可避免会遇到权限设计的相关问题 , 行业里已经很成熟 。虽然它不是核心业务功能 , 但却牵一发而动全身 , 需要产品经理根据具体业务使用场景来设计 。
通常情况下我们所说的“权限” , 包括“功能权限”和“数据权限” , “功能权限”指用户登录系统后能看到哪些模块 , 操作哪些按钮 , 企业中的由于用户拥有不同的角色 , 分工职责不尽相同 。
比如常见的CRM系统 , 销售人员和财务人员由于处理的业务不同 , 登录系统后 , 看到的功能模块也不尽相同;而同样都是财务人员 , 因为职位等级不同 , 拥有的操作功能也可能不同 。
尤其是针对删除或者撤销的功能权限的控制 。比如“删除”的操作 , 不会随意提供给一个普通员工 。而数据权限指的是用户在某个模块里能看到哪些范围的数据 , 比如A业务经理只能看到自己的客户数据 , 但是A的业务总监可以查看到各个区域业务员的客户数据 ,
4. 功能权限中按角色访问控制设计
其基本思想是 , 对系统操作的各种权限不是直接授予具体的用户 , 而是在用户集合与权限集合之间建立一个角色集合 , 每一种角色对应一组相应的权限 。
一旦用户被分配了适当的角色后 , 该用户就拥有此角色的所有操作权限 。
这样做的好处是 , 不必在每次创建用户时都进行分配权限的操作 , 只要分配用户相应的角色即可 。而且角色的权限变更比用户的权限变更要少得多 , 这样将简化用户的权限管理 , 减少系统的开销 。一般情况下的角色权限时相对稳定的 , 而用户则因为时间的变化而需要获取相关新的权限 。


推荐阅读