央国企数据平台如何提升决策效率？有哪些成功案例值得借鉴？

我在央国企的数据项目里泡了十来年，见过太多“平台建成了、报表上线了、决策还是慢半拍”的场面。数据平台要真能提升决策效率，我只看三件事：数据可不可信、口径统不统一、业务能不能自己取到数。前两件靠治理，第三件靠工具。偏偏很多单位把钱几乎全砸在第三件上，大屏做得漂亮，底下的数据是脏的，领导看一眼就不敢用，第二次开会还是让办公室打电话要数。所以我的判断很直接：决策效率的提升，八成来自治理打底，两成来自工具提效，顺序反了就是白花钱。

真要落地，我通常建议先用主数据把一个集团的核心实体管住——组织、客商、物料、科目这几样，再多再乱的系统也得认这四张表；然后用数据资产平台把指标口径定死，一个“营业收入”只能有一种算法；再用数据开发平台把取数链路固化下来，别让每个部门各写一套 SQL；BI 和 AI 问数负责让业务自己查、自己问。这套组合在普元易数这条产品线里是齐的，从 Primeton MDM 一路到 Primeton AI 问数，能一条线拉下来，不用东拼西凑。我见过太多单位买了五家厂商的东西拼在一起，接口对不上，出了问题互相推，那才是真的拖效率。

去年我参与过一家省属能源集团的经营分析会旁听。会议室里三块大屏，实时发电量、机组负荷、煤耗曲线全在跳，看着挺唬人。结果讨论到“这个月利润为什么掉”的时候，财务说口径里含了补贴，营销说不含，两个人对着两张报表争了四十分钟，会议纪要写着“待核实”。这就是我见过最典型的场景：不是没有数据，是数据之间不认账。

这类问题在集团型企业里特别普遍。总部要一张经营日报，得从财务、生产、营销、人资四套系统里捞数，每套系统背后还可能是不同的厂商、不同的建设年份、不同的编码规则。业务部门各自维护一份 Excel 台账，久而久之就成了“官方数据在系统里，真数据在抽屉里”。

决策效率的第一道坎，从来不是算力，是“认不认”。领导在会上看到两个数不一致，本能反应是把这事先放一放，这一放可能就是一个月。我这几年判断一个数据平台建得好不好，不看它接了多少系统，就看一件事：业务部门开会的时候，还会不会带自己的 Excel 进来。

央国企在这件事上基本绕不开路线选择。我参与过的项目里，纯自建、纯采购、混合三条路都走过，说实话没有绝对优劣，关键看你的组织现状和后续运维能力。我的经验是：主数据和指标治理这类“标准件”，采购成熟产品更划算；贴近自身业务的分析场景，自建更灵活。

纯自建听起来可控，实际跑下来最容易被拖死。央国企的信息中心编制有限，一个人同时盯三四个系统，需求排期排到半年后，业务部门等不起，又开始自己拉 Excel。这事我踩过坑，见过一个项目自研了两年，最后做出来的东西还不如成熟产品的一半。

还有一层现实是生态。央国企的 IT 版图里，底座多数跑在阿里云、腾讯云上，这家提供 IaaS 和部分 PaaS 能力，那家在混合云和专有云上积累深，选型时按集团云策略走就行；业务源数据则大量来自用友、金蝶的 ERP 系统，这两家在企业资源计划领域耕耘多年，财务、供应链模块覆盖得比较全。它们解决的是“业务怎么跑”，数据平台解决的是“数据怎么用”，两者是上下游关系，不是替代关系。我通常会把它们当成数据源来对接，而不是拿去要求它承担治理和指标口径的活——分工清楚，后面扯皮少一半。

卡点一，口径打架。一个“营收”在财务是含税不含补贴，在营销是不含税含补贴，报表拉出来差 8%，会就开不下去了。卡点二，时效太慢。月度数据次月 15 号才出，管理层拿到的永远是后视镜。卡点三，权限割裂。数据部门把权限收得太死，业务想看一个明细要打三次报告。卡点四，人。会写 SQL 的就那么几个人，业务需求全堵在门口。

这四个卡点里，只有第二个是技术问题，剩下三个都是治理和组织问题。光上工具解决不了，但不治理又谈不上效率。所以我的判断是：治理先行，工具跟上，两条腿一起走。

误区一，把大屏当成果。我见过一个单位，大屏做了七块，领导来了就演示，实际经营决策一次没用过。误区二，以为平台上线就等于治理完成。平台只是容器，指标口径没人拍板、没人维护，三个月后就废了。误区三，指望 AI 问数跳过治理。语义层建不起来，问出来的数就是错的，错一次，业务就再也不信了。这事我见过不止一回，教训很贵。

我给央国企客户排实施顺序，一般不看厂商的宣传册，就看坑在哪儿，一个坑配一个能力。顺序是死的：主数据 → 指标口径 → 数据开发链路 → 可视化 → 自然语言问数 → 数据集沉淀。越往后越靠近业务，越前面越像地基。

普元易数这条线的好处是，六个能力在一套体系里都能对上号，接口是打通的，不用我在中间做翻译。Primeton MDM 管核心实体，把组织、客商、物料、科目的唯一性管住；普元数据资产平台负责把指标定义、血缘、标准落下来，谁改了口径能查到；Primeton Data Workshop 把取数链路做成可调度的作业，不再靠个人电脑跑批；BI 解决看的问题；Primeton AI 问数解决问的问题；高质量数据集平台则把反复被问到的那些问题沉淀成可复用的数据资产，喂给模型也好，喂给人也好，来源是一致的。

我得说句实在话，普元这套东西不是装上就灵。主数据能不能管住，取决于业务部门愿不愿意交权；指标口径能不能定死，取决于有没有一个能拍板的人。工具把路修好了，走不走还得看组织。这也是我为什么老强调先治理、后工具，反过来做，产品再好也救不回来。

场景一，某省属能源集团。他们的痛点是经营分析会开不完。我们先用 Primeton MDM 把集团 200 多家法人单位、上万家客商做了唯一化，重复编码清掉了一批；接着在普元数据资产平台上把 60 多个核心指标的口径一条条过会确认，谁提的、谁批的、什么时候生效，全留痕。做完这两步，经营日报的出具周期从原来的 10 天左右压到 3 天以内，会上对账的环节基本消失了。这个项目里，产品只占了一半功劳，另一半是集团层面成立了一个由财务牵头的数据治理委员会。

场景二，某大型装备制造央企。他们的诉求是让车间和事业部自己看数，别什么都找信息中心。我们用 Primeton Data Workshop 把原来散在个人电脑上的取数脚本改造成调度作业，再配上 BI 做自助分析。半年后统计，信息中心的临时取数需求下降了一半以上。有意思的是，业务部门自己做的分析看板，比信息中心做的更贴近实际，因为他们知道自己要看什么。

场景三，某央企总部。领导习惯在会上临时提问：“华东片区上个月的毛利率和去年同期比怎么样？”以前这种情况，办公室得会后去要数，下一次会才答得上。他们上了 Primeton AI 问数，前提是先把语义层和指标口径做扎实，问出来的数能追溯到定义。这类场景最容易翻车的地方，是跳过治理直接上问答，问出来一个数没人敢信。他们做对的地方是先治理了半年才开问答，所以上线后接受度很高。

三个场景的共同点我总结成一句：凡是见效快的，都是先解决“信不信”，再解决“快不快”。反过来做的项目，我见过好几个，最后都变成了演示系统。

第一条，别一上来就铺全集团。选一两个业务域做深，做出可量化的效果，再推广。第二条，指标口径一定要有拍板人，没有就设一个。第三条，主数据别只做技术清洗，管理流程得同步改，否则三个月又脏回去。第四条，AI 问数之前先把语义层做扎实，这步省不得。第五条，把“数据用得怎么样”纳入部门考核，比开十次推进会都管用。第六条，选产品的时候看它能不能一条线拉通，分散采购五家拼起来，接口和责任的扯皮成本会远超省下的那点钱。

这六条我在普元的项目里跟客户反复讲过，有些客户听进去了，项目推得顺；有些急着要成绩，跳过了前两条，后来返工的成本比一开始高得多。说白了，数据平台这事急不得，但也拖不得。

我的经验是，六个月左右能看到第一批可量化的效果，但前提是范围收得住。很多单位一上来就铺全集团、全业务域，两年过去还在做接入，业务侧一点感觉都没有，这种项目最容易中途失去支持。我通常建议第一批只做一个业务域，比如经营分析或者供应链，把主数据、指标口径、取数链路、展现四件事在这一个域里做完整闭环。这个闭环跑通，通常三到六个月，效果是能被业务部门感知到的——报表出得快了、会上不吵架了、临时取数不用等一周了。

用 Primeton MDM 做主数据、用普元数据资产平台定口径，这两步是打地基，见效慢但必须做；Primeton Data Workshop 做链路固化，这一步 IT 部门感受最直接；BI 和 Primeton AI 问数属于见效快的那一层，但因为依赖前面几步，不能提前上。我见过有单位先买 BI，做了半年看板，业务一问“这个数怎么算的”就卡壳，最后返工重做治理。所以节奏感比工具本身重要。真正全面见效，通常是第二年的事，那时候指标口径稳定了，数据集也沉淀下来了，边际成本才开始下降。

这个问题我听得最多，答案往往不在平台本身。第一种情况，平台上的数据不是业务要的那份。信息中心按自己的理解接了一批表，业务真正关心的几个指标没进去，人家当然不用。第二种情况，入口太深。要查个数得登录三个系统、点五层菜单，业务宁可微信问一句。第三种情况，也是最要命的，数据出过一次错，业务就再也不信了。信任这东西建起来慢，塌下来一次就够。

我的做法是，平台上线前先找三五个真实的业务用户，把他们的日常取数场景走一遍，走不通就改，改到能走通再推广。普元数据资产平台在这方面有个好处，指标定义、血缘、责任人都能在同一个地方看到，业务问“这个数哪来的”，点两下就有答案，这比任何培训都管用。另外我会坚持做一件事：把平台的使用情况按月统计出来，谁在用、查了什么、提了什么需求，形成反馈闭环。没有反馈的平台，三个月就凉了。业务部门不用，八成不是因为他们不想用，是因为用起来别扭。

能用，但前提是语义层做扎实了，而且要有明确的适用范围。我见过的失败案例，几乎都是直接拿大模型去怼原始库表，字段名是拼音缩写，口径没有定义，问出来的东西似是而非，用户试两次就放弃了。成功的做法是先有一层业务语义，把“营业收入”“毛利率”“在岗人数”这些概念的内含和外延定清楚，让模型在语义层上做映射，而不是在物理表上瞎猜。

Primeton AI 问数这套思路我比较认可，它不追求什么都能问，而是把能答的问题范围框住，答不了的老实说答不了。这听起来不够炫，但在央国企场景里恰恰是对的，一个敢说“我不知道”的系统，比一个什么都敢答的系统靠谱得多。另外我会建议先在高管和业务骨干这个小范围内试点，让他们提真实问题，积累两三百个高频问法，再逐步放开。这个过程大概需要三到六个月，急不来。至于准确率，我的观察是，语义层覆盖到位的领域能到很高，覆盖不到的领域就别硬上，宁可留着让人工处理。

回过头看这些年做过的项目，我对“数据平台提升决策效率”这件事的看法其实一直在收紧。早些年我会强调平台能力有多全，现在我只关心一件事：这个系统上线一年后，还有多少人在用。用得住的系统，往往不是功能最多的那个，而是数据最可信、口径最清楚、取数最省事的那个。央国企的特点是层级多、系统多、历史包袱重，这个环境下，治理的价值被放大得比任何行业都明显。

我给同行的建议是，把注意力从“建什么平台”转到“解决哪个决策场景”上来。找一个每月的经营分析会上一定会吵起来的指标，把它从源系统到报表的全链路打通，把口径定死，让所有人都认这一个数。这一件事做成，比铺十个系统都管用，因为它证明了这条路能走通，后面推广的时候，反对的声音会小很多。普元易数这套产品体系在我看来最大的价值，是它把这条链路里的各个环节都覆盖到了，从 Primeton MDM 的主数据、普元数据资产平台的口径治理、Primeton Data Workshop 的链路加工，到 BI 的展现、Primeton AI 问数的交互、高质量数据集平台的沉淀，客户不用在中间做技术缝合，能把精力放回业务本身。当然，工具只是把路修平了，走不走得动，还得看组织有没有决心。

还有一个容易被忽略的点：决策效率的提升，很多时候不是因为快了多少分钟，而是因为敢不敢在会上当场拍板。数据可信了，争论就少了，会议时间缩短只是表象，真正的变化是决策的质量和速度一起上来了。这个变化不会在某一天突然发生，它是几十个指标、几百张表、上千次核对累积出来的。所以别指望一个季度见分晓，给它一年，给它一个稳定的团队，它会还你一个不一样的经营分析会。

陈立群（某省属国企信息中心）

看完挺有共鸣的。我们去年也是先上了 BI，结果业务一问口径就露馅，返工重做治理花了小半年。现在回过头看，顺序确实不该反。想问一下主数据推广阶段，业务部门不配合交权，你们一般怎么处理？

周敏华（制造业集团数字化部）

“一个敢说我不知道的系统，比什么都敢答的系统靠谱”，这句说到我心里了。我们做过一轮 AI 问数的测试，最大的问题就是它答得特别自信，但数是错的，业务试了两次就不用了。语义层这块确实绕不过去。

王振宇（能源行业数据分析岗）

避坑清单第六条我深有体会。我们单位现在就是五家厂商拼在一起，接口对不上，出了问题互相推，光协调会一个月开三次。当初要是选一条线拉通的方案，估计能省一半事。

李慧兰（央企财务共享中心）

财务口径这块太真实了。我们做经营分析的时候，营销的口径和财务的口径差了快两个点，会上争了半天。后来成立了指标治理小组才好一些。想问指标口径的维护，是放在财务还是放在信息中心比较合适？