—元数据构造集成化的CRM.docxVIP

PAGE 1 PAGE 1 —元数据构造集成化的CRM  许多企业为了赢得和保持客户，将CRM软件作为一个重要的资源来利用，期望可以由此加强销售自动化、客户服务、市场营销以及其他诸多方面。然而，这些企业是否真的能够达到掌握成本、扩大利润的目的呢？更详细地说，这些企业是否由此就能够真正了解客户生命周期中的完整信息呢？就单个的业务部门来讲，各自的应用一般都可以很好地工作，但业务部门之间的协同却是个很大的问题。  简洁、局部的观点很难适应企业全球化的现实需求。元数据驱动的模型，尤其是模型驱动的信息集成，为将分散的、以业务部门为中心的CRM软件整合起来供应了解决方案。  企业通常依据其产品、人员构成以及工作场所，以独立的业务部门为单位来选购或开发各自的CRM系统。大企业很少能够一次性地为全部业务部门部署完全集成的CRM系统。因此，CRM系统往往会呈现出多样性，在同一企业中的不同业务部门设置许多互不兼容的数据模型。造成这种局面的主要原因:一是应用系统可能来自不同的系统供应商;二是各部门的详细需求存在差异。特殊是当两个企业合并的时候，集成本身的复杂性加剧了系统的多样性。  要识客户真面目  为了在“以客户为中心”的市场环境中保持竞争力，企业需要对客户有全面的熟悉，并且在企业内部共享客户信息。反过来，客户期望得到最好的服务，同时也期望企业全部部门都完全了解他与企业已经发生过的全部交互活动。客户不期望单单是曾经和他有过联络的那些部门了解这些状况，他不会把你的企业看成一个分工明细的大集团。相反，他期望企业的全部资源都在为他一个人供应一体化的服务。所以，他只会给你的企业打电话，而不管接电话的是客户支持部门还是投诉部门。为了供应最好的服务，企业必需从任何可能的客户资源和客户关系中为全部需要这种信息的业务部门供应有效的信息，其中既包括企业内部信息，也包括企业外部信息。  全部的CRM系统都有一个共同点：需要将CRM数据保存到某个地方。在应用CRM系统之前，企业最好将现有的信息保存到一个整合的数据库之中，当然这会消耗许多的时间和经费;在数据装载完成后，企业需要制定相关的数据使用和交换规程。这套规程为全部的客户供应数据交换的方法。数据库是CRM系统开发的核心。不仅如此，当企业在内部或者其他应用软件中使用这些信息的时候，挑战依旧存在。  虽然后端数据能够让我们对客户信息有比较全面的熟悉，很多企业还是购买一些前端软件来使整个应用程序变得简洁易用一些，但是这两者的集成却会变得特别困难，同时也比较费时。新的EAI软件能够跨系统工作，这大大削减了企业的工作量和费用，同时也能供应具体的业务规则。然而这些步骤只能为一些相关的交易供应信息反馈。一个麻烦的问题是，维持系统运转的信息和其他可供利用的数据资源仍旧无法得到满意。为了解决这个问题，一些CRM系统的开发商建议使用ETL（ExtractTransformandLoad，提取转换和加载）工具来随时从数据源中选取数据，并且将其保存在适当的系统中。你会发觉，这并不是一个很好的方案。  根本在于元数据  元数据模型驱动，尤其是模型驱动的信息集成，可以有效地解决CRM系统以业务部门为中心、各自为政的问题。元数据模型能够捕获存在于企业中的各种具体信息，比如客户支持部门使用基于Oracle的CRM解决方案，而投诉部门使用MicrosoftSQLServer数据库，这些数据的整合问题都可通过元数据来解决，甚至包括那些在组织机构之外的数据资源。  元数据模型描述了存放在不同数据源中的信息内容，同时供应了一套专业术语。这套专业术语是基于对象管理工作组（ObjectManagementGroup）的元对象设施标准（MetaObjectFacilitystandards）而制定的，能够便利地解释某个数据库中的一个对象与另一个数据库中的对象之间的联系。  一旦企业为业务部门的分布式信息系统、合作伙伴的或者是其他外部数据库中的信息建立元数据模型之后，就会得到一个比较完整的视图，说明各个应用软件是如何利用这些数据的。元数据就像是一个实现数据转换与集成的虚拟层，把企业花费了大量的时间和金钱、经过成年累月积累下来的各类数据整合成一个单一结构的大型数据库。  当这个元数据与信息集成引擎协同工作的时候，它能为企业带来一份关于整个企业数据的单一视图，同时也能供应一个强有力的数据提取引擎，将数据集成起来并传递到应用软件中。信息集成引擎所需的独立接口被看做是应用软件和信息的一个中间层，企业不需要进行代价昂贵的数据转换，也不需要冒险用ETL软件来收集信息。  集成的威力  通过信息集成引擎，企业可以利用现有的商业智能系统、门户和CRM系统