2023：数据协同的崛起（中）

凯哥出品，必属精品

（全文5530字，阅读约15分钟）

前言

企业已经进入数据民主化的时代，如何能够在全员皆是数据用户的情况下做好数据协同，成了所有企业面临的问题。数据协同是数据治理，数据利用的基础，协同做不好，会导致数据价值流的中断，各种浪费。

企业过去更多关注于数据生产和加工

对于数据协同缺少应有的重视和投入

精益数据方法论强调打造从数据源到数据产品的价值流的加速，数据协同创新是精益数据方法的六大能力之一。

前文阅读：2023：数据协同的崛起（上）

本文目录：

1.数据用户需求画像

2.数据用户痛点分析

    企业数据协同的目标是所有的数据用户能够打通全链路、全要素、全价值，构建高度自动化、闭环的数据加工应用，打造一站式数据生态环境。所以要想更好地协同，首先要梳理清楚这个协同链路上都有哪些用户，这些用户都有什么数据需求。

    按照企业数据的全生命周期价值链，数据用户主要分为 4 类：数据产品消费者、数据产品生产者、数据处理加工者、数据管理者（生产和提供者）如图6-4所示：

图6-4 数据用户的四大类型

    每一类用户又可以进行细分，从而形成企业数据协同的用户画像大图，如图 6-5 所示:

图6-5 企业数据协同用户大图

    1.数据产品消费者

    数据产品消费者是指数据产品的最终用户，一般可再分为两类。

    第一类是直接使用数据产品获得最终业务价值的业务人员，他们通过阅读或查看报表、指标系统、管理驾驶舱等数据产品的数据，获得信息，帮助自己做出决策并解决问题。此类用户可以细分为以下 5 种。

（1）决策层用户

    决策层用户指企业的领导层，他们主要的需求是掌握企业的全面、重要的运营数据，及时洞察企业的风险，帮助企业做出决策。在企业数据自服务门户里，他们可以直接看到决策所需要的指标体系、报表等。

    这类用户的特点是数量少却非常关键和重要，一般不太懂技术，时间很宝贵，他们希望一眼能看到重点。这类用户在企业数据自服务门户中应该是最特殊的，数据产品要针对每一个个体做个性化的设计和服务。

（2）管理层用户

    管理层用户一般指各职能部门、业务板块的管理层，他们在数据自服务门户里不仅需要看到指标体系、报表，还要看到一些向下分解的指标，可能还需要自定义查询功能。

（3）产品经理

    大部分产品经理都是数据产品消费者。比如说，他们在设计并开发产品的过程中需要清楚地知道企业已经有哪些数据集，有哪些数据服务，以及有哪些数据可视化工具可以调用，从而在设计产品的过程中避免重复设计，避免由于数据的不一致产生冗余二次数据。

    总的来说，产品经理是数据自服务门户的最大的业务用户群之一，他们需要根据自己的业务需求、产品需求在数据自服务门户中浏览、探查、发现自己所需要的数据产品，然后判断这些数据产品是否可以复用，是否需要对数据产品开发团队提出新的需求。

（4）业务分析师

    业务分析师对数据产品的需求和产品经理类似，他们往往需要了解更细节

    的数据情况。比如这个数据产品的数据源是哪些系统，取数和计算逻辑是怎样的，从而更准确地做出业务分析和判断。业务分析师消费的数据产品的主要形式是数据集和报表。

（5）业务运营人员

    产品上线以后需要持续地运营，这个过程需要大量的数据支持，比如各类用户数据、订单数据、行为数据等。业务运营人员根据业务目标对这些数据进行持续分析，提供运营的指导，再执行对应的业务动作，比如调整价格，给潜在用户推送营销活动等。业务运营人员消费的数据产品的主要形式是报表。

    除上述用户外，第二类数据产品消费者是将数据产品（数据集、数据 API、算法模型等）作为原材料组件来构建新的应用或者产品的二次开发者，比如业务开发团队使用数据团队提供的数据集、数据 API 和数据模型来构建新应用。

2.数据产品开发者

    数据产品开发者主要指需要开发报表、指标体系、数据集、数据模型等数据产品的用户。一般来说，数据产品开发者分为两类：业务型开发者和技术型开发者。

业务型开发者是指在数据产品开发过程中专注于业务需求、业务分析等方面的业务人员，包括数据产品经理、数据运营人员、业务分析师等。这类人员的特点是不具备编程能力，不具备专业的数据处理技能，但是熟悉业务，知道业务的目标，了解业务与数据的逻辑，所以他们能够使用熟悉的数据开发工具和方式来生产对应的数据产品，比如利用查询工具、可视化工具、Excel 来对数据从业务层进行解读、开发，使其形成新的数据产品。

技术型开发者是指用专业的数据开发工具进行开发的技术人员，一般包括数据科学家、算法工程师、机器学习工程师等。这类开发者基于已经处理、清洗好的数据集，利用算法、建模工具来对数据进行开发，成果是数据模型和算法，主要使用的工具包括 Jupyter Notebook、MATLAB 等。

3.数据加工处理者

我们可以将所有数据加工处理者统一归类为数据工程师。

数据工程师在源系统中对数据进行探查、获取、计算、建模、存储、挖掘、验证，最后将加工的数据集以数据立方体、数据宽表等形式提供给数据产品开

发者使用。数据工程师一般需要具备软件开发能力，能够熟练地使用数据工具，或具备软件编程技能，能进行 ETL 开发。

4. 数据管理者

数据管理者主要是源系统的数据工作者，他们负责设计业务软件或硬件的数据结构、数据模型，然后用应用系统将数据存储起来。数据提供者同时负责对已经生成的数据进行备份和恢复，从而确保数据的安全。

将企业数据用户的重点需求汇总成需求矩阵，如图 6-6 所示。

图 6-6 企业数据用户需求矩阵

    不同的数据用户，有不同的痛点需求，要针对性的制定解决方案予以解决。

数据团队的痛点

与数据产品生产关系最紧密的角色是数据团队，它可以分为 4 类：数据管理团队、业务团队、数据分析团队、数据工程团队。不同的团队的痛点不一样。

1.数据管理团队的痛点

数据管理团队肩负着统筹管理企业数据资产，挖掘和度量数据价值，保证数据产品和数据相关系统平台的稳定运行的职责。数据管理团队面临如下痛点。1）数据资产统筹管理难。企业的数据资产越来越多，种类越来越复杂，并

且越来越重要，如何全面、安全地统筹管理数据资产，既要让所有人能够便捷地访问和利用数据资产，又要保证安全合规？这是数据管理团队的首要需求，也是最大的痛点。

2）业务价值度量评价难。如何评价数据产品的价值，特别是那些不能直接销售的数据产品的价值，是数据管理团队面临的第二个痛点。需要一种模式让数据和数据产品的价值显性化、具象化，让业务用户和企业管理者感受到。

3）数据管理工作烦琐。数据团队越来越大，每天的工作任务很多。工作的状态如何，进度是否符合计划，是否有风险，有什么困难和挑战，也是数据管理者关心的。只不过当下更多是通过开会来解决这些问题。数据管理者需要一个全景视图，全面了解团队的关键项目、任务执行情况，以及数据相关资产的利用情况和风险情况。

4）业务需求反馈协调慢。业务部门中，数据产品消费者对于数据产品的反馈如何？有什么问题？是否能及时解决？过去这些反馈在事后才能获得，往往以投诉的方式获知。但是数据的加工生产本身都是在线的，所以完全具备实时监控和沟通的条件。

2.业务团队的痛点

数据已经成为业务团队工作的必备方法和工具，但是大部分业务人员都不是技术或者数据相关专业出身，仍然需要借助数据分析和技术团队来实现数据需求。但是企业的数据利用链路往往很难给业务团队提供高响应的支撑，主要体现在如下 5 方面。

1）找不到数据。业务人员经常面临的问题包括不知道公司有多少数据，不知道这些数据在哪里，想看数据却不知道如何获得，数据管理流程复杂冗长等。业务人员纵使有很多的业务需求和想法，还是会因为繁重而封闭的数据管理体系望而却步，最后只能放弃。

2）缺少业务型分析工具。业务团队虽然有很多的数据报表，也有专业的数据分析人员，但是很多时候针对个性化的需求，也希望自己能够直接快速地做一些简单的分析洞察。但是大部分企业缺少友好的业务型数据分析工具，导致很多企业有超过 50% 的数据分析都是在 Excel 里进行的。

3）数据分析质量差。由于数据口径、数据质量的问题，很多数据分析的结果不准确。业务团队与数据团队对同一个数据的理解不一致，又带来巨大的沟通成本，并且导致数据描述不清晰，数据分析效果差。

4）数据开发响应慢。业务对数据的需求总是比较紧迫的，需要被快速响应，但是数据开发团队的响应往往比应用开发团队的慢很多，这主要有两个原因：一个是业务团队与数据开发团队对数据需求的理解很难对齐，需要多次尝试验证才能找到最终正确的数据；另一个是企业数据开发团队的能力与应用开发团队相比，尚不那么成熟，缺少标准、统一的工具和流程。

5）应用上线慢。数据应用的上线和业务应用不一样。在上线之前，数据的接入、迁移、验证、测试需要大量的时间，接入数据越多的应用，上线过程越复杂。并且，数据应用的问题追溯比较困难，所以数据工程团队一般很难提供明确的 SLA（服务等级承诺）。

3.数据分析团队的痛点

数据分析团队现在成为很多企业里最热门，但是也最辛苦、最有挑战的团队。往往在季度、年度结束的时候，数据分析团队更是会接到大量需求，需要通宵达旦地工作，这是因为数据已经成为所有业务的生产要素，而数据分析团队的产能是有限的，导致数据分析团队超负荷工作。数据分析团队的痛点主要有以下 5 点，如图 6-7 所示。

图6-7 数据分析团队的五大痛点

1）重复需求多。这是很多数据分析团队最大的痛点。不同的业务团队提出的需求很多都是重复的，甚至 80% 的需求都是已经分析过的。但是由于需求提出方不同、数据范围不同、理解不一致，数据分析团队就要对这些需求重新分析一遍。而且很多需求的时间要求并不像业务团队在提需求时所说的那么紧迫，甚至不少数据分析的需求完成以后，其结果并没有被使用。

2）数据定位难。业务团队只能描述对数据的需求，但是不知道对应这些需求的数据从哪个系统中获取，数据分析人员没有参与系统的构建，也不知道数据在哪儿，往往需要通过多次交叉稽核、校验才能确认数据来源。

3）数据获取难。数据分散在不同的源系统中，系统对应部门不一样，数据的存储格式、结构标准也不一样，导致获取数据很困难。据统计，数据分析团队有超过 50% 的时间花在了获取数据上，而真正花在分析数据、探索价值的时间却比较少。

4）数据产品管理难。业务部门对数据的需求很多都是重复的，但是作为支持性部门，数据分析团队只能积极响应，导致最后开发的数据产品非常多，但是缺少体系化的管理。重复的、冗余的数据集和数据分析报表及视图等都堆积在各个平台中，越堆越多，越来越难以管理。

5）工具打通难。不同的数据分析人员所使用的数据分析工具不一样，有用传统商业智能工具的，有用 Jupyter Notebook 的，有用 MATLAB 的，多种数据工具分析的结果文件需要解析转换，打通工具也有困难。

4.数据工程团队的痛点

数据工程团队负责最终解决所有数据问题，但是大部分数据工程团队都面临很多痛点，主要包括以下 6 点，如图 6-8 所示。

图 6-8    数据工程团队的痛点

（1）不确定的数据源

数据工程团队的工作对象和生产要素就是数据，但是目前企业的数据分散在不同的内外部系统中，其中很多都是遗留系统，缺少文档，缺少标准，缺少对数据结构的描述记录。于是这些数据缺少统一的规划和管理，相互不联通，使数据用户像进入原始森林一样迷茫。如何清晰地管理这些分散的、高度不确定的数据源是数据工程团队一大痛点。

（2）重复数据需求

很多数据需求从源头开始就是重复的，企业缺少全局的数据规划，数据工程团队只能以响应业务需求为第一要务，最终产生了一系列新的数据，而已有的数据利用率较低，并且使用多套指标体系，数据立方体相互矛盾，数据工程团队难以对其进行维护和复用。

（3）资产归属不清晰

企业的数据每天都在不断增长，而数据资产的管理体系跟不上，导致数据资产的归属不明确，数据工程团队在开发和维护数据资产的时候缺少标准。哪些数据应该从哪个部门去获取，哪个部门拥有对这些数据的审核、修改的权限，这些问题经常导致数据工程团队要花大量的时间去盘点、沟通。

（4）运维困难

数据的问题一旦出现，就很难被定位和修复。一个不准确的数据，其背后可能是十几年企业业务逻辑的变化，数据血缘难以梳理，数据工程团队缺少文档和知识的积累，对数据的运维非常困难。

（5）新技术鸿沟

数据技术日新月异，各种工具层出不穷。对数据工程团队来说，使用数据处理技术和工具是需要很高的学习成本的。不同的数据工程师，对数据处理技术和工具的选择往往都不一样，加工处理的过程和结果也就很难共享。建立一套经过验证的、适合企业数据架构和特点的、标准化的数据技术体系，并提供给数据工程团队使用，是数据工程团队很迫切的需求。

（6）低效沟通

数据工程团队负责最底层的数据工作，所有的数据需求最终都要由数据工程团队来实现，所以数据工程团队每天面对大量的需求提报、问题沟通。但是目前很多企业缺少有效的沟通工具，导致数据工程师们将大量的时间花在低效的沟通上，甚至可能出现鸡同鸭讲的情况，双方讲了半天，结果并不是在讨论同一个问题，或者并不是在同一个数据集的基础上进行沟通。

那么这些数据用户的问题，如何解决呢？

通过高质量的数据协同，打通数据资产， 让数据的协同生产无缝集成，价值链高效流动是根本的解决方案。