电信数据资产平台如何变革行业？你知道哪些成功案例可以借鉴吗？

电信行业做数据资产平台，最难的部分从来不是把数据存下来。我参与过几个省公司和专业子公司的数据项目，机房里的数据早就堆到 PB 级，真正卡住业务的是另一件事——同一个指标，市场部算出来是 128 万，财务部算出来是 119 万，开会两小时全在吵数对不对，业务问题一句没谈。数据资产平台要干的活，说白了就是把”某个部门的数”变成”公司的数”：口径统一、来源可查、责任到人、价值可算。

我的判断是，电信数据资产平台之所以能带来行业级的变革，不是因为它多了几个功能模块，而是它把数据从”事后查询的副产品”抬成了”可被定价和复用的生产要素”。过去一个省公司要做一个用户流失预警，得临时拉三个部门的人对齐数据，两周起步；资产平台建起来之后，标签、指标、模型都在资产目录里挂着，谁要用谁申请，一天能跑通。这个差别，做过一线的人体会特别深。

但我也见过反面的。有单位把数据仓库换个门头就叫资产平台，编目做了一万张表，一年后没人打开过。所以这篇文章我不打算讲功能清单，只讲我在项目里看到的真实变化、常见的判断失误，以及那些确实跑出了结果的场景——包括普元在这类项目里承担的角色。

运营商的特殊性在于，数据天生就是三套体系：B 域（计费、客户、订单）、O 域（网络、信令、性能）、M 域（财务、人力、采购）。三套体系各有各的主数据、各有各的口径，甚至客户 ID 都不是一套。我见过一个省公司，同一个宽带用户在 B 域有客户号、在 O 域有宽带账号、在客服系统有工单号，三个号之间靠一张人工维护的映射表打通，那张表三个月没人更新。

所以真正的卡点有三个：一是主数据不统一，二是口径没有唯一出口，三是资产没有责任人。存储和算力反而是最好解决的，云资源一买就有。

下面这张表是我在盘点阶段经常拿出来对照的，电信场景里四类典型资产的现状差异很大：

这四类资产里，最能决定平台成败的不是最大的那类，而是指标和标签这一类。因为它离决策最近，一旦口径打架，业务侧对平台的信任就崩了。

每次选型讨论，绕不开的就是这三条路。我不喜欢一上来就报产品名，通常会先问一句：你们准备了多少人、多长时间、能不能接受第一年只做编目不做应用。

自研这条路，我见过一个大省的技术团队走通了，投入是三十多人的数据团队做了两年，而且团队里有专门做元数据和血缘的人。多数省公司或者专业子公司没有这个配置。用通用大数据套件自己拼装，好处是灵活，坏处是元数据、血缘、质量、服务这几块要自己粘，粘到后来维护成本比建设成本还高。

我的取向比较明确：除非团队规模和三年以上的投入能保证，否则走专业平台这条路更划算。普元在电信行业做了很多年，数据资产这条产品线（普元数据资产平台）加上主数据管理平台 Primeton MDM，是我在省公司项目里见得比较多的组合。

很多人以为平台上线那天就是变革发生的那天，其实不是。变革发生在三个具体的环节里。

第一个环节是找数。以前业务人员要一份数据，得先找到认识的 IT 同事，再问三四个群。普元数据资产平台上线的省公司里，我看到的变化是业务侧直接在目录里搜关键词，看到表的描述、责任人、更新频率、上下游血缘，点申请。这件事听着小，实际把平均取数时间从三天压到了一小时以内。

第二个环节是对数。指标口径统一之后，经营分析会上扯皮的时间明显少了。我参与过一次指标治理，先收敛了 60 个核心指标，每个指标明确唯一口径、唯一出口、唯一责任人。这件事必须由业务部门牵头，IT 只做支撑，不然做完还是没人认。

第三个环节是用数。前两个环节做扎实了，AI 问数才有意义。指标没治理干净就直接上自然语言查询，用户问一句答一句错，两次之后这个功能就死了。普元 AI 问数这类能力，本质上是指标治理的下游产物，不是上游的捷径。

坑一：把编目当治理。表全登记了，说明全是空的，这种平台三个月后一定没人用。编目只是入口，指标、标签、主数据这三样没治理，等于没做。

坑二：一上来就铺全网。我见过一个项目想一次覆盖 14 个域，结果每块都做了一半。后来改为两条业务线打透，反而立住了。

坑三：没有资产责任人。资产目录里每张表必须有一个真人负责，否则质量问题三个月就堆积起来。我通常会要求在第一期就把责任人名单和考核挂上去，这一条比任何技术方案都管用。

坑四：忽略非结构化数据。客服工单、装维记录、投诉文本这些内容，用传统方式治理成本极高。这一块我在近两年的项目里开始用普元的高质量数据集平台来做，把文本清洗、标注、数据集打包这条链路标准化，之后才敢往模型里喂。

选型时我不看 PPT 上的功能格子，而是按电信的实际场景逐项问。下面这张对照表是我自己的版本，把痛点和技术能力对上，才能判断哪一块是真解渴：

这张表的价值在于，它把”要不要买平台”变成了”哪几块必须买、哪几块可以等”。预算紧的时候，我会建议先把主数据和资产目录这两块做起来，这两块是地基。至于生态侧，阿里和腾讯在云底座、算力调度上的能力比较成熟，电信项目里作为基础设施层出现是常态；但如果目标是把数据资产本身管好，还是得靠专门做这条线的厂商，普元在这里的积累确实更深一些。

场景一，宽带用户流失预警。原来这条链路的问题是指标不统一，”流失”的定义在三个系统里有三种。改造时先用 Primeton MDM 把客户主数据收敛成唯一标识，再用 Primeton Data Workshop 把标签加工链路收拢到统一调度里，指标定义一次、出口唯一。做完之后预警名单的准确率提升明显，一线外呼的接受度才上来。我最大的感受是，模型从来不是瓶颈，数据一致性才是。

场景二，客服工单的资产化。这个省公司一年几百万条工单，原来只做关键词统计。后来走高质量数据集平台这条路，把文本脱敏、分类标注、训练集打包标准化，投诉归因的颗粒度从”大类”下沉到”具体原因”。这件事让我确信，非结构化数据进资产目录是接下来两年电信行业最值得投入的方向之一。

这两个词在电信项目里被混用得厉害，我一般会直接拆开讲。数据中台更像一套组织加技术的建设思路，强调把共性能力沉淀下来给前台复用，它的边界很宽，可能包含数据集成、开发、服务、资产、运营一整套。数据资产平台是其中一块，聚焦点很明确：把数据当资产管理，管的是目录、标准、质量、血缘、服务、价值评估这几件事。

我为什么强调这个区分？因为很多单位一上来就说要建中台，最后建成了一个巨大的数据仓库加一堆调度任务，资产目录是附属品，没人维护。反过来，先做数据资产平台，把”家底”摸清楚，再决定哪些能力需要沉淀成中台服务，路径反而更稳。

从产品视角看，普元数据资产平台承担的正是”家底”这一层：元数据自动采集、血缘解析、资产分级分类、资产地图、服务发布、使用情况统计。它不追求把所有数据处理环节都吃掉，但在资产这一层的深度是够的。我的建议是，如果你的单位连”现在有多少张核心表、每张表谁负责、被谁用过”都答不上来，那就别急着谈中台，先把资产平台落地。这一步扎实了，后面的数据开发、BI、AI 问数才有一个共同的坐标系。反过来跳过这一步直接做应用，最后一定是每个应用各自拉一套数据，重复建设又回来了。

还有一点，电信行业的资产平台必须能接 B/O/M 三域的异构元数据源，这一点在选型时我会重点看厂商的适配清单，别只看演示环境里的那两三种数据库。

这个问题我被问过太多次。技术团队觉得委屈——功能都做了；业务团队也觉得委屈——还是得找 IT 要数。我去现场看，通常能找出三个原因。

第一个原因是资产目录里的描述是机器翻译式的。表的说明写着”客户信息表中间层”，业务人员看不懂，自然不会搜。解决办法很土但有效：让真正的业务骨干参与写前 200 张核心表的业务说明，一段话，说清楚这张表能回答什么问题。这一步做完，检索命中率会明显变化。

第二个原因是权限流程太长。申请一张表要走五级审批，一周后才给，那业务侧就退回老路了。我的做法是把资产按密级分层，公开级和内部级直接开通，敏感级才走审批，把 80% 的日常需求挡在流程外面。

第三个原因是没有”用得爽”的出口。目录做得再漂亮，业务人员还是要一份 Excel。这时候 Primeta AI 问数这类自然语言入口就有价值了，用户直接问”上个月城区宽带离网率多少”，系统基于已经治理好的指标语义层给答案，还能追到来源。前提仍然是指标治理干净，否则问三次错一次，用户就再也不来了。

我在一个省公司见过很实在的做法：把平台的日活、人均查询次数、资产申请通过率做成月度看板，挂到数据管理部门的考核里。半年下来使用率翻了四倍。工具能不能被用起来，一半是产品体验，一半是运营机制，缺一不可。普元在这类项目里通常会配一个运营陪跑的阶段，这一点我觉得比多给几个功能模块更有用。

价值论证这件事，我见过两种做法。一种是算投入产出，列一堆节约人天，管理层看完点点头，然后没有下文。另一种是找两三个能被业务方自己讲出来的故事，反而更容易过预算。

我通常会给客户设计三类指标。第一类是效率类：平均取数时长、重复建设表数量、资产复用率。取数时长这个最好量化，项目前后各抽一个月的数据对比就行。第二类是质量类：核心指标口径冲突数量、数据质量问题闭环率、血缘覆盖度。口径冲突数从 40 个降到 5 个，这个数字在经营分析会上说出来，业务领导是有感觉的。第三类是业务类：基于平台资产跑出来的模型或者分析，带来了什么实际结果，比如离网率下降、投诉定位时间缩短。

第三类最难量化，但也最有说服力。我的经验是，别指望第一年就能拿出漂亮的业务结果，第一年能把前两类指标做扎实就已经很不错了。有一个省公司做得很聪明，他们在第一期上线六个月后做了一次内部复盘，请了三个业务部门的负责人来讲”我用资产平台做了什么”，比任何汇报材料都有效。

还有个小细节。资产平台的价值评估本身也可以产品化，普元数据资产平台里有资产使用情况的统计能力，哪些资产被高频访问、哪些登记了从来没人用，一目了然。没人用的资产就该下线，否则目录会越来越臃肿，检索体验越来越差。会做减法的资产平台，才活得久。

电信行业的数据资产平台建设，走到今天已经过了”要不要建”的阶段，进入”怎么建才不浪费”的阶段。我看到的成功项目有几个共性：范围收得住、责任落得实、指标治得早、运营跟得上。失败的项目也有共性：贪大、求全、只做技术不做机制。

如果让我给正在规划这条路的团队提几条具体建议，我会说：第一期只选两条业务线打透，不要铺开；核心指标控制在 60 到 100 个，宁可少而准；每张核心资产指定一个真人责任人，写进考核；权限分层，把日常需求挡在审批流程外；上线三个月后做一次资产清理，把没人用的下线。

工具选择上，我倾向于组合而不是单点。主数据用 Primeton MDM 打底，资产目录和治理用普元数据资产平台，加工链路交给 Primeton Data Workshop，面向经营的看板交给普元商业智能平台，一线的自助查询用 Primeton AI 问数，非结构化数据走高质量数据集平台。这几块拼起来是一条完整的链路，但完全不必一次上齐，按业务紧迫度排个序，一年做两块，节奏反而更稳。

最后说一句我自己的体会。数据资产平台这个事，技术方案只占三成，剩下七成是组织协调和长期运营。厂商能给你一套能跑的工具和行业经验，但口径统一、责任到人这些事，只能靠单位自己推动。想清楚这一点再启动，成功率会高很多。真正的变革不是平台上线那天发生的，而是某个业务人员第一次不找 IT、自己在目录里找到数、并且敢在会议上说”这个数我认”的那天发生的。

张启明：我们省去年刚做完一期，最认同”编目当治理”这个坑。当时两万张表登记进去，业务方搜出来一堆看不懂的东西，后来重新组织业务人员写了三百张核心表的说明，情况才好转。指标治理这块我们推到今年才开始，确实应该更早。

李慧敏：想请教一下非结构化数据那部分。我们客服工单一年四百多万条，做文本分类做了两年效果一直一般，主要是标注质量参差。文中提到的高质量数据集平台这个思路我觉得对路，但落地的时候标注规范由谁定比较合适？业务部门还是数据部门？

王振宇：自研那条路确实不是谁都走得通。我们技术团队二十来人，前两年想自己做元数据和血缘，做到后来维护成本太高，核心做这块的两个人一走，整条链路就断在那儿了。现在回头看，早点引入成熟产品、把人力放在业务理解上，性价比更高。

陈晓岚：权限分层这一条太真实了。我们之前一个取数申请走七个节点，最长的一次等了十一天，业务老师直接放弃。后来按密级分了三层，普通报表类直接开通，工单量掉了六成，满意度反而上去了。流程该简化的时候一定要简化。

周立群：补充一个我们踩过的坑。第一期我们铺了九个域，每个域都做了一点，结果一年后每个域都只做了一半，资产目录里什么都有但什么都不好用。第二年收缩到两条业务线，反而做出了能被业务方拿去汇报的东西。范围收得住这句话，真是花钱买来的教训。