谢谢大家。非常荣幸有这个机会到计费网做一个演讲。刚才王总漏讲了一个，我曾经是他的兵。我今天讲的题目就是建立可持续演进的CRM基础架构。我认为今天非常巧的是，早上神奇吴总谈到了资深厂商在资深系统方面的可能性、必要性。实际上我是来自亚信的研发部。亚信和神奇的思路有一些雷同，我们也希望通过多年的积累实现一些国产的工作。早上吴总也讲了，这里面最困难的是客户营销支撑，就是CRM这个部分难以产品化。目前亚信在CRM方面，就是客户营销支撑这一方面，我们做这个产品化的一些基本的想法以及一些典型的事件。
        我讲的东西分成这么几块，其实很简单。就是三句话，第一个为什么CRM不好做产品化。第二个是我怎么做可以使它可能产品化。第三个是亚信做了什么。
        这是营销支撑。这包括三大块的内容，包括客户交付、市场与客户的洞察以及产品管理，就是三大体系的流程，这个分下去有很多的流程。无论是客户交付还是产品的开发以及市场洞察，所依赖的东西首先要要求有完备的数据和信息。基于这些数据跟信息它的操作流程是我们这个系统所表现出来的功能。还有这些操作流程是不同的运营商在不同环境下的运营商、在不同管理下的运营商这个是否匹配的，我们是跟组织技能相匹配的。从这个角度讲是什么意思呢？我们的数据和信息很多时候都是不完备的。我们的操作管理流程在很多运营商内部、在部门内部可能是清晰的，但是跨部门的流程往往是不清晰的，而在系统的建设过程中逐步深入、完善。人的问题就更不要说了。
        总体而言，我认为在不同的阶段、不同的时候建立一个客户营销管理系统，永远是变化的，这会不停的发生变化，持续变化和演进的过程中，我们面对的是这样一个系统。
        第二个营销管理支撑系统从另外一个角度我也阐述一下这是变化的。网络也在不停的融合，一些新的技术也不断的涌现。很多年前我们看到网络的变化导致这个变化。但是现在我们很清晰，在网络没有变化的时候，不同的竞争状态，不同的市场环境下，推出不同的营销策略，就使得你这个营销支撑管理系统。基于管理来讲，跟你的管理是相匹配的。我的PPT主要是强调我们需要做的是一个变化的东西，它的外观、它的表现是不断要变化的，更何况我们处在这样一个环境里面。我相信运营商一定需要的是一个能够随需应变的系统。随需应变的系统如果我们没有办法做，我们是不是只能提供现场服务了呢？这是一个问题，一个巨大的问号，我想也围绕了神奇很多年，也围绕了亚信很多年。
        对于技术我们进行一些分解，从技术角度我们看这些问题，在我们搭建某一个系统的时候，我从多个角度分解这个工作。我们发现不同的工作它的复用程度，大部分是比较高的。因为我的时间比较紧，就不详细的阐述了。我们仔细的分析这些点，如果我们能够把低的，逐步的变高，这个是不是就可能强一些呢？我们做了很多方面的努力。
        首先一个最大的努力是什么呢？就是要减少系统间的耦合度。本身是大的变化，这个变化是每个模块局部小变化，而这不是整个的大变化，这要减少系统间的耦合度。还有系统内部的耦合度。我也希望在业务变化的时候，我的概念层面依然是可以支持的，我的变化不至于对整个系统导致的是致命的颠覆。其他的还有，不同的运营商，可能是同一个运营商的公司，管理流程可能不一样，这个业务规则是完全不一样的。我们希望这些不同的东西，不要融合在浩瀚的代码中，而要把这部分的东西，把这部分不太一样的东西，能不能用集成架构从这个里面抽取出来。这也是把流程以及业务规则和主体的业务进行分离，以及其他我们采取了很多办法。
        亚信的研发中心在这么多年来，在CRM这个领域，我们一直在尝试，只要符合这些能够提高复用度的，可以把这个变化抽取出来的，我们都在吸收外面的经验，我们也不断的在工程中进行实践。现在我们基本上形成了我们初步应对变化的思路。这个思路我不能读一遍，因为每个字都是我自己敲进去的。所有研发考虑这个问题的出发点就是这些，没有其他。
        第一个我们认为功能的变化和发展是恒定的，但是变化的功能是不是能够限制在一定的范围内？或许我们需要分割系统，建立松散耦合的总体架构，并不急于工具实现系统间的服务的互相调用及管理监控。
        第二个在某个功能实现，页面功能必须要基于用户易操作习惯及总体风格要求来定制、或许我们可以提供快速的页面开发组建。我们使开发人员可以在一些琐碎的GSP代码里面分离出来。
        第三个某个功能实现，流程、规则是导致业务逻辑对象（业务组件）变化的主要因素，或许我们可以基于工具来管理和配置并把他们从业务组件中抽离。
        第四个业务组件的变化依赖于数据模型。车厢业务概念，加强数据模型标准的研究建立适应国内运营支撑系统现状的落地，并实现从概念、逻辑、到物理存储多个层次，是稳定数据模型的关键。
        第五个，业务组件本身是原子化及基于一定的业务过程进行组装，在组装这个过程中可以提供一定的工具。
        第六个我认为要通过长期的工程实践进行归纳和总结。其实我们看，哪怕是固网，我在亚信做过固网，也做过移动。比如说产品订购，我没有看过有什么差别，都是这几个步骤，这个总结出来我们叫业务框架或者功能模板，这个模板在一定情况下也是不变的。这是应对思路，还有其他的一些东西，我这里是概括性的讲一下。
        再从底层往上看，可变的营销U系统存在着许多不变的特性。一些不变的东西就是我们所谓的CRM产品的基础。如果我们可以建立一套营销服务系统业务技术开发平台，这个二次开发平台我认为就是我们CRM产品演进的必由之路。但有一点如果我们想把一个解决方案完成，要把客户服务好，我们要跟运营商强调现场的服务、强调现场的服务流程和服务。总的来说，我们没有具备这样的能力之前，运营支撑系统，对于厂商而言，这是一个服务。
        我大概做了一个简单的思路归纳和总结。一个是CRM是一直变，第二个是针对变我们找到中间有什么不变的东西。下面就跟亚信非常相关的。我举了一个总体的想法，就是建立CRM基础开发平台是适应变化的良方。就是我刚才说的二次开发平台是变化的唯一解决方案。
        我们亚信经过6年时间的积累，我们开发了两个产品。一个是面向外部的企业级流程，一个是面向系统的私有流程。在这样的情况下，我们有一个Comframe进行封装。我们还有PROCESS以及面向业务组件的服务管理。总体来说，我们通过这两个工具，6年来不停的丰富和完善来实现了整个应用面向流程的开发。
        刚才举了一个例子，我们把一个图经过COMFRAME封装以后的情况。我刚才也讲了实现业务过程，就是PROCESS的可视化。我们用画图的东西，很多业务组件会有注册，随着业务组件的增多，你用的话可以拖过来，整个东西可以有两种模式。还有基于APPFARME事件框架动态实现规则检查点配置。如果我们这个EMAIL变化的接口变化的话，你整个接口都要变化。规则有一个规则的建模和规则引擎的基础。我们亚信都采用了APPFRAME的界面。基于平台我们探索的是有没有可能脱离应用，基于平台级进行一些深入应用级监控。我们知道移动的网管系统要求越来越高，但是应用级的网管还是有一些困难。当一些系统上线的时候，我们很难定位哪一个优先，但是使用这个平台的话，我们就可以知道是哪一个代码出现了问题。在使用的过程中，我们可以定位到某一个营业员，为什么速度比较慢？这会直接统计一些数据出来，这是目前的一些情况。
        这个最新的版本，基础技术框架平台，表达的方式上进行了更新。我们有一个架构，一个是APPFRAME和COMFRAME。这是第一个。
        第二个，我们光有这个平台，是不是有第三方的数据就可以了呢？我们现在没有第三方，这个情况是不是一样呢？我认为还是有区别的。所有的东西都是在功能实践中进行总结的。
        在业务层面我们怎么办呢？我刚才说了，我们要进入一些模型，这个模型大家很熟悉，不用我解释了。我们针对电信业务及系统开发经验，我们要进行本地化。我们在不同的现场积累不同的经验，如何进行本地化。但你服务的开发、你系统的设计一定是基于逻辑性系统设计的，而不是基于物理系统设计的。转变成你物理模型的时候，需要考虑性能等等其他的东西。这样使你的应用相对来说比较强的。这是刚才表达的一个意思。我们也根据这个项目进程吸收经验积累，有一整套东西。这个我们起名是BCE，就是累积业务框架。  在开发的过程中，我们也会建立业务层的框架，随着你工程增多，你这一部分的框架和模板会越来越多，这是一个例子，讲到BCE框架的例子。
        这个里面我想讲一个，就是运营商使用时候的一点，就是产品的框架，独立性、产品的设计。你能不能支持融合业务的受理，以及业务受理能不能顺应市场环境的关键。所以这一块我们也花了很大的工夫做。整体的CRM架构底层是套技术平台，然后吸收了很多数据模型对它进行落地，下面再不同的积累业务配置环境或者开发平台。我们把这三个东西合在一起，起了一个名字是ABaCus，大家都知道这个意思，这是算盘。
        下面我们简单介绍一下ABaCus的技术框架。为什么我们请的名字是AbaCus？这里我看大家比较累，我给大家解释一下，这个ABaCus，这个里面有A、B、C三个字母，A等于APPFRAME，B等于BCE，C等于Comframe。我想算盘这个东西显然比较模块化和构件化，是由珠子构成的。我们希望通过不同的工程实践积累算盘的珠子。第四点带有隆重的亚信公司情结。
        基于ABaCus的CRM架构体系。我相信未来三年，我们的框架越来越完善，越来越丰富。那个时候我们的CRM开发已经有一定的能力了。我再次说一下ABaCus这个东西的特点，我刚才说了，它真正的实现了面向流程开发。从功能制订以下无法做出产品化的东西，想做产品化，必须要有流程。第二个ABaCus完全是一套具备完整SOA理念的架构。我们现在整个BOSS系统，这个数据进行分布。不同的数据率可以提供它的服务，这些服务被APP平台管理和注册，这些服务假如我们日后在不同的现场这些可以重用，那么这些重用的服务就会纳入ABaCus的管理范畴。如果不能重复使用，这至少是一个范例或者模板，可以降低现场的工作量。我们做这个ABaCus的目的，我们不是非要做这个东西，我们是为了提升我们向客户交付解决方案的能力，缩短向客户解决方案的时间，所有的努力都是为了这个。
        整个架构上来讲，我刚才也说了，我可以用三个角度进行概括一下ABaCus。我们现在已经在一些工程里面逐步应用了。我认为有三个比较好的方面，第一个可扩展性比较强。其实我刚才一再谈这个。第二个我认为稳定性也比较强。为什么？因为我们可以在研发中心对ABaCus的测试、基础架构的测试投入大量的时间。但是并不见得现场的人就会很轻松，不是的。只不过我把现场人的工作从技术中解脱出来，去专注于业务，从业务设计中解脱出来，或者从文档中解脱出来去做、去满足市场部门的架构或者整个设计的要求。工作重点就会发生转变。第三个ABaCus在一开始设计的时候，就会完整的考虑这个系统的可管理性，这个系统是可控的、可管理的。我最近这几年也陆续看到BOSS系统在这几年要求越来越高，但是应用级的东西很难做到，这个是因为在集成架构上面无法提供这样的节点。
        我觉得一个产品的特征，当你的研发中心开发的时候，这要有模式。我们通过一定的模式提交到现场，然后现场不走样，或者通过你的培训，或者通过你其他的手段使他们基于这样的基础进行开发，我认为这样的东西才是产品，产品最大的特征就是稳定。不稳定的东西一定不会是产品。
        这是我今天要汇报的总体内容。我今天早晨听了吴总的讲话，演讲非常的有感触，我不知道我理解对不对。我觉得他大概讲到了这么几句话，这可能是中间的摘录，我认为跟我们的想法非常匹配，可能高度高一些，但是确实非常有感触。
        第一个话讲到了零件产品化、接口标准化，但是整体上解决方案是专业化和个性化的。我认为这个跟我们的想象有一点一致。
        第二个吴总讲到COTS的前提是管理能力，包括你的产品能力、开发能力以及实施能力的提升，我认为这个很认同。一个好的架构，必然要有一个好的结果。这个如何积累，一定是管理的过程。
        第三点吴总讲到要实现COTS化，实现的模式要通过实践积累的，我刚才也一再的讲这个，通过工程去积累，这样的东西才是中国化的东西。
        最后我对今天的演讲做一个总结，总体的意思也就是一句话，我们总是讲运营支撑系统的开发和网络系统的开发有很大不同。但是我们今天一些简单、大的对比，我认为大方向上是一致的，国内一些公司，他们的研发思路值得我们运营系统的厂商去借鉴和学习。
        谢谢大家，我今天讲的就是这么多。