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

一、指标是什么

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

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

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

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

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

二、指标的基本构成

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

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

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

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）

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

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

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

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

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

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

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

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

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

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

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

最后

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

#相关阅读#

中台实战（0）：最近处处惹人爱的中台到底是什么

中台实战（1）：看懂企业业务演进路线

中台实战（2）：中台的建设核心原则

中台实战（3）：数据中心中台化案例

中台实战（4）：业务的抽象建模

#专栏作家#

三爷，微信公众号：三爷茶馆，人人都是产品经理专栏作家。曾万达高级产品、MBA特约讲师、独立创业者，现某支付公司产品线负责人，拥有多款集团项目从零到一经验并带领实现商业化布局。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议