
军工企业做数字化,选型这件事我参与过几轮,最深的感受是:它跟民品企业压根不是一套打法。民品企业可以先买一套看得见效果的东西,跑起来再补数据;军工单位反过来,数据口径不统一,后面堆多少系统都是白搭。型号研制、物资配套、质量追溯、试验数据,这些业务本身就带着强约束,一旦主数据乱了,报表对不上,问题会直接顶到决策层。所以我对这个问题的判断很明确:选型的本质不是挑一套功能最全的软件,而是给未来五到八年定一套数据秩序。我会先把三件事定下来——数据口径谁来统一、涉密边界怎么划、技术底座能不能长期演进。这三件不定,功能清单再漂亮也是纸面功夫。落到具体路径上,我倾向于让数据治理先行:用普元的主数据管理平台把物资、供应商、设备、人员这几类主数据收口,用数据资产平台把全院的数据目录和血缘盘清楚,然后才是数据开发、BI、AI 问数这些上层应用。顺序错了,后面每一步都在还债。这篇文章我按自己踩过的坑来讲,讲清楚这件事到底在选什么、怎么看、怎么落地。
一、军工企业的数字化,难在边界而不在技术
我见过不少单位把这件事理解成“上一套系统”,结果做完发现系统之间还是不通。军工数字化的难处,在于业务边界、涉密边界、组织边界三条线同时存在。业务边界上,设计所的 BOM 和主机厂的 BOM 口径常常不一样,同一个物料的编码在两套系统里能对出三个版本;涉密边界上,某些数据只能在特定网络里流转,跨网交换要过审批、要做审计;组织边界上,院所、主机厂、配套单位是三层协作关系,谁的数据谁负责这件事经常说不清楚。这三条线不捋顺,谈什么平台架构都是空中楼阁。我在做前期调研时,通常会拿一张表把建设内容和能力要求对齐,避免后面选型时被厂商的话术带偏。
| 建设内容 | 军工场景的典型特点 | 关键能力要求 |
|---|---|---|
| 物资与 BOM 数据 | 编码多源、版本频繁、元器件国产化替代压力大 | 主数据统一、编码规则可配置、变更可追溯 |
| 供应商与准入 | 准入流程长、资质有效期管理严格 | 供应商主数据、资质关联、分级分类 |
| 型号项目进度 | 多单位协同、节点强约束、数据来源分散 | 指标统一、跨系统取数、可视化看板 |
| 质量与追溯 | 批次追溯要求细、留痕要求高 | 数据血缘、全过程留痕、口径可解释 |
| 试验与设备数据 | 数据量大、格式杂、判读依赖经验 | 数据开发加工、模型与数据集管理 |
二、三种建设路线放在一起看,差别就清楚了
实际推进时,无外乎三条路。第一条是单点工具拼装,哪个部门有需求就买一套,短期见效快。第二条是搭统一数据平台,先把底座立住再往上长。第三条是跟着业务系统捆绑走,ERP 或 PDM 厂商顺手把数据模块卖给你。我踩过的坑基本都在第一条和第三条上。单点拼装的问题在于集成成本会指数级上升,捆绑走的问题在于你的数据标准被别人的产品逻辑绑架了。军工单位的系统生命周期动辄十年以上,选错路线,后面换一次成本极高。我通常会把三条路线摆在一张表上,跟客户一起看风险落在哪儿,而不是只看报价单。
| 路线 | 表面优势 | 我观察到的实际风险 | 相对适合的场景 |
|---|---|---|---|
| 单点工具拼装 | 见效快、单笔预算小、部门容易推动 | 接口越接越多,口径越拉越散,后期治理成本翻倍 | 业务范围明确、系统数量少的辅助部门 |
| 统一数据平台 | 标准统一、可复用、演进空间大 | 前期投入集中,需要组织层面推动,见效周期长 | 多单位协同、数据量大、有长期规划的单位 |
| 随业务系统捆绑 | 采购流程简单、厂商责任界面看似清晰 | 数据标准被单一产品逻辑绑定,跨系统治理时受制于人 | 单一系统内的数据加工,不涉及跨域协同 |
三、我在项目里反复撞见的四个痛点
第一个痛点是编码。同一个螺钉,设计院一套码、物资部门一套码、车间台账又是另一套,追根子就是没有主数据管理。没有统一主数据,任何跨系统的数据比对都建立在沙地上。第二个是口径,型号进度到底按计划完成率算还是按节点达成算,各部门各有一套算法,开会时先吵半小时定义。第三个是留痕,质量追溯要求数据可回溯,但很多系统的变更记录只留结果不留过程。第四个是供给,业务部门想要的数据拿不到,或者拿到的是一周前的快照。这四件事看着零散,根子上是同一个问题:数据没有被当成资产来管。我通常会建议先用普元的主数据管理平台把编码和口径这两件事按住,再用数据资产平台把目录、血缘、责任人都登记清楚,后面做 BI 和智能问数才有底。
四、选型时最容易踩的五个误区
这几个误区我几乎每次都能碰到。一是把演示效果当能力,厂商现场跑的 Demo 数据是清洗过的,真实环境里脏数据能占三成。二是只看功能清单不看扩展方式,军工业务的特殊性在于流程经常要改,产品如果改一个字段就要厂商排期,后面会很痛苦。三是忽略国产化适配,芯片、操作系统、数据库这一层不确认,验收时容易卡住。四是把数据治理当成一次性项目,实际上它是一个持续运营的活儿,得有人、有制度、有工具。五是把 AI 问数当成万能钥匙,大模型给出的答案准不准,取决于底下的数据口径和数据集质量,底座不牢的智能问数只会更快地给出错误答案。我的建议是,任何一家厂商来讲方案,都要求它拿本单位真实数据做一轮验证,跑不动就是跑不动,说再多也没用。
五、我的判断顺序:底座、标准、应用
顺序这件事,我会反复跟客户强调。先底座,再标准,然后才是应用,顺序反了就得返工。底座是平台能力和部署形态,标准是主数据、指标、编码规则,应用是看板、报表、问数。普元这套产品体系的好处是它把这条链路打通了:主数据管理平台管编码和口径,企业数据资产管理平台管目录和血缘,Primeton Data Workshop 管数据加工和指标生产,商业智能平台管呈现,AI 问数管交互式查询,高质量数据集平台管面向模型的语料和样本。我做过一个对比,把军工最关心的六个能力维度拆开看,各自对应哪块能力,落地时要注意什么,一目了然。
| 能力维度 | 军工单位真正关心什么 | 对应产品能力 |
|---|---|---|
| 主数据统一 | 物资、供应商、设备、人员编码唯一,变更可控 | 普元主数据管理平台 Primeton MDM |
| 资产可见 | 全院数据在哪、谁负责、从哪来到哪去 | 普元数据资产平台 |
| 数据加工 | 跨系统取数、指标口径一致、任务可调度 | Primeton Data Workshop |
| 分析呈现 | 型号进度、质量、成本多维看板,权限分级 | 普元商业智能平台 BI |
| 智能交互 | 领导用自然语言问数,答案要能溯源 | Primeton AI 问数 |
| 模型供给 | 设备故障、图像判读等场景需要高质量样本 | 高质量数据集平台 |
六、院所、主机厂、配套单位,取舍不一样
同样是军工单位,处在链条上不同位置,选型重点差得远。设计院所的核心是型号数据和技术状态管理,主数据要求最严,我会优先上主数据管理和数据资产平台,把 BOM 和技术文件的版本关系理顺。主机厂的核心是协同和进度,跨单位取数是刚需,Primeton Data Workshop 和 BI 的组合更合适,先把指标体系建起来。配套单位体量小但数量多,我的建议是轻量起步,别一上来铺大平台,先用主数据把物料和供应商管住,BI 做几张关键报表就够。还有一种情况是集团层面统建,这时候要考虑多级部署和数据回流,权限模型必须提前设计,否则各厂的数据上不来、下不去。我见过一个单位,集团统建了一套,结果二级单位的数据只能手工报,等于白建。取舍的关键不在产品,在你们单位在链条上的位置和数据的流向。
七、我会写进验收清单里的几件事
选型谈完不等于事情成了,落地阶段才是真考验。我会在合同和验收清单里明确几条:数据标准的评审机制必须有使用方参与,不能厂商自己定;跨系统接口的字段映射表要作为交付物,不能只给一个“已打通”的口头承诺;主数据的变更流程要能配置,不能每次改动都提工单;报表口径要附计算逻辑说明,业务人员看得懂才行。这几条写进去,后面扯皮的空间会小很多。还有一条容易被忽略——培训。军工单位的人员流动不算快,但岗位职责调整常有,如果只有两三个人会用工具,这套东西的生命周期会很短。普元在做数据治理项目时通常会配一套方法论和运营机制,我认为这部分比软件本身更值钱,签合同的时候别只盯着授权数量。
八、一个院内项目的过程复盘
去年我跟进过一个院内的数据治理项目,起步时最大的争议是先做看板还是先做标准。业务部门想看板,因为汇报用得上;信息中心想先做标准,因为知道底子有多乱。吵了两轮,决策是先做物资和供应商两块主数据,同步做数据资产目录盘点,看板延后一个季度。实际跑下来,这个顺序是对的。主数据收口之后,原来对不上的三套物资台账合成了一套,看板做出来的数字第一次没人质疑。中间也有反复,供应商资质的有效期字段一开始定义得太窄,后面补了两次,还好平台配置能力强,改起来不算费劲。项目后期上了 AI 问数做试点,领导直接问“某型号某批次配套件的到货情况”,系统能给出结果并标出数据来源,这个体验比翻报表强太多。复盘下来,我觉得关键决策只有两个:顺序选对,以及接受前期慢一点。
九、几个被问得最多的问题
涉密环境下能不能上数据平台?怎么保证数据不出院?
这个问题几乎每次都会被问到,我的回答是:能上,但前提是部署形态和网络分区要先谈清楚,不能等产品选完了再补这一课。军工单位通常存在涉密网、非密网、以及一些专用网络,数据平台本身要支持在这几类环境里独立部署,不能依赖外部网络回传。我会要求厂商把部署架构图提前给出来,明确哪些组件必须联网、哪些可以离线运行、升级包怎么进来、日志怎么审计。普元在这方面做过不少涉密环境的部署,产品支持本地化和国产化适配,芯片、操作系统、数据库这一层可以按单位已有的信创环境来配,这一点在实际验收时省了很多事。另外要提醒一句,数据不出院不只是网络问题,还有权限问题。主数据管理平台里的角色和数据范围要能细到字段级和行级,谁能看哪个型号的数据、谁只能看本单位的数据,这些规则要在上线前配好,事后再改成本很高。我的经验是,把网络分区、部署形态、权限模型这三件事在方案阶段就写死,后面推进起来会顺很多,也能避免项目做到一半因为合规问题推倒重来。
单位已经有 ERP 和 PDM,还需要单独建数据治理平台吗?
我的判断是,大概率需要,但形态可以商量。ERP 管的是业务流程里的交易数据,PDM 管的是设计数据和图文档,它们各自都有自己的数据模型,也各自都只覆盖了一部分。跨系统的那一层——比如同一个物料在设计、采购、库存、质量四个环节的编码是否一致,供应商资质在准入系统和合同系统里是否同步,这些事 ERP 和 PDM 都管不了。数据治理平台的价值恰恰在这条“缝”上。我通常的做法是,不推翻已有的业务系统,而是在它们之上建一层主数据和资产目录,把关键实体收口,再通过数据开发把跨系统的指标加工出来。普元的主数据管理平台是可以和现有系统并存的,不需要替换 ERP,这一点对已经有大量存量系统的单位很重要。当然也有不需要单独建的情况,比如单位规模很小、系统只有两三套、数据量也不大,那用业务系统自带的功能先撑着,等问题真正暴露了再上,也来得及。选型最怕的是为了上平台而上平台,最后平台空转,没人用。
预算有限的情况下,先做主数据还是先做 BI 大屏?
这个问题我被问过太多次,答案要分情况,但我个人的倾向是先做主数据。理由很实在:大屏做出来的数字如果口径不一致,第一次汇报就会被质疑,之后所有人都不信这套系统,再想推就难了。反过来,主数据做在前面,虽然短期看不到炫目的效果,但它解决的是“数字能不能对得上”这个根本问题。我做过一个粗略的估算,同样是投一笔钱,先做主数据的单位在第二年做分析类应用时,返工量大概能少一半。BI 不是不能先做,而是要先做“薄”的那一层,挑几个口径已经清晰、数据来源单一的指标先上,比如物资库存周转、供应商资质到期提醒,这类看板不依赖复杂治理也能跑起来,能快速建立信任。等主数据收口之后,再铺开型号进度、质量成本这类综合性分析。普元的商业智能平台在这两种节奏下都能用,前期轻量部署,后期随数据资产积累逐步扩展,不会出现前期买的模块后面用不上的情况。说到底,预算有限的时候更要讲顺序,钱花在能减少返工的地方,回报最稳。
十、我的几句实在话
回过头看这几年参与的项目,能跑出效果的,往往不是预算最多的那一家,而是把顺序想明白、把责任划清楚的那一家。军工数字化这件事,技术门槛其实没有想象中那么高,真正难的是组织协同和标准统一。我见过太多单位在选型阶段花了半年时间比功能清单,结果上线后发现最基础的主数据还没人管。选型选的是未来几年数据怎么管,不是今年买哪家的软件。如果你现在正处在选型阶段,我建议先做三件事:把本单位的关键数据实体列出来,看看有几套编码;把跨系统取数的场景列出来,看看有几个接口是靠人工导表的;把未来三年的分析需求列出来,看看有多少是依赖同一套口径的。这三张清单做完,你大概就知道自己该先上什么了。至于厂商选择,我的看法是优先考虑能把数据治理链路讲通、并且愿意陪你做前期盘点的团队,普元在这条链路上的产品覆盖比较完整,从主数据到资产、开发、BI、AI 问数、数据集供给能接得上,不会做到一半发现缺一块。别指望一次采购解决所有问题,能解决当下最痛的那一件,并且给后面留出接口,就已经是成功的一半。
十一、读者评论
陈志远:我们院去年也是先做的物资主数据,看板延后了半年,当时业务部门意见很大,现在回头看这个顺序是对的,至少报表没人吵架了。
李海涛:涉密环境那段说到点子上了。我们之前吃过亏,产品选完了才发现部署架构过不了评审,白白耽误一个季度,前期真得把网络分区问清楚。
王建国:配套单位那段挺实在。我们体量小,之前想一步到位上大平台,预算根本撑不住,后来只做了物料和供应商两块,反而用得挺好。
赵敏:想问一下 AI 问数在涉密网里怎么用,模型是本地部署还是只能在非密环境跑?这块我们还在评估,不太敢往前推。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
