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

36 评论 4.2万 浏览 189 收藏 10 分钟

很多企业管理的中使用的软件,基本上都离不开“权限管理”。有的朋友对权限管理理解的很透彻,有些朋友对一些概念模糊不清。这里总结了一些常见的误区,可供大家参考。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

本文由@山人小道 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 您好,我想问一下权限在业务系统里还是单独一个系统?

    回复
  2. 您好,想问一下,怎么设计跨企业的业务流程?单位之间不存在隶属关系,但是业务上有交叉

    回复
    1. 审批

      回复
  3. 您好,我想知道,权限设计应该在产品初成型的时候就做完整的梳理和设计,还是先做简单权限区分,等产品相对成熟后再做更完善的权限设计?谢谢~

    回复
    1. 在设计的时候最好考虑未来一段时间的业务发展变化,基于这个变化来设计,不然权限体系很快就会落后,面临调整或重构,我们的系统就是从上线到现在已经调整过三次了。

      回复
  4. 你好,还有个问题想问下,就是功能权限和数据权限的之间的关系,我认为既然是如果具有了对某个模块的功能权限,那就必然获得了对这个模块的数据权限,毕竟是先要可见,才可以执行相应的操作,可以这么理解吗?

    回复
    1. 我的理解是功能都是基于数据的衍生品,有了数据才有相对应的功能,所以我也不是很明白数据权限和功能权限的关系

      回复
    2. 应该这样理解吧,有了功能权限肯定也是有数据权限,有了数据权限肯定也有功能权限,但是两个角色都有某个功能权限,但他们两个的数据权限不一定相同,数据权限的维度要低于功能权限

      回复
    3. 数据权限和功能权限应该是相互独立的,权限是功能权限与数据权限交叉子集。有功能权限而无数据权限,无法操作该条数据;无功能权限而有数据权限,则也无法操作。必须同时拥有功能权限和数据权限,才能操作数据。

      回复
    4. 你的描述应该是想知道功能权限与数据权限及操作权限之间的关系吧,可以概括为:功能权限优于数据权限和操作权限:
      1、获得数据权限和操作权限一定要获得功能权限,举个例子:你需要查看公司数据销售数据(数据权限)及新增报表字段(操作权限),必须得先有数据报表页面(功能权限);
      2、获得功能权限不一定需要获得数据权限和操作权限,举个例子:你拥有数据报表功能,但你可以不展示数据(数据权限)和不进行操作(操作权限),这个依然是成立的;

      回复
    5. 具有了对某个模块的功能权限,那就必然获得了对这个模块的数据权限,这句话对
      但是文中的数据权限主要是讲,不同角色的数据权限

      例:部门经理和区域总监都有客户管理中权限,但是对于数据范围的要求是不同的

      部门经理只能看到本部门及以下的客户数据
      区域总监则可以看到所有部门及以下的客户数据

      回复
  5. 这里边还是没有说出如何解决同等权限下多任职之间数据权限如何处理数据的问题

    回复
    1. 是的。。我也是想知道这个。。你要是知道了可以分享一下吗 ➡

      回复
    2. 有两种解决方案,第一种实现难度低,不用跟组织架构挂钩,相对简单,但是只适用于小公司团队,第二种与组织架构相关,相对复杂;
      1、将数据权限与功能权限区分开并与角色关联,数据权限可以将不同模块的数据拆分成不同层级颗粒大小的数据集,与功能权限一样,进行勾选选择即可;
      2、第二种是通过组织架构的部门界定部门从属关系,通过岗位界定人员从属关系【关系到数据范围】,比如员工在A\B两个公司任职不同的岗位和角色,通过角色将组织信息带出,然后选择数据范围和功能权限,切换组织可以解决不同组织同角色,同权限不同数据范围的问题;
      当然以上是本人结合作者的思考,如果有更好的、更加简单的方案可以说下。

      回复
    3. 能否加wx交流下,目前在思考的问题和遇到的问题,比上述情况更棘手

      回复
    4. 两者也会都包括呢,既要划分数据范围,比如个人的基础信息、实名信息,也要根据组织架构来区分,比如员工都能看客户基础信息,但只能看自己部门的。

      回复
    5. 其实区分清楚什么是功能权限,什么是数据权限,那么就很好设计了

      1.查看客户基础信息,在设计上你可以把他归纳到【客户管理】-【基础信息】的功能权限上
      2.只能看自己部门的,这个是数据权限,一般我们可以把数据权限设计为:本角色信息、本部门信息、本部门及以下信息、全部信息

      数据权限并不是说页面上的数据,而是角色管理边界

      回复
  6. 您好~您讲的通俗易懂,基本都能看明白,但是最后的tips,第4点,可以详细解释下吗,功能权限与数据权限有时可以通过模块进行转换,这个转换是指什么意思呢?

    回复
    1. 同问

      回复
  7. 学习啦,求问作者一个小问题,文中有提到功能权限中是基于角色的访问控制设计权限,那数据权限中是不是就是其中提到的以职务为单位将角色粒度细化?

    回复
    1. 不能这样理解,数据权限侧重的是数据;以职务为单位抽象成角色,只是说可以制定出更细粒的角色而已

      回复
  8. 多研究下,ERP系统,OA系统权限设计体系,在去其他轻量级产品,小菜一碟

    回复
    1. 👍

      回复
    2. 好的 谢谢指导,权限设计体系之于OA系统和ERP系统是关键与核心

      回复
    3. ERP的权限体系设计是最LOW的…已经远达不到现在的权限管理需求..

      回复
    4. 去学习下,再来说你LOW,还是与时俱进其他厂商DE “LOW” 国内前两名-SAAS-CRM 厂商合作很深,不知道你家排几名?

      回复
    5. EBS、SAP、用友这几家的ERP产品都用过,SALESFORCE的权限也研究过,都没看到权限体系有什么特别的,不知道你说的先进在哪里,公司现在业务系统权限体系都是内部自己设计的。

      回复
    6. 建议你去看下用友子公司畅捷通t+产品,或原用友子公司致远产品的权限体系,以及参数设置,工作流设置

      回复
    7. T+产品权限体系好不好不好说,在用友工作几年,权限方面没见到亮眼的产品。致远的产品倒是没用过…

      回复
    8. 自开产品,当然要设计自己特征,不存在哪个先进一说,权限体系大于小,复杂与简单设计差异

      回复
    9. 权限的先进性不但要满足业务需要,还要有易用性和好的用户体验。

      回复
    10. 你口口说先进,先进具体内容?那些产品满足你说的所谓先进性?

      回复
    11. 举个简单的例子,某些ERP产品为了满足业务权限管控需求,要在系统中设置几百个角色,权限交叉像蜘蛛网,花费大量的人力,你觉得这种先进么.

      回复
    12. 英才:先进具体内容?那些产品满足你说的所谓先进性?

      回复
    13. 倒数第二条和倒数第三条回复已经描述得很清楚了哈~

      回复
  9. github开源代码 smartadmin

    回复