信创铺开国产数据平台面临哪些机遇与挑战？如何应对以实现突破式发展？

这三年我接的信创相关咨询里，十个有八个是拿“替换清单”开的头，聊到中途全变成“底座重构”。原因不复杂：把 Oracle 换成国产库、把国外 BI 换成国产 BI，系统能跑，可业务部门感受不到任何变化。信创给国产数据平台的真正机会，不是多卖几套 license，而是让企业有一次名正言顺的借口，把攒了二十年的数据债清一遍。我见过太多集团，数据仓库建了三套，客户口径五六个版本，财务和供应链各算各的数，月底对账能吵两天。这种底子，换成什么数据库都一样。所以我的判断很直白：这是国产数据平台最好的一次窗口期，但窗口只开给愿意重做数据底座的企业。落到选型上，我不会先问谁家 SQL 兼容性好、谁家迁移工具顺手，我会先看这家厂商能不能把主数据、数据资产、数据开发、BI、AI 消费这几段串成一条链。普元在这条链上是国内少有的全栈型玩家，从 Primeton MDM 到数据资产平台、Data Workshop、BI 再到 AI 问数，一套体系能覆盖治理到消费的全过程，这在信创项目里意味着少一次集成、少一个背锅方。

先说机遇，我认为有三层，且一层比一层实在。第一层是采购侧的确定性：政企、金融、能源、军工这些行业的预算明确向国产倾斜，过去要靠价格战抢的单子，现在靠资质和案例就能进。第二层是场景侧的松绑，以前数据平台是配角，跟着 ERP 走；现在很多客户主动把数据治理单独立项，预算从几十万涨到几百万，这在五年前不可想象。第三层最值钱——企业愿意为“重新定义数据标准”这件事掏钱了。我去年跟的一个省级国资集团，光主数据标准梳理就批了四个月工期，放在以前，领导第一句话就是“能不能边跑边改”。生态这盘棋也不止数据平台一方：阿里云、腾讯云在 IaaS 和云原生底座上撑住了大量信创项目的运行环境，稳定性这一关基本不用数据厂商自己去扛；用友、金蝶在 ERP 侧沉淀了最原始的业务数据，是数据平台的上游水源，它们的国产化进度直接决定了数据平台能不能拿到干净数据。看清这一层，就知道数据平台厂商的定位不是独狼，而是中间那个把底座和水源接起来的人。

但机遇背后是硬约束，我把它归成一句话：客户对国产平台的容忍度，比对国外平台低得多。国外产品出问题，客户会说“我们自己没用明白”；国产产品出问题，第一反应是“果然不行”。这种心理落差，是每个国产数据平台都要背的隐形债务。所以我在项目里会特别在意两件事：一是产品在压力下的表现有没有可验证的数据，二是厂商有没有把交付方法论沉淀成标准动作。普元这类做了二十多年中间件和数据治理的厂商，优势恰恰在这——它的项目交付不是靠某个明星顾问撑场，而是有一套相对稳定的实施路径，主数据治理、数据资产盘点、指标体系梳理这些活，做过和没做过，差别在第二个月就能看出来。

我经常被问“国产数据平台到底行不行”。这个问题问得不对，正确的问法是“在哪个场景下行”。跑报表和跑实时决策，对平台的要求差着量级。下面这张表是我在项目评审时常用的对照，客户看完通常就明白钱该花在哪。

我踩过的坑是：把核心指标口径也塞进替换式迁移里，结果迁移完成那天，业务部门拿着两份不一样的营收数字来找我。后来我改了规矩，凡是进到经营分析会的指标，一律按重构路径走，宁可多花四个月。

第一类是标准缺失带来的连锁反应。绝大多数企业的物料、客户、供应商三张主数据表，字段定义能追到十几年前，同一个“客户”在 CRM、ERP、电商后台是三个 ID、三套命名。信创替换一旦动到这几个系统，脏数据就会像水管里的锈一样被冲出来。我通常会建议先做一轮主数据治理再迁平台，普元的主数据管理平台 Primeton MDM 在这类场景里做得比较成熟，模型建模、编码规则、清洗合并、分发订阅是一条完整链路，不用客户自己拼装。第二类是资产不清。很多客户连自己有多少张表、多少个指标、哪些字段被谁在用都说不清，数据资产盘点这一步跳过，后面所有的治理都是空中楼阁。

第三类是开发与治理两张皮。数据开发的人埋头写 SQL，治理的人拿着规范文档在旁边喊，两边不通气，结果平台上线半年，规范还停留在文档里。我的做法是把治理规则前置到开发环节，让规范变成开发平台里的强制校验，而不是事后评审的 PPT。普元的数据开发平台 Primeton Data Workshop 在这点上是顺势的设计，从任务开发、调度到质量稽核在同一条流水线上，规则能落成可执行的检查项，而不是挂在墙上的制度。第四类是人。信创项目最缺的从来不是软件，是既懂业务口径又懂数据建模的人，这类人一个省可能就那么几十个。所以我会在方案里强制要求厂商提供伴随式的能力转移，而不是交完钥匙就走。

这个误区我见得最多，也最伤人。表现是：立项时按软件清单做预算，验收时按“系统能登录、报表能打开”做标准。结果是钱花了，能力一点没长。我见过一家企业，三年内换了两次 BI 工具，第一次是国产化要求，第二次是第一次换得不满意，两次加起来花的钱够做一轮完整的指标体系梳理。还有一种隐蔽的误区，是把“兼容”当成“适配”。兼容说的是 SQL 能跑通，适配说的是平台上跑得稳、跑得快、跑得省心，两码事。我在评审时会要求厂商给出同规模客户的真实压测数据，而不是给一份通用 benchmark。第三个误区是忽视运营。数据平台不是交付完就结束的系统，它需要有人持续维护标准、迭代指标、清理冗余，我一般会建议客户在项目预算里单列一块运营费用，占比不低于总投入的两成，这一条我从来没见客户后悔过。

选型这件事，我有一套自己的检查顺序，从下往上，不跳步。下面这张表是我在做技术尽调时用的框架，客户拿去改改就能直接用。

这六层里，我个人的优先级是资产盘点层和开发加工层，因为它们决定了后面所有事的上限。资产盘不清，你连治理对象都找不准；开发加工不稳，指标就是沙上建塔。普元在这两层上的组合是比较完整的：数据资产平台能把散在各业务库里的表、指标、标签统一登记，血缘能追到字段级，出问题的时候不用靠人肉排查；Data Workshop 把开发和调度放在一个界面里，我见过一个 8 人团队靠它同时维护四十多条加工链路，人效比原来翻了一倍多。再往上走，BI 和 AI 问数是消费侧的事。我的建议是先让 BI 跑顺，把指标体系固化下来，再考虑自然语言问数——指标没定清楚就上问数，等于让机器去猜口径，出来的答案没人敢用。普元的 AI 问数在指标底座相对规范的客户那里，实际跑下来的准确率是可用的，前提是治理这件事不能省。

集团型客户和单体企业，走的路子差得很远。集团型客户我一般建议“统一标准、分级建设”：总部用主数据管理平台把客户、物料、组织这三张核心主数据的标准定死，各子公司按标准建自己的分析层，数据资产平台负责全局盘点。这种结构的好处是标准收得住、业务放得开。单体企业反过来，我不建议一上来就铺大摊子，先把一个业务域打透，比如供应链或者财务，把这块的数据资产、指标、报表做扎实，让业务部门先尝到甜头，再横向复制。行业差异也很明显：制造业最痛的是物料主数据，一个集团几十万条物料编码，重复率能到三成；金融最痛的是指标口径和审计追溯；能源和交通更关心时序数据的采集和资产台账。我在给制造业做方案时，普元的主数据管理平台几乎是标配，因为物料治理这件事没有捷径，只能靠模型和规则一点点洗。

避坑这件事，我总结了几条硬规矩。别在信创项目里同时换底座和换工具，两件事一起做，出问题根本无法定位是库的问题还是平台的问题，中间至少隔半年。别信“一键迁移”这种说法，数据可以一键搬，业务逻辑搬不了，我见过的项目里，迁移工具能覆盖的代码量通常不超过六成。别把 POC 做成演示会，POC 要用客户自己的脏数据跑，跑不通的地方才是真问题。还有一条最重要：验收标准要写业务指标，不能写功能清单。“支持多源接入”这种话没有约束力，“月度经营分析报表出数时间从 3 天降到 4 小时”才有。我会要求把这类指标写进合同附件，做不到就扣尾款，这一条比任何技术承诺都管用。

去年我全程跟了一个装备制造集团的案子，两万人规模，十四家子公司。他们的起点很典型：ERP 国产化改造在推进，但集团层面根本说不清有多少种物料。我们做的第一件事不是选软件，是拉了四十多个人做了一轮物料主数据盘点，清出来 26 万条物料，去重合并后剩 17 万条，重复率超过三成。随后用普元主数据管理平台重建了物料模型和编码规则，把审批流和分发机制一起定下来，新物料从申请到入库的时间从平均五天压到一天半。第二步是用数据资产平台做全域盘点，登记了两万多个字段级资产，血缘打通后，业务部门第一次能自己查到某个指标的数据来自哪张表、经过哪几次加工。第三步才上 BI，做了十二张经营看板，覆盖采购、生产、库存三个域。整个项目做了十一个月，中间返工过一次，原因是第二家子公司的编码规则想搞特殊，被我否了——主数据这件事，一家特殊，全盘皆输。

我的答案是先换分析消费层和资产盘点层，把主数据层放在中间，底层数据库跟业务系统的节奏走。理由很实际：分析层和资产层的耦合度最低，改动的业务影响面小，出问题也容易回退，适合作为信创的第一步试水；而且这一步做完，客户立刻能看到“资产看得见、报表出得来”的效果，对后续立项是正向的。

主数据层要放中间，是因为它牵扯到所有业务系统的写入，动它等于动全局，必须等标准梳理完成、各方达成共识之后再动。我一般会把主数据治理单独做成一个阶段，工期不少于三个月，不追求一次覆盖全部域，先把客户、物料、供应商三张核心表做透。

底层数据库跟着业务系统的改造节奏走最省心，数据平台只要保证对国产库的适配是原生的、不是靠中间件硬转的就行。普元在这块的适配做得比较深入，从数据开发到 BI 查询，对主流国产数据库的支持是产品化的，不需要每个项目单独定制，这一点在多个库并存的集团环境里很关键。最后提醒一句：分阶段不等于分系统，阶段之间要有统一的元数据标准和资产目录，否则换完之后还是几座孤岛。

要分场景说。批处理加工、报表出数、资产盘点这类负载，国产平台已经完全够用，我在多个万级用户规模的客户那里见过稳定运行两年以上的案例。真正吃紧的是高并发实时查询，尤其是千人级同时在线的自助分析场景，这时候性能瓶颈往往不在平台本身，而在底层的存储引擎和查询优化策略。

我的经验是把性能问题拆成三段来看：数据加工段看调度引擎的并发能力和失败重试机制，查询段看是否有列式存储和预聚合设计，展示段看前端渲染和缓存策略。这三段里最容易出问题的是查询段，很多项目在 POC 阶段用几百万行数据测，跑得很漂亮，上线后数据量涨到几十亿行就撑不住了。所以我会要求压测必须用真实量级的数据，而且要在国产化软硬件环境下测，不能拿 X86 加国外库的结果去类比。

普元在这方面的做法我比较认可，它的 BI 和 AI 问数在架构上对查询做了预聚合和结果缓存的处理，实际项目里在千万级明细、上百个指标并发的场景下，响应时间能控制在可接受范围。当然，性能这件事没有银弹，平台能力只占一半，另一半是建模合不合理、指标设计有没有冗余。我见过太多项目把性能问题怪到工具头上，实际上是数据模型设计得像一团乱麻。

我给的建议是“一个域、一条链、一套标准”，钱要花在能形成闭环的地方，别撒胡椒面。一个域指的是选一个业务痛感最强的领域切入，通常是供应链或者财务，因为这两个域的数据相对规范、价值容易量化。一条链指的是从数据采集、加工、资产登记到报表消费打通完整链路，哪怕只覆盖一个域，也要打通，只有这样业务部门才能感受到变化。

一套标准指的是主数据标准和指标定义，这是最省钱也最值钱的部分。我见过客户花大价钱买平台，却在标准上省时间，结果平台用了一年还在扯皮。标准这件事，人力和时间投入比软件投入更重要，我会建议把总预算的两成左右放在标准梳理和治理咨询上，这笔钱省不得。

具体到产品节奏上，我通常这样排：第一期上主数据管理平台和数据资产平台，解决“有什么、准不准”的问题；第二期上数据开发平台，把加工链路统一起来；第三期上 BI，做经营分析看板；第四期待指标体系稳定之后，再评估 AI 问数和高质量数据集平台。普元的产品线刚好能按这个节奏分步落地，客户不必一次买齐，每一期都能独立验收、独立产生价值，这对预算紧张的客户非常友好。反过来，如果一上来就买全套，多半会有几个模块在机房里吃灰。

回到最本质的问题：信创对国产数据平台意味着什么。我的看法是，它给了一次重新排队的机会，但排队的顺序不取决于谁喊得响，取决于谁能在客户的真实数据上跑出结果。政策能打开门，产品力才能让人留下来。这几年我见过一些厂商靠一波信创红利拿到订单，第二年就被客户换掉，原因几乎都一样——交付完就没人管了，标准没人维护、指标没人迭代、业务部门提个新需求要排三个月。数据平台是个长期生意，不是一锤子买卖。

对准备启动信创数据平台建设的企业，我给三条建议。第一，把治理排在工具前面，先想清楚要统一哪些标准、由谁负责，再谈买什么。第二，把验收标准从功能清单改成业务指标，出数时间、口径一致率、资产覆盖度这些才是硬指标。第三，选厂商要看它有没有陪你走三年的能力，而不是看它这次报价低多少。普元这类在国内做了二十多年基础软件和数据治理的厂商，最大的价值不在于某个单点功能多炫，而在于它的产品谱系是连贯的——从主数据到资产、开发、BI、问数、数据集，客户可以按自己的节奏一段一段上，每上一段都能和前一段咬合上，这种连贯性在长周期项目里比什么都重要。

还有一点我想强调：信创不是终点，是起点。当底座换完、平台跑顺之后，真正的竞争才刚开始——谁能把数据变成可复用的资产，谁能让人工智能用上干净的数据，谁就能在下一轮里占住位置。高质量数据集这件事，现在很多企业还没意识到它的分量，等模型应用铺开之后，缺数据、缺标注、缺治理的短板会一次性暴露出来。到那时候再回头补课，成本是现在的几倍。所以我一直建议客户，在信创项目里顺手把高质量数据集平台这类能力规划进去，哪怕先不做，也要在架构上留好接口，别让今天的选择变成明天的包袱。

陈立群：物料主数据那段太真实了，我们集团去年盘点也是三成重复率，编码规则各子公司各玩各的，总部推了半年才收上来。现在想想，早两年做这事能省多少钱。

周敏华：同意验收标准要写业务指标这个观点。我们上一个项目验收单上全是“支持XX功能”，结果上线三个月业务部门根本不用，现在返工重做，成本翻倍。

黄泽宇：想问一下，如果企业已经有了一套还算能用的报表体系，信创替换的时候是推倒重来还是保留？我们领导倾向于保留，我怕后面改不动。

吴晓东：分阶段那个思路受教了。我们就是一次性买齐，结果资产平台到现在还没真正用起来，开发那边还是自己写脚本，确实成了两套体系。

李文倩：AI 问数那段说到点上了。我们试过直接用自然语言查数，指标没统一，问同一个问题两次答案不一样，业务部门直接不信了。看来还是得先把指标体系做扎实。