关于理解客户方面，在前篇中曾经提出如下两个问题：

　　 在电信行业日常运营中记录的原始客户信息不够完整，并且这些信息被割裂在"BOSS系统"、"客服系统"、"BI系统"至少这3个系统中，无法向企业各部门、各角色人员提供一致的展示。

　　 对原始客户信息进行分析的广度、深度均不足，同时这些信息也仍然无法向企业各部门、各角色人员提供一致的展示。

　　基于目前系统建设的现实条件和发展阶段，我们可通过做这几方面的工作来达到解决这些问题的目的：

-在日常经营生产中记录完整的原始客户信息

-对客户信息进行更广泛深入的分析

-向服务和营销人员提供统一有序的客户信息视图展示

　　这里先给出目前阶段为解决这三个问题而设计的建议方案总体架构图，下面将分别对相关内容进行进一步的解释。

　　
图1 理解客户方面可以做的改进

　　记录完整的原始客户信息

　　这个问题，其实就是如何更好的"了解"（仅仅是了解而已，还谈不上理解）客户的问题。我们来看看在目前系统建设的水平下，应该进行怎样的改造，以能够在日常经营生产中记录完整的原始客户信息。

　　我们知道，由于历史发展的原因，在我们建设BSS系统的前几年，并没有CRM的理念，所以一般往往客户信息被分割在几个不同的系统。最初，我们为了提供业务受理和计费服务，在营账系统中记录了客户的基本信息、订购关系信息、账户存折等信息；在客服系统中，记录了客户的投诉、咨询、建议等服务请求信息。接下来的几年中，我们认识到在海量数据中进行数据挖掘的价值，从而建设的经营分析（BI）系统，在BI系统中除了其余的挖掘主题外，我们也进行了针对客户相关的数据挖掘，如：客户消费行为、离网倾向等等。这些经分中的信息就又形成了客户的另一种信息。综上所述，目前我们国内的电信运营商，即使省集中化做得最好的运营商，其客户信息也至少被分割在营账系统（往往归属BOSS或BSS）、客服系统、BI系统这三个地方，更不用说没有完成省集中、或刚刚完成省集中的运营商了。

　　对于这样的局面，当然首要的基础要做到的是进行系统的省集中建设。本文不对省集中进行讨论，而只对省集中之后如何在营账系统、客服、BI之间进行信息集中给出建议。这里针对前面图1相关的内容说明如下：

　　 将BOSS或BSS的营账子系统数据库，定位为今后的O-CRM数据库。一般来说，BOSS/BSS系统中的CRM部分功能，被称为O-CRM(运营型客户关系管理)；而BI系统，中的CRM部分功能，被称为A-CRM（分析型客户关系管理）。

　　 非常重要的一点，要在不久的将来使得营账数据库转变为O-CRM数据库，就必须将账务相关的数据如账单等从中挪出，从而使得其逐步转变为严格的OLTP性质的数据库，而非目前的OLTP/OLAP混合的库。这实际上就是要实现营账的分离。而要实现营账的分离，并不是一个将账单等数据从数据库挪出这么简单的事情，更重要的其实还是因为账务应用（出账、信用控制等）使用了大量的营业数据。因此，要实现营账分离，就必须使得账务数据库能够有完整、独立的营业数据（即三户资料）。而要使得账务数据库能够有完整的三户资料，而且这些资料必须是实时更新的，就必须在账务系统中也建设类似中间件的应用，这一中间件应用纯粹只用来从O-CRM系统接收最新的三户资料变更请求。由于这属于另外一个课题，这里不做深入的讨论。

　　 将客服系统、BI系统的相关客户信息全部集中当前的营账数据库（即将来的O-CRM数据库）。其中，客服系统将客户服务请求（投诉、建议、咨询等）信息导给O-CRM数据库（即图中序号①所示），而BI系统将客户分析相关的信息集中到CRM数据库（即图中序号②所示）。

　　 从目前阶段开始的一段时期内（大概2～4年），还可以保留客服系统独立进行客户服务请求信息的管理和保留相关业务逻辑，不强行要求其和BOSS/BSS融合为一个系统，但要求其将客户服务请求等信息通过文件非实时接口（如每天一次）同步给O-CRM库（即图中序号①所示）。同时，要求客服系统将客户服务请求信息的管理（即投诉咨询等受理）功能和呼叫中心平台本身的业务管理（如坐席签入签出等）功能进行物理部署上的分离，以便为将来实现O-CRM的完整糅合打下基础。