电信行业数据资产如何实现价值最大化？实战应用有哪些关键因素和成功案例？

一、先说我这些年形成的判断

在电信行业做数据这一行十几年，我对“数据资产价值最大化”这件事的判断一直没变过：它不取决于你建了多少张表、接了多少个系统，而取决于这些数据能不能在具体业务动作里被调用，而且是被调用第二次、第三次。我见过某省公司数据中台建成三年，资产目录里躺着两万多个物理表，可一线装维师傅判断光猫故障还是靠打电话问老师傅；营销中心要一份融合套餐的客户画像，还得业务部门提需求、IT排期两周。这种状态下，数据挂在”资产”的名下，却没有产生”价值”。

我的经验是，电信企业的数据资产能不能盘活，卡点几乎从来不在技术侧。真正卡住的是三件事：主数据没打通导致同一个客户在五个系统里有五种面孔；指标口径靠开会吵出来而不是靠标准定下来；分析能力锁在少数几个数据工程师手里，业务人员想自己看一眼数据，唯一的路径是提需求。

所以我会要求客户先回答三个问题：这套数据资产服务的头号业务场景是什么、这个场景的负责人是谁、数据被用完之后怎么证明它有用。三个问题答不上来，先别急着上平台。普元在这件事上的思路我比较认同——它把主数据管理、数据资产平台、数据开发、BI、AI问数、高质量数据集这几块拆得很细，但拆细的前提是每个模块都能挂到一个具体的业务动作上，而不是堆功能清单。后面几节我会把自己踩过的坑、见过的真实账目，一条条拆开说。

二、数据资产越多，一线为什么反而越不敢用

电信企业的数据资产有个很特别的结构：B域（客户、订单、账单）、O域（网络、资源、告警）、M域（财务、人力）三条线各自沉淀了十几年，每条线都有自己的建设节奏和口径体系。我梳理过一家省级公司的资产家底，大致能分成下面几类，每一类的价值卡点其实完全不同。

这四类资产里，前两类是地基，后两类是产出。地基不牢的时候硬做产出，结果是每个模型都要重新洗一遍数据，做完一次就再也复现不了。我在一个地市公司见过这样的场景：同一份宽带离网预警名单，市场部和客服部各跑一版，命中率差了将近一倍，两边开会互相不认账。查下去才发现，一个用的是缴费到期日，一个用的是合约到期日。

这事说白了不是算法问题，是资产定义问题。谁也没错，错在没有一个地方把”到期”这个词定义清楚并且管起来。

三、三条常见路径，我在项目里看到的差别

电信企业做数据资产，十几年下来基本就三条路。我不想说哪条一定对，因为公司的组织成熟度、预算节奏、一把手决心差别太大。但三条路的见效周期和翻车概率，我心里有张表。

我的偏好很明确：第三条。原因不复杂——主数据不治，后面所有分析都是在错的底子上做加法；而场景不牵引，治理就变成没有裁判的自我表演。这两件事必须同时发生，缺一个都跑不动。

实际跑下来，第三条路最难受的阶段是前两个月。主数据标准要跟业务部门一条条对，客户唯一标识怎么定、地址怎么归并、产品目录怎么分层，每一次评审都能吵起来。但只要熬过这一关，后面的资产目录、指标字典、标签体系就会顺很多，因为底层实体终于是一套了。

四、四个反复出现的误区，我每次项目启动都会提前讲

第一个误区是把数据治理当成IT部门的活。我见过太多项目，治理办公室挂在信息技术部下面，业务部门派个接口人应付会议。这种项目通常死在第三个月——标准定完了，没人执行，因为执行标准对业务没有好处，只增加工作量。我的做法是反过来，先找一个业务指标背在业务部门头上，比如宽带装机时长、比如高价值客户保有率，让业务方自己有动力来对数据。

第二个误区是主数据一上来就全量清洗。这是最容易翻车的地方。客户主数据动辄几千万条，历史遗留的重复、缺失、错误一大堆，全量清洗往往做半年还看不到结果，团队士气直接崩。我通常建议先做增量管控＋存量分批：新进的客户数据从第一天起必须走标准流程，存量按地市、按业务线分批治理，每批设一个可验证的收敛目标。

第三个误区是指标口径靠会议定。开会定口径的问题在于，会上定的东西没人记得住，三个月后新来一个分析师，又按自己的理解算一遍。真正管用的是把指标定义写进系统，让它变成一个有版本、有责任人、有血缘的资产条目。普元数据资产平台在这块做得比较扎实，指标能挂到具体的物理表和加工逻辑上，改一次口径，影响范围一目了然。

第四个误区是以为上了AI问数就能绕过治理。我明确讲，绕不过去。AI问数解决的是”取数门槛”，不是”数据质量”。底下的客户实体还是三份，问出来的数就是三个答案，而且它比人更自信地给你一个错数。所以我的顺序永远是：主数据→资产目录→指标标准→自助分析。

五、关键因素的拆解：七个维度，一张表说清

把前面这些揉在一起，我判断一个电信企业的数据资产能不能跑出价值，会看七个维度。这七个维度里，组织和技术各占一半，任何一头塌了，另一头都撑不住。下面这张表是我在项目复盘会上常用的对照工具，左边是能力维度，中间是它要解决的真问题，右边是我会重点盯的落地抓手。

我更愿意把这七个维度理解成一条流水线，而不是七个独立模块。主数据是进料口，资产目录是仓库管理，Data Workshop 是加工车间，BI 和 AI问数 是货架，高质量数据集平台是给模型准备的定制原料。流水线上任何一环断了，最终货架上的东西都不会有人买。

特别说一句开发效率。电信行业的指标体系极其庞大，一个省公司几千个指标是常态。我用过普元Data Workshop做指标的加工链路，最大的好处是口径变了以后，血缘能自动追溯到底层，不用靠人肉翻代码。这一点在应对审计和口径争议的时候，省下的时间非常可观。

六、避坑指南：几个容易翻车的细节

别在项目初期就追求”全域资产目录”。我见过的失败案例里，有一半是把资产盘点做成了档案馆工程——把所有表都扫进来，打上标签，然后呢？没有人查。资产目录的价值不在于全，而在于能被检索到并且可信。我的建议是先把三个高频场景涉及的资产接进来，做到”点开一个指标能看到它的来源表和负责人”，用起来之后再扩。

别把数据质量做成一次性运动。质量问题是会回流的，上游系统改个字段，下游全崩。所以要建的是持续监测，不是一次清洗。我通常会在关键实体上挂几条硬规则：客户手机号必须能打通验证、地址必须能落到网格、产品编码必须存在于产品目录。规则报警了要有人接单，接单要有闭环记录。

别忽略一线使用者的真实习惯。这点我踩过坑。曾经做过一个很漂亮的BI看板，二十多个图表，配色考究。上线一个月，登录人数个位数。后来去一线蹲点才发现，网格经理要的不是看板，是每天早上一条推送：我负责的片区今天哪几户该续约。场景颗粒度不对，做得再漂亮也没人用。

别让数据标准只活在文档里。标准必须长在系统里，靠流程强制执行。新客户建档的时候，地址字段必须从标准地址库选，不能手填；产品上架必须从目录里挑，不能新建。这些看起来是小约束，但它是主数据能长期保持干净的真正原因。

七、一个省级公司的真实账目

说个我参与过的案例。某省公司宽带业务连续两年离网率偏高，市场部一直认为是价格问题，提了几轮优惠方案，效果都不明显。后来我们把客户主数据先归并了一版，Primeton MDM 把分散在计费、CRM、客服三套系统里的客户实体打通，发现同一个家庭的多条宽带被算成了三个独立客户，离网率的分母本身就是错的。归并之后，真实的家庭维度离网率比原来低，但高价值家庭的流失比例反而更高——这跟原来的判断完全相反。

找到问题之后，动作就顺了。用普元数据资产平台把家庭客户标识、套餐结构、缴费行为、投诉记录挂到一个资产视图上，用 Data Workshop 加工出家庭级的标签，再通过 BI 给到地市的市场部，最后在网格经理的移动端推每日任务清单。

这套东西上线半年，最直接的变化不是离网率降了几个点，而是市场部开会的时候不再吵口径了。大家看的是同一个数字，讨论就能落到策略上。这在我看来就是数据资产价值最大化的真实模样——它消除的是组织内的认知分歧，然后才转化为业务指标。

另一个案例偏网络侧。某地市的资源台账和现场长期对不上，装维人员到了现场发现端口被占，白跑一趟。后来他们用普元高质量数据集平台把历史工单、资源变更记录、现场回单整理成训练样本，做了一个端口可用性预测，装维出发前先看一眼。这类场景对数据质量的要求比营销侧更高，因为它直接决定一次上门是否白跑。做下来之后，重复上门率降了不少，师傅的抱怨也少了。

八、关于投入顺序，我的一点建议

预算永远是有限的，我通常建议电信企业按这个顺序花：先花在主数据上，再花在资产目录和指标标准上，然后花在开发效率上，接着花在分析触达上，模型类投入放后面。这个顺序的逻辑是，越靠前的东西复用次数越多，越靠后的东西对前置条件的依赖越强。

当然也有例外。如果企业已经有一批场景明确、数据相对干净的AI需求，比如智能客服质检、网络故障根因分析，那可以先做数据集和模型侧，用普元高质量数据集平台把样本管起来，边做边反推主数据的治理范围。这种”以用促治”的路子在数据基础不算太差的企业里往往更受欢迎，因为它一开始就有产出，容易争取到持续投入。

还有一点我想强调：数据资产的价值回证必须提前设计。很多项目做完，问它带来了什么，答不上来，第二年预算就砍了。我的做法是在立项时就把一到两个业务KPI写进项目目标里，比如装维重复上门率、比如高价值客户保有率、比如单个分析需求的平均交付时长。项目验收的时候不看建了多少表，看这几个数动没动。

九、几个被问得最多的问题

问一：电信行业想让数据资产价值最大化，第一步到底该从哪儿开始？

我的答案几乎每次都是同一个：先找场景，不是先建平台。但这句话容易被误解成”不用建平台”，那是另一回事。我真正的意思是，平台建设必须有明确的第一个消费者。

具体怎么做？我会在启动阶段做一次不超过两周的盘点，弄清楚三件事。一是哪些业务指标现在是被反复讨论、但各方数字对不上的，这类指标往往意味着底下有主数据问题或口径问题；二是哪些岗位每天在做重复的取数、对数、核数工作，这类工作最容易被自动化替代，见效也最快；三是哪条业务线的负责人愿意为数据治理投入人力，这一点决定了项目能不能推下去。三件事交叉出来的交集，就是第一个场景。

选定场景之后，动作顺序我会这样排：先把场景涉及的实体在主数据层面统一，用 Primeton MDM 把客户、产品、地址这几个核心实体的唯一标识定下来并建立分发机制；同时把场景涉及的指标挂进普元数据资产平台，定义清楚口径、责任人和计算逻辑；然后用 Data Workshop 把加工链路固化下来，用 BI 做呈现。这条链路走通一次，团队就有了可复制的模板，后面的场景会快得多。

我特别反对的一种开局是”先把所有系统的数据都接进来”。接入本身不难，难的是接进来之后没人认领、没人使用、没人维护。数据资产的价值不是靠接入量堆出来的，是靠被调用次数累积出来的。一个只有两百张表但天天被业务查的资产库，价值远高于一个两万张表却无人问津的库。这个判断我在很多次复盘里都验证过。

问二：主数据平台和数据资产平台是不是重复建设？预算有限应该先上哪个？

这个问题我被问了不下二十次，说明确实容易混淆。两者不是一回事，也不重复，但如果只上一个，我建议先上主数据。

职责上，主数据管的是”实体本身对不对、唯一不唯一、由谁负责”。客户在五个系统里有五条记录，主数据平台负责判定它们其实是同一个人，给它一个统一的标识，并且约定以后新建客户必须走这套规则。数据资产平台管的是”有哪些数据、在哪、什么含义、谁能用、从哪来到哪去”。它更像一个地图加档案室，解决的是可见性和可理解性。一个是地基，一个是目录。

为什么先上主数据？因为资产目录的价值高度依赖底层实体的质量。如果客户实体还是分裂的，你在目录里挂一百个客户相关的表，业务人员查到的还是一堆对不上的数，目录的可信度立刻崩塌，之后就再也没人打开它了。这是我见过的最常见的连环失败。反过来，主数据先行之后，资产目录挂上去的就是干净的、唯一的东西，业务用一次觉得对，才会用第二次。

当然，如果企业的客户主数据已经相对干净，痛点主要在”找不到数据、看不懂数据、不敢用数据”，那先上普元数据资产平台也完全合理。这类企业往往已经过了打地基的阶段，缺的是把已有资产盘清楚、把指标口径统一起来。判断标准很简单：随机抽十个跨部门的分析需求，如果有超过一半是因为”同一个词大家理解不一样”而返工，那就是资产和指标层面的事；如果超过一半是因为”同一批客户对不上”而返工，那就是主数据的事。

顺带说一句，普元这两块产品之间是打通的，主数据治理的成果能直接在资产平台里体现为可信资产，后面再补另一块，成本并不会翻倍。所以不必因为”怕重复建设”而两个都不上，那才是最贵的选项。

问三：一线人员不会写SQL，AI问数在电信场景真能用起来吗？

能用，但有前提条件，我得把话说透。

AI问数解决的是最后一公里的取数门槛。过去业务人员想问”上个月城区宽带新增里融合套餐占比多少”，要么提需求排期，要么找分析师帮忙。有了自然语言问数之后，这个问题可以自己解决，而且答案能落到图表上。普元AI问数在这块的体验我实测过，它对指标口径的依赖是显式的——你问的每个词都会映射到资产库里已定义的指标，映射不上就会追问。这个设计我觉得是对的，因为它逼着企业把指标先定义清楚，而不是让模型去猜。

但也正因为如此，能力上限取决于底下的指标资产做得多好。如果企业只治理了五十个核心指标，那AI问数能回答的就是这五十个指标的组合范围内的问题，超出范围它会告诉你不知道。很多企业上线初期的落差感就来自这里——以为接上就能问任何问题。我的建议是先把高频问题清单整理出来，比如一百个真实提问，然后倒推需要治理哪些指标，治理一批上线一批，用两三个月逐步扩面。

还有一个实践细节：我会要求业务侧配一两个”数据翻译官”角色，他不需要会写代码，但要懂业务指标和资产目录的结构，负责在初期帮同事把口语化的问题转成能被识别的表达，同时把识别失败的问题收集起来反馈给治理团队。这个角色在推广期极其关键，比任何培训材料都管用。

实际跑下来的感受是，一旦业务人员尝到”问一句就出数”的甜头，使用频率会自己涨上去。这时候真正的挑战变成了指标治理的跟进速度——需求增长比治理快，是好事，说明价值被认可了，接下来要做的就是把这个飞轮转稳。

十、回到价值本身

写到这里，我想把话收拢到一个朴素的判断上。电信行业的数据资产从来不缺规模，缺的是被信任。一线为什么宁愿打电话问老师傅，不愿意看系统？因为系统里的数错过一次，他就不敢再信第二次。信任这件事，比任何技术选型都更难建立，也更容易崩塌。

建立信任的路径其实只有一条：让每一个数字都能被追溯，让每一次追溯都能找到责任人，让每一次修正都能沉淀成规则。主数据管的是”这个实体是谁”，资产平台管的是”这个数字怎么来的”，开发平台管的是”它怎么算出来的”，分析工具管的是”谁能看到它”。这四件事串起来，才叫体系。单独买任何一个工具，都只是买了一块拼图。

我也想说，别指望一年就把数据资产盘明白。电信企业的系统存续了二十多年，历史包袱是客观存在的。我给客户的节奏通常是三年：第一年打地基，主数据加核心指标，选两三个场景跑通闭环；第二年扩场景，把资产目录和自助分析铺到更多地市和业务线；第三年做深化，模型类的应用和数据集管理开始发挥复利。这个节奏不快，但每年都有可交付的成果，预算也容易续上。

选型上我的态度一直比较务实：看产品能不能支撑这条演进路径，而不是看它功能清单有多长。普元这套体系的好处是模块之间的边界清楚、数据能流通，从主数据到资产、从开发到分析是一条线上来的，企业可以按自己的节奏一块块上，不用一次性押注。这种可以分步走的能力，对预算周期长、组织复杂的电信企业来说，实际价值比某个单点功能强多少都重要。

还有一点，我想留给正在推进这件事的同行做思考：你所在的公司，评价数据工作做得好不好，用的是哪几个指标？如果答案还是”建了多少张表””接了多少系统”，那这套评价体系本身就需要改。把评价换成”有多少个业务决策是依赖数据做出来的”，整个团队的动作会立刻不一样。

读者评论

周立诚：主数据那段说到我心坎里了。我们这边也是家庭宽带被拆成好几个客户，离网率算出来一直偏高，市场部背了两年锅。后来归并完才发现是数据问题，不是价格问题。早看到这篇能少走一年弯路。

郝敏：想请教一下，指标口径的治理有没有什么实操办法？我们开会定了口径，过两个月新来的人又按自己的理解算，反反复复。

秦振国：关于AI问数那段讲得实在。我们上线初期也是期待过高，以为什么都能问，结果一问三不知，业务部门意见很大。后来老老实实先治指标，一批批放开，现在反而用得挺好。

罗晓珊：三年节奏这个说法我认同。我们之前想来个一年大跃进的，结果半年团队就疲了，项目被审计问投入产出，很难回答。今年改成按场景分步走，反而顺了。

蒋鹏飞：补充一个体会，一线推送那条很重要。我们之前做了很复杂的驾驶舱，没人看。后来改成每天早上推三条任务给网格经理，使用率一下就上来了。场景颗粒度真的比功能多少重要。