CRM-系统案例分析

CRM 系统分析

软件产品评估

一般来说，CRM 分为两种：一是分析型CRM，二是业务流程处理型CRM。分析型CRM 是以改善业务管理为目的的分析活动。分析的对象是由企业的CRM 业务和当前应用所产生的相关数据。分析型CRM 使企业能够对与客户(现有客户和潜在客户)有关的各种因素(需求、方式、机遇、风险等)作出分析与评估。分析型CRM 包括以下内容：①客户分析(区域分析、风险分析、嗜好分析);②促销活动分析与管理(业务活动的有效性分析)。

一个典型的分析型CRM 系统，应该包括4 个主要的功能：①客户分析功能;②市场信息运用于客户分析功能;③日常市场活动分析;④预报客户行为的各种方法模型。

客户分析需要很多可以定量化的信息，这些信息通常来自各种不同的数据源。对于这些信息必须加以整合，并以合理的方式放到客户数据仓库中，以便于对其作挖掘处理。因此，分析型CRM 应该具有这些的接口功能：①企业与客户的主要接触点接口(客户服务中心、Web 和自动柜员机)。②关键收益点接口(POS、电子商务、定单录入)。③外部数据(客户地域分布、生活方式等信息)。

由于许多通用型CRM 产品在设计上未考虑客户行业性问题，仅能进行简单的信息录入与展现，或实现固定的简单流程，在客户化上缺乏产品平台与工具。因此，CRM 软件产品应选择注重行业业务应用特点，把行业营销与服务业务所涉及的基础业务功能融合到产品中，形成行业产品平台的软件。在应用上应选择接近业务流程的产品，并在客户化过程中将关键业务操作融入系统，以保障应用的效果。

厂商评估

在CRM 厂商方面，我们看到CRM 厂商出现了比较明显的分化。CRM 厂商基本上分化出三种厂商模式：

通用型CRM 厂商。这类厂商从CRM 理念出发，将客户管理的通用思想，例如：客户生命周期、客户价值金字塔、交叉销售、向上销售、精细营销等理论用产品的方式固化并实现。这类厂商理论上可以进行跨行业的应用，但是实施难度在于要和每个行业、每个企业的具体实践相结合，提出有针对性的方案，沟通难度大。

行业特色CRM 厂商。这类厂商往往从最有经验的行业进行突破，其产品具有明显

的行业特征，在某个行业的影响力较大，这类厂商在行业内的竞争优势明显，而且其实施经验也相对丰富。

企业定制CRM 厂商。这类厂商多数为系统集成商，以项目研发和完全的定制化运作，一般是根据客户的需要开发管理客户的模块，确保产品符合企业的特殊需要。缺点是这类厂商的CRM 理论和实践均具有局限性，优点是对单个项目的成功运作具有成熟的经验。

行业特点及CRM 支撑重点分析

我们知道CRM 管理的主要是市场、销售和服务的相关业务，而在这三个业务领域中，不同行业的业务特点和管理要求差别很大。CRM 来说，我们可以从产品和客户的复杂性，市场、销售和服务过程的复杂性等方面来进行行业特点的分析。

CRM 应用对于企业而言越来越重要，因此在商业软件系统中，很多软件都号称有CRM 的管理功能，有的是独立的CRM 产品，有的是与其他软件，比如OA、ERP 集成的产品。这些CRM 系统都有各自的特色，能满足特定行业的需要，根据行业特点确定大的选型方向是非常重要的，否则要么难以满足需求，要么功能过剩，而且应用起来非常不方便。

AMT 咨询认为，从技术层面，用管理对象的"信息颗粒度"来进行不同CRM 系统的区分是一个最重要的标准。所谓信息颗粒度是指对管理对象描述的细分程度，总体而言OA 管理对象的颗粒度是文档级，而ERP 是字段级，也就是我们通常所说的非结构化和结构化。一般来说，管理对象量化的描述越容易，结构化就越强，比如订单，所有信息都可以进行字段级的描述，而对于合同，就很难进行字段级去描述。

从"信息颗粒度"角度来看，CRM 是一个介于OA 和ERP 之间的结构化和非结构化的产品，而不同的商业化CRM 系统在这方面差别很大，总体上可分为：

·文档级的CRM

·字段级的CRM

·介于两者之间的CRM

一般OA 类产品中的CRM 都是文档级的；一些大型的CRM 系统，尤其是与ERP 紧密集成的CRM 系统，比如Oracle、SAP 是字段级；而一些中型的CRM 系统，比如Saleslogix、MicrosoftCRM、Kingdee、TurboCRM 等刚好介于二者之间。

以下以合同为例，来说明不同的CRM 系统是如何管理一个合同的？如果是文档级的CRM，合同就是一个附件，就是一张纸，无非是电子的，最多我们能抽出里面最基本的属性来进行描述，比如签约双方，签约日期，有效期等等，但是合同的条款呢？它对文档级的CRM 系统而言只是"一张纸"而已，是一个黑洞，计算机无法理解合同意味着什么。但是像Oracle 和SAP 这样的CRM 系统，它是如何管理合同的？完全像订单一样，它通过非常多的字段，以及规则来描述这份合同，把合同的条款变成可执行的规则和指令，这样合同就变成了可执行的"订单"，就像订单要发货，要收款一样，是有相应的规则和流程来处理的，比如如果合同上有一个条款是：客户收货后 3 日内，厂家上门安装。那在系统中就会根据客户收货的日期派出一个安装服务的任务给相应的人员，而不再是纸上的一句话而已了。

那有这个必要吗？如果公司每天处理100 个合同没必要，如果是1000 个合同，只有10 个人负责合同跟进这件事情，就有必要了；如果不是这样的合同，而是一个咨询服务的合同，可能也没必要了。这就是说首先要考虑业务的特点和管理本身是否需要这样的管理精细程度，然后再考虑IT 系统的颗粒度是否需要与之匹配。

回到信息颗粒度的概念上来，OA 中的合同颗粒度本质上就是文档，而像Oracle 这样的系统，合同不是文档，而是对象，通过无数字段信息和规则描述的对象，颗粒度是字段级的。有了字段的描述，意味着后面有一堆的业务逻辑来支撑这个合同的自动化运行，这是二者最本质的区别。

即使同样对管理对象进行字段级的描述，由于其颗粒度的不同，差别也非常大。比如对客户行业的描述，在一般中小型的CRM 系统中，用一个字段进行描述，这意味着从多个维度进行客户类型的划分系统无法支持，因为我们无法把一个多棵树型的复合结构（每个维度对行业的划分可以看成一棵树）简化为一个字段来记录。而在一些大型的CRM 的系统中，客户行业的划分本身是一张表，从界面上表现为用户可以增加任意多的行来进行客户行业的划分。所以在这样的系统中，行业本身是一个管理对象，而不是一个字段。更为重要的是，这样的处理不单是对客户不同行业的记录，而这种描述可在相关的业务逻辑中进行应用，比如在市场活动中根据多个维度筛选参加活动的客户、根据多个维度来进行不同行业客户解决方案模版的定义等。

根据行业特点，结合不同CRM 系统信息颗粒度的概念就能确定大的选型方向，比如对于咨询服务业，选择文档级的CRM 系统是适合的；对于大型装备行业必须选择字段级的CRM 系统；而对快消品行业，可以选择介于两者之间的系统。