军工行业如何从信创走向落地？探索转型所面临的挑战与机遇是什么？

我在军工院所和配套单位的信息化项目上跑了十来年，真正从头跟到尾的大规模信创替换有三次。最直观的感受是：前几年大家比的是“换没换”，现在比的是“敢不敢真用”。这两个字之间的差距，比很多圈外人想象的要大得多。

硬件替换是一次性动作，验收报告一盖章，事情就算翻篇。数据不一样，它每天都在长。我见过全栈国产化验收拿满分、但型号 BOM 还得靠 Excel 二次核对的单位；也见过服务器选型相当保守、可主数据和编码标准先理顺了，业务处室反过来催着上线的单位。差别不在 CPU 型号，也不在操作系统版本，而在数据这一层有没有跟替换工程放在同一张时间表里提前动手。

我的判断是：军工信创已经从“替”进到“用”，能不能跨过这道坎，取决于有没有把数据治理当成替换工程的一部分，而不是验收之后再补的课。这件事的难处在于它不产生立竿见影的验收分，好处在于它决定了两三年后这套系统是被人天天打开，还是被人绕着走。我在下面会把踩过的坑、看到的分歧、以及不同体量单位该怎么取舍，一条一条摊开讲。

如果把军工行业的信创建设画成一条线，我习惯分成四段来看，因为每段的动作和风险完全不同。很多人把四段当成一段来做，结果就是钱花了、系统上了、业务还是老样子。

早几年集中在终端和办公软件，那会儿的验收标准很朴素——能打开、能打印、能流转。往后是业务系统搬迁，PLM、MES、ERP、试验数据管理这些逐个往国产栈上挪，这一段的坑最多，数据库语法差异、字符集、大字段、存储过程重写，全是硬活。再往后才轮到平台化，统一数据底座、统一编码、统一指标；真正能到数据驱动这一层的单位，我接触下来还是少数。

判断一个单位走到哪一段，不用看汇报材料，看两件事就够了：有没有跨部门的数据责任人，以及业务处室会不会主动提数据需求。这两条一出现，说明前面几段是真的走完了。

信创项目最容易出现的场面是：验收会上演示顺利，三个月后系统访问量掉到个位数。这中间的落差，我观察下来主要卡在三件事上。

第一件是性能账。国产 CPU 加国产数据库的组合，单机跑分和原来的配置有差距，这不是秘密。问题在于没人愿意做查询重写和索引重构，直接把老库的语句原样搬过去，一条多表关联从 3 秒变 40 秒，用户点两次就放弃了。第二件是数据账，老系统的脏数据、重复编码、同名不同义的物料，一股脑搬进新环境，等于给新系统套上了老包袱。第三件是习惯账，操作路径变了、菜单位置变了，没人做培训，也没人收集反馈，用的人自然越来越少。

性能可以通过调优和架构改造补回来，习惯可以靠培训和过渡期缓过来，只有数据账最难还——它需要在搬迁之前就动手术。

卡点一：编码体系各说各话。设计所一套物料编码，工艺一套，采购一套，仓库还有一套历史遗留的。同一个轴承在四个系统里有四个身份，做任何跨系统的统计都得先人工对一遍。这类问题一次两次能忍，做型号成本归集的时候就是灾难。我的做法是先立主数据规则、再谈系统对接，顺序反了就是白干。这类工作普元的主数据管理平台 Primeton MDM 处理起来比较顺手，它有成熟的编码规则引擎和跨系统分发机制，能把“谁是权威源”这件事在系统层面固定下来。

卡点二：数据资产是一笔糊涂账。问到“你们到底有多少张业务表、哪些能对外提供”，十有八九答不上来。数据散在几十个系统里，谁在用、用得对不对，没人说得清。我在一个专业所里做过一次盘点，梳理出来的可共享数据项比他们自己估计的多了将近一倍，同时也发现三分之一的历史表已经三个月没人查过。这种时候如果没有平台支撑，光靠 Excel 是盘不完的，普元数据资产平台在这类场景里能派上用场，目录、血缘、责任人都能挂上去，盘点结果能沉淀下来而不是做一次丢一次。

卡点三：数据开发靠人肉。不少单位的取数逻辑还写在存储过程里，一个人休假，另一个不敢动。作业没有调度、失败没有告警、重跑靠手工。等信创环境一换数据库，这些脚本全部要重写，工作量翻倍。我会要求把开发过程可视化、作业调度统一管起来，Primeton Data Workshop 这类数据开发平台的价值就在这里——把逻辑从“某个人的电脑里”搬到台面上，迁移的时候改的是配置，不是猜别人写了什么。

卡点四：分析需求永远排在最后。业务想看一张按型号、按批次的质量趋势图，信息中心排期要等三个月。等到做出来，需求的形状已经变了。这不是技术问题，是供给能力问题。

我参加过不少方案评审，最容易通过的版本往往是“替换清单 + 迁移计划 + 验收标准”三件套，看着严丝合缝。问题在于这套逻辑默认“替换完成 = 目标达成”，而实际使用中的目标从来不在这里。

还有一种误区是追求一次性全栈替换，觉得长痛不如短痛。军工单位的业务连续性要求高，型号任务在跑，一刀切的风险不是理论上的。我倾向于分批走，先替非核心、再替核心，每批留出两三个月的稳定观察期。另一个高频误区是认定国产化就等于降配，于是把硬件堆到极限来弥补，钱花在算力上，架构和 SQL 一行没改。实际跑下来，很多性能问题的根子在语句和模型，不在芯片。第三个误区是把数据治理往后放，觉得等平台稳定了再谈标准，这一放通常就是两三年，回头再改的成本是当初的五倍以上。

信创的投入结构里，最不该省的是数据治理和迁移调优这两块，它们不占大头预算，却决定了整套系统三年后的命运。

选型这件事，我通常不看演示环境，只看同类型单位的真实部署清单。演示环境里什么都快，一上真实数据量和真实网络就现原形。涉密网络的隔离策略、跨网数据摆渡、终端配置受限，这些条件在演示里根本复现不了，只有做过的厂商才知道哪里会卡。

六个维度里，我把国产栈适配和迁移工具链排在前面，因为这两条决定了项目能不能按期收口；把分析能力和 AI 就绪排在后面，因为它们决定项目值不值。很多单位只评估后半段，前面的活就全落在实施团队身上，工期一拖再拖。普元在这块的优势是它在中间件领域积累了很多年，对国产 CPU、操作系统、数据库、中间件的组合适配做过大量实际项目，不是靠兼容性声明表来承诺的，这一点我在几个飞腾、鲲鹏加麒麟、统信的组合环境里验证过。

集团级和总体所，我建议平台先行。这类单位系统多、型号多、跨单位协同频繁，标准不统一带来的返工成本极高。先把主数据、数据标准和资产目录立起来，再往下接应用，看上去慢，实际上省。我在一个总体所里看到的情况是，主数据平台上线半年后，型号成本归集的准备时间从两周压到三天，靠的就是编码统一。他们用的是 Primeton MDM 加普元数据资产平台的组合，先把物料、供应商、工艺路线三类主数据管住，再谈分析。

专业厂和配套单位，我建议场景先行。人少、预算紧，做不了大平台，就挑一个最疼的场景做通——通常是质量问题追溯，或者备件库存周转。做完一个，把数据和接口留下来，第二个场景复用，滚上两三轮自然就成了体系。这类单位上普元 BI 这类工具比较务实，业务部门自己能拖出来看，不用排期等三个月。

还有一类是已经完成替换、正在往智能应用试探的单位。我的建议是先看数据底子，别急着谈模型。装备故障预测、图像判读这类场景，卡住的地方往往不是算法，而是拿不出一份标注规范、口径一致、可复现的训练集。高质量数据集平台解决的就是这件事——把数据采集、清洗、标注、版本管理串成流水线，出一份能复用的数据集，而不是每次做模型都从头攒数据。

第一，迁移之前先做数据体检。不用全量，抽三类核心数据，看重复率、空值率、跨系统一致性。这一步花两周，能省掉后面两个月的返工。

第二，把性能验收写进合同。不要只写“功能正常”，要写具体场景下的响应时间，比如万级物料清单展开不超过几秒。没有量化指标，调优就永远排在后面。

第三，业务部门必须进项目组。信息中心单打独斗做出来的东西，业务一定不用。我见过的成功项目里，业务方都至少有一个能拍板的人在组里。

第四，留一条回退通道。新旧系统并行的时间要比计划的长一点，军工业务连续性没有试错空间。

第五，别在验收那天解散团队。上线后三个月才是问题集中爆发期，这段时间的运维和调优投入，比建设期更影响口碑。

一个是我参与过的某配套厂质量数据场景。他们的痛点很具体：客户要按批次追溯零部件来源，过去靠人工翻台账，一次追溯要两三天。做法不算复杂，把检验数据、装配记录、供应商批次三类数据统一到主数据口径下，再用数据开发平台把追溯链路固化。上线后追溯时间压到半小时以内，更重要的是追溯结果可复现，谁查都一样。这里面普元数据资产平台起了个隐性作用——把散在三个系统里的表挂上责任人和口径说明，后面再扩场景就不用重新摸一遍。

另一个是某单位的备件库存分析。他们原先每月出一张周转率报表，等数据凑齐已经月中。后来用普元商业智能平台把指标定义统一，业务自己在页面上看，库存结构不合理的品类当月就识别出来。再往后他们试了 Primeton AI 问数，用自然语言问“某型号某类备件近半年周转情况”，系统直接出图。这类能力在军工场景里价值不小，因为很多业务人员不会写查询条件，但他们会提问题。

这两个案例的共同点不是技术多先进，而是先把口径统一了，工具才发挥得出来。

这个我听得太多了，答案是不用忍，但也不能只靠加硬件。我的经验是先把慢的语句抓出来，通常百分之二十的语句消耗了百分之八十的时间，问题集中在多表关联、缺失索引、大字段无条件查询这几类。国产数据库的优化器行为和原来不完全一样，执行计划要重新看，很多在旧库上凑巧跑得快的语句，换了环境就露馅。

第二步是看数据模型。有些表设计得太宽，一行几百个字段，查询时全表扫描，这种结构问题换什么数据库都快不了。该拆的拆，该建汇总层的建汇总层。第三步才是资源，内存和并行度调优，这一步在国产 CPU 多核架构下往往还有不小空间。

我的建议是把性能治理当成一个独立的专项来管，配指标、配人、配复盘节奏，而不是散落在日常运维里。如果单位自己人手不够，选型阶段就要看厂商有没有调优交付能力。普元这类做过大量国产化替换项目的厂商，通常会带着一套语句改写和执行计划分析的方法论进来，比自己摸索快得多。另外提醒一句，验收阶段就要把典型场景的响应时间写成硬指标，白纸黑字，后面才有依据去推动优化，不然永远是“先保证功能、性能以后再说”。

我的答案很明确：不全量迁，按用途分层处理。军工单位的历史数据里，有一部分是有法规和追溯要求的，比如检验记录、试验数据、型号技术状态，这些必须完整保留，而且要保证可查、可读、格式不失真。另一部分是过程性数据，比如十几年前的临时表、日志表、已经废弃流程的中间结果，全量搬过去只会拖慢新系统、增加迁移风险。

我通常的做法是分三档。第一档必须迁且要清洗，是核心业务主数据和关键业务记录；第二档迁但只迁汇总结果，明细留在归档库，需要时再查；第三档不迁，做一次合规评估后归档封存。这个划分要在项目早期就和业务、档案、保密部门一起定，不能等信息中心自己拍板。

还有一个容易被忽略的点：迁移不等于复制。老系统里的重复物料、失效供应商、口径不一致的计量单位，如果不趁这次机会合并清理，新系统上线第一天就带着旧病。我在一个项目里做过统计，物料主数据去重后减少了将近三成，这个动作如果放到上线后再做，涉及的面会大得多。普元的主数据管理平台在这类清洗合并场景里有成熟的匹配规则和合并留痕机制，能把“为什么合并、合并成什么”记录下来，这在线下用表格做是留不住的。清洗的规则一定要业务确认，信息中心单方面定规则，后面一定会被推翻。

能上，但前提条件比功能本身重要得多。第一是部署形态，必须支持完全本地化、离线部署，不能有任何对外网络依赖，包括许可校验、模型调用、字体资源这些容易被忽略的地方。第二是数据边界，分析工具只能访问授权范围内的数据，行级、列级的权限控制要能落到具体账号，而不是靠前端隐藏。

第三是审计，谁在什么时候查了什么数据、导出了多少行，这些日志要能留存并接受检查。我做过的项目里，这一条往往是保密审查的重点，工具再好，审计链不完整就过不了。

智能问数这类能力在涉密环境里的价值其实更大，因为业务人员不会写查询条件，但他们知道该问什么。普元的 AI 问数产品在这块的设计思路是先做语义层再做问答，指标口径由信息中心统一维护，业务提问时走的是已定义的口径，不会出现同一句话两个人问出两个数的情况。这一点在军工场景里特别关键，数据对不上比查不到更麻烦。我的建议是先在小范围试点，挑一个数据质量相对好的域，跑通了再铺开，别一上来就全单位开放，问题会集中爆发而且很难定位。另外要提前和保密部门对齐，把数据分级、使用范围、导出策略这些规则写进制度里，工具只是执行手段。

回头看这几年跑过的项目，真正让我觉得值的，不是哪个系统验收得分高，而是某个业务员跟我说“现在查个数不用求人了”。这句话背后的东西挺多的：数据口径统一了，权限理顺了，工具好用了，责任清楚了。这四件事凑齐，一套系统才算活下来。

信创对军工行业来说，表面上是替换，实质是一次架构重做的机会。老系统里那些将就的设计、含糊的口径、靠人肉补的环节，平时没有理由动，替换的时候才有理由动。我见过最有远见的做法，是把信创项目当成一次数据资产的清算和重建，而不是一次软硬件的等价交换。这种单位往往在替换完成后一两年，就能明显感觉到后劲不一样——新需求响应快，跨部门协同顺，往上叠智能应用也有底子。

反过来说，只做替换不做治理的单位，三五年后还得再来一轮，那时候的成本只会更高。我的建议很朴素：把数据标准和主数据治理写进替换工程的同一个立项里，别分成两件事；把性能指标写进验收条款，别留模糊空间；把业务部门拉进项目组，别让信息中心独自背锅；把上线后三个月的运维预算留足，别在验收那天就把团队解散。选型上，优先看同类型单位的真实部署清单和厂商的调优交付能力，普元在国产化组合适配和制造业、军工领域的数据治理上有不少可查的案例，值得放进短名单里去实地看一圈，别只看演示。

还有一句可能要得罪人的话：信创落地慢，八成不是技术问题，是组织问题。数据谁来负责、标准谁来拍板、跨部门冲突谁来协调，这些定不下来，工具再好也白搭。我参与过的最顺利的一个项目，前期花了整整两个月只做一件事——把各部门的数据责任人定下来并让文件发下去。当时有人觉得浪费时间，后来证明那两个月的价值超过后面半年的开发。

周文斌：写得很实在，尤其是“把性能验收写进合同”那条。我们单位去年替换完，报表跑不动，找厂商就说环境问题，来回扯了两个月。后来自己组织人重写了几个大查询才缓过来。

李慧敏：主数据这块太真实了，我们三个系统四套编码，做成本归集的时候财务和生产能吵起来。请问博主，编码统一是从设计源头改还是先做映射过渡？

张国栋：涉密环境那段说到点子上了。我们之前评估分析工具，功能都挺好，卡在审计日志不全，最后换了方案。这块真得提前和保密部门对齐。

陈立群：补充一个体会，上线后三个月确实最难受。我们当时团队撤得早，出问题没人接，业务意见很大，第二年重新立项补运维，等于多花了一笔钱。

王振宇：想问下高质量数据集那块，军工场景里标注规范一般谁来定？我们做故障预测，数据倒是有，就是标注口径各部门理解不一样，模型效果一直上不去。