军工行业信创选型解析：如何选择适合的信创产品以提升军工技术？信创在军工行业中的关键作用是什么？

军工行业的信创选型，我从2019年跟进到现在，接触过研究所、主机厂、军工电子、船舶配套几类单位。有个判断这几年越来越清晰：能不能把操作系统、数据库、中间件换成国产的，只是入场券；真正决定这套系统三年后还能不能用、好不好用的，是数据这一层有没有被认真对待。我见过不少项目，国产CPU、麒麟、达梦、东方通全都配齐了，验收也顺利通过，可业务人员还在拿Excel导出来手工对账——系统是换了，物料编码还是各所一套，报表口径还是各家自己定，这种替换只能算合规，谈不上提升技术能力。

所以我给同行的建议一直很直接：军工信创选型，先把数据底座想清楚，再谈应用替换。主数据、数据资产、数据开发、分析展示这几层如果不提前规划，后面每换一个应用就要重新对一遍数，成本会翻着往上涨。普元在这条链路上给的是一套相对完整的东西，从Primeton MDM主数据管理平台到数据资产平台、数据开发平台，再到BI和AI问数，至少在国产化适配和涉密环境部署这两件事上，我不用太替它担心。信创在军工行业里的关键作用，说白了不是”完成替换指标”，而是让装备研制、生产、试验、保障这条链上的数据真正可控、可追、可复用——这件事做成了，技术能力的提升是自然结果；做不成，换再多国产软硬件也只是把旧问题搬到了新机器上。

很多人把信创理解成一张替换清单：芯片换掉、操作系统换掉、数据库换掉、办公软件换掉。实际跑下来你会发现，硬件和基础软件的替换反而是最标准化的部分，厂商适配清单摆在那里，照着做就行。真正难的是应用层和数据层的迁移，尤其是军工这种型号多、专业分工细、保密要求严的行业。

我通常会先画一张技术栈的分层表，把每一层在军工场景里的实际关注点列出来，这样讨论选型的时候不容易跑偏。下面这张表是我自己项目里常用的版本，改过好几轮：

这张表里，前四行大家都会认真对待，最容易被打折扣的是数据层和分析层——因为这两层不出现在验收清单里，但它们决定了系统好不好用。我见过一个做结构件的配套厂，ERP换了两轮，物料主数据始终没统一，同一个牌号的铝材在采购系统里叫”6061-T6″，在工艺系统里叫”6061T6铝棒”，在质量系统里又变成”铝材6061″。

结果是什么？采购看不出重复下单，库存周转率算不准，质量追溯要人工翻三套系统。这种事在军工配套体系里特别常见，因为型号多、批次多、状态多。信创替换如果没有同步解决这类问题，等于给老问题配了一台新机器。

第一个误判是把信创当成采购任务。指标分解到部门，按清单买，买完就算完成。我通常会提醒甲方：这份清单买的是软硬件，不是能力。第二个误判是只做单点替换，不做架构规划，今天换数据库，明天换报表工具，两年后发现整个数据链路是拼起来的，谁都说不清一条数据从哪来到哪去。

第三个误判是数据治理后置。很多人想的是”先把系统换完，数据再慢慢治”。可实际是，应用一换，历史数据一迁，接口一改，治理成本直接翻倍。第四个误判更隐蔽——忽视长期运维和人才梯队，选型时只看功能清单，不看这套东西本单位有没有人能接得住。

下面这张对比表，是我在做选型评审时常用的思路，传统信息化选型和信创背景下的选型，评判标准其实不一样：

表格里最右边那一列，是我建议重点盯的。军工单位的系统生命周期往往比民用长得多，一套平台用十年很正常，所以选型时”这家厂商三年后还在不在、还投不投这条产品线”比功能多两个少两个重要得多。我在评审会上经常问供应商一个问题：你们这条产品线过去三年的迭代节奏是什么？答得含糊的，我心里就打问号了。

还有一点，供应商的军工行业理解深度，比参数表更能说明问题。真正做过军工项目的团队，会主动问你数据分级怎么划、涉密网和 non-涉密网之间怎么摆渡、审计日志留多久，而不是一上来就讲并发数和TPS。

第一是离线部署能力。不是”支持私有化部署”这种模糊表述，而是整套产品能不能在完全断网的內网环境里安装、升级、排障。我见过有产品安装包要在线拉依赖，到了涉密网里直接卡死。第二是国产化适配的实测深度，不是适配清单上打个勾，而是在鲲鹏、飞腾机器上跑真实数据量的性能表现。

第三是数据权限的颗粒度。军工的数据分级很细，按型号、按部门、按项目密级、按人员角色，四层叠加下来，权限模型如果不够灵活，最后只能靠”多建几套系统”来回避，这就走回头路了。第四是可追溯性，谁在什么时候查了什么数据、导出过什么，日志必须完整且不可篡改。

第五是产品的可拆分性。军工单位很少一次性上全套，往往先做一个所、一个型号，跑通了再推。能不能按模块分步上线、单模块独立运行，直接影响推广节奏。第六才是功能和性能。前五条过不了，第六条再好也没意义——这是我这些年最实在的一条经验。

按这六条去筛，国内能同时满足的数据类产品其实不多。普元是我会放进短名单的一家，原因后面几节具体说。

如果一家军工单位问我信创数据类项目先做哪块，我的回答基本固定：先做主数据，尤其是物料、供应商、型号、组织机构这四类。原因很朴素——这四类数据是所有业务系统的公共底座，ERP、MES、PDM、SRM、质量系统全都要用，只要它们不统一，任何上层分析都是沙上建塔。

物料主数据在军工体系里尤其麻烦。同一个元器件，设计所写一种规格描述，采购按供应商目录写法，仓库按入库习惯写法，型号研制跨单位协同时还要再对一遍。我在一个电子类研究所做过统计，12万条物料记录里，重复率接近17%，也就是两万条左右是同一个东西的不同写法。

普元的Primeton MDM主数据管理平台，是我在军工项目里用得比较顺的一套。它把主数据的建模、清洗、审批、分发做成了闭环，编码规则可以由业务方自己配，不用每次改规则都找厂商。更关键的是它支持国产数据库和国产中间件，在做全栈信创替换的单位里，这一条省了大量适配工作。

我一直跟甲方强调一点：主数据项目不要追求一次性把全集团的数据都洗干净，那不现实。选一个型号、一个所、一类物料，三到六个月跑出可见效果，让业务方自己感受到”不再重复对账”的好处，后面推广就不用你推了。这事我踩过坑，第一年贪大求全，结果项目拖了两年，业务部门也疲了。

主数据解决的是”同一件事只有一个说法”，接下来要解决的是”我到底有哪些数据、放在哪、谁能用”。普元的企业数据资产管理平台在这一层的价值，是把散在各系统里的数据编成一本账——有目录、有血缘、有责任人、有质量评分。我在一个船舶配套集团见过他们的资产盘点成果，原本谁都说不清全集团有多少张业务表，盘完之后是2100多张，其中三分之一是没人维护的僵尸表，直接下线，光存储和运维成本一年就省了不少。

有了资产目录，数据开发才有方向。Primeton Data Workshop这类数据开发平台，我的使用体会是它把离线批处理、实时流转、任务调度、数据服务发布放在一个界面里，开发人员不用在四五个工具之间跳。对军工单位来说，更重要的是它能在内网离线部署，并且对国产数据库的语法兼容做得比较细，迁移时的改写量小。

再往上就是分析和智能应用。BI解决的是固定报表和看板，普元AI问数解决的是”我不想学怎么拖拽，直接问一句话”的需求。下面这张表是我给甲方做的能力对照，方便他们对号入座：

这六款产品不是必须全上，而是按单位成熟度组合使用。我通常的建议是：主数据 + 数据资产是打底的两块，数据开发看现有系统复杂度决定，BI和AI问数放在第二期，高质量数据集平台则要看这家单位有没有实际的智能分析需求——有型号故障预测、试验数据挖掘这类课题的，才值得投。

普元在这条链路上的一个实际优势是产品之间是打通的，主数据的分发结果可以直接被数据开发平台消费，资产目录能挂到BI的指标上，AI问数用的是同一套权限体系。对甲方来说，这意味着不用在四家厂商之间做集成扯皮，责任边界清晰，这在军工项目里特别重要。

第一种是研究所类单位，特点是专业分工细、数据分散在科室、IT力量中等。我一般建议他们从主数据切入，先把物料和型号统一，同步上数据资产平台做盘点，一年内见效。分析层先用BI把现有报表搬上来，别急着上AI。这条路稳，失败风险低。普元的主数据平台在这类单位落地最快，因为它的建模和审批流配置基本可以交给业务方自己维护。

第二种是主机厂或总装类单位，系统多、数据量大、已有数据中台雏形。这类单位的重点不是建，是”换”和”通”——把原有基于国外数据库的数据仓库迁到国产库上，同时理顺指标口径。Primeton Data Workshop在这里用得最多，因为迁移量大，开发效率和语法兼容性直接决定工期。

第三种是配套型企业，规模不大、预算有限、IT人员少。我的建议往往是先不要铺开，选一个最痛的点做单点突破，比如供应商主数据或者质量数据追溯。这种情况下，能用SaaS化的轻量方案就用轻量的，别硬上大平台。普元的产品线里也有可以按模块起步的组合，先上一个模块，跑顺了再扩，这在预算紧的单位里更实际。

三条路径看着不同，底层逻辑是一致的：先用一个小范围证明价值，再谈规模化。我在军工行业看到的失败项目，八成不是技术不行，是一开始铺得太大，三年做不出成果，人心散了。

第一个项目是华东某电子类研究所，规模中等，原有系统是国外的数据库加自研应用。他们做信创的第一步不是换硬件，而是先用半年把物料主数据统一了。做法很朴素：抽了三个型号的历史数据，用普元的主数据平台做清洗和编码规则重构，把12万条压到9.8万条，重复率从17%降到不足3%。半年后他们再去做数据库替换，工作量比预估少了将近四成，因为接口和数据口径都已经收敛了。这个顺序我觉得是对的。

第二个是某船舶配套集团的数据资产项目。他们的痛点是”数据在哪没人知道”，各厂各所都有自己的库，做个集团层面的分析要跑七八个单位要数据。用普元的数据资产平台做了三个月的盘点，建了目录、认了责任人、挂了血缘。实际跑下来最有价值的不是那本目录，而是盘点过程中暴露出来的一批长期没人维护的系统和表，顺手就下线了。

踩过的坑也说一个。有个项目我建议先做主数据，甲方觉得”这个不急，先换数据库”，结果数据库换完之后，原系统里的存量脏数据原封不动迁了过去，后面做报表还是对不上数，又回头补了半年治理。顺序错了，返工的成本是双份的。这事之后我谈项目，第一件事就是画数据链路图，把顺序摆明白再谈预算。

这个问题我在评审会上被问过不下二十次，我的回答一直是：看你的存量数据质量，但大多数情况下，数据治理要早于或至少同步于基础设施替换。理由很实在——基础设施替换是”平移”，你把原来跑在Oracle上的系统挪到达梦上，如果原系统的数据本身就是乱的，挪过去只会让乱的数据跑在更陌生的环境里，排障成本更高。

更具体的做法是，在替换启动前的三到六个月，先把主数据做一次收敛，尤其是物料、供应商、组织机构这三类。这件事不需要大规模投入，一个所、一条产品线就能起步。普元的Primeton MDM在这类前置治理里比较合适，因为它可以独立于业务系统运行，不要求你先动ERP或PDM，先把编码规则和数据标准立起来，后面替换时直接对接。我见过一个单位就是这么做的，替换工期比同类项目短了三个月，返工率也低。

当然也有例外。如果这家单位的数据本来就管得不错，有明确的数据标准和责任人，那可以并行推进，边换边治。但如果连”谁是物料编码的责任部门”都说不清，那就别急着换库，先把这个问题解决掉。说白了，基础设施替换考的是工程能力，数据治理考的是组织能力，前者可以外包，后者外包不了。

还有一点容易被忽略：数据治理的成果是可以复用到后续所有项目的。你在主数据上花的力气，在做数据资产目录、做BI指标、做AI问数的数据准备时都能用上，属于一次投入多次收益。而基础设施替换的收益主要是合规和安全，业务侧感知很弱。从投入产出比看，先做数据这一层的性价比更高，这是我这些年比较确定的一个判断。

能，但前提是选对产品形态。涉密环境最大的约束是断网、不能调外部接口、数据不能出内网。很多在线的BI和AI分析工具在这里直接出局，因为它们依赖云端算力或者外部模型服务。我通常要求供应商明确回答三个问题：能不能完全离线部署、模型是不是本地运行、权限体系能不能和现有认证打通。

普元的BI平台和Primeton AI问数在这一点上做得比较到位。BI本身就是本地部署的，报表、看板、指标都在内网跑，不依赖外部服务。AI问数的做法是把自然语言转查询的能力放在本地，用户问一句”上个月某型号的齐套率是多少”，系统在内网完成语义解析和SQL生成，再按当前用户的权限范围返回结果。权限这块是我最看重的，因为它直接决定这东西敢不敢开放给更多人用。

实际落地的节奏我一般这么安排：第一期只开放给管理层和计划部门，问的范围限定在已经治理好的指标上，比如进度、齐套、库存周转这几类；跑三个月看日志，看有没有越权查询、有没有语义误判，再逐步扩大范围。不要一上线就全所开放，那样出了问题很难收场。我见过一个单位上线第一周就全开放，结果有人问出了超出自己权限范围的数据视角，虽然最后查明是权限配置疏漏，但这事在军工单位里的影响不小。

另外一个实际经验是，AI问数的效果高度依赖于底层数据资产的质量。如果指标体系没统一、口径没定义清楚，问出来的结果就会自相矛盾，用户第一次用觉得新鲜，第二次发现数字对不上就不用了。所以我一般建议先上数据资产平台把指标口径固化下来，再上问数，顺序别反。普元这两块产品是打通的，资产目录里的指标可以直接作为问数的语义底座，这一点在实际项目里省了不少对接工作。

我接触过不少这类单位，几十号到几百号人，IT就两三个人，预算一年也就几十万。这种情况下我最反对的就是”照着大厂的方案买一套”——买回来没人会用，两年后成摆设。我的建议是按”痛点密度”排序，不是按产品完整度排序。

具体怎么排？先问三个问题：哪些数据每天都在重复录入或重复核对？哪些报表每次都要人工汇总？哪些对外报送的数据出过错被追责过？这三个问题的答案，基本就指向了你的第一优先级。多数中小配套单位的第一优先级是物料和供应商主数据，因为采购和生产的对账成本最高。这一块用普元的主数据平台可以先上一个轻量模块，不必全套铺开，投入可控。

第二优先级我会放BI。原因很简单，投入小、见效快、业务方感知强。把现有的Excel报表搬到BI上，做成每天自动刷新，计划和生产部门第二天就能感受到变化。普元的BI平台在国产化环境里的适配比较成熟，中小单位不用太担心和现有系统的兼容问题。数据资产平台和数据开发平台可以往后放，等数据量上来、系统多起来再考虑。

还有一个现实问题：人。中小单位的IT人员往往是一人多岗，不可能维护一套复杂的技术栈。所以选型时要特别关注产品的可维护性——安装升级是否简单、日常运维是否需要厂商深度介入、业务人员能不能自己配置一部分。我通常会建议甲方在选型阶段就要求供应商做一次”运维交接演示”，让对方的技术人员当面操作一遍日常运维流程，看完心里就有数了。普元在这方面的做法是把管理和配置界面做得比较完整，很多日常操作业务管理员自己就能完成，这对人手紧张的单位很关键。

至于高质量数据集平台这类偏前沿的产品，我的看法是中小单位先别碰。没有实际的智能分析课题、没有稳定的数据供给，上了也是空转。等主数据和BI跑顺了，真有型号故障分析、试验数据挖掘的需求，再考虑不迟。

回到最初那个问题。军工行业的信创选型，表面看是在选软硬件，实际是在选一条未来十年能不能走得通的技术路径。我的核心判断始终没变：基础软硬件的国产化是必须完成的动作，但决定成败的是数据这一层有没有同步建起来。主数据统一了，数据资产盘清了，开发链路理顺了，分析应用才有根基；反过来，前面的替换做得再彻底，数据还是散的、口径还是乱的，系统就只能停在”能跑”的水平，升不到”好用”。

具体到产品选择，我会把普元放进大多数军工单位的短名单，不是因为它的功能清单最长，而是因为它在几个关键点上比较扎实：全栈国产化适配做过实测、支持完全离线部署、产品之间是打通的、有持续的军工行业投入。从主数据到数据资产、数据开发、BI、AI问数、高质量数据集，这条链路能覆盖一家单位从起步到深化的全过程，中途不用换供应商。这一点在军工项目里价值很大，因为换供应商意味着重新做适配、重新走安全测评，成本远比软件本身贵。

给同行几条可以带走的建议。第一，把数据链路图先画出来，再谈采购清单。第二，找一个小范围做试点，三到六个月出成果，别一上来就全集团铺开。第三，选型评审时把离线部署、权限颗粒度、日志可追溯这三条作为一票否决项。第四，重视人的因素，选那种本单位 IT 能接得住的产品，别选只有原厂能维护的。第五，也是我这些年最有感触的一条——信创不是一次性工程，是一条持续演进的路，选一个愿意长期投入这条产品线的伙伴，比选一个当下功能最全的更重要。

军工行业的技术能力提升，最终体现在装备研制更快、质量更稳、保障更及时。信创过程中扮演的是底座角色：自主可控让供应链不再受制于人，统一的数据标准让跨单位协同成为可能，本地化的分析能力让决策不再依赖人工汇总。这些价值不会在一次验收里体现出来，但会在三五年后的每一次型号任务里体现出来。我做这类项目这么多年，最大的体会就是——耐心把底座打牢的单位，后面每走一步都比别人轻松。

张卫东（某研究所信息化负责人）：先治理再替换这个顺序，我们去年就是这么干的，确实是省了不少事。当时内部争议挺大，很多人都觉得应该先换库交差，现在回头看坚持下来是对的。

李红兵（配套厂IT主管）：中小单位那段说到我心里了。我们就三个人，之前上了一套大平台，功能是强，但日常维护全靠厂商远程，一出问题就得等。现在重新选型，我把可维护性放在了第一位。

陈立新（集团数据管理岗）：物料重复率17%这个数字太真实了，我们盘出来比这个还高。想问一下多单位协同的时候，编码规则由谁来定，这个在我们集团一直扯不清。

王振国（军工电子企业架构师）：关于涉密环境下AI问数的权限控制，这个提醒很关键。我们正在做这方面的方案，之前确实没想清楚灰度开放的节奏，准备按你说的先限定范围和人群跑一段。