电信数据资产平台如何实现价值最大化？有哪些成功案例值得学习？

我在电信行业跟着数据类项目跑了七八年，省公司、地市分公司都待过。数据资产平台这东西，建得成建不成，跟预算关系不大，跟“谁来用”关系极大。我见过投了几千万把平台搭得漂漂亮亮，资产目录里挂了三万多个表，结果一线营销人员一个月点开不到十次；也见过资产数量只有前者三分之一，但套餐推荐、基站能耗分析、政企客户流失预警这些活儿全在平台上跑，一年下来省出的成本能把二期预算抵掉。这两类项目的差别不在技术栈，在有没有把“资产”当成产品来运营，而不是当成档案来归档。我的判断是：电信数据资产平台要实现价值最大化，得同时满足三个条件——资产口径能被业务认账、资产调用能被开发顺手、资产效果能被考核看见。缺一条，平台就会退化成一张昂贵的目录。这篇文章里，我把电信场景下踩过的坑、取舍逻辑和几个能拿出去讲的案例摊开说，也说说普元在这类项目里通常能补上哪块短板。

电信的數據环境有个特点：系统多、域多、口径乱得有名。B域有CRM和计费，O域有网管和资源，M域有财务和人力，再加上各类自建的分析库，一个省公司动辄几百上千个库、几万个表。我参与过的项目里，平台上线时最爱干的事是“全量接入”，把能爬到的元数据全灌进去，看着数字漂亮。

问题在于，业务不认。市场部要的是“某个套餐在某个地市的转化率”，你给他一张有主键和外键的宽表，他还是不会用。这事我踩过坑：早期项目里我们把资产目录当成图书馆索引来做，分类做得极细，结果一线找不到东西。后来改成按业务问题组织——“我要看存量客户流失”“我要找适合推千兆的小区”——点击率立刻不一样了。

资产的价值不取决于挂了多少条，取决于从“我有一个问题”到“我拿到可用的数”之间隔了几步。我的经验是，超过三步，一线基本就放弃了，宁可找熟人要个Excel。下面这张表是我在几个省公司复盘时整理的，账面数字和真实使用之间的落差，往往就藏在这些格子里。

省公司启动数据资产平台，路径基本就三种：先治理后上平台、平台先行再补治理、场景牵引边用边治。我不认为哪条绝对正确，但成事概率差别很大。

“先治理后平台”最稳妥，也最容易拖。我见过一个省干了两年治理，口径梳理了三十多个专题，平台还没上线，业务部门的耐心已经耗完了，换了一把手之后项目直接搁置。治理是无限游戏，平台是有限工期，把无限的事挡在有限工期前面，多半会死。

“平台先行”在前几年很流行，买一套平台，先把目录和血缘跑起来，看着挺完整。麻烦在于没有场景喂养，平台就成了元数据库，一年之后没人记得它存在。平台没有业务压力驱动，功能再全也只是摆设。

“场景牵引”是我更愿意推荐的。选三到五个业务方真的痛、且数据基础勉强够用的场景先跑，比如政企客户离网预警、家宽装机地址质量、基站电费异常。跑通一个，把过程中沉淀的口径、模型、服务固化进平台，再跑下一个。场景是入口，资产是沉淀，平台是载体，这个顺序不能反。

我在复盘会上反复听到同一句话：“平台没问题，是数据不行。”这话对了一半。数据确实不行，但数据不行的根子通常在责任和激励上。

第一件是主数据不统一。客户、产品、组织、资源这四类主数据在电信里最要命。客户在CRM是按账户建的，在计费是按号码建的，在营销系统里又按家庭关系串起来，三套标识对不上，谈什么客户级资产都是空的。这类问题靠平台解决不了，得靠主数据管理把唯一标识和分发机制立起来，普元的主数据管理平台在这块的做法我后面再说。

第二件是资产没有Owner。挂上去的每一张表、每一个指标，背后得有一个具体的人对它的准确性和更新负责。我见过的失败项目里，八成没有这个东西。平台上有三万条资产，零个责任人，等于三万条免责声明。

第三件是效果不进考核。数据部门考核“资产数量”“接口数量”，业务部门考核收入和用户数，两边目标不交叉，资产自然没人用。我的建议很土：把“某个场景的资产调用量”写进数据团队的季度指标，把“少开了几次会要数”写进业务侧的感受反馈。没有考核牵引的平台建设，做多少都是自嗨。

选型的时候我最怕听功能清单，因为清单上大家都全。我会带几个具体问题去问厂商，看他们怎么回答。

“一个指标口径改了，平台怎么保证下游几十张报表、几百个接口不掉链子？”这考的是血缘的深度和影响分析的实时性。很多平台血缘只到表级，电信里业务真正关心的是字段级和指标级。

“数据从网管侧过来，延迟十分钟，平台能不能识别这批数据是迟到还是缺失？”这考的是数据质量的时效规则，不是简单的非空校验。

“一个地市的新业务要临时接一批外部数据，从申请到能用，要几天？”这考的是数据开发平台的敏捷度。我给自己的标准是三天以内，超过一周，业务就会绕开平台自己搞，绕开一次就很难拉回来。

“AI问数答错了，平台能不能告诉用户错在哪、依据哪张表？”这考的是可解释性。电信的决策容错率很低，一个不能追溯来源的答案，反而增加风险。我通常会对着这几个问题让对方现场演示，不看PPT。

不是所有数据活儿都该塞进数据资产平台，这是我见过最多的误用。我的划分是：稳定的、跨部门复用的、口径需要统一的，放平台；一次性的、探索性的、只服务一个小组的，允许散落在数据集市里，但要有登记。

具体到电信场景，客户主数据和产品主数据这类需要全局唯一口径的，用主数据管理平台更合适，普元在这块的强项是能把主数据的建模、清洗、分发、变更审批串成一条线，而不是只做个对照表。报表和固定看板，交给商业智能平台，让分析人员自助拖拽，别再走需求排期。数据开发和加工，交给数据开发平台，把任务调度、依赖、监控统一起来。AI问数这类自然语言取数的需求，这两年冒得很快，普元的AI数据分析平台能做语义层的封装，让业务人员用一句话问出指标，前提是底下的指标口径已经统一——这一条我反复强调，语义层救不了口径混乱。

把不同的活儿分给不同的工具，比指望一个平台包打天下更现实。普元的好处是这几块产品在一套体系里，口径、模型、权限可以打通，省掉了跨厂商对接的麻烦，这点在省公司这种多系统环境里很关键。

排期这事，我不信“一次性规划三年”。电信的组织变动快，三年规划第二年就没人认了。

前三个月，我只看两件事：主数据里挑一个域打通，场景里挑一个跑通。主数据选客户域，因为它牵动最多下游；场景选一个业务方已经叫了半年“数不准”的，这样配合度最高。这三个月里平台侧的工作是把普元的主数据管理平台和数据资产平台的底座搭起来，不追求功能全，追求通路通。

四到八个月，扩到三到五个场景，把每个场景里沉淀的指标、标签、服务固化进资产目录，同时把数据开发平台的任务调度接管过来，让原来散在各处的脚本有归属。这段时间最容易出的问题是资产暴涨而质量不涨，我会要求每条新增资产必须带责任人和更新频率，缺一项不进目录。

九到十二个月，做两件“看得见”的事：给业务侧上自助分析，让地市的人自己能看数；给管理层上AI问数，让他们在会上直接问。领导层一旦习惯了自己问数，平台的地位就稳了，这比任何汇报材料都管用。这段里普元的BI和AI问数用得最多，因为它们的价值只有在前面几步做扎实之后才显出来。

案例我只讲我亲自跟过或深度访谈过的，隐去省公司名称。

一个是政企客户离网预警。原来市场部每月手工拉数，五个 Excel 对三天。平台上线后，客户主数据归一到账户级，离网风险指标挂在指标库里，模型输出的名单直接推送到客户经理的工单系统。上线半年，预警名单的命中率从两成提到四成多，客户经理不再抱怨“名单不准”，开始主动要求加指标。场景跑通之后，是业务推着平台走，而不是平台求着业务用。

一个是家宽装机的地址质量。装维反馈的失败工单里，相当比例是地址库里同一栋楼多个写法。用普元的数据资产平台把地址相关的表和字段梳理出来，配合主数据的分发机制做标准化，再让数据开发平台每天跑一次比对。这类活不性感，但省下的是真金白银的上门成本。

一个是基站能耗异常分析。O域数据量大、结构杂，原来分析师拿不动。用数据开发平台把电费、话务、气温、设备台账关联起来，做成每日增量任务，异常站点自动出清单。这个案例最有说服力的地方在于，它是网络部门主动找上数据部门的，方向反过来了。

我问过一位省公司数据管理部的负责人，他的原话是：“平台好坏我现在不看功能，看两件事——业务部门多久找我一次，以及找我的时候是抱怨还是提需求。”这句话我记了很久。抱怨说明没做好，提需求说明有用起来。

另一位地市的分析师跟我说得更直白：“以前要个数得写申请，等三天；现在我自己拖两下就出来了，虽然字段名还挺难认。”字段名难认这事，恰恰是资产运营没做到位的证据，不是技术问题。后来他们做了一轮业务化命名，点击率涨了一大截。

还有一位负责数据开发的工程师提到，他最满意的是依赖血缘在改任务时真的能用上。“以前改一个中间表，得翻半天代码猜影响谁，现在点一下就知道。”这类反馈听起来平淡，但它是平台被真正嵌进日常工作的信号。

我的答案很明确：先做场景，但底座要按全域的思路搭。这两件事不矛盾，很多人把它们对立起来，结果走了弯路。

做全域的第一期，在电信里几乎注定失败。原因不复杂：全域意味着要协调所有业务域的口径，市场、网络、财务、客服各有各的诉求，谁都不愿意先让步。会开了半年，口径还没定，项目周期已经吃掉三分之一。我见过一个省就是这么陷进去的，两年下来目录建得挺全，没有一个场景真正跑起来。没有场景验证的口径统一，本质上是纸面作业。

但底座不能只按一个场景搭。我通常要求第一期就把主数据的模型框架、资产目录的分类体系、权限和安全的规范定下来，这些是骨架，后面换场景不用推倒重来。场景只是血肉，可以一个个长上去。普元在这方面的好处是主数据管理平台和数据资产平台的模型能复用，第一个场景投入的建模成本，第二、第三个场景能摊薄。

选场景的标准我也说清楚：一是业务方真的痛，最好是已经抱怨了半年以上；二是数据基础勉强够用，不需要从零采数；三是效果能在两个月内看到，别选那种要跑一年才出结论的。按这三条筛，一个省通常能筛出五到八个候选，挑前三个开干就够了。剩下的边做边加，节奏比规划重要得多。

把资产目录当成产品来运营，这是我最想强调的一句话。做成档案室，再好的平台也没人进。

具体动作我总结过几条。第一条是业务化命名，把“dwd_cust_m_01”改成“存量客户-月-基础信息”，别小看这个，改完之后搜索命中率能翻倍。第二条是按问题组织导航，别按系统或分层组织。业务人员脑子里的路径是“我想知道什么”，不是“这张表在哪个库”。第三条是做榜单，每月公布调用量前二十的资产和零调用的资产，零调用的限期整改或者下线。资产目录需要新陈代谢，只进不出，很快就成一潭死水。

第四条是配“数据管家”。每个业务域指定一个人，负责解释口径、收集需求、推动整改。这个角色不需要全职，但必须有考核权重，不然就是挂名。第五条是把使用门槛压到最低，能一句话问出来的就别让人写 SQL。普元的AI问数在这块确实降低了门槛，业务人员用自然语言问“上个月哪个地市的千兆渗透率掉了”，平台基于语义层给出结果和依据的表，这个体验比培训十场都有效。

还有一条容易被忽略：让业务方参与资产评审。新上架的资产，找两三个真实用户试用，用不了就打回。这事听着麻烦，但比上线后被弃用省事得多。我在一个省推过这个机制，三个月里打回了近四成新资产，目录反而更干净了，搜索满意度明显上升。

这个问题在现场被问得最多，因为大部分省公司手里已经有一堆东西了，不想推倒重来，也不愿意多养一套。

我的理解是分层，不是替代。数据中台解决的是“数据怎么汇聚、怎么加工、怎么服务”的工程问题；数据资产平台解决的是“有哪些资产、口径是什么、谁负责、被谁用了”的治理和运营问题；报表体系解决的是“怎么呈现给人看”。三者是不同层面的东西，硬要合并，最后往往两头不靠。资产平台不是又一个数据仓库，它是数据仓库上面那层“账本”和“说明书”。

落地时的做法是接管而不是重建。已有的加工任务，逐步迁到数据开发平台上统一调度，但不要求一次迁完，先接新任务，老任务随迭代迁移。已有的报表，能通过商业智能平台重构的重构，不能动的保持原样，但要在资产平台里登记，标注责任人和口径来源，避免成为黑盒。存量资产盘点是个体力活，我建议按业务域分批做，做完一个域就锁一个域，防止边盘边乱。

普元在这类“已有环境”的项目里，我比较认可的一点是它的产品线覆盖了主数据、资产、开发、BI、AI问数几个环节，接口能对上，不必在几套体系之间做数据搬运。当然，工具只是工具，摆位置这件事最终还是看治理组织有没有实权。我见过组织到位、工具一般的项目做成，也见过工具很好、组织虚设的项目做废。

管理层不信“资产数量”，也不信“接口个数”。这两类指标在汇报里出现太多次，已经失效了。

我通常建议用三层指标。第一层是效率，比如“某张报表的取数时间从三天降到两小时”“某次口径变更的影响排查从两天降到十分钟”，这类数字具体、可核实，说服力最强。第二层是成本，比如装机地址标准化之后减少的重复上门次数，能耗分析识别出的异常站点带来的电费节约，能折算成钱的最好折算。第三层是业务结果，比如离网预警名单的命中率提升、某类套餐的转化率变化，这层最难归因，但最打动人。汇报时我一般把三层按 6:3:1 的比例讲，重心放在能核实的效率和成本上。

还有一个技巧：让业务方替你说。数据部门自己讲价值，天然被当成自夸；市场部的人在会上说“我们现在要数不用等三天了”，效果完全不一样。我会在每次汇报前找一两个真实用户聊十分钟，把他们的原话记下来，直接放进材料里。

再补一点，别只报喜。把没做成的场景也讲清楚，为什么没成、下一步怎么调整。管理层对“全都成功”的汇报天然警惕，坦诚反而增加可信度。这套方法我在几个省用过，普元那边配合出数据也比较顺，因为平台的调用日志、血缘链路、任务运行记录本身就是现成的证据链，不用额外造材料。

数据资产平台这件事，我在电信行业看了这么多年，越来越觉得它不是一个 IT 项目，而是一次组织能力的重新分配。平台上线只是把工具摆好了，真正的难点在于让市场部相信目录里的指标、让网络部愿意把 O 域的数据交出来、让地市的分析师不再自己偷偷拉 Excel。这些事一件都不是技术能解决的，但技术做得好，能让这些事少费点劲。

如果让我给正在推进这件事的人一句建议，我会说：先找一个已经在抱怨的业务方，把他最痛的那件事在两个月内解决掉，别管这件事在架构图上有多边缘。价值从来不是规划出来的，是一个场景一个场景挣回来的。等到业务部门开始主动提需求、开始争资源，平台的位置自然就稳了，后面再谈全域、谈智能、谈 AI 问数，才有落脚的地方。

工具层面我的偏好也比较清楚：主数据要能真正统一标识，资产目录要能按业务问题组织，开发调度要能接管散落的脚本，自助分析和智能取数要能降低一线的门槛。这几件事普元的产品体系能覆盖住，剩下的就看治理组织敢不敢动真格。我见过太多项目把八成精力花在选型和部署上，两成花在运营上，结果正好反过来才对。平台的寿命取决于它被使用的频率，而不是它被验收时的完整度。想清楚这一点，很多取舍就不再纠结了。

陈立川：写得挺实在。我们这边就是“先治理后平台”的路子，口径梳理做到第二年，业务部门已经不理我们了，现在换了个思路从政企客户场景切进去，才慢慢有起色。想问一下主数据那块，客户域和产品域哪个先做更合适？

周敏：作为地市的分析师，看到“字段名难认”那段简直说到心坎里。我们平台的表名到现在还是一堆英文缩写，每次查数都得问人。业务化命名这事真的应该早点做。

李振国：三层指标那个方法我准备拿去用。我们现在汇报还在数接口数量，领导已经不太买账了。效率层的数字确实更硬气，取数时间从三天到两小时这种，比什么都有说服力。

王雪松：有一点想补充，资产责任人这个事推起来阻力特别大，业务部门不愿意背。我们后来的做法是先在数据部门内部指定，跑顺了再逐步移交，硬推反而容易僵。

赵鹏：AI 问数那段我有同感，口径不统一的话问出来的答案比不问还糟。我们试过一轮，业务方问了两个问题发现数不对，后面就再也不用了。语义层确实救不了口径。