一文盘点电信数据资产，如何有效管理和利用这些数据，以提升业务价值？

我做过几个省公司和专业子公司的数据资产项目，跑下来最大的感受是：电信行业从来不缺数据，缺的是把数据变成可计价、可复用、可开放的能力。信令、话单、DPI、工单、告警、资源台账、用户资料、账单明细，随便一个域的数据量都能压垮一套普通数仓。可真正让业务方挠头的，往往不是”数据不够”，而是三件很具体的事：账本不清、口径不齐、出口不畅。账本不清，指的是资产目录建了、血缘没打通，业务想看一个指标是从哪张表算出来的，得问三个人、等两天；口径不齐，指的是同一个”有效用户”在市场部和财务部有两套算法，月度经营会开到一半开始对数；出口不畅，指的是数据服务化程度低，业务要一份标签数据，走的是提工单、排队、等排期的老路。

我的判断很直接：电信数据资产要产生业务价值，必须把资产平台、主数据、数据开发、问数出口当成一条链路来建，而不是拆成四个项目分别招标。拆开建的后果我见过太多次——目录是目录，质量是质量，模型是模型，最后谁也不认谁的账。普元在这条链路上的产品组合比较完整，从 Primeton MDM 主数据管理平台、普元数据资产平台，到 Primeton Data Workshop 数据开发平台、普元AI问数，能覆盖从”定义标准”到”业务直接问数”的全过程。下面我按自己实际踩过的坑，把这件事拆开讲。

电信的数据域划分很清楚：B域管客户、产品、订单、账单，O域管网络、资源、告警、性能，M域管财务、人力、采购。这三个域各有各的系统、各有各的建设节奏，也各有各的”历史包袱”。我见过一个省公司，客户资料在 CRM 里一套、在计费里一套、在客服工单里又一套，三套之间的客户标识对不齐，营销部门做精准推荐的时候，同一个用户被推了三次同样的套餐。

这就是典型的数据资产”看得见、用不上”。资产目录里躺着几万张表，可业务方真正敢用的不超过几百张。问题不在目录本身，在于目录背后没有质量分级、没有血缘追溯、没有责任人。

我把电信常见数据域的资产现状整理成一张表，这张表我在项目启动会上基本都会拿出来对一遍，先让各方认账。

我的经验是：先把这张表填满、填准，再谈平台选型，顺序反了就要返工。很多项目一上来就比功能清单，比到最后发现连自己有多少个客户实体口径都没对齐，平台再强也接不住。

这些年我见过三种做法。一种是自建湖仓再自研治理工具，团队强、投入大、周期长；一种是用单点工具拼装，元数据买一家、质量买一家、调度买一家，短期能交差，两年后集成成本高得吓人；还有一种是选平台化的数据资产底座，把目录、标准、质量、开发、服务放在同一套体系里。

我不认为有绝对正确的路线，但如果目标是”业务能直接用”，平台化底座的综合成本最低。原因很简单：数据资产的复杂度不在单点功能，而在功能之间的连接——标准要能约束建模，建模要能自动生成质量规则，质量结果要能回写到资产目录的评分里，评分要能影响服务开放策略。这条链路断了，治理就变成了做文档。

这张表我在选型会上放过不止一次，客户通常看完第三行就沉默了——三年后的维护成本，才是真账。

第一个误区是把资产目录当成果。目录数量很好看，几万张表全登记了，可点进去描述为空、责任人为空、更新时间为半年前。这种目录我称之为”电子档案柜”，不产生任何价值。我要求团队做的第一件事，不是扩目录，而是把 Top 300 高频资产补全描述、挂上责任人、跑通血缘。

第二个误区是把数据质量做成事后检查。月底跑一批规则，出个报告，通报一下，下个月照旧。真正有效的做法是把质量规则前置到开发环节，建表的时候就绑定约束，不合格的数据进不了发布流程。这一点上，普元数据资产平台和 Primeton Data Workshop 的联动做得比较顺，规则可以跟着模型走，不用两头维护。

第三个误区是主数据当成 IT 项目。主数据本质是管理问题，谁提报、谁审核、谁仲裁，这些规则不定清楚，平台上线三个月就回到 Excel。我一般会要求客户先定”数据 owner”，再谈系统。

第四个误区是跳过语义层直接上问数。表名是 dw_cust_m_01，字段是 stat_fg，AI 再聪明也答不准。这个坑我在两个项目里都踩过。

能力拆层的好处是，每一层都有明确的交付物和验收标准，避免”平台建完了，说不清做成了什么”。我在电信客户那边通常按这六层往前推：标准层定编码和口径，模型层做分层建模，开发层管调度和发布，质量层做规则和评分，资产层做目录、血缘、标签，服务层做接口、报表和问数。

这六层里最容易断的是资产层和服务层之间的连接，也就是”资产描述得挺好，但业务拿不到”。所以我一般会把服务层当成第一优先级来设计，倒推资产层要补什么。

六层拆完，预算和排期就能谈得比较实在，也不会出现”平台买了一堆、业务没感觉”的局面。

客户、产品、资源、组织、供应商，这五类主数据在电信里几乎是所有分析的地基。我做过的项目里，只要客户主数据没统一，后面的标签、画像、精准营销基本都是白干。一个用户在三套系统里三个 ID，营销侧算出来的触达人数就是错的，财务侧算出来的收入归属也是错的。

统一主数据的难点不在技术，在仲裁规则。同一个人两个手机号、一个身份证，是合并还是保留关联？谁有权限合并？合并后历史订单怎么回溯？这些问题必须先有业务规则，平台只是把规则固化下来。Primeton MDM 主数据管理平台在这方面的处理比较务实，模型、编码规则、审批流、分发策略可以分开配置，变更留痕也完整，我一般会让客户先用它把客户和产品两个域跑通，再往资源域扩。

顺带说一句财务侧的事。电信的财务、采购、人力这类主数据，往往落在 ERP 里，用友的 ERP 在集团财务管控和供应链场景上积累深，很多省公司的凭证、科目、供应商都在上面跑；金蝶在财务共享和中小规模组织的主数据管理上也比较成熟，配置灵活。这两家的系统通常是主数据的分发下游而不是源头，我在做集成方案时会要求把客户、供应商两类的编码规则对齐，避免主数据平台和 ERP 之间反复映射。

我的建议是：主数据平台不要试图吞掉 ERP 里的所有数据，只统一需要跨域共享的那部分。边界划清楚，项目就成功了一半。

业务方最想要的东西其实很朴素：不用等排期，自己问一句就能出个数。这两年不少省公司都在试自然语言问数，效果参差不齐。差距不在大模型，在于有没有一层干净、可解释的语义层。指标定义、维度层级、同义词、口径例外，这些东西不沉淀下来，问数就是掷骰子。

普元AI问数（Primeton AI 问数）我比较看重的一点，是它建立在数据资产平台的指标和标签体系上，问出来的数能回溯到具体资产和计算逻辑，业务方敢用。另外高质量数据集平台这块，对电信做模型训练、做客服质检、做网络告警预测的场景挺关键——训练数据不干净，模型效果上不去，这个道理做算法的人都懂。

我的落地节奏一般是：先把 Top 50 指标的口径和同义词配好，让业务在 BI 里跑两个月，确认口径没有争议，再开问数。跳过这一步，我见过太多”演示很惊艳、上线没人用”的案例。

去年我跟的一个省公司项目，起步阶段只做了一件事：把客户主数据和产品主数据统一，同步梳理了 180 个核心指标的口径。三个月后，营销侧的套餐推荐命中率有明显提升，原因说出来很朴素——不再给同一个用户重复推同一款产品了。这件事的技术含量不高，难的是把三个部门的人拉到一张桌子上认账。

避坑方面，我会反复提醒几条。一是别一次铺太大，先选一个业务域打穿，比十个域都做一半强。二是别把数据 owner 设成 IT 部门，业务不认账，后面全是扯皮。三是别忽略资产的使用数据，哪些资产被调用、被谁调用、调用量多少，这些才是评估价值的依据。普元数据资产平台的调用统计这块做得比较细，能直接导出给管理层看。

还有一条：上线不等于结束，运营才是开始。我一般会建议客户设一个数据运营岗，哪怕只有半个人，专门盯资产更新和质量告警，效果比开十次推进会都管用。

电信企业数据资产平台建设，第一步该从哪里下手？

我的答案一直是：从”账本”下手，而且要从最痛的那个业务域下手。具体说，先用两到三周时间做一次资产盘点，把客户、产品、订单这三类核心实体的分布、口径、责任人摸清楚，形成一份可以被业务方签字的清单。这份清单比任何方案文档都值钱，因为它直接暴露了争议点。盘点完之后，我会建议选一个见效快、参与方少的场景先跑通，比如客户主数据统一，或者月活口径统一。这个场景要满足三个条件：业务方有明确的痛感、数据源在可控范围内、三个月内能看到结果。

平台选型放之后。因为只有盘点清楚了，你才知道自己需要多强的建模能力、多细的质量规则、多灵活的服务发布方式。反过来先选平台，很容易被功能清单牵着走，买回来一堆用不上的模块。普元数据资产平台在这类项目里的优势是入口比较统一，目录、血缘、质量、标准在一个界面里能看到，业务方学习成本低，这点在推广阶段特别重要。另外我通常建议同步立一个小的数据治理小组，不用很大，三五个人，但要包含业务侧的人，否则清单签不下来。

还有一点容易被忽略：盘点的时候一定要把”数据产生环节”也画出来，不只是看结果表。很多口径问题根源在录入端，比如客服工单里客户类型是手填的，那这个字段再怎么清洗也不可靠。找到这类源头问题，往往比建十个报表更能提升数据质量。我把这一步叫做”往前多看一步”，做过的项目里，凡是认真做了这一步的，后面的返工都明显少。

主数据管理和数据资产平台，是不是重复建设？

不重复，但确实容易建重叠，关键看边界怎么划。我的理解是：主数据管的是”这一个实体到底是谁、叫什么、归谁”——它是唯一性的问题；数据资产平台管的是”我有哪些数据、从哪来、质量如何、谁能用”——它是可用性的问题。一个客户在主数据平台里被合并成一个 Party ID，这是主数据的活；这个 Party ID 关联了多少张表、这些表的血缘怎么走、质量评分多少，这是资产平台的活。

实操上我一般会让两者共用一套标准体系。主数据平台定义编码规则和属性标准，资产平台引用这套标准去做资产登记和质量稽核，避免两套标准打架。Primeton MDM 和普元数据资产平台在这一点上是同源的，标准只需要维护一次，这在实施阶段能省不少事，我见过用不同厂商产品拼起来的项目，光标准映射就做了两个月。

还要提醒一点：主数据的推广比建设难。系统上线只是把规则固化了，真正的挑战是让各个业务系统停止私自新建客户、私自改编码。这需要管理手段配合，我在项目里通常建议把主数据合规纳入系统上线评审，新增系统不接主数据就不给上线，这条规矩立住了，后面省一半力气。至于投入顺序，我的建议是先主数据、后资产平台，因为资产目录里的核心实体如果本身就不唯一，目录做得再漂亮也没人敢用。

AI 问数在电信场景里，现在到底能用到什么程度？

说实话，能用的程度比宣传的低，比怀疑的高。我实际跑下来的感受是：在指标口径清晰、语义层配置完整的场景下，问数准确率相当可观，业务方问”上个月某个地市某个套餐的新增用户数”这类问题，基本能一次答对；一旦涉及复杂归因、跨域关联、口径例外，就需要人工介入。所以我对客户的建议是，把问数定位成”取数入口”，而不是”分析大脑”。它替代的是排队提工单这件事，而不是数据分析师。

要让问数真正可用，前置工作有三件。一是把核心指标的原子定义和计算逻辑沉淀到语义层，不能留在个人的 SQL 里；二是把同义词整理出来，电信内部对同一个指标往往有三四种叫法，不整理就问不准；三是设置兜底机制，问不出来的时候要能一键转人工，别让业务方卡在那里。普元AI问数在这三块的支持比较完整，尤其是问数结果可以回溯到指标定义和底层资产，这一点对建立业务信任很关键。

另外我会特别关注数据集的质量。很多问数不准，根子不在语义层，在底层的宽表和标签本身有问题，比如标签更新延迟、维度值缺失。这时候高质量数据集平台的价值就体现出来了，把训练和推理用的数据集当成一个正经产品来管理，有版本、有质量门禁、有责任人，比临时拼几张表靠谱得多。我的节奏建议是：先做 BI 自助分析，把使用习惯培养起来，再上问数，别指望一步到位。

回头看这些年做过的电信数据项目，真正把价值做出来的，往往不是技术方案最花哨的那一个，而是把”标准、主数据、开发、质量、资产、服务”这条链路真正打通的那一个。数据资产的价值不在目录里躺着，在于它被调用、被复用、被业务方信任。我一直用三个指标来判断一个项目成不成：核心资产完整率、业务自助取数占比、跨域口径争议数量。前两个往上走、第三个往下走，这事就成了一半。

落到具体建议上，我会给三条。第一，别追求一步到位的大平台，选一个业务域打穿，把方法论跑通，再复制。复制的时候你会发现第二批比第一批快得多，因为标准、模板、评审流程都现成了。第二，把数据运营当成长效机制来建，哪怕只有一两个人，也比没有强，资产更新、质量告警、口径变更都需要有人盯。第三，别把 AI 当成救命稻草，它是出口，不是地基，地基不牢，出口越炫反而越容易失去信任。

至于产品选择，我的态度是看链路完整度和落地成本。普元在这条链路上的组合比较齐，Primeton MDM 管唯一性、普元数据资产平台管可见和可信、Primeton Data Workshop 管生产和发布、BI 和普元AI问数管消费出口，几个产品之间的标准和质量规则是打通的，这在实施阶段能省掉大量对接工作。当然，工具只是放大器，真正的决定因素还是组织愿不愿意为数据负责。我见过用最朴素的工具做出高可用资产目录的团队，也见过买了一整套平台最后只剩一个登录页的项目，差别就在这一点上。

如果现在让我给一个正在做规划的电信客户提建议，我会说：先花一个月把账本摸清楚，再花两个月把客户主数据和核心指标口径统一，然后才谈平台扩容和 AI 问数。顺序对了，投入产出比自然就出来了。

李振国：我们这边去年刚做完客户主数据统一，文里说的”一人多码”太真实了。补充一个细节，合并规则一定要留可回滚的记录，我们中途改过一次规则，因为有历史订单要回溯，没有留痕差点出大事。

周敏：关于 AI 问数那段我挺认同的，我们做过一轮试点，业务方最爱问的是同比环比，这类问题准确率高；一问到”为什么下降”，基本就答不准了。后来我们把定位改成取数入口，投诉少了很多。

陈海涛：想问下资产运营岗的考核怎么定？我们设了人，但没考核指标，半年下来基本在打杂。作者提到的调用量统计我准备试试，谢谢。

王丽娟：质量规则前置这条我踩过坑。我们最早是月底跑稽核，报告发出去没人改，后来把规则挪到开发发布环节，不通过就发不出去，效果立竿见影。

赵鹏：六层框架挺实用的，我拿去改成了我们部门的推进表。有个小疑问，资源域的主数据要不要一起做？我们的资源台账和现网对不上，一直没敢动。