一个案例,三个角色,简单说下B端产品的权限设计

13 评论 44763 浏览 222 收藏 7 分钟

理论性的内容我个人也是不擅长,所以就简单的说说权限设计,忘同行不吝指教。

入行以来也接触过一些B端产品,这些产品之中权限管理是重中之重,权限管理不仅仅是整个系统的一个小小的模块,它一直贯穿整个系统,从登陆到操作到最后的登出。说它相当的复杂真不为过。

对于权限,如果从控制力来分的话,可以分为功能级权限和数据级权限。从控制方向来分的话又可以分为从系统获取数据和向系统提交数据。一般来说,权限管理无非是围绕着用户,角色和资源三个方面来进行权限管理操作。

首先,设计的时候要面向开发人员友好,让他们能够很好的理解需求和流程。不至于因为权限的问题影响开发。实际上,一般权限设计都会让在最后进行实现。因为前期考虑太多的权限会严重影响产品开发的流畅性。当然最重要的还是面向用户友好,毕竟产品的使用者是用户,所以逻辑清晰,结构完整的权限体系就显得越发重要。

举例:

派单系统

业务:系统的客户在前台提交一个订单,后台对应的接收到该订单并分派给业务员给客户完成服务。

角色:

  • 老板—查看报表和人员角色修改
  • 业务经理—1.业务管理(接单后对订单进行派发)。2.对业务员进行行政管理(增删改查)
  • 业务员—接单处理,反馈订单信息

第一种情况,简单的完成权限设计

整理一下,从业务流程来看,涉及到的角色其实就是前台的用户,业务经理和业务员。

图片1业务流程

然后从功能来看:

图片2功能逻辑

这样子系统的架构就能够比较清晰的进行设计了。

菜单的总体结构如下:

1 订单管理

  • 1.1未处理订单
  • 1.2已派发订单
  • 1.3已处理订单
  • 1.4处理下派订单
  • 1.5提交已完成的下派订单

2 系统设置

  • 2.1密码修改
  • 2.2个人信息设置

3员工管理

  • 3.1查看下级员工信息
  • 3.2修改下级员工信息
  • 3.3员工角色设置

4 报表管理

  • 4.1查看报表

通过登录的时候对账号类型进行判断或者不同角色通过不同的登录页面进入相应的系统页面

老板的菜单显示为:

2系统设置

  • 2.1密码修改
  • 2.2个人信息设置

3员工管理

  • 3.1查看员工信息
  • 3.2修改员工信息
  • 3.3员工角色设置

4报表管理

  • 4.1查看报表

业务经理的菜单显示为:

1订单管理

  • 1.1未处理订单
  • 1.2已派发订单
  • 1.3已处理订单

2系统设置

  • 2.1密码修改
  • 2.2个人信息设置

3员工管理

  • 3.1查看下级员工信息
  • 3.2修改下级员工信息

业务员的菜单显示为:

1订单管理

  • 1.4处理下派订单
  • 1.5提交已完成的下派订单

2系统设置

  • 2.1密码修改
  • 2.2个人信息设置

这是第一种简单的权限设计思路。但是,如果,如果boss对系统的扩展性要求较高,而非一个过渡性的系统。那边就需要改变思路。重新设计系统了。

第二种情况,完成更加灵活且复杂的权限设计

在这种情况下就要考虑下现有的各种角色以及各种角色对应的操作是否是可修改的。未来是否会变更。

比如查看报表的权限后期业务经理业务查看?随着业务的扩大,业务经理是否变成多个?boss是否能够禁止业务经理的派单权限?在这种情况下,各种权限其实是变成可配置的了。

这个时候就需要转化思路了。首先将所有的功能全部抽离并罗列出来。如下就是简略的功能列表

表格

其中,boss角色一开始就具备所有的功能。他可以创建下级角色—业务经理,创建的同时给业务经理这个角色分配权限(实现方式可以类似技能树0.0)。也可以创建一个归属业务经理的业务员。这样,权限,角色都是可进行灵活配置,扩展性和实用性也更强。

Step1:角色管理-添加角色

图片4角色管理-添加角色

图片5添加角色

在这一步中进行角色的添加并分配权限。

Step2:用户管理-添加用户

图片6添加账户

图片7添加账户2

在这个步骤中重点是给添加的用户分配角色(即权限)

这样子就将角色,用户,权限分离开,管理也就更加的方便和灵活了。

但是值得注意的是,这三者之间的关联性,对某一个的删除,修改等操作是否会对其他部分产生影响。这个就需要产品经理在后面进行慢慢的梳理了。

如有错误,欢迎指正,谢谢。

 

本文由 @阿拉士奇 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 或者,将角色在设计时直接固化,如业务经理、业务员等在流程中必须有的功能点,直接就固化了,不需要通过权限菜单去配置,后续就需要将不同的员工分配为业务经理/业务员就可以了

    来自湖南 回复
  2. 在功能权限设计上,应该结合流程节点,对流程从开始到结束所必须经历的环节所涉及到功能点,在权限设置时应以流程导向的方向进行设置,避免因角色权限设置上的遗漏,导到流程走不下去。比如:上述示例中,假如因为遗漏,所有角色都没配“分派订单”这个功能点的权限,流程就走不下去了

    来自湖南 回复
  3. 写的稍浅,如果有2个负责人,分管不同部门如何设置?人员有跨组织管理如何解决?这只解决了功能权限的设置,没解决数据权限的分配设置

    来自浙江 回复
    1. 同意

      来自上海 回复
  4. 能够看出人群组织的奥秘

    来自浙江 回复
  5. 1、如果这个业务经理也拥有了【角色设置】&【权限设置】的权限,那这个业务经理是不是可以直接修改boss的权限,直接把boss干掉?
    2、当这个业务经理设置了子账号,二级业务经理设置了权限,那后面如果业务经理的账号和权限被修改了,或者被拿掉了;那这个被他设置的子账号,怎么办

    来自上海 回复
  6. 反感角色 提倡分组

    回复
    1. 谢谢,下次按分组的情况进行考虑。看看哪种方式更加实用当前项目,

      来自江苏 回复
    2. 为什么反感角色呢,个人感觉角色更灵活,对功能的拆分重组更适合,小白一枚,望解惑

      来自上海 回复
    3. 角色的用法不太适应于流程性很强的应用,流程性很强的应用产品,更适合用“身份”来设计,如电商平台的买家身份和卖家身份,身份就决定了这两者进行流程分工时的责权利

      来自湖南 回复
    4. 身份这里希望多说一点,没理解

      来自上海 回复
  7. 确实不错

    回复
    1. 谢谢

      来自江苏 回复