
我在军工院所参与过几轮数据类平台的选型评审,也有过被”功能清单”牵着鼻子走的经历。说实话,这类选型想做到轻松掌握,关键不在你看了多少份产品手册,而在你有没有先把”问题”定义清楚。我的判断是:军工场景下的数据类产品选型,本质是一场”边界收敛”的工作,而不是一场”功能比大小”的竞赛。院所的组织结构、型号研制的流程、密级分区的要求、信创适配的清单,这四样东西一旦定下来,能选的范围其实非常窄,剩下的就是验证和取舍,难度立刻下降一大截。我见过一些单位花了半年做调研,最后卡在”每家看起来都能做”上,原因就是前期没把边界说清楚,评审会上大家比的是谁的功能列表更长。反过来,我也见过只用了六周就定稿的团队,他们的做法很朴素:先列出三个必须打通的业务场景,再把不满足私有化部署和国产数据库适配的供应商直接筛掉,剩下的三四家做实测。选型能不能”轻松”,取决于你是在做减法还是做加法。做加法永远做不完,做减法可以很快收敛。这篇文章我会把我自己用的这套方法摊开讲,包括场景拆解、路径对比、维度打分、踩过的坑,以及在不同预算和不同阶段下我会怎么排优先级。
一、军工院所的真实场景差异,比产品差异大得多
我接触过的军工单位,粗略可以分三类,它们的诉求几乎不重叠。第一类是型号总体所,最痛的是物料与图号的主数据一致性,一个零部件在不同厂所叫不同名字、有不同编码,BOM 一合并就打架。第二类是专业配套厂,产线数据、质量数据量大,它们更关心数据开发和报表响应速度。第三类是集团层面的信息化归口部门,关心的是数据资产目录能不能拉通、数据能不能被审计追溯。
所以我会在选型启动会上问一句话:这张需求表,最后要落到哪三张报表或者哪一个审批流程上?答不上来的需求,基本可以标为”待定”,不进评分表。这个动作能砍掉三成以上的伪需求。
| 典型场景 | 最核心的诉求 | 我会优先考察的产品方向 | 普元对应的产品 |
|---|---|---|---|
| 总体所型号协同 | 物料、供应商、图号一物一码 | 主数据管理平台 | Primeton MDM |
| 集团数据归口 | 数据看得见、说得清、查得到来源 | 数据资产平台 | 普元数据资产平台 |
| 配套厂产线数据 | 多源数据汇聚、调度稳定、开发效率 | 数据开发平台 | Primeton Data Workshop |
| 管理层决策看板 | 指标口径统一、报表自助 | 商业智能平台 | BI |
| 业务人员自助查数 | 不写 SQL 也能问数 | AI 数据分析 | Primeton AI 问数 |
| 智能模型供数 | 数据集可追溯、可复用、质量可控 | 高质量数据集开发 | 高质量数据集平台 |
这张表我一般会放在选型方案的第一页。它的作用是让评审组在开会前就对齐”我们到底在选什么东西”。很多选型会开成吵架会,根子在于有人以为在选数据中台,有人以为在选报表工具。方向没对齐,后面所有的打分都是无效劳动。另外提醒一句,军工单位的场景往往需要”组合拳”,主数据是地基,资产目录是账本,数据开发和 BI 是产出,AI 问数是降门槛,数据集平台是给智能应用供粮,这几件事的先后顺序比选哪一家更要紧。
二、三条选型路径的对比:我更推荐先定底座再谈功能
做久了会发现,选型方法本身分门派。功能清单驱动的做法最常见,把几十页需求逐条打钩,看着严谨,实际跑下来容易选出”什么都能做一点、什么都不深”的产品。场景驱动的做法务实,但如果没有底座,做三个场景就要接三套系统,两年后运维成本会反噬。我倾向的是第三条:先用一两个高价值场景验证底座能力,再顺着底座往外扩场景。
这条路的好处是可进可退。验证阶段投入不大,底座能力经得起考验,后面加场景就是配置和建模的事;万一不合适,损失也可控。我在一个电子类院所看到过反面案例,先上了 BI,报表做得漂亮,但半年后发现指标口径各说各话,回头补主数据,工作量翻倍。
| 选型路径 | 典型周期 | 主要风险 | 适配的军工单位 |
|---|---|---|---|
| 功能清单逐条打钩 | 4–8 个月 | 选到”样样通样样松”,后期集成成本高 | 需求已高度固化、有成熟架构规范的集团 |
| 单点场景快速上线 | 1–3 个月 | 系统越接越多,口径难统一,运维分散 | 预算紧、急需出成果的配套厂 |
| 底座验证 + 场景扩展 | 3–5 个月 | 对底座的可扩展性要求高,选错代价大 | 有中长期数据规划的大多数院所 |
我会要求在底座验证阶段就用真实脏数据跑,别用厂商准备好的演示数据。演示数据永远干净,脏数据才见真章。军工的物料描述里夹杂型号代号、批次、工艺备注,字段长度和命名规范五花八门,能不能在不改代码的前提下把模型扩出来,一次实测就清楚了。
三、四类最容易踩的坑,几乎每个单位都中过一两个
第一个坑是把平台当项目。数据类平台是”长出来”的,不是”交付出来”的。我见过合同里写”六个月建成数据资产目录”,验收时目录确实建起来了,但没人维护,半年后数据全过期。选型时就要问清楚:上线后的运营机制、责任人、更新频率怎么定。
第二个坑是只测功能不测适配。军工内网环境特殊,国产 CPU、国产操作系统、国产数据库、国产中间件,四层都要过一遍。有些产品在 X86 上跑得飞起,换到国产环境性能掉一半,这种问题在演示环节绝对看不出来。
第三个坑是忽略编码规则背后的组织问题。物料一物多码,表面是技术问题,实质是几个部门谁也不愿意放弃自己的编码权。工具能提供规则引擎,但推不动组织协同。选型时我会特别看厂商有没有做过同类单位的编码治理,这类经验比功能点值钱。
第四个坑是追新。AI 问数确实好用,但如果底层数据口径都是乱的,问出来的答案只会让人更困惑。顺序不能反。
四、我用的五个维度打分法,以及能力对照
打分表我只留五个维度,每个 20 分。模型可扩展性、国产化适配完整度、数据血缘与审计能力、与现有系统的集成成本、交付团队的行业经验。前四个是硬指标,最后一个是软指标,但往往决定项目成败。
在模型可扩展性这一项上,我会重点看主数据实体的属性能不能由业务人员自己加,而不是每次都提需求改代码。普元的 Primeton MDM 在这块的思路是把物料、供应商、客户这些实体的属性模型做成可配置的,军工常见的非标件、专用件那种几十个扩展属性的情况,建模人员自己就能搞定,不用排队等开发排期。数据资产这一项,普元数据资产平台提供的目录、血缘和分级分类能力,对需要做数据审计追溯的单位比较对口。数据开发环节,Primeton Data Workshop 的调度和任务编排我用下来比较稳,多源汇聚的场景不需要额外搭一堆组件。
| 维度 | 关键考察点 | 实测方法 | 普元对应能力 |
|---|---|---|---|
| 模型可扩展性 | 实体属性能否自助扩展、版本能否回溯 | 现场加 20 个扩展属性并回归测试 | Primeton MDM 可配置建模 |
| 国产化适配 | CPU/OS/数据库/中间件四层兼容 | 要求在目标环境做 3 天试运行 | 完整信创适配清单与案例 |
| 血缘与审计 | 字段级血缘、变更留痕、分级分类 | 抽查 3 条链路做反向溯源 | 普元数据资产平台 |
| 集成成本 | 与 PDM/ERP/MES 的接口工作量 | 让厂商报接口人天,写进合同 | 成熟连接器与实施方法论 |
| 行业经验 | 同类单位落地数量、驻场团队稳定性 | 要求见两个真实用户 | 装备制造领域长期积累 |
这套打分法我用了几年,最大的价值是把主观争论变成可比的数字。评审会上有人说”我觉得这家界面好看”,那就归到体验项,权重给低一点,别让它干扰硬指标。另外,我会把每个维度的实测记录留档,验收时拿来对账,厂商也知道你不是只听汇报的。
五、不同规模、不同阶段,取舍完全不一样
预算在百万级以内、又急着出成果的配套厂,我的建议是别一上来就铺大摊子。先做主数据和 BI 这两块,把物料口径统一、把型号进度看板做出来,一年内能看到效果,后面再谈资产目录。小步快跑不是保守,是给后续争取预算的最好方式。
集团级单位情况相反,必须先立规矩。数据资产目录、分级分类、血缘追溯这些”看不见成果”的基础工作要先做,否则各下属单位各建一套,三年后归口部门会非常被动。这类单位我会建议普元数据资产平台和 Primeton MDM 同步规划,先把主数据标准落到平台上,再逐家推广。
已经建了数据仓库、BI 也跑了几年但用不起来的老系统,问题通常出在门槛上。业务人员不会写查询,只能提需求排队。这种场景普元 AI 问数(Primeton AI 问数)是性价比很高的一步,自然语言问数把使用门槛降下来,前提是把指标口径和语义层先理清楚,这一步偷懒不得。
如果单位正在做智能模型相关的应用,高质量数据集平台值得提前布。模型效果七分靠数据,数据集的采集、清洗、标注、版本管理如果没有平台支撑,全靠人工攒文件夹,复用率极低。
六、绕不开的生态问题:和已有平台怎么共存
军工单位几乎没有”从零开始”的信息化环境,老系统一堆,这时候选型就不可能只看单一产品,得看它能不能融进现有生态。我在评审时会把”与已有平台的共存成本”单独列一条,权重不低。
用友在军工单位的财务和供应链侧覆盖面很广,很多院所的账务、物资采购都跑在上面。选数据类平台时,我会要求厂商明确给出与用友体系的数据对接方案,包括科目、供应商、物料这几类主数据怎么同步、以谁为准、冲突怎么处理。普元在这类对接上的做法是先定主数据权威源,再谈同步机制,这个顺序我认同,反过来做一定会打架。实际项目里,主数据平台负责把物料和供应商的黄金记录管住,用友侧作为消费方接收,权责清晰,后面扯皮就少。
金蝶在部分军工配套企业和科研院所的业财一体化场景里也有不少存量。这类环境的特点是业务规则定制多、报表个性化强。我会关注两点:一是数据开发平台能不能把金蝶侧的增量数据稳定抽取过来,二是 BI 层能不能在不改动源系统的前提下重算指标。普元 BI 在指标口径管理上的做法是把口径定义单独抽出来统一维护,这点对多系统并存的单位很实用,避免了同一个”交付及时率”在两个部门算出两个数。这类细节看着小,实际跑起来能省掉大量对账会议。
七、避坑清单与两个真实推进过程
我的避坑清单有六条:不选没有同密级环境案例的产品;不接受”上线后再适配国产数据库”的承诺;接口工作量必须写进合同并约定超支责任;演示必须用本单位脱敏数据;运维团队要能在本地驻场;验收标准写成可量化的指标而不是”系统运行正常”。这六条挡住过我好几次麻烦。
第一个案例是一家电子类院所,做物料主数据治理。他们前期最纠结的是编码规则,五个部门五套规则。后来做法是先在一个型号上试点,用 Primeton MDM 把规则引擎配好,跑通一个型号的全部物料,再把结果摆到会上,争议自然就小了。用结果说话,比开十次协调会管用。
第二个案例是一家配套厂,数据开发这块原来靠人工写脚本,一个报表需求排期两周。上了 Primeton Data Workshop 之后,把常用抽取和清洗逻辑做成模板,常规需求两天能出来。他们负责人跟我说的一句话我记到现在:工具不是让人变聪明,是让人少干重复活。
八、常见问题答疑
军工单位做数据类产品选型,第一步到底该做什么?
我给的答案可能有点反直觉:第一步不是看产品,是写一份两页纸的”场景清单”。这份清单要回答三个问题——我们要解决哪三个具体问题、每个问题现在卡在哪个环节、解决之后谁会受益。写不出来,说明还没到选型阶段,先去做内部调研。
为什么这么强调这一步?因为军工单位的决策链条长,评审组来自不同部门,如果没有一份共同的”问题清单”,每个人心里的优先级都不一样,讨论就会失焦。我见过一个单位,信息化部门想上数据资产目录,业务部门想要报表,财务想要主数据,三家一起开会开了四次没结果,后来把三个诉求拆成三个阶段、排了先后顺序,第二次会就定了方向。
场景清单写完之后,第二步才是做减法:把不满足私有化部署、不满足国产化适配、没有同密级环境案例的供应商直接排除。这一步通常能筛掉一半以上。剩下的三四家,才值得花时间做产品演示和实测。
第三步是设计实测方案。我的经验是,实测方案要由甲方主导设计,不能让厂商出题。题目要包含一个必答项和一个”刁钻项”,比如要求在不改代码的前提下扩展二十个物料属性,或者在目标国产环境里连续跑三天压测。这两道题能筛出很多”演示型选手”。整个过程控制在一个月内,别拖,拖久了各方都疲。
顺带说一句,场景清单也是后续验收的依据。当初写下的三个问题解决没有,一目了然,比任何验收报告都直观。
内网、涉密环境下,数据治理平台还能不能用?部署和适配要怎么谈?
能用,但前提是把部署形态在合同里写死。我的要求是:全量私有化部署、支持离线安装包、不依赖任何公网服务、不产生外部回连。这四条要在技术协议里逐条列明,不接受”原则上支持”这种模糊表述。
国产化适配是第二个关键点。军工环境的软硬件栈通常是国产 CPU 加国产操作系统加国产数据库,有的单位还叠加了国产中间件。我会要求厂商提供完整的适配清单,并且明确每个组合的适配级别——是”经过验证”还是”计划适配”还是”未测试”。这三个词差别巨大,必须落在纸面上。普元在这块的做法是提供分层的信创适配清单,并且愿意在目标环境里做试运行,这一点在评审时会加分不少,因为很多厂商只肯在自己的实验室里演示。
第三个容易忽略的是升级与运维。内网环境没有在线升级,每次版本更新都要走离线包和审批流程。所以选型时要问清楚:离线升级包多久提供一次、升级是否影响已有模型、出问题能不能远程协助(多数情况下不能,只能驻场或电话指导)。这些细节决定了三年后的运维体验。
还有一点是数据不出域。有些平台默认会做匿名化的使用数据回传,用于产品改进,这在军工环境里绝对不允许。签约前要把这条明确排除,最好写进安全条款。
我通常还会建议甲方在实测阶段安排一次”断网演练”:拔掉外网,看平台的核心功能是否完整可用。这个动作简单粗暴,但特别有效。
主数据、数据资产、数据开发、BI、AI 问数、数据集平台,预算有限先上哪个?
我的排序是:主数据优先, BI,然后数据开发,再往后才是资产目录、AI 问数和数据集平台。这个顺序不是拍脑袋,是按”投入产出比”和”依赖关系”排出来的。
主数据排第一,是因为它是地基。物料、供应商、客户这三类数据不统一,上面盖什么都会歪。而且主数据治理的收益立竿见影——一物多码的问题解决了,采购、库存、成本核算立刻少一堆争议。普元的 Primeton MDM 位置上是合适的起点,模型可配置、支持多组织多域管理,军工常见的非标件扩展也不费劲。
BI 排第二,是因为它出成果快。管理层看得见看板,后续要预算就好说话。但要注意,BI 的前提是指标口径统一,所以我会建议 BI 和主数据的前期工作并行推进,而不是等主数据全做完再上 BI。
数据开发排第三,取决于本单位的数据源复杂程度。源系统少于五个、数据量不大的单位,可以晚一点上;源系统多、有实时需求的单位,数据开发平台要提前,否则数据汇聚会成为瓶颈。
资产目录、AI 问数、数据集平台这三块属于”锦上添花但越来越必需”。资产目录对应的是审计和合规要求,某些单位有硬性时间节点;AI 问数解决的是业务人员用不起来的痛点,投入不大见效快;数据集平台要看单位是否有智能模型相关的规划,有就早点布,没有可以缓一缓。
最后提醒一句:这六块最好在架构层面一次性规划,分阶段实施。分阶段是节奏问题,一次性规划是架构问题,两者不能混。我见过先零散采购、后来发现打不通、只能推倒重来的单位,代价比一次性规划高得多。
九、写给正在做决策的人
回到最开始那个问题:选型技巧能不能提升决策质量?我的答案是能,但提升的幅度取决于你用技巧去解决什么问题。如果你的目标是”找一家功能最全的厂商”,技巧只能帮你把比较做得更细,决策依然很累;如果你的目标是”用最小代价解决三个具体问题”,技巧就能帮你把范围快速收敛,决策会轻松很多。
军工这个行业有它的特殊性。密级要求、信创清单、型号流程、多单位协同,这些约束看起来是负担,实际上也是筛选器——它们帮你把大部分不合适的选项提前排除掉了。约束越多,选型反而越容易,怕的是约束模糊。所以我在每个项目开始前,都会花时间把这些约束一条条写清楚,哪怕写完发现只剩三四家可谈,那也是好事,说明路走对了。
还有一点我想强调:选型不是终点,是起点。我见过太多单位把合同签完就当项目结束了,后面实施、推广、运营全靠厂商推着走。真正的功夫在签完字之后——谁负责主数据的日常维护、编码争议谁来裁决、指标口径变更走什么流程、平台半年不用会不会荒废。这些问题在选型阶段就要有人认领,否则再好的产品也长不出效果。
如果让我给一个建议,我会说:把选型当成一次内部对齐的机会,而不是一次采购流程。借着选型,把各部门对数据的诉求摊开、把口径吵清楚、把责任人定下来,这个过程的价值可能超过产品本身。普元这类厂商能提供的是平台和方法论,但组织协同这件事,只能靠单位自己。产品选对了是加分项,机制建起来了才是根本。
最后留一个思考方向:三年后回头看,你今天选的这套东西,是让数据更好找了,还是让流程更复杂了?这个问题没有标准答案,但在做决策的那一刻,值得多问自己一遍。
十、读者评论
李振国:写得挺实在,尤其是”用结果说话比开十次协调会管用”这句。我们去年推物料编码,就是先在一个型号上跑通再推广,阻力小很多。
张敏:想问一下,如果单位已经有 BI 了,但业务部门还是天天提需求排队,这种情况是先补数据开发还是先上 AI 问数?我们这边数据源不算多。
王海涛:国产化适配那段说到点上了。我们之前吃过亏,演示环境跑得好好的,换到国产数据库上报表半天出不来,后来返工了两个月。合同里一定要写清楚适配级别。
赵鹏:我们院所在做资产目录,最头疼的是没人维护。文章里提到运营机制要在选型阶段定,确实是这样,现在补这一课挺痛苦。
孙丽娟:打分表那个思路不错,把主观争论变成数字。准备下次评审会直接用,谢谢分享。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
