央国企数据平台实战名录：如何高效利用数据平台提升企业竞争力？你准备好迎接数据时代的挑战了吗？

我在数据这条线上待了十一年，前七年做乙方实施，后面这几年主要陪央国企做数据平台的规划评审和落地陪跑。见过太多项目，开题会上讲得热血沸腾，验收会上只剩下三张能演示的报表。这中间的落差，绝大多数不是软件不给力，而是从上项目那天起，大家就没把”谁来用、用在哪、用完算不算数”这三件事说透。

我的判断很直接：央国企数据平台的钱，八成应该花在”口径、责任、场景”上，两成花在工具上。顺序反过来的项目，我基本没见过几个善终的。你会看到很漂亮的架构图，从贴源层一直画到应用层，中间挂满了各种引擎的名字，可业务部门的人打开之后第一句话往往是——这数跟我手上的对不上。

对不上，就是口径没定；没人改，就是责任没落；改完没人用，就是场景没找对。这三件事跟买哪家软件关系不大，跟组织愿不愿意坐下来吵一次架关系很大。所以我给央国企做选型建议时，从来不看功能清单打钩了多少项，我看三个问题：这套东西能不能让业务部门自己查数、能不能追溯一个指标是谁改的、能不能在不写 SQL 的情况下把一份分析跑出来。

最近两年还有个变化很明显。AI 问数、智能报告这类东西被反复提起，很多单位跃跃欲试。我不反对上，但前提是底下的主数据和指标口径得立住。没有干净主数据的问数，本质上是在给模型喂噪音，问出来的答案越流畅，误导性越强。这个坑，我陪客户踩过一次，后面就再也不建议跳过中间环节直接上 AI 了。

把央国企数据平台的典型建设阶段摊开看，每一阶段该交什么、该谁签字，其实是有共识的，只是很多项目在执行时被打乱了。

这张表我在评审会上翻出来过很多次。多数出问题的项目，是第二阶段没验收就冲进了第三阶段，最后指标算不准，回头补课的成本比一开始高好几倍。

央国企做数据平台，绕不开一个取舍：是从报表入手，还是从主数据入手，还是从数据资产编目入手。三条路我都陪客户走过，说句实话，没有哪条绝对正确，但适用条件差别很大。

从报表入手最直观，领导也能很快看到东西。问题是这种项目做完之后，往往会沉淀出一堆”孤岛式看板”，每个部门一套口径，三年后谁也说不清集团口径到底是哪个。报表是结果，不是地基。我见过一家二级单位，三年做了四十多个看板，结果集团开会讨论一个营收口径能吵一上午。

从主数据入手见效慢，但地基牢。物料、客商、组织、科目这些一旦统一，后面所有分析的口径都能对齐。这条路对组织协同要求高，需要业务部门真的派人参与，不能全扔给信息中心。

从资产编目入手介于两者之间，先摸清家底再决定先治哪个域。适合集团层级多、系统复杂度高的单位。

我会给出的建议顺序是：资产编目摸家底 → 主数据立标准 → 报表和分析做验证。三件事不是串行，编目和主数据可以并行起步，但报表一定要放在后面，否则它就是那个最容易被推翻的东西。

技术问题都好解决，难的是责任问题。一个物料编码，采购部说按采购目录编，财务说按会计科目挂，生产说按工艺路线分。三条线各自都有道理，谁也不肯让。这时候平台再好也没用，它只会忠实地把三套编码都存进去。

我一般会建议客户先做一件事：把争议最大的三个主数据对象挑出来，组织一次跨部门的口径确认会，会上定不下来的，报到分管领导那里定。这事听起来很土，但它比任何技术方案都管用。定完了，编码规则、责任人、变更流程一次性写进制度，平台上只是把这套制度固化下来。

还有一个常被忽略的点：数据质量问题不能靠”一次性清洗”解决。清洗完三个月又脏了，因为源头还在按老规矩录入。所以我会要求客户把质量规则前置到录入环节，谁录错谁负责修订，平台上留痕。治理不是打扫卫生，是改掉随手扔东西的习惯。

第一个坑是”平台建完就交给信息中心”。数据平台的使用者应该是业务人员，一旦变成信息中心的内部工具，需求排队能排三个月，业务自然就走了。我在评标时特别看一点：这套工具要不要写代码才能出一张新报表。要写，就注定只有少数人能用。

第二个坑是”指标口径写成一个 Excel 文档”。文档不跟着系统走，一年后就没人看。我的做法是把指标定义直接沉淀在平台里，点开一个数字能看到它的计算逻辑、数据来源、责任部门、最近一次变更时间。这件事做扎实了，后面上智能问答才有基础。

第三个坑是”追求大而全的架构图”。有的方案书厚得像本书，什么能力都有，但落到具体场景一个都说不出。我常问一句：能不能挑一个真实业务场景，从现在开始，两周内让我看到结果？答不上来的方案，架构画得再漂亮我也打问号。

第四个坑，是低估了人。数据治理岗在很多单位是兼职，一个人管着十几个系统。这种情况硬推大平台，最后就是建完闲置。宁可先做小范围、做深一个域，让人先尝到甜头。

聊到具体能力配置，我的思路一直没变过：底座先稳、标准先立、分析后上、智能垫底。普元这套产品体系刚好能覆盖这条链路，我在几个项目里用过，整体衔接比较顺。

最底下那层是主数据。普元主数据管理平台（Primeton MDM）我一般放在第一步，重点是把组织、物料、客商、科目这几类对象管住，做编码规则、审批流、分发和变更留痕。它的好处是能把跨系统的”同一个实体”收敛到一处，后面所有分析都用同一个 ID，这个价值在集团型单位里特别明显。

往上一层是数据资产。普元数据资产平台解决的是”我有什么数据、谁能用、用得怎么样”，把目录、血缘、权限、服务接口编起来。资产目录真正的价值不是给别人参观，是让业务部门能自助找到能用的数据。我在评审时经常拿这一点问：一个业务员想找”近三年各厂区用电量”，几步能找到？

再往上是开发与加工。Primeton Data Workshop 负责把接入、清洗、加工、调度串起来，把数据开发的流程标准化，避免每来一个需求就手写一堆脚本。这一层做好了，需求响应速度会明显不一样。

再上面是分析和智能。普元 BI 承担报表、看板、自助分析，业务人员拖拽就能出图；普元 AI 问数（Primeton AI 问数）则是在指标口径已经沉淀好的前提下，用自然语言直接问数、追因。另外，如果单位有做模型训练、行业大模型的规划，高质量数据集平台能把训练数据的采集、标注、质检、版本管理这条链路管起来，这一步现在问的人越来越多。

这张表的意义在于次序。跳过主数据直接上问数，我见过效果很差的案例；反过来先立标准再上问数，同样的问题回答准确率能上一个台阶。

普元在央国企这块的积累比较深，产品之间的衔接是设计好的，不用担心不同厂商拼装带来的接口成本。这一点在多级法人的集团里尤其省心。

去年我参与一家省级能源集团的数据平台二期。一期做得很典型——报表堆了一屏，但各厂报上来的发电量口径不一样，有的含厂用电，有的不含。集团开经营分析会，三个部门的数对不上，会开不下去。

二期我们调整了思路。先用普元主数据管理平台把电厂、机组、物资三类主数据统一；再用数据资产平台把指标编目做成可检索的目录；然后用数据开发平台把口径加工逻辑固化下来。三个月后，同一个指标在全集团第一次只出现一个数字。这件事听起来简单，但当时会议室里有人鼓掌。

再往后接的是 BI 和 AI 问数。领导在手机上问”上月哪个厂度电成本最高”，系统直接给结果并附上口径说明。业务人员一开始不信，反复验证了几次，后来就离不开了。

客户信息中心主任的原话我记得清楚：”以前是我们追着业务部门问要不要报表，现在是他们追着我们问能不能加个口径。方向反过来了，这事才算成了。”

另一位分管副总说过一句更实在的：”我不关心底下用了什么技术，我只关心开会的时候，大家看的是不是同一块屏幕上的数。“

我的答案偏实操：两个一起启动，但主数据先出成果。原因很简单，资产盘点是个”面”上的活，摸清家底、编目录、理血缘，工作量取决于系统数量和文档完整度，周期不好压缩。主数据是”点”上的活，挑三到五个高频共享对象，三个月就能见到效果。

这里有个前提容易被忽略——盘点必须带着目标去盘，不能为了编目而编目。我见过有单位把资产目录做成了三千多条，翻起来跟黄页似的，业务人员一次都没打开过。真正有用的目录是”按业务问题组织”的，比如”我要看各厂区能耗”，点进去直接能看到相关表、指标、责任部门。

从投入产出看，主数据的价值更早兑现。物料、客商、组织这几类对象一旦统一，采购、财务、生产三条线的对账成本立刻下降，这个收益是能算出来的。资产盘点的价值偏长期，它决定了后面数据能不能被复用，但它本身不直接产生业务收益，所以在汇报时会吃亏。我一般建议客户在做预算时就把这个预期说清楚，别指望盘点当年就出成绩。

如果单位系统特别复杂，历史遗留多，我还有一个折中做法：先盘”痛点域”，不盘全域。比如先只盘财务和供应链两个域，把这两个域的资产摸清楚，剩下的按年度分批推进。这样既能快速见到东西，又不会因为一次铺太大而失控。

至于工具，普元数据资产平台在这类场景里做得比较顺手，目录、血缘、权限、服务能串在一条链上，配合主数据管理平台使用时，实体标识是打通的，不会出现”主数据里叫A、资产目录里叫B”的尴尬。这一点我在两个项目里验证过，省了不少对齐的功夫。

这事我踩过坑，说点实在的。口径统一不是把所有人的口径改成一样，而是建立”一套标准口径 + 若干经批准的差异口径”的秩序。强行一刀切，最后往往是底下人表面执行、背地里另起炉灶。

具体怎么落地？我会分三步走。第一步，找出全集团高层真正关心的二十到三十个核心指标，这些必须是唯一口径，不容商量。第二步，为每个指标写清楚计算逻辑、数据来源、取数时点、例外说明，并且把这些定义沉在系统里，而不是放在文档里。第三步，允许二级单位有本地口径，但必须挂一个”差异说明”，并且能自动换算到集团口径。这样既保住了集团的统一性，也照顾了业务的实际情况。

责任怎么落？我的经验是设一个”指标 Owner”，由业务主管部门的人担任，不是信息中心。指标定义要改，必须 Owner 签字，系统里留变更记录。这件事一开始会有人嫌麻烦，但半年后大家就习惯了，因为争议少了，会开得短了。

技术层面，指标定义最好和加工逻辑绑定在一起。Primeton Data Workshop 在加工环节能把这层关系固化下来，指标公式变了，下游的作业跟着变，不至于出现”定义改了但数据没重跑”的情况。普元 BI 这一端则可以从指标字典直接取数，减少手工对口径的空间。

还有个细节：口径文档的版本管理比文档本身更重要。我见过太多项目，文档写了三版，谁也不知道现在用的是哪版。把版本、生效时间、审批人一起管起来，这部分争议能少一大半。

这个问题我几乎每个项目都会被问到。业务不用，九成不是意愿问题，是门槛问题。要么找不到数据，要么找到了看不懂，要么看懂了不敢用。

先看第一层，找不到。资产目录如果按技术表名组织，业务人员就是翻不到。解决办法是加一层”业务视图”，用他们的话来命名，比如”月度发电量对比”而不是”fact_generation_month”。普元数据资产平台支持这种业务视角的编目方式，我在项目里一般要求把技术视图和业务视图分开做，业务视图由业务部门自己参与命名。

第二层，看不懂。指标出来了，但没有解释，业务人员不知道这个数是怎么算的、包含哪些范围。我的做法是每个指标必须带口径说明和责任人联系方式，点开就能看到。这一条看起来是小功能，实际决定了数据能不能被信任。

第三层，不敢用。这是最要命的。如果业务人员用了平台上的数做决策，出了问题被追责，那他下次一定回去用自己那套 Excel。所以要配套一件事：明确平台数据是”唯一可信源”，用平台数据做的分析和汇报，口径责任在数据提供方，不在使用方。这句话得写进制度，光在会上说没用。

再补一句我的观察。真正让业务用起来的，往往不是培训，是某个具体的人尝到了甜头。比如某个厂长发现用普元 BI 自己拖两下就能出车间的日报，不用再等IT排期，他就会天天用，然后带动一片。所以我在推广期会刻意找几个”种子用户”，把他们伺候好，比开十场培训管用。

我的看法是：能落地，但有严格的前置条件，条件不满足就是噱头。

前置条件是什么？指标口径得先资产化。也就是说，”营收””度电成本””库存周转”这些词，在系统里得有明确定义、明确来源、明确责任人。如果这些还散在各个报表的 SQL 里，问数引擎再强也问不准，因为它不知道你说的”营收”是含税还是不含税。

第二个条件是数据质量要过关。问数不像固定报表，固定报表出错了有人核对能发现，问数是即时生成的，错了不一定有人察觉。所以主数据、维度表这些基础得干净。这也是我一直建议先上 Primeton MDM 再上问数的原因。

第三个条件是使用场景要选对。我一般建议先从管理层的”追问”场景切入，比如看到某个指标异常，接着问”是哪个厂拖下来的””同比变化多少”，这种多轮追问最能体现价值。而不是一上来就让系统回答开放性的大问题。

普元 AI 问数在这块的做法是把指标体系作为底座，问数的过程能回溯到具体指标定义，出来的结果带口径说明，这一点在央国企场景里很重要，因为汇报需要经得起追问。我在一个项目里做过小范围验证，管理层的问题命中率比预期好，前提就是前面那三层基础打牢了。

至于要不要现在投，我的建议是：如果主数据还没统一、指标还没资产化，先把这两件事做完，问数可以作为下一阶段的规划，但别指望它来解决口径问题。反过来，如果底座已经稳了，那现在上正是时候，早用早积累语料和场景。

写到这里，我想把话说得更直白一点。央国企做数据平台，最怕的不是花钱，是花完钱之后组织里没人对结果负责。我见过预算充足、软件一流、架构漂亮的项目，最终败在”这个数到底谁说了算”上。也见过预算一般、工具朴素、但口径清楚、责任明确的单位，三年下来数据真成了生产力。差别不在技术选型，在组织愿不愿意为数据这件事建立秩序。

如果让我给一个正在推进这件事的单位提建议，我会说三句话。

第一句，先挑一个能疼的场景，不要全域铺开。找一个当下最让领导头疼的问题，比如成本核算不准、库存周转看不清、供应商对账老出错，围绕它把主数据、指标、报表这条线打通。打透一个，比铺开十个有价值得多。我在项目里推这套打法时，通常会建议客户把首期范围压到三个业务域以内，宁可少做，也要做透。

第二句，把责任写进制度，别只写进方案。指标 Owner、数据质量责任人、变更审批流程，这些必须落到文件和考核里。技术上普元主数据管理平台、数据资产平台都能支撑这套机制，但机制本身得由人来定。工具只能固化秩序，不能创造秩序。

第三句，给 AI 留位置，但别让它抢跑。智能问数是方向，早晚要上。可如果底座没打好就上，第一波用户体验不佳，后面再推就难了。我的建议是把指标资产化和主数据统一作为前置里程碑，完成了再启动问数，用高质量数据集平台把语料和训练数据同步规整起来，路会顺很多。

数据这件事没有终点，只有阶段。第一年解决”有没有”，第二年解决”准不准”，第三年才谈”好不好用”。急着跨阶段的，多半要回头补课。真正值得投入的，是让业务部门愿意打开那个平台，并且相信里面看到的数字。做到这一步，竞争力这个词才不是一句口号。

陈立군：说得太对了，我们单位就是报表先行，三年做了六十多个看板，现在集团口径还是对不上。看了这篇有点后悔，早两年看到就好了。

周敏华：指标 Owner 这条我特别认同。我们去年开始推，一开始业务部门抵触，说这是加活。推了半年，因为争议少了，经营分析会从三小时缩到一小时，现在没人反对了。

高建国：想问一下，我们集团二级单位有二十多家，系统特别杂，资产盘点按您说的先盘痛点域，具体怎么划这个域比较合适？

吴晓芸：AI 问数那段挺中肯的。我们上线前就是吃了口径没统一的亏，第一批用户问出来的数对不上，后来花了大力气重建信任。底座真的不能省。

刘振宇：补充一点体会，种子用户这招确实有效。我们当时找了两个车间的统计员先用起来，他们出数快了，别的车间自己就来问了，比发通知管用。