数据库 频道

谈谈数据产品蓝图和构建模式

  数据管理实践向数据产品的演变有几个关键方面。传统的数据管理侧重于内部运营需求,数据存储在孤立的系统中。数据目录已转变为交互平台,促进数据发现和消费。数据产品管理强调通过迭代开发和以客户为中心的方法为外部客户提供价值。

  摩尔鸿沟凸显了从早期采用者过渡到更加广阔市场的挑战。数据复用和货币化至关重要,内部数据产品为外部商业化奠定了基础。

  反馈循环在整个数据产品生命周期中至关重要,有助于持续改进和适应客户需求。简化内部和外部数据产品的流程包括优化开发、交付和维护,以确保敏捷性和效率,并通过反馈循环通知每个阶段的迭代增强。

  下面我们了解现代数据管理的复杂性及其向数据产品的演变。最后,我们从标准化的角度简要讨论对以下模型的支持。

  让我们通过讨论上面的模型的编号部分来看看它。

  1. 传统数据管理

  在数据产品出现之前,传统的数据管理实践主要围绕组织内部运营需求的数据收集、存储和处理。数据通常在孤立的系统中进行管理,不同的部门根据其特定要求维护其数据库。这些数据库通常用于事务或运营目的,例如管理客户信息、库存或财务记录。

  数据目录代表了数据管理实践向数据产品演进的关键一步。传统上,组织维护数据目录主要用于内部参考,提供存储在其系统中的数据集的元数据描述。这些目录充当数据资产信息的存储库,包括其结构、使用和所有权。

  然而,随着数据产品的兴起,数据目录已经转变为动态的交互式平台,其设计不仅可以对数据资产进行编目,还可以促进更广泛的用户发现、探索和消费。现代数据目录利用先进的元数据管理功能(例如自动元数据提取和丰富)来提供对组织数据环境的全面洞察。

  结果,我们得到了“目录中的数据”,其中包含丰富的元数据,有时甚至是精炼格式的数据,可以按原样或组合打包到数据产品中。

  2. 数据产品管理

  数据产品管理在重点、方法和目标方面与传统数据管理不同。传统的数据管理主要围绕组织内部运营需求的数据收集、存储和处理。它通常涉及管理孤立系统中的数据,主要强调确保数据质量、一致性以及符合监管要求。传统数据管理的目标是通过为决策和分析提供准确可靠的数据来支持内部业务运营,例如客户关系管理、库存管理和财务报告。

  相比之下,数据产品管理超越了传统的数据管理实践,强调数据驱动的产品和服务的开发、交付和优化。数据产品管理不是仅仅关注内部运营需求,而是以客户为中心,主要关注通过数据驱动的解决方案向外部客户或最终用户提供价值。这包括识别市场机会、了解客户需求,并将这些需求转化为解决特定痛点或为用户带来切实利益的数据产品。

  3.摩尔鸿沟

  摩尔鸿沟,也称为“鸿沟理论”或“跨越鸿沟”,是杰弗里·摩尔在其著作《跨越鸿沟:向主流客户营销和销售高科技产品》中提出的概念。

  鸿沟代表了技术或产品的早期采用者与更广泛的主流市场之间的巨大差距或障碍。摩尔认为,技术采用生命周期可分为五个阶段:创新者、早期采用者、早期大众、晚期大众和落后者。早期采用者和早期大众之间存在鸿沟。

  对于科技公司来说,这一鸿沟是一个关键阶段,因为跨越它通常决定了产品是否会在大众市场取得成功,还是仍然局限于内部应用。与吸引早期采用者的策略相比,跨越鸿沟需要不同的营销和销售方法。公司必须解决主流客户的担忧和要求,他们可能比早期采用者更关注风险,并且有不同的需求和期望。

  摩尔鸿沟存在于内部和外部数据产品案例中。数据产品是为了特定目的而开发的,客户可以是内部的或外部的。无论目标受众是什么,都需要跨越鸿沟。

  4.数据重用和货币化

  在 4 和 5 中,我们讨论内部或外部目的的数据产品。在这种情况下,通常使用术语“数据货币化”和“商业化”。数据商业化涉及通过向外部客户销售或许可数据产品或服务来产生收入,而数据货币化则涵盖旨在从数据资产中提取价值的所有活动,无论是通过直接创收还是其他方式。虽然这两个概念相关且经常重叠,但它们代表了利用数据实现业务目的和实现不同目标的不同方法。

  内部数据产品对于促进组织内数据重用、促进协作和推动明智决策至关重要。虽然他们专注于在内部提供价值,但他们还通过验证数据资产、完善分析能力以及提供外部数据货币化途径,在为数据商业化计划奠定基础方面发挥着至关重要的作用。

  5. 数据交换和商业化

  面向外部的数据产品的数据商业化涉及将内部数据资产转换为可销售的产品或服务,然后出售或许可给外部客户或合作伙伴的过程。这通常从识别组织内有潜力满足特定市场需求或机会的有价值的数据资产开始。这些数据资产可能包括专有数据集、分析功能或来自内部运营或客户交互的见解。

  这也是数据合同(作为技术合同)缺乏的时刻。当数据产品暴露给外部客户时,责任和其他法律方面必须作为风险管理的一部分予以考虑。在这种情况下,数据合同具有法律要素,并成为数据协议。因此,在上图中,我们为外部价值实现数据产品的数据协议设置了单独的框。

  6. 从重用到交换

  尽管数据产品最初可以设计用于服务内部需求,但其中一些可能会成为商业化的业务资产(价值实现发生在外部)。这是应该时刻牢记的。

  简化内部和外部数据产品的流程涉及优化数据产品开发、交付和维护的整个生命周期,以提高效率、有效性和敏捷性。理想情况下,您应该拥有一种流程模型,使您能够在需要的任何时刻以最小的努力将内部数据产品公开给外部商业化。对待每一个数据产品,就好像如果业务需要的话,有必要将其公开。

  7.反馈循环

  反馈循环至关重要,就像任何成功的商业模式一样。数据产品开发以迭代周期运行,构成其生命周期的基石。理想情况下,反馈循环应该渗透到每个阶段,允许回归一个或多个步骤。例如,在数据产品销售期间,可能会出现重要数据丢失且当前不可用的情况。在这种情况下,反馈循环会延伸回数据创建。同样,当定价计划无法满足客户期望时,反馈循环会从数据产品价值实现转向数据产品提供,促使业务对计划进行调整。

  数据产品管理要求

  鉴于上述高度简化的思维过程被接受,我们可以得出一些数据产品管理的要求。

  首先,必须能够重用元数据。数据产品蓝图是内部和外部价值实现的草图。所有的数据产品都有数据合同(技术重点)。

  根据业务目标和机会:

  1.  数据产品蓝图包含最少的业务元数据和数据合同,组合成数据产品以供内部使用。

  2.  具有完整业务元数据的数据产品蓝图,包括定价计划和具有法律方面的数据合同(成为数据协议),被合并为用于外部目的的数据产品。

  定义一次并重复使用

  现在,我们不想将相同的元数据定义为数据产品蓝图、数据合同和数据协议的一部分。那是多余的。我们希望所有元数据定义一次并在数据产品的各个部分中重复使用。以数据质量为例。它将在统一模型中定义一次并用作组件。数据质量的价值主张可能不同(提供商承诺的价值和级别),但框架和元数据模型保持不变。

  在上面的示例中,我们利用了 2 个标准化核心组件:数据质量和访问。目录和数据合同中的数据产品描述都以相同的结构(Schema)定义了工件的两个方面。现在,业务流程中所需的元数据至少有两部分定义相同,并且不需要转换。理想情况下,数据质量和访问组件元数据定义一次并在数据合同、数据产品和数据协议中重复使用。

0
相关文章