指标管理系统从0到1，从规划到落地，这篇文章手把手教会你
假如你所在的企业业务发展迅猛，在强调用好数据的当下，如果没有好用的系统，肯定都会逐渐碰到如下问题：
- 不知道有啥：企业数据资产多如牛毛，但知道和找到对的数据却困难重重；
- 需求满足慢：搞清楚自己该要啥该找啥，你会发现公司业务多变化快，需求多，取数人力不足；
- 指标对不齐：数据变更快，变更记录不及时，数据来源多、数据处理人员多、口径多，多份数据对不齐；
- 问题排查慢：系统数据出问题，数据加工链路长，碰到人员流动和交接，问题排查慢，修复耗时长。
发现数据问题，定位数据问题，解决数据问题，经常搞得基层员工焦头烂额（如果你在基层干过，真的而是叫天天不应叫地地不灵）。千里之堤溃于蚁穴，这些看似不起眼的小问题，慢慢就会积攒成大问题，甚至会严重影响到整个组织的日常工作、战术目标达成、战略愿景的实现，落后的生产力和需求严重不匹配时，当非技术出身的管理层、领导层都能感受到问题的严重性时，于是，就可以从上而下开展轰轰烈烈的优化治理专项。
这种企业信息化升级，往大了说，可以说是数据治理、数字化转型之路。一般来说，大家说的都是构建高效智能的数据中台，数据治理可能也提上了日程。数据治理的核心是什么？核心是统一数据口径。数据口径的抓手就是【指标】。
从产品的视角来看，指标管理最终的目标是：让大家能清楚看到、方便用到。
一、前期规划
市面上关于【如何建立指标体系】的方法论一搜一大堆，相对而言，讲如何构建指标管理系统的少了不少，不过只要耐心搜寻，大厂的竞品就等着你发掘，而且文档还比较全。等你拥有了这些参考信息，系统就实现了80%了，因为功能和界面交互都很好抄，就差工程师帮你把系统开发出来了。
但其实指标管理系统想做好并不容易，因为可能做完系统，进行指标管理落地时，更多问题会凸显出来，尤其是在业务已经发展起来的阶段。
作为一个有很多失败经验的老产品，接下来给你分享一些微不足道的经验。
第一，你要定位问题。
你要搞清楚，这个系统到底要解决什么问题，现状是怎么样的。谁在推动做指标管理、指标治理这件事情。
很多时候，推动这件事情的人，是带有研发背景、数据分析背景的领导，而这些领导规划做这件事，也不是很清楚呢。或许是因为看了一场其他同行的分享，被案例里的故事给说服了，然后开始未雨绸缪提前规划这件事情。但是，在你规划系统去解决问题之前，问题真的被定位了吗？可能也不好定量描述问题有多严重，当前的损耗有多大，那是否有人定性地进行了描述呢？
领导对这块问题的认知是什么，如果没啥认知，让我们解决的问题是什么呢？你可以把这些问题抛出来，问那个任命你来做这件事的人。这个问题是否在更高的层面拉通了认知，能争取到多少解决问题的时间窗口，多少资源。
世人都晓神仙好，惟有功名忘不了。“做好数据治理，科学管理指标，数据驱动业务”，大家都会喊口号，为的是做成之后拿好处，可是真正能落实的人，并不多。很多时候，我们不敢提问，不敢抛出问题，组织让我们做什么，我们就一股脑去做了。当这些问题并未暴露出来，我们都不清楚价值、意义就贸贸然开始做，那最后谁来认可咱们解决问题的价值呢？
第二，你要有抓手。
当你搞定了第一个问题定义和价值问题，你准备开始做了。而真正想要落地，你必须从全局出发，做一步，脑子要往后多推演几步。你要思考：假如我们要按照敏捷迭代的方式去做，第一个版本MVP应该是什么样子，我们要针对什么样的问题场景交付什么内容，用户能做什么样的应用。做这个系统的价值到底应该如何体现。
内容层面，你要考虑，应该将哪些指标纳入管理范围，这些指标怎么用起来？指标数据从何而来。应用层面，应用的场景是什么？ 单纯地看指标的口径，还是说要快速地取指标数据？价值层面，如何评判这些指标真的被业务用起来了？ 用户查询了多少次，用来做了多少次报表？我们要对自己掌握的信息有个把握。当下我们现在掌握了哪些信息，比如，现在，已经有哪些指标做成了看板了，哪些指标还没有。其次，还想掌握哪些信息？对于未来也要有所考量，公司的战略层面还有哪些业务，粗略情况如何，是否需要指标分析，这块我们只能基于业务情况进行粗浅的预估。
总的来说，动手之前，花个1-3天时间，深度搜集信息，制定策略，谋定而后动。
二、准备工作
作为一名数据产品经理，你要面对的是关注数据结果及其呈现形式、但不懂技术或者没空关心技术的业务方。99%的人，尤其是做业务的人，不会关注数据怎么来的、数据怎么加工的，大家只会关注数据结果，取结果若碰到问题，直接会把问题抛出来让技术人员解决。
当我们发现在线表格已经无法满足公司管理需要时，我们开始规划指标管理系统。你要做几点：
- 洞察业务需求、目标用户习惯、明确系统价值；
- 了解组织的管理要求，设计人机交互和底层数据系统；
- 协调技术人员，传递需求场景，完成系统建设；
- 切入业务场景、运营和推广系统，并最终让业务用起来。
业务可以组合各种维度、修饰词、时间周期，自己设置查询条件。指标取数核心功能：能支持用户基于维度进行指标的挑选，然后进行即系查询，并能下载指标结果。后台系统需要做的就是，管控这些用户对应的维度、修饰词、时间周期的使用权限。
选择指标的界面可以参考如下：
选择完维度和指标后，可以在取数界面点击查询进行取数。
指标取数的产出结果案例如下：
如果还能跟BI系统打通，支持各种关联分析，比如，针对某个指标，制作折线图、柱状图，如果还能加上趋势预测等等自动分析功能，那就更好了。
对比指标取数，标签取数的道理是相同的。不过，标签取数的结果，都是人数。我们需要针对这群人，再进行下钻分析（后面再讲）
2）指标查询
指标查询，可以理解为一个商场的指引台。
当你到了一个大商场，你会不知道目标店铺在哪里，当你转得晕头转向的时候，有个向导告诉我们目标店铺在哪一层，哪个方向（左拐、右拐、直行，别讲什么东南西北）
指标查询也是如此，它能在以下几个场景发挥作用：
- 当你晕头转向时，告诉你系统中现在有哪些指标，对应的负责人是谁。
- 当你没指标权限时，基于系统反馈的指标负责人信息，你可以通过IM系统，找到对应的联系人。
- 当你发现数据有问题，指标有错误，系统有故障，你可以找对口的负责人进行排查。
比如，当你看到近1天观看时长这个指标，这个时长的单位是什么呢？如果指标的名称上没展示，那就可以通过指标的详情来了解，是小时，还是分钟，还是秒。
再比如，人均观看时长，分子分母分别是什么？分子是观看时长，那分母是平台近1天的全部活跃用户，还是有观看行为的用户，还是有有效观看的用户呢？这也是需要解释的。
比如，我们可以在数据地图中，让用户快捷查询指标。
当然，我们也可以直接在取数的界面进行必要信息的展示和提示，这样就不必要再到另外的界面去查询。
对于业务来说，这种系统越简单越好，需要跳转的页面越少越好，甚至可以结合NLP系统对业务使用的业务语言，转化为技术语言，然后进行取数。
比如问，我想知道最近元梦之星的直播情况，请告诉我有哪些维度和指标。并直接帮我取数，按照Excel的形式给出结果。然后系统自动判断并执行即系查询操作，并按照Excel格式给出。
不过，如果系统底层数据没做好治理，也没积累案例，实现难度比较大。更加关键是，中型公司落地一个模型的收益，能不能覆盖投入的成本。
2. 用于后台管理的功能
设计完了面向业务应用的功能，接下来，我们再考虑用于管理、支撑的后台功能。
首先问自己一个问题：MVP阶段，需要复杂的管理功能吗？需要什么样的数据支持呢？回答这个问题，需要有点技术背景，但如果你不懂技术其实也没问题。
第一，指标能取数，那肯定需要有数据源，第二，业务人员进行的各种取数条件的设置，可能要能转化为从数据源里取数的语言（取数脚本）。
这里需要两个东西：具体的表数据（数据源）、以及解释取数配置的东西（生成取数脚本的逻辑）。有了这两项，只要提前在代码里配置好，哪怕没有管理功能，用户在界面上的操作也能取到结果。而设计功能，当我们的底层表、指标、维度、修饰词等等信息变得庞杂以后，能够更加方便地查询、管理。
接下来，我们再来看，要有哪些功能。
1）原子指标管理
这里，基于原子指标是否要指定来源的事实表，可以区分为两种做法。抛开这个点，我们先说公共的部分。
解释一个原子指标，需要告诉使用者：指标的中文名称、英文名称、指标的单位、指标的业务含义、业务的负责人。除此以外，我们还可以对指标进行分类，包含业务域、主题域、业务过程、数据域等。（我不建议划分太细，划太细其实也挺难找的）
接下来，我们再说两种不同的做法。
第一种，原子指标指定来源事实表。
这里，核心就是要指定指标的字段，是基于数仓中的哪个事实表中的哪个字段进行何种计算，最终的出来。
衍生指标 = 维度 时间周期 修饰词 原子指标。
那么，当我们构建了衍生指标之后，我们是能够通过维度反向筛选有哪些可选的衍生指标的。
3. 指标管理功能总结
看完了这么多，感觉很复杂，是吧？化繁为简。先抛开修饰词、业务域、数据域，只关注指标和维度。我建议你从SQL（结构化查询语言）的角度去重新理解指标管理。
为什么数据产品经理要懂点技术，我认为核心是要懂点SQL。因为懂了SQL，才能从SQL（物理模型语言）的角度去理解这些一切一切。
其实SQL也不用掌握太深，只要看懂最简单的代码就够了。我们看看下面这段语句，其含义是：统计2023年12月12号当天不同支付类型的订单数量。
select dt as dt, pay_type as pay_type, count(order_id) as cnt from dwd_order where dt = 20231212 group by dt, pay_type
假如我们的支付方式有两种：wechat和alipay，那么最终的表格会如下：
看完SQL，我们再问问问题。
在SQL里维度是什么？在哪里？维度就是对应的group by的字段。这个字段是可以来源于事实表的主键，也可以是事实表关联维度表后取得维度表得字段。
指标是什么？在哪里？是count(order_id）吗？不，如果你只往查询系统里输入count(order_id），系统是没有执行结果的。只有当你指定了表，表取数的时间范围（时间周期），指定的维度，才能取到结果。如果不指定时间范围，那就是整个表全部的范围（也就是从有这张表的那天起的全部数据）。如果不指定维度，那就是全维度（也就是所有的订单总数）
如果，我们从刚刚的结果表里取数呢？指标是什么？
我们不需要定义count(order_id)了，我们的SQL可以这样写：
select dt as dt ,pay_type as pay_type ,cnt as from dwd_order where dt = 20231212
这就是为什么指标能有两种管理办法。因为不管哪种，只要最终生成的SQL能从物理表里取到正确的结果就行了。当你理解了SQL是如何取数，如何描述指标，那你就能理解为什么要构建所谓的原子指标管理、衍生指标管理、维度管理。
五、产品运营
1. MVP阶段就要考虑后续运营
前文说到，要MVP，要基于场景、用户需求去初始化我们的最小可用产品，第一个版本我们为了快速产生价值，很多地方是简陋的。但你要时刻牢记，正是因为舍弃，我们才有获得。
这套系统，相当于是将之前的业务提需求、开发开发报表的流程，进行了系统化，并且记录了过程信息（也就是指标、维度、事实表等等对象的元数据），当这套管理体系和对应的系统建设完成时，后续只需要进行日常的运营和维护。
当我们的产品功能上线以后，接下来就进入新的PDCA循环了，Plan（计划）、Do（执行）、Check（检查）和Act（处理）。不仅可以对系统的内容（数据资产）进行进一步的丰富，在交互和用户指引方面，也有很多工作可以做。
2. 在问题中迭代系统
当然，你也会面临一些内容和功能层面的问题。
比如，业务方希望你能在指标取数中增加新的指标。而这需要开发新的底层表，录入指标数据，直到丰富整体的指标体系。比如，当指标过多，用户不方便进行指标的搜索、查询时，要做一些必要的指标分类、说明文档、操作指引等。
再比如，因为公司规划原因，某些业务停滞，某些数据也不再需要了。如果公司对成本管控比较严，可以从数据的实际应用情况出发，基于指标体系、数仓表血缘等，对不再使用的报表及其整个调度任务体系进行下线处理。以便节约存储和计算的成本。
总而言之，这套系统完善之后，能解决50%以上的规范化的取数、看数问题就不错了。而针对特定场景的分析，还需要人工来支持。人工智能，先人工，才能智能。
当然，问题是解决不完的，人的需求是满足不完的~
六、总结和未来展望
1. 总结
从规划的注意事项，再到落地的功能规划和涉及介绍了很多，大致上为你描绘了指标管理。
不过，我想提醒你，那些能够落地指标管理的企业，都是天选企业，它们汇聚了优秀人才，跟随着时代的发展，基于技术和管理的创新，跨过了层层考验，在重重磨难之中成为大业务量的企业，拥有真正的大数据，真正地利用数据发挥价值，但凡少创了一个关，都到不了所谓数据驱动业务的阶段。
对于大多数实体业务经营型的企业来说，科学的指标管理是业务发展的助推器。数据和对应数据管理系统的发展，离不开强力的业务支撑，绝对不要为了做而做，管理指标的目标也不仅仅是为了更好地查看数据，其目标是做出更优质的决策，拿到更好的业务结果。
2. 未来展望
在生成式AI如火如荼进行的时候，我们可不可以利用AI来做更多呢？
AI能在哪些场景嵌入现有的工作流，改善当前工作流，做更加深入的落地呢？比如，业务方看完数据后，直接用语音、文字给AI发送指令，请给近30天没在平台消费的用户发送满30减5的消费券通知，并自动生成统计任务，在1小时候给我反馈通知发送的达到量、点击量，消费券的使用量，产生的交易金额。
人还是做主导，但是基于数据做决策、做动作、回收数据的整体链路更加高效。长路漫漫，道阻且长~
以上，感谢阅读~
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！