成熟CRM系统的权限体系解析
权限体系的价值在于支撑不同用户处理职责范围内的业务,保护业务处理的顺畅进行而不被干扰,降低发生误操作风险,更保障业务数据的安全。权限体系是后台/B端产品的产品经理绕不过去的领域。本文通过对微软CRM等成熟CRM后台的权限体系的解析,为B端产品经理提供参考。
权限体系的核心要素
权限体系的要素有:组织、角色、用户和权限、页面、视图。
- 组织、角色、用户是基于业务变化可即时调整的。
- 权限是最底层属性,由开发人员基于业务需求开发实现。权限约束的对象是后台的具体实例。根据数据接口安全需要,可设计专用的接口权限。
- 页面、视图是系统按照业务配置、给对应用户呈现的内容。
1. 组织
组织有多个类型,常见有三种:
- 基于行政组织来设置的,但又可能会不同于行政组织。比如总部在行政上会有销售副总、销售部长、营销部长,而在营销系统的权限配置中,不会创建公司高管、下面设销售部、营销部,而是将销售总监、销售部长、营销部长放在在一个部门里,给不同角色。
- 基于某个业务线来设置,比如按产品线维度,A1产品线的只能看到AI产品线相关的线索、订单等业务数据。
- 临时项目组织。因业务需要,临时创建的组织,从多个组织中拉入人员,共同处理某特定业务。
2. 角色
角色是权限分配的单位与载体。复杂业务中,角色可基于不同业务组织创建,以限定业务范围。
3. 用户
用户归属于某个组织、且拥有某个或多个角色的权限。因组织所在的位置或等级、以及角色,决定了用户拥有的权限。存在即使角色相同,但因组织等级不同,可见的数据范围也不同的情况。
4. 权限
权限分功能权限、组织权限、数据权限。
(1)功能权限:
常见的功能权限有新增(建)、编辑、查询、删除、停用、分配、分享、提交、审批等。功能权限+组织权限,决定了可以看到多大范围的业务数据,因查询是最基础的功能权限。比如可以查询到本部门所有订单数据,但只能修改单据的所有人(Owner)是本人的订单。
权限体系较为精细的平台,对分享还做了限制,比如张三分享某数据给李四时,可设置李四是否可以再分享出去。这样的业务场景多用于B端业务,比如商机跟进。客户是有AE负责,售前顾问提供解决方案,就会出现1个AE对多个售前顾问,客户数据需要定向的共享给售前顾问。
(2)组织权限:
分个人、部门、本下级、组织4个等级。比如个人是指一线的销售顾问,部门指销售顾问所在的部门(也可以是小组);本下级指本级以及下级部门的权限、如销售大区;组织级指当前组织下所有业务部门的权限。
下图为功能与组织权限授权页面:
(3)数据权限:
此处特指字段级权限。指某角色或某用户能否查看或编辑某个实例中的某个字段。字段级权限应用场景较少,比如费用审批中最终审批人确定的核准金额字段。字段级权限一般与页面、视图融合在一起配置使用,毕竟不让人家看到字段的值,就干脆不要让人家看到这个字段了。
5. 页面
页面有新建、编辑、查询页面。大部分场景下,新建、编辑、查询页面所显示的字段信息是一致的,即使用同一个页面布局。为了提高用户体验或输入效率,新建、编辑会与查询页面不同,增加很多交互控制,或功能按钮。
同一个实例,可以配置多个页面,并分配给多个角色,不同角色看到的页面内容不同。注意与字段级权限的配合。比如管理人员看到的商机页面与销售员是不同的,通过配置的方式给管理人员配置页面。
6. 视图
视图可以通俗的理解为列表。可以配置多个视图,并分配给指定用户或团队,不同角色看到的列表中的字段不同。
灵活的系统可以支持用户自行定义视图中放哪些字段、字段的前后顺序和业务数据的排序规则,也可以将多个字段的输入值作为筛选条件、而自定义一个视图。当然,能否自定义视图也是需要权限控制的。每个业务数据会有默认的视图。同样,需要注意与字段级权限的配合,即使增加了不可见字段,列表显示字段值为“-”或“****”。
权限体系的使用
有些平台通过分配菜单权限给不同角色的方式来呈现数据视图,还要给业务数据的查询权限,赋权较复杂,非常的不灵活。而且,权限大的用户会看到同一个业务数据有多个菜单,比如运维和系统管理员。合理的做法是:
- 菜单入口:用户拥有某业务数据的查询权限,登录后就可以该业务数据的菜单入口。菜单入口分组呈现,比如客户管理在营销、销售、服务里都可以看到。
- 视图:点击菜单后,系统根据当前用户和对应角色匹配视图。
- 可见的数据范围:视图中呈现的数据是按照用户所在的组织即组织权限来提供业务数据的。视图中呈现的功能按钮是根据当前用户的功能权限、业务交互控制规则来显示的。如,即使有审批权限,但当前数据的审批状态为已审批,审批按钮隐藏或置灰。
- 可操作的功能:打开某条业务数据时,系统根据当前用户对应角色匹配页面。页面中呈现的功能按钮是根据当前用户的功能权限、业务交互控制规则来显示的。
总结
CRM系统较为灵活,需要强壮的权限体系来支撑,对系统的持续迭代非常重要。我们在架构设计时,需要统一和标准化权限体系,开发和产品在理解上达成一致。新增业务功能时,产品经理专注于业务设计,而不需要多考虑权限体系对业务的约束和限制。
本文由 @王建儒 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
学习收藏了,今天就当一回课代表吧。搭建私域流量运营,当然必须要有工具。给大家推荐一款由【人人都是产品经理】【起点课堂】旗下独立研发的私域流量运营工具——粮仓·企微管家。粮仓·企微管家是一款基于企业微信的一款营销型SCRM系统。集裂变获客、留存促活、销售变现、客户管理于一体的私域增长闭环系统。覆盖企业客户运营的生命周期,助力企业私域流量运营,提升售前/售后服务能力。还可以免费开始使用哦~ http://996.pm/M0A06
《B端平台权限体系设计:RBAC模型的技术实现逻辑》已提交审核,如没有找到或未审核通过,可在公众号『王建儒的B星球』中找
最近比较忙,有空我会写比较细的权限实现方法。B端产品经理、后端开发是必须理解权限体系的,不然后走弯路的。
我看了有很多平台的设置很多菜单权限,通过菜单来配置组织权限。举例,简单的CRM可以玩玩,如果平台有10+业务中心、上百张业务表,50+角色,就会很容易出错。
一直没搞懂角色权限与组织权限间有什么差异?两者权限配置是否有交叉?
角色包括了功能+组织+数据权限,举个例子:销售经理可以看到销售顾问的客户数据:功能权限是客户数据的查看权限,组织权限是本小组/部门所有销售顾问的客户数据,数据权限是除了看到销售顾问看到的之外,还可以看到这个客户的信用信息,或者可以修改某个信用信息中的字段,比如建议授信额度。
功能+组织+数据可否理解为存在父子关系
不是父子关系,是相互关联、组合,形成权限约束
“组织权限是本小组/部门所有销售顾问的客户数据”是什么意思?是说组织权限是本小组/部门所有销售顾问的客户数据查看权限吗?
是指本小组/部门下所有人的客户数据的权限,比如说查询权限。但如果给了修改权限,那经理也可以修改顾问的客户数据的。其他权限的类似,比如分享等。规则就是功能权限+组织权限,是组合约束的。
权限体系的使用,这部分不知道我的理解是否正确,请指正:
1. 用户登录后,有什么功能权限,也就是菜单和按钮的权限,取决于用户所在的用户组。每个用户组里,可分配不同的菜单组合。
2. 用户点击菜单后,能看什么数据,取决于用户所在的组织结构。系统通过组织权限(个人、部门、本下级、组织)来判断可以该用户可以看的什么数据。
问题1:
菜单权限分2两类:1)非业务数据类的,这个单独赋权;2)业务数据类的,只要有查询权限即可见的。
用户组可以理解为角色吗?有些平台比较复杂,还会建立角色组的
问题2:
用户查询业务数据时,根据用户所在的组织+角色上的组织权限与业务记录上的owner对应的组织来判断的。
学习了
为什么不能在PC上不能回复一些英文,比如微软的CRM产品名称?
看样子是从事Dynamic CRM(office 365)的大佬,总结的棒棒哒,望可以向您请教。
看来你也是从事微软CRM产品的大佬哦,我们多交流。我目前喜欢帮客户自建私域平台。
当然,微软CRM我非常认可,商业产品中非常不错的产品。只是别用标准方案,根据客户业务自己玩。平台很好
是的,标准方案基本上不适合本土企业,大部分都是在这个框架中进行行业定制化,然后多项目中复用
专题内容 #汽车行业营销领域数字化平台# 敬请关注!
已发布(3篇):1-汽车行业营销领域数字化平台概述、2-车企的渠道价值评估、3-数字化转型的驱动力与方向
审核中(2篇):4-车企为什么要做数字化营销平台?5-车企线索管理的定位与流程
已完稿(1篇):6-中台化的线索管理
文章都很有深度,有理论有实践,真大佬,期待交流
感谢关注、留言。我最近在思考如何与大家更直接的沟通,想想还是蛮期待的
是不是可以开个微信公众号,毕竟大家平时微信用的最多
看我个人信息
加我,建群
败给平台的违禁词了
您好,已经加您了