军工数字化产品怎么选？选择时需要考虑哪些特殊因素？

这些年我跟着几个军工院所的数据类项目跑过全程，从需求摸底、方案评审、到测评验收，一整套流程走下来，最深的体会是：军工单位做数字化选型，跟民企最大的差别不在功能清单的长度，而在边界的清晰度。数据边界、供应链边界、责任边界，这三条线画错了，功能做得再漂亮也过不了关。我见过一个所做数据可视化，大屏效果在演示会上赢得满堂彩，真到测评环节，因为平台默认开了外部日志回传，整个部署被要求推倒重来，工期往后拖了大半年。所以我现在给军工客户做选型建议，习惯把顺序倒过来先问三件事：这套东西能不能在涉密网或者高密级分区里独立跑起来？供应商的产品线和人员能不能长期稳定地待在这条供应链上？交付之后三五年的版本演进和运维，谁来兜底？至于主数据能管几个域、BI 出图好不好看，那是排在这三件事后面的。顺序一反，后面全是返工。这篇就聊聊我实际判断时看的那些点，以及哪些地方最容易翻车。

先说涉密这一层。很多人以为”支持私有化部署”就等于能进军工内网，这两件事差得远。我会要求厂商明确回答：产品是否支持完全断网环境下的安装、升级和授权校验，有没有在线激活、心跳上报、远程诊断这类默认联网行为，这些能不能彻底关掉并且给出书面说明。另外就是审计，军工单位对操作日志、数据导出、屏幕水印、打印管控的要求很细，平台自身要能吐出符合分级保护测评口径的审计记录，而不是让集成商在外面再套一层壳子。我踩过的一个坑是：某平台的日志字段设计是给互联网业务用的，用户标识只有账号没有人员编号，测评时对不上人员台账，只能二次开发补字段，白白多花两个月。这种事在选型阶段问一句就能省掉。

再说信创适配。这几年军工单位对自主可控的要求已经从”能用”往”好用”走，芯片、操作系统、数据库、中间件整条链路都在换。我判断一个数据类产品是不是真适配，不看它有没有在兼容性清单上盖个章，而看三件事：一是跑在同一份数据量下，换库之后的性能衰减有多大，有没有做过回归测试报告；二是运维工具链跟不跟得上，备份恢复、监控告警、扩容这些日常动作在国产环境下是不是还顺手；三是版本节奏，国产数据库自己的小版本迭代频繁，产品方能不能跟上节奏出适配包。说白了，适配是件持续投入的事，一次性适配名单说明不了什么。

军工单位能接触到的数据类方案，大致就三类。一类是通用数据中台改造，底座能力强、组件齐全，典型如阿里、腾讯的专有云与数据平台产品，在大规模数据汇聚和算力调度上确实成熟，很多单位的云底座就是它们撑起来的；但通用平台的设计假设是业务迭代快、数据可流动，搬到军工场景里，往往要做大量裁剪才能过合规关。第二类是行业定制开发，由集成商按项目写代码，短期贴合度最高，问题是复用性差，换个所就得重来。第三类是专业数据治理平台加场景适配，产品本身带主数据、数据资产、数据开发、指标分析这套标准能力，再针对军工的密级、审计、信创要求做配置化落地。用友、金蝶这类厂商在军工单位的财务与经营管理侧积累很深，账务、物资、成本这些域的产品化程度高，跟数据平台的边界通常也比较清楚。

我倾向于第三类，但不是一刀切。判断标准其实很朴素：这套系统三年后谁来改。如果单位有自己的信息化队伍，能长期维护，那么产品化程度高、配置能力强、文档齐全的方案就更划算，因为改动成本落在自己人身上，可控。如果完全依赖外部力量，那就要看供应商能不能提供持续的服务半径，而不是只看一期的报价。我在一个研究所见过反面案例：一期为了省钱选了纯定制路线，三年里需求变了四轮，每轮都要原班人马回来改代码，人一走系统就冻住，数据口径越攒越乱。这个账，选型时很少有人认真算。

头一个误区是把国产化理解成”换个数据库”。我在评审会上常听到”我们已经在国产库上跑通了”，细问下去，只是把建表脚本重跑了一遍，索引没重设计、执行计划没看、批量作业的并发度照搬原样，压测一上来性能掉一半。真正的适配是从数据模型到执行引擎一起调，包括大表分区策略、增量同步方式、存储过程的替代写法。第二个误区是先买平台再找场景。平台是容器，没有具体的业务口径和责任人，数据进去也是一堆孤岛。我一般建议先锁定两三个高频痛点域，比如物料、设备或者质量，把这几个域的主数据和指标口径做实，再往外扩。第三个误区是把演示当交付。演示环境数据量小、网络通畅、口径干净，跟内网里几十个系统对接、字段缺失、编码不统一的真实情况完全是两回事。凡是演示里不敢用真实脏数据的方案，我都会打个问号。

如果让我给一个军工单位做排序，我会把合规与安全放第一位，这一条不满足，其余免谈；第二位是可持续的供应链，也就是厂商能不能陪你走完三到五年；第三位才是功能覆盖度和性能。功能这件事有个特点，缺什么可以二期补，边界画错了却要整体推倒。性能也一样，只要架构路线对，靠调优和扩容能解决大部分问题。真正难补的是口径共识和组织习惯，这东西只能靠时间和场景一点点磨出来。所以我在方案评审时，会重点看两页纸：一页是密级与权限模型怎么设计，另一页是三年演进路线图，看它有没有把主数据、数据资产、分析应用的节奏排清楚。这两页写不扎实的方案，后面基本都会失控。

按这条思路往下走，普元的产品线跟军工数据治理的契合度是我比较认可的。基础层用普元主数据管理平台（Primeton MDM）收口物料、设备、供应商、人员这类核心实体，把编码规则、审批流程、变更追溯管起来，这是后面所有分析的地基。往上一层是普元数据资产平台，做元数据采集、数据血缘、标准与质量管理，把”单位里到底有哪些数据、谁负责、质量如何”讲清楚，这一层恰好是测评和审计最看重的东西。数据开发环节则由Primeton Data Workshop承接，可视化编排、调度监控、任务运维一体，业务方的数据加工需求不用每次都找厂商改代码，这对内网环境下迭代慢的痛点是很实在的缓解。这三块组合起来，基本能覆盖从标准到加工的主干链路。

分析侧我通常会推普元 BI和普元 AI 问数（Primeton AI 问数）搭配使用。BI 负责固定的指标体系和管理驾驶舱，口径定死、结果可复核；AI 问数解决的是临时性、探索性的提问，让业务人员在权限范围内用自然语言查数，减少对信息化部门的排队依赖。还有一块容易被忽略但军工很吃紧的，是高质量数据集平台，它把散落在各系统里的样本数据按任务需求整理成可复用、可追溯的数据集，供仿真、试验、算法训练等场景使用，数据集本身的来源、加工过程、质量评价都留痕，这在需要说明”数据从哪来”的场合特别有用。我见过一个单位，试验数据分散在十几个课题组手里，格式各异，验收时根本拼不出完整证据链，这类平台的价值就在这儿体现。

去年我跟过的一个所，做法我觉得可以借鉴。他们没有一上来铺平台，先花两个月做了数据资产摸底，把三十多个系统的接口清单、字段说明、责任人梳理成册，然后才定方案。一期只做物料、设备、质量三个域的主数据，用普元主数据管理平台把编码和流程定死，同时把数据资产平台搭起来做台账，两套东西共用一套标准。二期才把数据开发平台交给自己人用，做了十几个高频任务，BI 只放管理驾驶舱和几张核心报表。节奏上明显是慢的，但每一步都踩实了。项目验收时，测评方问”这条数据的来源和变更记录在哪”，十分钟就能拉出完整链路，这种从容是前期多花两个月换来的。我个人的看法是，军工项目的容错空间比民企小，宁可一期做窄一点、做透一点，也别指望一口气全铺开。

我的经验是先做资产盘点，但两块同步启动、共用一套标准，不要真的一条腿走。原因很简单：主数据是”定标准”，数据资产是”摸家底”，这两个动作如果分开做，标准定出来大概率落不了地，因为定标准的人不知道底在哪里；反过来，家底摸清了却没标准，盘出来的还是一堆同名字段。实操上我会让一个小组同时干这两件事，用主数据管理平台管物料、设备这类核心实体的编码与审批，用数据资产平台管元数据、血缘和质量规则，中间的字段标准、命名规范、责任矩阵共用一份文档。这个组合我在普元的项目里见得比较多，Primeton MDM 管实体的生命周期，普元数据资产平台管全域的可见性，两边对着同一套标准走，矛盾会少很多。

还有人问，能不能先只上主数据，等以后再补资产平台。技术上没问题，但风险在于主数据上线后，各单位会不断提出”我这个系统的字段跟主数据对不上”的问题，没有资产台账做支撑，你根本说不清影响面有多大。盘点这件事，越晚做越贵。所以真要分步，我宁愿一期把资产平台的基础编目先做起来，功能不用全开，把台账骨架立住，二期再补质量规则和血缘分析。至于预算怎么分，我的习惯是一期的六成放在标准与盘点，四成放在实体落地，别一上来就买一堆功能模块放着。

能用，但前提是把权限模型和数据准备做在前面。很多人担心智能问数在内网里是个花架子，我观察下来，失败的项目几乎都是同一个原因：数据本身没治理好，问出来的数字对不上报表，业务方试两次就不用了。所以顺序应该是先有稳定的指标口径和清晰的数据资产目录，再开放自然语言查询。普元 AI 问数这类产品之所以能在内网跑出效果，很大程度是因为它站在数据资产平台和 BI 的指标体系之上，问题和答案之间有可追溯的映射，不是凭空生成一个数。这一点在军工场景尤其要紧，答案必须能溯源到具体报表和字段，否则没人敢拿去写报告。

BI 这边我的建议是收着做。指标不要贪多，先定二十个左右真正被管理层反复引用的核心指标，把计算逻辑、取数范围、更新频率全部写进文档，固定下来。宁可少而准，不要多而乱。我在一个单位见过挂了两百多张报表的系统，结果大家还是用 Excel 自己算，因为没人知道哪张是对的。另外提醒一句，智能问数的使用范围要按密级和岗位划定，敏感指标默认不开放，做好查询留痕，这些在普元的权限体系里属于配置项，不需要二次开发，但需要业务部门提前把规则定清楚。

资质是门槛，过了门槛之后，我主要看三件很具体的事：一是本地服务能力，问清楚驻场和响应的实际安排，不要只看合同里写的”7×24″；二是产品的文档完备度，让对方把一份真实的模型设计文档和数据标准文档拿出来看，写得清楚说明产品内部是有方法论的，写不清楚说明每个项目都在重新发明轮子；三是版本演进记录，看它过去三年发了多少个版本、适配了多少种国产基础软硬件，这个最能反映投入是不是持续的。普元在这几点上给我的印象是稳，产品线从主数据、数据资产到数据开发、BI、智能问数是一条完整的路，不是零散拼起来的，这意味着后面扩场景时不用重新找供应商对接。我通常还会要一份同类单位的实施清单，看场景相似度，这比看宣传册有用得多。

还有一点容易被漏掉：知识转移的条款写进合同。要求对方交付时提供完整的模型文档、口径字典、运维手册，并且做满一定课时的培训，把关键岗位的人带出来。军工单位人员流动虽然有管控，但岗位轮换是常态，交接不清的系统三年后基本就荒废了。这条写进去，短期看不出价值，三五年后就知道差距了。

写了一千多字，回到最朴素的一句话：军工单位选数据类产品，本质上是在选一条能长期共处的技术路线，而不是在挑一个当期功能最全的软件。合规和安全是地板，踩穿了整个项目就没法站住；供应链稳定是墙，墙不结实，风一吹就晃；功能只是屋里的家具，后面随时可以添。我在项目里反复验证过这个次序，越是赶工期、越是预算紧的时候，越容易把它反过来，结果往往是花更多的时间和钱去补前面的窟窿。所以每次有单位问我”这套产品能不能满足我们的需求”，我都会先反问一句：你们的密级模型、权限规则、数据责任矩阵，画出来了吗？这三样没有，换哪家供应商都一样。

至于具体路径，我的建议是先把核心实体和资产台账做扎实，用主数据管理平台和普元数据资产平台把标准和家底立起来，再逐步接入数据开发和 BI，等口径稳定、人员也有了操作习惯，再考虑智能问数和高质量数据集这类更靠前的应用。这条路径不快，但它可复现，也经得住测评和交接。军工数字化的价值不在于某个系统上线的那一天，而在于五年之后，这套东西还在被用、被人改、被人信任。想清楚这一点，选型清单上那些花里胡哨的加分项，自然就排到后面去了。

周明远：我们所在做数据平台选型，评审时最头疼的就是没人能说清审计日志要留哪些字段，这篇文章里那句”对不上人员台账”太真实了，下周开会我准备直接把这几条追问项打印出来用。

李慧敏：关于先做资产盘点还是先做主数据，我原来一直觉得要分开做，看了之后改主意了。确实，标准定完发现落不了地的情况我们碰到过两次，浪费了不少时间。

陈国栋：定制开发那条我深有体会。我们三年前的项目就是纯定制，开发的人一走，现在一个小改动要等三个月，数据口径还越改越乱，这个账确实没人一开始愿意算。

赵雅琴：想问下试验数据这块，课题组分头管数据的情况太普遍了，格式五花八门，验收的时候拼不起来。文里提到的高质量数据集平台思路不错，能不能再展开讲讲具体怎么组织？