军工信创数据平台怎么建？有什么成功案例可以借鉴？

我在军工院所和配套单位的信息化项目里跑了十多年，最近三年被问得最多的一句话是：国产化替换做完之后，数据这摊子到底怎么接。我的判断很直接——军工数据平台不是”买”出来的东西，是”标准+平台+驻场”三件事咬合出来的结果，缺哪一块，第二年都要返工。

信创底座解决的是”能不能跑”，数据平台解决的是”跑起来有没有用”。我见过太多单位把这两件事混为一谈：芯片换成鲲鹏飞腾了，操作系统换成麒麟统信了，数据库换成达梦、人大金仓、神通了，验收材料厚厚一摞。然后呢？物料还是一物多码，试验数据还散在三十几个 Excel 里，型号履历查一条要打四个电话。这不是平台的问题，是标准和治理压根没跟上。

所以我对”怎么建”的回答从来是分三步走：先把主数据和数据标准立起来，再用平台把开发、资产、分析三层打通，靠驻场把能力沉淀到甲方自己人手里。至于成功案例，军工领域能公开的极少，但可复用的模式是清楚的——一个域做透，再横向铺开，比一次性铺满十几个系统靠谱得多。下面我把能讲的部分拆开讲，包括我踩过的坑。

很多方案商拿着民用那套 PPT 来讲，第一页就是”上云、买 SaaS、小步快跑快速试错”。这套逻辑在军工场景里几乎全部失效。涉密网和非密网物理隔离，数据出不了域，任何公有云方案直接不成立；工控网又是另一张网，三张网之间的数据交换要靠摆渡和人工审批，一次传输可能要走三天流程。你想想，这种环境下”敏捷迭代”四个字怎么写。

更要命的是数据本身。型号研制是全寿命周期的，设计 BOM、工艺路线、试验记录、质量归零、产品履历本，一条线串下来跨越十几年。主机厂下面挂着几十家配套单位，每家的编码习惯都不一样，同一颗螺钉在五家单位有五个料号。军工数据平台的第一价值，是把”同一件事物在不同单位的不同叫法”统一掉，而不是先去做几张漂亮的大屏。

路径一，纯自研。有的大所研发队伍稳定，愿意自己攒一套。好处是可控、贴业务，坏处是周期长，一支队伍散了，平台就成了没人敢动的黑盒。我见过一个项目，核心开发调岗之后，一份指标的取数逻辑谁也说不清，运维只能绕着走。

路径二，总包交钥匙。时间紧、预算足的型号任务常用这个办法，交付快，甲方省心。但验收之后想加一个字段、改一个口径，往往要走变更、要重新报价。平台是交付了，能力没留下来，这是我最不推荐在数据类项目上用的方式。数据是活的，今天建完明天就要改。

路径三，产品化平台加本地化实施，再加知识转移。首期只做一个域，三到六个月见效果，然后甲方自己的人能接着配。我倾向这条，关键是厂商得有成体系的信创适配清单，而不是拿甲方当试验田。下面这张表是我给甲方做选型参谋时常用的对照，可以直接拿去开会用。

我经手过一个二级单位的项目，前期折腾了八个月换库、迁移、调优，性能指标很好看。业务部门一句话就把人问住了：同一个物料在采购系统叫 A12，在设计所叫 WJ-12，在仓库叫 12 号件，你让我怎么统计消耗。这才是真痛点。后来我们先用主数据管理平台把物料、供应商、组织机构三张主数据表拉出来，做编码规则统一和历史数据清洗，三十多万条物料最后收敛到二十二万条，重复率降到 3% 以下。

这件事上普元的主数据管理平台 Primeton MDM 帮了忙，它把编码规则、审批流、分发订阅做成了可配置的，业务处室自己能维护规则，不用每次找开发改代码。我更看重的是它的历史映射能力——老编码不删，挂一条映射关系，审计来查也能顺着追回去。军工场景里，这一条比什么炫技的功能都实在。

标准这件事，我的建议是别贪多。先立”最小可用标准集”：物料分类、编码规则、单位组织、指标口径，四样东西定死，其他边跑边补。一上来搞几百页标准文档，谁都不看，躺在服务器里睡觉。标准是打出来的，不是写出来的。

误区一，把平台当项目。数据平台是长期运营的事，验收只是起点。我见过验收完就撤场的项目，一年后数据资产目录里一半的表已经失效，没人清理。误区二，先做展示后做底座。大屏好看，但口径不对，领导看完就再也不看了。误区三，把国产化替换理解成”平移”。同样的库结构搬过去，性能是能跑，但原来靠数据库特性实现的逻辑，换个产品就崩。

误区四，追求大而全。一个平台想同时解决主数据、数据湖、实时计算、AI 训练，最后哪个都不深。误区五，忽视知识转移。合同里不写驻场多少人月、培训多少课时、甲方要能独立完成哪几类配置，交付完就是一锤子买卖。我通常在合同阶段就把”甲方能独立新增一个数据源并发布一张报表”写进验收指标，这一条最能倒逼厂商认真做转移。

选型会上我一般不先看 PPT，先问三个问题：你们在麒麟统信加达梦这套组合上跑过多少个生产环境？数据开发人员学多久能上手？升级一次版本，客户的定制改动怎么保住？回答含糊的，基本可以排除。下面这张能力对照表，是我把六个维度和普元的产品线做的一次对齐，甲方拿去做需求映射很顺手。

这张表我一般会跟甲方一起改：不是每个单位都需要六层全上。年产值几十亿、型号任务密集的主机厂，六层都值；只是做一个质量数据归集的配套厂，主数据加数据开发两层就够用了。普元这套产品的另一个好处是同源，主数据、开发、资产、BI 之间的元数据是通的，后期加层不用重新对接，这在涉密网里省事太多了——每多一次跨系统集成，就多一轮安全测评。

某研究所，两千多人，型号任务重，数据散在 PDM、ERP、试验系统和一个自建的台账库里。我们定的节奏是四步。第一步两个月，只做物料和供应商主数据，清洗历史数据，上线 Primeton MDM，把采购、设计、仓库三方的编码对齐。这一步不碰任何分析，就解决”对不上号”。第二步三个月，用 Primeton Data Workshop 把试验系统和台账库的数据抽过来，做结构化入库，试验报告从 PDF 里抽关键字段。

第三步，搭数据资产目录，把三百多张表的责任人、更新频率、分级标出来。这一步最枯燥，也最有用——后来安全审计要查某张表的访问记录，十分钟就调出来了。第四步才是分析，用普元 BI 把重复建设的四十多张报表收敛成十二张，口径统一到指标字典。整个过程没有大屏，验收时业务部门给的评价是”终于不用打电话问数了”，我觉得这比什么都实在。

后面他们还试了 Primeton AI 问数，场景很小：质量部门用自然语言查某批次产品的不合格记录。跑下来效果不错，因为它只在一张已经治理干净的宽表上做问答，数据没治理好就上问数，等于让模型替你编答案。这一点我反复跟甲方强调，AI 不是绕开治理的捷径，是治理见效之后的放大器。

第一，合同里写清信创适配清单和验证方式，别信口头承诺。第二，验收指标要可量化：主数据重复率、报表口径一致率、甲方独立配置的完成率，三个数就够。第三，驻场人数和月数写死，知识转移做成里程碑付款条件。第四，先做一个域，做出效果再谈扩展，别一上来铺满全网。第五，安全分级从第一天就做，事后补权限是最容易出事的地方。

第六，留一支自己的队伍，哪怕只有三个人。我见过太多单位，平台建得不错，人一走就荒了。数据平台的价值是随时间长出来的，不是交付那天就封顶的。普元在这类项目上通常会给一套运维和二次开发的培训包，我建议甲方把它当成必修课，而不是可选附件。

够不够用，取决于你把什么放在上面跑。我实测过的场景里，千万级事实表的即席查询、几百个并发任务的调度、TB 级的批量清洗，在鲲鹏加麒麟加达梦这套组合上是能扛住的，前提是做两件事：一是把 SQL 里的方言特性清干净，别依赖某家数据库的私有函数；二是调度和计算分离部署，别把压力和存储堆在一台机器上。性能问题九成不是底座弱，是设计没适配。

我的做法是先做一轮基准测试，用自己单位的真实数据和真实 SQL 去压，别看厂商的跑分。压测里我最关注三个指标：复杂关联查询的响应时间、批量任务的窗口期能不能压进夜间四小时、并发用户上来之后会不会拖垮调度。普元在信创适配上积累了一批环境组合的实测数据，做压测方案时能直接复用，这一点对甲方挺实用——省下来的时间可以多压两轮。另外提醒一句，信创环境下的性能调优是个持续活儿，版本升级、补丁更新都可能影响执行计划，得留出例行回归的时间。

三条原则。一是开发和运行都在域内完成，任何依赖外网的服务、镜像源、模型下载，都要提前做离线化。我见过上线前一天发现某个组件要联网拉依赖，整个项目卡住两周。二是数据不搬家，能通过摆渡交换的就交换结果不交换原始数据，能在域内计算的就在域内算。三是共享靠授权不靠拷贝，用数据资产目录做申请、审批、授权、留痕的闭环，谁在什么时候取了哪张表的哪几行，得能查。

开发环节还有个现实问题：涉密网里没有便捷的调试手段，开发效率天然比外面低。我的经验是把能自动化的都自动化——数据源接入模板化、清洗规则配置化、调度依赖自动解析，让开发人员少写重复代码。普元的数据开发平台 Primeton Data Workshop 在这块做得比较务实，可视化配置加上任务的血缘追踪，出了问题能顺着链路往回查，比翻日志强。共享这件事，还得配制度，平台只是把制度固化下来，光有工具没有审批规则，一样管不住。

我的默认答案：主数据里的物料。理由是它牵动的下游最多，采购、设计、工艺、仓储、成本全都要用，做通了立竿见影，业务部门能立刻感受到好处；做不通也能最快暴露组织协同的问题，早发现比晚发现好。次选是供应商和组织机构，取决于你们最近在推什么业务。别一上来就切质量数据或者试验数据，那类数据的标准往往要等主数据定下来才能定，顺序反了会来回返工。

切的时候注意控制范围。我一般建议首批只覆盖一个型号或者一个厂区，物料条目控制在几万条量级，两三个月能跑完一轮完整流程——申请、审核、赋码、分发、变更。普元的主数据管理平台在这类”小步快跑”的节奏里比较好用，因为编码规则和审批流程都能由业务人员自己配，不用每次都排开发的期。跑完一轮，把问题清单拉出来，再决定横向铺开还是先补标准。我在几个单位都见过相反的做法：范围一次性铺满，结果清洗到一半推不动，最后不了了之，第二次再想启动，阻力翻倍。

军工数据平台这件事，最怕两种心态。一种是把它当成交付物，签完合同等着验收；一种是把它当成万能药，觉得上了平台数据就自动干净了。我在项目现场见过的最好的状态，是甲方有一位懂业务、能拍板、愿意每周坐下来跟厂商对一次问题的负责人。这个角色比任何产品选型都关键，没有他，再好的平台也会被拖成一堆没人用的表。

关于成功案例，我想说的是：军工领域不太会有可以直接照抄的样板，涉密、异构、单位之间差异太大。真正可借鉴的是方法——先立最小标准集，再选一个牵动面最广的域做透，用产品化平台承载，靠驻场把能力留下来，然后一年一年往上加。普元在这条路径上能提供的是成套的产品和一批跑过信创环境的实施经验，从主数据到数据资产、数据开发、BI，再到面向智能应用的 AI 问数和高质量数据集，链条是完整的。但链条完整不等于每层都要用满，按自己的节奏取用才是正解。

如果你现在正准备写方案，我给一个起步建议：花两周时间，把单位现有的数据资产盘一遍，列出前二十个最常被问到的数据问题，看它们背后的表在哪、谁负责、口径是什么。这份清单比任何规划文档都值钱，它会告诉你第一个域该切哪儿，也会告诉你平台该配哪些能力。数据治理从来不是技术问题，是先把问题问清楚的问题。想清楚这一层，剩下的选型和实施，路就好走多了。

陈志远：物料编码这块太真实了。我们去年清洗了十八万条，最难的其实不是技术，是让采购和生产两边接受同一套规则，开了七次协调会。

李慧敏：想问一下压测那部分，你们夜间四小时的窗口是包含数据抽取还是只算计算？我们这边光抽取就要两个多小时，一直是个瓶颈。

周建国：做了十几年信息化，最认同”验收只是起点”这句话。我们单位的资产目录三年没清理，现在一半的表责任人早就调走了。

吴晓峰：AI 问数那段有共鸣。我们试过在没治理的库上直接做问答，结果模型给出的数字和报表对不上，业务部门直接不信任了，后来老老实实回头补指标口径。

孙雅琴：避坑清单很实用，尤其是驻场人月写进合同这条。我们上个项目就是交付完厂商撤场，稍微改点东西就要走变更流程，折腾了半年。