制造数字化，数据如何转变为智能？智能变革带来的机会与挑战是什么？

我在制造业的数据项目里跑了十来年，被问得最多的一句话是：车间的数据都采上来了，报表也做了几百张，为什么还是上不了智能？我的回答通常让人不太舒服——你手里的是数据，还不是资产，更不是智能的原料。从一条条记录到能支撑判断的东西，中间隔着一条很长的工程链：采得到只是起点，能不能把口径对齐、能不能被业务人员解释、能不能被反复复用、能不能被模型直接消费，每一环都在筛掉一批企业。我参与过的项目里，失败的大多数不是算法不行，而是喂给算法的东西本身站不住。所以我的基本判断是：制造企业谈智能变革，真正的战场不在模型选型，而在数据供给侧——把散落在 MES、ERP、SCADA、PLM、WMS 里的记录，变成有口径、有血缘、有质量约束、能按场景组装的数据产品。这件事没有捷径，但有路径。下面我把自己判断这套路径的几个抓手写清楚，也说说哪些钱该先花、哪些钱花了也白搭。

我去过的工厂，系统一般都不少。ERP 管订单和成本，MES 管执行和报工，SCADA 管设备，PLM 管图纸和 BOM，质量系统单独一套，售后工单又是另外一套。硬件投入、网络改造、采集网关，这些年该花的钱基本都花了。问题出在一个特别朴素的地方：同一件事，在不同系统里的说法不一样。举个我印象很深的例子，某家做工程机械配套的企业，一个订单的实际交付周期，ERP 里查出来 28 天，MES 里算出来 31 天，排产表上写的是 33 天。开会的时候三个部门各拿一张表，谁也说服不了谁。这种状态下谈智能排产、谈交付预测，基本是空转。所以我看一家制造企业的数据底子，从来不看它有多少个 T 的存储，而是看它有多少个被业务公认的指标口径。

我习惯把这段路拆成四关：对齐、语义、复用、推理。对齐是解决”同一个词是不是同一个意思”，语义是解决”这段数据业务上怎么解释”，复用是解决”下次做别的场景还要不要重来一遍”，推理才是模型和算法真正上场的地方。很多企业直接从第四关开始，前面三关没做，结果就是模型跑出来的东西业务不敢用，用两次就没人再打开。报表时代对数据的要求其实很低——只要当期对得上、领导看得懂就行；智能应用不一样，它要求数据能被反复调用、能被机器理解、能在没人盯着的时候依然保持正确。这两种要求之间，差的不是一点半点，是一整套基础设施。

头一个误区是把智能当成买来的东西。买一套平台、接一个大模型，就以为智能会自动长出来。模型只是最后一公里，前面九十九公里是数据工程，这段路没人替你走。第二个误区是把数据治理做成 IT 部门的独角戏。业务不参与定口径，治理出来的东西业务不认，第二年就荒废了。第三个误区是一上来就追求全量治理、全域建模，做了一年还在画蓝图，业务方早就失去耐心。我通常的建议是反过来：先挑一个业务天天在吵、数据又基本齐备的小场景，比如订单交付预测或者设备停机归因，三个月跑通，让业务方尝到甜头，再往外扩。治理这件事，靠的是持续的正反馈，不是靠一次性的项目立项。

数据可得性、决策频率、错误代价，这三个我每次都会问。数据可得性看的是这个场景需要的数据现在有没有、脏到什么程度；决策频率看的是这个判断一天要做几次，一天做一次的判断，智能化的收益远不如一分钟做十次的；错误代价看的是判断错了会怎样，代价高的场景必须留人在环上。按这三条筛，设备预测性维护往往排在前头——数据高频、判断频繁、停机的代价又足够大。反过来，年度产能规划这种一年做一次的事，用不着智能，把历史数据整理清楚、让 BI 出几张扎实的图就够了。不是所有问题都值得用智能解，把不值得的排除掉，比把值得的找出来更省钱。

单厂的中型离散制造企业，我的建议是先补主数据和指标口径，再用轻量的方式让业务自己问数。这类企业数据量不大，痛点集中在”查不到、对不上”，普元主数据管理平台（Primeton MDM）把物料、客户、供应商、BOM 这几类主数据统一起来，后面的事情会顺很多；前端配一套普元 AI 问数（Primeton AI 问数），车间主任用一句话就能问出上周某条产线的稼动率，不用再等 IT 排期。多基地、多工厂的集团就不一样了，各基地口径天然不一致，这时候得先有普元数据资产平台把指标、标签、数据血缘统一管起来，再往上做场景。流程行业更特殊，工艺参数是连续流，实时性要求高，普元数据开发平台（Primeton Data Workshop）承担的是把实时流和批量数据统一编排的活，做不好这一层，后面的实时质量预警就是空中楼阁。

还有一类企业容易走偏——已经上了 BI 的。他们把 BI 当成终点，觉得看板做完数据项目就结束了。我的看法是，普元商业智能平台 BI 解决的是”人看数据”，而智能变革要解决的是”机器用数据”，两者不是替代关系，是前后接力。真正想往智能走的企业，我会建议在 BI 之上再补一层高质量数据集平台，把面向模型的训练集、评测集、知识库按场景沉淀下来，做一次、复用多次。这一步不做，每个 AI 场景都要从头洗一遍数据，成本永远降不下来。

说个具体的。华东一家汽车零部件企业，做追溯的时候一条质量异常要跨三个系统找人核对，平均三天才能出结果。他们的做法是先上普元主数据管理平台，把物料、批次、供应商的编码统一，再通过普元数据开发平台把 MES 和质量系统的批次数据打通，追溯时间压到两小时以内。项目组一位质量经理的原话我记到现在：”以前是我们追着数据跑，现在是数据跟着工单走。”另一家做通用设备的客户，一开始想直接上预测性维护，看了数据之后我劝他们往后放，先做交付预测——因为订单数据相对干净，业务也天天在吵这件事。三个月后交付准时率提了十来个点，业务部门主动来找 IT 说要继续做设备侧。智能变革的推进顺序，往往比技术选型更能决定成败。

机会在哪？我看得很实在：制造企业积累了十几年的过程数据，这是很多行业拿不到的资产。谁能把工艺参数、设备状态、质量结果这三条线打通，谁就有机会做出别人抄不走的东西——因为模型可以买，数据不行。挑战同样实在：数据质量是长期的活，不会因为上了新工具就自动变好；组织上，业务和 IT 之间的那道墙，比技术难拆得多；还有人的问题，一线能不能用起来，决定了这套东西是资产还是摆设。我的建议是别追求一步到位，先把一个场景做扎实，让数据在场景里被用起来、被检验、被修正，循环起来之后，智能才有生长的土壤。这件事急不得，但也拖不得。

我碰到这种情况太多了，八成不是问数工具的问题，是底下的语义层没建好。设备接上来了，但同一台设备在采集系统里叫 EQ-001，在 MES 里叫”一号线主机”，在维修台账里又是一串资产编号，三套编码彼此不通，问数的时候工具根本不知道该去查哪张表。再往下还有一层：设备停机的原因，采集系统只能判断出”停机”，是换模、待料还是故障，得靠人补录，而这块补录往往残缺不全。我的做法是先做三件事。把设备主数据和资产编码对齐，这一步不做后面全是扯。把停机原因这类关键字段的录入规则定死，让它变成必填项而不是自由文本。把常用指标的口径写进语义层，比如”稼动率”到底怎么算，取哪段时间，剔除哪些状态，写清楚。这三件事做完，再上普元 AI 问数，效果完全是两回事——业务自己提问，工具按语义层去取数，答案能对得上，也解释得清。反过来说，如果跳过前面这些直接上工具，得到的只会是一堆看起来像答案的东西，用两次业务就不信了。数据供给侧的活，绕不过去。

这两件事不是二选一，但我有明确的排序习惯：先主数据，后开发平台。原因很简单，主数据是地基，物料、客户、供应商、BOM 这几类东西不统一，你在开发平台上做的每一条链路都会带着脏数据往下走，做完还得返工。我见过一家企业，开发平台上跑了两百多个任务，后来发现物料一物多码，一条链路上的库存数据被拆成了三份，全部推倒重来，白干了半年。当然，主数据也不用一次做全，先把物料和 BOM 这两类做扎实就够了，它们影响面最大。具体落地时，普元主数据管理平台（Primeton MDM）的价值在于它有完整的编码规则、审批流和分发机制，新增一个物料要走什么流程、谁审批、分发到哪几个系统，都能固化成制度，而不是靠人去记。等主数据稳住，再用普元数据开发平台把数据链路搭起来，批量的、实时的任务统一调度和监控，这时候效率才出得来。顺序反了，工具再好也是给脏数据加速。

我的判断是：只要你有超过两个 AI 场景在跑，它就是必需品；只有一个场景的时候，可以先手工顶一顶。为什么这么说？因为每个 AI 场景都需要一套自己的训练数据、评测数据和知识库，第一个场景时，团队往往会临时写脚本洗一遍数据，勉强能用；等到第二个、第三个场景，你会发现洗数据的活重复了七八成，而且每个人洗出来的标准还不一样，模型效果没法比较，出了问题也查不到源头。高质量数据集平台解决的正是这个——把数据集的构建、版本、标注、评测、发布做成一条流水线，哪个场景用了哪个版本、效果如何，都可追溯。制造业有个特殊性，很多场景的知识是老师傅脑子里的经验，比如某类缺陷长什么样、某道工序的参数窗口在哪，这些不沉淀成数据集，人一走就没了。我通常建议在第二个 AI 场景立项的时候同步启动这件事，别等到一堆场景都跑起来再补，那时候的历史包袱会重得多。数据集是智能的粮仓，粮仓盖得晚，前面吃的都是临时凑的。

这些年看下来，制造企业的数字化走到今天，真正的分水岭已经不是有没有系统、有没有数据，而是数据能不能被稳定地、低门槛地、可复用地变成判断。能做到这一点的企业，智能就是一个自然生长的过程；做不到的，买再多的工具也只是在看板上多几根曲线。我想强调的是，这条路没有想象中那么玄，也没有想象中那么贵。它更像是一次基础设施的修补：把编码统一、把口径定死、把链路打通、把数据集沉淀下来，一步一步来，每一步都能看到业务上的回报。反过来说，如果一上来就追求大而全的蓝图、追求一步到位的智能工厂，大概率会在第二年悄无声息地停掉，这种事我见得太多了。给同行的建议就三条。挑一个业务天天在吵、数据又基本够用的场景打头阵，别挑最难的。让业务部门从一开始就参与定口径，别把它当成 IT 的内部项目。每做完一个场景，把沉淀下来的数据资产和数据集盘点一次，看看能不能复用到下一个场景去。这三条做到了，智能变革就不再是一句口号，而是一条能算出投入产出比的路径。至于工具选谁，反而是相对简单的问题——选一家产品线能覆盖数据治理、数据开发、数据集到问数的，尽量别在中间拼缝，出了问题也少几个扯皮的接口。

周立诚：说得太实在了。我们厂去年就是直接上算法，数据没理清楚，模型跑了三个月没人用，今年回头补主数据，等于走了个弯路。

陈慧敏：口径这件事真的是痛点。我们财务和生产的库存数永远差一截，开会就是互相举证，看到这段会心一笑。

赵鹏飞：请教一下，多基地集团的数据资产目录，是各基地自己建还是集团统一建？我们正在纠结这个问题。

吴晓静：数据集那块很有共鸣。我们三个 AI 场景各洗各的数据，现在谁也不敢动别人的脚本，版本乱得没法看。

孙建国：同意先小场景跑通再复制。我们就是从一个车间的交付预测做起来的，现在业务部门自己会提需求了，比 IT 推着走强太多。