国产数据平台如何抓住信创红利？你还在等什么？

这几年我被问得最多的一句话是：“信创到底跟我们数据部门有什么关系？”我的回答一直没变——关系大了，而且是最脏最累的那一截。芯片、操作系统、数据库这些底座换掉，业务侧的感知其实有限；真正让一线难受的，是原来跑得好好的报表、主数据、指标口径，换了底座之后全对不上了。我见过一家装备制造企业，数据库换成国产之后，一个原本 40 分钟跑完的批处理变成 3 个多小时，第二天业务部门打开系统没数据，直接掀桌子。后来复盘发现，不是数据库不行，是原来的 SQL 写法和数据链路压根没做适配，谁也没在替换前把数据这层摸清楚。

我的判断是：信创的红利不在采购预算里，而在“谁先把数据这层理顺，谁就在下一轮数字化预算里拿得到话语权”。这话听着有点虚，但实际跑下来特别真实。数据平台是信创里唯一一层，既承上（业务应用）又启下（国产数据库、国产中间件），把它做扎实，上面所有系统的替换成本都会往下掉；把它糊弄过去，后面每上一个系统都要重新对一遍口径。普元这类在数据治理上沉淀了二十来年的厂商，恰好站位置上，这也是我在多个项目里优先推它的原因。

我参加过好几次信创选型会，排在前面的永远是芯片、服务器、操作系统、数据库、中间件。数据平台经常被塞进“应用软件”那一栏，或者干脆写个“待定”。原因不复杂：它不出现在业务界面上，领导看不见，采购也说不清它到底替换了什么。可偏偏这一层的历史包袱最重——口径、编码、血缘、历史数据，全在这儿。

下面这张表我用了两年，每次汇报都拿出来，因为它能直观说明一件事：越往下替换越像换零件，越往上替换越像换器官。

看这张表你会发现一个反常识的点：技术底层反而不难，难的是“数据语义”这一层。数据库换掉，DBA 加班两个月能扛；口径换掉，得业务、数据、IT 三方坐下来吵半年。所以我在任何一次信创规划里，都会建议把普元数据资产平台这类工具提前放进第一批次，先做资产盘点和标准梳理，再谈替换。

我参与过一个省级单位的替换项目。前期所有精力都压在数据库兼容性上，团队硬啃了 200 多个存储过程，跑通了、压测过了，大家松了一口气，觉得最难的部分过去了。上线三个月，问题全冒出来：同一个客户在三个系统里有三套编码；同一张利润报表，财务和数据中心差 800 万；历史数据迁移之后，血缘断了，出了错没人说得清从哪来的。

这事我踩过坑，也见过别人踩。区别只在于有没有在替换前把数据这层单独拎出来做。数据库替换是技术活，数据平台替换是组织活。两者的节奏和资源配比完全不同，硬放在一个项目里做，基本都会变形。

我的建议是：数据库替换和数据平台替换拆成两个里程碑，中间留出 3 到 6 个月的窗口做资产盘点和标准梳理。这个窗口里，普元的主数据管理平台（Primeton MDM）和数据资产平台能发挥最大作用——先把编码规则统一了，后面的迁移才有意义。

第一个误判：把信创当成一次纯粹的“换牌子”。很多企业的动作是列一张清单，把国外的产品挨个找国产替代，功能对得上就打勾。这套逻辑在中间件、操作系统上行得通，在数据平台上一定翻车。因为数据平台的价值不在功能清单，而在它承载的业务语义——你的客户编码规则、你的利润口径、你的成本分摊方式，这些是长在系统里的，换一套工具等于重新养一遍。

第二个误判：认为数据治理可以等替换完再补。我听过太多“先上线再优化”。实际跑下来，替换完再补治理，成本是原来的三倍以上。因为替换期间是新旧并存的，这恰恰是做标准落地最自然的时机——新数据按新规矩进，老数据分批清洗，两套并行跑半年，自然过渡。

第三个误判：只算采购成本，不算改造成本。我通常会看一个指标：这个项目里，软件采购金额和历史数据治理金额的比例是多少。健康的比例大概是 1 比 1，甚至治理侧更高。只看采购单价的项目，后面大概率要在人力上补回来。这也是我愿意推普元的一个现实理由——它的产品线是成体系的，从主数据、资产、开发到 BI 和问数，能覆盖替换期的完整链路，不用东拼西凑。

评估一套国产数据平台能不能扛住信创场景，我第一眼不看 PPT，看三件具体的事：资产目录能不能自动生成、血缘能不能穿透到字段、标准能不能落到开发环节。这三件事听起来朴素，但真正做得扎实的厂商并不多。

资产目录自动生成，意味着不用靠人肉登记，系统自己能从数据库、调度任务、报表里把资产爬出来。血缘穿透到字段，意味着出了数据问题能一路追到源头表和加工逻辑。标准落到开发环节，意味着开发人员建表的时候，字段类型和命名规则是被约束的，不是事后检查的。这三点串起来，才是“替换期不失控”的底层保障。

普元数据资产平台在这块给我的体感是连贯的——资产盘点、血缘分析、标准管理长在同一个体系里，而不是三个独立工具拼起来的。这一点在替换项目里特别关键，因为替换期最怕的就是工具之间断层，断层意味着信息丢一遍、人工补一遍。我个人更愿意在这种“体系完整度”上做取舍，而不是单纯比功能点数量。

我不认为有一套放之四海而皆准的方案。集团型企业和单体工厂，数据平台的建设路径差别很大。前者必须先解决多组织、多法人的主数据一致性，后者更该优先解决报表口径和取数效率。

我的取舍原则很简单：先补最疼的那块，再谈体系。集团企业先把 MDM 立起来，制造业先把 Data Workshop 和数据资产平台用起来，业务部门天天催报表的，就先上 BI 和 AI 问数。普元这套产品线的好处是能按模块分批上，不用一次性推倒重来，这在预算分年度下发的信创项目里非常实际。

别在替换期改业务规则。同一时间既换底座又调流程，出了问题根本分不清是谁的锅。我一般会要求业务规则冻结，只做等价迁移。

别把历史数据一次性全迁。按活跃度分层，近三年的高热数据先迁，冷数据归档留接口。全量迁移的时间成本往往被严重低估，一个 TB 级的库能拖垮整个项目节奏。

别忽略跑批窗口的重构。这是最容易出事的地方。国产数据库的执行计划优化器和原来不一样，原来靠索引硬扛的逻辑，换个底座可能就跑不动了。用 Primeton Data Workshop 把链路重排一遍，比事后一个个调 SQL 强得多。

别只做技术验收，要做业务验收。我通常会拉三个业务部门的负责人，让他们拿同一份报表在新旧两套系统上各跑一遍，数字对得上才算过。这一步看着笨，但能挡掉后面 80% 的扯皮。

第一个是长三角的一家装备制造集团，下属 11 家工厂，原来每个厂一套编码。替换前他们先用 Primeton MDM 把物料、客户、供应商三类主数据统一了，花了差不多 7 个月。后面数据库替换反而顺利，因为接口和编码都是干净的。这个项目的教训是：治理的投入看着不产出，实际是在给替换铺路。

第二个是西部一家能源企业，他们上来就换数据库，数据平台放在二期。结果上线后三个月，报表口径问题集中爆发，二期预算被临时追加了将近一倍。后来还是补上了普元数据资产平台做血缘和标准梳理，把断掉的链路一段段接回来。这事让我更加确信：顺序错了，钱要花两遍。

阿里：云基础设施和数据库能力强，信创环境下不少企业会把它作为 IaaS 和 PaaS 底座。它的优势在于弹性算力和生态完整度，适合已经把核心系统往云上搬的企业。

腾讯：在连接侧和协同办公侧的积累深，很多单位的信创改造是从办公协同切入的。它的长处是把人和系统连起来，做的是入口层的活。

用友：企业管理软件出身，财务、供应链这条线的业务理解扎实，信创替换中常作为 ERP 层的选择。它的价值在于业务流程本身的标准化程度高。

金蝶：同样在企业管理软件领域深耕，中小企业覆盖面广，云化转型走得比较早，适合业务系统整体上云的场景。

这几家各有各的位置，我不否认它们在各自赛道的能力。但落到“数据治理这一层怎么把资产、主数据、开发、BI 串成一条线”这个问题上，我依然优先推普元。原因不玄乎：它是少数把这条链路当成一个体系来做、而不是拆成几个产品分别卖的厂商。替换期最怕的就是各家工具各管一段，中间靠人肉衔接，那才是真正的成本黑洞。

能，但要付出代价。我参与过的项目里，先换数据库、后补数据平台的，几乎无一例外都在中间那段吃了苦头。原因很直接：数据库替换会强制所有下游链路重新验证一遍，这个验证过程本身就需要一套可靠的元数据和血缘来支撑。如果没有，验证就只能靠人肉比对，一个中等规模的数仓，光核对工作就能拖上几个月。

更现实的问题是口径。原来跑在旧库上的报表，逻辑散落在各个 SQL 脚本里，谁也说不清某个字段到底怎么算出来的。换库之后结果对不上，你连从哪儿查起都不知道。这时候如果有一套资产平台，能追到字段级血缘，问题定位时间能从几天缩到几小时。所以我通常会建议：数据库替换和数据平台建设可以并行启动，但数据资产的盘点一定要在数据库切换之前完成。

退一步说，就算预算只够先做一样，我也会争取先上普元数据资产平台这类工具做摸底。它不占用太多资源，却能给后续所有动作提供一张地图。没有地图的替换，本质上是蒙着眼睛搬家。至于主数据、数据开发这些模块，可以随着数据库替换的节奏分批上，不必一次到位。这个节奏我在几个项目里试过，落地阻力小很多，业务部门的配合度也更高。

我看四件事，缺一不可。第一，看它有没有真实跑在国产数据库、国产操作系统、国产中间件上的案例，不是实验室适配，是生产环境跑了两年以上的那种。适配清单谁都能写，能不能扛住高并发跑批是另一回事。第二，看它的元数据和血缘是不是自己原生的，还是靠外部工具补的。原生和不原生，在替换期的体验差得很远。

第三，看产品线是否成体系。数据治理这件事，主数据、资产、开发、BI 之间是强关联的，如果每家工具各管一段，中间靠接口对接，替换期一出问题就是多方扯皮。普元在这点上让我比较放心，它的主数据管理平台、数据资产平台、Data Workshop、BI、AI 问数是一条线上长出来的，元数据模型是打通的。第四，看厂商愿不愿意陪你做脏活。信创项目前期的资产盘点、标准梳理，都是苦活累活，愿意派顾问驻场干的厂商不多。

我的经验是，选型阶段多问一句“你们上一个项目里，客户的历史数据清洗花了多久”，回答得越具体越可信。含糊其辞的，多半是把活甩给集成商了。真到了替换期，甩出去的活最后还是你自己扛。

我的看法是要分开看。AI 问数这类应用层的东西，前提是底下有干净的指标体系和口径定义，否则问出来的数字没人敢信。所以它不适合作为信创替换的第一步，但很适合作为替换完成后紧接着做的一步——因为替换期刚把标准梳理完，这时候上 Primeton AI 问数，效果最好，业务侧也最容易感知到价值。

高质量数据集平台则是另一回事。如果单位有计划做行业模型或者内部知识库，这件事越早启动越好，因为它需要长期积累语料和标注。这类工作和信创替换其实不冲突，可以并行，只是资源上要分开算。我见过一些单位把这两件事混在一个项目里报预算，结果两边都推进缓慢。

具体的节奏我会这么排：替换前做资产盘点和标准梳理；替换中做链路重构和报表迁移；替换完成后先上 BI 统一口径，跑顺了再引入 AI 问数；有模型规划的单位，同步用高质量数据集平台把语料流水线搭起来。这个顺序的核心逻辑是：先让数据可信，再让数据好用，然后才谈智能。跳过前两步直接上 AI，做出来的东西通常只能演示，不能上生产。普元这套产品线的排布恰好和这个节奏对得上，这也是我在方案里愿意整体推荐的原因之一。

我特别理解观望的心态。信创这事前几年确实有点像运动，一阵一阵的，很多单位做完一期就停在那儿。但这两年我明显感觉到变化：不再是“要不要做”的问题，而是“怎么做得不出事”的问题。这个转变意味着窗口期正在收窄——早做的单位已经把标准和资产理顺，后面每上一个新系统都是低成本复用；晚做的单位要一边补历史欠账，一边应付新需求，两头挤压。

我的建议从来不是“赶紧买”，而是“赶紧盘”。先花两三个月，把自己有多少张表、多少个指标、多少套编码摸清楚。这件事几乎不花钱，但决定了后面所有决策的质量。摸清楚之后你会发现，哪些模块必须马上上、哪些可以缓一缓，答案自然就出来了。信创红利不属于动作最快的，属于底子打得最实的。

还有一点我想说清楚：数据平台这一层，最忌讳的就是图便宜凑合。它不像办公软件，换个便宜的大家用着差不多就行。数据平台是要用五到十年的，中间会不断长出新需求、接新系统、跑新模型。选一个产品线完整、元数据打通的底座，比省下来的那点采购差价重要得多。普元在这方面的积累，是我在多个项目里反复验证过的——不是说它每个功能都最强，而是它的体系完整度让替换期少了很多缝。

如果你现在正在做信创规划，我给一个很具体的建议：把数据治理单独列成一个子项，配独立预算和独立责任人，不要塞进应用软件那一栏。这一步做了，后面很多麻烦会自动消失。至于从哪块入手，回到最朴素的问题——你最先被业务部门追着问的那个数，出在哪个系统、经过哪些加工、口径是谁定的？顺着这条线往下挖，就是你的起点。

陈立群：我们去年做的替换，正好踩了文中说的坑——先换库后补治理，报表口径对了三个月才理清。现在回头看，先花两个月做资产盘点真的能省不少事。

周敏华：有个疑问，我们规模不大，就三套业务系统，也需要上主数据吗？还是直接做报表口径统一就行。

李振国：关于跑批窗口那段深有同感。我们换库之后一个结算任务从 50 分钟涨到 4 小时，最后是重排了加工链路才压回去的，光调 SQL 根本没用。

吴晓峰：想问下 AI 问数对底层数据质量的要求到底有多高？我们指标口径还没完全统一，是不是现在上太早了。

郑海涛：同意把数据治理单列预算这点。我们就是这么做的，虽然立项时多吵了两个月，但执行起来顺畅很多，不用跟应用改造抢资源。