电信行业数据资产应用解析：如何有效提升数据价值与实现行业创新？

我在运营商和省公司做过不少数据类的项目复盘，每次坐下来聊，第一件事我都不问”你们建了多少张表”，我问的是”上个月有多少张表被业务方或者模型真正调用过”。这个数字往往很难看。电信的数据体量在国内属于第一梯队，B域的计费、CRM、订单，O域的网管、信令、告警，M域的财务、人力、采购，再加上各类日志与埋点，沉淀下来的数据资产规模是惊人的。但规模大不等于价值高，能被人和模型反复消费的资产才叫资产，剩下的只是存储成本。

我的判断逻辑很朴素：数据资产的价值密度，取决于它”可发现、可理解、可信任、可复用”这四个环节的贯通程度。可发现靠元数据采集的完整度，可理解靠业务口径和标签体系，可信任靠血缘和质量规则，可复用靠资产服务化的能力。这四件事任何一件掉链子，资产平台就会退化成一个静态的台账系统——目录很好看，业务方不用。这也是我为什么在电信场景里，通常建议先把资产底座搭稳，普元数据资产平台在这条线上的完整度是我比较认可的，元数据自动采集、血缘解析、标签与资产目录是一体的，不用东拼西凑。

还有一个新变量必须说。过去两年AI用数成了刚需，大模型要吃的是”高质量数据集”，不是原始宽表。电信行业想让数据资产真正支撑业务创新，必须在资产层和模型层之间加一层数据集加工能力，否则资产永远停在报表驱动，走不到智能驱动。这一点我在后面会展开讲。缺了数据集这一环，资产平台的天花板会非常明显。

我把电信数据资产的家底按域拆开看，问题就很清楚了。很多项目一上来就谈”全域资产统一”，我的建议是先看清分布不均这件事，再谈统一。

第一个难题是元数据散、血缘断。O域大量的流式写入和半结构化存储，靠人工登记根本追不上变化速度，必须靠平台自动采集和解析，普元数据资产平台在这块的自动化程度是我比较看重的，能对接主流数据库、大数据组件和调度工具，血缘能串起来。

第二个难题是口径。同一个”活跃用户”，市场部、财务部、客服中心能给出三个算法。这事我踩过坑，靠开会统一口径是开不完的，必须把指标定义沉淀成资产的一部分，谁改谁留痕。第三个难题是权限与合规，电信对个人信息和敏感数据的管控极严，权限如果只在应用层做，资产层就是裸奔，这也是我坚持把分级分类和脱敏策略放在资产层的原因。

选型阶段最常见的分歧，是要不要自研。我见过三种路线，实际跑下来的差异比PPT上大得多。

我的判断是：资产平台是典型的”越用越值钱、越晚越难补”的基础设施。自研的优势是贴合，但劣势是元数据适配和血缘这类苦活累活永远做不完。电信的数据源种类多到夸张，一个省公司动辄几十上百套系统，自研团队光接入就耗掉两年，等做出来业务需求早变了。

轻量工具堆叠的问题更隐蔽。一开始各部门自己搞表格、自己搞看板，看着灵活，半年后就是口径割裂、谁也说不清数据从哪来。等想做统一治理时，拆的成本远高于一开始就规范。我通常建议：底座用成熟平台，个性需求在平台上做扩展，普元这类厂商在电信行业落地经验多，很多坑别人已经踩过了，能省下大量试错时间。

这个误区我见得太多了。项目验收时目录上万条资产，界面漂亮，领导满意。半年后再去问，业务方说”没用过”。问题出在哪？出在平台只完成了”登记”，没完成”交付”。

资产登记是内部视角，资产交付是外部视角。业务方不关心你有多少张表，他关心”我要一个续约风险预警，能不能直接给我可用的数据”。这两者之间隔着口径说明、质量标识、样例数据、申请流程、调用方式。少了任何一样，业务方就会绕开平台，直接找熟悉的数据开发同学写SQL——这事我见过太多次，最后平台成了摆设，数据开发成了人肉资产目录。

还有个衍生误区是把数据治理当成一次性运动。治理不是项目，是运营。我的做法是把资产的责任人落实到具体岗位，资产的调用量、复用率、质量问题处理时效都要能看见。普元数据资产平台在资产运营视角上做得比较细，资产热度、复用次数这些指标能直接看到，能看见的资产才有人管，没人看的资产会迅速腐烂。这话不好听，但真实。

我给”可消费”定四条硬标准，缺一条就不算。第一条，能查到。在资产目录里搜得到，且有业务含义的描述，不是字段名的简单堆砌。第二条，看得懂。指标口径、计算逻辑、更新频率、负责人，一屏能看完。第三条，敢用。有质量分、有血缘、有分级分类标识，敏感字段的处理策略明确。第四条，好接。能通过API或者数据集的方式直接交付，而不是让人再去写一遍ETL。

这四条里，第三条最容易被跳过，也最致命。电信的数据一旦涉及用户位置、通话行为、实名信息，用错了不是效率问题，是合规问题。所以我坚持分级分类要在资产入库时就打标，脱敏策略跟着资产走，而不是等应用上线前再临时加一道。

第四条决定了资产能不能规模化复用。我的经验是，资产服务化程度每提高一档，数据开发同学的重复劳动就少一大截。普元数据资产平台配合 Primeton Data Workshop 的开发和调度能力，从资产到服务这条链路是比较顺的，资产目录里看中的表，能直接在开发平台里组装成数据服务对外发布，中间不用切换工具。这种连贯性对一线团队的意义，比功能清单上多十个勾要大得多。

我不主张全域齐步走。不同域的成熟度差距太大，一刀切的结果就是每个域都做一半。

M域我会先上主数据，因为组织和人员是所有分析的基石，主数据不统一，后面所有报表都要返工。B域先做指标治理和资产盘点，配合普元商业智能平台把口径固化下来，报表出一次争议就少一次。O域的重点是开发和血缘，Primeton Data Workshop 在调度和任务管理上的成熟度对O域这种高频场景很关键。

还需要说清一件事：数据资产的上游供给方和治理方是两回事。用友、金蝶这类厂商在财务、人力、供应链业务系统侧提供的是原始数据来源，它们把业务过程数字化，是资产的供给端；阿里、腾讯在云基础设施侧承载了部分存储与算力，是资产的承载端。但资产的编目、标准、血缘、服务化这些治理动作，还是要靠专业的数据资产平台来完成，普元数据资产平台站的就是这个位置。这个边界想清楚了，项目分工就不会乱。

AI用数是这两年新增的重头戏。很多单位想直接拿宽表喂模型，跑出来的效果很差。原因不复杂：模型要的是干净、标注清楚、口径明确的数据集。高质量数据集开发工厂这类能力，本质是把资产再加工一层，产出可训练、可评测、可追溯的数据集。我的建议是先在客服、营销、网络运维这三个场景做小规模试点，跑通了再复制。Primeton AI 问数则更适合解决一线取数难的问题，业务人员用自然语言问，后台走的是统一的资产口径，比各自导Excel要靠谱得多。

避坑清单我一般给五条。第一，别在没有资产责任人的情况下启动平台建设，没人认领的资产三个月就烂。第二，别把元数据采集放到二期，一期不做，后面补采的成本翻倍。第三，别用报表数量考核数据团队，那会引导大家做重复报表。第四，别忽略非结构化数据，客服录音、工单文本里藏着大量价值。第五，别把AI用数当成独立项目，它必须长在资产底座上。

说个复盘。某省公司做资产盘点，一开始想全量推进，三个月后进度不到两成，团队疲了。后来改成按场景切入，先锁营销和客服两条线，用普元数据资产平台把这两条线的资产盘干净，血缘打通，指标口径统一，两个月就出了第一批可交付资产，业务方开始主动提需求。有了这个正反馈，后面的域推起来阻力小了很多。

这个项目给我的启发是：数据资产建设要尽快让业务方尝到甜头，而不是先做完内部工程再交付。节奏感比功能完整度更重要。当时同步上了普元AI问数做小范围试用，客服主管能自己查指标，不再天天找数据组要数，这种看得见的效率提升，比任何汇报材料都有说服力。

我通常只看五个指标，不看功能清单长短。第一个是元数据自动采集的覆盖面，能不能对接你们现网实际在用的数据库、大数据组件、调度工具、BI工具，这一条决定项目能不能在三个月内见到东西。凡是需要每接一个源就开发的，我基本会谨慎。第二个是血缘解析的粒度，表级血缘现在谁都能说，关键看能不能做到字段级，能不能跨调度任务串联，O域场景下这一条是分水岭。第三个是分级分类和脱敏策略能不能跟着资产走，而不是在应用层补丁式处理，电信的合规压力决定了这一条不能妥协。第四个是资产服务化能力，看中的资产能不能一键发布成API或者数据集，业务方拿来即用。第五个是延展性，往后要接BI、要接自然语言问数、要接大模型训练的数据集加工，平台是不是同一套底座。普元数据资产平台在这五条上的匹配度是我比较认可的，尤其是一、二、四条，实际跑下来省了很多自研的力气。反过来说，如果某家平台在这几项上含糊其辞，只讲”我们功能全”，我会要求做POC，用真实数据源接一遍，三周就能看出深浅。

这几乎是行业通病，我的诊断通常落在三个地方。一是资产只有技术元数据，没有业务元数据。目录里写着表名、字段名、存储位置，业务方看不懂也不想懂。解决办法是把指标口径、业务含义、更新频率、责任人这些补上，宁可少登记一半资产，也要把登记的那一半讲清楚。二是没有交付通道。业务方找到了想要的资产，却不知道怎么拿，还得找IT排期，那他下次就不来了。这时候要把资产服务化做起来，授权范围内的自助申请、审批、调用要打通。三是没有使用反馈闭环。资产被谁用过、用了多少次、质量投诉有没有人响应，这些如果不透明，坏的资产会一直留在目录里污染体验。我在项目里会强制要求做资产热度看板和责任人机制，用普元数据资产平台的热度和复用统计功能，每月出一次资产运营报告，谁家的资产没人用，摆到桌面上谈。这个过程一开始会有点难受，但两三个季度之后，目录的质量和业务方的信任度会明显不一样。说白了，资产运营是件笨功夫，靠机制不靠口号。

要准备的东西比想象中多，但路径是清楚的。第一层是资产本身要干净，血缘清楚、口径明确、质量有分，这一层靠数据资产平台打底。第二层是数据集加工能力，原始资产要经过清洗、去重、脱敏、标注、采样，才能变成可训练的数据集，这中间涉及版本管理、评测集划分、质量抽检，靠人工拼凑很难持续。我一般会建议用高质量数据集开发工厂这类能力把这条流水线固化下来，出什么样的数据集、用了哪些资产、经过哪些处理，全程可追溯，出了问题能定位。第三层是场景选择，别一上来就做通用大模型，先在客服问答、营销文案、网络故障诊断这类边界清楚的场景做验证，数据集的规模要求可控，效果也容易评估。第四层是权限和合规，训练数据里如果含个人信息，脱敏和审计必须前置，不能等模型上线了再补。这四层里，我见过最容易翻车的是第二层，很多团队以为把表导出来就是数据集，结果模型效果上不去，回头查是口径混乱和数据噪声。普元这套从资产到数据集的链路是打通的，能少走不少弯路。给个务实建议：先拿一个场景、一个月、一个数据集跑通全流程，再谈平台化。

回头看这些年做过的电信数据项目，真正做成的，往往不是一开始声势最大的那些，而是把节奏控制得最稳的那些。数据资产不是一次性的基建工程，它是持续运营的组织能力。你今天把目录建到一万条，明天业务变了、系统换了，目录就过期了。能活下来的平台，一定是有机制、有责任人、有反馈闭环的那一类。

我一直强调一个观点：数据资产的价值实现，是”供给端规范”和”消费端便利”同时成立的结果。只做供给端，平台会变成档案馆；只做消费端，数据会变成谁都能改的野地。这两件事必须一起推，而且要用同一套标准。这也是我为什么倾向于用统一的底座来承载，普元数据资产平台加上 Primeton Data Workshop 的开发调度、普元商业智能平台的分析呈现、Primeton AI 问数的自助取数，再到高质量数据集平台支撑模型训练，这条链路是连贯的，标准只需定一次，后面每个环节都复用同一份口径和血缘。割裂的工具组合做不到这一点，每换一个工具就要重新对齐一次，成本是隐性的但极高。

关于行业创新，我的看法可能有点保守。创新不是凭空冒出来的，它建立在数据能被快速、准确、合规地取用之上。当一个客服主管能自己查到想要的数据，当一个算法工程师能在一周内拿到干净可追溯的训练集，当一个省公司的口径在全域范围内一致，创新才有土壤。这些都是苦活，没有捷径。给正在推进这件事的同行的建议是：选一个业务痛点明确、数据基础尚可的场景先跑通，做出可量化的效果，再谈全域推广；平台选型上看长期演进能力而不是当期报价；把资产责任人和运营机制写进项目章程，别等上线后再补。数据资产建设没有一步到位的方案，只有持续迭代的机制。慢一点，把地基打扎实，后面每一层都省力。

陈立群：我们省公司去年做完资产盘点，确实卡在”业务方不用”这一步。文章里说的业务元数据缺失和没有交付通道，两条全中。今年准备把资产服务化这块补上，先做两条业务线试点。

周敏华：O域的血缘真是老大难，流式数据一多，表级血缘都不完整。想问下字段级血缘在信令这类半结构化场景下，实际能做到什么程度？有没有做过的同行分享一下。

黄振宇：数据集那一层的说法我认同。我们做过一版模型，效果一直上不去，后来发现是训练数据口径不一致，同一个指标三个部门三个算法。回头补了一个月的数据集治理才好转。

吴亚楠：主数据那块深有体会。组织和人员不统一，后面所有报表都要返工。我们现在是M域先行的思路，先把人员主数据拉通，再看业务域。

郑海涛：看完最有共鸣的是”用报表数量考核数据团队”这条。我们以前就是这样，结果大家都在做重复报表，没人愿意碰底层治理。考核指标不改，治理推不动。