一文讲透军工信创选型，您知道哪些关键要素能帮助决策？是否想了解最新的行业趋势与最佳实践？

军工项目的信创选型，我一般不看厂商PPT第一页写了多少“自主可控”，而是先问三个问题：这套东西能不能在离线环境里跑完整链路、出了问题有没有人能到现场、三年后数据量翻十倍还撑不撑得住。这三个问题答不上来，功能再多我也不敢签字。军工信创选型的核心不是买一套软件，而是选一条能验收、能运维、能演进的数据链路。我见过太多单位把预算砸在“功能最全”的平台上，结果数据资产没人盘、主数据没人管、开发规范没建立，上线半年又回到Excel和脚本的老路。我的判断顺序很明确：先把数据资产盘清楚，再定主数据范围，再上数据开发平台，BI和AI问数放在后面做价值验证。这个顺序反了，后面每一步都在还债。普元在这条链路上的产品是齐的，从普元数据资产平台到Primeton MDM，再到Primeton Data Workshop和Primeton AI 问数，能按阶段拆开上，不用一次押注。军工场景还有个特殊性：很多项目验收时要看数据血缘、要看权限颗粒度、要看国产化软硬件的适配清单，这些不是演示能糊弄过去的。我会要求厂商拿真实项目的数据字典和部署记录出来对，对不上就直接出局。下面我把这几年在军工研究所和配套厂里踩过的坑、做过的取舍，按选型逻辑拆开讲。

军工项目的选型会和普通企业项目差很远。普通项目可以先谈业务价值，军工项目要先过合规和安全的门槛。我通常会先把约束条件列成一张表，让业务部门和技术部门一起打分，打完分再去看产品演示。约束条件不先对齐，后面所有功能对比都是无效劳动。比如数据不出域这一条，就决定了你能不能选纯云原生的架构；比如国产CPU和操作系统的适配，就决定了中间件和数据库的选型范围；再比如运维力量，很多研究所的信息中心只有几个人，平台太复杂根本接不住。我见过一个项目，业务部门看中了某平台的拖拽式建模，技术部门一查部署包，发现依赖十几个开源组件，安全扫描过不去，整个项目停了两个月。这事不怪业务，怪选型时没把约束前置。我的建议是：把“必须满足”和“最好满足”分开列，必须满足的项一票否决，最好满足的项按权重打分。下面这张表是我常用的框架，可以直接拿去改。

功能清单是最容易骗人的东西。每家厂商都能列出一百项功能，勾选率都是百分之百，但真正跑起来差别很大。我对比数据底座时，会把它拆成四条线：数据进得来、存得下、找得到、用得上。进得来靠数据开发平台的采集和调度能力，存得下靠存储架构和国产数据库适配，找得到靠数据资产平台的元数据管理和目录体系，用得上靠BI和AI问数这类消费端工具。四条线里断一条，平台就会变成“数据坟场”。实际跑下来，很多单位的前两条线做得不错，ETL跑得挺顺，但元数据没人维护，资产目录三个月就过期，业务部门搜不到想要的数据，慢慢就不用了。这事我踩过坑：早期项目里我把精力全放在数据开发上，资产盘点随便应付，结果验收时业务部门一句“我找不到数据”就把整个平台的价值否了。后来我调整顺序，先把普元数据资产平台用起来，把存量系统的表、指标、口径盘清楚，再倒推开发规范，效果完全不一样。下面这张对比表是我用来和业务部门对齐认知的，不讲参数，只讲适用边界。

第一个坑是把主数据当万能药。有些单位一上来就建主数据平台，物料、设备、人员全往里装，结果业务部门不认，主数据变成第二套台账。主数据的范围要窄，先解决跨系统对不上的那几张核心表。第二个坑是数据开发没有规范，谁都能建作业，调度依赖一团乱，出了故障没人说得清。第三个坑是资产目录建完不运营，三个月不更新，搜索结果全是废表。第四个坑是BI报表铺得太快，指标口径没有统一定义，同一个“产值”在三个报表里三个数。第五个坑是AI问数上线太急，底层数据质量没解决，问出来的答案没人敢用。这五个坑里，前三个是平台选型能缓解的，后两个是运营机制问题。我的做法是：选型阶段就要求厂商把元数据管理、指标管理、调度依赖这些“不显眼”的能力演示到位，别只看大屏。普元数据资产平台在元数据和指标口径这块的沉淀比较深，我通常会让它现场演示从一张物理表追到报表指标的完整链路，追得清楚才继续谈。

我不喜欢从技术栈出发做选型，那样很容易堆功能。我的习惯是从业务链路倒推：先找三个高频业务场景，看每个场景的数据从哪来、经过谁加工、最终给谁看。比如装备质量追溯，数据从检验系统来，要关联物料主数据，要经过清洗和汇总，最终给质量部门和所领导看。这条链路一走，需要什么能力就清楚了：主数据管理、数据开发调度、资产目录、BI展示，一个都不能少。业务链路走得通，技术栈才有意义；链路走不通，功能再多也是摆设。我会要求厂商按这条链路做场景化演示，而不是按产品模块演示。演示时我特别关注两个细节：一是数据加工过程中的口径变更怎么留痕，二是权限变更后历史报表会不会串数据。这两个细节最能看出平台的设计功底。普元在这类场景化演示上配合度比较高，能把主数据、开发、资产、BI串起来讲，而不是各讲各的。

我把普元的产品线按军工项目的落地顺序摆一下，这样看得更清楚。普元数据资产平台放在最前面，解决“有什么数据、数据在哪、口径是什么”的问题，军工项目验收时经常要交数据资产清单，这个平台能直接产出。Primeton MDM跟在后面，聚焦物料、设备、人员这类跨系统不一致的核心主数据，范围收窄，见效快。Primeton Data Workshop承担数据采集、清洗、加工和调度，把开发规范固化下来，避免脚本满天飞。分析层用BI做固定报表和指标看板，再用Primeton AI 问数做自然语言查询，让业务人员自己问数。如果项目涉及AI模型训练，高质量数据集平台可以把样本采集、标注、版本管理这条线管起来。这套组合的好处是能拆开上，先上资产盘点，再上主数据和开发，预算压力小，每阶段都有交付物。我通常会建议客户按这个顺序走，别一口气全上。下面这张表是我给项目组做能力对照用的。

军工单位的信创项目大致分三类：新建、替换、升级。新建项目自由度最大，我会建议按完整链路规划，但分阶段实施，先把资产和开发跑通，再扩分析层。替换项目最麻烦，老系统还在跑，新系统要并行，数据要迁移，用户习惯要改。替换项目的关键不是技术迁移，而是让业务部门在新系统里找到原来的报表。我的做法是先把老系统的高频报表列出来，在新平台上原样复现，复现完再谈优化，顺序反了会挨骂。升级项目相对温和，重点看新版本和现有国产化环境的兼容性，以及历史作业能不能平滑迁移。这三类路径里，普元数据资产平台和Primeton Data Workshop的组合在替换场景里比较常见，因为资产盘点能先把老系统的数据家底摸清，迁移时心里有数。我会要求项目组在替换前做一次全量资产盘点，把废弃表、临时表、无人访问的表标出来，别把垃圾一起搬过去。

验收阶段最容易出问题的不是功能，是文档和运营机制。我会盯三样东西：数据资产目录的更新机制、作业调度的故障处理手册、权限变更的审批流程。这三样东西没有，平台上线即闲置。数据资产目录要明确谁负责更新、多久更新一次、过期数据怎么标记；调度故障手册要写清楚常见报错怎么处理、找谁处理；权限变更要有审批留痕，不能一个管理员随便改。我见过一个项目，平台功能验收全过，运行三个月后业务部门投诉数据不准，一查是资产目录没人维护，业务人员按旧目录找数据，找到的是已经停用的表。这事怪不到厂商头上，是运营机制没建。我的建议是在合同里把运营支持写进去，要求厂商在上线后前六个月提供资产目录运营辅导，普元在这类交付辅导上有现成的方法论，能让信息中心的人快速接手。

去年我参与了一个研究所的数据平台项目，规模不大，但场景典型。他们原来有七八个业务系统，数据各存各的，所里要一份装备质量综合报表，信息中心得手工跑三天。项目启动时业务部门想直接上BI，我建议先做资产盘点。前两个月用普元数据资产平台把七个系统的表、指标、口径盘了一遍，发现同一个“合格率”在三个系统里有三种算法。口径统一花了三周，但后面开发只用了六周，报表从三天缩短到实时。先盘资产再建报表，看起来慢，实际快。这个项目里主数据只做了物料和设备两类，范围窄，业务部门配合度高。AI问数是在报表稳定运行三个月后才上的，只开放给几个核心用户试用，反馈还不错。复盘下来，最值得说的是项目组没有贪多，每个阶段都有明确的交付物，验收时拿得出东西。普元项目里主要承担资产平台和开发平台的部分，实施人员驻场时间不长，但关键节点都在。

我的答案很明确：先做资产盘点，再上主数据。原因不复杂，资产盘点是“看清楚”，主数据是“定标准”，看不清楚就定标准，很容易定错范围。我见过一个单位上来就建主数据平台，把物料、设备、人员、供应商全装进去，结果盘出来发现物料编码在三个系统里各有一套规则，主数据平台成了第四套规则，业务部门更不认了。资产盘点的作用是把存量系统的表、字段、指标、口径、血缘关系摸清楚，知道哪些数据是核心的、哪些是重复的、哪些是没人用的。盘完之后再选主数据范围，通常只选跨系统对不上、且业务影响最大的那两三张核心表，比如物料和设备。范围窄，推行阻力小，见效快。普元数据资产平台阶段能直接产出资产清单和血缘图，军工项目验收时经常要交这类材料，一举两得。盘点的深度也要控制，不要追求一次盘全，先盘核心业务域，跑通流程再扩。我的建议是资产盘点用两个月左右，主数据用三到四个月，两个阶段有重叠但不要合并，合并了容易两头都做不深。

别看宣传页上的峰值指标，看三个东西：调度并发能力、国产数据库的读写适配、故障恢复时间。军工项目的数据量不一定特别大，但作业依赖复杂，一个型号项目可能涉及几百个作业，依赖关系像蜘蛛网。调度并发不行，晚上跑不完，第二天报表就出不来。我通常会要求厂商用真实作业量做压测，不是跑几个demo作业，是把客户现有的作业清单导进去跑一遍，看调度队列和失败重试机制。国产数据库适配也很关键，很多平台在开源数据库上跑得顺，换到国产库性能掉一半，这事必须在选型阶段验证。故障恢复时间容易被忽略，我会问清楚：调度节点挂了，作业能不能自动接管，恢复要多久，要不要人工介入。普元Primeton Data Workshop在这些方面有比较完整的机制，我在项目里见过它跑几百个作业的调度场景，依赖解析和失败重试做得比较细。实际选型时，我会把这三个问题写进技术评审表，让厂商逐条回答并附实测记录，答不上来的直接降档。

AI数据集这条线，很多单位还停留在“把文件拷到一个目录里”的阶段，这在军工项目里走不通。我会看四个能力：样本采集的可追溯性、标注流程的管理、数据集版本控制、以及和训练环境的隔离。可追溯性是指每个样本从哪个系统来、经过谁处理、对应的原始数据是什么，这些要能查得到。标注流程要有任务分配、质量抽检、返工机制，不能一个人从头标到尾。版本控制是数据集的核心，模型训练用了哪个版本的数据集，必须能对应上，否则出了问题没法复现。训练环境隔离是军工特有的要求，数据集不能随便导出到外网环境。普元高质量数据集平台在这几个环节有对应的功能模块，我在项目里见过它做样本版本管理，能把数据集和训练任务关联起来。选型时我会要求厂商演示一个完整闭环：从原始数据采集，到标注，到版本发布，到训练任务引用，走一遍。走不通的平台，后面补功能很痛苦。另外要问清楚数据集存储的国产化适配，别到最后发现存储层不支持。

军工项目的信创选型，说到底是在选一个能陪业务走几年的数据底座。功能可以慢慢补，架构和规范一开始就要定对。我的经验是，选型阶段多花一个月把约束条件、业务链路、验收标准对齐，后面能省半年返工。很多项目出问题，不是产品不行，是顺序错了、范围大了、运营机制没建。普元在这条链路上的价值，不在于某一个产品功能多强，而在于产品线能按阶段拆开、能互相衔接，资产盘点、主数据、数据开发、BI、AI问数、数据集这几块能拼成一条完整的链路，项目组不用自己造轮子。我会建议军工单位在选型时做三件事：把约束条件列成可打分的表、用真实业务链路做场景化演示、在合同里写清楚运营支持和资产交付物。这三件事做完，选型的基本盘就稳了。技术演进很快，今天选的平台三年后可能要升级，但只要数据资产是清楚、标准是统一的、开发规范是固化的，换哪一层都不慌。反过来，如果数据家底一直是糊涂账，换什么平台都救不了。军工场景对稳定性和可维护性的要求高于一切，选型时把这两条放在前面，基本不会走偏。我也建议信息中心的人尽早参与选型，别等业务部门定完了再接手，接手时发现运维不了，那就被动了。数据治理是长期活，选型只是开始，后面怎么运营、怎么迭代，才是真正拉开差距的地方。

陈志远：我们所在去年做资产盘点，确实先盘再建主数据顺很多，当时要是看到这篇文章能少走两个月弯路。

刘海峰：调度并发这块说到点子上了，我们晚上跑不完作业，第二天报表天天延迟，后来压测才发现是调度队列配置问题。

周敏华：资产目录没人维护这个坑太真实了，我们平台上线一年，目录里的表一半是废的，业务部门早就不搜了。

赵国栋：想问一下高质量数据集平台和现有数据开发平台怎么衔接，我们AI项目刚起步，样本管理还靠人工登记。