介绍
关于数据产品的讨论很多，尤其是随着数据网格等方法的兴起。如果做得正确，使用数据产品创建分析可以推动真正的业务价值并显著加快分析交付速度。在这篇文章中，我们尝试从业务角度确定数据产品应该是什么，并研究构建它们的框架。
数据网格定义的数据产品
数据网格详细介绍了将其定义为“产品”的一些常见的方面。这些通常侧重于所交付内容的技术、打包和部署方面。
尽管这些是一组非常好的要求，但它们忽略了几个非常重要的方面：
它们不提供任何业务背景或指导-这些实际上是技术而不是业务需求，即它们范围限定了数据产品在其技术环境中的行为方式。
它们不包括任何实际的产品要求。即产品需要解决什么问题，客户是谁，价值是什么等。
产品经理对这些方面知之甚少，并且很难使用这些方面来绘制产品生命周期流程。
通常没有办法与任何类型的数据或业务策略联系起来。即我要构建什么产品?如何让他们随着业务的变化而变化?
事实上，如果有人尝试将其直接应用于面向分析的业务策略甚至应用场景，那么人们会感觉基于这种定义还不能满足需求。
数据网格以及许多其他方法通常谈论专注于数据的“数据即产品”或“数据产品”，但这种观点存在一些问题。
大多数数据都是中间产物。例如，它是分析模型的输入，比如Excel、ML、数据仓库模式等。它很少直接为企业提供实际的见解或价值。
数据作为许多其他组件和用例的组成部分被复制、分割、聚合和传播。
产品通常仅指打包和部署方面，包括运行和操作功能。
这些描述实际上是数据服务。
数据产品——如何聚焦产品部分
为了更多的关注产品方面，我们应该为数据产品是什么以及它与业务的关系制定基本规则。为了尝试解决这个问题，必须清楚数据产品是什么。当与业务利益相关者交谈时，需要用业务术语进行交谈，所以可以用这种方式建造产品。
数据产品需要：
直接驱动损益。
告诉我一些关于业务的事情。
告诉我在业务中做一些事情。
具体来说，这可以解释为：
有针对性并专门解决分析环境中的业务问题。
为企业客户提供直接价值。
不仅仅是数据集，除非它实际出售(例如在外部市场上)。
拥有一个包含直接业务客户交互反馈等的产品生命周期。
为了从产品角度解决业务战略，我们需要从业务战略试图解决的关键问题开始。例如，对于运营经理-如何每年将运营成本降低10%。
分析构建者与业务其他部门的代表一起，需要将其分解为较小的分析和数据问题。我们可以将其视为决策流程：
数据产品决策流程
当我们按照流程进行工作时，我们会提出关键问题，这些问题的答案将满足需求并定义结果，这些结果实际上是为问题提供答案的数据产品。
在流程的每个部分中，我们都将问题分解为问题列表，并在下一层中使用更细粒度的数据产品和服务来回答这些问题。也就是说，当我们向下移动时，我们会变得更加具体，并且我们也会更接近来自将数据作为服务提供的业务流程和系统的实际数据。
数据产品金字塔
这将表现为一个数据产品金字塔，每个产品都旨在解决最终解决顶 级业务问题的流程的一部分。
数据产品以金字塔形式组织的原因是可以快速、增量地交付。此外，无需等待整个用例交付即可从业务部门接收反馈。
该流程从需要根据特定业务需求做出的顶层决策开始。例如，需要降低运营成本，需要测试我的营销策略等。然后会分解为要提出的问题。
做出决定的原因是为了获得可衡量的结果并有一个具体的目标。很多时候，数据和分析团队被要求提供数据，并花费大量时间努力创建模型，获取数据后却发现它没有回答任何特定问题，或者问题是错误的，无法按照组织的要求创建。没有数据支持来实现它的创建。
所以，简单来说：
以正确的方式(可行)提出正确的(有价值的)问题，其答案实际上支持(或推动)正确的决策。
为了构建金字塔，我们首先根据业务来创建一个模拟金字塔，通过决策过程并使用业务和各自的数据团队的知识来分解用例。
然后，使用模拟数据创建一些实际的数据产品，以了解数据需求。数据用于服务于下层和上层数据产品。然后，在获取数据并完成详细需求时，重新分解和细化每个数据产品，用真实数据替换模拟数据。
如果产品已经存在，那么它们可以用作流程的一部分。
数据产品类型
同样重要的是要指出，金字塔由不同类型的产品组成，这些产品解决了不同的问题，并具有不同的方法和目的。
这些分为：
决策产品-这些是模型/算法和决策产品，它们要么告诉企业他们需要做什么，要么根据其做出的决策实际执行操作。例如，推荐引擎实际上可以从电子商务系统购买产品。
知识产品-这些实际上告诉我一些关于我的业务的信息，这些信息源自底层数据和信息产品-即它们通常是预测或应用语义的模型或算法，告诉我为什么会发生某些事情(例如单一客户视图、分类等)。
信息产品——这些只是给我提供信息。它们位于实际交易数据之上，但仍然给我一个细粒度问题的答案，例如我的总历史成本是多少等。
数据服务-正如我之前所说，这些不是数据产品，而是为所有所需数据产品以特定格式和操作配置文件(例如SLA、访问模式等)提供特定数据的重要组件。这些是特定于用例的，并不是专门为重用而设计的。
他们“组装”来自业务领域和其他产品的数据，以构建供特定数据产品使用的特定结构。它们还包括注释和标记，以便其他使用者可以重复使用它们，只要它们不破坏原始用例。
数据产品策略
我们讨论了数据产品，但它们不能单独存在。它们需要成为实施业务战略的整个流程的一部分。
上图显示了我们如何创建数据产品作为总体战略的一部分。
左侧是关键业务变革驱动因素，它提供触发任何变更以完成流程的机会。
每个变更都会从业务和解决方案的角度进行评估、优先排序和框架。
然后通过数据产品漏斗将其提炼成一组数据产品。业务客户(包括利益相关者)通过构建和部署的快速反馈回路不断进行审查和完善。
当产品获得可接受的结果后，就会将其发布到公司的数据基础基础设施上，以便在整个企业中使用和重复使用。
业务变革驱动因素
该流程的起点是对业务变革驱动因素做出反应。这些可概括为三个领域：
业务驱动——业务战略因高管的愿望或市场力量的强制变化而发生变化。
环境驱动-环境发生变化，企业需要针对新冠疫情做出响应就是最近的一个例子。
运营驱动-业务运营发生变化，例如运营中断、新系统、新数据等，并且流程和系统需要进行一些更改以适应它们。
数据产品漏斗
数据产品漏斗是用来实施数据产品以应对业务变化的流程。我们将业务计划创建为带有问题的分析决策，并将它们放入顶部的漏斗中，向下计算(边实现边迭代)，数据产品从底部出来，部署到基础设施中。
注意：尽管我们沿着漏斗向下移动，但我们可以从漏斗的任何其他部分返回到漏斗的任何部分。
为此，我们按照以下过程进行迭代：
用例的业务变革驱动因素
首先，我们将关键变革举措填充到漏斗中，作为基于需要做出的决策的实际问题列表。
用例选择/优先级
接下来，业务团队使用价值框架根据其价值来确定决策流程的优先级。
业务框架
接下来，我们确保问题是正确的并且以正确的方式提出。
解决方案框架
接下来，我们选择要解决的分析问题的类型、概况、初始输入等。
将用例构建并迭代为数据产品金字塔
然后，我们将每个用例/决策分解为数据产品金字塔，当我们在漏斗中上下迭代时，这些金字塔会逐渐构建。
转换和部署到数据产品基础基础设施
最后，我们将产品发布到数据产品基础基础设施，其中包含一个数据产品目录，该目录维护有关运行时操作等方面的元数据，并能够轻松重用。
主要成果
如果我们遵循这个过程，我们会得到以下结果：
适应业务战略——业务战略可以从小处开始，随着业务的变化而发展和适应。
直接基于业务策略的快速交付非常有价值的用例。
可以在整个企业中使用和重复使用的实际和特定的现实世界“产品”的组合。
实施流程
我们知道我们需要交付什么，我们知道它如何融入战略，但我们如何实施呢?
我们将实施能力分为三个部分。全部作为迭代循环执行：
价值框架——指导企业通过提出正确的问题来选择最有价值的业务决策。
快速自适应实施流程-该流程允许数据、数据和分析团队快速实验、开发决策/用例并将其细化为数据产品。
灵活而强大的数据产品基础-是一种基于数据和IT基础设施的功能，提供用于开发、部署和操作数据产品的工具和软件，以支持其他两个支柱。这通常包括数据网格和数据结构等方法的技术概念。
让我们深入研究每一个：
价值框架
价值框架使业务战略能够根据实际价值逐步定义，并将业务愿景和愿望与可交付成果联系起来。它分为：
价值框架——这是企业“所有人”就如何衡量价值并将其应用于分析业务成果达成一致的一种方式。
业务价值地图-由于计划是增量定义的(提前或作为对外部事件的响应)，此流程用于映射每个计划的实际商定价值，以便确定优先级和重点。
业务用例解决方案框架-每个计划都被分解为候选商业用例，并对其进行分类，以便查看是否a)这是正确的问题，b)是否以正确的方式提出。例如，运营主管可能希望通过减少员工数量来降低成本，但实际上更容易实现的目标可能是降低基础设施成本。
用例选择和优先级划分——创建和构建每个用例时，可行性与其他优先级任务一起完成，以允许获胜者填充实施漏斗，在下一部分中作为数据产品交付。
快速自适应实施流程
这是一种为每个决策/用例快速创建和完善数据产品的迭代方法，并分为：
用例实施流程-一种迭代开发方法，可将用例快速分解为业务可以理解的数据产品和数据服务的层次结构。
数据产品设计框架-数据产品原型、模板和模式(组成、定义、代码工件等)库，可解决用例的不同部分，无需或很少的代码即可快速创建这些用例。
数据产品组合/市场-一个商业友好的可搜索数据市场，数据产品在其中部署和运行。每个数据产品都有一个完整的产品生命周期——即创建/使用和退役。
联合数据治理和管理-简单地说，它是每个数据产品实施全局定义的策略和规则的能力，并且本地决策/用例。
数据产品基础
这是用于构建和部署数据产品软件和数据制品的数据基础设施和开发能力。它分为：
跨业务数据产品基础架构，例如数据网格和其他产品架构。这使得每个企业的所有团队都能以受控且低摩擦的方式部署数据产品。它支持多种技术、数据和分析模式-请注意，没有单一堆栈。
快速数据产品创新能力——这使得能够在安全的环境沙箱中快速制作新数据、技术和产品的原型和实验。
增量创建业务和数据功能部件——共享数据工件，例如业务词典、策略、领域地图、本体等。随着每个数据产品金字塔的构建，逐步和迭代地构建和完善。
重要的是要注意该过程早期部分的高度实验性和迭代性。数据产品可以以非常粗略的形式创建，以获取业务计划的反馈，并在经过测试和完善后变得更加成熟。最后，一旦它们被证明适合用途，它们就可以被标记为“生产”，准备在基础设施上发布。
数据产品的生命周期可以较长(例如季度报告)，也可以较短(例如针对即将发生的业务事件的临时研究)。但随着业务的变化，它们都可以方便创建和淘汰。
此外，支持任何类型的数据产品也很重要，即需要高操作配置文件(例如实时推荐引擎)的数据产品可以与任何低配置文件(临时市场研究报告)一起在数据基础上发布。
产品可以是实时/批量的，也可以具有任何其他类型的操作配置文件，因为业务不区分它们。
域所有权
为了使这种方法在大型复杂组织中发挥作用，流程和支持基础需要支持由不同业务领域的不同团队中的团队拥有、构建和运行的数据产品。
在此示例中，负责顶 级用例的数据团队成员仅构建顶 级决策产品。他们与其他四个领域团队联络，构建每种不同的产品和服务以形成金字塔。
重要的是，每个产品的工作都由拥有该部分需求的团队来执行，即数据产品应该由拥有提供该见解或数据的业务流程的团队直接交付。
一个有效的例子
为了加深印象，我们将通过一个示例进行工作：
想象一下，我们有一位运营主管，他的业务目标是降低所有业务领域的运营成本。
首先，我们声明决定是为了降低运营成本!这将被视为使用价值框架的优先事项。
接下来，我们需要问做出这个决定需要什么——这向我们提出了以下问题：
我的目标成本降低是多少?金字塔成功的总体衡量标准。
接下来我们需要开始深入研究，例如
我的最高成本在哪里?我需要瞄准哪里?
未来成本与业务需求相关
各业务线的历史和未来成本
按业务线划分的历史和未来交易量(仅用于此示例的简化使用模型)
其源自
人力资源、运营和其他系统的成本最低
来自调度和时间表系统的员工名册
来自OLTP系统的事务数据。
因此，人们可以开始了解这些问题中的每一个问题是如何通过数据产品和数据服务金字塔(在最低级别的情况下)来回答的，所有这些金字塔都是为了回答它们上面一层的问题而构建的。
上图显示了为该金字塔提供服务的数据产品金字塔示例
顶层决策产品是一个人员优化引擎，它根据金字塔较低层计算的最 佳事件和成本创建新的花名册。
下一个级别有两个知识产品-第一个预测未来成本，第二个将未来业务成本与未来业务事件相关联。
下一个级别有一个信息产品-一个指标(按业务线提供历史成本)和两个数据服务。第一个给出了历史交易，第二个给出了员工名册详细信息。
最后一层有很多数据服务，它们都将跨业务线的所有事务系统的数据呈现给上层的数据产品和服务。
小结
以上部分展示了如何使用数据产品来直接解决和实施业务策略使用这些方法和框架，公司可以从小规模起步，逐步建立业务战略，以及有价值的面向业务的数据和分析“产品”集合，这些“产品”可以在整个组织中快速使用和重复使用。
