采取灵活且有效的方法来计划、设计并实现基于 IBM DB2 Data Warehouse Edition 的基本数据仓库解决方案。本系列文章的第 1 部分将关注客户互动过程以及计划数据仓库项目。
简介
商业智能(Business Intelligence)已经进化为包括越来越多的数据分析技术。无论采用哪种数据分析方法，数据仓库都仍然是利用信息资产的重要基础。本系列文章将帮助您使用 IBM DB2 Data Warehouse Edition(DB2 DWE)交付某种数据仓库基础设施，该基础设施对于随需应变的商业智能至关重要。本文将关注数据仓库计划，其中包括客户互动过程、业务发现、项目建议以及项目计划。目标读者
本文是为需要知道如何交付数据仓库解决方案的 IT 专业人士撰写的。本文假定您已经熟悉系统和数据库的概念。有许多主题未在本文中进行介绍，但它们同样是交付良好数据仓库解决方案的基础，包括系统和数据库设计、管理、性能调优等。本文仅仅关注与数据仓库密切相关的问题。商业智能是什么?
商业智能(Business Intelligence，BI)是对于大量数据的收集和分析，以便洞悉如何驱动战略性和策略性商业决策。BI 是用于将数据转换成信息的过程和技术的集合。它包含了种类繁多的技术，包括数据仓库、多维分析或在线分析处理(OLAP)、数据挖掘和数据可视化，以及简单的查询和很多种用于制作报表的分析工具。这些技术允许业务用户收集、存储、访问和分析数据以提高做出业务决策的能力。图 1. 商业智能是什么?数据仓库是什么?
数据仓库(data warehouse)是一个集中式的存储库(repository)，包含了综合详细的数据和概要数据，用于从不易变的历史角度提供客户、供应商、业务过程和事务的完整视图。
另一方面，数据集市(data mart)包含数据仓库中所存储数据的一个子集，这些数据是特定商业社区、部门或用户群所感兴趣的(例如：市场促销、财政或帐户集合)。
数据集市是由其用户的功能范围而非数据集市数据库的大小定义的，意识到这一点十分重要。在结构良好的 BI 系统中，数据仓库充当多个数据集市的一个源。数据仓库是什么?
数据仓库(Data warehousing)是用于管理和交付用于进行决策的完整、及时、正确和可理解信息的过程和工具的设计和实现。它包括使企业可以创建、管理和维护数据仓库或数据集市的所有活动。数据仓库(Data warehousing)处理对于数据仓库(data warehouse)或数据集市的开发、实现和操作的管理。它包括元数据管理、数据采集、数据清理(data cleansing)、数据集成、存储器管理、数据分布、数据归档、操作报表制作、分析报表制作、安全性管理、备份和恢复计划等等。
下面的小节提供了对于数据仓库(除了报表制作和分析)的简介。将特别关注为分析准备数据 —— 该任务通常占大多数数据仓库项目计划的 80%。为何选择 IBM DB2 Data Warehouse Edition?
IBM DB2 DWE 是一个功能强大且完整的商业智能(Business Intelligence)基础设施产品，其中包括了 DB2、集成的 OLAP、高级数据挖掘、数据提取、转换和装入(Extraction、Transformation and Loading，ETL)、报表制作工具等。DB2 DWE 操纵并提高诸如 DB2 OLAP Server 和来自 IBM 合作伙伴的高级桌面 OLAP 工具的性能。
DB2 DWE 是最具成本效益的数据仓库工具之一。据 Market Magic Ltd 在 2004 年的研究报告所称(参阅 参考资料)，DB2 DWE 在 5 年多对于数据仓库实现的 Probable Cost of Ownership?(PCO)要低于 Oracle 和 NCR Teradata 的。
可预见的伸缩能力以及没有限制是商业智能(Business Intelligence)平台的关键标准。DB2 通过其独特的无共享(shared-nothing)架构的实现来满足该需求。可伸缩性同时适用于大型和小型数据库。
可伸缩性和价格都很重要，但是它们无法单独解决构建 BI 平台的挑战。DB2 DWE 通过同样交付关键的分析和挖掘技术完成了该蓝图。DB2 与用于 OLAP 应用程序的 DB2 Cube Views、在数据库中用于实时数据挖掘的 Intelligent Miner Scoring 以及在深嵌于 DB2 的诸如空间扩展器(spatial extender)和 XML 查询等新工具完全集成，从而确保无缝的集成和优化的性能。客户互动过程
数据仓库解决方案的客户互动过程与以某种方式进行的其他 IT 解决方案的相似。然而，数据仓库解决方案具有一些重要的不同，包括强大的面向业务的数据、进程的多层迭代以及更多终端用户的涉及。
下图展示了作为数据仓库解决方案提供者的您在一个成功的项目期间与客户要进行的主要交互。图 2. 数据仓库解决方案客户互动过程
解决方案启动(Solution start up)：在这个客户互动的初始步骤中，您与您的客户将决定启动数据仓库项目，并开始建立协议。因为这是所有类型项目的通用步骤，所以本文中不会详细讨论。
业务发现(Business discovery)：这是理解当前和期望业务数据分析需求之间差异的过程。它包括收集和记录业务需求，理解客户环境，以及完成差异分析。(关于细节，请参阅 下一节。)
解决方案建议(Solution proposal)：基于客户需求，您需要为数据仓库项目或解决方案提出建议。
解决方案计划(Solution planning)：本步中，您计划解决方案，并指定所需的数据仓库基础设施、人员和资源。
仓库概念建模(Warehouse conceptual modeling)：仓库高级设计包括仓库架构和实现选择以及用于捕获业务需求中所定义的所有业务主题领域的概念数据建模。
仓库阶段设计(Warehouse phase design)：仓库阶段设计包括逻辑和物理数据建模，用于在更加详细的层次上捕获业务需求，但是仅仅设计当前项目迭代中的主题领域。该步骤还包括 ETL 过程设计。
解决方案实现周期(Solution implementation cycle)：数据仓库实现包括目标存储库和数据集市数据库，以及 ETL 过程实现。
解决方案部署(Solution deployment)：将新的数据仓库解决方案移至生产环境中。
该数据仓库客户互动过程是基于自底向上(或阶段性)数据仓库实现方法的。在部署数据仓库解决方案之后，可以在新的逻辑和物理数据建模上为与当前业务需求相关的其他业务主题启动该项目，或者如果有新的业务需求，就重新启动业务发现阶段。业务发现
业务发现过程包括三个任务：收集和记录业务需求，理解客户的业务环境，以及执行差异分析。这三个任务可以重叠进行，您将总是同时执行这些任务中的几个。例如，理解业务需求的一部分就是调查客户的业务数据源，这些数据源涉及了三个业务发现任务。在开始进行业务发现过程之前，解决方案提供者理解每个任务的目标是很重要的。
进行差异分析的目的是理解客户的业务难题和需求，并评估需要用于弥补当前业务状态及其业务需求之间差异的资源。图 3. 业务发现过程
收集并记录业务需求
在执行该任务期间，您应该可以发现并理解客户的业务难题，识别并优先考虑业务需求，以及关注感兴趣的业务主题领域。在完美的世界中，在客户互动的开始，您可能拥有完整的数据仓库项目的书写业务需求集。而在现实商业世界中，特别是在中间市场的公司中，初始的业务需求通常是不完整的;最初的联系常常包含电话、e-mail 或非正式的谈话。在向项目投入过多时间和资源之前，遵循所有初始会议以完整地识别所有的业务需求是十分重要的。
收集完整的业务需求并非是一项普通的任务。它需要积极地与您的客户进行交流。最适合于该工作的是一位有经验的分析员，应具有较强的业务和人员技能以及关于数据仓库和数据建模的合理知识。确定终端用户的需求
在收集需求的过程中，您收集并记录终端用户的需求。您通常要研究终端用户是如何卷入业务过程和信息分析活动的。因为这些终端用户并非一定理解数据仓库的概念，所以您应该询问允许您得以理解特定业务问题的问题。在本阶段中，通常发现终端用户的需求是非正式记录的，且没有用详细的数据结构表示。在收集终端用户的需求时，您可以采访终端用户，研究现有的文档和报表，以及监控进行中的信息分析活动。具有业务过程工程和信息分析方面的经验可能十分有帮助。
终端用户需求可以分为 4 个类别：
业务对象是商业术语中信息分析目标的高级表示。一个给定的数据仓库项目可能具有一个或更多业务对象。例如，业务对象可以是：“数据仓库必须支持操作成本的分析，以及产品销售利润的分析。”
数据仓库项目中的联合业务对象集可以帮助确定项目范围。它们还可以帮助识别项目中所涉及的信息主题领域，以及识别终端用户所分析的业务过程(通常是高层次)的度量。
业务查询表示终端用户在其日常信息分析活动中询问并尽力解决的查询、假设和分析问题。就像业务对象一样，业务查询也是用商业术语表示的。您通常将期望精确规划它们。它们不是用 SQL 术语表示的。业务查询类别中频繁碰到的一些实例有：
存在检查查询，例如“给定产品是否已经卖给某位特定客户?”
品项(item)比较查询，例如“比较两位客户在过去的 6 个月中的购买价格”或“比较每个商店每周对于一个特定产品的销售品项数目”。
趋势分析查询，例如“给定产品集在过去 12 个月中的销售增长如何?”
用于分析比率、等级和集群的查询，例如“按照去年中的美元销售列出最佳客户。”
统计分析查询，例如“计算每个产品类别在每个销售区域中的平均品项销售。”
数据分析场景是增加您所捕获和分析的需求集实质的较好方式。例如，某些业务需求是通过分析现有报表查询工作流和解释当前业务数据分析结构而生成的。
现有的数据模型可能是可用的，并且可以用于进一步指定或支持终端用户需求。您可以通过重新构建和集成源数据模型来收集数据模型。
终端用户需求集涉及了许多领域，且许多因素都可以影响其结果。这些因素可能包括终端用户的业务知识，他们可以如何较好地表达自己，或他们接受采访多长时间。用户需求也是随时间变化的，某一天正确的内容到了第二天可能不再有效。您如何知道何时成功地识别了用户的需求呢?没有一个绝对的测试，但是如果您的需求解决了下列问题，那么您就可能获得了足够的信息开始进行数据建模：
谁是用户所感兴趣的?考虑个人、小组和组织。
哪些业务过程和功能是终端用户尽力分析的?
用户为何需要数据?
何时(哪个时间点)需要记录数据?
相关过程在何处(地理上，组织上)发生?
您如何可以度量业务过程和功能的性能或状态?确定功能需求
终端用户需求帮助您理解当前业务过程和业务难题，而功能需求则帮助您理解客户从数据仓库解决方案中所期望的服务比例。所查询的问题基于您的数据仓库知识、评估以及对于终端用户需求的理解。功能需求信息通常来源于关键业务合同、业务经理、IT 专业人士以及潜在的终端用户。功能需求帮助您设置总体项目比例和目标。查询下列问题：
您需要哪些新的信息分析功能来提高业务?给定您期望基于数据仓库所构建的报表的详细定义。
如果有一个现有的数据分析过程，您碰到了哪些问题?
新的数据仓库有多少潜在的用户，他们位于何处?
业务报表每隔多久就需要重新进行构建?
客户端中哪些人将参与项目，他们的责任是什么?
项目预算是什么(如果那些信息可用)?
项目完成的目标数据是什么?
如果有义务特定的聚合度量，那么那些度量的定义是什么?
数据仓库需要哪种类型的安全性配置?理解客户的环境
您一开始收集和记录业务需求时就要理解客户的环境。在整个项目过程中，这些任务都将持续进行。在项目的早期阶段理解客户环境是十分重要的，以便避免误解和不受欢迎的惊喜。许多业务和技术假设都将基于早期的客户环境调查结果。理解客户的业务环境
难以预测您需要哪些知识来用以完全理解客户业务环境，因为每个业务都是惟一的。然而，为了取得成功的客户互动，您必定需要知道几件事情。它们包括但不限于：
谁是项目决策人?
谁是项目的关键的联络人员?
需要解决哪些类型的业务问题?
谁是终端用户?终端用户可能不是决策人，但他们提供关于数据仓库可用性的宝贵信息。
您需要哪些特别的业务知识?
您的客户具有 IT 人员吗?如果是，您可以从他们中获得多少支持?理解信息基础设施环境
客户的网络环境可能简单，也可能复杂。您可能不需要理解关于其网络的一切事情，但是需要记录与数据仓库生产环境相关的事情，用于设计和配置数据仓库。下面是您应该知道的一些事情：
生产环境中使用哪种类型的网络连通性和协议?
网络流通的平均和最大吞吐量是多少?何时是冲突和峰值时间?
数据仓库需要支持多少终端用户?您的客户计划使用什么操作系统和报表制作应用程序?
终端用户位于何处(在 LAN 中，跨公共 Internet 或 WAN，在 VPN 中，或其中一些组合方式中)?理解数据环境
理解客户的数据环境是数据仓库项目中最重要的任务之一。它是下列工作的基础：
构造现实的项目建议和合同。
设计并实现数据采集。
设计数据仓库和数据集市。
设计数据验证和清理。
将该任务分配给有经验的数据仓库专业人士，他们理解业务分析、数据分析和建模。他们需要与客户的 IT 人员和终端用户进行合作。
为了识别将支持仓库数据模型和业务需求的数据源(业务内部和外部的)，您需要记录所有的数据源。描述其位置、系统、访问方法、源数据流通和更新频率、数据安全性和数据质量。
数据质量是识别数据源中的重要问题之一。不仅要确定业务数据是否可用，而且还要确定所有数据源的数据质量是否足够支持业务需求。如果存在数据质量问题，您和您的客户就都需要尽快知道。
数据问题可能在客户的操作数据源中存在多年。在很多情形下，问题是在源数据的早期分析中或稍后在数据转换过程的设计和实现中发现的。请确保通知您的客户，以便他们可以准备处理计划。
检查数据质量并非是一项普通工作;它同时需要数据建模和商业领域的知识。最可能的是，您将需要一些终端用户参与该任务。在某些情况下，您可能无法访问敏感的业务数据。如果是这样，您应尽力获得一些随机的业务数据样品，并允许客户修改一些数据值，且不影响数据质量。
您需要尽可能多地知道项目有关数据的情况。下面是您需要详细回答的问题(不仅是在高层次上)：
有多少数据源与项目相关，它们位于何处?
数据仓库是否直接访问数据源?支持何种类型的数据连接?
数据仓库是否需要客户企业网(intranet)外部的数据?如何可以访问哪些数据?
所有数据源中每天生成多少新数据?
数据仓库中数据更新的期望频率是多少?
是否有共享数据?如果有，哪一个是主数据源呢?
数据质量如何?如果可能，您应该检查所有可用的数据字段。
如果有丢失数据或脏(dirty)数据，您的客户是否可以在数据源中进行纠正呢?
客户是否可以保证将来已纠正数据字段的数据质量呢?如果不能，谁将负责进行数据清理?
如果无法在客户的数据源中纠正丢失的数据或脏数据，什么业务规则将用于纠正数据呢?差异分析
在收集业务需求并研究业务和数据环境之后，您就可以执行差异分析了。差异分析将检查您所具有的信息，并确定需要哪些资源和工作来满足客户要求。差异分析的目的是：
理解客户的业务难题。
理解客户问题的主题领域。
向客户给予他们将需要提供的资源或支持的评估，以及为了根据客户需求交付解决方案您这一方所需要的开发工作的评估。
帮助指定用于项目的技术和工具。
差异分析十分重要，因为它是您数据仓库项目建议和设计的基础。需求分析
取决于您用于多少时间和资源，您可以决定将需求分析放在业务级上进行。这意味着您将生成关于您理解客户业务难题、业务领域、报表定义和性能度量的完整报告。
使用需求分析技术，您可以构建初始的仓库数据模型，以表示您非正式所捕获的终端用户需求。需求分析产生信息分析员可以直接解释的模型的图表(schematic)表示。在需求分析的结果通过需求验证阶段之后，将成为数据仓库建模的主要输入。识别业务难题
当您具有完整的项目业务需求集时，与项目相关的业务难题将很容易识别。您或许必须回到客户那里，并询问更多问题，以便发现和优先考虑他们所有的业务难题。在数据仓库项目中，您通常通过部门、需要回答的业务问题以及业务问题的紧急性来划分业务难题。在识别业务难题的过程中，您可以发现潜在的新项目，以觉察到所有的新机会。识别业务主题领域
主题领域大致通过对业务感兴趣的主题进行划分。为了提取潜在的主题领域列表，您应该首先考虑客户的商业利益(例如：客户、利润、销售、组织或产品)。为了帮助确定主题领域，要考虑与商业利益相关的“何时、何处、谁、什么、为何以及如何”等问题。例如，对于“谁”问题的可能回答包括客户、雇员、经理、供应商、业务合作伙伴和竞争者。在识别所有候选主题领域列表之后，您可以更清晰地分解、重新排列、选择和重新定义它们，从而产生最能表示您客户组织的主题领域列表。确定主题领域的层次结构或其他分组以提供它们是什么以及如何相互关联的清晰定义。
一旦开发了主题领域列表，您就需要定义它们之间的业务关系。关系是确定维量数据仓库模型中可能使用的维数的良好起点，因为主题领域是关于您所感兴趣的业务的全貌。根据客户的业务难题优先考虑一些主题领域，并将项目建议基于这些优先权是十分重要的。识别差异
基于业务需求分析的结果以及您对于业务环境的理解，您将可以识别客户业务的当前内容与他们期望从数据仓库项目中所获得的东西之间的差异。数据差异
数据无疑是数据仓库项目中的主要元素。差异分析中要回答的第一个问题就是可用的业务数据是否支持业务需求。请特别关注下列领域：
是否有足够的数据满足项目的商业目标?如果没有，是否可以获取外部数据源来填补这一差异?
业务数据质量是否满足了业务需求?如果没有，是否可以进行足够的清理以满足所表述的需求?
虽然提供高质量数据是客户的责任，但这是向客户提供附加服务的一个机会。基础设施差异
评估客户网络、硬件、软件、现有的应用程序等等的可能性提高。请特别关注下列领域：
服务器系统和网络是否健壮得足以处理期望的仓库数据流?
如果多个网络和位置中有多个数据源，它们是什么类型的网络呢?本地网络之间可以交换多少数据呢?
如何可以访问数据源?如果您无法直接访问数据源，您将需要从客户获得什么层次的 IT 支持以获得数据?
您的客户是否需要为数据仓库增加新的服务器?如果是，服务器的规范是什么?
仓库中有哪些类型的数据管理和数据分析工具已经可用?这些工具提供什么类型的数据分析服务呢?资源差异
资源差异的确定包括评估人员、技能、领域知识、计划表和预算。请特别关注下列领域：
客户是否可以提供需要用以支持项目的技能和人员钟点类型?
客户项目预算是否足以涵盖整个业务需求集?如果不能，当前预算下要包含哪个主题领域是最重要的?项目建议
到此时您所做的所有工作都为项目建议奠定了基础。数据仓库项目建议至少要包括下列信息：
您对于客户业务需求的理解。
您对于客户业务难题的理解。
您对于客户信息基础设施和数据环境的理解。
解决方案的范围。
客户业务问题的主题领域。
作为解决方案的提供者，您所使用的业务和技术方法。
应用于该项目的业务和技术假设。
项目最终可交付性的定义。
如果客户具有一些理解数据建模的 IT 专业人士，在建议中包含初始数据集市模型就是一个好主意，用以演示您是如何捕获业务需求的。
完整的项目建议还是与您客户签订的最终项目合同的基础。最为关键的是在项目建议和合同中要包括所有必要的业务和技术假设，以便双方都能很好地理解从项目中期望什么。任何对于项目假设进行的修改都很可能会影响项目时间表和预算;使客户意识到这一点并明白表述将省去日后的大量麻烦。
建议应包括下列项目假设。业务假设
项目需要什么层次的客户业务知识支持?
项目需要什么层次的客户业务管理支持?
项目需要什么层次的 IT 专业人士支持?
本项目中涉及哪些主题领域，以及什么是期望的项目可交付性?技术假设
需要将哪些数据传送到数据仓库中?
每隔多久就需要更新数据仓库?
如果多个数据源中存在共享数据，哪一个是主数据源呢?
如果没有主数据源，共享数据有什么数据集成业务规则呢?
如果有丢失的或脏数据，您将如何进行呢?建议应包括用于数据修理的详细书写业务规则。您的客户应在其数据源中修正丢失的数据，但他们可能会寻求帮助。经验法则就是您不要修改客户的任何数据，而是优化数据。
数据仓库中所有数据聚合的业务定义是什么?您的客户需要提供该信息。请确保指定限期。技术简介
在项目建议中，您通常应该描述计划在解决方案中使用什么技术。如果存在项目建议陈述，请确保为客户计划一个简要的技术演示。如果客户可以看到项目最终他们将获得什么，就会极其有帮助。开发项目计划
在客户签订解决方案建议之后，下一步就是创建实在的项目计划，其中包含尽可能多的项目细节。该计划将清晰记录双方的所有期望，因此，客户知道从您期望什么以及您需要从他们期望什么。在开发项目中尽可能多地让客户参与是一个好主意，因为没有客户的理解和支持，计划就不真正是计划了。项目计划应包含下面所描述的元素。项目范围
数据仓库项目计划与典型的 IT 项目计划共享许多事情。然而，数据仓库项目也具有一些独有的特点：
数据仓库目标通常是用通用语句定义的。数据仓库开发需求不应太具体是很重要的。如果它们太具体，就可以能影响数据仓库的设计方式，可能排除看似无关但可能对于所执行的分析十分关键的因素。
定义项目范围的主要原因之一就是为了防止出现新需求时整个生命周期不断变化。在数据仓库(data warehousing)中，定义范围需要特别小心。您需要防止目标随着出现新需求而不断变化仍然是正确的。然而，有价值的数据仓库的两个关键就是其灵活性以及处理设计时未知的查询的能力。因此，在定义范围时，重要的是明白所交付的数据仓库很可能将比初始需求指定的宽广一些。
由于数据仓库项目的重复本质，项目范围可能仅仅包含最重要或紧急的主题领域。然而，请记住高级数据仓库设计应该包括所有的业务主题领域。
数据仓库的主要目的是进行数据分析 —— 不要将操作目标与数据仓库的信息目标混淆。基础设施计划
数据仓库基础设施计划描述了软件、硬件、数据网络以及其他支持数据仓库的元素。基础设施计划是基于差异分析和项目预算的。人员计划
一旦客户批准项目计划，就要集合为解决方案挑选的整个项目团队。技能和人员计划应包括下列细节：
描述了每个团队成员的必要技能、详细责任以及时间表的人员计划。关键的团队成员应该总是有一个备份。
异常的官方定义，例如项目范围或项目团队成员中的变化。
数据仓库团队应包括：
项目经理，负责管理和协调您和客户之间的解决方案互动。
领域专家，为数据仓库设计提供业务领域知识。
终端用户，负责测试和验证仓库的设计和实现。
数据仓库架构师，是数据发现和数据仓库设计中的关键人物。至少一位有经验的数据仓库架构师参与成功的数据仓库项目是十分重要的。该架构师通常来自于仓库解决方案提供者一方。
数据建模者，负责逻辑和物理仓库数据建模。
ETL 开发人员，负责 ETL 设计和开发。
这是一个角色列表;一个人在数据仓库项目中可以具有多重角色。例如，数据仓库架构师和数据建模者可以是同一个人，而领域专家和终端用户可以是同一组人员。设计、开发计划
根据可用的技能和经验，开发用于仓库解决方案设计、开发和测试的综合计划。所有技术成员都应该参加创建项目计划的这一部分，因为只有他们知道完成计划要花费什么。该计划应包括：
必要硬件、软件和文档的综合列表
客户将在不同阶段或项目时间范围内提供的可交付性的详细列表(例如组织图、数据、格式等等)
项目设计、开发和测试活动的综合时间表
您将在不同阶段或项目时间范围内提供的可交付性的详细列表(包括文档、培训材料以及解决方案本身)
带有备份计划的项目可依赖性、假设和风险的综合列表。项目检查点计划
您与客户应该在项目检查点计划上合作。一些客户真正使用该计划来一步步地同意项目。该计划应包括：
包含您和客户的主要检查点的综合时间表。
每个检查点的项目可交付性的综合列表。部署和用户接受度测试计划
在向客户生产环境部署所有或部分解决方案可交付性之前，您应该执行用户接受度测试(User Acceptance Test，UAT)。UAT 是一个极其正式的测试过程;它是客户对于您项目可交付性的正式批准。UAT 过程可能需要花费客户的终端用户的大量时间，因为在他们可以启动 UAT 之前，您可能首先需要对他们进行培训。该计划应包括：
项目及其部署时间表的最终可交付性。
针对解决方案培训终端用户的计划。
UAT 时间表。客户教育计划
客户教育是数据仓库项目每个阶段的一部分。让客户的终端用户参加解决方案开发过程十分重要，因为客户可以在早期阶段改正错误，客户还了解如何使用解决方案的大量有关系信息。客户教育计划应包括：
指派给项目的终端用户列表及其项目时间表。
主要检查点项目可交付性的列表(包括用户文档)和时间表。
正式的用户教育实施时间表。金融和技术风险评估
如果没有足够的有经验和技能的人员参加，数据仓库项目就是一种高风险的业务。让您自己组织中有经验的同事来查看数据仓库项目计划，以确保：
项目技术风险相当低。
项目时间表是可行的。
项目将有利可图。
在进行该评估之后，请与您的客户一起查看项目计划，并建立一致同意的项目计划。
