CDI项目缘何失败?

在客户数据集成(CDI)措施跻身成为世界500强公司CIO首选举措时，许多CDI项目在实施阶段就惨遭失败。

可扩展性差

失败的主要原因之一就是没有认识到影响客户主数据中心可扩展性的全部因素。

例如，许多CDI供应商狭隘地认为影响可扩展性的因素无非只是一两个而已――比如每秒交易事务或加载的记录总数。

数据架构师出于对CDI项目实施终止的担忧，目前已经开始审查可能影响项目可行性的所有可扩展性因素。

现在，对供应商和项目责任方来讲，前所未有的重点就是考虑CDI项目整个周期中影响可扩展性的全部因素，CDI项目周期包括这几个阶段：创建、管理、共享和扩展客户主数据中心。

因此，许多公司都在拓展CDI可扩展性评估框架，力求全面认识CDI项目各阶段需要审查的重要可扩展性以及性能杠杆和衡量标准。这样的一个评估框架可以作为一项指南，降低CDI措施的实施风险。

CDI团队在考虑所有这些各不相同的可扩展性因素之时，必须有这样的信心：他们研究的解决方案架构灵活适用于所有这些因素。

一直以来，对CDI战略的一个重大误解就是认为公司的客户主数据中心要么具有适用性、要么具有可扩展性，不能两者兼顾。这样的认识通常会导致公司根据单一的可扩展性标准选择最理想的解决方案，而且要经过多方权衡，因而实施和维护非常拙劣。

最新的CDI指标性结果表明，可实现商性能和可扩展性并存，同时又能保持适用性和可扩展性架构。

因此，公司需要审查和选择适用性设计的架构――而且兼顾主数据生命周期的全部可扩展性因素。

适用性架构是针对客户主数据实体的灵活而可靠的数据模型。这样就可以保证CDI中心主数据的性能优化和存储优化，公司不再被动按照僵化的应用程序数据模型进行标准化。而且，这一方法确实可以整合统一的客户意见交易数据，可以避免客户中心复制大量冗余数据，确保公司可以扩展使用大规模的记录容量。

相比之下，“可扩展”数据中心――可以快速访问的单一业务数据中心存储所有客户数据类型(包括交易数据)，数据管理繁重，可扩展性差。最后一点同样重要的就是公司必须选择可以随意在分散的中心配置进行部署的解决方案，以满足大公司中不同部门的本地化要求和可扩展性要求，因为大公司中的各部门都有自己的数据管理制度。

所以，在选择风险性的CDI措施之时，请务必利用可以识别主数据生命周期的关键驱动的CDI可扩展性评估框架，和适用于所有变化因素的解决方案架构。

数据模型不够灵活

目前，公司赢取客户的成本急剧增长，而留住客户――尤其是能带来丰厚利润的客户――却变得异常困难。

因此，了解客户不只是一句口号，更是商业上的必然要求。不过，公司想要真正了解客户，就必须根据各种数据来源，创建统一、综合的客户视图。

这些数据来源包括：客户数据库、客户信息文件、财务和订单管理系统、产品目录以及外部数据服务。整合为统一的客户视图以后，公司可以制定以客户为中心的战略。

但是，如果利用现有的技术平台，借助各种数据来源、应用程序、渠道来构建和管理统一的客户视图，那将是一项非常复杂和费钱的工作，而且收效甚微。

引起费用高涨以及客户主数据项目中心失败的主要原因是解决方案的数据模型不够灵活。尤其是当CDI供应商在现有的客户关系管理等应用程序、或者在零售金融、保险等行业的固定数据模型中应用CDI解决方案，上述原因更加明显。

缺乏灵活性成为这些方案的软肋，因为数据模型必须根据客户要求定制，才能满足现有系统和业务的需求。如果数据模型经过重大修改，位于模型顶端的商业服务就会破裂，采用固定数据结构的管理逻辑也会如此。

而且，客户数据种类必须在客户中心内部建立模型，而项目无法灵活地限制数据范围，就会变得很大，增加发生故障的风险。

因此，公司必须重新审视各种CDI方案的数据模型是否灵活，从而保证项目无论在短期内还是长期都取得成功。

在判断数据模型是否灵活时，下文列举了一些关键因素：

一、数据模型：易损坏还是易扩展?客户中心必须根据企业情况而定，实际上公司内部各部门的情况也不相同，因此关键问题不在于立即可用(out-of-the-box)的数据模型是否“丰富”。

实际上，正如餐馆预先制定菜单一样，如果外部属性并不适合扩展主数据中心，那么数据模型就不会太丰富。

最根本的问题在于：解决方案是否愿意数据模型得到修改?大多数CDI解决方案提供的固定数据模型由他们独特的应用程序发展而来。这些方案试图满足原始设计之外的真实需求，而数据模型却不能提供必需的实体和关系结构，或者需要大量价格不菲的定制服务。

同时，即使完成了定制，最终的数据模型效率也不会太高，因为在合成现有的应用程序逻辑和修改后的模型时，处理负荷很高。

理想情况下，自适应CDI方案(adaptive CDI solution)必须针对每家企业，提供最初的数据模型；或者引入经过验证的数据模型，通过进一步修改体现准确的商业实体，从而为客户中心建立模型。

另外，必须提供所有的支持数据管理服务，包括大量的元数据管理服务，从使模型更加容易扩展和更改。于是，相关的专业数据模型在一开始就能满足项目要求，而无需强迫公司将固定的数据模型标准化。

二、商业服务：定制还是合成?基于固定数据模型的CDI解决方案可能会提供抽象商业服务层，即整合数据。但是，这些商业服务很容易遭到破坏，如果潜在的数据模型经过修改，就需要定制服务。

因此，在实施过程中，如果固定的数据模型根据客户要求定制，不再完全标准化，可能就只有少数相关的商业服务得到保留。

更糟糕的是，虽然这些商业服务需要定制，但是定制程度越高，就越难迁移到将来的升级产品中。相反，自适应架构必须在服务整合框架中提供粒度级别的数据整合，如一组完整的API；而服务框架可能用于合成相关的高级商业服务。

这些商业服务和API可以实现相对缓和的产品升级路径。这种方法提供多种方式，可以根据中心内部(各种级别的抽象层)的规则，利用下游系统在服务架构中分享所有的数据实体。

三、数据种类：哪些需要建模?主参考数据、关系型数据、事务型数据等客户数据都拥有各自的特性，面临各自的挑战，因此在CDI方案中需要区别对待。

例如，存在于各个系统或数 据储存库的参考数据通常经过重复删除，可能会彼此冲突且无记录系统。

另一方面，事务型数据通常具有记录系统，因此协调过程几乎不存在冲突。同时，参考数据只是客户数据中很小的一部分，拥有很少的数据卷，而事务型数据卷很大，需要大量投资基础架构，才能存储从源系统复制而来的数据。参考数据的潜在冲突得到了解决，关系型数据就能得到有效管理。

另外，为了正确管理，关系型数据及其群组如成员数据(households)需要借助先进的虚拟化工具，显示实体间的复杂关系。

固定数据模型法采用应用程序级别的数据模型，主数据、关系型数据和事务型数据等各种客户数据在客户中心模型中完全加以封装。

这种方法需要对大量的客户属性进行重复删除，然后存储到客户中心。相反，自适应法必须对数据模型进行分段，只有核心主数据和关系型数据需要建模，并存储在客户中心。事务型数据必须根据潜在源系统的特性，存储在合适的站点。

例如，如果源系统为批量生产，没有实时接口，或者系统负荷有所限制，但是能定期抽取数据，那么事务型数据可能寄存在操作型数据储存库中，客户中心能够动态地加以访问。

另外，如果源系统拥有实时整合性能，并且不受服务器系统负荷的限制，事务型数据就可以动态获取，缓存在中心内部；此时延迟性较低、可用性较高，不必删除独立储存库中源系统的重复数据。这么做就非常灵活，大大减少需要存储在客户数据中心的数据卷；同时减少总拥有成本，而系统可以更加灵活地按需传输各种形式的数据。

四、数据模型：影响扩展能力。最后，数据模型的灵活性会对CDI解决方案的扩展能力和性能产生重大影响。

由于固定的数据模型方案通常是事先调整模型，以支持本地应用程序，因此公司可用哪些性能和扩展参数均受到供应商的限制――供应商必须支持自身的应用程序架构。

相反，如果采用灵活的数据模型方案，在模型配置成功后，就已完成了所有的调整和标准化过程，从而支持主数据中心项目和相关程序特定的扩展能力和性能，而不只是支持某家供应商的应用程序。

两种方法在扩展能力上的差异会对数据的整个生命周期造成重大影响，包括：构建、使用、管理和扩展主数据中心。

人们常误认为自适应解决方案有损性能，不过最近，CDI基准测试(CDI Benchmarking Results)驱散了这种谬论，测试结果表明自适应、可扩展架构的性能很高，扩展能力很强。

总之，灵活的数据模型是自适应CDI架构的重要组成部分。公司如果希望减轻CDI项目的实施风险，应该考虑上文列举的几大因素可能给数据模型带来哪些影响。在这方面决策错误，就会增加项目成本和管理难度，甚至影响整个CDI方案。

拙劣的数据控制

最近，很多大型企业开始着手于客户数据集成(CDI)管理计划，目的是获得其客户和他们在产品、经营场所和主营业务之间关系的一致见解。

过去几年中，随着对数据集成集线器需求的不断增加，很多CDI供应商现在也开始在新兴市场中争夺领导地位。

由于这些供应商提供了一系列具有丰富多彩功能和服务的打包的集成方案，所以很容易忽略CDI集线器最基本的需求――可靠的客户数据管理。在相互冲突、各不相同的数据源间创建一致的客户见解是所有CDI实施存在的理由。

因此，确保集线器中的数据可靠合并，其例外得到适当管理，数据策略得到有效实施。

简而言之，数据得到良好管理已经成为解决方案最关键的要求之一。然而，很多公司通常会在他们的供应商选择过程中对这些数据管理功能评估不足，往往导致他们在以后的实施阶段对自己的决定追悔莫及。

所以，让企业严密审查CDI解决方案的架构，以便确定它是否能够长期满足他们所有数据管理的需要，这一点至关重要。

因此，如果您着手一个解决方案，请考虑以下对数据管理功能至关重要的三个因素：数据可靠性，数据管理性和管理制度，并确保这些因素全部都是灵活的架构平台的一部分。

一、数据可靠性：内置式还是扩充式。主要关注于数据操作性用途的大多数应用程序核心的CDI解决方案通常低估了首先构建一个可靠、大容量的客户集线器挑战的严峻性，或者低估了跨多个主营业务管理不同的数据管理制度挑战的严峻性。

虽然外部工具可以轻松地集成到此类解决方案中来清除和匹配数据，但更棘手的问题是合并匹配的记录以便为每个客户创建“最优”主记录。

从本质上说，承诺可缩放，可操作的集线器但扩充了数据质量工具的CDI解决方案，随着时间的推移将导致数据管理成本不断增加。

为了为每个客户及其不同的附属机构“黄金”或主记录，系统必须跨所有数据源动态评估可靠性――基于用户定义的参数和内在的数据属性――并确保只有最可靠的内容才能在主记录的核心级别存在。

例如，如果呼叫中心在确认订单时开始收集电子邮件地址，则该数据属性可能比客户在网站提交的电子邮件地址更可靠。能够快速调整系统以便让呼叫中心电子邮件地址从网站电子邮件地址中脱颖而出的能力是任何CDI系统重要的架构组件。

而且，数据可靠性的这种核心级别的脱颖而出能力必须内置到核心产品架构中并且不应该随着客户集线器扩大到数百万的客户而被牺牲掉。最后，最终用户接受客户数据集线器的程度取决于如何维持高水平的数据可靠性，即使随着集线器数量不断增加或者新数据源被添加进来也是如此。

二、数据管理：即开即用还是自定义。没有数据管理业务就不能实施可操作的客户集线器吗?只要数据开始在支持的业务流程间流动，异常和错误也开始流动。

因此，充当数据集成平台的任何客户集线器必须提供业务能力，通过业务分析师和最终用户或者指定为数据管理者的任何人来监控和处理此类例外。

现今，很多CDI解决方案忽视了触发在数据流期间创建的关于例外的警告所需的实时可配置规则。对于复杂的数据管理任务(例如调查某些有问题的主记录的历史记录和沿袭)，管理此类例外通常需要完整的用户界面。这可能是确保用户接受和数据集线器可靠性维持高水平的唯一途径。

在其它情况下，企业可能会选择针对主集线器的编程界面构建特定的用户界面，以便适合它的需要。任何情况下，自适应的解决方案必须基于规则的可配置性、一流的数据管理控制台和编程界面，才能处理所有数据例外和可靠性需要。

三、数据管理制度：集中式，分散式还是两者皆有。大多数CDI解 决方案设计为创建单个仓，即用于服务多个应用程序的可操作集线器，而不是可以伸缩满足企业需求的仓。

虽然聚焦式部署可能是集中式数据管理的期望选项，但它通常不能满足整个企业对管理和兼容性的所有业务需求。

通常，某些数据属性(例如隐私首选项)需要集中式控制和例外处理，而其它属性则最好留给本地管理。

此外，安全性和对集线器中数据属性的访问权很大程度上会因每个组织内的单个角色和组织而改变。

事实上，要跨主营业务支持多种业务需求，不同的数据属性可能会需要多个数据管理制度，而这些属性都在一个企业内。

自适应的途径必须基于分散式的架构，以便可以部署多个集线器，进而可以集成不同的数据源和支持不同的进程，同时还可以基于任意数量的集散或对等的管理制度彼此间共享数据。

这就形成了一种主营业务，并提供了另一种灵活尺度来共享某些而不是全部数据。每一种都基于其自身数据的可靠性和管理策略。有了完全的基于规则的可配置性和数据管理界面，就可以支持多种数据管理制度。

四、数据管理要求：编码的还是可配置的。

随着业务变更步伐的不断加快，横跨企业维护数据质量的复杂性和可靠性也不断增加。在自定义内置式或基于固定模型的主数据集线器中，很难在业务逻辑或进程中实施更改，因为反映业务条件和要求的规则通常是自定义编码的或者被牢牢绑定到基本的固定数据模型中。

为能以一种智能并持续的方式自动实现用户数据的合并，同时在业务变更时维持最高水平的数据质量和可靠性，企业能为其数据清洁、匹配和合并进程有效管理重复的业务规则就变得非常关键。

因此，自适应的主数据解决方案必须捕获并管理这些不断变化的业务条件，而不用IT团队在每次需要更改时自定义编码这些规则。

此外，适应于数据合并、变更检测和重新写回的所有业务规则，必须可以轻松配置和快速更改，而不用额外的编程，从而反映特定的业务条件和相关的数据需要。

这就生成了一个解决方案，可以在正常的操作过程中在发生业务变更时进行管理，而不会威胁多个源系统间的数据完整性。

总之，数据必须是所有CDI项目的核心焦点，并且数据的可靠性、管理性和管理制度从不应是一个复杂的CDI解决方案的事后反省。企业必须严密审查在这个领域供应商提供内容的细节，以便减少项目失败给他们带来的风险和降低CDI实施的总成本。

(作者：安纳拉・韦德拉)