Ventana Research｜是时候把指标中台纳入企业数据架构了！

Posted 2023-04-05 Kyligence

近日，Kyligence 秋季线上论坛成功举办，来自领先的市场研究和咨询机构 Ventana Research 的 David Menninger 发表了主题为 Add a Metrics Store to Your Information Architecture《把指标中台纳入企业数据架构》的演讲，希望对大家有所启发。

以下为演讲实录

大家好，我是来自 Ventana Research 的 David Menninger，有 30 多年数据分析的从业经历，非常高兴能够与在座诸位分享我们研究的成果，帮助大家及时掌握最新的技术动态。

今天我想从下面这张图开始我的分享。大家可以回想下，目前在企业里，指标管理、分析战略和数据战略之间的联系真的紧密吗？很多企业关注数据战略、数据模型、DataOps 等，但是却很少真正聚焦指标及管理。接下来，我将从数据和指标之间的关系开始，分享什么是指标中台、以及企业为什么需要指标中台。

 

1. 研究背景

作为一家独立的分析机构，Ventana 在进行调研时收集了来自数千家企业组织的反馈及其各种技术的使用情况。今天引用的各项信息主要来自于我们的分析和各项数据基准、数据治理基准。我们希望这次研究能尽量全面地代表各类机构，所以也收集了来自不同规模、不同地域的各类公司的信息。

指标无处不在，如大家熟悉的总销售额、员工平均收入、资源利用率等都是指标。相较数据而言，指标被赋予了业务价值，是量化的度量，企业可以通过指标来衡量和评估某项正在进行中的任务进度。

有些指标可以基于原始数据获得，但大多数需要基于不同数据的组合，比如通过数学公式对数据进行计算，其中有些计算可能相当复杂，甚至需要基于数据进行预测。例如在房地产行业，你可能需要预测一座大楼的入住和出租率，针对每个单元的入住和出租率，再对利率和维修费用进行假设，然后将其代入一系列的公式，得出该出租物业的预期盈利情况。

指标本身包含了数据计算的含义，同时也将目标和数值联系了起来。比如在还没有定义相关目标的情况下，数字 7 本身并不具备特殊意义。但是当我们加入目标和定义后，数字 7 就有了意义，我们可以判断 7 是好还是坏。如下图所示，如果它在绿色区域，那就是表现还不错；但如果在黄色、橙色或红色区域，那可能就有待改进。为了确保目标和指标能在组织内共享，以及理解目标和指标的关系，指标和目标的定义就尤为关键。

 

那么新的问题来了，企业该如何存储这些指标?

很多企业会把指标存储在数据平台上，比如关系型或非关系型数据库。如果是关系型数据库，的确可以实现在组织内广泛访问，不过使用的表达式将受限于 SQL，或者说复杂的指标计算只能在数据库之外完成。如果企业用的是非 SQL 数据库，确实可以更轻松地修改业务模型，但所用的表达式语言就会比较难与组织共享。

当然，也有一部分公司会将大部分指标存储在 BI 工具内，BI 工具支持较丰富的表达式，但是这些表达式又只能在这些 BI 工具内部使用，很难与其他工具共享，如果企业使用多种 BI 工具，共享就更难了。当然，也可以选用数据工程工具，把这些表达式写进数据管道中，计算完成后，组织内成员就可以访问。但这也意味着要提前进行预计算和存储，当用户访问的时候，这些数据很可能已经过时了，甚至还可能造成数据库的“爆炸”。

 

另外一个选项是使用计算引擎、语义层、其他 OLAP 技术。这些解决方案的确支持企业内的共享，并且还提供了一个通用的抽象层。美中不足的是，这些方案缺乏目录管理和协作功能，但对于企业而言，这些能力又非常关键。

近几年，有一些领先企业开始考虑选用指标中台。指标中台是对计算引擎的进一步拓展，增加了目录、治理、协作、API 等能力，稍后我也会提到 API 为什么很重要。那究竟什么是指标中台？大家可以把指标中台理解成是一个指标的集市，它存储了之前提到的各项规则、定义，如何进行计算，以及对齐指标相关的各项目标。构建指标中台的目的就是为了能轻松在组织内分享这些指标，并相互协作。

2. 什么是指标中台

指标中台包含计算引擎，可以帮助企业计算这些指标背后的各种数据，同时提供一个可供访问指标的方式，比如各种 BI 工具等。除了目标、计算表达式，指标中台还应包含由指标引擎带来的目录信息。

 

指标中台能够帮助业务人员找到相关数据和指标。不过，随着各类分析应用变得越来越复杂，某些分析可能要被嵌入到某些应用中，然后再被进一步嵌入到其他流程中。我们需要通过 API 完成这些嵌入，以便实现流程的自动化，不再需要人工参与，因此 API 已经成为满足这些需求的必要条件。

企业通过构建指标中台来管理数据和指标，这样就可以有一个框架来管理各项规则，比如谁可以访问，谁可以修改这些规则，这也是指标中台重要的一部分。既然需要指标中台来完成这些计算，那就需要保证所有指标的性能和可扩展性，随着组织成员开始访问指标中台，它就应该能为大家的指标查询和计算需求提供交互式的响应。

前面提到了治理，我们再来了解下为什么说指标治理和数据治理很重要。在没有指标中台之前，大家会把数据存在各处，比如数据库、数据管道、各种计算引擎、BI 工具等。其实在架构设计之初，企业就应该考虑在其中加入治理。据 Ventana 调研，数据的治理程度与数据分析的满意程度高度相关，受治理的数据更容易得到分析人员的信任和使用。

3. 指标中台的价值

我们在数据治理相关研究中发现，53%调查对象都将指标加入了数据目录，但只有 43% 真的在进行治理，这就是所谓的断层，也就是这件事情的重要性和实际达成的效果之间的差距。另一方面，对指标的治理可以增加人们对数据的信任，与数据的可信度相关。46% 左右的受访者在面对经过治理的指标时，相信他们的数据是可信的，在面对未对指标进行治理的情况下，只有 15% 的机构认为他们的数据是可信的。

 

那如何让人们参与治理呢？方法之一就是数据目录，数据目录是数据治理中的重要一环，它让治理变得更容易接受和执行。通过指标目录帮用户找到所需的指标后，用户更愿意参与治理，因为这将帮助他们看到谁在访问这些指标数据及利用率如何。而参与治理的好处就是能更轻松地找到自己需要的信息。

90% 左右的组织都认为数据目录是他们数据治理中的重要一环，但如果其中不包含指标，数据目录的价值就会大受影响，这里不妨回想下我们刚刚提到的那个数字，只有 15% 的组织信任他们的数据。因此我认为治理指标远比治理数据重要，如果没对指标进行治理，其实也就是没能对组织内最重要的信息进行治理。

 

接下来我们再来谈谈协作，数据分析是一项团队活动，极少会完全由一个人来完成全部的分析工作，也就是说由同一个人负责数据的访问、准备、计算，基于计算结果的决策以及决策的执行。既然如此，企业就需要一个中台来分享这些信息以及协作。

 

我想再次强调下，围绕分析和指标进行协作远比只围绕数据进行合作更重要。我们曾问过受访者，你认为协作有多重要？超过 2/3 的受访者，也就是图上的两块深色区域的受访者认为协作是数据分析中的重要一环。

4. 建议

以上我们谈到了很多与指标和指标中台相关的信息，现在我来简单总结下，同时给出一些个人建议。

 

对于企业来讲，指标可能比数据更重要。指标管理不存在捷径，企业想把分散在数据库、数据管道和 BI 工具中的数据和指标收集，就需要考虑在现有信息架构中加入指标中台。指标中台是企业聚焦指标管理的重要方式，在企业信息架构中加入指标中台后，将有力推动公司业务的提升。

指标中台要能被组织广泛访问，让信息在公司内得到更广泛的访问、更好的治理，并能带来更高的一致性；同时，它的架构要切实可行，支持高并发和高可扩展性，能满足组织内的所有访问需求。

感谢大家参加本次指标中台的分享，并希望通过这次分享能让大家开始思考如何将指标中台融入信息架构。

Kyligence Zen（预览版）现已开启试用，欢迎您点击链接申请试用。

中台实战：数据指标体系创建思维

在前面的中台实战系列文章中，我们已经详细地描述了中台战略的建设目标与企业发展演化方式，以及一个数据中心中台化演进案例，到了这篇文章我们开始来聊一下如何去为企业业务量身打造一套指标体系？为后面的数据中台建设思路学习打好基础。

一、指标是什么

首先我们需要搞清楚指标的定义。

提起指标这个词，每个人似乎都可以说出几个指标，像经常在工作中会听到的日活、月活、注册率、转化率、交易量等。

但是又有几个人真正知道指标的定义是什么呢？

事实上指标就是用来量化事物的一个工具，帮助我们去将一些抽象的事件得出一个轮廓上的描述。

例如我们通过日活能去判断出我们整个产品的用户量，从而能反应出我们这个产品的一个健康程度，也就是否处于增长过程中？

二、指标的基本构成

谈完了指标了定义，那我们具体来看看指标这一事物它要怎么描述，也就是我们要如何去定义一个指标。

首先我给大家一个指标的构成公式：

指标 = 业务维度描述 + 技术维度描述

Part1 业务维度

业务方为了业务需求进行定义的，也就是大家日常听到最多的数据需求，例如：

• 我要看商城复购率；
• 我要看产品的日活；

这里我为大家总结了业务维度必须要描述的字段：

Part2 技术维度

该维度也就是技术同学为了实现而必须了解的内容，下表是我为大家总结的技术维度必须要描述的字段：

三、指标体系的寻找方法

掌握了指标的定义后，接下来在日常的工作中我们需要做的就是根据具体的业务去寻找他的监测指标是哪些？

那么通常来说我们可以用以下两种思路去寻找指标体系。

• 自上而下（Top-Down strategies）：由业务驱动进行指标设计；
• 自下而上（Bottom-Up strategies）：由现有系统的功能模块逆推功能指标；

Part1 自上而下（Top-Down strategies）

这种模式下我们需要创造一些指标来反应问题，很多问题我们是没有办法用直接指标统计出的，我们需要发挥创造性去定义一些间接指标从侧面来反应问题，如当国内疫情逐渐控制住后，作为世界中的重要经济引擎，世界想要了解时下中国的复工情况，而此时我们不可能去逐家公司去问他们的复工情况，为此我们就需要使用一些侧面指标去反应复工情况：

指标1：通过二氧化氮排放量情况来反应复工情况

我们知道在日常的生产生活过程中，大多数制造企业的生产过程中与城市汽车运行中都会排放二氧化氮，那么我们可以将二氧化氮作为一个经济活动的侧面反应物。

前段时间美国NASA的卫星图像帮我们在疫情前后就二氧化氮排放量做了个对比，先是武汉地区的二氧化氮排放出现急剧减少，此后全国的二氧化氮排放逐渐出现下降。而空气中二氧化氮程度的下降与限制交通和工商活动的时间相契合。

我们不能推断出这与在疫情期间实施严厉的防疫隔离措施有关，尤其是重工业等部门生产受限，私人驾驶汽车出行减少等。因此我们可以通过监测二氧化氮的排放量这一间接指标来观测中国经济的复工情况。

指标2：城市拥堵指数

除了通过二氧化碳监测，在日常的经济生活中，我们还有一个非常常见的指标，就是城市拥堵指数。

我们通过百度地图发布的数据可以看到，根据春节假期结束后复工首月( 2月3日至3月1日)各城市的拥堵数据分析显示，全国拥堵排行TOP10 城市为：上海、北京、杭州、南京、天津、兰州、大连、沈阳、石家庄和济南。排名第一的上海市，通勤高峰拥堵指数为1.1902，较去年同期下降28.89%。

有了这个对比，实际上我们就能找到疫情前后，经济运作体系中的一个侧面反应物，我们只需要对比疫情前后拥堵指数的恢复情况，就能很快速的得到经济复工水平。

以上两个指标其实就是领域驱动设计中一个正向的思维方式：

业务域->需求域->实现域

第一步：完成业务域到需求域转化

我们将实际的业务找到其构成点，如上面的案例中我们将经济复苏这一大的业务细分成经济复工情况，再将经济复工分解为企业复工与日常消费情况。再将企业复工细分为企业生产恢复率，日常消费细分为日常生活恢复率。

最终抽离出如下的需求域：

第二步：完成需求域到实现域定义

在这一步，我们根据细分下来的实际需求目标去寻找能够反映这些目标的指标，如我们将企业生产恢复率定义为企业生产所带来的二氧化氮排放量。将日常消费恢复情况以市民的日常出行拥堵率进行衡量，最终完成了真正监测中我们需要看到的具体指标的定义。

由于这种方法我们找到的指标往往都是间接性的指标，因此我们将这种自下而上的指标寻找方法也称为为侧面指标寻找方法。

Part2 自下而上（Bottom-Up strategies）

在指标找寻的过程中，我们除了非常复杂的去根据业务的情况进行指标的寻找与创造之外，我们还有一个相对简洁的方法，就是根据现有的系统进行指标的寻找。

众所周知，我们系统的所有功能。是为用户而服务的，那么我们在指标设计过程中就可以理解为用户对于功能的使用情况，就反应了用户对于该系统模块是否接纳，因此我们可以通过各个模块中功能触发情况来进行指标定义。

这实际上就是领域建模中一个逆向的思考方法：

?功能域->需求域->实现域

第一步：由系统功能大纲推导指标需求

我们将系统面向用户做提供的功能都罗列出来，如审批系统中我们有审批发起、审批附件添加、审批人审批、审批状态通知这几个功能。

根据如上几个功能我们可以定义出如下的监测的指标范围，如使用审批频率，审批成功次数，审批耗时等，这一步需要我们尽可能的穷举所有指标。

第二步：根据如上指标去筛选我们所要的指标

通过在上一步我们穷举出了该模块所能统计的指标范围后，也就是说我们想看的数据只能在这个全集范围内了，因为如果超出这个范围系统是不支持的。

这个时候我们就可以根据我们的需要从中去挑选所要的指标，组成我们最终的指标体系。通过这种方式我们能很快的定义出指标范围，我们不需要额外去思考侧面指标仅仅是以当前系统模块所能支持的范围出发。

而事实上日常工作中，我们经常会以这两种方式同时进行，我们先找到某系统模块所能支持的指标，再根据我们的需求去额外定义一些侧面指标，从而完成我们整个指标体系的搭建。

最后

值得注意的是指标体系的建设是一个非常复杂的过程，在运用本文的思路前，我们必须知道指标体系建设的一个重要前提是必须要搞清楚自身的业务与业务的目标，否则我们搭建出的指标体系都是空中楼阁，无法对业务起到真正的指导作用。

转载自：中台实战（5）：数据指标体系创建思维