为什么, 光靠技术还不够，定义数据项目范围

注：由于中文句子结构调整，将“定义数据项目范围”置于句末以符合中文表达习惯。

这是关于数据策略的系列文章的第一篇。这篇文章将讨论定义数据项目时所面临的挑战。接下来的文章将进一步探讨数据策略。

近年来，许多组织在数据技术上进行了投资，以作为提升业务价值的“放大器”。不幸的是，大多数这些组织发现，仅仅依靠技术并不能解决繁琐的数据流程、效率低下的数据团队结构或组织内部缺乏对数据的热情和理解等问题。这就是为什么即使是最先进的数据平台也常常无法充分发挥作用。总之，我们应该将数据技术视为一种工具，而非终极目标。

仅靠技术本身并不是解决繁琐的官僚数据流程或效率低下的数据团队架构的解决方案。（图片版权：Author）

这篇文章深入探讨了为什么许多数据项目从设计上就容易失败。通过一个例子，我展示了仅从技术角度来界定数据项目的范围是不足以创造持久的价值的。接下来，我将引入康威定律（Conway's Law）来说明这些失败背后的重要模式和规律。最后，我将探讨如何通过更全面地关注组织的数据驱动能力来改善项目的成果。

许多组织通过启动一个“数据项目”来开启他们的数据驱动之旅。这些项目雄心壮志，希望在组织内部实现新的数据驱动能力。然而，我发现这些项目往往根本无法成功，永远无法实现这一目标！

典型的數據煩惱包括長且不可預測的數據準備周期、影子報告，以及對保羅的依賴性（圖片版權：Author）。

为了说明这一点，让我们来看看组织现在遇到了哪些困难：

1. 长期且难以预测的数据准备时间：所有报告均由一个集中的报告团队创建。业务团队将其需求传递给该报告团队，由该团队实施并交付所需的报告。报告团队和业务团队之间的优先事项不一致，导致了长时间且难以预测的准备时间。
2. 影子报告：由于处理时间过长，业务团队开始在电子表格中创建自己的报告。这些报告是直接从源应用程序导出或使用现有报告的导出数据构建的。
3. 只有保罗知道：关于数据以及数据如何从源流向目标几乎没有文档记录。幸运的是，有保罗，他记住了每个流程是如何运作的。不幸的是，保罗不能同时处理所有请求。保罗的可用性成为许多交付计划的瓶颈。
4. 不可信的KPI：管理层使用一个集中的KPI仪表板。不幸的是，每次打开KPI定义时都会引起争议。要么KPI定义每次打开时都会被争论，要么支撑该KPI的数据含有数据质量问题，这些问题会极大地影响数字。例如，一个显示客户数量的KPI显示了20%过多的客户，因为源系统中的数据重复问题导致。
5. 未知的数据访问：数据访问由一个中央服务台团队处理。该团队不了解谁可以访问哪些报告或数据库的哪个部分。因此，他们随意给予所有人所需数据的访问权限，而没有任何迹象表明这是否合理。数据访问权限从未被审查过。
6. 创新停滞：由于集中的报告团队完全专注于处理报告请求，没有时间进行创新。他们专注于保持所有事情正常运行。关于新事物，如人工智能或非结构化数据的业务请求，由于资源不足而被推迟。

组织常常面临诸如不可信的KPI指标和数据访问管理困难等数据困扰。（图片版权：Author）

过了一段时间，之前描述的问题开始恶化，从而定义了一个“数据项目”。该项目将引入一个新的最先进的数据平台，使组织快速进入21世纪。业务团队甚至可以使用“自助报告”功能。项目计划和路线图已经确定，开发团队已经加入，准备工作已经完成，现在可以开始了！

让我们现在跟随乐观的（但有些不切实际的）“成功的交付”以及按时交付数据平台的情景来时间跳跃。这个新平台本应将组织的数据问题转化为数据优势！但实际情况并非如此：

1. 长且不可预测的数据交付时间：自助报告功能可用，但这继续造成延迟，业务团队仍依赖于集中化数据团队来处理数据的摄入和准备。
2. 影子报告：尽管电子表格使用量减少，但这在另一种工具中形成了未治理的影子报告，相同的报告在报告门户中仍存在多个版本。
3. 只有保罗知道：保罗仍然是导航新平台的关键人物，他的知识仍然是创新的瓶颈，无人能替代。
4. 不可信的KPI：尽管在项目期间数据质量得到暂时改善，但持续的数据输入错误导致新的质量问题，使得KPI再次变得不可信。
5. 未知的数据访问权限：新平台具有细粒度的访问控制，但服务台团队仍然按照相同的有缺陷的流程授予访问权限，而没有充分理解。
6. 创新受阻：尽管新平台具备强大的功能，但由于对保罗的依赖，持续的数据质量问题以及数据访问的不确定性，创新仍然受到阻碍。然而，至少创新不再受技术限制。

结果表明，在一个纯粹的技术性数据项目之后，几乎没有组织变化。（图片来源：Author）

这里展示的是在许多数字转型项目中常见的康威定律所描述的模式。

“设计系统（在这里指广义上的系统）的组织，只能设计出与这些组织沟通结构类似的系统。” — 梅尔文·E·康威, (How Do Committees Invent?（《委员会如何创新？》）)

康威定律虽然起源于1957年，Skelton等人在其畅销书《团队拓扑学》中展示了这条定律在当今组织中的适用性。简单来说，如果团队之间的沟通像在传递球一样，软件架构会根据这种沟通方式被优化。

康威法则指出，一个组织将会设计出与其沟通结构相似的系统；即使这些结构就像是大家传递网球一样（图片版权：作者 Author）。

将康威的法则应用在我们的数据世界中时，我们可以得出以下三点：

• 实现后的数据平台将针对中央数据团队进行优化，因为这是当前组织内沟通的方式。
• 每个数据实施都包括保罗，这表明新的数据平台也将围绕保罗来设计。
• 在当前组织中，数据团队和业务团队之间没有关于数据访问和质量的沟通渠道。这意味着新的数据平台不会专门优化以打破部门间的壁垒。

从之前的章节中，我们了解到，一个仅专注于技术的数据项目并不能解决组织中的所有数据问题。根据康威定律所言，同样的沟通导向问题会不断在不同的技术中出现。这表明了大量的资金、资源和时间被浪费了。

一种改进的方法是使用“逆康威结构”（参见Skelton et al. 和 Forsgren et al.）。在这种方法中，在软件完成之前，你会重新配置团队间的沟通。这种结构意味着你的数据项目将重点从单纯的科技转向人员和流程。事实证明，在重新组织使用平台的流程和团队之后，你会交付（部分）新平台。

我们的例子中的反康威操作，即在完成数据平台软件前，先调整团队间的沟通。(图片版权：Author)

在我们的例子中，我们需要按照上述描述重新配置通信线路以利用反康威调整。下面，我提供了几种如何执行此策略来解决各种数据问题的方法。

• 为业务团队（甚至是业务领域）提供必要的培训、人员配备和明确的角色与职责，以便他们能够创建自己的报告。
• 一旦团队准备就绪，将他们引入自助数据工具。
• 监控并识别达到所需的前置时间所需的额外步骤。
• 如果团队频繁因缺乏工程能力而受阻，则将这些团队中的数据工程师整合进来。
• 将业务团队的数据工程师引导至数据平台的工程工具。

• 消除对保罗的直接依赖，禁止团队在项目工作中直接依赖保罗。
• 保罗通过在数据目录中添加元数据来记录他的知识。
• 由于禁止与保罗沟通，业务团队被鼓励采用数据目录来实现他们的需求场景。

• 明确界定数据的所有者，负责数据的访问权限和质量。
• 指定数据守护者，负责处理数据质量问题。
• 实施一个数据访问流程，由数据守护者审批访问请求，保证遵循最小权限访问原则。

此图展示了调整互通讯道是如何导致使用提供的数据工具的。（图片版权：Author）

要从数据中获取价值，必须将数据项目扩展至数据技术之外。应该考虑流程和工具，以塑造组织，使其适应未来的以数据驱动的工作方式。正如反康威手法所描述的，最好在你的数据平台搭建结束前就开始调整组织结构。这有助于构建符合你期望工作方式的最佳数据架构。在数据治理和管理的领域，例如在《DAMA DMBOK》中，可以找到优化数据流程和组织结构的灵感。

我相信反向康威操作激发了新系统的设计和采用。然而，我有一个问题是购买和配置数据平台而不是自己构建一个的影响。例如，前者的方法可能允许组织购买强制特定的工作方式的软件（例如，数据网）。我认为在这种情况下，不管你是先进行组织转型还是在平台交付之后进行，意义不大。

虽然这篇文章提供了一些关于如何更好地规划数据项目的指导，但仍有一些未解答的问题需要解决：

1. 我们是否知道我们组织最优的数据驱动工作方式是什么？ 如果我们不知道这一点，这将使得塑造组织和流程变得非常困难。
2. 如何在飞机飞行过程中更换发动机？ 这个比喻解释了在实施新的数据驱动的工作方式时变革管理的难度。我们不能暂停所有工作，直到每个人都适应了新方法；我们需要一种更巧妙的变革管理方法。

为了回答这些问题，有必要制定一个支持您业务战略的数据策略，同时还要结合适当的变更管理实践。在接下来的文章中，我将深入探讨数据策略和变更管理等话题，来回答这些问题。

作为最终结论，单靠技术是不够的，无法让你的组织变成数据驱动型的；只有合适的人才和流程才能使技术发挥作用。不过，技术在构造这整个拼图中仍然扮演着关键角色。购买（或构建）适合支持你未来工作方式和数据策略的数据平台软件，仍然是不可或缺的一块拼图。没有成熟的数据技术，单靠重新组织工作方式也无法解决问题。

问题？反馈？通过 LinkedIn 或发送邮件至Jan@Sievax.be.

_本文由 Sievax 好心带来，这是一家致力于引导您走向数据卓越的咨询公司。咨询公司 Sievax 致力于引导您走向数据卓越。想了解更多详情吗？访问我们的_ 网站 ！我们提供 数据策略大师班 ，帮助您更好地掌握数据策略的世界。