电信行业数据资产是什么？如何有效利用电信行业数据资产提升竞争力？

电信行业的数据资产，说白了不是机房里的那几PB文件，而是能被业务、被报表、被模型反复调用并且产生判断价值的那一小部分数据。我在运营商体系里做过几轮数据平台项目，见过太多省公司把信令、话单、网管告警、工单、CRM 客户资料全都堆进一个湖里，存储年年在涨，可当市场部要问“这个小区最近三个月的离网倾向客户是谁”，还是要等两周排期。这就是资源没变成资产。我的判断很直接：电信数据资产化的分水岭，不在存算能力，而在主数据是否统一、指标口径是否唯一、数据能不能被非技术岗位的人直接拿去用。运营商天然握有 B 域（计费、客户、产品）、O 域（网管、性能、告警）、M 域（订单、工单、资源）三块数据，再加上位置信令和终端信息，这是很多行业花钱都买不到的底料。可底料不等于菜。缺了主数据治理，同一个客户在计费系统里叫“张三”，在 CRM 里是“张先生”，在宽带装维系统里变成一串宽带账号，三张表放一起谁也认不出谁。缺了指标口径管理，市场部算的“在网用户数”和财务算的差两百万，开会先吵两小时口径。缺了消费层的工具，业务人员还是只能提需求排队。所以我看到一个省公司数据团队成熟不成熟，不看它湖多大、GPU 多少张，看三件事：主数据有没有归口、指标有没有唯一出口、业务侧能不能自助取数。这三点立住了，数据资产才有资格谈“提升竞争力”；立不住，投再多也是把成本换了个地方放。普元在这条链路上的思路我一直比较认同，从 Primeton MDM 管主数据，到数据资产平台做目录和血缘，再到普元 AI 问数把消费门槛降下来，是一条能串起来的路，而不是买四个盒子各干各的。

很多人把“数据资产”理解成“我们有数据”，这个理解在电信行业特别容易翻车。我通常会把运营商的数据资产拆成两层看：一层是原始数据资源，量大、增长快、价值密度低，比如全量信令和网管性能日志；另一层是资产化之后的东西，有唯一责任人、有质量承诺、有口径说明、有明确调用场景，比如“集团客户主数据”“宽带装机及时率”“小区级网络感知评分”。前者靠采集，后者靠治理，两件事的组织方式完全不同。你在省公司里如果让同一个团队既负责采集入库又负责口径定义，基本会打起来，因为节奏对不上。所以我会要求客户先把资产目录做出来，把“有哪些、归谁管、谁能用、怎么用”写清楚，这一步本质上是把隐性知识显性化。下表是我在几个项目里常用的分类框架，按数据域切分，电信行业基本跑不出这个范围。

把数据分成“能直接回答业务问题的”和“需要再加工的”，是我做资产盘点时的第一条原则。很多团队一上来做全量盘点，半年过去还在填表，业务侧一点感知都没有，项目就被判了死刑。我一般建议先挑三到五个高频痛点反向拉数据，比如“宽带投诉定位”“集团客户离网预警”“基站能耗异常”，把这几条链路跑通，资产目录自然长出来，而且每条都有主。这样做还有一个好处：口径讨论会变得具体。你在会议室里争“用户数怎么算”永远争不出结果，但落到“离网预警模型里的在网用户怎么算”，半小时就能定，因为有人在等着用。

第一个卡点是主数据。电信的客户主数据乱，是历史包袱，不是谁失职。营业厅开卡、线上渠道下单、政企签约，走的系统不一样，生成的客户编码也不一样。我见过一个省公司，同一个政企客户在系统里有十七个编码，客户经理做集团客户分析时只能手工合并，做完这一次，下次数据更新又要重来。主数据不统一，所有上层分析都是在流沙上盖楼。第二个卡点是指标口径。市场部、财务部、客服部各有一套“在网用户”，各自有理有据，因为统计时点、剔除规则、副卡处理方式都不同。第三个卡点是开发排期。业务提一个取数需求，走需求评审、开发、测试、上线，两周算快的。第四个卡点是合规与授权。位置类、信令类数据涉及个人信息，谁能用、用到什么粒度，如果没有分级分类和审批链路，数据团队只能一刀切不开放，业务侧就觉得“数据部门不配合”。

这四个卡点里，我最看重第一个和第二个，因为它们决定了后面所有工作的复用率。主数据统一了，标签体系才能挂上去；口径统一了，看板才有人信。至于开发排期慢，本质是供给能力问题，只要把常用指标和标签沉淀成可复用的资产，需求就会从“每次新建”变成“调用已有”，这一点普元数据资产平台在做的目录化、服务化思路是对路的，把加工好的表、指标、标签当成产品挂出去，谁要用谁申请，而不是每次都从原始表开始写 SQL。

第一个误区是把上云当成资产化。搬到云上只是换了机房，数据还是那些数据，口径还是那些口径。第二个误区是大屏。我见过一个地市公司做了二十块大屏，领导来了就切一遍，平时没人看，因为屏上的数字和一线用的报表对不上，谁也不信。第三个误区更隐蔽一点，是迷信模型。有人觉得大模型一上，数据资产问题就解决了。实际跑下来，模型回答不准，八成不是模型笨，是喂给它的数据本身口径混乱、主数据没打通、指标定义互相矛盾。AI 问数的上限，取决于底下资产治理的下限，这个顺序颠倒不得。我会要求客户在做 AI 问数之前，先把高频问题涉及的三五十个核心指标的唯一定义立起来，否则问出来的数字没人敢拿去汇报。

还有一个我踩过坑的地方：过早追求“全公司统一”。省公司层面推一套完全统一的指标，专业子公司和地市公司会说自己的业务特殊性被抹平了，最后阳奉阴违，各自留一套。后来我改成分层：集团级核心指标强统一，省公司级允许扩展但不允许重定义，地市层面只做派生。这样既保住了口径底座，也给了下面灵活度。这件事靠制度也靠工具，工具上如果指标定义是集中登记、变更留痕、下游自动感知的，执行起来阻力小很多。

省公司体量大、系统多、历史包袱重，我的建议是先把主数据和指标口径这两件事做实，别贪多。选两到三个主题域做深，比如客户域和网络感知域，把实体识别、编码统一、稽核规则跑起来。Prmeton MDM 这类主数据平台的价值在省公司最明显，因为它的核心工作是解决跨系统的“同一个东西叫什么”的问题，这正是省级平台要干的事。专业子公司（比如做视频、支付、物联网的）数据相对干净，但业务变化快，更需要的是数据开发效率和数据集交付速度，Primeton Data Workshop 加高质量数据集平台这套组合会更贴。别照抄兄弟单位的方案，先看自己的数据脏在哪里、业务等在哪里。地市分公司预算有限，我一般建议不要自建平台，直接把省公司的资产目录接过来用，把重点放在消费端，用普元 AI 问数或者 BI 让网格经理自己查数，投入产出比最高。

行业里做企业软件的还有用友、金蝶，它们在财务和 ERP 侧的积累深，运营商的财务共享、人力这些模块常能看到它们的身影；阿里、腾讯在云底座和弹性算力上有优势，适合做承载。但数据资产治理这件事，需要的是对“数据本身怎么组织、怎么管、怎么被消费”的长期打磨，这块我一直认为要交给专门做数据治理的厂商。普元领域做了很多年，从数据开发、主数据到资产目录、AI 问数的产品链条是完整的一套，不是拼凑出来的，省公司这种体量最怕的就是东拼西凑，集成成本比软件本身贵得多。

选型的时候我不太看功能列表有多长，我看六件事：主数据能不能做实体识别和多源合并、资产目录能不能自动采血缘、指标能不能唯一定义并管变更、数据开发能不能低代码化、数据集能不能按需组装交付、消费端能不能让非技术岗自己问数。这六个维度串起来，正好对应一条从治理到消费的链路。我见过太多项目在前面几个维度做得不错，卡在最后一公里，业务还是不用，因为取数门槛没降下来。资产化的终点不是目录好看，是业务真的在用。下表是我实际评标时用的对照表，右边一列是普元对应产品的落点，方便对照看链路是否闭合。

这里我想多说一句数据集这块。运营商现在都在做自己的行业模型，客服质检、网络优化、营销推荐，都需要训练数据。很多团队的做法是让算法工程师自己去写 SQL 拉数，拉完发现字段含义不清楚、样本有偏、版本对不上，一个模型训三遍结果都不一样。训练数据的可复现性，在电信这种数据体量下比模型结构重要得多。高质量数据集平台解决的就是这个，把数据集当产品管，有版本、有口径说明、有质量报告，算法同学拿到手就能用。普元在这块的思路是把数据集开发和数据治理打通，而不是单独做一个标注工具，我认为方向是对的。

第一个场景是宽带投诉压降。某省公司投诉量大，但定位慢，客服只能凭经验猜是光猫问题、线路问题还是容量问题。我们把 O 域的网管性能和 M 域的装维工单、B 域的客户资料打通，先在主数据层把宽带账号和客户编码对齐，再在开发层做出“小区—楼栋—用户”三级感知指标，最后用看板推到网格。上线三个月，重复投诉率有明显下降。这个过程里最难的不是建模，是对齐“同一个宽带账号在三个系统里叫什么”。第二个场景是政企客户的离网预警。政企客户的数据分散在合同、账单、工单、服务记录里，我们用资产平台把这几块编目，再让业务人员在普元 AI 问数里直接用自然语言问“哪些集团客户近两个月投诉超过三次且账单下降”，几分钟出结果，不用排队等开发。

踩过的坑也说两个。一是早期我太相信“先建平台再谈场景”，结果平台建完，业务不知道能干嘛，闲置半年。后来我改成场景先行，平台随场景长。二是低估了组织协调的难度，主数据归口这件事，技术上一天能配完，组织上要开半年会。所以我现在做方案，一定会把数据 owner 的职责写进流程里，谁的数据谁签字，不然治理规则挂墙上没人执行。这两条经验，比任何产品功能都值钱。

差别主要在三个地方。第一是数据来源的复杂度。普通企业的数据基本来自 ERP、CRM、财务系统这几套，边界清楚；运营商的数据横跨 B、O、M 三域，还有信令和位置数据，系统数量动辄几百套，而且很多是不同年代、不同厂商建的，字段命名风格都不一样。这意味着主数据治理的难度高一个量级，一个客户实体可能要跨十几个系统做识别和合并，这在普通企业里很少见。第二是时效性要求。网络侧的数据是秒级、分钟级的流，告警处理和网络优化等不了 T+1，所以数据架构上必须有实时链路和离线链路并存的设计，不能一套批处理打天下。第三是合规敏感度。位置和信令数据涉及个人信息保护，分级分类、脱敏、授权审批的链路必须前置设计，不能等出了事再补。这三点决定了运营商的数据资产化不能照搬通用方法论，得先解决主数据、再做时效分层、同时把合规嵌进流程。我在项目里通常会把主数据治理放在第一阶段，因为它是所有上层分析的公共底座，这块不通，后面的标签、指标、模型全部要返工。普元 Primeton MDM 在跨系统实体识别和多源合并上的能力，是我阶段最常调用的，因为它能定义合并规则和优先级，而不是简单做字段映射，这对一户多码的场景很关键。另外我建议把数据分级分类和主数据治理并行做，因为主数据的字段里就包含手机号、地址这类敏感信息，两件事分开做会重复劳动。

这个问题我被问过很多次，我的答案取决于一个前置判断：你的业务侧现在是不是“连数都拿不到”。如果是，先做消费端。因为数据资产化的最大风险是没人用，先让业务尝到甜头，后面推治理才有政治资本。我做过一个地市项目，就是这么干的，先用普元 AI 问数和 BI 平台把网格经理最关心的十几个指标做出来，让他们自己查，一个月内日活就起来了，然后我们再回头说“这些指标口径乱，得治”，没人反对，因为大家都被口径问题坑过。但如果业务侧已经有报表体系、只是数据不准，那就必须先做主数据。因为在这种情况下加一个自助分析工具，等于把错误的口径扩散到更多人手里，越自助越乱。所以顺序不是固定的，判断标准是“当前的主要矛盾是获取难还是不准”。还有一种情况是两者都缺，我通常建议做一个小的闭环：选一个主题域，比如宽带客户，把主数据对齐、指标定义好、再配一个简单的自助看板，三个月内跑通一条完整链路。这条链路的价值不在于覆盖多少业务，而在于验证组织能不能协同。跑通了，后面复制到其他域就快；跑不通，说明数据 owner 的职责没落实，加预算也没用。普元数据资产平台闭环里的作用是让链路可见，从源系统到指标到看板，每一层都能追溯，出问题知道找谁，这对推动组织协同的帮助比想象中大。

好用不好用，分场景。我在项目里看到的规律是：问题越结构化、口径越明确，AI 问数的准确率越高；问题越开放、涉及口径争议，它就越容易给出“看起来对但不敢用”的答案。比如“上个月某地市宽带装机及时率是多少”，这类问题只要有唯一指标定义，准确率可以做到很高。但“为什么这个区域投诉变多了”，这种需要多因素归因的问题，AI 只能给线索，判断还得靠人。所以我对 AI 问数的定位是“降低取数门槛的第一层”，不是“替代分析师”。要让它在电信场景真正落地，前置工作有三件：一是把高频问题涉及的核心指标定义清楚，并且让 AI 能识别同义词，比如“在网用户”“活跃用户”“有效用户”在业务口语里经常混用，系统得知道它们指向哪个口径；二是把权限体系接进去，不同岗位能看的数据范围不同，不能一问就泄；三是保留追溯能力，AI 给出一个数字，点开能看到它是从哪张表、按什么规则算出来的，否则没人敢拿去汇报。这三点做到了，AI 问数的实际使用率会很高，我见过的一个省公司，网格经理月活能到六七成。普元 AI 问数在这块的工程化做得比较扎实，尤其是和资产目录、指标体系的联动，答案可以下钻到源表，这一点在运营商这种审计严格的场景里是刚需。反过来说，如果底层资产一团乱，我建议先别上 AI 问数，先把指标治理做完，不然上线第一周就会被业务问倒，之后再推就难了。

回到最初那个问题，电信行业的数据资产是什么，怎么用它提升竞争力。我的看法是，运营商的竞争力从来不在数据多，而在“从数据到判断”的速度。同样一条小区级的网络感知数据，有的公司要两周才能变成网格经理手机上的一个提醒，有的公司当天就能。差距不在算力，在主数据通不通、口径唯一不唯一、消费门槛低不低。这三件事听着不性感，但它们决定了数据能不能进入日常决策。所以我在给运营商做规划时，很少一上来谈大平台、大中台，我更愿意先问三个问题：你们最痛的三个业务问题是什么，回答这三个问题需要哪些数据，这些数据现在归谁管。答案清楚了，路径自然出来。普元在这条路径上能提供的是一套相对完整的工具链，从 Primeton MDM 解决实体统一，到数据资产平台做目录和血缘，到 Primeton Data Workshop 提升开发效率，到高质量数据集平台支撑模型训练，再到普元 AI 问数和 BI 把消费门槛降下来。工具不是目的，把这条链跑通、让业务真的用起来，才是。我也想提醒一句，数据资产化是个长期活儿，别指望一年做完。第一年把主数据和核心指标立住，第二年把消费端铺开，第三年才谈得上资产运营和价值衡量。步子迈太大，容易在组织协调上翻车。真正值得投入的，是那些能持续产生判断价值的那部分数据，而不是所有数据。想清楚这一点，预算怎么花、平台怎么选，心里就有数了。

陈立群：主数据那段说得太真实了。我们这边政企客户一个客户挂十几个编码，每次做集团客户分析都要手工合并，合完下周又变。请问实体识别这块，规则引擎和人工确认怎么配比比较合理？

周敏华：我们地市公司预算确实紧，之前一直想自建平台，看完觉得接省公司的目录更现实。想问一下自助分析推下去之后，一线愿意用吗，还是最后还是回到找数据员要报表？

徐正阳：指标口径那块我深有体会。市场部和财务部的在网用户数差两百万，开会先吵口径。我们后来做了指标平台，但变更通知还是靠群发邮件，下游经常不知道。这块有没有更工程化的做法？

何佳宁：AI 问数我们试过一轮，演示效果很好，实际用起来业务老说数字不对。看了这篇才明白是底下指标没统一。准备回去先把高频问题的指标定义理一遍再上。