|
大多数企业数字化转型已经取得初步成果，战略方向上基本明确，组织架构上有足够支撑，系统工具上基本完成建设。不过实际的转型效果依然参差不齐，不少机构仍然存在战略与执行脱节，取数难用数难，指标口径不统一，同名不同义等痛点。
究其原因，大多数的问题都在指标上，因为指标是监控与贯彻战略的抓手，取数、用数自然也是为了计算指标，口径不一等指标的痛点，自然也影响业务监测，进而导致战略与执行脱节。
因此，数据指标能否用得好，成为数字化转型的关键，本节将介绍数据指标在行业中的应用，重点围绕下面三点展开：
 
指标体系设计框架已较为成熟，主要来源于企业战略自上而下的演绎，以及一线业务实操自下而上的归纳。基于这种设计方法，再加上底层应用和管理体系的支撑，共同构成了一个整体的经营分析的指标库。
整体的目标制定是基于公司的发展战略，如十四五战略规划、数字化转型规划等，分析战略实现的决定性因素，梳理指示实现价值的可测量数据，进而形成一级指标，或称北极星指标。
指标体系是按照自上而下演绎、自下而上归纳两个方法结合，多维多层指标框架是对整个业务板块指标的梳理，在每一个板块里面横向展开指标业务的维度，纵向基于整个指标的层级，从战略指标展开至经营管理指标、业务执行指标。指标体系梳理完毕，应用包括可视化、流程、用户交互等。指标的管理体系，需要基于管理制度、管理流程、组织职责。
基于公司业务发展战略，通过企业价值树分解，梳理企业核心关键KPI，形成指标库。战略衔接需要通过核心指标拆解成为各个部门的承接指标，但是这些指标中的维度和口径之间会有区别，这些区别是整个指标体系设计里面需要重点关注的各项标准。这里需要引入“价值树”的概念，可以理解为战略分解的关键影响因素，可以拆分为不同层次的价值流，比如绿色工厂里面可能会分解为相应的供应链，供应链里面又可以分解成为不同的价值流，包括每个环节的响应效率、每个环节执行的质量健康度、基于时效和质量产生的对应成本等。其次，这些价值流在不同业务板块都有不同的呈现方式，需要根据价值驱动因素优先级进行排列，比如目前哪些部门里面的哪些对应的价值流是需要核心先关注的。
自上而下的演绎包括制定北极星指标、建立价值树和价值驱动因素优先级，逐步拆解形成指标。例如，提升客户活跃和留存的北极星指标，可以拆成增加客户留存、提升产品销售能力和提升审批效率等二级指标，再向下可以拆成增加客户留存、提升客户粘性、提升客户忠诚度、促进交易量等子指标。
这种自上而下演绎的方法论和传统指标体系建设方式存在一定差异，传统指标体系通常是拆解到维度，而这里则注重指标上下级之间的关联。在大指标出现异常的时候，会对其下的子指标进行分析，寻找原因，而不是单纯的只看大指标的维度。
有了自上而下演绎得到的指标，为什么还要做自下而上的归纳呢？因为演绎过程中，可能为了追踪新的战略目标，而设置一些新指标，这些指标对一线业务来说是比较陌生的，因此还需要收集一线常用的指标并将其体系化，进行自下而上的归纳。两个方向相结合，形成最终的指标库。
自下而上的方法：基于企业现有指标体系
通过指标的收集、解析、整合和归类，形成指标库。也叫做归纳法，通过梳理企业现有的经营指标去归纳总结，形成相应的指标互补，最终形成一个多维、多层级、全场景覆盖的指标树。比如提升渠道能力，可能涉及很多指标，我们把各个渠道的，比如网银的、客户经理产能的指标都细分出来，归纳到体系中，形成一个结合业务维度和技术维度的全场景的指标体系框架。
指标在收集的过程中，一方面需要对一线的业务系统做收集，一方面要对当前日常汇报材料进行归纳汇总，包括定期复盘会、各级管理会议相应的资料，这些资料可以帮助去做整合归类，而整合中又会用到目前指标的业务维度、技术维度等。但是自下而上梳理的过程中，也存在不同部门之间可能会有重合指标的情况，而这些重合的指标甚至可能也会在对应口径上有出入。为了解决这种问题，最好的解决方式之一是设定业务的指标owner，不同业务的指标owner会帮助整个指标梳理的过程形成更好的聚合。
具体的指标盘点主要包括七大步骤，即通过调研访谈梳理业务条线、场景，以及业务流程和过程，覆盖所有业务条线和场景、流程，形成原子指标，进而形成衍生指标。
以供应链的采购执行为例，采购执行可以分为对整个物料需求的拆解，到需求的下单，再到供应商的对接。采购执行环节包含了不同的流程，整个信息流里面会包含单据，所以这些流程和单据帮助企业构成了一个业务环节，这个业务环节所对应的原子指标同时也可以明确出其分析维度，比如供应商的维度、对应产品线的维度、不同财务科目的维度等，这些维度可以帮助企业去拆解出来KPI。基于这样的KPI，就可以明确出计算逻辑，最终通过平台落地。
最终形成一个图谱，涵盖所有的环节，可以看到每个环节中有多少指标。如果某个环节没有指标，就说明存在遗漏，需要针对性地去补充指标；而如果某个环节指标偏多，则可能是KPI导向或者存在重复指标。这样梳理出的图谱就会比较完整，并且是基于统一价值链的。
需要特别注意“补数据”动作，不同的业务板块里面可以拆解出来相应的业务环节，以及对业务环节拆解出相应的原子指标，但是同时企业也需要去注意采取主动或者被动的方式去补充相应的数据指标。比如供应链里面供应商的管理，需要去根据现在的系统做一个比照，包括供应商的降本、供应商的配额等，这样就可以帮助企业查看哪些数据已经覆盖，哪些数据还没有覆盖。
由上至下可以分成三层，决策层、管理层和执行层。
决策层关注的人均产值、销售收入、净利润、资金周转、销售订单的情况，再往下拆解就对应到业务环节里面，包括销售拜访、订单签订流程、发货出运的流程等等。这些流程构成管理层想要的核心指标，并拆解成具体的维度，比如产品、订单、销售业务、财务等。继续往下看，这些维度会涉及到执行层里面详细的一些指标的战略体系，基于指标体系在价值流的过程中可以梳理出多维的价值动因分析，再去对相应的问题进行拆解指标，解决问题。
举一个场景的案例，比如要对目前某个期间内订单下滑明显的行业，以及对应的客户进行定位，就先要对客户的类型、当前合同类型、延期提货、以及订单状态等生命状态去做相应的监控。要注意去观察是否在某个期间内有客户的价格是明显低于红线价的，依照LTC环节，分解出一个一个价值的动因。通过这样的方式，最终可以解决在业务环节中指标体系的完整性和业务问题。
指标定义，应包括业务属性、技术属性和管理属性，特别是属主部门非常关键，需要明确由哪个部门对该指标的定义负责，当指标数值出现偏差时谁负责修正，指标管理中的很多痛点都是源于属主部门没有定义清楚。
指标库分成三个视角去看，业务属性、技术属性以及管理属性
-
业务属性包括指标含义、指标业务口径、计算规则、统计区间以及相应的统计频率。
-
技术属性包括系统的字段名称、指标数值类型、指标的技术口径等。
-
管理属性包括指标分类和属主部门(指标的owner)。
指标体系建好之后，还要管理好。首先，需求收集流程要明确，即需求谁来提、谁来处理。指标的拆分创建流程，也要定义好各部门的职责。接下来，指标的审批、发布，后期的监控和失效归档，都需要建立相应的机制。譬如，某股份制银行的数据资产平台中存在6-7个AUM指标，无法明确该用哪个，所以只好再增加一个，如此下去就可能导致指标的无限增长，因此需要一套完善的体系对指标的使用进行监控、分析和管理。
分为指标的owner、指标落地的开发者，指标管理的维护者，指标的消费者。这些不同的管理角色可以对应到端到端的指标分解的流程（指标需求收集-指标拆分创建-指标发布应用-指标归档失效）中，以及管理制度中。
指标管理的第一步是进行指标需求的收集，需要对齐业务口径，数据初探以及梳理分歧/冗余指标。在整个指标全生命周期管理的过程中，需要每一个业务部门的高层牵头去做业务指标的定期优化改进，比如可以通过定期的复盘会的形式。
将战略指标进行拆解，对于经销商的覆盖率会下沉到对每一个三-六线城市进行分析；对于库存是要考虑每一个工厂、每一个基地，每一个城市的分仓/中心仓等等。对于这些维度进行运营动作的分析拆解，比如考虑城市内的门店覆盖率，必备单品的品规数，相应门店活动的投资金额、品牌的覆盖等等。以大区负责人的视角为例，本月预估是可以4个大区达成75%，但是其中的东区整体目标达成只有70%。在这种情况下，需要去关注这些变化来分析东区。同时，可以通过看中心仓/分仓，以及不同的区域和经销商来看目前必备单品/新品库存、畅销品库存的情况等。这些库存的情况一方面可以帮助企业指导经销商大力去推广哪些品类，另外一方面可以帮企业通过经销商的视角去预测。
指标来自于数据仓库和数据集市，底层数仓/集市是如何搭建的
数仓的标准结构包括ODS层、DWD层、DWS层、ADS层。目前很多企业在使用BI等数据应用的时候，数据直接由ODS对接到数据应用，缺少了中间各层的数据加工。应用层直接读取原始数据，由于明细数据量很大，会导致应用层很慢，不同的分析师从ODS从头按自己的理解加工，也会带来指标口径不一致的问题。因此企业一定要建数仓、建集市，一层一层地建设，最后通过ADS层来服务各类数据应用。
-
DWD层：主要做清洗和落标的工作，对于垃圾数据、脏数据、空数据、不符合码值的数据会统一在这层做清洗，统一标准。同时在该层做一些维度退化，把表适度做宽。最后是做数据脱敏的工作。
-
DWS层：即汇总层，将数据汇总成服务于某一主题的宽表，不面向特定应用。
-
汇总层：表需要满足通用性，原则上不跨主题域，并且要标明统计周期，因为不同域的时效性不一样，还要避免将不同层级的数据放在一起。
如果直接从底层数据取数，那么指标的逻辑会写在SQL中。例如授信余额这一指标，业务含义是在授信额度上减掉已用额度所剩下的额度，如果没有提前在汇总层中把授信余额计算好，每个人对指标含义的理解可能不同，就会导致不同系统算出来的授信余额不一样，可能带来超额授信等风险。出现指标差异，要去查底层逻辑也会非常耗时耗力。如果把授信余额口径提前在汇总层加工好，在指做指标时只需要筛选客户类型，然后选中授信余额，就可以出指标，这样业务部门就有了自己分析指标的基础，因此数仓的良好构建非常必要。
指标主要用在BI分析，可分为4个层次，统计型、归因型、预测型、决策型
BI 分析是指标应用的主要场景，主要包括 4 种类型
即基于现在的数据做统计分析，了解现在的数据呈现怎样的特征，这是大多数客户使用BI的场景。
即了解为什么数据会呈现某种统计结果，是由哪些原因导致的，可以通过指标的维度分布查看，也可以通过下钻查看关联指标和子指标的情况。
即根据现有的数据去预测未来的趋势。现在通常的做法是通过一个项目来做，例如在金融行业里预测下个周期的不良率，或某个客户的投诉概率，在风险领域的建模，就是这样一个过程，很少能通过BI直接完成这个建模和预测的过程。当然目前有拖拉拽式的自助式建模分析平台，这是另一条技术路线。
现在能做到这一步的非常少，或者说这不是BI的定位。决策型是指当发现某业务的趋势后，直接通过接口把需要修正的业务通过API发送给业务系统进行修正，例如改一个开关功能、改限额、改属性等，整体是把BI的边界做得很大，这是不是BI的职责目前还没有定论。但这确实是指标分析的终极目标，即能够完成从分析、归因到改进的闭环，并且能够监控改进后的结果。
目前绝大多数BI都属于统计型，包括报表和大屏一类的可视化应用。
随着人工智能技术近两年突飞猛进的发展，AI for BI 这个赛道最近又热了起来，AI 在统计型 BI 中，能帮用户做些什么呢？
AI在统计型BI的应用场景中,侧重输入标准化,引导客户思路
利用大模型的能力，可以通过问答的形式，给到一些原因的提示，如果输入的内容其他人已经输入过，或者在库里能够匹配到这些度量或者维度，系统会做一些提示，也可以帮助引导分析思路。分析出来后，产品会把整个的意图和分析过程展示出来，由用户确认分析路径是不是有问题，用户也可以在上面直接去改维度和分析的度量。这就是目前FineBI在尝试的问答BI产品。
统计型BI更多的还是为你展示数据是什么样的，但不能告诉你为什么。基于这一问题，FineBI提供了数据解释的功能，可以初步完成归因和下钻。
比上图所示，可以看到2016年利润突然上涨很多，一般在传统BI中需要把该指标提出来，再去数仓中做分析。FineBI的数据解释功能，可以自动将利润指标所涉及的维度全查出来，这样就可以看到哪个维度占比最大，比如A产品的利润占88%，是主要的贡献者，可以继续下钻查看A产品在不同地区的销量，又发现华北的A产品销量贡献最大。这样就得到了初步的归因，但这还是基于维度的，有时维度差异不大，再往下钻维度差异也不大，就说明可能不是这些维度的影响，可能是底层其他子指标的影响，因此需要进一步的归因分析。
在完成初步的分析以后，还可以进行深度归因，这是基于指标体系构建时不同指标之间上下级的关系。
例如信用卡的透支余额指标，可能受卡数量和户均余额影响，这就是指标体系构建时，将北极星指标拆解到两个子指标，还可以继续下拆，比如卡数量可能受申请总量和通过率影响，申请总量又可以看不同的渠道，到底是线上还是线下渠道的申请总量变动比较多。
类似的拆分逻辑是基于业务知识的沉淀，通过大模型以及问答BI，学习业务人员的分析思路，最终体现在产品中，给出一些提示和建议。
比如在问答时自动弹出一些推荐，提示是否要看一些关联指标。这是AI在指标管理和BI领域中的一个非常好的应用场景。
预测型BI相对比较困难，目前大多是通过项目来实现。通常会涉及一些逻辑回归等模型，需要对大量的历史数据做处理，之后形成对未来的洞察。例如预测投诉，客户多次访问页面并在与客服通话中多次表达不满，这些都是客户投诉的前期表现，有了这样的数据积累后，就可以预测客户在哪些日期存在较大概率会投诉。如果通过BI或指标来分析比较困难，首先这其中涉及非常多的非结构化数据以及非数值数据，需要进行WOE或onehot变换，其次到底是哪些因素影响的Y变量，很难判断，需要非常多的数据积累，反复的调参以及业务人员的经验，因此通常通过项目来实现。
基于归因分析发现了问题根因，然后通过API或者在跳转业务平台的直接操作，完成问题发现、归因到解决的闭环。
例如前面的例子，卡量下降8%，经过分析发现线上申请总量下降了9%，那么就要定位到线上渠道去解决问题，如果解决不了可以督办下去，这就涉及到经营分析的一些思路，即通过指标分析和归因识别到问题以后，督办问题负责人予以解决，把问题转给渠道管理来解决。
又比如，笔均交易额突然出现大幅下跌，笔均交易额通常是受交易渠道限额影响，接下来去分析渠道的限额，如果发现确实是交易限额有变化，就可以去修改限额设置，直接在BI里面完成接口修改。
这就是将来指标管理和BI产品的一个可能的方向，即完成统计、归因、预测、决策的闭环，在BI中直接解决问题，这样使数据分析的价值更加显性化。
指标体系都存储在指标库中，可以由专门的指标管理系统来存储，不过不必纠结于工具，比如我们团队的指标库就是基于飞书在线文档实现的，包括业务架构、指标清单、管理要素、指标模型、维度清单等，还包括常用指标展示的驾驶舱和数据应用场景等。例如前面举例的信用卡余额指标，拆解为数量和余额，以及进一步拆分成申请总量和通过率，这些都可以通过父子指标的层级配置实现。北极星指标的拆解关系都配在指标库中，业务人员想要分析时，只要在指标库里面查一下这个指标的下级指标都有哪些、怎样使用，还可以叠加不同的维度，就可以完成指标的下钻和归因分析。
所有的产品的最终目标是让业务人员可以直接使用。然而目前在很多企业，BI的推广和使用还存在很多问题，比如一些年龄比较大业务人员不会使用或者说抗拒使用，还有些人认为应该由技术人员来做，数据分析的职责不清。
针对这些问题，最关键的是组织架构上，需要有相应的数据分析团队帮业务部门分析，而且数据分析团队最好内置在业务部门，每个业务团队有1-2个数据分析岗，这些人员由业务部门考核，逐步的让业务条线感受到数据的作用，以及数据分析上手不难，这是需要一个过程的。
数据项目的最大风险就是建完了以后没人用，因为数据项目与业务系统不同，通常是非刚需项目，不是雪中送炭，只是锦上添花，即没有这一套产品，业务也能生存下去。所以在做数据类项目时，经常是建完以后业务部门觉得学习或迁移成本太高，没必要用，业务部门还是习惯在原有的逻辑中去完成。甚至有一些业务人员认为数字化对其自身是一种威胁，原来所有的业务经验和知识，包括客户都在脑子里，如通过数字化的手段固化到系统中，那个人的价值在哪？因此要让业务人员充分参与，意识到产品能够减轻工作量而不是增加工作量，需要长期的宣导、培训、竞赛，把企业的数据文化建立起来，这是最核心的工作。
通常的培训都是产品上线后介绍产品操作方法，做起来非常简单，但是绝大多数情况下不起作用。现在帆软有专门的团队通过一套方法论来引导客户，而不是单纯的讲产品功能。整体包括数据人才诊断、培养和评估三个环节：先看整个组织架构有没有问题，包括人才体系建设、职能岗位职责分布；然后去做培训，有线上、线下、集中、分散、点对点、批量等多种方式；之后去做评估，包括FCA和FCP认证。
我们合作的客户中，例如华夏银行，就把指标派到了分行，要求每个分行都有一些工程师能够参与分析，这样就可以比较好地加强业务的积极性。在东亚银行，也做了很多培训和大赛，包括请领导站台、内部宣发、外部宣发等，使整个产品的使用比例有了大幅提升。当习惯用数据做决策后，这套系统就会成为业务人员工作中的必不可少的工具。
本白皮书对170多位企业CIO、CTO、数据管理负责人或拥有同等职责的IT负责人的调研，了解IT管理者对BI的应用情况、价值诉求、技术需求、主要参考因素。通过对调查情况分析，深度洞察BI现状和发挥数据应用价值的关键，并基于此提出专业建议，以帮助企业推动决策改善、推进企业数字化转型，白皮书中不少观点可以给大家来年数据工作立项带来一些参考。
| 
