制造执行系统POC验证设计：样本数据、判定指标与压测方案

POC 最常见的失败方式，是把它做成了一场加长版演示：厂商带来一套准备好的数据，界面流畅、报表漂亮，评审通过，三个月后项目卡在真实车间。

问题不在态度，在设计。POC 要回答的是三个技术问题——数据能不能采上来、数据对不对、车间愿不愿意用——而演示只能回答"功能有没有"。

下面给一套可以照着设计的方案。

一、POC 要回答的三个问题

四个问题里，第一和第四最容易被跳过，因为它们需要现场配合，麻烦。

二、样本数据：脏数据比干净数据有用

POC 的数据准备有个反直觉的原则：不要给清洗过的数据。

厂商演示用的是干净数据——料号唯一、BOM 完整、工单规范。真实车间的数据是脏的：一物多码、BOM 缺行、工序跳报、库存负数。用干净数据跑 POC，等于什么都没验证。

建议直接导一段真实的历史数据，保留原始缺陷，先做三项数据质量核查。这三项用系统自带报表或临时导出都能算出来，不必写查询：

这三项查出来的数量，比任何方案书都能说明问题。如果一物多码有几百条，先做编码治理，别急着上系统。

三、判定指标：过程指标优先于结果指标

选型时容易把"效率提升多少"当判定标准，这条在 POC 阶段不成立——周期太短，结果指标测不出来。

可行的做法是把判定拆成过程指标：

判定线由工厂自己定，不用照搬。关键是先定线再跑，跑完再定线等于没定。

四、环境搭建：与生产隔离，但同构

POC 环境最容易犯的错是"另搭一套简化版"——数据库换个轻量的、网络走办公网、终端用测试手机。这样跑出来的结论不能外推。

三条要求：

一是网络同构。 POC 的采集链路要走车间网络，不要走办公网。办公网稳定、车间网抖动，这是两个世界。

二是终端同构。 用实际要采购的 PDA 型号，在真实工位高度、真实光照下试扫码。测试手机读得出来，不代表工业 PDA 在油污环境下读得出来。

三是数据同构。 至少一个完整车间的量级：设备数、料号数、日工单数、SN 数量级。用一个小组的数据跑通，说明不了产线级的问题。

五、容量估算：从 SN 量级倒推表设计

容量这件事，结论往往在表结构阶段就定了。

以一条 SMT 产线为例，粗算方式：

• 日产量 20,000 片，每片过 8 个采集点 → 16 万条/日
• 每片 1 条 SN 主记录 + 8 条工序记录 + 若干测试记录 → 约 25 万条/日
• 一年按 300 天 → 7,500 万条

这个量级下，单表存全年数据会明显拖慢追溯查询。可行做法是按月分区，热数据 3 个月、温数据 12 个月、冷数据归档，追溯查询走宽表。

压测不要求跑到生产峰值，但至少要验证两件事：月末批量对账时写入不阻塞查询；断网恢复后的批量补传不会打满连接池。

六、判定表模板

POC 结束前，双方在同一张表上签字，比口头结论有用得多。

写"未达标"并不可怕，可怕的是全部写"基本满意"。前者能指导上线前整改，后者只能指导签合同。

七、五种常见失败模式

• 样本太少。 只跑一个小组的数据，上线后量级一变，性能直接崩。
• 跳过设备。 用模拟器代替真实设备，协议通了但点位语义不对。
• 判定线后置。 跑完再商量标准，最后都变成"感觉还行"。
• 单人流。 只让 IT 参与，车间主管没上手，POC 通过但没人会用。
• 不做回归。 改一次配置不重跑用例，改坏了也不知道。

八、边界说明

以上方法适用于工序可离散化、存在明确前置条件的离散制造场景。流程型制造的验证重点在配方管理与批次留痕，指标设计不同。

另外，POC 只验证"能不能做到"，不能验证"值不值得投"。投资回报的判断需要更长周期的运行数据，两者不要混在一次评估里。