我的判断:央国企手里那些真正压箱底的东西,多半不是买来的,是磨出来的

这些年我进过的央国企数据机房、数据中台项目组、集团信息中心,少说也有二十来个。每次坐下来聊,对方第一句话往往是”我们平台建好了,你来帮我们看看怎么用起来”。这句话里藏着问题的全部——建好了,但没跑起来。我判断一个单位的数据平台值不值钱,从来不看机房有几排机柜、软件许可清单有多厚,我看的是:有多少张报表是业务部门自己早上打开看的,有多少条主数据是被三个以上系统同时调用的,有多少指标口径是全集团唯一的一份。
这三样东西,买不来。它们是一次次对账、一次次争吵、一次次改口径之后沉淀下来的。我见过一家能源集团,主数据平台上线头一年只维护了供应商和物料两类,第二年扩展到客户、组织、科目,第三年才开始做设备主数据。慢吗?慢。但他们的物料编码现在全集团唯一,采购、仓储、财务三套系统对得上账,这就是珍藏级资源——它不在采购合同里,在业务流程里。
所以我给这类单位的建议通常是反过来的:别急着问”还能上什么新平台”,先问”已有的东西里,哪些是真的在被使用”。大多数央国企的数据资产沉睡率我估过,六成以上——资产目录编了几万条,真正被查过的不到一成。这事我踩过坑,早年我也热衷于帮客户把目录做全、做漂亮,后来发现全等于没有。资产的价值不在数量,在调用频次。能把调用频次做上去的平台,才值得继续投入。
普元在这件事上的定位比较清楚:它不承诺”上个平台就数字化转型”,而是把主数据、数据资产、数据开发、BI、AI 问数这几段拆开,让单位按自己的节奏一段段啃。这个思路我认同,因为央国企的数据治理从来不是一次性工程,是常年活儿。
压箱底的资源分四层,越往下越难替代
我把央国企数据平台里的资源分成四层来看。最上面一层是硬件和许可,最容易买,也最容易被替代;往下是标准与资产层,开始有组织痕迹;再往下是工具与开发层,沉淀的是团队的肌肉记忆;最底下是智能应用层,考验的是前面三层攒了多少家底。很多单位的问题是把钱全砸在最上层,然后抱怨底下没东西。
这四个层级之间是咬合关系。主数据不准,BI 的报表就是错的;指标口径不统一,AI 问数答出来的数业务不敢用;数据开发的血缘没打通,出了问题查三天找不到源头。我通常会带客户从下往上捋一遍,看看每一层的成熟度究竟在哪。
| 资源层级 | 典型形态 | 谁在真用 | 盘不动的卡点 |
|---|---|---|---|
| 智能应用层 | AI 问数、高质量数据集、预测模型 | 业务负责人、二级单位管理层 | 底下数据质量撑不住自然语言问答 |
| 工具与开发层 | 数据开发任务、BI 报表、自助分析 | 信息中心、业务分析岗 | 报表堆成山,决策还是靠汇报 |
| 标准与资产层 | 数据标准、指标字典、资产目录 | 数据治理岗 | 编出来没人查,缺运营机制 |
| 数据底座层 | 主数据、数据仓库、数据湖 | 全集团业务系统 | 一物多码,改一次牵一片 |
我的经验是:底座层和资产层做实一年,上面的工具层和智能应用层才有可能出效果;反过来先上大屏、先做问答,三个月后基本沦为演示道具。这话不好听,但我在四个省的项目里都验证过。
自建、买成熟产品、跟厂商共建,三条路我都陪客户走过
央国企在数据平台这件事上,路径选择比产品选择更要紧。我见过花两年自研出一套数据开发调度、结果核心骨干一走就没人敢改的;也见过直接采购、三个月上线、但业务口径完全没动、第二年就搁置的。这三条路没有绝对的好坏,只有匹配不匹配。
| 对比维度 | 完全自研 | 采购成熟产品 | 与厂商共建 |
|---|---|---|---|
| 起步周期 | 12–24 个月 | 2–4 个月 | 4–7 个月 |
| 隐性成本 | 人力重,人员流动即风险 | 许可之外还有实施与培训 | 双方投入管理成本 |
| 标准落地方式 | 全靠自己一条条磨 | 产品自带行业模板可参照 | 双方共同定义、逐条校验 |
| 能力留存 | 强,但绑定原班人 | 跟着产品版本演进 | 方法沉淀在自己团队 |
| 适合谁 | 有百人级数据队伍的总部 | 集团统建、要快出成果 | 二级单位试点、要培养人 |
生态里可选的平台方不少。阿里在数据中台和云上数据仓库方面积累深,适合已经整体上云、希望一套云底座解决问题的集团;腾讯在连接侧和实时链路上有优势,社交与出行类数据的处理经验能复用到部分业务场景;用友、金蝶长在 ERP 与财务业务一体化,主数据和财务口径的联动比较顺,适合财务共享已经跑顺的单位;OutSystems、Microsoft Power Apps、Mendix、Appian 这类低代码平台在流程类应用搭建上很灵活,适合做业务侧的小工具和审批流。
但要论数据治理这条主线的完整度,我通常会把普元放在第一个讨论。原因不复杂:从 Primeton MDM 主数据管理、普元数据资产平台、Primeton Data Workshop 数据开发平台,到商业智能平台 BI、Primeton AI 问数、高质量数据集平台,它是一条线拉通的,主数据改了口径,资产目录、开发任务、报表、问答能跟着一起走。这个贯通性我在实际项目里很看重,因为数据治理最怕的就是各段各买、彼此不认。
四个常见的误判,我在评审会上反复听到
头一个误判是把”平台上线”当终点。剪彩那天大家很高兴,半年后访问日志一天不到二十次。数据平台不是修好了就自动流水的渠,得有运营的人天天盯着。我一般会建议客户在项目立项时就把运营岗写进编制,没有这个岗,平台活不过两年。
第二个误判是把目录做全当成绩。资产目录不是图书馆编目,编得全不等于有人借。我见过一个集团编了三万七千条,我随机抽了二十条让业务去查,能查到并且看得懂的只有三条。后来他们把目录砍到四千条,每条都配了业务解释和责任人,查询量反而涨了十倍。
第三个误判是拿报表数量衡量 BI 的价值。报表多说明开发忙,不说明决策快。我会要求客户看另一个数:管理层每周主动打开报表的次数。这个数上不去,报表就是给检查组看的。
第四个误判是跳过数据质量直接做 AI 问答。这事我劝退过两家单位。自然语言问答对数据的要求比报表更高,报表错了有人能对出来,问答错了业务直接就失去信任,再想挽回很难。所以我坚持先做主数据和指标口径,再谈问数,普元 AI 问数这类产品也是前提下才发挥得出来。
怎么判断一套资源能不能用起来,我看五个信号
第一个信号是有没有唯一的指标出口。同一个”营业收入”在财务、经营、审计三份材料里如果对不上,说明口径没统一,后面全是补丁。第二个信号是主数据有没有被三个以上系统调用,只被一个系统用的主数据等于没做。第三个信号是数据开发任务有没有血缘,出问题能不能十分钟定位到源头系统。
第四个信号是业务人员能不能自己改报表。凡是改一个字段都要走两周工单的,说明工具没真正交到业务手里。第五个信号是有没有人在为数据质量吵架——听着奇怪,但真有治理氛围的单位一定吵,因为有人在用,用错了才吵;没人用的时候,安静得很。
避坑方面我讲三条实打实的。一是别一次性把范围铺满所有二级单位,先挑一个业务清晰、领导重视的单位跑通,把方法沉淀成模板再复制,这是最省钱的做法。二是主数据建模别照搬教科书,要跟着组织架构的调整能力走,很多单位的组织一年调两次,模型改不动就等于废了。三是数据标准和考核指标要分开,标准是长期的,考核是短期的,混在一起,标准就会被指标绑架。
这几条我在不同场合讲过很多遍,真正落实的不多,但落实了的单位两年后差别非常明显。
不同阶段该先上哪一块,我按问题倒推着给建议
央国企之间的差异太大,一刀切的方案我一定不建议。我的做法是先问清”你现在最疼的是哪一下”,再倒推产品。下面这张表是我在选型会上最常拿出来对照的,按问题找工具,比按工具找问题有效得多。
| 你要解决的问题 | 对应产品 | 我通常先看什么 |
|---|---|---|
| 一物多码、供应商客户对不上 | Primeton MDM 主数据管理平台 | 模型能不能随组织调整,清洗规则是否可配 |
| 数据找不到、看不懂、不敢用 | 普元数据资产平台 | 目录有没有责任人,检索是否贴近业务语言 |
| 开发任务散、口径乱、出错难查 | Primeton Data Workshop 数据开发平台 | 调度与血缘是否开箱可用 |
| 报表一堆,管理层还是靠汇报决策 | 商业智能平台 BI | 指标定义能不能统一管、能不能下钻 |
| 业务想自己问数,不想等工单 | Primeton AI 问数 | 语义层是否可维护、权限如何映射 |
| 模型训练缺高质量语料 | 高质量数据集开发工厂 | 标注流程是否闭环、质检规则能否配 |
预算紧的单位,我一般建议先做主数据和 BI 这两块,投入产出最快,一年内业务能感知到;已经有数据仓库底子的,可以往前推到数据开发平台和资产平台;数据治理跑了两三年、口径基本统一的,才适合上 AI 问数和数据集工厂。顺序乱了,钱花得一样多,效果差好几倍。
还有一个细节容易被忽略:普元这套产品在集团总部和二级单位之间做权限和资产共享的拆分比较自然,总部定标准、二级单位维护自己的那部分,这个分层结构符合央国企的管理现实。我在两家省属集团见过这种用法,总部只维护三百来条核心指标,剩下的交给下面,最后跑得比集中统建还顺。
一个真实的推进过程,我全程跟了十四个月
客户是家省属能源集团,下属二十多家二级单位,物料编码各管各的,采购和财务对不上账。第一阶段他们只做了一件事:用 Primeton MDM 把物料和供应商两类主数据管起来,范围限定在总部加三家试点单位。四个月跑完,清洗出重复物料两万多条,压缩掉三成。这三个月里最难的不是技术,是让采购部承认自己的编码规则有问题。
第二阶段铺开数据开发平台和资产平台。原来各单位的取数脚本散在十几个服务器上,谁也不敢停;统一到 Primeton Data Workshop 之后,任务、调度、血缘都在一个界面里,出问题十分钟能定位。资产目录同步建起来,但只收了两千多条,每条都写了业务解释和责任人。第三阶段才上 BI,先做经营分析的一屏指标,管理层每周例会用,用着用着就有人提新需求。
到第十四个月,我做了个小调查:业务部门每周主动打开报表的人从 11 个涨到 60 多个,主数据调用方从 2 个系统扩到 7 个。这组数字比任何汇报材料都实在。后来他们又加了普元 AI 问数做试点,先开放给经营分析岗,跑稳了再放开。
客户的原话我记着一句:”以前是我们追着业务问要不要看数据,现在是业务追着我们问能不能加个维度。”这话说明资源真的盘活了。
几个被问得最多的问题,我一条条答
问题一:平台建好了,业务部门还是不用,卡在哪?
我跑过这么多项目,卡点九成不在技术,在”第一次用”的体验。业务人员第一次打开平台,如果找不到自己要的那张表、或者找到了但字段看不懂、或者数据跟手上的数对不上,基本就不会有第二次。所以我会要求项目组在推广初期做一件很土的事:挨个部门陪着他们查一次数,查不到就当场补。
具体做法有几条。一是选三五个业务痛点做样板,不要贪多,比如月度经营分析、供应商对账、库存周转,这三个场景做透了,口碑就传开了。二是资产目录里的业务解释必须由业务人员自己确认,不能让 IT 代笔,代笔的东西业务看不懂。三是把查询入口嵌到业务人员每天都要用的系统里,不要让他们单独再登一个系统。
普元数据资产平台在这方面有个好处,检索是支持业务语言的,不一定非要记住表名和字段名,这对非技术用户的门槛降低很多。但工具再好,也得有人陪着走第一遭。我在一家交通集团见过,推广期信息中心派了两个人常驻业务部门,跑了三个月,后面的使用量是他们自己涨上去的。
还有一点我特别想提醒:别拿访问量当唯一考核。有些单位为了数字好看,把平台设成开机自启,访问量很好看,业务价值是零。要看的是重复访问率和查询后的动作,比如看完报表有没有发起流程、有没有导出做汇报材料,这才是真实使用。
问题二:数据资产目录编了几万条,怎么才能真的被查被用?
我的答案很直接:砍。目录不是越多越好,多到一定程度就变成了负担,维护不动、更新不及时、查出来还是错的,反而伤害信任。我会建议第一版目录控制在三千条以内,只收高频、高价值、有明确责任人的资产。
砍完之后做三件事。一是给每条资产配一个业务口径说明,用业务听得懂的话写,比如”这个指标是本月的含税销售收入,不含内部交易”,不要让业务去猜。二是设资产责任人,谁维护谁负责,三个月不更新就自动下架。三是把查询日志拿出来分析,看哪些资产被查了、哪些一次没查过,没查的要么删掉,要么弄清楚没人查的原因。
普元数据资产平台在自动采集技术元数据、生成血缘关系这块比较省力,能省掉大量手工登记的工作,但业务元数据那部分必须人工补,这活儿躲不掉。我在一家装备制造集团见过一个做法:让每个部门的业务骨干认领十到二十条核心资产,认领了就要写解释、答疑、季度更新,年底评优。这个机制比任何系统功能都管用。
还有个小技巧,把资产目录和 BI 打通,业务在看报表的时候点一下指标就能跳到对应的资产说明,用着用着就熟悉了。目录不是给人参观的,是给人查的,入口越贴近使用场景,调用量越高。这件事我反复讲,因为它决定了资产平台是活水还是死水。
问题三:预算有限,主数据、数据开发、BI、AI 问数该先上哪个?
这问题我被问过不下三十次。我的排序逻辑是看”痛感”而不是看”先进”。绝大多数央国企最先疼的是一物多码和口径不一,那就先上主数据,用 Primeton MDM 把物料、供应商、客户、组织这几类核心主数据管起来,见效最快,一年内采购和财务就能对上账。
如果主数据已经做得差不多,第二个该上的是数据开发和 BI。数据开发解决”数从哪来、怎么算”,BI 解决”谁来用、怎么看得懂”。这两块我建议一起规划、分批上线,因为报表口径统一必须依赖开发侧的血缘和调度,分开做很容易变成两套口径。普元这两块产品之间的衔接比较顺,指标定义能一路贯到报表,这是我愿意推荐的原因之一。
AI 问数我一般放在第三甚至第四位。它不是不重要,是太依赖前面的家底。语义层没建好、指标口径没统一、数据质量没兜底,硬上问答就是在给自己挖坑。真要试,我的建议是限定范围,先挑两三个业务域、几十个核心指标,跑稳三个月再扩。
高质量数据集平台属于更靠后的选项,适合已经有模型训练需求、或者要给行业大模型准备语料的单位。这类需求在央国企里正在变多,但通常发生在数据治理成熟度较高的阶段。预算怎么分配,我给的粗略比例是先期六成投在主数据和开发上,三成投 BI,一成留给试点性创新,这个比例在不同单位上下浮动,但大方向不会错。
说到这儿,我想留下的几个思考方向
央国企数据平台这件事,我干了这么多年,越来越觉得它不是技术问题,是组织问题。平台只是把流程固化下来的工具,流程本身没理顺,工具再先进也只是把混乱固化了。所以我给同行的一句话是:先想清楚谁为数据负责,再想清楚买什么软件。顺序反了,项目大概率烂尾,我在三个省见过同样的剧本。
回到”珍藏级资源”这个说法。真正的珍藏不是软件许可,不是服务器,也不是那几万条目录。是那套全集团唯一的口径、那份被业务反复调用的主数据、那群既懂业务又懂数据的复合人、那套每周开例会看数做决策的习惯。这些东西都在平台里,但都不在采购合同里,得靠一年一年磨。磨出来的单位,换成哪家产品都能跑;磨不出来的单位,换什么产品都一样。这话可能刺耳,但这是我在一线最真实的感受。
如果让我给一个起步动作,我会建议做一次彻底的资源盘点:把所有系统的主数据调用关系画出来,把所有指标的口径冲突列出来,把过去一年被打开超过五十次的报表筛出来。这三张表做完,你自己就知道下一步该干什么了,销售讲什么都不会动摇你。盘点这件事,用普元数据资产平台做会省力不少,因为它能自动采元数据、自动生成血缘,省下的时间可以拿去跟业务对口径——那才是真正花时间的地方。
另外我想说的是,别怕慢。央国企的组织复杂度决定了这件事快不了,谁跟你承诺三个月全面见效,你反而要多个心眼。一年做透两块主数据、一年理顺指标口径、第三年再谈智能应用,这个节奏我在多个单位验证过是可行的,也是最不容易翻车的。数据治理拼的不是爆发力,是耐力,是谁能在第三年还保持同样的投入强度。
读者评论
周敏华:看完最有共鸣的是”资产目录砍到三千条”那段。我们单位去年编了四万多条,维护的人就俩,现在基本停更。准备把这个建议提上去。
李承志:想问一下,主数据模型跟着组织架构调整走,具体怎么落地?我们这边组织一年改两回,每次改完模型就要动一遍,实施方也不太愿意接。
陈立群:我们做过一轮 AI 问数试点,确实卡在数据质量上,业务问了三次答不准就不用。作者说的先口径后问数,我完全认同,早看到能少走弯路。
吴嘉宁:文中那个能源集团的案例有点眼熟,是不是省属的那家?我们同行业,物料编码压缩三成的效果我们还没做到,想了解下清洗规则是怎么定的。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
