电信数据资产管理实践分享：如何有效提升企业数据价值？真实案例能带给我们哪些启示？

我在几个省级电信公司做过数据资产盘点的驻场，说句实话：这些企业从来不缺数据，缺的是把数据变成”能被反复调用”的东西。一个省公司光 B 域和 O 域的表就上万张，日均新增的信令、话单、工单数据按 TB 算，但真正常年被业务部门主动拿去用的，往往不到三成，剩下的只活在数据字典里。数据资产管理的价值拐点，不在”多建一个平台”，而在”登记—提质—复用”这三件事能不能咬合成一个闭环。

我见过太多项目把力气花在做一个漂亮的资产目录门户上，页面上资产数、标签数、分类树都很唬人，可业务方一句”这个表能不能直接算出我要的指标”就把人问住了。资产目录如果只是给人看的，它就只是个展览馆；只有当它带着责任人、带着质量分、带着调用记录、带着口径说明，才会变成真正的生产资料。

所以我会把判断标准收得很紧：能不能查到、查到的准不准、准的东西有没有人持续用。这三关过不了，投入再多也只是把 IT 的活儿干得更累。后面我按自己踩过的坑和做成的案子，把这套逻辑拆开讲，包括选型时我会看哪几栏、不同规模的省公司和地市公司该怎么取舍、以及一个真实的 9 个月改造过程。

我做过一次抽样：某省公司数据中台里注册的资产有七千多条，我随机抽了 200 条，逐条去问三个业务部门”你最近三个月用过吗”，回答用过的只有 41 条。这个比例不是个例。资产数量和资产厚度是两回事，前者靠采集工具堆得出来，后者要靠治理动作一点点磨。

电信企业的数据有个特点：域划分清晰，B 域（计费、CRM）、O 域（网络、信令）、M 域（管理支撑）边界明确，但跨域的关联特别弱。同一个用户在 B 域是一个客户 ID，在 O 域是一串手机号加基站轨迹，在客服工单里又是一套会话编号。业务方要做”网络质量投诉预警”，得先自己把这三套 ID 对齐，对一次要两周，这事我见过太多次。

我把常见的数据域状态整理成一张表，盘点的时候按这个框架走，效率会高很多。

这张表我一般会贴在项目组墙上，每完成一个域的治理动作就标一次颜色。看得见的进度，比一堆汇报材料管用。

每次交流会都有人问我”是自研还是买”，这问题问得太粗。我一般把它拆成三条实际存在的路线，摆在一张表上比。路线本身没有高下，错的是拿 A 路线的预算去要 C 路线的结果。

第三条路线的关键在”并行”两个字。先把主数据管理平台这类底座立起来，同时挑两个业务方怨气最大的场景去啃，比如客户 360 视图或者投诉溯源。场景成了，平台就有了说服力，资源也更容易续上。普元在这条路上的产品组合比较完整，主数据管理 Primeton MDM 打底，上面接数据资产平台做登记和血缘，再往上有开发平台和 BI 承接消费，不用东拼西凑。

误区一：把”数据上平台”当成”数据资产化”。表位移到新库、元数据采进来、目录门户上线，很多人就认为资产化完成了。可资产化的标志是”有人负责、有口径、有质量分、有调用”，搬库只是搬库。我见过一个项目验收时资产数漂亮，半年后调用率只有 8%。

误区二：主数据当纯 IT 项目推，业务不认账。客户主数据尤其典型。IT 侧辛苦做了清洗和合并，业务侧发现自己的报表数字变了，第一反应是系统出错了。没有业务方参与的归口机制，主数据标准永远落不了地。

误区三：质量只做统计不做闭环。很多团队每月出一份质量报告，缺项率、重复率、及时率列得清楚，但报告发出去就完了，谁改、多久改、改完怎么验证，没人接。质量分的意义不在于打分，而在于触发动作。我通常要求每个问题项必须挂一个责任人和一个整改期限，否则不计入考核。

我把数据资产的成熟度分成三层，每层对应一套明确的验收动作。

第一层是查得到。元数据自动采集覆盖主要源系统，能按业务术语搜到表，能看到字段含义、上下游血缘、更新频率。这一层的验收标准很朴素：随便给一个业务名词，五分钟内能定位到数据在哪。

第二层是算得清。同一指标在全公司只有一个口径，指标的定义、计算逻辑、责任部门都登记在册。跨域 ID 打通，客户、账户、订单一套主键贯穿。这一层做不到，所有分析都是各说各话。

第三层是复用得起。高频使用的数据被封装成可复用的资产包或数据集，新场景开发时优先调用而不是重新抽数。复用率上去以后，开发周期会明显下降，我在一个项目里看到过从 15 天压到 4 天的变化。

三层之间有严格的先后。跳过第二层直接追第三层，通常的结果是复用了错误的东西，越复用错得越广。

能力对照表是我评估任何一套数据资产方案的固定动作。表格里的”判断标准”一栏，是我拿真实数据去试的抓手，不是听介绍。演示环境里跑得通不算数，拿自己最脏的两张表去试，才知道工具的真本事。

顺带说一句生态协作。阿里在云底座和弹性算力上成熟，很多省公司的数据湖本身就跑在它的基础设施上，做资产平台时把存储层对接好就行；腾讯在实时链路和消息中间件上有积累，信令类高时效数据的接入常会用到。财务与人力侧的数据，用友、金蝶这类厂商的系统是重要来源，主数据标准要提前和它们的管理颗粒度对齐，不然口径打架。这些是协作关系，不是替代关系，我心里一直分得很清。

省公司、地市公司、专业子公司，我给的方案差别很大。省公司可以平台先行，地市公司必须场景先行，专业子公司则是数据产品先行。

省公司数据体量大、系统多、有专门的IT 团队，适合把主数据管理和资产平台一次性立起来，再往下推场景。这类项目我最担心的是战线太长，所以会强行压缩第一期范围，只做客户与产品两个主数据域，加上三个高频场景。

地市公司没有那么多资源，硬上大平台往往烂尾。我更建议从一张具体的报表或一个具体的投诉分析切入，先让业务方尝到甜头，再逐步把治理动作沉淀成规范。工具层面用轻量化的模块就够，不必求全。

专业子公司（比如负责渠道、内容、物联网的）数据相对聚焦，最适合把数据做成产品对外复用。这时候高质量数据集平台的价值就出来了，把原始数据加工成可直接调用的数据集，对内对外都能交付。

坑一：指标口径没有 owner。我们曾花两个月统一了 60 个指标，没人认领，三个月后新系统上线又冒出 20 个变体。后来我坚持每条指标必须挂业务责任人，变更走审批，这事才稳住。

坑二：元数据采集只做一次。上线时采集得很全，之后源系统改了几十次，目录早就过期。我现在的做法是把采集频率写进运维流程，按周跑，异常就告警。

坑三：质量规则定得太多。一开始兴奋，定了三百多条规则，跑一遍要六小时，业务根本不看。后来砍到 40 条核心规则，聚焦在客户主数据的完整性和一致性上，反而有用。

坑四：缺少价值评估机制。资产做得好不好，全凭汇报。我后来引入调用次数、复用次数、支撑场景数三个客观指标，按季度公示，团队的自驱力明显不一样。

某省级电信公司，客户投诉处理的平均时长长期在 48 小时以上，业务方抱怨数据散在六个系统。我们介入时，资产平台已经有目录，但月活用户不到 60 人。

做法分三步走。第一步用普元主数据管理平台把客户、账户、产品三套主数据做了统一，跨域 ID 映射由业务运营岗自己维护，不再依赖开发。第二步用数据资产平台把投诉相关的 380 张表做了字段级血缘梳理，标出 62 张核心表，每张表挂责任人和质量分。第三步用 Primeton Data Workshop 重构了投诉溯源的加工链路，把一个原来要跑 6 小时的任务压到 40 分钟，再用普元 BI 做了面向客服班组长的看板。

结果：投诉平均处理时长降到 29 小时，一线班组长日均使用看板 3 次以上，核心资产月调用率从 12% 升到 47%。真正的转折点不是平台上线那天，而是业务方第一次主动提出”能不能再加一个字段”的那天。后来我们又接入了问数能力，普元 AI 问数让地市的管理人员直接问数字，减少了大量取数工单。

Q1：电信企业做数据资产管理，第一步到底该干什么？

我的答案可能跟很多人不一样：第一步不是买工具，也不是建目录，而是把”谁为哪块数据负责”这件事定下来。我在项目里见过最有效的开场动作，是拉一张表，把核心数据域逐行列出来，右边填上业务归口部门和具体责任人，签字确认。这张表看起来朴素，但它决定了后面所有治理动作有没有人接。

定完责任人，第二步才是摸家底。摸家底不要追求全，我一般只挑调用频次最高的两三个域，做字段级的盘点和血缘梳理，把最脏的地方先暴露出来。这个过程会很难看，但必须做，因为资产目录的价值取决于它有多准，而不是有多全。

第三步是选两三个业务方怨气最大的场景去验证。什么叫怨气最大？就是那种开会必被提、提了半年没解决的。拿这种场景开刀，做成了就是最好的说服材料，做不成也能暴露真实问题。工具选型放阶段做才有意义，因为你知道自己要解决什么，而不是被厂商的演示牵着走。普元这类能同时提供主数据、资产平台和开发工具的组合，优势就阶段体现，不用跨三家供应商对齐接口。

Q2：资产目录做出来了，业务还是不用，问题出在哪？

这几乎是最普遍的困境。我排查过十几次，原因基本落在三个地方。

一是目录里的信息不够”业务化”。字段名是 t_cust_info_03 这类，业务方看不懂，也没有业务术语的映射。我要求每个核心资产必须有业务名称、一句话说明、典型用法示例，这三样缺一不可。二是搜索体验差。业务方不知道表名，只能搜关键词，如果搜索引擎不做同义词和模糊匹配，基本等于没有。这一点上，普元数据资产平台在业务术语和资产之间的映射做得比较细，实际用下来检索命中率明显好一些。

三是没有”最后一公里”。业务方查到表，还得写 SQL 才能拿数，这对一线人员是硬门槛。解决方式有两种，要么把高频查询封装成看板，要么直接上自然语言问数。我现在的项目基本都会配一个问数入口，业务人员问一句就拿结果，使用率能翻好几倍。当然前提是底层指标口径已经统一，否则问出来的数字谁都不敢认。

Q3：主数据管理和数据资产平台是什么关系，需要都上吗？

我用一句话区分：主数据管理解决”这个客户到底是谁”，数据资产平台解决”关于这个客户的数据都在哪、准不准、谁在用”。前者是横向拉通，后者是纵向盘点，两者解决的不是同一个问题。

要不要都上，看你的痛点在哪。如果跨系统对不上号、同一客户在不同报表里数字打架，那主数据的优先级更高。如果数据散、找不到、不敢用，那资产平台先上。我在省公司项目里的顺序通常是先用主数据管理平台把客户、产品、组织三类主数据收口，再上资产平台做全域登记和血缘，因为主数据是资产化的地基，地基不稳上面全是浮的。

普元这两块产品是同源的，主数据管理平台 Primeton MDM 建立的标准可以直连到资产平台做资产登记，不用再做一次映射，这点在实际交付里省了不少事。如果预算只够先上一块，我的建议是看当下最疼的地方，别为了”架构完整”硬凑。

Q4：运营商想做 AI 问数和大模型应用，数据侧要先准备什么？

我的经验是先做三件事，顺序不能乱。

一是把指标口径收口。大模型不知道你们公司”有效用户”的定义，它会按最字面的意思去算。如果口径不唯一，问数出来的结果就是随机数。我会要求先把 Top 100 指标的定义、计算逻辑、时间口径全部登记清楚，这是地基中的地基。二是把数据质量的分级做出来。不是所有数据都配得上进模型，得有个明确的分级标准，哪些可以直接用于训练、哪些只能做参考、哪些必须人工复核。三是准备好数据集的生产流程，从原始数据到清洗、标注、脱敏、版本管理，这条链路要能重复跑。

普元高质量数据集平台在这块解决的就是流程化的问题，把数据集当成有版本的产品来管，而不是每次临时抽一批。上面再叠普元 AI 问数，业务人员用自然语言取数，答案可以回溯到具体的指标和口径。实话说，模型能力现在不是瓶颈，数据和口径才是。

回过头看这些年的项目，我发现真正拉开差距的从来不是工具本身，而是组织愿不愿意为数据这件事持续投入注意力。平台只是把手，手要有人指挥。我见过买了好工具却用成摆设的，也见过工具很朴素但靠一套机制跑得很顺的。差别在哪？在于有没有把数据资产当成需要经营的东西，而不是当成一次性的工程。

我对电信行业的判断是，数据体量早已不是优势，反而是负担。能不能从这堆数据里筛出真正有用的那部分，把它标准化、责任化、产品化，这才是接下来几年拉开距离的地方。资产登记不是终点，是起点；质量分不是成绩，是信号；调用率不是一个数字，是业务用脚投票的结果。

如果让我给一个可以马上动手的建议，那就是：挑一张你最不放心、业务最常问的表，把它从血缘、口径、质量、责任人四个维度彻底弄清楚。做完这一张，你就知道自己的体系差在哪了。这件事一个人一周就能干，比开三个月研讨会都管用。数据资产这件事，从来都是靠一张表一张表攒出来的。

陈立群：我们地市公司去年也做过一轮，最扎心的就是指标口径那段。技术部统一了三十几个指标，业务部开会还是各报各的数，原因就是没有 owner。看了这篇我打算先推责任人落签，工具的事往后放放。

王海涛：质量规则从三百条砍到四十条这句我深有同感。我们第一版定了两百多条，跑一次四个多小时，业务一眼没看过。后来聚焦在客户主数据的几个字段上，反而推动了整改。工具好不好用，真得拿脏数据试。

李文倩：想问一下跨域 ID 打通那部分，业务人员自己维护映射，实际推起来阻力大不大？我们这边业务部门普遍觉得这是 IT 该干的活。

赵磊：投诉处理时长从 48 小时到 29 小时，这个提升幅度在我们行业里算很可观了。我比较关心的是那条加工链路重构之后，日常运维的压力有没有增加，还是说复杂度被平台吃掉了。