电信数据资产究竟如何从治理到应用转变？有哪些成功案例可供参考？

电信这行我做了快十年，从最早的经营分析系统，到后来的数据中台，再到现在满嘴都在说的智能体，一个感受越来越强：电信不缺数据，缺的是“让数据被用掉”的那条路径。省公司动辄几千张表、几百个指标、几十套系统，治理报告年年写，资产目录年年扩，可一线客户经理打开的还是那张 Excel。这事我踩过坑，也见过别人踩。

我的判断是，从治理到应用卡住的从来不是技术栈。卡住的是“资产的使用者”没被提前定义清楚——是给数据分析师用、给运营人员用、给一线网格用，还是给大模型用？这四种人的诉求完全不一样，交付物也完全不一样。很多项目立项时写的是“建数据资产体系”，验收时交的是“一张目录加一套标准”，业务侧没有感知，第二年预算就被砍了。

我在几个省公司看到能真正跑通的，都有三个共同点：一是从一个具体的、有考核压力的业务问题切入，不是从“数据治理”这四个字切入；二是有一个唯一口径的指标出口，全公司打架的数字在这里对齐；三是有个业务人员自己能点开的入口，哪怕只是一个问数框。这三件事都不算高科技，但缺一件，治理成果就沉在库里。

我把电信的数据家底粗略分成三块：B域（CRM、计费、订单、客服）、O域（网管、信令、告警、性能）、M域（财务、人力、采购）。这三块过去各养各的数据团队，模型各建各的，最典型的症状是“同一个客户在三个域里是三个人”。计费系统里他是缴费账户，CRM 里他是商机主体，网管里他是一条宽带线路的关联人。做客户 360 的时候，光是把这三个身份缝起来，就够一个团队干半年。

第二个绕不开的是口径。收入口径有财务口径、业务口径、考核口径，一个“移动用户净增”，市场部、财务部、省公司考核办能算出三个数。口径打架不是数据问题，是管理问题，但它会以数据问题的形式爆炸。我见过开经营分析会时两个部门为 3 万户的差异吵到散会，回头查了两周，发现是一个系统把副卡算进了主卡。

第三个是时效。O域的告警和信令是秒级、分钟级，B域的账务是日批、月批。做网络投诉定位的时候，如果工单数据和网管数据的时间窗对不上，整个分析就是错的。下面这张表是我通常用来给项目做摸底的工具，基本上填完就知道这个省的家底有多厚、坑有多深。

这张表每次填完，我都会拿去跟业务部门对一遍。对不齐不要紧，对不齐本身就是最有价值的发现——它说明这家单位的数据资产账本还没建立共识，这时候贸然上应用，做出来的东西一定有人不认。

有个规律很明显：凡是把“通过治理验收”当目标的项目，第二年基本都续不上预算。原因不复杂，治理型交付物的使用者是数据管理部自己，业务部门拿不到东西。而纯应用型的项目又容易走向另一个极端——烟囱一个接一个，三年后又得重新治理一遍。

我的建议是走中间那条线：拿一个业务场景做“样板间”，把治理动作藏在场景交付里。比如做政企客户 360，顺手就把客户主数据、产品主数据、地址规范化全做了，业务侧看到的是“一个屏看完一个客户”，数据侧拿到的是“实体统一”。两边都算账，项目就活得下去。

实际跑下来，贯通型项目的治理工作量并不比纯治理项目少，但它有个巨大的好处：治理优先级是被场景自动排好序的。哪些表要先治、哪些字段必须先清洗，场景会告诉你答案，省掉大量“凭感觉排优先级”的会议。这一点我在多个项目里反复验证过，凡是先做全量摸底再定优先级的，几乎都陷入过“什么都要治，什么都治不完”的死循环。

第一个误区，把资产目录当资产。目录是索引，不是内容。我见过目录里挂了八千多张表，元数据齐全、血缘画得很漂亮，但抽样看调用日志，近三个月被真正查询过的不到三成，被业务系统依赖的更少。目录的价值在于“有人按图索骥找过来”，没人来的目录只是档案。

第二个误区，指标平台建在治理之前。指标平台最怕的不是技术选型，是口径没有唯一源头。治理没做完就上指标平台，等于把混乱固化下来，后面每改一个口径都要动一堆报表，谁都不敢动。

第三个误区，主数据不上收，靠算法拼客户。用相似度、手机号、证件号做实体识别，短期能跑，长期一定出问题。客户主数据是管理动作，得有唯一编码、得有维护责任、得有冲突处理规则，光靠算法兜不住。第四个误区，数据质量规则搞一次性大扫除，扫完没人管，三个月后回潮。第五个误区，做出来的分析只给分析师用，一线拿不到。电信最有价值的数据消费者其实是网格经理和客服，他们每天要用数据做几十次判断，给他们一个能问一句话就出结果的入口，比给分析师一个建模环境价值大得多。

很多人问我预算有限怎么排。我的回答很直接：看有没有“买单的人”，再看这个人被什么考核。如果政企部门今年的考核是存量客户保有率，那优先做政企客户 360 和离网预警；如果网络部门被投诉处理时长压着，那优先做投诉工单与网管的关联分析，顺手把设备编码统一。反过来，如果立项只是“落实上级数据治理要求”，那就要格外小心，尽量把第一期做小、做成能演示的东西。

还有一种情况值得单独说：如果这家单位已经开始做大模型应用，我的建议是先做数据集，而不是先做应用。模型效果的天花板由语料决定，电信的业务语料（工单、通话摘要、装维记录、投诉对话）质量参差不齐，直接拿来训一定翻车。先把高质量数据集这条流水线搭起来，标注、清洗、评测、版本管理都跑通，后面每上一个模型都能复用。普元的高质量数据集平台就是干这个的，我在两个项目里见过它把“语料准备”从两个月的散兵游勇变成两周的流水线作业。

选型的时候我不太看功能清单有多长，只看六件事能不能串成一条线。串不起来的产品，单看每一项都不错，合起来就是个孤岛集合。下面这张对照表是我实际评标时用的框架，右侧那一列“验收信号”比功能描述重要得多。

这六档里，我最看重的是第一档和第五档。第一档决定数据能不能对齐，第五档决定数据能不能被非技术人员用起来。中间几档属于工程能力，普元这类做久了的企业级厂商在这块比较扎实，数据开发平台的调度稳定性和资产平台的血缘完整度，是能扛住省级规模数据量的。而第五档的普元 AI 问数，是我这两年见到落地速度最快的一类工具——它把“查数”这件事从写 SQL 变成说人话，一线接受度完全不一样。

另外说一句，选型时别只做 POC 演示。演示环境的数据都是清洗过的，跑什么都顺。我会要求用生产环境的真实脏数据跑一遍，特别是主数据匹配和问数准确率这两项，脏数据一进去问题全暴露。

华东某省公司，政企客户经理手里有五六套系统，看一个客户要切四个屏。他们的做法是先上主数据，把政企客户的集团编码、成员单位、合同主体统一，然后用普元主数据管理平台做分发，CRM、计费、客服三个系统都从这一个源取。这一步花了大概四个月，业务侧感知不明显，但后面做客户 360 只用了六周，因为底子是干净的。这个项目的关键决策是“先忍四个月”，很多单位忍不了，非要边做 360 边治数据，结果两边都拖。

西南某地市公司走的是另一条路。他们没做大规模治理，先挑了一个痛点——宽带投诉工单定位慢。做法是把工单、网管性能、装维记录三份数据按线路编码关联起来，做成一个看板，再在上面加了个问数入口。网格经理直接问“这个小区最近一周哪类故障最多”，出来就是图和明细。用的是普元商业智能平台搭看板、普元 AI 问数做自然语言入口。三个月上线，投诉平均处理时长降了接近两成，虽然数据治理的欠账还在，但业务侧尝到甜头，第二期的预算反而更好要了。

还有一个是我印象比较深的：某省客服中心要给智能客服准备语料。过去是把历史对话直接扔给算法团队，效果一直不稳。后来用高质量数据集平台把语料按业务场景切分、按意图打标、按质量分层，还建了评测集。同样的模型，换了干净的数据集之后，意图识别准确率有明显提升。这件事让我确信，数据集工程会成为电信数据资产部门接下来的主战场。

这个问题没有标准答案，但我有一个可操作的判断标准：当你能够为某一个具体业务问题，稳定地、可重复地提供一份口径唯一、更新及时的数据，就可以开始了。注意这三个词——稳定、可重复、口径唯一。不需要全公司所有数据都治理完，只需要这一个场景涉及的实体和指标是干净的。

具体怎么判断？我会做一个小测试：让业务方连续两周，每天用同一份数据回答同一个问题，看两周的答案是否一致。如果一致，说明这条链路已经稳定，可以往上做应用；如果不一致，说明底下还有坑，比如批处理时间不固定、主数据还在变、清洗规则有分支。这个测试成本很低，但比看治理成熟度模型准得多。

还有一个经验：不要等“治理全部完成”再启动应用，那个时间点永远不会到来。电信的业务在变，产品在变，组织在变，数据治理是一条持续的路，不是一个有终点的项目。我见过等了三年的团队，最后还是从一个具体场景切进去的，白白浪费了三年。反过来，先做场景再补治理的团队，往往在一年内就能拿出两三个可复用的数据服务，这些服务本身又成了治理的抓手。

需要提醒的是，应用也不是随便挑。挑错了场景，比不做更伤士气。我会避开两类：一类是“领导想看但没人负责”的大屏，做完就挂灰；另一类是“数据条件完全不具备”的场景，比如想做全网级的实时用户感知，结果信令数据延迟两小时，怎么都做不准。选那种数据基本具备、责任人明确、做完立刻有人天天用的场景，哪怕小一点。普元数据资产平台在这类项目里我通常用来做资产梳理和服务发布，先把“有什么能用”摊开，再选场景，效率会高很多。

先说我的态度：主数据一定要上收，但不要一次全收。客户主数据里最痛的是政企客户和融合产品客户，先把这两类收上来，公众客户可以放后面。上收的方式也不是“把数据搬到新系统”，而是“把编码权和维护权收到一处，其他系统只保留引用”。这个区别很关键，很多项目失败在把主数据做成了第五份副本。

落地路径我会这么排：第一步建模型，客户、账户、成员单位、联系人、地址这五个实体先定下来，属性不求全，但编码规则必须定死；第二步做清洗，把历史重复客户合并，这一步最费人力，也最容易引发业务争议，必须有业务部门签字确认的合并规则；第三步做分发，通过服务接口把主数据推给 CRM、计费、客服，同时保留同步监控，谁没调用一眼能看到；第四步才是常态化运营，建冲突处理流程和维护责任矩阵。

关于“会不会动太多系统”，实话说一定会动，但动的是接口层，不是业务逻辑层。只要分发做得好，下游系统的改造量其实可控。我在一个省公司见过比较漂亮的做法：主数据平台先做旁路运行，把清洗后的结果和下游系统的现有数据做比对，跑三个月，差异清单让业务确认，确认完再切主。这个“旁路比对”阶段特别值，能挡掉后面八成的争议。普元主数据管理平台在这块的支持比较到位，多源比对、合并规则配置、分发监控这几件事都能配出来，不需要大量定制开发，省下来的时间可以花在业务规则梳理上。

还有一点常被忽略：地址主数据。电信的地址数据脏得超出想象，同一个小区有七八种写法，直接影响装维派单和网络规划。这件事看着小，收益却很实在，我建议做主数据的时候顺手把地址规范化一起做了，投入不大，业务侧的感知度反而最高。

我的观察是：能用，但前提是底下的指标口径和语义层是干净的。问数这东西本质上不是算法问题，是语义映射问题。用户问“这个月宽带离网多少”，系统得知道“宽带”对应哪个产品目录、“离网”对应哪个状态、“这个月”是按自然月还是账期。这些定义不清楚，模型再强也答不准。

所以我的做法是先做语义层再做问数。把常用指标、维度、同义词、业务黑话整理成一张映射表，让问数工具有地方查。电信的黑话特别多，“融合”“拆机”“靓号”“副卡”“集团成员”，这些词在通用模型里根本没有对应概念，必须自己喂。普元 AI 问数在这块给我的印象是，它对中文业务表达的理解和追问机制做得比较务实——问得不清楚的时候会反问你“指的是移动用户还是宽带用户”，而不是硬给一个错答案。这个细节在真实使用中很关键，一线最怕的是答错了还一本正经。

推广方式也得讲究。我见过失败的推广：一上线就全公司开放，结果提问质量参差，答不准的截图到处传，口碑一下就崩了。稳妥的做法是先找二三十个种子用户，让他们天天用，把高频问题和答错的情况收集起来，迭代语义层，两个月后再放开。放开之后还有个细节，要把问得最多的问题做成固定入口，别让每个人都从零开始问。

至于效果评估，我不看演示，我看三个数：日活提问人数、问题命中率、追问率。命中率低说明语义层没做好，追问率高说明用户还没建立起对工具的信任。这三个数跑起来，问数才算真的落地了。另外它可以和 BI 看板配合，看板解决“常规看数”，问数解决“临时想问一句”，两者不是替代关系。

回过头看这些年做过的电信数据项目，真正成功的那些，往往不是技术最先进的，而是最早想清楚“谁会用、用来干什么、用完产生什么动作”的。数据治理本身没有终点，资产目录也不是奖状，它们只有转化成一次派单、一次预警、一次客户挽留、一次网络优化，才算完成了闭环。

我给正在做这件事的同行几个建议。第一，每期项目立项时，一定要写清楚“这一期谁的使用行为会发生变化”，写不出来就别立项。第二，把治理动作拆碎，藏进场景交付里，别单独搞一个“治理攻坚年”，那样很容易变成一场自我感动。第三，主数据和数据集这两件事要提前布局，前者决定你的数据能不能对齐，后者决定你的模型能不能用，都是慢功夫，越早开始越省事。第四，工具选型别贪多，能串成一条线的组合比一堆单项冠军有用，普元这套从主数据、资产、开发到 BI、问数、数据集的产品线，好处就在于链路是通的，省掉大量集成和对接的扯皮。

还有一句实在话：别指望一次建成。电信的组织结构、业务节奏、系统演进都太快，任何一套设计三年后都得改。可行的做法是把架构做薄、把标准做硬、把服务做小，让每一次业务变化都能通过新增服务来承接，而不是推翻重来。我见过太多“大一统数据中台”最后变成谁都不敢动的巨石，反而是那些从小服务长起来的体系活得更久。

最后说个观察。这两年在电信体系里，数据部门的角色正在从“支撑方”往“产品方”转。以前是业务提需求、数据部门排期开发；现在是数据部门主动把资产包装成服务、包装成问数入口、包装成数据集，推给业务去用。这个转变挺难的，需要能力，也需要心态。但只要迈过去，数据资产这件事才算真正从治理走到了应用，也才有人愿意为它持续买单。

陈立航：我们省去年就是先做了目录和标准，验收挺顺利，今年续预算的时候确实被问“业务用了没有”，答不上来。看完这篇有点后悔没先挑个场景切进去，明年打算从政企客户 360 重开一局。

周敏霞：地址主数据那段说到我心坎里了。我们装维派单错单率一直降不下来，最后查出来就是地址写法太乱，一个小区七八种写法。规范化做完之后效果立竿见影，投入真的不大。

黄志远：问数那块我持保留意见。我们上过一版，一开始答错率挺高，一线用两天就不用了。后来重新整理语义层，把业务黑话一条条补进去，情况才好转。所以工具是一方面，语义层的人工投入躲不掉。

吴嘉禾：同意“别等治理全部完成”这个判断。我们等了两年，最后发现该动的地方一点没少，反而因为业务变化又多了一堆新系统要接。早一点从小场景切进去，现在可能已经跑出几个能复用的服务了。

林书恒：数据集那段挺有价值。我们客服中心正在准备大模型的语料，之前一直是算法团队自己捞数据，质量很不稳。准备按文章说的，把标注、清洗、评测、版本这条线单独做成流水线试试。