数据指标在金融行业的应用

导读 本文将基于帆软（FineBI）BI 产品的建设经验，介绍数据指标体系建设和底层建设，并以授信余额等金融指标为例，展示父子指标、指标下钻、问答AI 等在金融行业的应用。

今天的介绍会围绕下面四点展开：

1. 怎么建体系

2. 怎么建底层

3. 怎么用指标

4. Q&A

分享嘉宾｜张鲲 帆软软件有限公司 咨询总监 

编辑整理｜吉恩

内容校对｜李瑶

出品社区｜DataFun

---

01

怎么建体系

首先来介绍如何构建指标体系。

指标体系设计框架已较为成熟，主要来源于企业战略自上而下的演绎，以及一线业务实操自下而上的归纳。基于这种设计方法，再加上底层应用和管理体系的支撑，共同构成了一个整体的经营分析的指标库。

整体的目标制定是基于公司的发展战略，如十四五战略规划、数字化转型规划等，分析战略实现的决定性因素，梳理指示实现价值的可测量数据，进而形成一级指标，或称北极星指标。

有自上而下演绎得到的指标，为什么还要做自下而上的归纳呢？因为演绎过程中，可能为了追踪新的战略目标，而设置一些新指标，这些指标对一线业务来说是比较陌生的，因此还需要收集一线常用的指标并将其体系化，进行自下而上的归纳。两个方向相结合，形成最终的指标库。

自上而下的演绎包括制定北极星指标、建立价值树和价值驱动因素优先级，逐步拆解形成指标。例如，提升客户活跃和留存的北极星指标，可以拆成增加客户留存、提升产品销售能力和提升审批效率等二级指标，再向下可以拆成增加客户留存、提升客户粘性、提升客户忠诚度、促进交易量等子指标。

这种自上而下演绎的方法论和传统指标体系建设方式存在一定差异，传统指标体系通常是拆解到维度，而这里则注重指标上下级之间的关联。在大指标出现异常的时候，会对其下的子指标进行分析，寻找原因，而不是单纯的只看大指标的维度。

自下而上的归纳，通过指标的收集、解析、整合和归类，形成指标库。

最终形成一个多维、多层级、全场景覆盖的指标树。比如提升渠道能力，可能涉及很多指标，我们把各个渠道的，比如网银的、客户经理产能的指标都细分出来，归纳到体系中，形成一个结合业务维度和技术维度的全场景的指标体系框架。

具体的指标盘点主要包括七大步骤，即通过调研访谈梳理业务条线、场景，以及业务流程和过程，覆盖所有业务条线和场景、流程，形成原子指标，进而形成衍生指标。

最终形成一个图谱，涵盖所有的环节，可以看到每个环节中有多少指标。如果某个环节没有指标，就说明存在遗漏，需要针对性地去补充指标；而如果某个环节指标偏多，则可能是 KPI 导向或者存在重复指标。这样梳理出的图谱就会比较完整，并且是基于统一价值链的。

指标定义，应包括业务属性、技术属性和管理属性，特别是属主部门非常关键，需要明确由哪个部门对该指标的定义负责，当指标数值出现偏差时谁负责修正，指标管理中的很多痛点都是源于属主部门没有定义清楚。

指标体系建好之后，还要管理好。首先，需求收集流程要明确，即需求谁来提、谁来处理。指标的拆分创建流程，也要定义好各部门的职责。接下来，指标的审批、发布，后期的监控和失效归档，都需要建立相应的机制。譬如，某股份制银行的数据资产平台中存在 6-7 个 AUM 指标，无法明确该用哪个，所以只好再增加一个，如此下去就可能导致指标的无限增长，因此需要一套完善的体系对指标的使用进行监控、分析和管理。

02

怎么建底层

指标来自于数仓，接下来看一下底层数仓是如何搭建的。

数仓的标准结构包括 ODS 层、DWD 层、DWS 层、ADS 层。目前很多企业在使用BI 等数据应用的时候，数据直接由 ODS 对接到数据应用，缺少了中间各层的数据加工。应用层直接读取原始数据，由于明细数据量很大，会导致应用层很慢，不同的分析师从 ODS 从头按自己的理解加工，也会带来指标口径不一致的问题。因此企业一定要建数仓、建集市，一层一层地建设，最后通过 ADS 层来服务各类数据应用。

DWD 层主要做清洗和落标的工作，对于垃圾数据、脏数据、空数据、不符合码值的数据会统一在这层做清洗，统一标准。同时在该层做一些维度退化，把表适度做宽。最后是做数据脱敏的工作。

DWS 层，即汇总层，将数据汇总成服务于某一主题的宽表，不面向特定应用。

汇总层的表需要满足通用性，原则上不跨主题域，并且要标明统计周期，因为不同域的时效性不一样，还要避免将不同层级的数据放在一起。

如果直接从底层数据取数，那么指标的逻辑会写在 SQL 中。例如授信余额这一指标，业务含义是在授信额度上减掉已用额度所剩下的额度，如果没有提前在汇总层中把授信余额计算好，每个人对指标含义的理解可能不同，就会导致不同系统算出来的授信余额不一样，可能带来超额授信等风险。出现指标差异，要去查底层逻辑也会非常耗时耗力。如果把授信余额口径提前在汇总层加工好，在做指标时只需要筛选客户类型，然后选中授信余额，就可以出指标，这样业务部门就有了自己分析指标的基础，因此数仓的良好构建非常必要。

03

怎么用指标

构建好底层数仓和指标体系后，接下来看一下如何应用指标。

BI 分析是指标应用的主要场景，主要包括 4 种类型：

• 第一种是统计型，即基于现在的数据做统计分析，了解现在的数据呈现怎样的特征，这是大多数客户使用 BI 的场景。
• 第二种是归因型，即了解为什么数据会呈现某种统计结果，是由哪些原因导致的，可以通过指标的维度分布查看，也可以通过下钻查看关联指标和子指标的情况。
• 第三种是预测型，即根据现有的数据去预测未来的趋势。现在通常的做法是通过一个项目来做，例如预测下个周期的不良率，或某个客户的投诉概率，在风险领域的建模，就是这样一个过程，很少能通过 BI 直接完成这个建模和预测的过程。当然目前有拖拉拽式的自助式建模分析平台，这是另一条技术路线。
• 第四种是决策型，现在能做到这一步的非常少，或者说这不是 BI 的定位。决策型是指当发现某业务的趋势后，直接通过接口把需要修正的业务通过 API 发送给业务系统进行修正，例如改一个开关功能、改限额、改属性等，整体上是把 BI 的边界做得很大，这是不是 BI 的职责目前还没有定论。但这确实是指标分析的终极目标，即能够完成从分析、归因到改进的闭环，并且能够监控改进后的结果。

目前绝大多数 BI 都属于统计型，包括报表和大屏一类的可视化应用。

统计型 BI 可以为你展示数据是什么样的，但不能告诉你为什么。基于这一问题，FineBI 提供了数据解释的功能，可以初步完成归因和下钻。

如上图所示，可以看到 2016 年利润突然上涨很多，一般在传统 BI 中需要把该指标提出来，再去数仓中做分析。FineBI 的数据解释功能，可以自动将利润指标所涉及的维度全查出来，这样就可以看到哪个维度占比最大，比如 A 产品的利润占 88%，是主要的贡献者，可以继续下钻查看 A 产品在不同地区的销量，又发现华北的 A 产品销量贡献最大。这样就得到了初步的归因，但这还是基于维度的，有时维度差异不大，再往下钻维度差异也不大，就说明可能不是这些维度的影响，可能是底层其他子指标的影响，因此需要进一步的归因分析。

另外，利用大模型的能力，还可以通过问答的形式，给到一些原因的提示，如果输入的内容其他人已经输入过，或者在库里能够匹配到这些度量或者维度，系统会做一些提示，也可以帮助引导分析思路。分析出来后，产品会把整个的意图和分析过程展示出来，由用户确认分析路径是不是有问题，用户也可以在上面直接去改维度和分析的度量。这就是目前 FineBI 在尝试的问答 BI 产品。

在完成初步的分析以后，还可以进行深度归因，这是基于指标体系构建时不同指标之间上下级的关系。

例如信用卡的透支余额指标，可能受卡数量和户均余额影响。指标体系构建时，将北极星指标拆解到两个子指标，还可以继续下拆，比如卡数量可能受申请总量和通过率影响，申请总量又可以看不同的渠道，到底是线上还是线下渠道的申请总量变动比较多。

类似的拆分逻辑是基于业务知识的沉淀，通过大模型以及问答 BI，学习业务人员的分析思路，最终体现在产品中，给出一些提示和建议。

比如在问答时自动弹出一些推荐，提示是否要看一些关联指标。这是 AI 在指标管理和 BI 领域中的一个非常好的应用场景。

预测型 BI 相对比较困难，目前大多是通过项目来实现。通常会涉及一些逻辑回归等模型，需要对大量的历史数据做处理，之后形成对未来的洞察。例如预测投诉，客户多次访问页面并在与客服通话中多次表达不满，这些都是客户投诉的前期表现，有了这样的数据积累后，就可以预测客户在哪些日期存在较大概率会投诉。如果通过 BI 或指标来分析比较困难，首先这其中涉及非常多的非结构化数据以及非数值数据，需要进行 WOE 或 onehot 变换，其次到底是哪些因素影响的 Y 变量，很难判断，需要非常多的数据积累、反复的调参以及业务人员的经验，因此通常通过项目来实现。

基于归因分析发现了问题根因，然后通过 API 或者在跳转业务平台的直接操作，完成问题发现、归因到解决的闭环。例如前面的例子，卡量下降 8%，经过分析发现线上申请总量下降了 9%，那么就要定位到线上渠道去解决问题，如果解决不了可以督办下去，这就涉及到经营管理的一些思路，即把问题转给经办人，或者是客户经理，或是渠道管理来解决。

有一些指标可以看到增长，但是否带来了真正的提升？例如信用卡的通过率提升了，是不是带来了激活率的提升。如果通过了很多的信用卡，但是客户激活并不多，那卡产品的设计可能有问题，或者激活流程太复杂。

又比如，笔均交易额突然出现大幅下跌，笔均交易额通常是受交易渠道限额影响，接下来去分析渠道的限额，如果发现确实是交易限额有变化，就可以去修改限额设置，直接在 BI 里面完成接口修改。这就是将来指标管理和 BI 产品的一个可能的方向，即完成统计、归因、预测、决策的闭环，在 BI 中直接解决问题，这样使数据分析的价值更加显性化。

指标体系都存储在指标库中，可以由专门的指标管理系统来存储，不过不必纠结于工具，比如我们团队的指标库就是基于飞书在线文档实现的，包括业务架构、指标清单、管理要素、指标模型、维度清单等，还包括常用指标展示的驾驶舱和数据应用场景等。例如前面举例的信用卡余额指标，拆解为数量和余额，以及进一步拆分成申请总量和通过率，这些都可以通过父子指标的层级配置实现。北极星指标的拆解关系都配在指标库中，业务人员想要分析时，只要在指标库里面查一下这个指标的下级指标都有哪些、怎样使用，还可以叠加不同的维度，就可以完成指标的下钻和归因分析。

所有的产品的最终目标是让业务人员可以直接使用。然而目前在金融机构，BI 的推广和使用还存在很多问题，比如一些年龄比较大业务人员不会使用或者说抗拒使用，还有些人认为应该由技术人员来做，数据分析的职责不清。

针对这些问题，最关键的是组织架构上，需要有相应的数据分析团队帮业务部门分析，而且数据分析团队最好内置在业务部门，每个业务团队有 1-2 个数据分析岗，这些人员由业务部门考核，逐步的让业务条线感受到数据的作用，以及数据分析上手不难，这是需要一个过程的。

数据项目的最大风险就是建完了以后没人用，因为数据项目与业务系统不同，通常是非刚需项目，不是雪中送炭，只是锦上添花，即没有这一套产品，业务也能生存下去。所以在做数据类项目时，经常是建完以后业务部门觉得学习或迁移成本太高，没必要用，业务部门还是习惯在原有的逻辑中去完成。甚至有一些业务人员认为数字化对其自身是一种威胁，原来所有的业务经验和知识，包括客户都在脑子里，如通过数字化的手段固化到系统中，那个人的价值在哪？因此要让业务人员充分参与，意识到产品能够减轻工作量而不是增加工作量，需要长期的宣导、培训、竞赛，把企业的数据文化建立起来，这是最核心的工作。

通常的培训都是产品上线后介绍产品操作方法，做起来非常简单，但是绝大多数情况下不起作用。现在帆软有专门的团队通过一套方法论来引导客户，而不是单纯的讲产品功能。整体包括数据人才诊断、培养和评估三个环节：先看整个组织架构有没有问题，包括人才体系建设、职能岗位职责分布；然后去做培训，有线上、线下、集中、分散、点对点、批量等多种方式；之后去做评估，包括 FCA 和 FCP 认证。

我们合作的客户中，例如华夏银行，就把指标派到了分行，要求每个分行都有一些工程师能够参与分析，这样就可以比较好地加强业务的积极性。在东亚银行，也做了很多培训和大赛，包括请领导站台、内部宣发、外部宣发等，使整个产品的使用比例有了大幅提升。当习惯用数据做决策后，这套系统就会成为业务人员工作中的必不可少的工具。

04

Q&A

Q1：数仓建设有从 ODS 到 DWD、DWS、ADS 这样的成熟理论，为什么企业明知道还是直接从 ODS 到应用层呢？

A1：不是所有人的认知都一样，有的认为建设一套仓库只是方便科技人员管理数据，并不是给业务用的，就导致科技人员建仓时，按照科技的思路去做主题划分和数据汇总，而没有考虑业务，所以在汇总时只把科技认为常用的指标释放出来，业务人员缺少的指标只能自己去 ODS 层取。因此 ODS 层和 DWD 层是可以自下而上地建的，但上面的 ADS 和 DWS 层一定要从业务需求出发来建，这样才能建设一个真正有用的汇总层。本质上还是部门墙的问题，导致整个过程没有很好的协同。

Q2：BI 能够穿透到哪个层级，是报表层还是业务系统的单据？

A2：业务系统的原始数据在数据架构最下层，原样导入 ODS，再一步步往上加工，如果在 BI 上发现一个指标有问题，可以首先横向穿透，看到整个的指标有哪些维度有问题，进入维度中去穿透，或者按照子指标去穿透，但是基本都还是在应用层或者汇总层。如果要看明细的原始数据，可以定位出某一批客户或者流水号，然后把主键提出来，去原始系统里查，但是基本不会到穿透到 ODS 层，因为应用层一般不会直接对接到 ODS 层，最多是对接到汇总层。

Q3：业务指标的变化，根因分析可以定位到具体的某些客群的影响吗？如何实现？

A3：对客群的话，基本上是客户维度，例如有个人客户维度、公司客户维度，客群是人为定义的标签，把个人客户维度又拆成很多客群，例如 A 客群、B 客群，然后在这个维度上做维度表，不断和宽表去加工，最后形成一些基于客群的指标。所以当一个指标出现异常时，例如授信余额指标出现异常，就去看客群 A、客群 B 的授信余额指标波动。如果发现客群 A 的授信余额是上升的、客群 B 的是下降的，就可以判断是客群 B 出问题。当然具体依赖于客群的标签打的是不是准确、指标和维度的关联是不是准确等。

Q4：请问怎么区分数据解释和指标下钻？可以以 FineBI 的功能为例吗？

A4：数据解释是基于维度的，在宽表中可能是一个度量，把这个度量的所有维度算一遍，然后去看贡献值。归因中的下钻，是业务逻辑的一个体现，在数据解释里面没法去解释，因为指标都不在同一个表里，所以可以：（1）有业务经验，配在大屏看板的下钻逻辑里面；（2）做一个指标库，让业务人员有地方可以查询，例如上面提到的基于飞书文档搭建的指标库，项目交付、现场咨询、给到客户都可以用，在查指标时，就能知道它有哪些子指标可以下钻，通过一些下钻的配置或者指标库查询，让业务人员知道这几个指标是父子相关的。

以上就是本次分享的内容，谢谢大家。

分享嘉宾

INTRODUCTION

张鲲

帆软软件有限公司

咨询总监

拥有 15 年以上银行及金融行业从业经验，曾参与民营银行筹建，头部咨询公司特聘专家，专注于金融行业大数据架构及应用，包括基于大数据的精准营销、风险控制和反欺诈，对于银行业数据应用、管理和治理有深刻见解。

往期推荐

活动推荐7 月 5-6 日，DataFunCon2024·北京站将在北京·丽亭华苑酒店举办。会议聚焦以大数据和大模型为代表的新质生产力，甄选出近 100+ 企业级落地案例，可参考、可复制、可持续，助力业务数智化转型。扫描下方二维码或点击「阅读原文」即可查看完整议程，现在报名最高可减 1800 元，更多团购优惠添加票务小助手咨询。

点个在看你最好看