为什么数据仓库项目失败

为什么数据仓库项目失败

数据仓库项目是组织可以承担的最可见和昂贵的举措之一。可悲的是,他们也是最有可能失败的。 曾经一次,Gartner报道 超过50%的数据仓库将无法实现用户验收。由于投资规模(两次和金钱)所需,这种项目的成功可以制造或打破职业生涯。因此,要理解为什么数据仓库项目失败。

为什么数据仓库项目失败

在我的岁月里 数据仓库顾问,我被称为救援一些停滞不前的(甚至失败)的数据仓库项目。虽然任何两个失败的DW计划的后期永远不会是相同的,但我发现这些项目中有一些共同的主题,从来没有通过终点线。了解为什么数据仓库项目失败是至关重要的,所以您可以避免这些常见错误。

下面,我已经组装了我在不成功的数据仓库计划中找到的十个最常见的属性。

没有回答大问题:为什么?

令人惊讶的技术项目,包括数据仓库举措,而不是明确愿景,为什么需要它们。有时它是因为该项目可交付是年度的行业流行语。其他时候,它只是 假定 组织需要他们建立的东西,因为“其他人都有一个。” “为什么?”的答案问题比“如何?”更重要

数据仓库项目是耗时和昂贵的,并且需要在组织的每个级别都有很大的支持。在每一项此类倡议中,项目中间至少有一个点,其中一个C级执行员问,“再次提醒我为什么我们这样做......?”这是一个有效的问题,并且在项目开始之前应该有编纂答案的问题。

此外,“为什么?”问题的答案。应该由每个人都知道,而不仅仅是CXO和签署支票的人支付。我已经看到了太多的案件,工作人员 - 特别是技术人员 - 只是在做一件事而没有理解它如何适应大局。每个参与者从建筑师到商业分析师从项目经理到QA测试仪,应该了解项目的高级目标。

使用大爆炸方法

数据仓库不仅仅是数据库和喂食它的ETL过程。它是各种业务单位的复杂交集,来自不同步伐的许多来源的不同形状的数据,以及许多指标和每种测量。简而言之,数据仓库是一个较小的相关项目的集合,将在不同的时间开发和测试。

我见过的最成功的实现是所有涉及的增量数据仓库开发。虽然这种方法需要更加谨慎的规划和良好的沟通,但将项目突破到可以开发,部署和测试的较小的作品,其成功率比试图执行一切(“大爆炸”方法)。增量开发意味着您的核心资产首先完成,允许设计中的任何错误或遗漏,以便以最小的影响纠正。

虽然一切都是一旦大爆炸方法可以在非常小的数据仓库计划上工作,但这种方法没有很好地扩展。

直接跳到写作代码

您应该在数据仓库项目的早期使用最多的工具是白板。任何开头的DW项目,“让我们建立一些表!”或者“我会写ETL代码!”是由错误的实体驱动的。应该清楚地理解这一点 这是首先是一个商业项目,而不是技术人员.

了解业务需求(见“为什么?”来自早期的子弹)是第一个优先级。接下来是要了解业务将要询问数据的问题类型。编码解决方案,即使是原型,也是几步之遥。写入代码永远不应成为数据仓库项目中的第一步。

处理要求和可交付成果作为复选框

这里不要误解我的意图:理解和尊重范围和可交付成果至关重要。但是,数据仓库项目遭受遭受,因为要求被视为打击列表并完全按要求提供。要求和可交付成果是指导所进行的任务,但这并不意味着他们无法质疑或澄清。

当工作人员授权询问基本问题(“我们为什么y做x时可能更好?”)而不是只是指示构建一个小部件,您将最终获得更加成熟和强大的数据仓库。

断开技术人员和利益相关者之间的连接

很多时候,在数据仓库项目中表示的每个组内都有非常不同的语言。技术人员在分析和功能方面发言。业务分析师在行为和工作流程中发表讲话。高管了解结果和高级结果。在同一页面上获取这些组是这些项目中的重要任务,也是最困难的事情之一。

在整个数据仓库生命周期中管理组之间的通信是常量。在数据仓库项目失败的原因之中,这一个是大多数此类失败的计划中的一个因素。从收集到设定期望的初始要求,从部署到培训,管理DW项目的人必须不断确保这些组中的每组都能理解其他人。从结果和可交付成果到所使用的术语,确保每组朝向相同的终点线移动至关重要。

缩短(甚至完全跳过)测试和验证

当时间在数据仓库项目上运行短时,测试和验证通常是受害者。缺乏经验的项目经理或建筑师可能会节省或消除测试和验证的时间。相反,由于测试不足而救出了一个被停滞或失败的项目的人很了解该项目的这一部分与任何其他人一样重要。

有问题只能通过适当的测试和验证来发现。这些需要时间,但对数据仓库计划的成功至关重要。抵制促进通过削减该宝贵的运动来缓解调度压力。

在ETL上花太少的时间

设计,建筑和测试提取 - 变换负载(ETL)逻辑是每个数据仓库项目的最耗时的一部分。在项目调度期间也经常低估。通常,ETL处理被视为仅仅是复制操作,其中从一个位置读取数据并写入另一个位置。然而,它比这更复杂 - ETL的一部分很容易是该项目的最重要的最困难和艰苦的部分。

Etl. 层就像房子的基础:弄错了,其余的结构都是不稳定的。花点时间,遵循 Etl. 最佳实践 along the way.

跳过训练

部署数据仓库时,您将要去 移动很多奶酪。您将更改商业用户与数据互动多年的方式 - 可能甚至几十年!在建立数据仓库的同时是我们像我们这样的技术人士的大量工作,学习使用新的数据仓库也需要很多工作。适当的培训可以缓解这一转变。

投资时间训练基本人员。不要只是提供一个文件的卡车;与用户一起工作以确保他们可以转换为访问数据的新方法。以他们理解的方式训练它们,使用适用于它们的任何媒介(跑书,视频,人员培训)。

这种项目的最糟糕的潜在结果之一是没有人使用新的数据仓库。如果没有适当的培训,数据消费者可能只是继续做旧手动方式的事情。如果数据仓库坐着未使用,如果该项目的成功是重要的吗?

使用错误的人员

数据仓库项目与任何其他类型的技术项目不同,需要了解数据仓库架构和最佳实践以及对数据的特定于域的知识。简单地说,使用错误的人团队是数据仓库项目失败的原因之一。

仔细选择将建立建筑师,构建和测试数据仓库解决方案的人员。无论您是在内部资源还是使用 带上合作伙伴协助,请确保您的团队对数据仓库项目具有深入的体验,并了解您的组织的独特数据挑战。

忽视维护

数据仓库项目没有结束日期。当然,将有一个日期,解决方案的生活和专门投入其发展的资源被显着缩放。但是,数据仓库是一个生物,需要作为数据和业务需求发生变化的持续护理和喂养。对数据仓库的持续需求付出不少关注可能导致短期成功但项目的长期失败。

结论

虽然数据仓库项目失败了有多种原因,但许多这种不成功的举措中发现了共同的主题。为了更好的成功机会,避免这些陷阱!

关于作者

Tim Mitchell
Tim Mitchell is a 数据架构师和顾问 谁专注于摆脱数据疼痛点。 需要帮助数据仓库,ETL,报告或 训练 ? 如果是这样的话, 联系Tim. 没有义务30分钟聊天。

4评论 在“为什么数据仓库项目失败”

  1. 好帖子,它应该是一个从事EDW项目的人的必备读数。在这方面,我们都可以从Hadoop世界学习一些东西,并考虑调整有失败历史的行为。具体来说,

    –EDWS花费太多时间来显示价值。然后,你指出的价值通常是模糊的“big question: why?”。这两个大的是
    –逻辑建模:作为从业者,我们浪费太多时间做明星架构建模。只有这样我们就可以了…
    –ETL:昂贵的承包商,昂贵的承包商,花费太多时间花费了同样的ETL代码’t know your data.
    –一般情况下,ETL应该尽可能避免。使用外部表,链接服务器,语义层,并利用现有用户了解您的数据并知道SQL。

    现在看看这在Hadoop中的完成。非常少的建模是前面的,用户是给予的区域“data lake”去体验。他们用蜂巢做到这一点。现在数据可以是“learned”没有正式项目提取的价值。由于数据集变得非常宝贵“certified”,ELT过程正式化,并且数据自然地进入EDW。

    点是…即使是Kimball伙伴也正在重新评估它们’讲道讲道。如果我们的话,我们都应该考虑替代品和重新考虑“best practices”真的很棒。

  2. DW项目周围问题的优秀摘要。

  3. 同意您的所有评论,作为用于设计和实施数据仓库的前人。我不确定我会在谈话中徘徊。我认为Hadoop有其用途“lake”非结构化数据用于适用于数据或作为数据的暂存地面。

    已经说完了这一切,我意识到DW从数据模型最终确定的那一刻就会过时。数据关系数据库和维度建模的整个前提是业务规则建立在关系和参照完整性内。业务规则在大多数组织中始终如一地更改,因此在开始构建DW之前,您的模型在过时。这就是所谓的“early binding”数据的。 Hadoop和非结构化数据背后的房地之一就是您可以使用“late binding”数据的。这只是意味着你不’t “bind”在访问数据之前的关系。这简单地意味着更灵活的数据结构。我认为这就是戴夫所依赖的。我建议做一些阅读“早期结合与晚结合”数据的。但是,IMO,这就是使传统DW过时的原因,并且是一个失败的贡献者以及上面的原因。

  4. 任何IT项目和DW的失败的一个添加贡献者也不例外,假设工具在没有适当测试的代表卷中没有适当测试的工具。

发表评论

本网站使用AkisMet减少垃圾邮件。 了解如何处理评论数据.