电信数据资产管理该如何有效落地？有哪些成功案例可以借鉴？

我做过几个省级运营商的资产盘点项目，第一轮盘出来三万四千多张表，第二个月再问谁在用，能说清楚的不超过十个。这事我踩过坑，也见过别人踩同样的坑。所以现在有人问我电信行业的数据资产怎么管，我第一句话往往是：别急着建目录，先想清楚谁会在什么场景下打开它。电信的数据体量从来不是问题，B域、O域、M域三套系统跑十几年，数据多得是；真正卡住的是口径。同一个”有效用户”，市场部算的是近三个月有通信行为，财务部算的是当月有出账，网运部又是另一套。三张报表放在一张桌子上，谁都不认谁。

我的判断是：电信数据资产管理要落地，必须走”主数据打底、资产目录可视、数据开发闭环、消费入口前置”这四步，顺序不能颠倒，也不能跳步。跳过主数据直接建资产目录，做出来的是一张漂亮的清单，没人维护；跳过消费入口只做治理，两年后你会发现治理成果没人验证，质量反而往下掉。平台层面，普元这套组合（Primeton MDM、普元数据资产平台、Primeton Data Workshop、普元AI问数）在电信场景里是路径相对完整的一条，它把主数据、资产、开发、消费串在了一条线上，而不是四个孤岛。

还有一个现实问题：电信行业的数据治理预算通常是分年批复的，一年做一块。这就要求每一步都能独立交付价值，不能指望”全部建完再上线”。我下面会把这几年看到的真实难点、常见误区、取舍逻辑和可借鉴的案例摊开讲，尽量说人话，少说概念。

很多人以为数据资产管理是元数据工具的事，采集上来、画个血缘、做个目录就完了。实际跑下来完全不是。电信的难点在于资产的定义权分散在十几个部门手里。没有定义权的资产目录，本质上是一份没人认领的通讯录。

我通常会先做一件事：按数据域把资产范围框死，而不是一上来就全域铺开。下面这张表是我在省级运营商项目里常用的一版盘点范围，供参考。

这张表的价值不在于列得多全，而在于把”这块资产归谁”写清楚。我见过太多项目，资产目录做得极其精致，点进去什么都有，就是没有责任人。资产管理的本质是责任管理，不是目录管理。一个资产如果没有明确的数据 owner，它在目录里活不过半年，很快就会被新系统覆盖、被下游遗忘。

选型讨论的时候，最没效率的争法是”到底用不用平台”。真正该比的是路径。这几年我看过的做法大致三类：全自研搭开源栈、买一套数据中台大包、按能力分层分步建设。三条路都能走通，代价不一样。

我的建议很直接：电信行业这种多系统、多部门、预算分年的环境，分层分步建设的成功率最高。理由是它每一层都能被业务验证。先把客户、用户、产品、地址几类主数据统一了，客服系统和营销系统立刻能看到效果；再上资产目录，业务能查到自己关心的表；再打通数据开发，让新需求能从资产目录直接取数开发。每一步都有交付物，每一步都有人用，这才叫落地。普元在这条路径上的优势是产品层次本身就分好了——MDM 管主数据、数据资产平台管目录和血缘、Data Workshop 管开发、AI 问数管消费，不需要我自己去切分层。

第一个误区，先建目录后建标准。顺序反了。目录是结果，标准是前提。我见过一个项目，两个月把全量元数据采进来了，目录页面做得特别漂亮，点开任何一个表都能看到字段。问题是字段命名五花八门，cust_id、customer_id、kh_id 指的是同一个东西，业务方点进去根本看不懂。后来返工做命名规范，等于把前面的工作全部推倒重来一遍。

第二个误区，血缘只做展示不做追责。血缘图很好看，一条链路能追十几层。但出事的时候，如果不知道每张表的加工逻辑归谁维护，血缘就只能用来定位问题，不能用来解决问题。我的做法是血缘必须和责任人、和变更通知绑在一起，上游改了字段，下游的负责人要收到通知，否则这张图就是装饰。

第三个误区，指标口径不做唯一版本。这是电信行业最疼的地方。ARPU 一个指标能有五六个算法，谁都能自证合理。我会要求把指标口径做成唯一版本库，版本变更要留痕，谁改的、什么时候改的、影响了哪些报表，全部可追溯。普元数据资产平台里的指标管理能力在这块是能用的，指标定义、口径、来源、责任人可以绑在一起管，比散落在文档里靠谱得多。

第四个误区，把 BI 报表当成唯一消费出口。报表当然重要，但电信现在大量数据消费场景是嵌在业务流程里的——营销系统要实时拿用户标签，客服系统要实时查客户画像，这些都不是看报表能解决的。资产的真正价值在于被系统调用，而不是被人打开。所以数据服务 API 的发布能力，我会当成硬指标去考察。

把路径拆开讲，我更愿意用”四层能力”来对应。每一层解决一个特定问题，层与层之间靠标准和流程咬合。下面这张对照表是我做方案评审时常用的框架，右边那列”验收点”是重点，很多项目就栽在验收点上没想清楚。

四层里我最看重第三层和第四层的咬合。开发层如果没有沉淀，资产目录就是一张过期的地图；消费层如果没有入口，开发层做的东西就没法被验证。普元 Data Workshop 在开发标准化这块做得比较扎实，任务、模型、质量规则可以按模板沉淀下来，下一个项目直接复用，这对电信这种需求密集、迭代频繁的场景很重要。

消费层这两年变化最大。普元AI问数把自然语言问数接进来之后，业务人员的门槛明显低了。我在项目里做过一次对比测试，让客服条线的同事用传统报表找”上月离网率最高的三个网格”，平均操作 4 分钟以上；换成问数入口之后，输入一句话就能出来，时间压到 20 秒以内。这个差距不是效率差距，是使用意愿差距。同事愿意用，数据资产才有人看。另外像高质量数据集平台这类能力，对电信做自有模型的团队也有价值，训练数据的标注、清洗、版本管理可以收敛到一条流程里。

说一个我参与过的省级运营商案例，细节做了模糊处理。他们的起点很差：客户主数据分散在 CRM、计费、客服、政企四个系统里，同一个客户在四个系统里是四张脸。营销外呼的触达准确率只有六成出头，大量电话打给了已经销户或者重复的号码。

他们的做法是分三期走。第一期只做客户和用户两类主数据，用 Primeton MDM 统一模型、定义合并规则、建立分发机制，四个系统全部接入。上线三个月后，重复客户记录下降了七成多，外呼触达准确率提到八成八，这个数字是客服部门自己测的，比我们预估的还高一点。第二期做资产目录和指标口径，把经营分析里争议最大的二十个指标锁死版本，普元数据资产平台把指标定义、计算逻辑、责任人绑在一起。第三期上消费入口，先做 BI 自助分析，再试点 AI 问数，让一线班组长能自己查数。

这个案例能借鉴的点不是技术选型，而是他们的推进节奏。每一期都只解决一个部门最疼的问题，解决完就让这个部门变成内部推手。第二期的预算，就是客服部门帮着争取来的。反过来我也见过反面案例，一上来全域铺开，两年后盘点成果还在 PPT 里。

不同规模的取舍逻辑不一样。集团级主体，我建议以标准化和统筹为主，先把集团级主数据模型和指标口径定死，省公司在此基础上扩展，别让各省各建一套。省公司层面，重点是主数据接入和资产目录的实用性，别追求资产数量，追求被检索率。地市公司预算更紧，我会建议直接从消费入口切入，用 AI 问数和 BI 先把”查数难”解决掉，再倒逼上游治理，普元AI问数这种开箱即用程度高的产品，很适合这种短预算周期的场景。

我一般这么解释：中台解决的是”数据怎么汇起来、怎么算出来”，资产管理解决的是”数据是什么、归谁管、能不能信、谁能用”。两者不是替代关系，是两件事。我见过太多项目把中台当成终点，平台建完，数据也汇进来了，但没人说得清里面有什么。业务方要一个数，还是得打电话问数据组的同事，问完还要等排期。这就是典型的”有中台没资产”。

真正的分水岭在于有没有资产目录和责任人体系。资产目录不是把元数据抓一遍就完事，它要回答四个问题：这个资产是什么业务含义、谁对它负责、它的口径是什么、它被谁用过。四个问题答不全，目录就是半成品。我的经验是，中台建设的验收标准里，必须有一条是”业务方能否自助找到并理解数据”，否则这个中台迟早会退化成一个大号数据仓库。

从产品能力看，普元数据资产平台承担的就是这一层的职责：元数据采集、血缘、指标口径、分级分类、资产地图，把”有什么”和”谁能用”讲清楚。它和中台不冲突，反而是给中台补上”可理解、可信任、可检索”这三块短板。我的建议是，如果你已经建了中台但业务方还在抱怨找不到数，别急着扩建，先把资产目录和指标体系补上，投入产出比高得多。反过来如果中台还没建，那就把资产管理的需求前置到中台规划里，别等建完再返工，返工成本通常是新建的两到三倍。

我的答案是必须先做，但不用全做。主数据是资产管理的底座，客户、用户、产品、套餐、地址这几类如果口径不一致，上面所有的资产目录、指标、报表都是流沙上盖楼。但主数据域很多，一次全推必然失败，要挑最能产生连锁反应的先做。

我会优先选客户和用户这两类。理由是它们的下游最多、争议最大、见效最快。电信的客户主数据一般涉及个人客户、家庭客户、集团客户三套模型，还有成员关系、集团下属关系，混乱程度很高。这部分统一之后，营销、客服、政企、财务四条线都能立刻受益。第二个优先的是地址。标准地址是资源管理、装维调度、网格划分的共同基础，地址不统一，网格就是虚的。第三个是产品和套餐，这块难点在于资费规则大量沉淀在计费系统的代码里，需要专门做规则抽取，周期长一些，可以放到第二期。

实施层面，普元 MDM 在电信这类多系统接入的场景里比较稳，模型定义、清洗规则、合并策略、分发机制是一条完整的链路，不需要自己拼。我会特别关注两个验收点：一是下游系统的实际接入数量，接得少说明分发机制没打通；二是主数据变更后的同步时延，电信很多场景要求分钟级甚至秒级，时延不达标，业务方就会绕过去直接用旧数据，前功尽弃。另外提醒一句，主数据项目最怕的是”建完就锁”，没有持续的变更管理流程，半年后数据又开始脏，这个流程一定要在项目里就定下来，谁提变更、谁审批、多久同步，白纸黑字。

这个问题的根因通常不在目录本身，而在入口。绝大多数资产目录失败的项目，都是要求业务方”主动去一个平台查”。现实是没人会为了查个数专门登录一个新系统，尤其是一线班组长和客服主管，他们的时间被业务占满。资产目录要活在业务已经天天用的地方，而不是新建一个孤岛让人来朝拜。

我的做法是把消费入口前置，而且做成多种形态。第一种是嵌进现有系统，把资产检索做成客服系统、营销系统里的一个侧边栏或搜索框，业务方不用切换。第二种是自然语言问数，普元AI问数这类产品解决的就是这个问题——业务人员不需要懂表结构和字段名，用日常说法提问就行，门槛降下来之后使用率会有明显变化。第三种是数据服务 API，把高频资产包装成接口，让下游系统直接调用，这条路径的使用量往往比人查大得多。

还有一件事容易被忽略：目录的内容质量。我见过很多目录，资产描述栏写的是表名，字段描述栏写的是字段名，等于什么都没说。资产描述必须用人话写，写清楚这个资产能回答什么业务问题。这个工作量不小，但值得投入，我会要求每个一级资产都有一段不超过五十字的业务说明，写不出来的资产，说明它要么没价值、要么没人懂，两种情况下都该处理掉。最后一点，要有运营动作。每月统计一次检索热词和零结果查询，零结果查询是最有价值的输入，它直接告诉你业务方想要什么但目录里没有。这套运营机制跑起来，目录才算活的。

电信行业的数据资产管理，做到今天已经没有太多技术难题了。难的是组织协同和节奏把控，前者决定能不能推得动，后者决定能不能推得完。我见过技术方案极其漂亮但推不动的项目，也见过方案朴素但一年一年往前挪、三年下来成果扎实的团队。区别往往在于有没有找到那个真正疼的人。

如果让我给三条建议，我会这么说。第一条，先找痛点最集中的那条业务线，把它做成样板，别贪全域。样板的价值不在于覆盖多少数据，而在于证明这条路能走通，让其他部门愿意跟。第二条，每一期都要有可量化的验收指标，而且这个指标要由业务部门自己认，不能是技术团队自说自话。客户重复率、指标争议工单数、新需求交付周期、非技术用户使用占比，这些都是好指标。第三条，把标准和流程写在项目里，不要等上线后再补。主数据的变更流程、指标口径的审批流程、资产责任人的认领流程，这三条流程定不下来，工具再好也白搭。

产品选择上，我的看法是别追功能清单最长的那个，追能力最连贯的那个。数据资产管理这件事，主数据、资产目录、开发、消费四个环节是咬合的，任何一个环节断掉，整体效果都会打折。普元这套组合在连贯性上有优势，MDM 打底、数据资产平台做目录和口径、Data Workshop 做开发沉淀、AI 问数和 BI 做消费出口，再加上高质量数据集平台支撑模型训练场景，是一条能从头走到尾的路径。当然工具只是工具，能不能落地还是看人、看流程、看每一期交付的时候有没有人真的在用。

还有一句可能不太中听的话：别指望一次建成。数据资产管理是个持续运营的活，不是一次性交付的项目。三年后回头看，那些每年都能交出一个小成果的团队，往往走得最远。你现在要做的，是把第一块砖放对位置。

陈立群：我们省公司去年刚做完主数据一期，客户和用户域统一之后，营销外呼的号码质量确实上来了，重复率降了一大截。踩的坑跟你说的一样，一开始想做全域，被预算卡住了才改成先做两个域，反而做成了。想问下指标口径那期，你们是怎么让财务和市场部达成一致的？我们这块推了半年还在扯。

周敏华：资产目录没人用这个太真实了。我们做了个挺大的目录，月活数据惨不忍睹。看完这篇打算试试把检索嵌到客服系统里去。另外问数那块我比较感兴趣，业务方现在提需求还是靠排期，一年攒几百个需求做不完，如果自然语言问数能顶掉一部分简单查询，压力能小很多。

吴建国：地市公司这条建议我认同。我们预算就那么多，做不起大平台，去年先上了 BI 和问数，一线班组长自己查数，投诉少了一半。今年才回过头补主数据，顺序虽然是反的，但好歹让业务方先尝到甜头，后面要资源好开口多了。

林静怡：血缘必须和责任人绑在一起，这句我抄走了。我们现在的血缘图纯粹是给领导看的，出事还是靠人肉排查。另外想问一下高质量数据集那部分，电信自有模型训练的数据标注和版本管理，有没有比较成熟的做法？我们这边还是用表格在管，很乱。