2018 年我陪一家做家居用品的客户去看 WMS 演示，演示室里一切完美：扫一个条码，波次秒出，拣选路径漂亮得像教科书。客户老板当场点头，说就它了。9 个月后上线第一周，这个仓的日均订单积压到了 6000 多单，老板在仓库里冲我吼：演示的时候怎么都好好的？
我怎么回答？演示的都是假的。
供应商的演示环境是排练了无数次的剧本：数据是清洗过的，流程是挑过的，操作的人是实施顾问本尊。把这个剧本直接搬到你家仓库——每天几百个散件、缺货、混放、换标签的真实世界——翻车是必然的。今天这篇只讲一件事：POC 怎么做，才能在签合同之前把坑挖出来。
演示是个剧本，别当真
先讲三个最常见的演示把戏，你下次看演示可以对着核对。
第一，预置数据。演示库里只有 500 个完美 SKU，每个都有条码、有批次、有明确库位。你家仓库呢？可能有 2 万个 SKU，里面混着没条码的、包装破了的、一个托盘上三批混放的。演示的时候系统当然快，因为它根本没见过脏数据。
第二，绕开难场景。销售演示永远演示"收货-上架-拣选-复核-发货"这条阳光大道。你问退货怎么走？他说可以配置。你问序列号追溯？他说支持。这两个"可以""支持"，在实施阶段通常要再掏一笔定制开发的钱。敢不敢让他在演示现场，用你的退货流程走一遍？大部分不敢。
第三，演示的人不对。给你演示的通常是售前或资深实施顾问，对系统熟到闭眼都能操作。真正上线后给你做实施的，是另一拨人，可能是刚培训完三个月的新人。演示的顺滑程度和你未来的实施质量，基本没有关系。
写 POC 脚本：用你自己的数据，跑你自己的流程
POC 的核心就一句话：把演示的主动权从供应商手里抢过来。
你先写一份 POC 脚本，不超过 10 个场景，全部来自你家仓库过去三个月真实发生过的单子。我的建议清单：正常收货上架、整托收货带破损、紧急插单波次、缺货转单、序列号商品退货、混托盘拆零补货、盘点差异调整、换标签重打。每个场景配真实数据：拿你真实的 SKU 主数据（至少 2000 个，含那些难搞的），拿你真实的一周订单。
然后定死规则：供应商不许用预置数据，必须现场导入你的数据跑；操作的人必须是你指定的仓库主管，不是他们的顾问手把手代劳；每个场景计时。
这一条"不许代劳"最关键。我见过太多 POC 现场，供应商顾问站在操作员身后，一步一步口述，鼠标都快替他点了。这测出来的是顾问的水平，不是软件的水平。让你们家文化程度最低的那个主管去点，他能学会，这系统才算好用。
数据准备有个实操细节：真实数据要脱敏（客户名称、价格字段抹掉），但 SKU 编码规则、批次逻辑、库位结构必须原样保留。脱敏后的数据至少提前一周发给供应商做导入，POC 当天才第一次见数据的，十有八九会以"数据格式问题"为借口要求改期——这一周的缓冲期，就是用来戳破这个借口的。另外，订单量别给太少：我一般要求至少覆盖一天的真实单量，几十单的 POC 测不出波次和并发的问题，纯属自我安慰。
通过线要量化，别谈感觉
POC 结束开会，千万别问大家"感觉怎么样"。感觉是最不靠谱的验收标准。
提前写好通过线，写在 POC 脚本第一页，供应商签字确认。比如：8 个场景里至少 7 个在无人指导下一次跑通；波次释放 500 个订单的响应时间在 2 分钟以内；盘点差异调整全程不超过 5 步点击；你们主管独立操作 2 小时不出错。
达不到怎么办？两条路：供应商承认要定制开发，给出书面工作量和报价；或者直接淘汰。最忌讳的是"我们回去研究一下"——这句话翻译过来就是"现在做不到"。
还有一个狠招：POC 期间把你们的 IT 叫来，让他看数据接口。WMS 将来要和 ERP、TMS、电商平台对接，API 文档全不全、有没有沙箱环境，半天就能看出来。接口烂的系统，实施阶段会把你拖死。
签约前最后问三句话
POC 通过了，准备签约。签之前把这三句话问清楚，写进合同附件。
第一句：演示里跑通的场景，上线时如果跑不通，定制开发费用谁出？很多合同里实施费是"预估"，超了另算。把 POC 通过的场景清单作为验收标准写进去，跑不通就是供应商的责任。
第二句：实施团队是谁？把核心顾问的名字写进合同，换人要经过你同意。别让销售口头承诺"我们派最好的团队"，口头的不算数。
第三句：上线后前 90 天的响应时效。系统刚上线一定出问题，关键是供应商多久能到场。写死：严重故障 4 小时内远程介入，24 小时内到场。顺带把实施超期的违约责任也谈了——很多项目一拖就是半年，合同里没有超期条款，你一点办法都没有。
回到开头那个家居客户。后来他们换了一套系统，第二次选型我让他们做了整整三周的 POC，用真实数据跑了 200 多个真实订单。第二套系统上线当天，仓库只加班了 2 小时。老板后来跟我说，早知道第一次就该这么折腾。
POC 不是走过场。它是你签合同之前，唯一一次让供应商用真本事干活的机会。别浪费了。
