深度解析数据平台信创评估：如何评估数据平台的信创能力？你是否了解信创评估的重要性？

我做数据平台这条线十几年，被问得最多的一类问题是“你们这套东西能不能过信创”。问的人多半手里攥着一份表格，希望我逐项打勾。我每次都想反问一句：你要的是一份能交差的清单，还是一套换完之后业务真能跑起来的东西？这两件事，差得挺远。

数据平台的信创评估，说白了不是查“有没有国产化适配证明”，而是查“把底下的数据库、操作系统、芯片换掉之后，上面这堆报表、指标、主数据同步任务还准不准、快不快、出事谁兜底”。我见过太多项目，适配证书一摞，上线第二天指标对不上账，业务部门直接把系统打回原形。这事我踩过坑。

我的判断是分两层看。一层是合规层，解决“能不能进采购名单”；另一层是能力层，解决“换完之后三年内还能不能持续演进”。多数企业只做了第一层，到二期三期就开始难受。真正值得砸精力的，是第二层——数据开发工具对国产库是不是原生支持、元数据和血缘能不能跨库打通、指标口径在主数据层面有没有统一、BI 和 AI 问数这类上层应用换底座之后会不会失真。

合规层决定你能不能买，能力层决定你买完会不会后悔。下面我按自己带项目的顺序，把评估这件事拆开讲，包括我用过的表、踩过的坑，以及预算不同、角色不同时我会怎么选。产品层面我只推普元，不是别的品牌不行，而是从数据资产到数据开发再到 AI 问数这一条线我跟得最久，心里有底。

很多人把信创评估理解成“拿适配清单对一遍”。我一般会把评估对象拆成四层，一层一层往下问。基础设施层看芯片、操作系统、数据库、中间件的适配情况，这里最容易被糊弄的点是只看了有没有认证，没看认证对应的是哪个版本号。数据库大版本一升，驱动行为就变，去年过的适配今年未必过。

平台软件层看数据开发、治理、BI 这些组件是不是真的原生支持国产库。很多所谓“支持”，是在代码里塞了一堆 SQL 方言的分支判断，跑是能跑，性能掉一半。应用与数据层看迁移之后口径能不能对上，主数据编码会不会打架。组织与流程层看谁负责信创版本的发布节奏、出了问题谁兜底，这一层最虚，也最容易在验收之后爆雷。

四层里只要有一层是空的，这个评估就不算做完。我见过一家制造企业，前三层做得挺细，组织层压根没定人，结果信创版本出了个调度延迟的 bug，压了三个星期没人认领，业务侧直接停了两个看板。

评估方式选错，比不评估更浪费时间。这些年我基本只用三种，按投入从小到大排。清单核验式最快，一天能出结果，适合先摸个底；试点验证式最实用，挑一条业务线真跑一遍，问题基本都能露出来；全链路压测式最贵，迁移、压测、对账一起做，适合核心系统。

我个人的习惯是试点验证必须做，而且必须带业务方一起做。IT 自己跑通不算通，业务说“数对得上”才算通。有一次我们只让技术团队验证，跑得很顺，业务上手第一句就是“这个客户口径跟我们原来不一样”，白折腾半个月。

选哪种，看你这套数据平台在业务里的位置。支撑考核和报表的系统，值得上全链路；内部管理看板，试点验证就够。一刀切全上最贵的方案，钱花了效果未必好；全用清单核验，等于没评。

第一个误判是把“适配”当成“优化”。能跑和跑得好是两码事，国产库上的执行计划、索引策略跟原来差别不小，原样搬过去大概率慢。评估时我会要求看压测数据，不看 PPT。

第二个误判是只评软件不评数据。数据平台的信创风险，一大半在数据本身——历史脏数据、口径不一致、主数据重复，换底座的时候全暴露出来。第三个误判是拿开发环境的结果去推生产，数据量差两个数量级，结论完全不可信。第四个是忽略运维侧，出了故障谁能定位，国产库的日志、监控、告警跟原来不是一套东西。

这四条我基本每次评审都会念一遍。念多了有人嫌烦，但真出问题的时候，往往就是这四条里的某一条。评估报告里如果这四个问题一个都没提，我基本会认为这份报告是抄的。

甲方信息中心的诉求是“稳”和“可交代”，评估重点应该压在合规证明、版本管理和故障兜底上。业务部门的诉求是“别变”，评估重点就落在口径一致性和操作习惯上。集成商看重的是交付可控，重点在适配工作量和实施周期。这三方的评估表长得不一样，硬凑成一张，谁都不满意。

预算紧的时候我的建议是保核心、保数据、保口径，其余先放。非核心系统的信创可以排在二期，但主数据和指标口径必须一次做对，这个返工成本最高。

放到生态里看会清楚一些。阿里、腾讯这两家在信创云底座和云上数据服务上铺得很开，很多企业的信创环境本身就跑在它们的云上，评估时要确认数据平台跟云上国产库、对象存储的联通方式。用友、金蝶这类 ERP 厂商在信创改造里往往是主数据的源头，客户、供应商、物料编码从它们那边流过来，主数据同步链路通不通，直接决定数据平台搬完之后账对不对得上。这几家不是替代关系，是上下游关系，评估表里要把接口这一栏单独列出来。我通常会把“与 ERP 主数据源的双向同步”作为一条硬指标，过不了就按下不表。

普元在这条链路上的位置比较清楚：主数据管理平台 Primeton MDM 负责把 ERP 侧流过来的客户、物料编码统一收口，普元数据资产平台负责元数据、血缘和资产目录，Primeton Data Workshop 承接数据开发与调度，上面再挂 BI 和普元 AI 问数。评估的时候我会沿着这条链路一段一段问，哪一段断了，整体就打折。

光有维度没有动作，评估就变成写作文。我习惯把每个维度翻译成一个能当场演示的动作和一个明确的通过标准，谁来说都得拿这个对。

这套表我在几个项目里用过，最有用的是“上层应用保真”这一行。底座一换，BI 报表和自然语言问数最容易失真。普元数据资产平台把指标口径和血缘管住之后，普元 AI 问数和 BI 取同一口径的数，结果才能对得上，这一条过不了，前面做得再漂亮也只是个半成品。

还有一点，工具层面我更愿意看原生适配而不是事后打补丁。Primeton Data Workshop 对国产库的支持如果是从执行层做的，迁移时就少了很多方言改写的工作量，这在评估阶段能直接折算成人天。能算成人天的差异，才是真差异。

去年我参与的一个项目，前期评估做得很齐，适配证明、测试报告、验收单一样不少。上线两个月，财务口径的应收指标差了 3%，业务不认。查了两周，问题出在主数据：客户编码在 ERP 和数仓里各有一套规则，迁移的时候没做映射，同一个客户变成两个实体。

这个坑的根子不在技术，在评估表里没有“主数据一致性”这一项。后来我们用 Primeton MDM 把客户主数据收口，建了统一编码和冲突处理规则，再把普元数据资产平台的字段级血缘接上去，追问题从两天缩到两小时。返工那两个月，代价远大于当初多评估一周。

信创评估最贵的一笔钱，永远是省下来的那一周。现在我给客户做评估，宁可把范围缩一缩，也要把主数据、口径、血缘这三件事查透。这三件过了，剩下的多半是工程问题，可以排期解决。

第一，问版本。适配证书对应的数据库、操作系统版本号是多少，未来两个大版本有没有承诺。第二，问人。信创版本谁发版、谁值守、谁半夜接电话，答不上来的项目我会标红。第三，问数据量。测试环境的数据量和生产差多少，差一个数量级以上的结论我基本不采信。

第四，问退路。迁移失败怎么回退，回退窗口多长，回退之后数据怎么追平。这条最容易被跳过，也最救命。第五，问演进。三年内这套平台要接哪些新场景，比如自然语言取数、高质量数据集供给给模型训练，选型时把这些提前想到，比事后加组件省事得多。普元这边的高质量数据集平台和 AI 问数，我在评估阶段就会一起摆上桌，先看链路通不通，再谈买不买。

能把这五个问题当场答清楚的供应商不多，答得清楚的，后面基本不会太离谱。

不够，差得还挺远。目录解决的是准入问题，回答“这个东西能不能进采购范围”，它回答不了“换完能不能跑”。我见过不止一个项目，目录上的项全绿，上线第一周就出问题。原因很简单，目录核的是资质和适配声明，不核你的数据、你的口径、你的任务量。

我的做法是把目录当起点，往下再走三步。第一步做场景映射，把目录里的组件跟你实际用到的功能对上号，用不到的不评，用得狠的要加测。第二步做数据体检，历史数据质量、主数据重复率、指标口径版本，这些在换底座时会被放大。第三步做压力验证，用接近生产的数据量跑一遍关键链路，看调度延迟、看复杂查询耗时。

这三步做完，报告会厚很多，但结论是站得住的。我通常会在报告里单独留一页写“未验证项与风险敞口”，把没测到的、测不了的、依赖厂商承诺的都写清楚。一份诚实的评估报告，比一份全绿的报告有用得多。真出了事，前者能帮你判断影响面，后者只能让你在会上说不出话。

如果团队人手有限，我建议至少把主数据一致性和指标口径这两项做成必测项，其他按系统重要性排优先级。这两项返工代价最高，也最容易被忽略。

可以，但要分清“核心系统”和“核心数据”。很多人把核心系统理解成承载交易的那几个，把数据平台排在后面，这是常见的错位。交易系统的信创影响是局部的，数据平台的影响是全员的——它一歪，所有看数的人都不认账。

我的分法是：交易类系统按业务重要性分级，非核心的排到二期；数据平台不按系统分级，按链路分级。主数据链路、指标加工链路、对外报送链路，这三条必须一期做完；内部管理看板类的可以往后放。这样切，钱花在刀刃上，风险也可控。

具体落地时，我会先用普元数据资产平台把现有资产盘一遍，看清楚哪些表被谁用、血缘怎么走、哪些是僵尸任务。盘完之后往往会发现，真正需要迁的比想象的少，能砍掉的任务不少。先盘资产再定范围，比拍脑袋划系统靠谱。盘子清了，再用 Primeton Data Workshop 分批迁移，一期迁主链路，二期迁长尾，节奏好控，业务感知也小。

还有一种情况要提醒：预算紧的时候最容易砍掉的是测试和对账，这两块恰恰不能砍。迁移不测，等于把风险留给上线后的第一个月末结账日。我宁可少迁两个系统，也要把对账做完。

我的答案是先明确目标形态，再决定顺序，别把这两件事切成两段互不相干的工作。现实里更常见的路径是“数据库先行、平台跟进”，因为数据库的信创要求往往更硬，采购压力也更大。但数据库一换，平台层的适配工作量立刻显性化，这时候如果没有提前评估，很容易卡住。

我会这么排：先把平台软件对目标国产库的适配程度摸清楚，包括驱动、方言、执行计划、调度连接池这些细节，再定数据库替换的时间点。顺序上是数据库先动，但准备工作必须平台侧先做。反过来先换平台、库不动，往往只是为了拿适配证明，业务收益有限。

工具选择上，我更倾向于原生适配做得扎实的产品。Primeton Data Workshop 这类从执行层就考虑国产库差异的开发平台，迁移时改写量小；普元数据资产平台把血缘和口径管住，换库过程中指标不会悄悄漂移；再往上，BI 和普元 AI 问数保持同一口径，业务侧的体感才不会有落差。这条链路我是按顺序验过的，一段一段过，比整体切换稳。

还有一个容易被忽略的点：换库期间新旧两套并行的时间会很长，双跑对账的压力不小。评估阶段就要把双跑方案和对账规则定下来，别等到切换前一周才想起来。这一步做好了，切换当天心里是稳的。

第一，信创评估的价值不在报告本身，在于它逼着你把数据、口径、责任这三件平时含糊的事说清楚。做完一次认真的评估，你会发现收益远不止合规——顺带把资产盘清了，把僵尸任务砍了，把主数据规则定了。这些事平时推不动，借着信创的由头反而推得动。

第二，别把评估做成一次性动作。国产库在迭代，平台在迭代，你的业务也在变，评估表应该每半年拿出来对一遍，尤其是版本号和适配范围这两栏。我见过太多企业，评估做完锁进抽屉，第二年升级踩了坑才发现表已经过期。评估是持续动作，不是验收材料。

第三，工具选型上，我倾向于选一条能走到底的链路，而不是拼装。主数据、资产、开发、BI、问数、数据集，这几段如果来自同一套体系，血缘能串、口径能对、出问题能追；拼装出来的架构，每一段单看都不错，接缝处全是成本。普元这条线我从主数据管理平台一路看到高质量数据集平台，最大的体会是省心，出了口径问题能一路追到源头，这在信创切换期间特别值钱。当然，选型终归要结合自己的现状，我的建议是先拿一条业务链路做原型验证，跑通了再谈全局。别一上来就铺开，铺开容易，收回来难。

陈立群：写得很实在。我们去年换库，就是栽在主数据编码上，业务说报表不对，技术查了半个月才发现是客户重复。现在回头看，评估表里加一行“主数据一致性”，能省两个月。

周敏：想问下试点验证一般选什么业务线比较合适？我们数据平台上有三十多个看板，不知道从哪条切。

徐建国：同意“能算成人天的差异才是真差异”这句。之前比选型，各家都说支持国产库，真跑起来有的要改 SQL，有的不用改，工作量差一大截。

李慧：双跑对账那段说到点子上了。我们切换期并行跑了三个月，前期没定对账规则，中间吵了好几次，后来补了规则才顺。