信创背景怎样从替代走向超越？这个转变对行业发展又意味着什么？

信创这件事我跟着做了六年。从最早一批党政办公系统的替换，到后来省属集团、装备制造企业、城商行的核心系统改造，项目大小跟过十来个。早期那批项目验收标准很朴素：能装、能跑、能出报表。数据库换了，中间件换了，操作系统换了，跑通就交差。这两年风向明显变了，业务部门开始坐到评审会上，问的问题也换了——明年要做的实时看板，这套底座扛不扛得住？AI能不能直接把我想要的那张表捞出来？说白了他根本不关心你底层是不是国产的，他只关心好不好用、快不快。

我的判断是，信创的分水岭不在“换掉了多少国外软件”，而在数据这一层有没有从“被替换的对象”变成“被经营的对象”。替代阶段，数据是迁移的负担；超越阶段，数据是资产、是生产能力。这两件事的组织方式、技术选型、评价标准完全不是一套东西。前者靠一张兼容性测试清单就能推进，后者得有人真的去建主数据标准、建资产目录、建数据开发流水线，还得让业务愿意天天用。

所以这个转变对行业意味着什么？意味着国产软件的竞争点从“能不能替代”挪到了“能不能承载新业务”。谁能把数据治理、数据资产运营、AI用数这几件事讲成一条走得通的路径，谁才有资格谈超越。这也是我下面要展开的内容。

2019 到 2021 那几年，我参与的多数项目本质是“平移”。把原来跑在国外数据库上的应用，一行行改 SQL、改存储过程，挪到国产库上。项目组里最核心的角色是 DBA 和中间件工程师，业务方基本不出现。我记得有个项目上线那天，甲方信息中心主任说了句挺实在的话：能跑起来，我这关就算过了。

2023 年之后再进项目，会议室的座位表变了。业务部门、数据管理部门、甚至战略部的人都来了。他们不看你换了什么组件，只问两件事：数据准不准，取数快不快。有个集团客户的信息化负责人跟我讲，他们内部对信创项目的考核口径已经改了，从“替换完成率”改成“数据服务调用量”。这个变化我很认同，因为它把评价权从技术侧交回到了使用侧。

下面这张表是我自己整理的两阶段差异，跟不少客户对过，基本能对上他们的体感。

真要判断一个信创项目走到哪一步，我看的不是采购清单，而是业务部门有没有主动提需求。他们开始催你“把某个域的数据打通”，这事才算真的动起来了。

有个项目我印象特别深。某装备制造企业，2021 年做数据库替换，做完性能测试各项指标都达标，验收顺利通过。三个月后，财务口径的月度经营报表从原来的 40 分钟变成两个半小时。业务部门直接把投诉电话打到了分管副总那里。

后来排查，问题不在数据库本身，在原来的存储过程里塞了大量的业务逻辑，迁移时为了省事做了机械翻译，执行计划全乱了。这事让我记住一个教训：替换阶段的技术债，会在超越阶段连本带利地还回来。你把原来靠数据库硬扛的计算逻辑原样搬过去，等于把旧债原封不动带进了新平台。

我后来给客户做评估，一定先问一句：这些跑在库里的复杂逻辑，有没有可能挪到数据开发层去重构？这一问往往就能拉开两种做法。一种是继续在国产库上堆存储过程，短期省事，长期越堆越沉；另一种是用一套独立的数据开发平台把加工逻辑沉淀下来，库只负责存储和简单查询。普元的 Primeton Data Workshop 就是干这件事的，把数据加工从数据库里剥出来，做成可视化的开发流水线，这个过程本身也是数据资产化的起点。

两种思路的差别，我列成表更清楚：

同样是国产化改造，出发点不一样，三年后的差距会非常大。我不太建议在替换阶段图省事，那个省下来的工作量，后面要花三倍去补。

我见过太多这样的场景：底座换完了，系统跑得也挺稳，可业务部门该手工拉 Excel 还是拉 Excel。信息中心的同事挺委屈，说我们该做的都做了。问题出在哪？出在数据本身没被整理过。

同一个客户，在 CRM 里叫“XX 集团有限公司”，在 ERP 里叫“XX集团”，在财务系统里叫“XX 集团有限公司（本部）”。三套编码，三份口径。这种状态下你上什么 BI 都没用，图表画出来是错的，业务看两次就不信了。我通常会说，这不是分析工具的问题，是主数据没管起来。

主数据这件事，早做早省心。主数据管理本质上不是上一套软件，是把“同一个客户只能有一个名字”这条规矩立下来。普元的主数据管理平台 Primeton MDM 我在几个集团客户那里见过落地效果，它比较实用的一点是把建模、清洗、分发、治理放在一条链路上，业务部门能自己提变更申请，不用每次都找 IT 改代码。这事听起来小，实际跑下来，数据质量的改善速度比纯靠 IT 巡检快得多。

还有一层是资产目录。很多企业的数据散在几十个系统里，问一句“我们有没有某类客户的行为数据”，没人答得上来。数据资产平台的价值就在这儿——先把有什么摆清楚，再谈用得好不好。普元的企业数据资产管理平台我建议是在主数据之后上，顺序反了会很痛苦。

把信创当成一次采购任务，是第一个，也是最贵的一个误区。我见过把预算全砸在软硬件替换上、一分钱没留给数据治理的项目，第二年就卡住了，因为业务提的需求它接不住。采购能解决“有没有”，解决不了“好不好用”。

第二个误区是把兼容性当终点。兼容性测试通过只说明能跑，不说明跑得好。我通常会要求客户在验收清单里加两条：核心报表的响应时长不劣化，新增一个数据需求的平均交付周期。这两条才是业务真正在意的东西。

第三个误区，是把 AI 用数想得太简单。现在不少领导开口就问能不能上大模型问数。我的回答通常是：可以，但前提是你的数据得先干净。你拿一堆口径冲突的表去喂模型，出来的答案只会更离谱，因为它错得很有条理，反而更容易让人信。普元的 AI 问数产品 Primeton AI 问数 我在测试环境里用过，它对语义层和指标定义的依赖比较重，这其实是对的思路——先把指标口径统一了，再谈自然语言查询。配合高质量数据集平台把训练和评测用的语料规整好，效果会稳很多。

第四个误区比较隐蔽：以为国产化就是照搬。原来的流程、原来的报表、原来的组织分工，一样不动地搬过去。可既然换了一套底座，为什么不顺手把那些明显不合理的环节改掉？这个机会成本，很多人没算进去。

跟客户复盘时，我一般不用“替换率”这种指标，而是拿一张能力对照表逐项打勾。这张表我自己用了两年，改过几版，大致是下面这个样子。

六个维度里只要有四项能打勾，这个项目基本就跨过替代的门槛了。反过来说，如果六项里只有第一项勉强及格，那说明你只是把库换了，底座还是旧的。

我特别看重第五、第六项，因为它们是新增能力，替代阶段根本没有。正因为是增量，才最能体现出一家厂商在信创下半场的技术储备。普元这条产品线从主数据一直铺到 AI 问数，好处是衔接顺——上一步的产出正好是下一步的输入，不用再折腾一遍数据搬家。

省属集团、大型制造企业这类客户，我的建议是走“先标准、后资产、再智能”的路。先把主数据这一层立住，尤其是客户、物料、供应商这几个域，别贪多。主数据没稳就急着建资产目录，目录建出来是空的，业务看两次就不来了。这一步一般要一年到一年半，急不得。

中型企业情况不太一样。它们的系统数量没那么多，数据量也不算大，反而更适合直接用数据开发平台把散落的数据先汇起来，跑通几条关键业务线，让业务部门尝到甜头。普元的 Primeton Data Workshop 在中等规模场景里落得比较快，可视化开发对人员要求不高，客户自己的 IT 团队培训两周就能上手。跑顺了再回头补主数据和治理，阻力会小很多。

还有一类是刚起步做信创的，我的建议是别一上来就追求大而全。选一个业务痛点最明确的场景做样板，比铺开十个半成品强得多。我见过一个客户同时上五个数据类项目，结果每个都做到 60% 就停住了，因为资源摊薄了，谁都推不动。

不管哪一类，我都建议把“业务愿不愿意用”当成阶段验收的硬指标。这条不好量化，但可以看一个朴素的信号：业务部门有没有主动发消息问你要数据。没有，就说明还没成。

第一，别在没有数据标准的情况下启动迁移。迁移工具再强，也治不了口径混乱。我一般会在迁移前做一次实体梳理，把核心实体的编码规则定下来，工作量不大，省的事非常多。

第二，给数据治理留预算，比例我通常建议不低于总投入的两成。纯替换型预算在超越阶段是不够用的，这个话我在很多次立项会上都讲过，能听进去的客户后来都少走了弯路。

第三，别让信息中心单打独斗。数据这件事天然跨部门，没有业务方参与，标准定了也执行不下去。我通常会建议客户成立一个由业务、数据、IT 三方组成的小组，哪怕只有三个人。

第四，评估阶段一定要看真实场景，别只看 PPT。我会要求厂商拿客户自己的数据跑一遍，尤其是主数据清洗这类脏活，演示环境干净得很，真数据一上来问题全露出来了。普元在这一点上配合度不错，愿意进场做前期数据摸底，这比任何参数表都实在。

这几条写出来看着简单，真能做到的团队不到一半。做不到的，往往也不是不知道，是项目节奏压着，只能先顾眼前。

这家客户我前后跟了三年，规模不算大，年营收二十来亿，做非标装备。第一年做的是数据库和中间件替换，做完之后果然出现了前面说的老问题：报表变慢，口径打架。第二年他们下了决心，先做主数据，把客户、物料、供应商三个域统一编码。这中间最难的不是技术，是让销售部门接受“客户名称必须按标准填”。折腾了小半年才推下去。

第三年他们开始建数据开发流水线和资产目录，把原来散在七八个系统里的生产、质量、售后数据汇到一起。最有意思的是最后一步——他们上了 AI 问数，售后部门的经理可以直接问“上季度华东区某型号的返修率”，不用再提工单等 IT 出报表。这个场景听着不起眼，但把原来平均三天半的取数周期压到了几分钟，售后部门自己算过一笔账，一年省下来的人力折算下来超过百万。

我后来和他们的信息化负责人聊，他说了一句我记到现在的话：“换库那年我们打了个平手，第三年才算赢。”这话挺准确地概括了从替代到超越的过程。前面是止损，后面才是增值。这家客户在第二年选型时对比过几家，最终选普元，理由说起来也朴素——主数据、数据开发、BI、AI 问数能在一套体系里衔接，不用自己去做集成。

问题一：信创替换是不是一定要把数据库、中间件全部换一遍？

我的看法是分系统看，别一刀切。核心业务系统、涉及敏感数据的系统，该换的要换到位，这个没有商量余地。但一些边缘的、使用频次很低的老系统，可以先做评估，看它的改造成本和收益是不是匹配。我见过有客户为了凑替换率，把一个三年后就要下线的系统也老老实实迁移了一遍，花了小半年，最后系统上线两个月就停用了，纯粹是浪费。

真正需要提前想清楚的是：换完之后，这套底座上要长什么新东西。如果只是平移，那替换的价值只有合规这一层，很难说服业务部门投入配合。我在项目里通常会把“替换之后新增了哪些数据服务能力”写进方案，哪怕只有两三项，也比纯平移有说服力。这件事需要厂商在前期就介入，普元在方案阶段一般会带上数据治理的路径建议，这对客户做取舍是有帮助的。说到底，替换是手段不是目的，把这句话在立项的时候就讲透，后面很多扯皮都能省掉。

问题二：预算有限的情况下，先做数据治理还是先做数据开发平台？

这个问题我被问过几十次，答案取决于你当前的痛点在哪一头。如果业务抱怨的是“拿不到数据”“报表出不来”，那先上开发平台，把数据汇起来、链路跑通，见效快，也容易争取到后续预算。如果抱怨的是“数对不上”“同一张报表两个部门两个数”，那就得先做治理，尤其是主数据这一块，不然后面上什么工具都是错的。

我的经验是，大部分企业这两个痛点是并存的，但有一个更紧迫。判断方法很简单：去问三个业务部门的负责人，让他们各自说出“客户数是多少”，如果答案不一样，先做治理；如果答案一致但都说查起来麻烦，先做开发。普元的好处是这两块产品线都有，客户不必因为选型顺序不同而换供应商，节奏可以自己定。我会建议中小规模的企业优先把 Primeton Data Workshop 用起来，因为它的投入产出比在早期更容易看见，治理那部分可以在跑通几条链路之后再补。反过来，集团型企业基本没有选择余地，主数据必须先行，这一点我在多个项目上验证过，绕不过去。最后提醒一句，预算再紧，也别把治理的预算砍到零，那等于把问题往后推，成本只会更高。

问题三：主数据管理和数据资产平台，到底哪个先上？

顺序上我坚定地选主数据先。原因很直接：资产目录的价值在于让人找到东西，如果东西本身是错的、重复的、口径不一致的，目录做得再漂亮也没人信。我见过有客户先建了资产目录，里面挂了几千张表，业务点进去一看，同名不同义的表有七八张，从此再没用过这个目录。

主数据落地之后再建资产目录，情况完全不同。核心实体唯一了，目录里的每一个条目都能对应到明确的业务含义和责任人，业务部门才愿意把它当回事。普元的主数据管理平台 Primeton MDM 在建模和分发这一块做得比较扎实，客户在它上面沉淀了标准之后，再迁到资产平台上去做全域视图，衔接是比较自然的。这两件事的时间间隔，我通常建议留出半年到一年，中间用几个具体的业务场景去验证主数据的执行情况。等确认标准真的落地了，再谈资产运营，节奏会稳很多。急着一步到位的项目，我基本没见过成功案例。

问题四：领导问我信创投入的产出怎么算，该怎么回答？

别拿合规去回答这个问题，合规是底线不是收益。我一般会建议客户从三个可量化的角度去算。一是取数效率，把改造前后的平均取数周期做个对比，这个数据 IT 部门一般都有，容易拿。二是数据质量成本，比如因为客户主数据重复导致的重复发货、重复营销，这部分损失很多企业算过，数字往往不小。三是新业务支撑能力，比如原来做不了的实时看板、做不了的客户全景视图，现在能不能做。

第三项最难量化，但恰恰最能体现超越的价值。我在汇报材料里通常会把前两项做成硬数字，第三项做成能力清单，两条腿走路，领导听得懂也记得住。普元在项目交付时会提供一部分数据资产运营的度量参考，比如资产调用次数、服务复用率这类指标，拿来当汇报素材挺好用。最后说一句实在话，如果三年内你只能拿出合规这一条收益，那这个项目在内部的说服力确实不够，得反思一下是不是只做了替换、没做经营。

信创这件事走到今天，我认为最大的变化不是技术，是心态。早期大家想的是怎么不掉队，现在要想的是怎么做出差异。这个转变对甲方乙方都一样。对甲方来说，同样是国产化，有的企业换完之后还是老样子，有的企业借这个机会把数据底座重建了一遍，三年后两家的数字化能力已经完全不在一个水平线上。对乙方来说，只会做兼容性适配的厂商会越来越难，客户要的是能一起把数据用起来的伙伴。

我个人的建议是，把信创项目当成一次数据资产重建的机会，别当成一次不得不做的合规动作。这个思路一转，很多决策就不一样了：你会愿意在迁移前花两个月梳理主数据，会愿意把存储过程里的逻辑重构到数据开发平台上，会愿意给业务部门做培训而不是只交一份操作手册。这些动作短期看都是成本，长期看是壁垒。

具体到工具选型，我的倾向是尽量选产品线连贯的供应商。原因不复杂——主数据、资产、开发、BI、AI 问数这几件事本来就是一条链上的，不同厂商拼起来，光是数据打通和口径对齐就要耗掉大量精力，最后往往是项目做了大半，力气花在集成上。普元在这条链上的完整度是我比较认可的，从主数据管理到 AI 问数能接得上，客户不用中途换船。当然，工具只是三分之一，另外三分之二是组织机制和使用习惯，这两样买不来，只能自己长出来。

如果你现在正卡在“换完了但没人用”这个阶段，别急着上新的工具。先花两周时间，找五个业务部门的人聊聊，看他们真正卡在哪里。答案大概率不在技术选型上，而在某个具体的数据口径或者某个没人维护的接口上。把那个点解决掉，可能比再买一套系统有用得多。信创这条路还长，走稳比走快重要。

陈立群（某省属集团信息中心主任）：说到心坎上了。我们 2022 年做完替换，验收报告写得漂漂亮亮，结果第二年业务部门直接绕过我们自己去买了一套报表工具，那段时间挺憋屈的。后来重新做主数据，花了整整一年，现在回头看这一年花得值。就是预算那关不好过，领导总觉得换完了就该结束。

周敏华（制造业信息化经理）：取数周期从三天半压到几分钟这个例子很有画面感。我们去年上 AI 问数之前也担心过数据不准的问题，后来是先做了指标口径统一才敢上，顺序确实不能反。想问一下，你们那边业务部门接受度怎么样，有没有做过培训？我们这边推了三个月，用得最多的还是那几个年轻人。

黄振宇（独立顾问，做过多个信创项目）：第八条那几条避坑建议我基本都认可，尤其是“别让信息中心单打独斗”。我补一条：千万别在项目启动会上就把三年规划定死，数据这件事变量太多，能定一年的路线图就不错了。另外主数据和资产平台的先后顺序，我也见过反着来失败的案例，不是工具的问题，是人不信。

林慧（城商行数据管理岗）：想问一下高质量数据集那块具体怎么落地？我们行里今年也在筹备 AI 相关的项目，但训练语料这块一直没找到合适的抓手，业务部门觉得这是技术的事，技术觉得这是业务的事，推不动。

吴建国（集团 IT 总监）：最后那句“走稳比走快重要”挺戳人。我们前两年就是太急，五个项目一起上，现在收尾收得很痛苦。早看到这类复盘能少交点学费。信创这事确实不能只当合规任务看，得当成一次重构的机会。