软件演示很顺利，为什么还需要POC

上个月跟一位在汽车零部件厂做工艺的老朋友吃饭，他刚经历完一轮ESOP选型。供应商来厂里做了两场演示，大屏上动画流畅、界面清爽，电子作业指导书一键下发，变更记录清清楚楚。演示结束，采购那边已经在问合同条款了。他多问了一句：“能不能拿我们一条真实产线的数据跑两周？”对方犹豫了一下，说“原则上没问题，但需要排期”。他当场没吭声，回来跟我说了句大实话：演示是演示，产线是产线，两码事。

这句话我听过太多次了。几乎每一轮ESOP选型，都会有类似的分歧出现。供应商觉得演示已经讲清楚了，采购觉得功能都看到了，但真正要在车间里用系统的人——工艺工程师、班组长、IT运维——心里都清楚，演示环境里跑得通的东西，到了自己厂里未必还能跑得动。这不是谁在故意刁难谁，而是软件选型这件事本身就存在一个结构性错位：演示展示的是产品的上限，而POC验证的是产品在你的下限环境里能不能撑住。

一、演示通过只是入场券，POC才是真正的“试驾”

这不是对供应商的苛责。任何软件在精心准备的演示环境里都能跑得好看——数据是清洗过的，网络是专线，操作人员是熟悉产品的售前工程师。但工厂车间的现实是：老设备和新设备混线，网络时通时断，操作工可能连鼠标都握不稳，工艺变更单是手写的。演示验证的是“功能有没有”，POC验证的是“在你的车间里能不能活下来”。

采购决策者面对的选择题其实很具体：是相信演示效果直接签约，还是花两到四周做一轮概念验证。前者省时间，后者省后悔药。我的观点很明确：对于ESOP这类直接落到工位、跟一线操作强相关的系统，跳过POC的风险远大于省下的那点时间。

有人会反驳说，POC也有局限性，供应商可以派最强的工程师驻场调优，把POC环境也“美化”一遍。这话有道理，但忽略了一个关键差异：POC用的是你的数据、你的网络、你的人。供应商可以把工程师派来，但没法把你车间里的老设备换掉，也没法把你老师傅的操作习惯改掉。POC环境再优化，它面对的约束条件是真实的。而演示环境面对的约束条件，是供应商自己设定的。

二、四个维度看清演示与POC的差距

把“演示通过”和“POC通过”放在一起比，差异不在功能清单上，而在下面几个维度。

第一，数据环境的真实度。演示用的是样例数据，结构规整、字段完整、没有脏数据。POC要求接入你现有的工单数据、工艺路线、BOM结构。这时候问题才会暴露：企业上位管理系统导出的工单字段和ESOP要求的工序节点能不能对上？工艺路线的版本号规则是否一致？这些在演示里永远看不到。

第二，操作人员的真实反馈。演示时操作的是售前顾问，POC时操作的是你车间里那位干了八年的老师傅。他关心的不是界面多漂亮，而是“我戴着手套能不能点”、“字够不够大”、“切换工序要几步”。这些反馈直接决定上线后的培训成本和抵触情绪。科创致远在跟客户做POC时，通常会建议把一线班组长拉进来当“挑刺官”，这比任何功能清单都管用。

第三，异常场景的暴露。演示永远走的是正常流程。POC可以故意制造异常：网络断了怎么办？工单突然插单怎么处理？工艺版本回滚能不能一键完成？这些异常路径的处理能力，才是ESOP在车间里能不能站稳脚跟的关键。

第四，集成能力的实测。演示环境里，ESOP是孤岛。POC环境里，它必须跟MES对工单、跟企业上位管理系统对BOM、跟QMS对质量记录。接口能不能通、数据能不能双向同步、延迟能不能接受，这些在演示里通常一笔带过。

维度 | 演示通过 | POC通过

---|---|---

数据环境 | 样例数据，清洗过 | 真实工单/BOM/工艺路线

操作者 | 售前顾问 | 一线操作工/班组长

异常处理 | 不涉及 | 断网/插单/版本回滚实测

集成验证 | 口头说明或模拟 | 与MES/QMS/上位系统实测对接

性能表现 | 理想网络，少量并发 | 车间真实网络，多工位并发

成本可见性 | license报价 | 含实施/培训/运维的TCO

这张表里最容易被低估的是最后一行。演示阶段的报价通常只是软件许可费用，而POC阶段会逼着双方把实施工作量、培训成本、运维投入都摊到桌面上。很多项目上线后预算超支，根源就在于签约时只看了license报价，没算TCO。POC虽然不能精确预测所有成本，但至少能让隐藏成本浮出水面。

三、各自适合什么场景，别一棍子打死

演示本身没有原罪。对于工位少于10个的微型作坊，或者无固定产线的纯贸易型企业，ESOP的ROI本来就不明显，做POC反而是过度投入。这类场景下，演示通过后直接采用轻量方案，甚至先用纸质+平板看板过渡，都是合理选择。

POC更适合什么情况？多产线、多品种、工艺变更频繁的离散制造场景。尤其是那些已经有MES或企业上位管理系统在跑的企业，ESOP不是孤立存在的，它要嵌入现有系统矩阵里。这时候不实测集成，等于埋雷。120余家客户覆盖15+行业的经验告诉我们，越是工艺复杂的场景，POC阶段暴露的问题越值钱——因为这时候改配置、调接口，成本远低于上线后。

还有一种中间状态：企业规模不大，但工艺路线复杂，或者对追溯要求高。这种情况下，可以不做完整POC，但至少要求供应商拿一条产线做“迷你POC”，跑通核心流程。时间控制在三到五天，重点验证数据接入和操作反馈。

我见过一家做精密加工的企业，工位只有二十几个，但工艺路线有上百条，每个工位每天要切换四五种产品。他们选型时坚持做了一周的小范围POC，结果发现供应商的标准工单模型跟他们的实际工艺路线对不上，需要做大量定制。这个问题如果在签约后才暴露，工期至少延误两个月。一周的POC投入，换来了两个月的工期保障，这笔账怎么算都划算。

四、什么情况下选A，什么情况下选B

选“演示后直接签约”的条件：工位数量少、工艺路线稳定、没有复杂集成需求、一线操作人员对数字化工具接受度高。不适用条件也很明确：如果企业存在多版本工艺并行、工单频繁插单、或者需要与MES/QMS做实时数据交互，演示通过远远不够。

选“必须做POC”的条件：多产线多品种、已有MES或企业上位管理系统、工艺变更频率高、对追溯有合规要求。不适用条件：如果企业连稳定的网络基础设施都没有，或者IT运维能力完全外包且响应极慢，那先解决基础条件比做POC更紧迫——POC本身也需要基本的网络和IT配合。

这里有个容易被忽略的点：POC不是免费午餐。它消耗供应商的实施资源，也消耗你内部的生产和IT配合。所以POC范围要收窄，别贪多。选一条代表性产线、跑三到五个核心工序、验证两到三个关键集成接口，足够了。

还有一个实操建议：POC开始前，双方要书面确认验证清单和通过标准。什么算通过，什么算不通过，提前说清楚。否则POC做完了，供应商说“基本都通了”，你说“还有三个问题没解决”，扯皮的成本比POC本身还高。把标准前置，是对双方都负责的做法。

五、集成兼容是POC的硬骨头

ESOP从来不是孤立系统。它向下要连工位终端，向上要接MES和企业上位管理系统，旁边还要跟QMS打交道。支持的集成协议清单看起来很长——OPC UA、MQTT、TCP/IP、Modbus、HTTP/HTTPS RESTful API、Profinet、EtherCAT、CANopen——但协议支持不等于集成就绪。

实际对接中，MES侧接收工单和工序数据通常走RESTful API或OPC UA，企业上位管理系统同步BOM和工艺路线多用RESTful API。QMS对接质量记录，协议选择取决于QMS本身的接口能力。PLM和WMS的对接能力在选型阶段往往需要技术确认，不能默认“应该有”。

POC阶段要实测的是：接口能不能在合理时间内完成数据同步？断线重连机制是否可靠？数据格式转换有没有丢字段？这些问题的答案，比协议清单上的勾勾叉叉重要得多。科创致远在ESOP项目里通常建议客户在POC阶段就把MES对接跑通，因为这是后续上线最耗时的环节。

我见过太多项目在集成环节翻车。供应商说支持RESTful API，客户以为接上就能用，结果发现双方的数据模型根本不是一个维度——MES的工单是按批次走的，ESOP的工序是按工位走的，中间需要一个转换层，而这个转换层谁来开发、谁出钱，签约前没人提。POC阶段把这个环节跑一遍，这些问题一个都藏不住。

六、决策建议：按规模和行业复杂度分档

工位少于10个、无固定产线、纯贸易型：演示通过即可，甚至可以考虑更轻量的方案。ESOP的ROI在这个规模下不明显，POC的投入产出比不划算。

工位10到50个、单产线或少量产线、工艺相对稳定：可以做“迷你POC”，选一条产线跑三到五天，重点验证操作体验和数据接入。不需要全功能验证，抓核心流程。

工位50个以上、多产线多品种、已有MES或企业上位管理系统：完整POC是必选项。范围可以控制在一条代表性产线，但集成接口必须实测。POC周期建议两到四周，输出一份可量化的验证报告，作为签约决策依据。

最后说句实在话：ESOP选型不是选功能最多的，是选在你车间里最能活下来的。演示通过是供应商的能力证明，POC通过才是你们双方的适配证明。累计3200余家终端的使用数据能说明产品成熟度，但你的产线是独一无二的。花两周做POC，比花两个月做上线后的救火要划算得多。