假设有一张工单，要做100件产品。

车间已经报工80件，系统看板上写着：进度80%。

这个数字没错。可是，如果客户现在问：“周五能交80件吗？”你敢直接答应吗？

先别急。80件里，有20件还在等终检。检验通过的60件里，只有50件完成了入库。至于这50件有没有被别的订单占用，还得继续查。

同一张工单，此刻至少有三个都算得对的数字：工序完成80件，检验合格60件，已经入库50件。把它们都叫“完成数量”，麻烦就来了。

图1：报工、检验与入库数量（示意，非产品截图）。

你可能会说，这不是数字口径的问题吗？跟选MES有什么关系？

几家厂商演示时，都能下发工单、扫码报工、做质量检验、显示生产看板。你看到的是同一组动作，自然觉得都差不多。可同样叫“进度”的数字，取的未必是同一步的数据。

它可以按末道工序报工计算，也可以按检验放行计算；成品入库又是另一个节点。界面上都写着“完成率”，演示当然容易长得一样。等计划员拿这个数答复客户，差别才显出来。

所以我更建议换个问法。别问“你们有没有生产进度看板”，问：“看板上的80%，到底是哪一步完成了？剩下的20件在哪里？已经做出来却不能交的，又卡在什么地方？”

如果系统答不上来，再漂亮的大屏也帮不了你催交期。

当然，不能把“周五能不能发货”整个问题都推给MES。MES该说清车间做到了哪一步；仓库是否有可用库存、订单是否已经锁货、运输能否赶上，往往还要结合ERP、WMS等系统和实际安排。好的演示不该假装一套系统无所不知。它至少应该把自己知道什么、不知道什么，交代清楚。

这也是为什么，选型时最好少看一轮厂商准备好的样板数据，多拿一张自己工厂的工单出来。

把客户和价格等敏感信息隐去，留下产品、工艺路线、计划数量，以及一次确实发生过的报工和检验记录。让入围厂商用同一份资料回答同一个问题：这张订单现在做到了哪里，哪些数量可以进入下一步，哪些还不能？

注意，不是让顾问在PPT里讲“系统可以实现”。请他打开系统，一步步把数字点出来。80件怎么来的，20件待检是谁记录的，检验不通过的产品后来去了哪里。查到最后，如果现场记录根本没有采集，厂商也应该直说，而不是靠一个总数猜答案。

到这儿，第一层差别就出来了：那80、60、50件，系统能不能找到各自的原始记录？找不到，就只是把一张表里的总数搬到了另一张屏幕上。

还有一个容易漏掉的问题：它记的是整张工单的数量、一批产品的数量，还是每一件产品的状态？

如果产品只需要按批次管理，要求员工每做一件都单独扫码，可能徒增工作量。但如果客户要求按序列号追溯，系统里只有“本工单合格60件”这一个总数，等出现质量问题，你就找不到具体是哪几件、用了哪批料。不是追溯页面做得不够漂亮，是当时没有把需要追的关系记下来。

但还没完。

假设那10件已经检验合格、还没入库的产品里，有5件后来被质量部门要求复检。昨天的报表已经发出去了，今天才发现问题。现在要把这5件暂时拦住，系统会怎么做？

直接改掉昨天的合格数，看上去最快。可再过一周，有人追问为什么昨天说合格60件，今天却有5件不能入库，你拿什么解释？

更稳妥的处理，是保留昨天发生过的检验结果，再记录今天是谁、因为什么原因要求复检，当前哪些产品不能继续流转。具体审批和放行规则由企业自己决定，系统要做的是让这些决定有据可查。

这时你看的已经不只是一个“质量模块”。质量员把5件挂起后，原来10件待入库产品里，只剩5件能继续入库。仓库的待入库任务不能照旧收10件，计划员也得看见这个变化。如果三个页面各算各的，后面仍然得靠电话对账。

图2：复检后的数量状态（示意，非产品截图）。

不少系统在顺着流程走时都很流畅。工单下发，报工，检验，入库，一路点到底。可工厂里的信息经常是事后才补齐的。返工判定改了，检验结果复核了，仓库发现批次不对，又得往回找。历史记录能不能保留，错误能不能按权限纠正，纠正后会影响哪些数量，这些往往比“提交”按钮更能说明系统合不合适。

再往深一层，还有一笔容易被忽略的账。

同样一个演示动作，背后可能是现成功能，也可能要调整配置，还可能是为这次项目单独开发。今天看起来只差几次点击，明年工艺变了、质量规则调整了，维护成本可能完全不同。

所以，当厂商说“这个我们能做”，别急着在选型表里打钩。接着问一句：“刚才这一段，在你们当前版本里是怎么实现的？如果我们的放行规则改了，谁来改、改多久、会不会影响已有记录？”

这句话同样适用于低代码方案。比如织信可以用数据模型、流程、权限和接口能力搭建MES，适合需要持续调整业务规则的企业。但“平台能搭”与“这套MES已经适合你们车间”，不是一回事。它也要拿同一张工单、同一套数量口径来验证，还要算清楚建模、实施和后续维护由谁承担。

反过来，如果一家工厂的生产方式比较稳定，某个成熟MES的标准流程刚好覆盖主要业务，少改动、早上线，可能更划算。选型没有必要先站队。

我会把最后一轮演示留给真正使用系统的人。让计划员问一次交期，让操作员报一次数量，让质检员处理一次待检，让仓库核对一次入库。不要他们站在旁边看顾问操作，而是让他们自己上手。

如果这套流程只在熟练顾问的电脑里成立，换到车间就要靠电话、微信群和Excel补答案，问题并没有解决，只是换了个地方发生。

试点也不用一上来铺满全厂。挑一类有代表性的产品和一小段可核对的生产过程，先跑通，再拿纸面记录与系统结果对账。哪些数据没有采到，哪些规则是企业自己还没定，哪些地方是厂商产品确实做不到，分别写清楚。前两类问题，换一家厂商也不会自动消失；后一类，才是你真正要比较的产品差异。

比较结果时，也别只写“支持”或“不支持”。当场跑通的、调配置才能做的、需要开发的、必须由其他系统提供数据的，分别记下，再问清实施时间和费用。选型会上终于能讨论同一件事，而不是比较谁讲得更自信。

图3：同题演示的核验问题（示意，非产品截图）。

看完几家MES演示，觉得差不多，很正常。因为大家都在展示自己最顺的一条路。

真正该带进选型会的，不是更多功能名称，而是一张你们自己的工单，和一个必须有人回答的问题。 一件产品，从“做了”到“能交”，中间每一步是谁确认的？

谁能把这件事讲清楚、做出来，并且让你们的人以后也能继续用，谁才值得进入下一轮。