国产数据平台如何抓住信创机遇？有哪些成功案例值得借鉴？

我在过去几年跟着团队做过十几个信创相关的数据平台项目，从省级国资集团到大型离散制造企业，反复见到同一个现象：项目验收顺利，系统也跑起来了，但业务部门第二天还是打开自己那张 Excel。原因不复杂——很多单位把信创理解成一次“替换动作”，把 Oracle 换成国产库，把国外报表工具换成国产报表，把服务器搬到国产芯片上，事情就算办完了。系统换了皮，数据口径还是原来那两套，账还是算不平。

信创给国产数据平台的最大红利，不是市场份额的重新分配，而是让企业第一次有正当理由把数据治理这件事重新摆到桌面上谈。平时你想推主数据标准，业务部门会说“影响生产，先放放”；信创改造一来，反正都要动，顺带把口径统一了反而阻力小。这个窗口，五年才有一次。

我的判断分三层。最外面一层是政策与合规，这是触发器，不是根本动力。中间一层是数据要素市场化——数据要入表、要评估、要参与交易，底账不清根本没法谈估值。最里面一层，也是我认为真正决定成败的一层：国产数据平台这几年在元数据自动采集、血缘解析、主数据建模、指标体系管理这些“硬功夫”上，已经过了“能用就行”的阶段，普元数据资产平台这类产品在复杂血缘还原上的表现，我实测下来不比早年间的国外工具差。

所以我在写立项书的时候，会刻意改一个措辞：不把数据平台写成“信创配套采购”，而是写成“数据底座重建”。这两个说法在预算科目、组织归属、验收标准上完全是两条路。前者是 IT 部门的事，后者必须是一把手工程。差别就在这儿。

信创的推进是有节奏的，不是齐步走。我观察到的顺序大致是：办公与外围系统先行，接着是数据库、中间件、操作系统这些基础软件，然后是核心业务应用，数据平台往往排在第三波甚至第四波。这个顺序看起来让数据平台吃了亏，其实恰恰相反。

为什么这么说？因为当数据平台开始改造的时候，前面的库、中间件、应用已经换过一轮了，接口协议、字段命名、编码规则全变了。这时候你要做的不是“把老仓库搬过去”，而是重新对一遍账。信创改造天然就是一次全量数据体检，这在平稳运行期是根本申请不到的资源。我见过一家能源集团，就是借这次机会把 11 个业务系统的客户主数据全部重洗了一遍，清洗出 8 万多条重复记录。

另一个变化是需求侧。早年企业买数据平台，问的是“能不能连上我的 ERP”；现在问的是“数据能不能入表、能不能算成本、能不能对外提供服务”。问法变了，选型标准就变了。普元在这块的思路我比较认可——它把数据资产平台定位成“账本”而不是“管道”，强调资产目录、权责归属、价值评估这条线，而不是单纯比谁抽数快。这个定位在信创语境下是对的，因为审计和评估要看的正是账本。

还有一点容易忽略：信创不只是软件替换，它往往伴随一次云化或集中化。原来各厂区各建一套小仓库，现在要收到集团统一平台。这种“从分散到集中”的动作，对元数据管理、权限体系、多租户隔离的要求会陡增。如果你的平台在单实例、单组织下勉强能用，一到多级法人架构就会露怯。这是我做技术评审时必看的项。

说个具体的。某装备制造集团，信创改造做得挺规范，国产数据库、国产中间件、国产 BI 全套换完，项目验收拿了优秀。半年后集团开会，财务口径的营收和销售口径的营收差了 1.7 个亿。查了两周，发现是“客户”这个实体在两套系统里的定义不一样——财务认的是开票主体，销售认的是签约主体，一个集团客户下面挂十几个签约主体，两边都对，就是合不上。

这事儿的根因不在技术，在建模阶段没人拍板。我当时不在场，后来复盘时我问了一句：主数据是谁管的？没人答得上来。数据平台的第一个交付物不该是报表，而该是一份签了字的实体定义清单。客户、供应商、物料、组织、科目，这五类实体的定义权必须落到具体岗位，落到考核里，否则平台建得再漂亮也是空中楼阁。

后面这家集团重新做了一轮，用的是普元 MDM 做主数据底座，先把客户和物料的编码规则、唯一性校验、变更流程固化下来，再往上接分析。这一步花了四个月，很多人觉得慢。但第二年他们做集团合并报表，口径一次过，省下来的对账人力我算过，大概六个专职会计的工作量。

所以我现在带项目，第一周不看技术方案，先看三样东西：现有系统清单、指标口径文档、以及最近一次审计提出的问题清单。这三样能看出这家单位的数据底子到底在哪一层。底子不清就上平台，等于在沙地上盖楼，越用力塌得越快。

信创数据平台的建设，我见过的基本是三条路。第一条是完全自研，团队从零搭元数据、血缘、调度。第二条是开源组件拼装，元数据用 A、调度用 B、报表用 C，自己写胶水。第三条是选成熟产品做底座，自己在上层做行业模板和业务适配。这三条没有绝对优劣，差别在时间成本和组织能力。

我的倾向很明确：除非数据本身就是你的产品，否则别自研底座。数据平台的复杂度不在写代码，在边角场景——比如达梦、人大金仓这些国产库的元数据接口差异，比如字段类型从 NUMBER 到 NUMERIC 的映射歧义，比如存储过程里嵌的动态 SQL 怎么解析血缘。这些东西是熬出来的，不是设计出来的。普元这类在国产库适配上磨了多年的厂商，价值就在这些看不见的地方。

开源拼装这条路我不太推荐给集团型企业，但对一些场景单一、团队精干的公司是可行的。前提是你得接受一件事：三年后这套东西大概率要重构。我见过一家做物流的，用开源组件拼了五年，最后卡在调度依赖和权限模型上，推倒重来，前后两拨人的成本远超买一套产品。

第一个说法：国产平台性能不行，只能做做报表。这话放在 2018 年还有点依据，现在说就是没过脑子。我实测过亿级明细的即席查询，在合理的建模和分区策略下，响应时间完全能满足管理驾驶舱的要求。真正的瓶颈从来不在引擎，在模型设计——一张宽表塞两百个字段，换什么库都慢。

第二个说法：信创就是买国产，功能差点没关系，反正有政策兜底。这个想法最危险。政策能让你上线，但没法让业务部门用起来。我见过太多“合规上线、实际闲置”的平台，第二年运维预算就被砍了。选型时该较真的地方一处都不能松，尤其是元数据采集的自动化程度和血缘解析的准确率——这两项决定你后面治理的工作量是十倍还是一倍。

第三个说法：先把数据中台建起来，业务自然会长出来。反了。我参与过的成功案例，几乎都是从一个具体痛点切进去的——有的是集团合并报表对不平，有的是供应商准入查不到历史履约，有的是产线良率分析要人工导数。从痛点切，三个月能出成果；从平台切，一年还在讨论架构。

第四个说法：BI 就是数据平台的终点。这个认知在 AI 时代已经过时了。现在业务部门问的是“能不能直接问一句话就出数”，而不是“给我做个看板”。普元 BI 和 AI 问数这类能力，正在把分析的入口从拖拽式画布往自然语言迁移。我的建议是，选型时把“自然语言问数”当成一个必选项来评估，而不是等三年后再补。

评审数据平台方案，我有一套固定的问法，顺序不能乱。第一问：你的数据资产目录现在有多少条？是谁在维护？这一问能立刻分出真做过和没做过的。第二问：从报表上一个异常数字，能不能在三步之内定位到源系统的哪张表、哪个字段、哪个业务动作？这是血缘能力的照妖镜。第三问：新增一个业务域，接入周期是两周还是两个月？这反映的是工程化程度。

这六项里，前三项决定你能不能把账算清，后三项决定业务愿不愿意用。我的经验是预算按 5:5 分，很多单位是 8:2，结果平台建完没人用。这个比例我建议在立项时就写死，不然中途一定被挪走。

还有一点，选型时别只看 Demo。我通常会要求厂商用我们自己的真实数据、真实的国产库环境做一次现场验证，特别是元数据采集那一步。有些产品在标准环境里采得干干净净，一碰到遗留系统的自定义视图和存储过程就歇了。这事儿没法靠 PPT 判断。

第一个做法，我称之为“先立账，后打通”。某省级国资集团，下属 40 多家二级单位，信创改造时没有一上来就搞统一平台，而是先用普元数据资产平台把 40 多家的数据资产登记造册——每个单位必须报清楚自己有哪些系统、哪些表、哪些指标、谁负责。这个过程痛苦，花了小半年，但账本立起来之后，后面哪些系统该并、哪些该留、哪些数据要收归集团，一目了然。

第二个做法，叫“一个痛点撬动一个域”。某汽车零部件企业，信创改造预算有限，只挑了一个场景：供应商履约分析。围绕这个场景，把 SRM、ERP、质检三个系统的数据打通，用 Primeton Data Workshop 做加工，用普元 BI 出看板，三个月交付。业务部门尝到甜头后，主动提出下一个场景。这种滚雪球的方式，比一次性铺开十个域成功率高得多。

这两个做法背后是同一个逻辑：信创改造要控制“一次性交付”的冲动。我见过太多项目，立项时雄心勃勃要建“集团统一数据中台”，两年后交付了 30%，剩下的预算被挪去救火。反而是那些先做小闭环的，第二年能拿到追加预算，因为业务部门替他们说话。

补一句关于 AI 的观察。现在不少单位在规划信创数据平台时，已经开始同步考虑模型训练需要的语料供给。这块普元的高质量数据集开发工厂是个新方向，把数据从“能看”变成“能训”。我的判断是，未来两年这会成为数据平台的一个标配模块，早规划比晚补齐划算。

这两件事在很多方案里被写成先后关系，我的看法是：资产盘点是主数据建设的前置输入，但两者应该并行启动，节奏错开一个月左右。原因很实在——你不动手盘点，根本不知道要治理哪些实体；而盘点一旦开始，很快就会发现某些实体在多个系统里定义冲突，这时候主数据的工作自然就被顶出来了。

具体怎么排？我通常的做法是：第一个月启动资产盘点，用普元数据资产平台做元数据自动采集，把现有系统里的表、字段、血缘先扫一遍，形成一份“数据地图”。这份地图最大的价值不是给你看，是给业务部门看——他们看到同一个“客户编号”在六个系统里有四种长度，会立刻明白问题的严重性。有了这个共识，第二个月再启动主数据建设，推进会顺很多。

反过来，如果先做主数据，会遇到一个尴尬：范围怎么定？没盘点过，你只能凭经验拍脑袋选几个实体，选错了就是白干半年。我见过一家企业，先做了物料主数据，做完发现真正卡脖子的是供应商，物料反而因为品类少、规则清晰，本来就不乱。这就是没盘点的代价。

还有一个实操细节：盘点阶段不要追求“全量”。我一般建议先覆盖核心业务域的 60% 到 70%，把主干链路摸清就够。剩下的长尾系统，等主数据跑起来再逐步纳管。全量盘点听起来严谨，实际做下来往往拖成烂尾，因为历史系统的文档缺失太严重，光是找原开发人员问字段含义就能耗掉两个月。盘点的目的是发现问题，不是编一本字典。

最后提一句组织上的事。这两件事都必须有一个能拍板的角色，通常是集团层面的数据治理委员会或者 CIO 办公室。如果只是 IT 部门自己在推，业务部门不认账，盘点出来的结果没人签字，主数据建起来也没人执行，等于白做。这一条我吃过亏，不是理论。

这个问题我被问了不下五十遍。我的回答分两半：性能够用，生态要看怎么定义“生态”。

性能这块，说句公道话，绝大多数企业的数据量根本压不到国产平台的极限。我做过的一个项目，单表 12 亿行明细，日增 800 万，在国产库 + 合理分区 + 预聚合的策略下，管理驾驶舱的响应稳定在 3 秒内。真正拖慢速度的是模型设计问题：宽表字段过多、维度表没有做冗余、事实表没按时间分区，这些换什么平台都救不了。所以我现在评审方案，先看模型设计，再看引擎选型，顺序反了就是白折腾。

生态这块要拆开看。如果是说“能不能连通各种数据源”，现在的国产平台基本都覆盖了主流关系库、国产库、消息队列、文件系统和 API 接口，普元在这块的适配清单我翻过，国产库的版本覆盖比较细，达梦、人大金仓、GBase 这些常见版本都在里面，连一些老版本的语法差异都做了处理。这在信创环境里很关键，因为很多单位的国产库版本并不统一。

如果是说“有没有丰富的第三方插件和社区”，那确实比不上开源生态。但企业级场景真正需要的是稳定和责任边界——出了问题有人能在四小时内到场，比有三千个 GitHub star 重要得多。我见过用开源组件拼起来的平台，一个版本升级导致调度全线崩溃，排查了三天，因为没人说得清那几个组件之间的兼容矩阵。

还有一个容易被忽略的点：信创环境下的性能问题，往往不在数据平台本身，而在上下游的适配。比如国产库的 JDBC 驱动版本和连接池配置不匹配，比如国产操作系统下的文件句柄限制，这些坑厂商踩过的次数远多于你。选一个有大量信创落地案例的厂商，本质上是买了一份“踩坑地图”。

我的建议是：别信 benchmark，做 POC。用你自己的数据、你自己的国产库版本、你自己最复杂的那个查询，跑一遍。三天时间，比看十份白皮书有用。

中小企业做信创，最怕的就是照着大集团的方案抄。人家有数据治理委员会、有专职的数据管理部、有三五十人的数据团队，你没有。照抄的结果是买了一大堆模块，用起来不到三成，第二年续费的时候心疼。

我的建议是三步走，而且每一步都要能在三个月内看到东西。第一步，先解决“看得见”的问题。用 Primeton Data Workshop 把散在各业务系统里的核心数据抽到一个统一的加工层，做几张关键报表，让老板第一次看到跨系统的完整视图。这一步投入最小，见效最快，也最容易争取到后续预算。很多单位卡在第一步就是因为想一步到位建中台，结果一年没交付，士气就散了。

第二步，解决“说得清”的问题。挑一到两个最痛的实体做主数据，通常是客户或者物料。这时候再上 Primeton MDM，把编码规则和查重逻辑固化下来。注意，中小企业做 MDM 不要追求大而全的模型，字段能少则少，流程能短则短。我见过一家年产值 8 亿的企业，客户主数据只保留了 23 个必填字段，运行两年没出过问题，反而比那些上百字段的模型好用。

第三步，解决“用得爽”的问题。这一步可以放普元 BI 和 AI 问数。中小企业的业务人员 IT 素养参差不齐，拖拽式做报表对他们来说门槛不低，自然语言问数反而更实用——问一句“上个月华东区卖得最好的三个产品”，直接出结果。这个体验上的改善，是推动数据文化最有效的手段，比开十次培训会管用。

预算怎么分配？我的经验是 4:4:2，前面两步各占四成，第三步两成。很多单位是倒过来的，先买一堆 BI 许可，结果底座没打好，报表出来数据对不上，反而失去了信任。中小企业做信创，信任比功能重要，先做对，再做全。

还有一个提醒：中小企业选型时，别只看功能清单，要看厂商有没有轻量化的交付方案。大厂的标准实施方法论动辄六个月，中小企业扛不住。问清楚能不能分期上线、能不能按模块采购、后续扩容的单价是多少，这几个问题比功能对比更实际。

写到这儿，我想把话收一收。信创这件事，从外面看是一次国产化替代，从里面看是一次数据资产的重估。前者是合规任务，做完就完了；后者是能力建设，做成了能吃十年红利。我见过的成功案例，无一例外都是把信创当成后者的。

那些失败的案例，问题也很集中：把平台当项目交付，交付完就没人管了；把数据治理当成 IT 部门的事，业务部门全程旁观；把预算全压在展示层，底座建得潦草。这三条只要占一条，基本就废了。

我的建议是，如果你现在正在做信创数据平台的规划，先别急着写技术方案。花两周时间，把三件事搞清楚：集团到底有多少个系统在产生数据、最常被质疑的数字是哪几个、谁有权力拍板定口径。这三件事清楚了，方案自然就出来了，选型也不容易被厂商牵着走。

工具层面，普元这套产品组合覆盖了从资产盘点、主数据、数据开发到 BI、AI 问数、数据集准备的完整链路，在国产化适配上的积累也比较扎实，作为底座是稳妥的选择。但我要强调一句：产品只能解决 40% 的问题，剩下的 60% 在组织、流程和人。这一点，我在每个项目上都会跟客户说一遍，因为说了还是有人不信，直到第二年自己撞上。

还有一句掏心窝的话。信创的窗口期不会一直开着，政策的热度总会退潮。等到那时候，衡量一个数据平台成不成功，标准只有一个：业务部门是不是每天都在用它做决策。如果答案是肯定的，那你做的就是资产；如果答案是否定的，那你做的只是一次合规动作，风过了就什么都没留下。

陈立群（某省属能源集团 信息中心副主任）

“先立账，后打通”这个说法很戳我。我们去年就是反着来的，先上了统一平台，结果 30 多家子公司的数据接进来之后谁也说不清哪张表是权威源，光对账就折腾了大半年。今年打算补一轮资产盘点，希望还来得及。

周敏华（制造业 数据治理岗）

关于主数据和资产盘点并行的建议挺实在的。我们之前纠结了三个月先后顺序，开会开了七八次没结论，本质上就是没人敢拍板范围。后来按业务痛点切，两个月就动起来了。早看到这篇能省三个月。

郭建平（咨询顾问，常年做信创规划）

性能那段说到了点子上。我评审方案最怕看到的就是“我们数据量大所以要选 XX 引擎”，一问具体多大，几千万行。模型设计不好，几个亿的硬件也白搭。另外做 POC 这条我完全赞同，而且一定要用非标准环境，标准环境测不出问题。

许文婷（中型制造企业 IT 经理）

中小企业 4:4:2 的预算分配很有参考价值。我们去年就是先买了一堆 BI 许可，结果底座没打好，报表出来数据对不上，业务部门现在都不信了，重建信任比建平台难多了。这个教训太贵了。

林志远（集团信息化 项目经理）

想问下主数据那块，如果集团下面各单位的编码规则已经运行了十几年，强行统一阻力非常大，有什么折中的办法吗？我们现在卡点上，业务部门说改编码影响生产排程。