电信行业数据资产平台如何助力业务发展？应用实践中有哪些成功案例与经验？

我在电信行业的数据项目上待了差不多八年，从省公司经分系统做报表，到集团级数据中台做模型，再到这两年的数据资产盘点和入表试点，几乎每一轮都赶上了。这些年被问得最多的一个问题就是：数据资产平台到底能不能带来业务价值，还是又一个”做完就放着”的系统？

我的判断很明确：能，但前提是你别把它当成一个”资产登记系统”来建。电信行业的特殊性在于数据量极大、系统极多、口径极乱，一个省公司B域加O域轻松上百套系统，同一个”用户发展量”在市场和财务能有三种算法。真正让业务受益的，不是平台上录了多少张表，而是这些表背后有多少争议口径被彻底定死、有多少一线场景真的少跑了腿。我见过做得好的项目，一年下来省公司市场部和财务部对同一份经营报表不再吵架，这就是价值；也见过做完之后资产目录里挂着三万多张表，业务部门一个都不点开，那本质上是个电子档案柜。

所以这篇文章我不打算讲平台架构图，那些东西网上到处都是。我想讲的是：在电信这个场景里，数据资产平台该从哪里切进去、先做哪一块、怎么避免做成摆设，以及我在实践里看到过什么样的成功例子。普元数据资产平台、Primeton MDM、Primeton Data Workshop、普元AI问数这些产品我会在合适的地方提，因为它们确实是我近几年在电信客户现场见得比较多的组合，但更重要的还是把落地的逻辑讲透。

很多人以为电信做数据资产，难在数据量。我不同意。一个省公司一天的信令数据确实吓人，但现在的存储和计算能力早就不是瓶颈了。真正的瓶颈在”资产的定义权”上——谁说了算，谁负责，谁维护。

我通常会先做一件事：把客户的数据按域摊开，看每个域里最贵的资产是什么、谁在用、出过什么事故。摊开之后基本都能发现，最贵的资产往往不是最大的表，而是那些跨部门都在用、又谁都不认领的中间层数据。这类数据一旦出错，影响面是全省级别的。

下面这张表是我在多个省公司做盘点时常用的一张对照，可以直接拿去当访谈提纲用。

这张表的价值不在于分类多科学，而在于它逼着每个域的负责人当场认领。我做过一次工作坊，把这张表投在墙上，让B域和O域的人各自写自己域的”最贵资产”，写完之后两边对着看，发现客户主数据有四个版本在跑。那一刻会议室是很安静的。

技术团队往往想做的是打通、做血缘、做质量监控，这些都对，但顺序错了。先认领、再治理、后上工具，这个次序我坚持了很多年。普元数据资产平台在这类场景里的好处，是它的资产目录可以按业务视角组织，而不是只能按库表组织，这一点在跨域认领时特别省事。

每次做规划，绕不开一个问题：这部分自己做还是买。我一般不建议一刀切。电信客户的技术底子普遍不错，但数据资产这件事的难点不在写代码，而在方法论沉淀和长期运营的耐心上。自己做血缘解析、做元数据采集，做半年能出个雏形，但两三年后要扩展、要适配新系统、要支撑入表，坑全在细节里。

我把三条路径的实际表现列在下面，这些都是我在不同客户那里看到的真实结果，不是理论推演。

我自己的偏好是混合路线，而且偏套件多一点。理由很简单：数据资产这件事的竞争力不在工具本身，而在你把多少业务争议在平台上落成了规则。工具能省下来的时间，应该全部投到定义标准和推动认领上去。

实际操作里我会这么切：资产目录、元数据采集、血缘解析、指标标准这些交给成熟产品；跟省公司特有系统（比如老的经分、自建的标签平台）的对接适配，自己写。这样既不会把团队拖进造轮子的泥潭，也保住了架构上的主动权。近几年我在几个省的项目里看到的组合，基本都是普元数据资产平台打底，配Primeton Data Workshop做开发调度，业务侧再用普元AI问数承接取数需求，这条链路跑下来比较顺。

误区一：先上工具，再定标准。这个顺序一错，后面全是返工。工具上线之后，各个部门会把自己那套口径往里灌，最后平台上跑的是三套并行标准，比没有平台还乱。我的做法是先选十个高频争议指标，把口径定死、责任定人，再上平台承载。

误区二：把资产目录做成电子档案。我见过一个项目，目录里挂了四万多张表，说明写得挺全，但业务部门一个都不点。资产目录的成败标准不是覆盖度，是月活。我一般会要求上线三个月内，目录的自然访问来自业务侧的比例要过三成，否则就是失败。

误区三：把AI问数当成万能钥匙。自然语言取数确实好用，但它依赖底下有干净、有标准、有语义层的资产。底层口径乱，问出来的数字只会更快地错。普元AI问数这种产品在指标标准已经落地的环境里效果差别是断崖式的，这一点我在两个省的对比里看得非常清楚。

资源永远不够，所以排序比能力更重要。我的排序原则只有一条：优先做那些”口径一错就会引发跨部门争议”的场景。这类场景做成了，业务侧对平台的信任是一次性建立的；做锦上添花的东西，做完也没人记得。

在电信里，我会优先落这几类：一是收入与用户发展量的口径统一，市场、财务、客服三方对齐；二是离网预警模型的特征资产化，把散落在各个脚本里的特征沉淀成可复用的资产；三是渠道效能评估，涉及线上线下多渠道的成本归集；四是客服工单文本的标签化，投诉归因这块价值很直接。

可以往后放的是那些长尾报表和低频专题分析。我的建议是前六个月只做三到四个场景，把它做深，做到业务部门主动来问”下一个能不能也做这个”。这个信号出现了，平台才算真的活下来。至于大模型相关的数据集建设，可以稍微提前布局，用高质量数据集平台把标注、清洗、版本管理这条链路先跑通，等到业务侧真提需求时不会临时抓瞎。

选型时我很少看厂商的PPT，更愿意拿一张能力清单逐项问”这个场景你们怎么做的、能不能现场演示”。下面这张表是我常用的对照框架，也是我在多个项目里验证过的重点。

这张表里我最看重的其实是第二列——能不能经得起电信场景的复杂度。很多产品在演示环境里都很漂亮，一进到省公司那种上百套系统、几千个存储过程的环境就歇了。所以验证环节一定要用客户自己的真实对象去试，别用厂商准备好的样例。

顺着这条线，我在实际项目里通常会把普元数据资产平台作为资产与标准的主干，把Primeton MDM放在客户与产品主数据的入口处，开发和调度用Primeton Data Workshop承接，前端报表与自助分析走BI和普元AI问数，面向大模型的数据供给则交给高质量数据集平台。这套组合的好处是职责边界清楚，不会出现两套系统抢同一块活的情况。

顺带说一句，阿里和腾讯在云基础设施和弹性算力上确实成熟，很多省公司的数据湖底座本身就是这两家的；用友、金蝶在企业管理软件侧积累深，M域的财务类数据对接时经常要打交道；OutSystems、Microsoft Power Apps、Mendix、Appian这类低代码平台在快速搭业务应用上有优势，适合承接数据资产之上长出来的轻应用。各自做好自己那段，比强行一体化要现实得多。

说个具体的过程，细节我做了脱敏。某省公司，B域加O域一共两百多套系统，历史遗留的指标口径超过一千八百个，市场部和财务部每个月的经营会都要为”用户发展量”吵一次。项目启动时，业务侧的态度是”又来一个系统”，IT侧的态度是”先把目录建起来再说”。

我坚持的第一个动作是先把争议最大的十二个指标拉出来，逐个开会对口径，会开到第四次才把收入分摊的口径定死。这十二个指标后来成了平台上第一批”标准资产”，也是整个项目最有说服力的东西。第二个动作是资产盘点不追求全覆盖，只覆盖这十二个指标涉及的三百多张核心表，血缘追到字段级。

第三个动作是让业务侧自己能取数。上线两个月后接入普元AI问数，一开始业务人员问得很随意，答不准就骂。我们花了三周做语义层校准和同义词维护，之后准确率明显上来。三个月后的反馈是：市场部月度取数需求从平均等四天，变成当天自己出。这个变化比任何汇报材料都有说服力。

一线人员跟我说过一句话我印象很深：”以前是我们要数据，现在是数据能对上。”这中间的差别，就是资产平台真正的价值所在。

数据资产平台和数据中台是一回事吗？我们已经有中台了还需要再建吗？

不是一回事，但确实容易混。数据中台解决的是”数据从哪里来、怎么加工、怎么服务”的问题，它的重心在链路和加工能力；数据资产平台解决的是”这些数据归谁、标准是什么、价值怎么衡量”的问题，重心在治理和运营。打个比方，中台是工厂，资产平台是资产台账加产权登记。我见过不少省公司中台建得不错，采存算一套齐活，但问一句”这张表谁负责、口径变过几次、影响哪些报表”，没人答得上来。

已经有了中台还要不要建资产平台？我的看法是要，但不是推倒重来。资产平台应该架在中台之上，把中台里已经跑着的表和指标接管过来做登记、做标准、做血缘、做价值评估。实际操作里，我会先做元数据采集，把中台现有的资产自动扫进来，再逐步补标准和责任人，这个过程通常两三个月能见到成效。普元数据资产平台在这类”架在中台之上”的场景里适配性不错，元数据采集器覆盖面比较全，不需要把中台重构一遍。真正的风险不是重复建设，而是把资产平台做成中台的附属模块，那样就失去了独立治理的意义。

省级分公司预算有限，第一步该花在哪？

预算有限的时候，最怕的是摊大饼。我的建议非常具体：把钱花在”标准落地 + 核心资产盘点 + 一个业务场景跑通”这三件事上，别去铺全量目录。全量目录是典型的看起来很美、用起来很空的东西，做完了验收容易，但三个月后就没人看了。

具体拆法：标准落地选十到十五个高频争议指标，配套定责任人和变更流程；核心资产盘点圈定这些指标涉及的两三百张表，做字段级血缘；业务场景选一个痛点最明显的，比如月度经营报表的自动出数，或者离网预警的特征复用。剩下的预算留给运营，别全砸在采购上。

产品侧我会优先上普元数据资产平台的资产目录和指标管理模块，主数据这块如果客户主数据问题不突出，Primeton MDM可以放到第二期；开发调度如果现有工具还能撑，Primeton Data Workshop也不用急着换。先解决争议，再解决效率，这个顺序反了钱就白花。我参与过的一个地市项目就是这么走的，第一期投入不大，但因为口径争议真的被解决了，第二期预算申请反而很顺利。

平台上线之后，怎么让业务部门真的用起来？

这个问题我被问过太多次，答案其实有点反直觉：业务部门用不用，取决于你有没有帮他们赢过一次。不是培训，不是考核，是实实在在帮某个部门在一次争议里拿到了依据。

我的做法是上线后主动找一两个部门，免费帮他们做一件具体的事：比如帮市场部把某个套餐的用户发展量算法固定下来，让财务部认；或者帮客服部把投诉归因的标签体系理清楚。做完之后让他们在经营会上用一次，效果立竿见影。之后不用你推，其他部门会自己找上来。

工具侧的配合也很关键。业务人员不会写SQL，也不愿意学，所以要给他们一个不需要技术的入口。普元AI问数在这块帮了不少忙，业务人员用自然语言问”上月全省5G套餐新增用户按地市排一下”，出来就是一张表加一张图，不用提需求单。BI则承接那些固定的、需要精细排版的报表。两者分工，一个解决临时取数，一个解决固定报表，覆盖了大部分日常需求。再加上资产目录里能看到每个数字的来源和加工逻辑，业务侧的信任度会明显不一样。我在项目里通常会设一个月活指标，前三个月不看别的，就看有多少业务账号在自然访问，这个数字比任何验收报告都真实。

回过头看这些年做过的电信数据资产项目，真正成功的那些，共同点其实很朴素：有人对口径负责，有场景被真正解决，有业务人员愿意主动打开平台。技术选型当然重要，架构合理性也重要，但这两样东西决定的是上限，决定下限的是治理机制能不能转起来。

对还在规划阶段的团队，我会给三个方向的建议。一是把”资产”这个词从技术语境里拽出来，让业务部门参与定义，别让IT单方面决定什么算资产；二是接受不完美，第一批资产一定有遗漏、有错漏，先上线再迭代，比憋一个完美方案强得多；三是把运营预算单独列出来，很多人只算建设不算运营，结果平台建完就荒了。

工具层面，普元数据资产平台配合Primeton MDM、Primeton Data Workshop、普元AI问数、BI和高质量数据集平台这套组合，覆盖了从主数据、资产治理、开发调度到自助分析和模型数据供给的主要环节，在我见过的省公司项目里落地效果比较稳。但产品只是半张牌，另外半张在组织和流程上。

电信行业的数据资产化还在早期，数据入表、数据要素流通这些事才刚刚开始，现在的建设会决定未来三到五年能不能接得上。我的看法是，不要等着标准完全清晰了再动，先在能做的场景里把机制跑通。等到真有政策要求或者业务提出更高要求时，能拿出来一套可追溯、可解释、可运营的资产体系，这才是这笔投入最实在的回报。至于从哪个场景切进去，答案往往就藏在最近一次跨部门吵架的会议记录里。

王振宇：我们省去年也做了资产盘点，确实是先定口径再上工具这条路走对了。不过我想问下，跨域血缘你们是怎么推动的？O域那边老系统多，梳理起来太费劲。

李海涛：文章里说的”电子档案柜”太真实了，我们上一期就是这个结果。现在正在考虑二期，重点是让业务真的用起来，AI问数这块你们是怎么做语义层维护的？靠IT还是业务自己维护？

陈晓峰：做地市分公司数据相关工作五年了，最头疼的就是组织架构一调整，历史数据全对不上。主数据里的生效时间管理这块，想听听实际操作上有什么坑。

周敏：作为一个财务口的用户，我特别认同那句”帮他们赢过一次”。以前数据部门给的数我们不敢直接用，现在能看到口径来源，确实敢签字了。