行业新闻

各位领导、各位专家、各位同仁：

大家上午好！本次分享原本应由杨总进行，但他临时有监管检查任务，因此今天将由我来为大家分享我们在数字化指标管理领域走过的弯路、踩过的 “坑”，以及沉淀下来的一些经验。

为什么要谈数字化指标管理呢？因为过去十年，我们银行业在数据领域投入了大量资源，数据中台、数据湖、实时计算、AI 模型等技术名词层出不穷。但回归到经营管理最核心的问题 ——“到底赚不赚钱、风险有多大、客户满不满意”，很多高层拿到的数据却依然存在 “对不上、算不清、信不过” 的问题。我们内部做过一项调研：在行长办公会上，针对 “对公存款日均余额” 这一项指标，计财部、公司部与数据部门三个部门给出的统计口径竟有三个版本，最大偏差达 8%。这并非因为我们的技术算力不足，而是指标管理存在漏洞。因此，数字化管理对我们而言，不仅是技术部门的 “锦上添花”，更是银行经营的 “生死线”。

今天，我将从三个部分为大家分享我们的实战经验。

一、痛点与目标

首先是我们遇到的痛点，关于指标管理的核心问题，我总结为四点：

第一，业务与技术融合难题。业务与技术部门沟通时常 “鸡同鸭讲”：业务部门说 “我要的是绿色客户”，技术部门却会问 “绿色客户在系统里该定义为 RGB 值还是布尔型”，导致沟通成本极高。

第二，口径一致性问题。口径不一致，会导致领导拿到的永远是 “错数”。业务部门宁愿手工统计数据，也不愿使用我们提供的数据成果，核心原因就是口径不统一 —— 考核口径与提供的统计口径不一致，行内 KPI 口径与监管部门要求的口径也存在差异。最终，同一张报表出现三套数据，领导只能 “谁的说法顺耳就信谁”。说白了，数据再多，若口径不一，也只是 “问题数据”。

第三，标准性问题。这一问题主要体现为标准缺失、“同名不同数”。我们常常误以为 “标准制定是技术部门的事”，但标准恰恰卡在技术与业务之间：我们既听不懂业务的 “黑话”，又摆脱不了技术层面的 “洁癖”，最终导致跨平台出现 “同名不同数” 的情况，本质上就是各说各话。举个例子，“不良贷款率” 这五个字，在监管报送、管会、风险集市、数据仓库四个平台中都在使用，名称完全一致，但打开取数逻辑（SQL）会发现四条逻辑 “南辕北辙”：有的扣掉了核销数据，有的包含重组数据，有的按五级分类划分，有的则按语义定义。这些指标名称像 “亲兄弟”，数据结果却似 “异父异母”。于是，指标建得越多、口径越分散、平台铺得越广，标准就越模糊，最终大家都不敢 “拿来就用”。

最后一点，是实用性问题。现实中，有两道 “断层” 让我们备受困扰：

一是指标定义与落地 “两张皮”。指标在平台上呈现得很规范，技术口径、业务口径也写得清清楚楚，但一旦应用到真实报表或数据场景中，一条取数逻辑（SQL）往往融合了七八个指标，没人能说清 “谁是谁的逻辑”“能不能拆出来复用”。结果就是，一旦逻辑调整，影响面就像 “毛线团”，剪不断、理还乱。

二是管理平台与生产运行 “两条轨”。当生产出现问题时，我们会陷入两难：到底先改指标，还是先改流程？管理部门要求，一个指标的紧急上线需经过评审、SID（系统标识）配置、运维、投产等多个步骤，即便是标准化变更，也可能需要五天；但生产一旦发生故障，告警响起后，事故处理窗口期往往只有 5 分钟。面对 “5 分钟 vs 5 天” 的矛盾，我们该优先 “救” 哪一个？

举个例子，我们昆山农商行大概有 3 万多个作业任务，每周都会出现生产问题；那些有 20 万 - 30 万作业任务的大型银行，恐怕更是天天上演 “救火现场”。当管理平台 “高高在上”，生产系统却在底下 “贴创可贴”，我们不得不面对一个尴尬的问题：有了指标管理平台，指标就真的能用了吗？

针对这些痛点，我们在 2022 年启动了指标管理平台的建设，搭建指标线上化管理能力。为实现这一目标，我们确立了三个核心方向：

第一，构建指标原子化管理。什么是原子化管理？即 “一个逻辑对应一个指标”，实现指标与业务的一一映射，保障所有场景下指标管理逻辑的一致性。指标的复用，必须同时满足 “逻辑一致” 与 “数据同源” 才算真正落地：“逻辑一致” 是前提，决定了指标口径不跑偏；“数据同源” 是保障，确保同一指标在不同终端、不同任务中跑出的结果完全一致。为实现这两点，我们采用 “原子化 + 组合” 的双层架构：先将不可再分的最小加工单元沉淀为 “原子指标”，保证逻辑唯一；再通过标准化组合规则生成 “配置指标”，确保数据同源。这样既能避免 “炒作业式” 的逻辑复制，又能让新增需求都基于同一份原子数据实现，达成真正意义上的指标复用。

第二，推进指标线上化管理。通过线上化管理平台，实现对流程和人员的有效管控，让指标按照标准化模式进行开发与落地。

第三，建立指标全生命周期管理。从需求引入、指标开发，到指标投产与变更，全程实现标准化管理。这意味着管理要覆盖指标的每一个环节：从需求提出到指标投产、下线，所有动作都要留痕，所有数据血缘可追溯 —— 也就是说，指标的 “生老病死” 都要有档案，变更带来的影响要能 “一键感知”。

二、指标管理

当然，目标再好，不落地也只是 “PPT 上的蓝图”。在指标管理实践中，我们着力构建全行统一的管理能力，从管理流程到管理模块进行完善，具体做了三个层面的工作：

第一，推进指标确权工作，将指标所有权归还给业务部门。过去，数据部门对指标工作 “大包大揽”；现在，通过确权，将指标的管理权与使用权交还给业务部门，由业务条线对所定义的指标 “终身负责”。同时，业务部门除了自己使用指标，还可将其分享给其他部门；需求部门则可通过资产检索平台查询其他业务部门的指标，若能检索到匹配指标，无需重新开发。

第二，强化需求管理，杜绝重复建设。指标需求提交至数据部门后，数据部门会先分析指标的可行性，并根据业务口径检索资产库：若存在类似指标，会先与业务部门确认数据是否一致，一致则直接复用；若不一致，会在原有指标基础上进行扩充完善。

第三，加强技术管控，让平台成为 “守门员”。通过平台实现指标的全线上化、标准化开发，目前我们采用零代码开发模式，并加入指标逻辑重复度检查：当指标逻辑重复度达到 80% 以上时，会先分析逻辑是否存在冲突，若有冲突则优先完善已有指标。通过以上三种途径，我们实现了指标的统一管理；标准统一后，指标重复开发减少，复用率提升，生产故障也随之自然降低。

三、成果展示

第三部分，是我们基于指标管理平台取得的成果展示。这套指标系统从 2022 年启动建设，至今已投入使用两年多，是全行统一的指标管理平台，集成了口径定义、规则加工、指标上下线等功能，实现了指标全生命周期管理。

指标管理平台的开发界面：界面中会根据指标定义生成任务，每个指标对应一个任务，包含开发人员、关联项目、关联需求等信息。在这个界面上，我们可实现自助拖拽式开发，无需技术人员手动编写 SQL 语句。

指标自动化测试界面：在平台上可开展自动化测试，能直观看到 ETL 脚本的测试情况与自动化测试结果。我们会在测试中配置自动化测试要点，系统会自动判断结果的重要性，测试人员先进行基础核查，再开展后续测试工作。

指标的作业依赖配置界面，属于指标管理平台的核心功能区：可清晰查看指标的所属人、所属业务部门，以及指标当前处于 “投产”“上架” 还是 “下架” 状态；此外，指标的转换规则、分类、定义、分层等信息，在平台上也能一目了然。

我们的成果是 “看得见、摸得着” 的：目前已构建指标约 8766 个，指标复用数量 1911 个，指标复用次数达 7206 次；通过指标出数优化，工单取数效率同比提升 80% 以上。这是我们获得的相关奖项及发明专利情况。

最后，我想给正在推进数字化指标管理的同行们提两条小建议：

第一，建设过程中遵循 “先僵化、后优化、再固化” 的原则。不要一开始就追求完美模型，先把流程跑通，让所有人养成 “先查资产、再提需求” 的肌肉记忆。

第二，指标并非 “越多越好”，而是 “越准、越少越好”。我们内部有句话：“一个不准的指标，比没有指标更可怕。” 宁可 “少而精”，也不要 “多而滥”。

我的分享到此结束，谢谢大家！