|
Microsoft 的战略客户关系管理
白皮书 摘要小企业所有者通常知道他们所有客户的名称，尤其是顶级客户的名称。例如，小企业所有者可以很容易查看单个客户名称、付款地址以及这些客户的购买情况。小企业所有者通常与客户保持着密切的联系，以便随时了解客户对其业务的满意程度，并努力培养与顶级客户的关系，以确保他们一直是自己的顶级客户。 相比之下，大型企业的所有者要想与客户保持这种灵活的接触就困难得多。这是因为，大型组织需要处理更多的复杂情况，它们不仅有更多的客户，而且有更多的雇员、产品、服务，最重要的是，还需要处理更多各种各样的文书工作和信息。这意味着，大型企业的所有者需要详细审阅更多的数据，才能确定有哪些最佳客户、哪些产品和服务客户更愿意同时购买，才能根据各个客户的购买习惯确定客户的总体需要。 仅在美国，Microsoft 就拥有超过一亿个客户，1“客户”是指从 Microsoft 分销商或零售商那里已经购买至少一个 Microsoft 产品的最终用户、注册为事件参加者的最终用户或订阅联机新闻快递的最终用户。Microsoft 的渠道关系要求公司通过各种独立的来源获得每个最终用户的名称和地址。Microsoft 依靠一组十分先进的工具和技术，也就是基于分布式数据仓库的高效 Microsoft® SQL Server™ 2000，来有效地管理与客户的关系。该系统每天能够加载 2 百万个以上的客户记录，但它只使用八台运行 Microsoft Windows® 2000 Datacenter Server 网络操作系统和 Microsoft SQL Server 2000 的计算机、两台运行 Microsoft Windows 2000 Advanced Server 网络操作系统的计算机、550 个硬盘驱动器、32 个磁盘控制器和大约 1 TB 与客户有关的数据。 同时，该数据仓库还包括 1 亿 5 千万条 SQL 事务记录，这些记录支持交叉表报表和图表化功能，便于管理者查看单个客户的综合情况并了解他们对 Microsoft 产品和 Microsoft 赞助的事件和新闻快递的兴趣。 对于 Microsoft 或其他任何大型组织来说，设计和部署分布式数据仓库环境以支持大型的全球客户关系管理 (CRM) 和决策支持系统 (DSS) 并不是件小事。没有一个符合实际的范例，要想计划、部署和扩展一个有效的系统将十分困难。本文档说明了 Microsoft 所面临的许多问题和挑战，以及它在扩展和部署其分布式数据仓库以支持 CRM 和 DSS 功能（这些功能以前需要有第三方的大型机环境的协助）时所采用的方法。 通过充分解释由 Microsoft 设计和支持小组完成的许多设计、开发和部署决策，本文档可以视作为 Microsoft 建立高度有效的分布式数据仓库所使用的方法范例。 业务要求Microsoft 信息技术小组 (ITG) 确定了三项业务要求，推动数据仓库的设计和部署支持 CRM 和 DSS 功能。这些业务要求是：提高客户满意度、规模经济以及更加标准化和集成化的环境。 客户满意度提高客户满意度的中心是 Microsoft 在 1999 年开始实施的全球 CRM 和 DSS 环境。这些环境是分布式数据仓库的中心部分，Microsoft 希望通过完整地使用这些环境，能够比以往更好地确定个人和组织正在使用哪些产品和服务。 该分布式数据仓库的一项关键功能是帮助 Microsoft 全面了解每个客户的情况。因此，Microsoft 正在设法统一各种来自内部和外部信息源的客户信息。在数据仓库中，客户和 Microsoft 之间的每个“接触”都将记录在中心储存库中。这意味着，当客户购买产品然后注册该产品时（无论使用平寄邮件或电子邮件，还是通过订阅新闻快递或参加某项事件），都会产生一些交互操作的记录，从而为 Microsoft 提供了该客户的个人化综合信息。随着时间的推移，我们相信更有效率的 CRM 解决方案将帮助决策者更好了解客户关系，开发出更好的产品和服务，由此提高长期的客户满意度和忠诚度。 规模经济Microsoft 是一家高度分散的企业，属下的 60 多个分支机构都有销售办事处。多年来，每个分支机构都投资建设独立的客户数据库解决方案，以满足其特定的需要。这些投资来源于每个分支机构的预算。例如，位于英国的分支机构每年为此花费了大约一百五十万美元。其他大型分支机构也需要做相同的投资，而少数几个较小的分支机构则不得不完全放弃对与客户相关的活动和事件有利的投资。这意味着，较小的分支机构通常无法用大分支机构的大手笔投资方式来培育与客户的关系。 分支机构还可能建立多个数据库以满足每个客户群的需求，或者建立不同的数据库以提供产品技术支持电话、产品注册、传出电话、营销等功能。每个独立的解决方案都需要对数据获取、数据处理、支持以及客户数据查询工具进行投资。由于单个投资通常只能使一个分支机构受益，所以传统的方法难于产生规模经济。 因此，Microsoft 设计和部署能够支持全球 CRM 和 DSS 的分布式数据仓库，其目的另一个方面是要努力利用规模经济，即仅用一个集中管理的解决方案来使所有分支机构的决策者都受益。 标准化标准也是 Microsoft 设计和部署使用集中管理的分布式数据仓库的全球统一 CRM 和 DSS 环境行动的中心。过去，在如何实现 CRM 方面，即使存在一些标准，各个分支机构所使用的不同实施方案却很少使用这些标准。例如，某些分支机构开发了自定义代码的应用程序来支持销售、市场和客户支持小组。而其他分支机构则使用第三方应用程序，或者外包整个客户关系职能部门。 为了解决这个问题，Microsoft 启动了一项内部计划，开发出标准化的和可伸缩的 CRM 和 DSS 实现方法，使所有分支机构的决策者都能够从中受益。该过程的第一步是统一位于美国的各个独立系统的信息，并设计和部署作为本文主题的分布式数据仓库。 概述由于 Microsoft 的客户数量庞大，仓库设计人员在规划解决方案时的首要决策之一是将客户信息分布在多个服务器上，其动机是获得强大功能。分布式设计允许多个服务器同时处理单独的任务（任务作为一个或多个 SQL 存储过程）。它还使扩展更容易，因为它支持识别那些可以划分成多个子任务的任务，而这些子任务又可以同时运行在多个服务器上。在编程级别上，这涉及到将 SQL 存储过程划分成两个或更多个新的存储过程，然后将这些存储过程加载在运行 SQL Server 2000 Enterprise Edition 的独立计算机上。 即使数据仓库已经作为分布式系统实施，每个服务器仍然能够与其他使用 Microsoft Cluster Service（包括在 Windows 2000 Datacenter Server 中）和存储区网络的服务器共享部分数据。每个群集服务器都执行专门的数据处理，然后通过把数据库放在某个群集磁盘资源中，来共享该处理的结果。随后，当另一个服务器请求共享的磁盘资源并重新加载共享的数据库时，系统将用更专门化的数据处理来继续执行后续的处理过程。 最后，决策者就能通过基于 Web 的活动管理及 DSS 工具来查看数据。使用这些工具，决策者就能根据特定配置文件查看客户列表，并根据实际选择的任一配置文件来生成活动和事件。到 2001 年 3 月，该数据仓库包含了大约 1 亿个 Microsoft 美国客户的信息，并且计划未来包括其他国家或地区的客户信息。 不管美国客户的信息是从什么地方收集到的，这些信息都会安全存储在位于华盛顿州 Redmond 的 Microsoft 总部的服务器中。这些系统每天 24 小时每周 7 天受到严格的安全措施保护。 数据仓库基于如下 Microsoft 产品：
数据仓库中的数据来自各种内部和外部渠道，包括 microsoft.com Web 站点和 Dun&Bradstreet。利用每天能够添加 2 百万条记录的容量，该数据仓库几乎始终都在加载那些注册新产品、订阅新闻快递或参与公司事件的新老客户的信息。 因为数据仓库采用集中管理方式，所以它只需要相对少的维护资源。数据仓库的设计、部署以及目前的维护只需要 23 个人参加，在运行大约一年之后，它已经证明具有几个明显的优点。例如，数据仓库正在帮助提供更全面的美国客户的情况；以前，为了实施新功能和报表功能，以及为了制定培养与公司顶级客户的关系计划，需要做大量的外包安排工作，而现在这方面所花的时间正在减少。图 1 概述了 Microsoft 内部所使用的分布式设计，以及服务器及其功能。 内部数据仓库的使用者由两组主要决策者组成：确定市场趋势者和数据挖掘者。第一组观察各个市场段，并使用相当基本的报表进行交叉表报告和历史分析，例如，参加事件或订阅新闻快递之后购买了产品的人数。第二组则挖掘横向销售和纵向销售的机会，以便规划未来的活动和事件。 设计由于分布式数据仓库的逻辑及物理结构对其分布式性质和可伸缩性起关键作用，因此下面将详细介绍 Microsoft 如何把数据仓库划分成逻辑层和物理层，并设计通过数据仓库的数据流。在这方面所做的工作是为了从各个分散的渠道获得客户名称和地址，这与利用现有客户的识别号相反。（要详细了解实施逻辑结构时所面临的问题，请参见“实施”一节。） 逻辑结构在分布式数据仓库的逻辑结构设计过程中，工程师考虑了为符合业务要求而必须在系统中执行的主要事件，以及这些事件的执行顺序。 事件工程师将六个数据仓库事件定义为主要事件：数据映射、标准化和匹配、操作数据存储、决策支持、活动管理和数据抑制。 数据映射。客户信息来自许多数据源，包括产品注册卡、事件注册卡、电子调查和订阅电子新闻快递。每个数据源既可以获得所有数据源共有的信息（例如“客户名称”），也可以获得给定数据源唯有的信息（例如“订阅起始日期”）。数据映射将数据字段在表中的位置标准化，以便（例如）客户的名称不会因为疏忽而存储到客户的地址字段。数据映射还对各种数据源提供的数据字段进行安排，以便每个输入文件都使用相同的数据字段格式。 标准化和匹配。与任何数据仓库一样，Microsoft CRM 和 DSS 数据仓库包括一些规定，以避免出现不必要的重复和冗余。例如，当客户更改地址、电话号码或职业信息时，数据仓库必须反映这些更改，而不能因疏忽去更新错误的记录（例如，更改另一个同名客户的记录），或者创建重复记录（例如，用原地址列出了一个客户，然后再用新地址列出该客户）。通过对每个更新记录以及所有新的客户记录使用标准化和匹配方法，数据仓库将确保建立一个完备和准确的单个客户信息记录。 操作数据存储。为了在准备永久存储时使数据均质化，数据仓库使用了基于星形构架格式的操作数据存储库 (ODS) 来获得灵活和永久的存储环境。从该环境中，DSS 和活动管理的“工厂处理”获得它们的数据。 工厂处理。在分布式数据仓库中，工厂处理涉及对 ODS 中的数据进行转换，以便适合进行报告、分析和活动管理等的活动。工厂处理的方法是，从 ODS 取得数据，并通过应用业务规则进行提炼，对其进行非规范化、聚合和分区处理，从而确保它有适合在数据集市中使用的格式。按照数据仓库的设计，在 ODS 和数据集市中，“单个客户”是最低一级的聚合。 决策支持。决策者必须能够统计正在注册产品、参与事件、加入新闻快递等的单个客户的数目。他们还必须能够观察给定市场段以确定纵向销售和横向销售的机会。出于这些原因，Microsoft CRM 和 DSS 数据仓库包括了灵活的 DSS 环境。 活动管理。决策者还必须能够邀请选中的客户参加公司赞助的事件，并使用批量电子邮件、平寄邮件或客户电话联系他们。出于该原因，数据仓库包括活动管理功能。 数据抑制。虽然 Microsoft 能够定期地以任何最实用的方式来联系数据仓库中的大多数客户是非常重要的，但某些客户却不喜欢与其联系，或者只愿意通过某些方式进行联系（例如，电子邮件而不是电话，或者平寄邮件而不是传真）。通过数据抑制，Microsoft CRM 和 DSS 数据仓库可以在判断要联系哪些客户以及何时以何种方式联系他们时考虑这些客户的要求。数据抑制是 Microsoft 在数据仓库中实施安全和隐私首选项的一个组件。该仓库不仅可以指示单个客户的首选联系和非联系信息，而且还能限制对敏感数据的访问，以便分析人员可以查看计算结果，而不用实际查看名称和地址。 事件顺序定义数据仓库中的主要事件之后，设计工程师确定了这些事件发生的顺序。如图 2 所示，事件被按照数据负载、工厂处理和数据集市的生成进行分组。 下面是数据流的简短摘要：
利用该过程，通过应用业务逻辑和规则，使数据保持在系统中的移动，其中间结果可以供需要该数据来进行额外处理的各种服务器使用。该方法允许数据仓库中的每个服务器有一个专门的角色，并确保所有服务器保持忙碌状态。 物理结构在 Microsoft CRM 和 DSS 数据仓库的物理结构的设计过程中，工程师考虑了逻辑结构、输入数据的数量、业务规则的复杂性以及高速计算机的可用性等因素。要最有效地利用硬件，并能够通过添加服务器进行扩展，工程师使用了分布式计算环境在建立逻辑结构之后对物理结构进行建模。 遵循在 90 年代初期流行起来的“适时”方法，该设计使组织（例如 Microsoft）能够仅在需要进一步处理时才应用财力资源。这种方法的另一个优点是，它使组织能够确实是在需要更多的计算能力时，才利用最先进和最强大的计算设备。图 3 说明 Microsoft 按照适时方法扩展数据仓库的方式。 物理结构还指定了需要多少服务器、每个服务器上需要运行什么产品以及如何处理联网和存储问题。对于 Microsoft CRM 和 DSS 数据仓库，该结构指定了八台在 Windows 2000 Datacenter Server 网络操作系统下运行 SQL Server 2000 Enterprise Edition 的服务器，和两台运行 Windows 2000 Advanced Server 网络操作系统用于中间层报表功能的服务器。系统要求 SQL Server 2000 Enterprise Edition 使用超过 3GB 的内存。图 4 说明了该部署情况，表 1 则详细说明了所使用的各种硬件配置。 表 1 Microsoft CRM 和 DSS 分布式数据仓库中所使用的硬件配置
目前，数据仓库使用了超过 550 个磁盘和 32 个磁盘控制器，组成总计 17.3 TB 未格式化的物理存储区。七台服务器正在使用 Microsoft Cluster Service（包括在 Windows 2000 Datacenter Server 中）和存储区网络 (SAN) 来共享接近 1 TB 的基于 SQL Server 2000 的数据，并使其可供其他运行 SQL Server 2000 的服务器全局使用。图 5 说明了 SAN 的逻辑体系结构，它使用逻辑单位数字 (LUN) 掩码功能。使用 Microsoft Cluster Service 来管理共享的逻辑驱动器。
图 5 逻辑 SAN 结构 数据流为了与其他服务器共享专门化处理的中间结果，数据仓库利用了 Microsoft Cluster Service、SAN 和 SQL Server 2000 备份。SQL Server 2000 备份用来把数据库放在群集化的驱动器资源上，然后使用 Microsoft Cluster Service 根据对驱动器资源的请求并应用“故障转移”将该驱动器资源转移到另一台服务器。这时，其他服务器可以通过执行更专门化的 SQL 代码，立即重新加载数据库并继续执行其他专门处理。 分布式数据仓库中的服务器通过线缆连接到光纤通道控制的磁盘卷。它们还通过线缆连接到异步传输模式 (ATM) 网络。最初，生产支持人员通过在网络上复制数据实现在服务器之间共享数据。当仓库只包含几百万条客户记录时，该方法很有效，但是对于更大的数据集合，则不能很好地扩展使用该方法，因为复制操作需要花费数天的时间才能完成。现在，使用 SAN、SQL Server 2000 备份和 Microsoft Cluster Service 故障转移，等量数据的加载操作可以在数分钟内完成。 注意，尽管通常部署 Microsoft Cluster Service 是为了提高容错性和可用性，但在分布式数据仓库中这不是它的使用目的。实际上，使用它只是为了在群集节点之间共享基于 SQL 的数据。数据将连续加载到 ODS 中。每周，操作小组都要停止加载过程，并使用 SQL Server 备份工具将 ODS 备份到 SAN。一旦备份完成，小组将使用 Microsoft Cluster Administrator 应用故障转移，从包含备份的驱动器转移到决策支持工厂服务器，并在这里立即重新加载数据。 决策支持工厂使用 SQL 通过应用业务规则和数据转换继续处理该数据。该过程运行大约需要超过四天的时间。然后，工厂服务器将在启动 SQL Server 备份，把 ODS 派生的数据库备份到共享驱动器资源时，然后开始运行它当前的工厂处理。 备份完成后，将使用 Microsoft Cluster Service 应用故障转移，从共享驱动器资源转移到活动管理工厂服务器。一旦发生该操作，活动管理工厂服务器将使用 SQL Server 2000 还原数据库并开始处理数据，以支持活动管理。该处理过程将与决策支持工厂所执行的处理过程同时进行。 活动管理工厂运行 SQL 存储过程大约需要 12 天的时间，同时对 ODS 派生的数据库应用业务规则和数据转换。 决策支持工厂执行完 SQL 代码之后，该工厂将使用 SQL Server 备份工具和共享驱动器资源，将它的数据库传输到两个不同的决策支持服务器。然后，每个决策支持服务器将还原包含在共享驱动器资源中的数据库，这将使数据集市可用于活动管理和报告目的。图 6 说明了该数据流。 集成分布式数据仓库集成了 30 多种不同的、来自公司内部和外部的数据馈送。这些数据馈送代表了美国客户与 Microsoft 建立联系的许多种不同方法，包括产品注册、新闻快递订阅、事件注册和更改地址。数据仓库将来自每个数据源的信息与单个客户和帐户以及单个名称和地址一一对应。 数据仓库还与内部业务系统（例如 MS Sales 和 World Wide Events 系统）进行集成。MS Sales 是包含分销商、零售商和客户销售相关信息的数据仓库。通过从 MS Sales 获得数据，分布式数据仓库可以提供有关公司赞助的活动如何影响购买决策的相关信息。集成 MSSales 目的是为了帮助决策者确定参加事件和订阅新闻快递是如何影响客户做出第二次或第三次购买决定的。通过从 World Wide Events 系统获取数据馈送，数据仓库得以维护有关客户注册到公司赞助事件的最新信息。 实施实施数据仓库涉及到设计逻辑和物理结构、部署 SAN、安装 SQL Server 2000 和 Windows 2000 Datacenter Server，以及配置 Microsoft Cluster Service 和第三方提供的软件。目前，设计人员正在分阶段实施分布式数据仓库。他们在 1999 年 11 月和 2000 年 8 月分别完成了第 1 阶段和第 2 阶段的工作。编写本文时正在实施第 3 阶段。 第 1 阶段包括部署仓库的物理和逻辑基础结构，并开发决策支持的用户界面。在该阶段，设计小组将数据源限制为仅三或四个，以便限制数据仓库需要处理的数据量。 也是在第 1 阶段中，决策者开始看到数据仓库可能获得的信息种类，并开始在进入下一个实现阶段之前提供反馈。现在，大约 30 个分支机构是在第 1 阶段中所实现的功能的定期用户。 在第 2 阶段中，通过从大约 30 多个数据源添加数据，工程师显著扩展了数据仓库的规模。他们还实现了更健壮的数据处理和验证环境、Trillium 匹配环境和支持管理活动的数据工厂。 编写本文时，CRM 数据集市中的数据被限制为居住在美国的客户。DSS 数据集市包含美国客户的数据以及部分全球数据。工程师使用美国客户作为数据仓库的初始数据集合，因为它是所有 Microsoft 客户数据集合中最大的。同样，小组考虑到在开始合并其他地区的数据集合（这是现在正在进行的第 3 阶段的一部分）之前，它是进行压力测试的有效基础。 实施数据仓库还涉及到用 SQL 编写自定义的业务规则和算法，这是其中一个需要持续和专门的工作以使分布式仓库获得成功的实施领域。因此，本讨论将帮助读者了解有关实施领域，它们需要数据仓库设计小组使用 SQL 但不包括实际源代码。（注意，该讨论假设读者已经熟悉数据仓库术语、基本编程概念和关系数据库的构建。) 数据加载在将粒度数据转变为适合于公司业务决策的信息的过程中，首先是将数据加载到操作数据存储 (ODS) 中。ODS 是基于 SQL Server 2000 的维度模型，它不是实体关系数据库 (ERD)，并且采用星形构架格式。ODS 的作用是使输入文件均质化，以便以后生成报表。 数据将按照客户邮政代码，从超过 30 个不同的数据源加载到 ODS 中。它们包括产品注册卡、事件注册卡、客户调查、电子产品注册和由 Dun&Bradstreet 提供的某些其他数据（例如，当前邮件地址和任何合法名称更改的数据）。加载之后，每个数据源的数据将被映射到常用输入字段，然后经过验证、与仓库中现有记录进行匹配，然后使用编辑优先级进行存储。 最多可以并发运行 18 个 SQL 加载作业。必须并发运行作业，才能支持每天加载到 ODS 的记录数。 数据验证数据验证的第一步是确认每个输入文件均包含适当的列数，并且每个列均正确地位于文件中。"Do Not Load" 标记用于标识那些应当从加载过程中排除的列。 所有被拒绝的记录均设置为能够手动审阅。在将每条记录加载到仓库中之前，要对每个电子邮件别名进行语法验证。 包含在每个地址中的州和省的代码则通过与存储的地理分类信息进行比较而得到验证。与该分类信息不符的值将会保留并作为自由文本加载。 自由文本字段将对照 "unacceptable values" 表进行比较。该过程用来检查由使用 Internet 的任何人所提供的自由文本数据。该过程还用来验证并确认自由文本是否适合于进行长期存储和生成报表。 标准化和匹配当现有客户注册第二个或第三个产品时，数据仓库将使用标准化和匹配来使客户与数据库中某个已有项关联。为了支持特殊情况，数据仓库设计人员在 ODS 中实施了他们自己的匹配编码算法。 ODS 按国家/地区识别记录，而这些记录通过使用第三方软件实现标准化。一旦可以使用第三方软件，则可以将它用于进行地址匹配。某些情况下，在 ODS 中使用的是匹配编码技术。 对名称，例如“Bill”和“William”，进行标准化处理，以便当 Bill 和 William 是同一个人时，该情况会反映在数据仓库中。GEO 编码用于将邮政代码与给定的城镇、街道关联。GEO 编码功能由第三方软件提供。 有时候，地址记录会发送给美国邮政管理局，以确定地址是否已经更改。如果更改，将使用新地址。 大多数数据源的数据首先将经过匹配数据并删除任何重复的处理。下一步，数据被传递给第三方软件，对名称和地址进行标准化处理，以便在邮政代码丢失的情况下提供名称和地址。在客户名称与仓库中现有记录关联后，包含重复客户名称和地址的记录将加载到仓库中。数据通过标准化和匹配处理之后，将使用编辑优先级存储在 ODS 中。 标准化和匹配为 Microsoft CRM 和 DSS 数据仓库提供了许多重要的优点：
编辑优先级编辑优先级是使用 SQL 开发的，用来按统计方式在字段级别对数据源进行分级，这对长期提高仓库中数据的准确性非常重要。每个数据源中的每个字段都会收到一个级别，指明包含在该字段中的数据的统计准确性。某些数据源提供非常准确的数据，而其他数据源提供的数据则不太准确。每个数据源都会提供一些唯一的信息，以及一些许多数据源共有的信息。系统将需要所有可用数据源的所有可用字段来建立反映每个客户的综合情况。 要判断哪些数据源中的哪些字段将提供能够反映每个客户的最准确情况的数据，编辑优先级解决了这一问题。例如，当每个字段中的数据保存到数据库时，将使用该字段记录数据源。通过记录为每个字段提供数据的数据源，编辑优先级将确定什么时候将不太准确的数据源提供的数据替换为更准确的数据源所提供的数据。如果需要，该方法还支持替换给定数据源所提供的所有数据。 数据仓库设计人员使用编辑优先级来生成帮助他们捕捉数据项错误（这在所有数据源中都是常见的）的统计结果，以便确定哪些数据源和字段更准确或不太准确。例如，一个数据源可能提供了过时的地址，而另一个数据源则可能无法反映最近的名称更改。因此，利用编辑优先级，仓库设计人员就可以确定最好使用第二个数据源的地址字段和第一个数据源的名称更改字段。 表 2 提供了如何使用编辑优先级的示例。字段 1、2、3、4 和 5 分别由数据源 1、3、2、3 和 1 提供。在该示例中，需要有三个数据源来提供数据的五个字段。字段 4 和 5 最初由包含低级别字段的数据源提供。利用编辑优先级，按照编辑优先级的定义，预期的结果是字段 4 和 5 中的数据将替换为包含更高级别字段的数据源的数据。 表 2 使用三个数据源的编辑优先级示例
编辑优先级为 Microsoft CRM 和 DSS 数据仓库带来了很多重要优点：
主要记录类型ODS 包含两个主要记录类型：基于个人的记录和基于组织的记录。基于个人的记录是指已经购买至少一个产品、参加至少一个事件或者订阅至少一个联机新闻快递的单个客户。基于个人的记录是由居住地址标识的，通常不包含组织名称。 基于个人的记录提供对多个电子邮件别名的支持，包括每个别名的数据源。家庭钥匙用于将单个客户都放在相同的物理位置。 基于组织的记录是指企业、公司、机构或部门。如果基于组织的记录按一定关系与基于个人的记录关联，则该记录将加载到仓库中。 电话号码与基于个人的记录关联，但不与基于组织的记录关联。数据供应商按周期提供新的电话和传真号码，以使它们及时得到更新。电话号码与现有的传真号码关联，以确保甚至在传真号码更改之后客户的首选项也会被保留下来。如果需要，可以设置一个标记，以将电话号码与公司的主办公室关联。抑制标记则包含每个客户的联系首选项。例如，可以设置一个标记来表示不要通过传真进行联系。 工厂处理“工厂处理”是 Microsoft 内部使用的一个术语，应用于在多个计算机之间分布 ODS、业务规则应用程序和数据集市。工厂处理是由数据仓库设计小组使用 SQL 开发的自定义过程，它是 Microsoft 内部仓库特有的分布式性质。 工厂处理用于定期地从 ODS 提取数据，以便在通过生成新的数据集市发布经过提炼的非规范数据之前，执行转换、聚合、派生和分区。使用数据集市，决策者可以深入研究和分析单个客户的事物、生成报表并支持活动管理的活动。图 7 说明从 ODS 到工厂处理的数据流。 工厂处理为 Microsoft CRM 和 DSS 数据仓库带来了许多重要优点：
数据集市数据集市是基于 SQL Server 2000 的数据库，经过优化可以有效地生成报表。工厂处理每周生成新的数据集市。数据集市提供了强大的决策支持和活动管理环境。 一旦数据集市已经生成，将使用内部开发的应用程序和第三方应用程序的组合，来获取数据并以图形方式将其显示在图形用户界面中。图形用户界面允许决策者清晰地查看数据并加以分析。例如，可以使用一个图形用户界面从四个数据集市获得数据，这将允许决策者“剥离”数据层，然后向所有的目标用户完全公开。这样做将使决策者能够更好地了解哪些产品、新闻快递和事件是不同目标用户的首选项。 仓库设计人员在数据集市中使用了四个透视系数，以使决策者更容易访问信息。这些透视系数是客户数据、产品注册、联机订阅和客户事件。 客户数据透视系数客户数据透视系数按照地理、配置文件、兴趣和帐户活动，为决策者提供了单个客户和组织的综合情况。该透视系数提供包含交叉活动分析在内的复杂查询，包括对个人和组织的配置文件的分析。透视系数将根据正在使用哪些虚拟透视系数，计算个人和组织的数量。 两个虚拟透视系数基于客户数据透视系数：个人和组织。这些虚拟透视系数类似于基本客户数据透视系数，但虚拟透视系数可以根据指定数目的个人和组织生成报表，而基本透视系数不能。 图 8 说明事实数据表的一小部分以及数据集市的客户数据透视系数中的一些相关维度。 产品注册透视系数产品注册透视系数将产品注册事务存储在基于时间的视图中。该透视系数的首要用途是确定单个客户长期的产品注册趋势。默认查询为财务月、分支机构、销售地点、产品名称和产品注册计数。 联机订阅透视系数联机订阅透视系数将联机订阅事务存储在基于时间的视图中。该透视系数的首要用途是确定单个客户长期的联机订阅趋势。对于与新闻快递相关的活动，透视系数包含所有订阅和取消订阅活动，包括单个个人的多个订阅或取消订阅操作。 客户事件透视系数客户事件透视系数将关于客户事件的活动信息存储在基于时间的视图中。该透视系数的首要用途是查看长期与特定事件联系的客户活动。该透视系数将计算个人邀请、注册、确认和事件参与的数量。 支持本文下一节将详细说明由数据仓库小组用来监视和维护系统的一些比较重要的支持工具。 这些工具可以主动帮助收集某些信息，这样，如果问题发生则可以使用该信息找到潜在的原因，当问题发生时它们还会收集其他信息。主要支持工具包括 Windows 2000 性能监视器、Windows 2000 事件查看器、基于 SQL Server 的电子邮件、Windows 2000 终端服务和 SQL 代码。 Windows 2000 性能监视器Windows 2000 性能监视器包含在 Windows 2000 Professional、Windows 2000 Advanced Server 和 Windows 2000 Datacenter Server 中，它用于找到由系统或软件组件所导致的性能瓶颈。性能监视器的输出结果以图形方式显示，并且支持同时查看多个系统组件和应用程序进程。性能监视器是操作小组用来确定进程或应用程序是否分配了太多内存或者使用了太多处理器时间的首要工具。 当需要调整系统性能时，由性能监视器提供的数据对于分析和操作小组具有相当高的价值。在 Microsoft，只有服务器管理员可以运行性能监视器，因为经验显示，当需要时该信息可以随时从一台计算机获得并在分析人员中间共享。经验还显示，通过限制用来同时查看性能数据的计算机的数量，可以略微提高性能。在 Microsoft，该数字很少超过五。 从使用性能监视器开始来启动性能分析有很多理由，其中主要的原因是重要的处理过程开始时需要使用比过去更多的时间来完成。某个小组做出启动性能分析的决定，并负责在几台专门用于该用途的计算机上收集性能数据。按照科学的方法所收集的数据有多有少，并且在运行怀疑过程时进行收集。管理员将添加所有性能计数器（除了用于网段的计数器），并将结果以日志的方式记录在磁盘上，保留时间为 48 到 72 个小时。然后，他们将日志文件传递给分析性能数据的分析支持人员。 性能监视器还用于利用内存、CPU 和磁盘计数器系统地覆盖性能计数器，目的是为了确定可能导致特定性能问题的进程。根据分析结果，通过添加更多硬件、调整 SQL 作业的时间设置或者将资源密集型进程移动到另一个服务器上，通常即可解决性能问题。 事件查看器通常，SQL Server 2000 和 Windows 2000 Datacenter Server 会将事件消息写入每个服务器上的应用程序日志和事件日志中，而事件查看器则基于这些事件消息显示相应的信息。每个事件消息都有相应的 ID，使用该 ID 可以确定很多常见问题的性质和严重程度，例如磁盘已满、硬件设备故障或者进程耗尽内存。通过事件查看器，数据库管理员 (DBA) 可以使用事件 ID 搜索 Microsoft Knowledge Base（http://search.support.microsoft.com/kb/c.asp?ln=en-us），以便更详细了解产生特定问题的可能原因。 基于 SQL Server 的电子邮件在 Microsoft CRM 和 DSS 数据仓库中，操作小组依靠基于 SQL Server 的电子邮件来跟踪 SQL Server 2000 活动情况。基于 SQL Server 的电子邮件被配置为定期地将通知发送给生产小组，使他们能够对系统内部情况有所了解。 问题需要立即处理时，基于 SQL Server 的电子邮件还可用来自动呼叫生产支持小组中的某个成员。从代码位置（该位置保证用电子邮件联络生产小组）用程序调用扩展 SQL 存储过程 XP_SendMail，数据仓库以此方式启动基于 SQL Server 的电子邮件。 Windows 2000 终端服务操作小组的成员使用 Windows 2000 终端服务（它是 Windows 2000 Datacenter Server 的一部分）来进行远程操作。利用终端服务，任何位置上的操作人员都可以像正在系统控制台一样，安装和配置 SQL Server 2000 以及排除有关故障。 SQLODS、工厂和数据集市服务器所使用的许多过程都是使用 SQL 开发的。在每个过程中，设计小组都使用了诊断代码，这些代码可以用来连续跟踪信息，帮助仓库操作人员确定仓库内部的当前情况。各种信息（例如，进程识别号和完成每个存储过程的所需时间）将连续写入基于 SQL 的表中，以便用于生成报表。可以随时查看包含在表中的信息，以便从 SQL 角度确定系统当前的运行情况。所记录的信息使得开发人员能够观察一段时间后的性能，并计划增加额外的容量。 最好的做法是，将 SQL 进程中所生成的消息记录到文件中，因为很多作业会需要很长的运行时间。这些作业将连续生成通知消息，经验显示，将这些消息记录到文件中可以有助于确保显示长度将不会被超过。 支持群集资源在类似分布式数据仓库的系统中，时间设置是数据流的关键因素，因此了解如何支持群集资源是非常重要的。在仓库中，七台服务器群集在一起以便共享磁盘资源。这七台服务器中的每一台均有自己的本地存储器，还有由 Microsoft Cluster Service 和 SAN 创建的全局存储器。如果服务器需要从全局存储器读取数据，则服务器将请求包含数据的群集磁盘资源。如果服务器需要将数据写入全局存储器，则服务器请求要将数据写入其中的群集磁盘资源。 数据仓库设计人员实施数据仓库以便来自 SQL Server 2000 的共享磁盘资源请求可以使用 SQL。当服务器执行 SQL 代码时，代码中有一行指令 Microsoft Cluster Service 为该服务器分配磁盘资源的语句，但该语句将在最后执行。 这种实施方法并不是由数据仓库设计人员首先提出来的。一开始，他们尝试通过调用多个服务器上的 cluster.exe 来分配磁盘资源。但该方法效果不好，因为它意味着要将共享的驱动器资源从服务器中取走，而同时 SQL Server 正在从中读取数据或向它们写入数据。因此，生产支持小组介入工作后，通过使用 SQL 语句开发出共享的驱动器接口，从而解决了该问题。驱动器接口被用作锁定机制，以便共享的磁盘资源不会脱离正在使用它们的服务器。需要共享驱动器资源的服务器将调用该驱动器接口代码，然后转入 SQL 等待循环，直到故障转移应用到该驱动器。 通过将该信息记录在表中，驱动器接口代码将跟踪共享的磁盘资源。驱动器接口代码是调用 cluster.exe 的唯一位置。使用仓库中共享磁盘资源的所有服务器都通过该公共接口执行调用。 安全系统实施了严格的安全措施来确保 CRM 和 DSS 数据仓库中客户数据的机密性。安全措施包括（但不限于）保护数据仓库的物理硬件以及计算、网络和软件组件。为了保护客户数据的机密性而设置的工作程序也得到严格执行。 对物理硬件的访问受服务器的放置场地限制，并且受获得合适密钥卡和培训的可信任人员的人数限制。设备每天 24 小时每周 7 天均受到录像监视。限制网络访问的方法是，将网络与 Internet 隔离并且用户在登录到网络前需要 Active Directory™ 服务身份验证。仓库中的每个服务器均使它的文件系统受到访问控制列表 (ACL) 的控制，以确保先要由 Active Directory 做进一步身份验证，然后才能访问文件系统。 SQL Server 2000 Enterprise Edition 保护每个数据库中的客户数据的方法是，要求内部 CRM 仓库用户获得特殊的帐户，并且使用 Active Directory 对这些帐户进行身份验证。 按照 CRM 仓库的设计，决策者通过数据集市来访问客户数据。根据每个决策者的工作范围限制他们对数据集市中敏感数据的访问。例如，不需要进行管理活动的决策者只有一定的访问权限，这样他们只能执行分析而不能实际获取包含客户名称和地址的列表。 建立小组为规划和实施 Microsoft CRM 和 DSS 分布式数据仓库，公司根据个人在六个独立领域所掌握的知识和技能，建立一个关系平等的工作小组，这六个领域是：存储工程、生产管理、程序管理、设计、测试和生产支持。图 9 说明了参加设计、实施和部署分布式 CRM 和 DSS 仓库的小组。
图 9 负责部署数据仓库的小组 存储工程要求。该项目需要能够设计和实施大型 SAN 的存储工程专家。他们要求能够部署后端设备，使设计人员能够将数据仓库扩展到极大比例。存储工程师还要能够为其他小组成员提供有关建议，帮助他们有效地支持使用 Microsoft Cluster Service 的环境。 人员。两个存储工程师加入小组，并带来他们在逻辑单元数 (LUN) 隐蔽方法、存储区联网、硬件基准设定和 Windows 2000 Datacenter Server 方面的专业知识。 生产管理要求。项目需要完全了解业务要求并帮助确保仓库以后达到公司目标的人员。这些人员需要能够面对公司决策者，并获得他们认为非常重要的信息要求。 在寻找能够担任产品经理的人选时，公司领导寻找有能力详细说明复杂的业务过程流、确定数据源和技术结构、并制作和完成相关技术说明的人员。产品经理还应当拥有 Microsoft 产品经验，包括 SQL Server 2000、Windows 2000 Advanced Server 和 Microsoft Office。 人员。符合上述要求的几个人选作为产品经理加入小组，帮助推动重大计划的实施。通过确定产品的特性和功能以及收集和分析业务要求和产品战略，使注重结果的技术专业人员得到启发。他们还负责委派工作任务、主动将要求融入到产品规划过程中、收集用户反馈并推动仓库设计的工作。 程序管理要求。项目需要的人员能够根据复杂的仓库设计及部署的要求，按照正常进度表和包含数百个不同步骤的项目计划来执行工作。这些人员需要随时跟踪所有项目相互依赖关系，并把业务要求诠释为功能规范、过程流和数据模型。 在寻找能够担任程序经理的人选时，项目领导寻找在信息技术方面具有五年管理经验、提供技术支持并能够同时执行协助和管理任务方面的人员。他们还要寻找具有客户端/服务器计算知识、优秀的书面及口头表达能力并且熟悉 Microsoft 产品（包括 SQL Server 和 Windows 2000 Datacenter Server）的人员。 人员。符合条件的几个人作为程序经理加入到小组中，他们帮助确定了开发时间期限、分析业务要求、制定帐户管理策略并管理跨部门的小组，以实现共同目标。这些人员通过与内部小组合作设计、开发和实施数据仓库，帮助推动项目进行。在管理小组成员之间的关系并建立强大的团队组织的同时，他们通过交流业务问题、可选方法和项目策略，为不同的工作小组提供意见。 设计要求。在寻找负责处理数据仓库的设计的人选时，项目领导需要关系型星形构架、加速表和聚合方面的专家，并且候选人能够使用 SQL 实施高度有效的代码。 人员。仓库设计人员是小组中目前最了解技术的人员。他们遵循规范设计出维护方便的代码，同时擅长在时间压力下开发出中度到高度风险的业务解决方案。他们负责按照项目目标和要求成功完成项目，并且能够向其他小组成员解释设计要求、功能集和功能。 这些人员拥有很强的书面和口头交流技能、出色的技术能力、对软件开发过程的深入了解、以及与程序经理、测试人员和生产支持人员密切合作的能力。此外，他们曾经广泛使用过 Microsoft SQL Server，有关系型和逻辑型数据库设计、SQL 编码和性能调整的经验，并且懂得 COM+/DNA、OLE、XML/XSL、MTS、Visual Basic® Scripting Edition (VBScript)、JScript® 开发软件、Visual Basic、DHTML、ASP、ADO 以及 Internet Information Service（Windows 2000 Server 中的 Web 服务器）。 测试要求。要确保所有功能都不会造成数据仓库不稳定，项目领导需要有足够的测试人员，在开发每个新组件的同时对其进行测试。测试人员需要精通数据仓库的各个方面，并保证项目“零缺陷”。他们需要以非常严格的方式分析和复现可能影响仓库稳定性的任何问题，以便仓库设计小组能够快速解决这些问题。 人员。测试人员要与设计人员密切合作，以防止出现问题并使产品更能经受测试。通过分析规范并编写测试仓库、用户界面和数据库功能的自动脚本，他们定义和执行测试步骤。测试人员还拥有出色的测试技能、对软件开发和 SQL Server 的深入理解以及分析Active Server Pages 和 SQL 中代码更改的能力。 生产支持要求。项目需要负责为正在进行中的日常生产提供支持的人员，确保简单的问题在可能对数据仓库总体产生负面影响之前得到及时解决。其他需要的重要技能是能够排除故障、能够根据有限信息快速解决问题、以及能够开发专门用于数据仓库支持的监控技术。 人员。对数据仓库提供生产支持的人员广泛熟悉 Microsoft 产品，包括 Windows 2000 Datacenter Server、Windows 2000 Advanced Server 及其 Web 服务器 (Internet Information Service) 和 SQL Server 2000。他们一般能够用 VBScript、JScript 和/或 Windows NT® Batch 开发命令行脚本。他们还了解 SQL 优化和编码技术；熟悉 C++、网络基础和系统调整及时间设置；并且是故障排除专家。 生产支持人员还要与网络工程师、存储工程师、开发人员、测试人员、程序经理以及包括数据库管理员在内的操作小组密切合作。他们拥有管理和解决问题的技能，并且具有迅速掌握新技术的能力。 经验教训在确定 Microsoft CRM 和 DSS 数据仓库获得成功之前，负责设计、部署和支持该仓库的小组遇到了许多问题和挑战。下面是一些主要的经验教训： 实际需要归档的记录很少。一开始，设计人员相信数据归档会是仓库设计的一个重要方面。随后他们发现，实际上只有少量的记录需要归档，并且处理这些记录的最好方法是利用数据抑制。 最好使用 Unicode。设计人员现在相信，他们应当在原始设计中更好地使用 Unicode。他们相信，假如在整个设计中广泛实施了 Unicode 支持，现在他们可能发现支持多个代码页会更容易。 在计算机之间复制数据库缺少伸缩性。一开始，生产支持小组在计算机之间复制 SQL Server 数据库，以便几个运行 SQL Server 的计算机会共享某些数据。但随后他们发现，在网上复制数据库占用太长的时间，而使用 SAN是在计算机之间共享数据的更好方法。使用 SAN，数据将以最高每秒 100 MB 的速度通过光纤通道和硬件主干道直接写入磁盘。使用 SAN 在服务器之间移动数据，可以将在服务器之间传输数据需要的时间从三天多减少到仅几个小时。 时间设置对于保持数据移动很重要。在实施初期，生产支持小组担心，当试图使用共享磁盘资源来共享数据时，群集磁盘争用可能导致问题。为了消除这一顾虑，小组成员开发了一个 SQL 进程，它通过提供这些资源公共接口来跟踪和管理共享磁盘资源的分配情况。在该进程的帮助下，要求访问共享磁盘资源的服务器只要调用该公共接口即可获得该资源。要求访问共享卷的服务器将把请求提交给自定义的应用程序，然后转入 SQL 等待循环，直到故障转移应用到驱动器。公共接口可以防止仓库中的服务器从另一台正在将数据写入驱动器的服务器那里移走共享驱动器阵列。 存储工程是一项必要工作。很多年以前，ITG 并没有自己的专业存储工程师小组。现在，存储工程师必不可少，并定期部署基于 SAN 的解决方案，以便跟上公司不断增长的信息要求。 结论小型、中型和大型公司的决策者都同样地要依赖于某种形式的准确和及时的信息，这些信息的形式能够使他们保持或重新获得处理业务的敏捷性。他们必须快速拥有所需信息，才能顺利调整他们的业务过程，以响应不断变化的市场条件，才能了解客户要求，管理并培育有价值的客户关系。 Microsoft 已经设计和部署了分布式数据仓库，目的是要获得对客户更全面的了解，并以此提高客户的满意度和忠诚度。通过在本文中介绍 Microsoft CRM 和 DSS 数据仓库的项目，ITG 希望它的有类似目的的客户能够获得一个参考范例。 |
