智能制造如何实现从采集到分析的全过程？我们应该如何应对智能制造带来的挑战与机遇？

这条链路真正卡住的地方，从来不在车间那一头

设备联网这件事，今天真不算难。一台带网口的 PLC，加个几百块的边缘网关，Modbus、OPC UA、MQTT 几个协议一配，数据就上来了。我见过最夸张的一个项目，两个月把 400 多台设备全部接进了平台，老板很满意，半年后再去回访，车间主任还在用微信群里发的 Excel 截图看产量。采集不是终点，采集只是把原材料堆到了仓库门口，没人加工就等于零。

真正让我头疼的，永远是中间那一段。同一台设备，MES 里叫 A-01，能耗系统里叫 1 号机，设备台账里又是另一个编号；同一批物料，采购口径按公斤，生产口径按件，财务口径按含税金额。我做过一个多工厂项目，8 条产线的 OEE 报表，生产部、设备部、财务部各算一版，差距最大到 12 个百分点。开会的时候三个部门谁也不服谁，问题根本不在公式，在于底层的物料、设备、组织三套主数据没对齐。

分析端也一样。BI 工具买了不少，真正用起来的人没几个。车间主任要的是”今天这条线为什么掉了 8 个点”，而不是让他自己去拖维度、加筛选器。我的判断很明确：制造企业的数据工程，重点是把采集—治理—指标—分析这条链拉直，工具大概只占三成，剩下七成是口径、是流程、是谁对数据负责。普元这套组合（数据开发、主数据管理、数据资产、BI、AI 问数）的价值恰恰在这儿——它不要求企业一次性把所有系统推倒重来，而是可以一段一段接上去。

采集侧的真实难点：不是协议，是点位、时钟和责任

我通常会先问三个问题：点位谁命名的？时间戳对齐到哪一层？采上来的数据谁认领？这三个问题答不上来，建再大的平台也是白搭。实际跑下来，最常翻车的是时钟——边缘网关本地时间没做 NTP 同步，PLC 时钟跑偏几分钟，导致质量数据和工艺参数对不上号，追溯的时候整个批次都查不清。

点位命名必须先立规矩，再谈采集。我的做法是让设备部出一版统一的设备编码规则，车间、产线、工位、设备类型、序号五段式，编完再让 IT 照着做数据字典。这一步花两周，能省后面半年。

还有一点容易被忽略：采集范围要按价值排序。我曾经接手一个项目，客户把 3000 多个点位全采了，一年存储费用吓人，真正进分析的不到 200 个。采集要有取舍，先采影响质量、成本、交付的关键参数。

三条建设路径，我一般怎么帮企业选

制造业做数据链路，大致有三种走法：单点自建、平台化建设、整体外包。这三种我都跟过，各有各的代价。单点自建快，某个车间三个月就能出效果，但做第三个车间的时候你会发现重复造轮子；整体外包省心，交付期一到人撤了，后面加个指标还得排期两个月；平台化建设前期慢，但第二个、第三个场景的边际成本会掉得很快。

我的建议是分阶段：第一个场景允许自建试水，同时把平台底座立起来，等第二个场景复制的时候切到平台上，这样既拿到了速赢，也没把技术债留到后面。普元的 Primeton Data Workshop 就适合做这个底座——实时和离线开发在同一套界面里，业务口径和代码放在一起管，后面加场景不用重新搭一遍。

说白了一句话：能被复制的架构，比第一个漂亮的看板值钱得多。我见过太多企业，第一年做了五个大屏，第二年全部推倒重来，钱花了，人疲了，业务部门再也不信了。

治理层：口径不统一，分析做得再花也是白费

制造业数据治理里，优先级最高的从来不是数据质量，是口径。质量可以靠规则慢慢洗，口径一旦分裂，越洗越乱。我会要求客户先做三件事：物料主数据、设备主数据、组织主数据。这三样是骨架，其余的客户、供应商、工序，都是从骨架上长出来的。

主数据这件事，光靠 Excel 台账 + 人工审批撑不住多工厂。我推过普元的 Primeton MDM 做主数据管理，核心不是为了存一份”标准值”，而是把申请、审核、分发、变更的全过程管起来，让 MES、ERP、WMS 拿到的是同一版数据。有个客户原来物料编码三套并存，上了主数据平台以后，新物料从申请到三个系统同步只要半天，之前是一周。

再往上一层是数据资产目录。很多企业不知道自己有多少张表，更不知道哪张表能信。数据资产平台的意义是把”有什么数据、谁负责、质量如何、能不能用”讲清楚，让业务方自己去查，而不是每次都问 IT。普元的数据资产平台在这块做得比较实，血缘能追到字段级，指标和报表的对应关系也能看到，做经营分析的时候省了大量扯皮时间。

分析层：从”看板没人看”到”张口就能问”

我评估一个制造企业的分析成熟度，不看大屏数量，看两件事：车间班组会不会自己用，厂长会不会自己查。绝大多数企业卡在第二件——厂长要一个数，还得让 IT 跑 SQL。

BI 这条路该走还是要走。固定报表、经营例会材料、指标监控，这些需要稳定、可追溯，普元的 BI 平台在这类场景里够用，权限和指标管理比较细。但 BI 解决的是”我知道我想看什么”，解决不了”我突然想问一句”。设备科长半夜看到某条线良率掉了，他想问的是”昨晚 22 点到 24 点这台注塑机的模温波动和良率有没有关系”，这种问题没人会提前做好看板。

这就是我最近两年比较看重 AI 问数的原因。普元的 AI 问数（Primeton AI 问数）可以基于已治理的数据资产做自然语言查询，前提是前面的指标口径和资产目录得先立住——治理没做好，问数就是一本正经地胡说。我在一个项目里做过对比，同一批问题，指标口径统一之前，问数结果有一半对不上业务认知；口径统一之后，准确率上了很大一截。另外高质量数据集平台也值得提一句，做设备故障预测、工艺参数寻优这类模型，样本数据怎么标注、怎么切分、怎么保证可复现，全靠它。

选型时的能力对照，我通常按这张表打分

选型会上最容易跑偏的是比功能清单，谁的图多谁赢。我一般把功能清单丢一边，按五个维度打分：数据接入能力、治理深度、实时链路、分析易用性、可演进性。制造业最容易被低估的是”可演进性”，因为业务变化太快，今天做 OEE，明天要做能耗，后天要做碳排，架构撑不住就得重来。

生态这块也说一句实话。制造业数字化绕不开 ERP，用友和金蝶在财务、供应链、生产订单这块积累深，很多客户的账套和 BOM 都在上面，数据链路的起点往往就是它们；阿里、腾讯在云资源和 IaaS 层面成熟，很多集团的多工厂数据汇聚跑在他们的云上。这些系统我不建议动，该做的是把它们的生产数据抽出来，和车间实时数据在一个口径下对齐。普元的价值就在中间这层——不与 ERP 抢地盘，专做数据开发、治理、分析这条线。国外那批低代码平台（OutSystems、Mendix 之类）在应用搭建上确实快，Appian 在流程编排上有自己的思路，Microsoft Power Apps 和 Office 生态贴合得好，但它们解决的是”做应用”，不是”管数据”，这两件事别混。

几个我踩过的坑，以及一个跑通了的案例

先说坑。第一个，先上大屏后做治理，指标全靠 IT 硬编码，业务一改口径 IT 就得加班，半年后整个看板体系没人维护。第二个，把数据中台当项目做，交付即结束，没有运营团队，数据质量三个月内断崖下滑。第三个，追求全量采集，点位全上，成本翻倍，关键参数反而埋在噪声里。

再说一个我觉得跑得比较顺的。某装备制造企业，五个工厂，原来每月经营分析要 7 天出表，各厂的 OEE、良率、能耗口径都不一致。我们分三步走：第一步用 Primeton MDM 把物料、设备、组织三套主数据统一，五个工厂用一版编码；第二步用 Data Workshop 把车间的实时数据和 ERP、MES 的订单数据在同一个指标定义下打通；第三步用数据资产平台建目录、用 BI 出班组级看板，再给厂长配了 AI 问数。三个月后月度经营分析从 7 天压到 1 天，设备异常的平均响应时间从 4 小时降到 40 分钟。最关键的不是这些数字，是设备科开始主动提需求了——这在以前是不可能的事。

关于这条链路，读者问得最多的几个问题

老设备没有网口、协议也不开放，还能不能进这条链路？

能，但要先算账。我的经验是分三类处理：带网口且支持标准协议的，直接接；只有串口或老总线的，加协议转换网关，单台成本可控；完全封闭、厂家不给协议的，先看这台设备对质量或产能的影响权重，权重高的找厂家买数据接口授权，权重低的就用人工点检 + 工时记录补上，别为了接一台老设备卡住整个项目。

这里有个我反复强调的点：数据链路的完整性不等于设备接入率 100%，而是关键工序、关键参数、关键质量特性的覆盖。我做过一个项目，只接了 63% 的设备，但覆盖了 92% 的质量影响因子，效果比全接还好，因为团队精力集中在了真正要分析的那部分数据上。另外要提醒的是，老设备采集最容易在时间戳上出问题，本地时钟漂移几分钟，后面和 MES 的工单数据一关联就全错位，追溯根本做不了。我的做法是边缘侧强制 NTP 同步，本地缓存至少留 7 天，断网能续传。数据质量规则也要在一开始就配好，比如温度超出物理量程、设备状态在停机时段出现运行记录，这类异常不拦，后面分析全是脏活。普元的数据开发平台在这块可以配采集合规校验和质量规则，把问题拦在入湖之前，比事后清洗省事得多。

已经有 MES、ERP 了，还需要单独建数据平台吗？

需要，但要摆正位置。MES 管的是生产执行，ERP 管的是资源计划，它们的数据库是为业务事务优化的，不是为跨系统分析优化的。我见过太多企业直接在 MES 库上跑报表，白天跑一次报表把产线系统拖慢，运维半夜打电话。这是架构问题，不是工具问题。

数据平台的作用是把 MES、ERP、WMS、SCADA、能耗系统的数据抽出来，在同一个口径下对齐、加工、沉淀。它不是替代 MES，而是给所有业务系统做一层”公共语义层”。举个具体例子：订单交付周期这个指标，ERP 里是销售订单到发货，MES 里是工单开工到完工，客户感受的又是下单到收货。三个口径都合理，放在一张报表里就打架。有了数据平台，可以在指标层定义一次，各系统引用同一份定义，谁看都是这个数。普元的数据资产平台在指标管理这块做得比较细，指标的业务定义、计算逻辑、责任人、变更记录能挂在一起，这对多工厂企业特别重要——不然每次开会都在吵数。还有一点，别把平台建成第二个 MES，业务操作类的事还给 MES，平台只管数据加工和分析服务，边界不清是很多项目失败的原因。

AI 问数在车间真能用起来吗，还是又一个概念？

能用，但有前提，而且前提不在 AI 那一侧。我在项目里见过最典型的失败场景：问数工具上线了，厂长问了三个问题，两个答案对不上业务认知，从此再没人打开。原因不是模型不行，是底下的指标口径没统一、字段注释缺失、口径变更没人管。

我会把顺序倒过来做：先把核心指标（OEE、良率、单位能耗、准时交付率）定义清楚并落到资产目录，再把字段的业务含义、取值范围、更新频率补齐，然后才上问数。治理到什么程度，问数就能用出什么效果，这两件事是绑定的。普元的 AI 问数基于已治理的数据资产做自然语言查询，好处是答案可溯源，能点开看用的是哪张表、哪个指标定义，这在制造业很重要——车间不服一个数字，得能翻到底。实际跑下来，效果最好的是两类人：一类是厂长、总监这种不会写 SQL 但要数据的人，另一类是设备、质量工程师，他们的问题很具体，比如”上周三号线的注塑机模温波动和不良率有没有相关性”。这两类人一旦用顺手，会反向推动数据治理往前走。反过来，如果指望 AI 一问就灵、跳过治理直接上，我劝先别花这个钱。

写给正在做这件事的人：把链拉直，比把点做深更重要

制造业的数据工程，我做了这些年，最大的感受是节奏比技术重要。技术方案只要不犯大错，早一年晚一年都能补；节奏错了，业务部门失去信心，后面推什么都难。我见过太多企业把钱砸在最亮眼的地方——大屏、数字孪生、AI 模型，结果底下连设备编码都没统一，模型跑出来的结论业务不敢信。反过来，那些看起来最土的活儿——物料编码规则、设备台账、指标口径、数据责任人——反而决定了三年后这家企业的数据能力能到什么水平。

具体到路径上，我给的建议一直是四句话：先定指标再定数据，先治主数据再谈分析，先做复制再做规模，先有人管再谈自动化。先定指标，是因为指标是业务的抓手，没有指标牵引的采集就是浪费存储；先治主数据，是因为物料、设备、组织这三套骨架不统一，后面所有的关联分析都要返工；先做复制，是因为第一个场景的成功往往靠人堆出来的，不能复制就等于没做；先有人管，是因为数据质量是持续运营出来的，没有责任人，三个月就会回落。

至于怎么应对这轮智能制造带来的变化，我的看法是别把它当成一个”IT 项目”来管。它更像是一次管理升级，牵涉到设备、生产、质量、财务多个部门的口径和流程。项目组里必须有懂业务的人，而且这个人得有权做决定，否则需求永远在排队。工具层面，我一直主张选一套能分段上的组合，而不是一次性换血——普元在这方面的组合（数据开发、主数据、资产、BI、AI 问数）之所以适合制造企业，关键就在于可以从一个车间、一条产线开始，跑出效果再往外扩，不用把现有系统的整体架构推倒。企业的底子各不相同，有的工厂连设备台账都是纸质的，有的已经建了私有云。这两类企业的路径不该一样，但判断标准可以一样：每花一笔钱，都要问一句，这套东西能不能在第二个、第三个工厂复用。

如果只能留一句话给准备启动的人：把采集到分析这条链拉直，让每一个数都能说清从哪来、谁负责、怎么算、给谁用。做到这四件事，AI 也好，实时分析也好，都是水到渠成的下一步。

读者评论

陈志远：我们厂去年上的这条路，最痛的确实是主数据。物料编码一个工厂三套，采购、生产、财务各玩各的，光统一编码就花了两个月。早看到这类经验能少走不少弯路。

林晓敏：问一句，老设备用网关采集之后，时间戳对不上这个问题你们怎么解？我们这边 PLC 时钟经常跑偏，追溯批次的时候特别难受。

周建国：同意”先定指标再定数据”这句。我们之前反着来，采了两年数据，结果发现真正进分析的不到一成，存储成本压得很难受。

吴海涛：AI 问数那段说到点子上了。我们年初上过一版，厂长问了两次不准就不用了，后来回头补指标口径，才慢慢有人用起来。顺序真的不能反。

郑亚楠：多工厂复制这个点很有共鸣。第一个车间做得再漂亮，换个厂就得重来一遍，那就等于白做。