随着市场竞争不断激化，顾客成为企业重要的“隐形资产”，CRM这一词在近年来大热。

但究竟什么是CRM？大部分人和企业都是一知半解，而市面上的解释也繁多。本文将从CRM的定义、运作原理视角、商业逻辑以及现行的CRM系统，帮助解析CRM，以期为广大管理人员和使用人员提供参考。

一、什么是CRM？从定义和例子简析

CRM，即客户关系管理（Customer Relationship Management），是一种以客户为核心的管理理念和业务策略，旨在通过建立、维护和发展良好的客户关系，实现企业与客户之间的互动、沟通和合作。

从定义上可以清晰的注意到CRM的要点是：客户导向和维护客户关系。

举一个简单的例子：

老酒馆的老板王老板，总是能记住老客户的样子、名字（或昵称）和喜好，并在每次客户进入酒馆时问好。王老板对老客户的信息记忆以及问好就是一种朴素的客户关系管理。

二、CRM是怎么运作的？

CRM系统的运作流程可以大致分为以下几个步骤：

1、客户数据收集：首先，需要收集客户的基本信息、联系方式、交互记录等数据。这些数据可以通过各种渠道获取，包括网站注册、电话咨询、邮件沟通等。

2、数据整合和存储：将收集到的客户数据整合并存储到CRM系统中，建立客户档案和数据库。这样可以方便对客户进行管理和跟踪。

3、客户分类和细分：根据客户的特征和需求，对客户进行分类和细分。这有助于更好地了解客户群体，制定针对性的营销策略和服务方案。

4、销售机会管理：CRM系统可以跟踪和管理销售机会，包括潜在客户、销售阶段、销售预测等。销售团队可以通过系统记录和更新销售机会的进展情况。

5、客户互动和沟通：CRM系统提供了多种沟通工具，如电子邮件、短信、电话等，方便与客户进行互动和沟通。可以发送营销资料、回复客户咨询、提供售后支持等。

6、客户服务管理：CRM系统支持客户服务的管理和跟踪，包括问题记录、工单管理、客户反馈等。通过系统可以追踪和解决客户问题，提供满意的客户服务。

7、销售分析和报告：CRM系统可以对销售数据进行分析和报告，生成销售报表、销售趋势分析、销售预测等。这有助于评估销售绩效、发现销售机会和制定决策。

8、自动化流程和提醒：CRM系统支持自动化流程和提醒功能，例如自动分配任务、提醒跟进、工作流审批等。这可以提高工作效率，减少人为错误。

9、数据安全和权限管理：CRM系统需要具备数据安全和权限管理功能，保护客户数据的安全和隐私。只有经授权的人员才能访问和操作相关数据。

三、CRM商业逻辑——从CRM价值了解CRM

CRM（客户关系管理）系统可以被广泛应用于各个企业部门和角色，并给企业带来顾客价值，包括但不限于以下内容：

1、完善产品/服务设计：根据客户数据改善产品或服务的外观、功能和流程等，减少产品/服务设计失败的可能性。

2、增加企业美誉度：客户服务团队使用CRM系统来记录客户问题、投诉和请求，及时响应和解决客户需求。CRM系统帮助客户服务团队提供高质量的客户支持，跟踪问题处理进度，并确保客户满意度。

3、营销支持：市场营销团队使用CRM系统来进行市场细分、目标定位和个性化营销活动。他们可以利用CRM系统分析客户数据、市场趋势和营销效果，制定更有效的市场策略和营销计划。

4、销售支持：销售人员是CRM系统的主要用户之一。他们使用CRM系统来管理销售线索、客户信息、销售机会和销售活动。CRM系统帮助销售团队跟踪销售进展、了解客户需求，并进行个性化的销售沟通和跟进，以提高销售效率和业绩。

四、从现行的CRM系统了解CRM——以简道云为例

现行的CRM系统主要分为两种，一种是定型的需要下载的CRM软件，另一种就是SAAS型系统。而简道云搭建的CRM系统就属于后者。

简道云CRM系统有以下几个主要功能：

根据现行的CRM系统，我们可以看到，CRM具有极大的价值，能够延展到企业生产、经营、营销、核定绩效、公共关系和营销等多个方向。

简道云CRM场景套件，提供预定义+自定义2大模块能力，快速落地L2C（线索到成交）全流程。除了CRM，提供200+的OA、ERP等模板，解决数据孤岛难题。前往了解CRM解决方案：

本文为我们介绍了功能权限和数据权限的不同点、以及不同部分中的要点与注意事项。

做2B的系统总是不可回避的遇上权限问题，他不是核心业务却又必不可少，而且总是牵一发而动全身，更要命的是不同客户组织架构完全不同，功能复用性很低。有没有什么方法论能快速理清权限问题呢？

我们一般说【权限】的时候是在说功能权限和数据权限。功能权限指用户登录系统后能看到什么模块，能看到哪些页面，而数据权限指的是用户在某个模块里能看到几条数据，能看到哪些数据。以下分别描述一下我对功能权限和数据权限的理解。

功能权限

在企业系统中，通过配置用户的功能权限可以解决不同的人分管不同业务的需求，但是如何实现快速配置？功能的粒度是模块级的还是页面级的还是更细粒度的？跨模块操作时没权限怎么办？

图1-1

RBAC模型

说到功能权限不得不说RBAC（Role Based Access Control)模型，它的中文是基于角色的访问控制，主要是将功能组合成角色，再将角色分配给用户，也就是说角色是功能的合集。RBAC有多个成员，但是基础的RBAC0就足够我们涉及的系统使用了。（如果想了解更多，请点击RBAC权限管理总结）

为什么要引入这个模型呢？请看以下的例子：

企业A一共有12个功能，需要创建100个用户，这些用户中有管财务的、有管人事的、有管销售的等等。如果不引入RBAC模型，我们需要每创建一个用户就要分配一次功能，至少（每个用户只有一个功能）操作100次，如果人数增加到1000甚至10000，并且一个用户可能会有多个功能的时候，操作会非常繁琐，如图：

图1-2

经过多次操作发现：分配给某些人的功能都是相同的，比如分配给A、B等10个用户的功能都是客户管理、订单管理及供应商管理这几个模块，那是不是可以把这几个功能模块打成一个包整体分给需要的用户呢？

这个包就叫做角色。由于角色和功能的对应关系相对固定，给用户分配权限的时候只分配角色即可。

图1-3

所以引入RBAC模型的意义在于：

解耦用户和功能，降低操作错误率；降低功能权限分配的繁琐程度。

图1-4 图中一个用户对应一个角色，但实际场景中也可以是一个用户对应多个角色

有些更复杂的系统可能会涉及RBAC家族的其他成员：RBAC1、RBAC3、RBAC97等，并逐渐看到【用户组】、【角色继承】、【受限角色】等概念，但模型的引入只是多了依据和调理，复杂度并不会因为模型的增多而快速降低，模型引入带来的边际效用只会越来越低。

更多角色问题请参考：角色权限设计的100种解法

功能的粒度

功能越多，操作越繁琐，复杂度越高，所以选择合适的功能粒度才能快速理清权限问题，也能帮助用户提升工作效率。

功能的粒度从粗到细一般分为：模块级->页面级->接口级（接口级的功能权限指的是哪个角色能调用哪些接口）。

从后台角度：为了系统安全，代码肯定都会实现到接口级。那我们做粒度选择的意义是什么？当然是为用户降本增效。只是粒度越粗，用户操作越简单，灵活性却越低。

非技术类的网站做到模块级就够了，否则用户体验会让人欲哭无泪。对比以下两张图感受一下：

图1-5

功能的优先级

如果权限必须细化到页面甚至接口级别应该要遵循一个优先级规律，即只要分配低优先级的功能必须先分配高优先级的功能，否则会出现有删除权限却找不到操作位置的尴尬情况（删除按钮在列表页面，却没有分配查看列表页面的权限）。具体做法可以通过交互的方式解决，比如检测到勾选低优先级的功能就自动帮助勾选高优先级的，或者通过提示性的文字帮助用户组合勾选。

需要说明的是不同的交互设计会导致优先级不一样，因为有的按钮会放在列表，有的按钮只放在详情页。我们常用的优先级顺序是查看详情>查看列表>增加、删除、编辑、其他操作按钮。

跨模块访问的问题

有一个功能权限是模块级的系统，其中模块A的页面有访问模块B某个页面的链接，那么只有模块A权限的用户可以点击链接进入模块B吗？

这个问题有两种解法：

1. 允许只有模块A权限的人通过链接访问模块B

这说明系统有一条隐含的规则：能看到链接就表示用户由模块A和模块B的某些页面的功能权限。后台需要给所有【有模块A权限】的用户【自动分配】访问模块B某个页面的权限。

2. 只有既有模块A权限也有模块B权限的用户才可以通过链接进行访问

这说明这个链接就是给同时拥有两个模块权限的用户设计的。即只有模块A权限的用户不能通过链接访问模块B。

这儿就需要根据真实业务替用户选择一种方式，但不管那种方式都可以通过交互和预定义的方式让操作更简便，比如如果选择第1种解法，那么初始化一个有A模块权限和B模块某个页面的角色，让用户随时可以选择。

数据权限

如果所有信息都是公开透明的，也就不需要做数据权限的控制。可现实世界如此复杂，每个人需要看到的、应该看到的数据永远不同，数据权限便应这些需要和规则而生。

数据权限解决的是用户能看到多少数据量和什么数据的问题，例如A和B两个用户都能看到销售模块，但A能看到320条数据，B只能看到100条数据，且A能看到的320条数据中包含着B能看到的100条数据，这些都是由数据权限决定的。

数据权限和什么有关？

数据权限一般和企业的组织架构相关，而组织架构分为树状和扁平状的（还有更复杂组织架构，此处暂不做说明）

图2-1 树状组织架构，每个部门都是一个结点

图2-2 扁平状组织架构

因为扁平状组织架构较为简单，需要注意的问题已经隐含在树状架构中，所以以下主要讲树状架构。

层级数量

不同的企业层级深度不同，如果系统支持无限层级，那好处是通用，坏处是带来了数据的复杂性和视觉实现的复杂性，所以也要具体问题具体分析。

结点间的数据共享方式

图2-3

因为用户具有的权限是功能权限和数据权限交叉定义的，所以此处假设G、A、B部门的用户都被赋予了用户管理和资产管理的功能权限

目前结点间的数据共享方式有几类：

实际业务系统进行数据权限的定义时：

a. 选择以上一种或几种规则；

b. 根据业务而定定义以上的【管理】：增、删、改、查及各种小功能的组合。

比如如果选择父结点只能【查看而不能编辑、删除、新增】子结点的所有数据，那么图中用户G只能查看部门A的所有数据而不能对其进行编辑、删除和新增。

结点里的用户存在上下级关系怎么办？

图2-4 和图2-3一样

如果实际业务中用户A1是用户A2的上级，并要求用户A1能看用户A2的数据，而用户A2不能看用户A1的数据怎么办？

如果数据权限只规定到结点级（组织级），那么用户A1和用户A2看到的数据都是一样的。所以需要再次引入功能权限的【角色】解决人员上下级问题。

例如，如图2-4，系统选择的结点间的数据共享方式是：结点只能增删改查自己所在结点的数据，另外引入角色规则：管理员可以增删改查所在结点所有数据，非管理员只能删改查自己创建的数据。那么如果用户A1的角色是管理员，A2是非管理员，A1就能增删改查A部门所有资产，A2只能增删改查自己创建的资产。

扁平架构

扁平化的组织架构比较简单，只存在树状架构中的第3个问题。请参考树状架构的第3个问题。

功能权限和数据权限的碰撞：跨模块的数据【使用】问题

假设某系统一共有两个模块：型号管理和设备管理，操作系统的流程是先创建型号再创建设备，如果一个用户只有设备管理而没有型号管理的权限，在创建设备时是否可以选型号？

图2-5

这其实是一个功能权限（接口级）和数据权限融合的问题，即用户创建设备的时候是否有请求型号列表接口的权限？列表中要展示哪些数据？

从功能权限讲：用户肯定有请求接口列表的权限，否则流程就无法走通了。

从数据权限讲：有几种规则作为参考，具体根据实际业务进行选择：

不管哪个层级或者谁创建的型号都在接口中展示（即型号数据在别的模块使用时全局可见）；只展示当前登录用户所属结点创建的型号；只展示当前登录用户所属结点及下属节点创建的型号（扁平化组织架构不适用）；只展示当前登录用户所属结点的父结点创建的型号（扁平化组织架构不适用）；只展示当前登录用户所属结点的兄弟结点创建的型号（扁平化组织架构不适用）；只展示当前登录用户创建的型号。总结建设toB的系统时要考虑两种权限：功能权限和数据权限。功能权限可以参考RBAC模型，通过引入角色、用户组等概念降低复杂度。但系统用户数量庞大，功能极度复杂且粒度足够细时，复杂度已不可避免，只需考虑是把复杂交给用户、运维还是代码。数据权限主要和组织架构有关，组织架构中树状架构较为复杂，需要统一或者分模块的定义层级间数据共享问题。数据权限定义过程中如果出现同一结点下的【用户间层级问题（上下级）】需要回到功能权限的【角色定义】去解决。有一类跨模块【使用数据】的问题也可以看成既定的接口权限和可选的数据权限问题。

总之扬帆在角色权限的海洋里绕啊绕啊绕，总会绕出几个原则，走出几个理论让我们绕的更快，徜徉的更有成就感。