Kimball维度模型之构建数据仓库先决条件

    如果你所在的公司授权你领导DW/BI项目的建设，那么这对你来说意味着什么？你如何评估你所领导的项目成功几率是多少？你又应该从何处开始入手？我强烈建议你在开足马力、埋头大干之前先花一点时间评估你所在机构对DW/BI项目准备就绪情况。本文将结合Kimball项目管理经典和笔者工作经验对如何评估DW/BI项目可行性标准化进行经验介绍。

一 构建DW/BI项目启动先决条件

    根据我们的经验，在您开始详细设计和开发数据仓库之前，必须确保三个关键因素已经到位。这些因素为你成功构建数据仓库奠定了基础。如果你不能自信地给您所在的组织在这些综合因素上打个合格的分数，那我强烈建议您放慢脚步，慎重考虑您的组织是否已经做好了数据仓库的准备。我们的经验表明，如果前期准备不足，负面影响不会随着时间的推移而自行纠正。与其在投入大量资金之前继续推进项目，不如在问题变得严重之前先停止DW/BI项目。这样做比继续在充满坎坷和障碍的道路上前行更为明智。而要做到这一点最重要的一点是你所在的组织至少要有一位具有担当且富有远见的管理者。

    针对DW/BI项目启动先决条件Kimball团队给出三个先决评估条件，详细信息请看下文介绍。

1 DW/BI项目得到强大的业务管理者支持

    在评估数据仓库准备情况时，来自业务管理者的强大支持是至关重要的因素。强大的业务管支持具备一系列关键特征。首先，他们对数据仓库的潜在影响有着明确的愿景，并对这一愿景坚定自己的个人信念，通常表现为愿意为其负责。强大的业务赞助者是组织内具有影响力的领导者，通常以坚实的成功记录和他人的高度尊重为特征，即在组织中拥有权威。此外，他们通常具有远见并具有良好的人际关系密切。不幸的是，很多组织内DW/BI项目的强力支持者往往也是组织中的新成员，他们加入并怀有改变组织愿景的积极态度。虽然我们见过这样的新成员通过数据仓库取得成功，但鉴于他们对组织文化、成员、氛围和流程的了解有限，这也是一种更具风险的选择。

    理想的支持DW/BI项目的业务管理者不仅强大，还具备现实主义。如果他们对数据仓库概念有基本了解，包括迭代开发周期，将有助于避免不切实际的期望。有效的管理者支持能够接受短期问题和挫折，因为他们专注于项目的长期成功。现实主义的管理者支持愿意妥协，能够做出艰难的决策并承担后果。

    最后，成功的数据仓库团队通常在组织内培养了多位强大的管理者共同参与。换句话说，不要将所有期望寄托在一个人身上。在只有一个强力管理者支持的情况下，当该管理者离职后，数据仓库往往会陷入停滞不前的境遇，而新管理者通常没有太多时间关注其前任的个人项目。

2 对于DW/BI项目强烈的业务动机

    数据仓库是应对特定关键业务需求的一种促进手段，不言而喻。成功实施数据仓库的组织通常共享一个共同的特点：即由一种迫切的业务动机引发的组织紧迫感。有时，是竞争和竞争格局的变化充当了推动因素；而其他组织则在内部危机中获得了动力。在其他情况下，对潜在市场机会的战略愿景成为了强大的动力。如果高管层认定未来十年的生存取决于成为以客户为中心的组织，那么谁会质疑一个能将全新业务方式的愿景变为现实的数据仓库倡议呢？

    一些组织历史上通过收购实现了增长，而要了解整个组织绩效，几乎是不可能的，除非开发一个集成式的数据仓库。

    与这些战略业务动机相一致的数据仓库有很大成功的机会。同样，如果数据仓库准备支持引人注目的业务动机，那么业务正当理由几乎就不成问题了。在这些情况下，组织还可能具有经济动力，以持续投资于数据仓库的长期发展。那些正经历大规模裁员或不友好合并讨论等彻底变革的组织，可能因为分散了注意力而难以启动成功的数据仓库倡议。

3 业务伙伴参与

    在数据仓库建设中，业务伙伴的积极参与至关重要。成功的数据仓库项目不是单一团队的努力，而是业务和技术团队共同努力的结果。在这个合作中，双方共同承担倡议的责任，形成了一种紧密的合作关系。

    业务伙伴的参与对于确保数据仓库的成功至关重要。如果业务和技术各自独立建设数据仓库，很可能导致项目失败。因此，数据仓库项目为提升技术团队与业务团队之间合作关系提供了绝佳的机会。通过共同参与项目，业务伙伴有机会更好地理解数据仓库的业务需求，而技术团队则能够更好地理解业务流程和目标。

    这种合作不仅有助于确保数据仓库能够满足业务需求，而且有助于建立跨团队的沟通和理解。业务伙伴的参与可以促使更好的信息流动，提高团队的协同效率。在这个过程中，双方有机会共同解决问题、分享洞察，并共同推动数据仓库的发展。

二 对于DW/BI项目启动先决条件,为什么没有包含技术？

    在构建数据仓库/商业智能（DW/BI）项目时，技术并不是先决条件，而业务理解才是至关重要的影响因素。尽管技术在项目实施中起到关键作用，但真正成功的数据仓库项目不仅仅依赖于技术工具和平台。

    首先，业务理解是确保数据仓库满足组织需求的基石。了解业务流程、需求和目标是建立有效数据模型、开发有针对性的报告和实现可靠分析的关键。如果缺乏对业务的深刻理解，技术的应用可能会失去方向，无法真正满足业务的期望。

    其次，业务理解有助于确保数据仓库项目与组织的战略目标相一致。通过深入了解业务需求，项目能够对数据进行有效整合，以支持更明智的决策制定。反之，如果仅依赖技术而忽视业务需求，数据仓库可能会变得过于复杂或无法满足实际业务问题。

    最后，业务理解有助于建立与利益相关者的紧密沟通和合作。在项目的早期阶段，与业务团队紧密协作可以确保项目团队对业务挑战和机会有全面的了解。这种合作有助于建立信任，并为后续的技术决策提供了更明智的基础。

    因此，尽管技术是数据仓库项目的重要组成部分，但业务理解是确保项目成功的关键先决条件。只有通过深刻理解业务需求，项目才能真正实现其预期目标并为组织创造持久价值。

三 Kimball经验总结

    成功的DW/BI项目通常共享上述一系列关键特征，而失败的项目则往往面临各种问题，其中一些问题可以总结自数据仓库专家Kimball的观点。

失败的DW/BI项目因素：

1. 能力弱的业务发起人和仅懂IT的技术发起人： 失败的项目往往出现在业务发起人缺乏深刻业务理解或技术发起人无法有效沟通业务需求的情况下。成功的项目通常建立在业务和技术团队紧密协作的基础上，而弱势的业务或技术发起人可能导致沟通障碍和项目目标的偏离。例子：在一个以技术为主导的项目中，业务发起人可能无法有效传达业务需求，导致最终交付的数据仓库无法满足真实业务场景。

2. 业务发起人未考虑项目节奏，但提出过多不切实际的需求： 失败的项目可能受到业务发起人未能合理评估项目进度和规模的影响。频繁变更、过多的需求以及对项目时间表不切实际的期望可能导致项目无法按时交付，最终影响项目成功。例子：在一个项目中，业务发起人可能在项目进行中不断提出新的需求，而无法意识到这些变更对项目的影响，最终导致项目延迟和预算超支。

3. 善意确冒进的业务发起人： 有时，业务发起人可能急于追求成功，却未充分考虑项目的可行性和风险。这种过于迫切的行为可能导致项目在初期阶段就陷入困境，难以持续发展。例子：一位业务发起人可能过于热衷于迅速实现数据仓库的目标，而忽略了在项目前期进行充分的规划和分析，导致项目在后续阶段面临问题。

4. 低质量的业务数据： 数据仓库的成功建立依赖于高质量的业务数据。如果源系统中存在低质量、不一致或不完整的数据，那么数据仓库将难以提供准确和可靠的分析结果。例子：如果源系统中的数据存在重复、缺失或错误，那么构建在这些数据基础上的数据仓库将无法满足用户的需求，从而影响项目的成功。

    然而在所有影响因素中，"强有力的管理者支持"是其中最为重要的前提条件。在经历十几个具体的项目经验中，有从0~1建仓经验，也有重构数仓经验，无独有偶，成功的案例都会有至少一位充满魅力领导者支持。不原相信的一点，失败的案例至少有一位不合格的管理者参合，**21世纪，人才是最值钱的**。