浅析CRM系统的用户权限管理

编辑导语：权限管理可以用来控制什么人可以干什么事，需要根据每个用户的部门、角色来明晰的划分，以此来保证系统的数据安全。本文作者根据自身公司在引进使用CRM客户关系管理系统时的情况，对CRM系统的用户权限管理停止了分析，一起来看一下吧。

在公司深耕教育行业8年之际，终于决定引入CRM（Customer Relationship Management）客户关系管理系统，以下是一些系统使用心得。

一、背景分析

以往公司所有订单数据均是依赖金数据这种表单搜集系统，金数据有一个好处就是灵敏，搜集的数据最后都集中于一个个的表格里，想要修改什么信息非常方便，也很容易就创建出来复杂多变的表单来搜集数据。

但是这也会带来一个很大的问题就是数据容易泄露，不论是暴露在表单里的数据还是表单搜集来的数据（真的就发生过，嘘~），再者就是在项目运营期间的数据轮转包括数据统计都非常的不方便，对学生来说，这就是一次性的消费没有账户概念，也不利于公司内部导流和复购。

还有一个问题就是数据权限问题，以我司举例，我们的员工分为销售部、产品部、客服部、技术支持以及其他职能部门。产品部分管公司的不同项目，销售部按东南西北区域划分市场，客服部是负责公司400客服热线的部门。金数据搜集来的数据对于所有这些员工是无差别展示的，总监和专员在数据呈现上没有任何区别。

因而随着公司业务开展以及长期战略规划规划，决定抛弃以往方式，引入CRM系统，协助公司实现更加数据化、规范化的前进开展，处置公司在客户管理、销售行为管理上的痛点、难点。

二、主要目的

公司希望所有的报名数据整合在一个系统，对学生生成账户，形成订单记录，为以后的更多玩法奠定根底。再加上订单会有大量B端产生的数据，所有B\C端的数据在项目后期又会统一运营，所以还会涉及到和自有系统的推送问题。

最重要就是保证数据安全，不论是对内的员工还是对外的竞争对手。以我司举例，我们的销售部要看到自己负责的所有产品的数据，产品部要看到自己负责产品的所有区域的数据，客服部要看到自己支持部门的所有数据，技术支持要看到公司所有的订单数据。所有这些员工谁该看到什么、谁能干什么，这需要一套完善的权限管理办法来实现。

权限管理简单来说就是用来控制什么人可以干什么事，需要根据每个用户的部门、角色来明晰的划分，以此来保证系统的数据安全。

本文也主要讲解CRM系统的权限管理模块内容。

三、施行办法

先理解一下CRM系统的“三位一体”多维度权限管理方法，这种人、部门、角色的多维度权限管理办法兼备灵敏度和易用性，当人员与部门变动后，只需简单调整即可完成对应的组织权限关系，并且能根据需要处置用户相关联数据。

在CRM系统里的每一个用户都有一个部门的划分，作为权限管理里一个重要的层级。每一个用户又可单独分配角色和职能，而权限管理又以此分为角色管理和职能管理。

其中职能管理用来控制你能做什么（比如能否查看订单、能否删除订单能否转移订单），角色管理是决定了你能操作哪些数据（比如只能操作自己的数据、自己及下属的、本部门、本部门及下属部门或者全部数据）。以一张图示来标明这种关系：

每种职能的功能权限构成“权”,每种角色的数据权限构成“限”。权+限=一个用户完好的权限。

下面以订单举例，逐个分析每个部门用户的权限管理办法：

1. 销售部


销售部员工是按区域划分各自的效劳范围，比如一部分员工专门负责华北区域的订单，这些员工又分别负责各自的项目。

图1

销售部的员工需要的功能有根本的增删改查订单权限，如上图第三级列表，这些功能需要在职能管理中设置，职能管理配置截图：

图2

图1的二级列表标签是代表每个销售员工根据自己职位的上下可视的数据范围，比如专员A不应该看到专员B的数据，主管应该看到自己及下属的数据，这种可视数据权限即需要在角色管理设置。角色管理配置截图：

图3

以上是销售部员工基于部门&角色的权限管理办法。但是销售部员工的订单负责人均是自己，也就是说除了自己他人都看不到也无法操作这些订单，那产品部的权限该如何处置呢？

2. 产品部


产品部员工需要看到自己负责产品的四大区域的订单，而这些订单的订单负责人已经划分给销售了，所以产品部无法直接看到订单数据。再者一个销售可能同时负责多个不同产品负责人的项目，因为这种互相交叉关联，所以也无法利用系统的助理或者共享规则来实现。产品部和销售部两个部门的数据对应关系如下图所示：

此时销售部门的依照「部门」的数据划分形式不能满足产品部门了，所以产品部门就需要开启数据权限多维度管理，新增「产品」管理维度，将业务对象“订单”及其他需要的对象同时开启产品维度管理，系统开启截图如下：

图5

将需要开启产品维度管理的对象开启之后，给每一个用户的权限设置选择自己负责的产品，这也就构成了产品部门用户的“限”，产品部门的“权”则和市场部门一样根据自己的职能决定。产品选择截图:

3. 客服部


客服部是依照对应区域给各销售人员配置的，类似于助理角色。因而可利用系统的“助理设置”，即把某销售人员设置为经理，把其对应客服设置为他的助理即可。

因为系统的助理具有和经理一样的数据查看权限，这样如无特殊要求则无需新增一种新的角色，但是需要根据业务需要新建职能，来特殊控制客服部门的操作权限，例如客服只能查看订单详情但是不可以删除订单。系统配置截图如下:

4. 技术支持


技术支持这一角色因为其角色的特殊性，所以需要看到公司所有人的订单数据，所以在上图3的角色权限设置为全部即可。但是技术支持又不需要像顾问或者客服一样高的功能权限，这一点也在上图2的职能权限设置即可。

有些时候技术支持不需看到订单的某些特殊字段，此时利用CRM系统的一个特殊功能：每一个对象的每一个字段都可以针对每一个职能来单独设置字段的可见\只读\导出权限。系统配置截图如下：

四、考虑总结

以上是以订单举例来盘点crm系统个用户的权限管理办法，总结一下就是有两种权限管理纬度，部门和产品。

1）部门的权限管理办法

用户可拥有多个角色及多个职能，职能负责控制功能权限，角色负责管理数据范围。给每一个用户赋予角色和职能,再把权限赋予这些角色和职能，这样的权限管理办法也就是RBAC（Role-based Access Control）基于角色的权限控制模型。这样的权限管理形式拥有极大水平的灵敏、便利以及可拓展性，关于此模型详解本站也有很多文章分析，感兴趣的同学可以去搜索。

2）产品的权限管理办法

直接给用户勾选数据，这种就是传统的权限管理模型，直接给用户自身赋予权限。而这样的管理模型无疑是不够灵敏的，一旦人员发生变动则有可能牵一发而动全身。

不论是什么产品都有可能遇到不同等级的权限问题，理解不同权限管理办法，在产品设计之初就应努力打造一个灵敏、可拓展的权限模块，防止用到时需要“伤筋动骨”。

本文由 @不做代码狗了 原创发布于人人都是产品经理，未经容许，制止借鉴

题图来自 Unsplash，基于 CC0 协议

转发了

CRM

转发了