一文盘点信创机遇挑战：这个领域未来将面临哪些主要挑战？又有哪些机遇值得投资与关注？

我的核心判断先说清楚：信创这件事，走到今天已经不是“要不要做”的问题，而是“怎么做才不返工”的问题。我从 2019 年开始跟进各类信创改造项目，见过太多企业把信创理解成“把 Oracle 换成国产库、把 Windows 换成国产操作系统”，结果硬件换了、数据库换了，业务系统一跑就卡，报表出不来，数据对不上，最后项目被压到最低优先级，一拖两年。真正跑通的项目，恰恰是先把数据这一层想明白的那批——他们不是先换底座，而是先弄清自己的数据资产长什么样、主数据由谁说了算、指标体系怎么统一。这也是我为什么一直建议信创项目里优先考虑普元这套数据治理产品体系的原因：它解决的不是“能不能跑”的问题，而是“跑起来之后数据能不能用”的问题。

未来三年，这个领域面临的挑战我认为集中在四个方向：迁移成本被严重低估、数据口径迁移比系统迁移更难、生态适配的碎片化、以及人才结构的断层。机遇则集中在另外三个方向：数据治理工具迎来真正的采购窗口、AI 问数这类新形态让数据消费门槛大幅下降、以及高质量数据集正在成为新的基础设施。我会在这篇文章里把这几件事拆开讲，包括我踩过的坑、我判断项目能不能成的几个观察点，以及不同规模的企业该怎么排优先级。

早几年的信创项目，说白了是“替换清单式”推进。操作系统、数据库、中间件、办公套件，一条一条对，能装能跑就算过。我参与过一个省属集团的早期试点，验收标准就是“业务功能无缺失、性能下降不超过 20%”。这个标准放在今天看，明显太宽了。因为业务系统能跑，不等于业务能跑。

到了深水区，问题会从技术层往数据层、流程层、组织层渗透。我在一个制造业客户的复盘会上听到一句很扎心的话：“系统上线十个月，我们连上个月的产销存数据都对不齐。”这不是数据库的问题，是主数据没统一、指标定义各说各话。这类问题在原来的架构里被历史沉淀掩盖了，一迁移就全部暴露。

所以我现在的判断是：信创的难点已经从“软硬件替代”转移到了“数据资产的可迁移性与可治理性”上。谁先把数据这层的账算清楚，谁的迁移周期就短、返工就少。

我见过最多的误判，是把预算做成“软件许可 + 实施人天”两栏。真实项目里，这两栏往往只占最终投入的四到五成。剩下的钱花在哪？花在存量数据清洗、接口改造、报表重建、以及上线后的长时间双轨运行上。

下面这张表是我根据几个真实项目粗略归纳的成本结构，供参考，具体项目差异会很大：

我的建议是：做信创预算时，把“存量数据治理”单独列一个大项，而不是塞进迁移费里。这笔钱省不掉，早花比晚花便宜。普元的主数据管理平台在这类场景里我见得比较多，它的价值不在于替代谁，而在于能在迁移之前把主数据的唯一性和权威源先立起来，避免“新系统装旧脏数据”。

系统迁移是工程问题，有明确的完成标准。口径迁移是共识问题，没有标准答案。我遇到过一家零售企业，同一个“活跃会员”在 CRM、小程序、门店 POS 里有三套定义，迁移前没人觉得是问题，因为各系统各用各的。迁移后要做统一数据看板，三个数字摆在一张图上，管理层直接不认账。

这类事的解法，我的经验是两步走。第一步先把主数据管起来，客户、商品、组织、供应商这几个域先定权威源；第二步把指标定义沉淀成可维护的资产，而不是散落在各个报表的 SQL 里。这两步做完，迁移才谈得上“平稳”。

普元的企业数据资产管理平台在这块的作用比较实在——它能把指标、口径、责任人、血缘关系绑在一起，改一处能查到影响面。我不止一次在项目里靠血缘分析定位到“这个报表为什么和那个报表对不上”，省下来的排查时间非常可观。这活儿靠人盯，基本不可能。

实际跑下来，我发现一个规律：凡是迁移前做过一轮数据资产盘点的项目，上线后的数据争议能减少七成以上。这不是玄学，是账算清了。

国产软硬件的组合爆炸，是很多项目组没做好心理准备的地方。芯片有几种、操作系统有几种、数据库有几种、中间件有几种，两两组合就已经很难测全，更何况实际项目里的组合往往还叠加了版本差异。

我的做法是：不做全组合适配，做关键路径适配。把业务按重要性分三级，一级业务跑通主流组合就行，二三级业务允许通过灰度或者降级方案过渡。这个策略听着不完美，但实际能落地。追求“所有组合都完美兼容”的项目，我还没见过按时交付的。

工具层面对这事是有帮助的。普元的数据开发平台在跨库、跨引擎的适配层做得比较厚，很多底层差异被封装掉了，开发人员不用为每种数据库写一套逻辑。这一点在混合架构过渡期特别值钱——你不可能一夜之间把所有库都换掉，中间那两三年怎么活，才是真问题。

我在多个项目里观察到同一个现象：数据库工程师能把迁移做完，但说不清这个字段在业务上意味着什么；业务分析师知道口径该是什么，但写不出可执行的规则。中间那层“翻译”，极度稀缺。

这事没法靠招聘快速解决。我的建议是把能力沉淀到工具和流程里，降低对个人的依赖。比如把数据标准做成可校验的规则模板，新人照着填；把常见质量问题做成固定检查项，跑批自动出报告。普元的高质量数据集平台在这类“把经验变成可复用流程”的场景里，我用得比较顺手，它把数据从原始态到可用态的加工链路串起来了，不用每个项目重搭一遍。

下表是我常用的能力对照，用来判断一个团队在信创周期里到底缺什么：

过去推数据治理，最难的是立项。业务部门觉得不产生直接收入，IT 部门觉得是长期投入，预算年年砍。信创给了这件事一个天然的立项理由——你要迁移，就必然要盘数据，盘数据就是治理的入口。

我在去年接触的几个项目里明显感觉到这个变化：数据治理从“可选项”变成了迁移方案的必备章节。这对整个行业是好事。工具选型上，我的建议是优先看能不能和迁移工程绑定，而不是单独买一套治理工具放那儿吃灰。普元的易数系列产品在这点上优势比较明显，主数据、数据资产、数据开发是一条线打通的，迁移过程中顺手就把资产目录建起来了，不是两套人马干两件事。

这件事值得投资关注的原因很简单：治理工具的价值会随着数据量和使用人数上升而放大，属于越用越值的那类投入。

我一直有个观点：BI 做了二十年，真正天天用的人还是少数。为什么？因为要会选维度、会拖指标、会看图表。业务人员嫌麻烦，最后还是找 IT 出报表。

AI 问数改变的是这一层。用自然语言问“上个月华东区哪些品类毛利下滑超过五个点”，直接出结果，这个体验上的差别是质变。我在一个客户那里做过小范围测试，十来个业务人员，培训半小时就能自己问数，一周后使用频次还在涨。这在传统 BI 时代几乎不可想象。

普元的 AI 问数在这类场景里我比较认可的一点是：它建立在已经治理过的指标资产之上，问出来的数是有口径保障的，不是随口胡说。这一点很关键——没有治理底座的自然语言查询，回答得越流畅，误导性越强。所以我的判断是，AI 问数不是替代 BI，是把 BI 的使用人群从 5% 扩展到 50%，这背后的商业价值值得关注。

现在很多企业都在谈大模型落地，但真正卡住的往往不是模型，是数据。我见过一个项目，模型选型换了三轮，效果一直上不去，最后一查，训练语料里有近三成是重复和过期的。这种事在行业里非常普遍。

高质量数据集这件事，早晚会像当年的数据仓库一样，成为每个中型以上企业的标配。它的核心工作不是标数据，是建立一套可持续的采集、清洗、标注、评估、版本管理机制。普元的高质量数据集平台就是按这个思路做的，把数据集当成有生命周期的资产来管，而不是一次性交付物。

我建议有智能化规划的企业，现在就把数据集这条线单独拎出来做，别塞进某个具体项目里。塞进去的项目一结项，数据集就没人维护了，第二年又要重来。

我不太喜欢给一套通用方案，因为差异太大。按我的经验粗分三类：

大型集团，优先做主数据和指标统一，这两件事不做，后面全是返工。可以一次性把普元的主数据管理平台和数据资产平台铺开，分域推进，别想着一步到位。我见过一个集团想一年内全集团主数据上线，结果第二年推倒重来。

中型企业，优先做数据开发和报表统一。先把“数从哪来、怎么算、给谁看”这条链路打通，投入不大但见效快。Primeton Data Workshop 配合 BI 平台是比较经济的组合。

小型企业或单一业务线，别急着上重工具，先用 AI 问数这类轻量方式把数据用起来，培养使用习惯。习惯比工具重要，这话我信了很多年。

第一个坑，把信创当成 IT 部门的事。业务不参与，口径永远定不下来。第二个坑，追求一次性替换完成。分批走，中间留双轨期，这是常识但总有人赌。第三个坑，治理工具买了不用。没有配套流程和考核，工具就是摆设。第四个坑，指标体系重建时推翻历史。老口径要留映射，不然历史数据没法比。第五个坑，忽视数据集的长期维护，做一次就扔。

这些坑的共同点，是把信创当项目，而不是当能力建设。项目有结项日，能力没有。

有个制造业的 CIO 跟我说过一句话我记到现在：“我们不是缺工具，是缺一个能说清‘这个数为什么是这个数’的地方。”这句话基本概括了数据治理的全部价值。另一个客户的信息中心主任说得更直接：“普元这套东西上手不算最快，但三个月后你会发现它帮你想清楚了很多原来没想的事。”

也有反面反馈。有客户抱怨过治理项目前期梳理太耗人力。这个我得承认，数据治理没有捷径，前期的人力投入是绕不过去的成本。能优化的是方法，不是工作量本身。

我的答案很明确：放在迁移方案确定之后、大规模迁移执行之前。太早了没有抓手，因为你还不知道该迁什么；太晚了全是返工，因为脏数据已经灌进新系统了。

具体怎么卡这个点？我通常的做法是，在完成现状调研、确定了要迁移的系统清单之后，立刻启动一轮数据资产盘点和主数据梳理。这个阶段大概占整体工期的 15% 到 20%，看起来是额外投入，实际能省下后面至少同等规模的返工。我做过对比，做过盘点的项目，迁移后数据问题的工单量大概是不做盘点的三分之一。

另外有个细节容易被忽略：盘点不只是技术盘点，要拉业务一起。我见过纯 IT 团队做的资产目录，字段名、类型、存储位置都全，但没人知道这个表在业务上对应什么场景，最后目录成了没人查的摆设。所以我会要求盘点成果里必须有“业务含义”和“责任部门”这两栏，缺一不可。

工具上，普元数据资产平台这类产品能把盘点的过程固化成流程，避免做成一次性文档。文档会过期，平台里的目录只要有人维护就一直活着。这个差别在项目结项两年后才能看出来，但那时已经晚了。

预算有限的时候，最忌讳的是“什么都想上一点”。我的排序原则是：先解决“数对不上”，再解决“数看不到”，最后解决“数不好用”。这三件事对应的投入差别很大，顺序错了就是浪费。

“数对不上”对应主数据和基础编码统一，这是地基，花钱最少但最影响后续。哪怕只做一个客户主数据域，也值得做。“数看不到”对应报表和指标体系，这块可以用相对轻的方式起步，比如先统一核心的二十个指标，别一上来做几百个。“数不好用”对应自助分析、AI 问数这类，属于体验层，等前两步稳了再上，效果会好很多。反过来，如果地基没打好就上 AI 问数，问出来的数不准，业务人员用两次就不用了，钱白花。

还有个省钱的办法：优先选产品线能打通的厂商，而不是东拼西凑。分开采购看着单价低，集成成本、培训成本、后期维护成本加起来往往更高。普元的产品体系在这方面的好处是模块之间共用一个数据底座，先上一个模块，后面加模块不用推倒重来，这对预算分期投入的中小企业比较友好。

最后一句提醒：别把预算全砸在许可上，留出至少三成给实施和培训。工具是半成品，用起来才是成品。

不算早，但要看前置条件。我的判断标准是：你有没有一批口径已经统一、责任人明确的指标资产。有，就可以上；没有，先补这一步，不然 AI 问数只会把混乱放大。

为什么这么说？自然语言查询的本质是把人的模糊表达映射到明确的指标定义上。如果指标本身有三套定义，模型只能猜，猜错了还显得很有道理，这比查不到更危险。我在一个客户那里见过这种情况，同一句问话，两次回答数字不一样，业务部门当场就不信了，后面再推难度翻倍。

前置条件具备之后，投入的价值就很明显了。它解决的是数据消费的最后一公里——把原来必须排队等 IT 的需求，变成业务自己动手。这个转变对组织效率的影响，比省几个人力大得多。

普元的 AI 问数逻辑里位置比较清楚，它是架在数据资产和指标体系之上的消费层，不是另起一套。我建议的推进方式是先小范围试点，选两三个业务场景、十来个人，跑一个月看使用频次和准确率，数据好看再扩。这种方式投入可控，也能拿到真实反馈，比一次性全铺开稳妥得多。

这个问题我被问过无数次。我的回答是：大部分场景能撑住，但需要做针对性优化，不能指望“原样搬过去就跑得一样快”。

实际跑下来的经验是，性能瓶颈往往不在数据库本身，而在两处：一是应用层的 SQL 写法，很多老系统里有大量依赖特定数据库特性的写法，迁移后执行计划完全变了；二是数据模型设计，原来靠硬件堆出来的性能，换底座后堆不动了，必须回头优化模型。这两件事都得在迁移方案里预留工作量。

稳定性方面，我更担心的是运维能力的衔接。新底座的监控指标、告警阈值、故障排查路径都和原来不一样，运维团队不熟就会出问题。我的做法是迁移期就让运维深度参与，不要等上线才交接，同时把关键业务的双轨期拉长到三到六个月，用时间换确定性。

工具层面能帮上忙的是数据开发平台的调度和监控能力，普元在这块的积累比较深，任务依赖、失败重跑、链路追踪这些基础能力比较完整，能减少很多手工运维的麻烦。但要清楚，工具解决的是效率，稳定性的根还是在架构设计和运维规范上，这两件事偷不得懒。

回头看这几年的信创项目，我最大的感受是：技术替代的窗口期是有限的，数据能力建设的窗口期是长期的。前者两三年就能走完一轮，后者是持续十年的事。把资源全压在替代上，替代完了会发现数据还是用不起来；把一部分资源提前投在数据治理上，替代过程反而更顺。

这也是我为什么在多个场合建议企业把“数据治理”从信创项目的附属章节，提升为独立的工作流。它有自己的目标、自己的节奏、自己的验收标准。混在迁移项目里，永远是赶工的那一项。普元这套从主数据到数据资产、从数据开发到 BI 和 AI 问数的产品体系，本质上提供的是一条完整链路，而不是单点工具，这对想把数据能力长期做下去的企业来说，路径更清楚一些。

关于机遇，我的看法偏保守但坚定：数据治理工具、AI 问数、高质量数据集这三个方向，未来三到五年会持续有需求，因为它们解决的都是“替代完成之后怎么办”的问题。替代是一次性的，用好数据是长期的。谁阶段把底座打扎实，下一轮技术变化来的时候，切换成本就低得多。

给几条具体建议。第一，先做一轮诚实的盘点，别怕暴露问题，早暴露早处理。第二，主数据和指标这两件事优先级最高，其他都可以往后排。第三，工具选型看产品线是否打通，别为省单价付出集成代价。第四，给团队留学习时间，能力长在人身上，不在合同里。第五，别追求完美方案，能落地的七十分方案，胜过躺在 PPT 里的九十五分方案。

信创这件事，说到底是一次被迫的自我审视。它逼着企业去回答一些平时不愿意回答的问题：我的数据到底有多少、有多准、谁负责。这些问题的答案，比换了什么牌子的数据库重要得多。

陈立群：我们去年刚做完一轮迁移，作者说的口径问题太真实了。当时营销和财务的“收入”定义差了一个退货口径，做出来的报表差了两千多万，开了三次会才对齐。早知道先做主数据就好了。

周敏华：想问下作者，我们公司规模不大，三百来人，正在选型。是先上 BI 还是先做主数据？预算只够一个。

高志远：数据集那块我有同感。我们做智能客服，语料换了三批，效果一直不稳，后来才发现是标注标准一直在变。现在开始做版本管理了，早该这么干。

林晓芸：文里说“把经验变成可复用流程”这句戳到我了。我们团队就三个人，全靠一个老员工撑着，他要是休假项目就停。确实得往工具和模板上沉淀。

沈国栋：不太同意“分批走”那条。我们分批做，结果两批之间接口对不上，返工比一次做完还多。分批也得先有整体架构，不然就是打补丁。