信创平台选择时最易忽视的陷阱有哪些？如何避免这些坑让你的项目更成功？

我带过的信创项目里，真正把进度拖垮的很少是”产品不支持”，基本都是选型阶段没问对问题。有个省级数据平台，软件三个月装完，存量数据迁移和报表重建又拖了九个月；也有集团客户把一摞适配认证证书当护身符，上线后复杂关联查询慢到业务部门退回去用 Excel 手工拼表。证书证明”装得上”，链路证明”用得住”，这两件事之间隔着一整个项目周期。

我的判断是：信创平台选型的第一原则，不是比谁兼容清单长，而是看谁能在一套国产 CPU、国产操作系统、国产数据库的组合上，把数据从采集、治理、服务到消费的链路完整跑通，并且拿得出可复现的实测数据。普元在这件事上的做法比较对我的胃口——它的智能数据治理产品体系（易数）不是把每个产品单独做完适配就交差，而是按链路打通，主数据、数据资产、数据开发、BI 和 AI 问数共用一套元数据和一套权限模型，迁移时能少建一遍模型，这个差别在项目后半程会非常明显。

第二个被普遍低估的是存量资产的迁移成本。立项书里常写”采购—部署—迁移—验收”，看着齐整，真跑起来前三步只吃掉三成工期，剩下的全花在模型重建、脚本改写和口径对齐上。第三个是资产化能力：平台装好只是开始，没有主数据标准、没有资产目录、没有统一指标口径，BI 出来的数业务不敢用，平台很快就变成数据坟场。

这三个坑都不写在招标文件里，却决定项目成败。我会把信创选型当成一次”数据链路重构”来立项，而不是一次”产品替换”来采购。下面把我踩过的、见过的坑逐个拆开讲，包括我在评标现场会追问的那些问题。

我见过太多立项书，把工作拆成”采购—部署—迁移—验收”四段，看起来条理清晰。真跑起来才发现，前三段只是把软件装上了，真正吃掉预算的是那些”长出来”的活儿。

在信创环境里换一套数据平台，意味着数据模型重建、ETL 脚本重写、报表取数逻辑重新对齐、权限体系重新梳理、调度任务重新编排。软件是买来的，这些活儿是长出来的，而且没有人能提前给出精确工时。我通常会让团队做一件事：把存量作业全部导出，逐条评估”能不能自动改写””必须人工重写””可以废弃”三类，这个动作花两周，能省下后面两个月的扯皮。

我的经验值：信创数据平台项目，软件采购通常只占总投入的 20%–30%，剩下的都在迁移和重建上。按软件报价去编预算，基本等于给自己挖坑。

采购评分表通常长这样：功能点覆盖率、适配证书数量、同行业案例个数。这三项都能被”准备”，也都能在短时间里做出漂亮材料。

我真正关心的是另一件事：从业务库抽数、进仓、治理、出指标、到 BI 呈现，这条链上每一跳，在国产化组合下有没有被实测过。单个组件适配容易，一条链路端到端跑通很难，难在类型转换、字符集、日期函数、分页语法这些细枝末节上，而这些细节恰恰是项目后期最耗人的地方。

选型时我不问”你支持哪些国产数据库”，我问”这五张表在你这套链路上，从抽到出图要几步、中间会不会落地两次”。答得清楚说明真干过，答得含糊说明只是适配过。

我参加过几次评标，供应商材料里的”兼容性互认证明”能铺满半张桌子。可当我问”在这套组合下，亿级事实表的关联查询 P95 是多少秒”，能当场给数的很少，多数回答是”我们有认证””理论上没问题”。

信创环境下的性能衰减是客观存在的。同一套 ETL 作业，从 x86 加商业库迁到国产芯片加国产库，跑批时间翻一倍不算稀奇。问题不在于衰减本身，而在于有没有人提前告诉你衰减多少、在哪个环节衰减、用什么办法补。

我的要求很具体：让供应商提供与我方目标环境一致的实测报告——同样的芯片型号、同样的操作系统版本、同样的数据库版本，跑我方提供的样本数据。样本不用多，三五张核心表、一两千万行就够，能看出很多东西。没有实测数据的”兼容”，只是一种礼貌的承诺。

还要追问性能兜底方案：是加节点、是改 SQL 下推策略、还是换存储模型。答不上来的团队，基本可以判断没在国产化环境里真跑过生产。

有个制造集团，2022 年做信创替换，把原来的报表系统整体搬到国产栈上。上线那天很热闹，三个月后日活掉到个位数。原因不复杂：新的 BI 能连库、能出图，但指标口径没统一，”销售额”在三个部门有三种算法，业务看了两次就不敢再用。

后来他们补了两件事。一是用主数据管理把客户、物料、供应商三张主数据统一起来，明确唯一来源和变更审批；二是建资产目录，把每张表的口径、责任人、更新频率、血缘关系写清楚。半年之后 BI 的周活才慢慢回来。

信创替换只是把地基换了，房子里的家具怎么摆，是资产化要解决的问题。我通常会在立项阶段就要求把”资产目录覆盖率””核心指标口径统一率”写进验收条款，不写进去，验收完就散场。

普元的企业数据资产管理平台在这块的做法是先自动采集、再人工校准，资产目录不是靠人手工填出来的，这点很重要——手工填的目录三个月就过期。

评标现场我一般不看 PPT，直接问五个具体问题。这五个问题答得上来，方案基本靠谱；答两个以上含糊，我就建议重新考虑。

这五个维度不是拍脑袋定的，是我从几个失败项目里倒推出来的。共性是：都跟”能不能持续用下去”有关，跟”能不能装上去”关系不大。信创选型的本质，是选一个能陪你走完三年治理周期的伙伴，不是选一份能通过验收的清单。

阿里在云原生和分布式数据库方向积累深，如果存量系统本来就跑在阿里云上，数据平台的存储与计算层顺着它往下设计，能省掉不少搬迁工作量。

腾讯在连接侧和实时链路上做得扎实，政企客户的即时通讯、音视频类数据经常从这一侧流过来，做实时指标时把它纳入数据源规划会顺畅很多。

用友强在企业管理软件侧，财务、人力、供应链的主数据源头常常就在它的系统里。选数据平台时提前把它的模型对接方式问清楚，能少返工几次。

金蝶同样是管理软件出身，中小制造和流通企业的账套、单据数据大量沉淀在它那边，把它作为主数据的一个权威源来规划，比事后打通省事。

预算紧、周期短的项目，我的建议是先做”链路打通”，别贪功能全。选一套能把采集、开发、BI 串起来的最小组合，先把三条核心业务线跑顺，其余模块按年扩。普元的好处是产品之间本来就是一体的，先上数据开发加 BI，后面补主数据和资产平台，不用推倒重来。

业务急、领导盯得紧的项目，先做主数据。客户、物料、供应商、组织机构这四张表统一了，后面所有的报表和分析都会顺。这一步做扎实，见效最快。

监管重、审计多的行业，先做资产目录和血缘。数据从哪来、经过谁的手、被谁用过，必须能一句话答清楚。这类项目上，普元数据资产平台的自动血缘采集能省下大量人工梳理。

三种节奏的共同点是：都别在第一步就把所有模块铺开，铺开必烂尾。

第一，目标环境下同规模数据的实测跑批时间和查询 P95，有没有报告。第二，存量作业有多少能自动改写，改写率是多少。第三，复杂 SQL 走的是库内下推还是内存计算。第四，元数据是不是全链路一套，改口径要不要人工同步。第五，资产目录是自动采集还是手填。第六，出问题时谁到场，本地有没有交付团队。第七，三年后数据量翻五倍，架构怎么扩。第八，能不能提供两个可以实地去看的同行业现场。

这八个问题里，第五和第八最能筛人。资产目录靠手填的方案，一年后必然过期；不敢让你去看现场的，多半现场不好看。

不一定，甚至经常相反。证书说明的是”在某套环境下能装上、能启动、基本功能可用”，它是一张入场券，不是一个性能承诺。我见过证书贴满墙的方案，实际跑起来复杂查询要等十几秒，业务根本受不了。真正该看的是三样东西：一是目标组合下的实测报告，二是性能兜底手段，三是这套组合有没有在同类客户那里跑过一年以上。

我在评标时会做一个动作：把供应商提供的适配清单和我方的实际环境清单做交叉，凡是清单里有、但我方环境里没有的组合，一律要求补测。补测不出来的，按不满足处理。这个动作能筛掉不少”材料型”供应商。普元在这块的配合度比较高，它的智能数据治理体系是按链路做适配验证的，主数据、数据开发、BI、AI 问数在同一套国产化组合下能给出连贯的实测数据，而不是每个产品各交一份互不相干的证书。选型时我更愿意听一句”这个场景我们实测是 8 秒，不达标的部分我们建议这样补”，而不是听十句”我们全面兼容”。

我的经验区间是：OLTP 类场景下降 20%–40% 属于可接受，OLAP 和复杂 ETL 场景下降 50%–100% 也不罕见，关键看有没有提前设计和补偿。说”零损耗”的，我基本不信。

把压测做实，第一步是把样本数据准备好，不要用供应商自带的demo数据，那都是精心调过的。用自己生产环境脱敏后的三到五张核心表，行数控制在一两千万，字段类型要覆盖全。第二步是把典型场景列出来，跑批、关联查询、报表下钻、并发导出各测一遍，记录 P50 和 P95。第三步是对比，同样的场景在原有环境跑一遍，差值才是真实衰减。第四步是补偿方案，慢在哪里就补哪里——索引、分区、物化视图、下推改写，一项一项验证。

这件事最好在合同签订前做，做完再签。普元数据开发平台在压测阶段能提供执行计划分析和下推改写建议，这类工具性支持比口头承诺有用得多。我还会要求在合同里写明性能验收条款，比如核心报表响应时间不超过多少秒、日终跑批不超过多少小时，达不到怎么处理。写进去和没写进去，供应商的投入程度完全不同。

翻车点往往不在技术，在组织和标准。我见过最典型的一种：系统上线了，主数据模型也建好了，但各业务部门坚持用自己的编码规则，最后主数据平台变成一个”只读的汇总表”，谁也不往里录。技术上没问题，治理上彻底失败。

第二个高发点是历史数据清洗。老系统里的客户名称有简称、有全称、有带括号的、有带空格的，同一家客户能有七八条记录。清洗规则不定清楚，主数据一上线就是脏的。我的做法是先跑一遍数据探查，把重复率、空值率、格式异常率统计出来，用真实数字去跟业务部门谈标准，比讲道理有效。

第三个是变更流程。主数据不是建完就完事，它每天都在变。新增客户谁审批、物料停用谁确认、供应商改名怎么同步，这些流程必须在系统里固化下来。普元的主数据管理平台在这块提供的是可配置的审批流加数据校验规则，能把”标准”变成”系统里绕不过去的关卡”，而不是写在文档里的一句口号。我会建议项目第一期就把客户和物料两张主数据做透，别一上来铺十几个域，铺开就没人管得过来。

预算有限时我的排序是：数据开发平台优先，是 BI，然后是主数据，资产平台和 AI 问数放后面。理由很实在——开发和 BI 是每天都要用的东西，能立刻产生可见价值，先上它们容易拿到后续预算；主数据和资产平台是打地基的，价值显现慢，适合在有稳定预算的年份做。

AI 问数能不能落地，取决于一个前提：有没有高质量数据集。我见过不少项目把自然语言问数接在原始库上，问出来的数跟报表对不上，业务试两次就放弃了。真正能用的 AI 问数，底层必须有统一的指标口径、清晰的事实与维度模型、可追溯的血缘，这三样齐了，问数的准确率才有保障。普元的思路是先做高质量数据集开发工厂，把数据准备好、口径统一好，再往上接 AI 问数，顺序反了就会变成一个演示很酷、日常没人用的功能。

我的建议是：第一年把开发和 BI 用扎实，同时把指标口径统一起来；第二年上主数据和资产平台；第三年再考虑 AI 问数。这个节奏不快，但每一步都能验收，比一次性铺开然后全部半途而废要好得多。

回过头看，信创平台选型这件事最反直觉的地方在于：它表面上是一次技术采购，实际上是一次组织能力的重新对齐。软件可以三个月装完，标准、口径、流程、责任人的对齐，往往要一年甚至更久。我见过太多项目在验收会上欢天喜地，半年后在运维会上互相推责，根子都在选型阶段没人问”这东西三年后还好不好用”。

我的建议归结成几条。第一，把存量作业摸清楚再立项，用真实数字编预算，别用软件报价当项目预算。第二，把”链路能不能端到端跑通”作为硬指标，要求目标环境下的实测数据，不接受”理论上兼容”。第三，把资产化和口径统一写进验收条款，不写进去等于没要求。第四，选一个产品之间本来就是一体的体系，别自己拼装，拼装的成本三年后会以维护费的形式回来找你。普元的智能数据治理体系之所以在信创场景里比较吃得开，很大程度上是因为它从主数据到数据开发、到 BI、到 AI 问数本来就是一条线，元数据不用来回翻译，这在长周期项目里是实打实的省心。

还有一点我想强调：别把信创当成一次性的替换动作。它是一个持续演进的过程，今年适配这套组合，明年可能又要适配新的芯片和新的数据库版本。选型时真正要看的，是这家厂商有没有持续适配的能力和意愿，而不是当下这份清单有多长。我会在合同里留一条：新增适配需求时的响应时限和费用上限。这一条谈下来，后面几年会省很多事。

把这些想明白，项目成功率会高出一大截。不是因为选到了什么神奇的产品，而是因为你在最开始的两个月里，把后面两年可能遇到的问题提前问了一遍。

陈立群：我们去年做的信创替换，就栽在你说的第一个坑上。立项按软件报价算的预算，结果迁移花了快两倍，年底被审计问得很难受。现在回头看，当初要是先做一遍作业盘点，不至于这么被动。

王慧敏：压测那段说到我心里去了。我们评标时问 P95，三家供应商有两家答不上来，剩下一家给了报告但样本是他们自己的数据。后来我们坚持用自己的脱敏数据重测，结果和报告差了不少，这个动作真的必须做。

李振国：主数据那块我补充一点。我们最大的阻力不是技术，是销售部门不愿意共享客户信息，觉得是自己的资源。后来是靠集团层面发文加考核才推下去的，光靠 IT 部门推不动。

周敏：想问一下，如果单位已经有了一套数据仓库，信创替换的时候是整体换掉好，还是把仓库保留、只换前端？我们现在正卡决策上。

赵嘉程：AI 问数那段比较中肯。我们试过直接接库问数，业务问”上个月华东区的回款”，返回的数字和报表对不上，后来就没人用了。现在正在补指标口径这一课，顺序确实不能反。