签约前怎么验证 APS：先约好真实数据、排程约束和验收条件

先说结论

• 看演示或看一张排好的甘特图，不能证明 APS 适合您的工厂。试排要用双方确认的一批真实数据，并把关键规则、输入口径和例外情况固定下来。
• 试点开始前先写验收表：测试哪些场景、哪些结果必须满足、哪些指标只作对比、数据由谁准备、问题由谁确认，以及不通过时如何结束。
• 比较服务商时，让每一家使用同一份数据和同一组场景说明；要求对方展示输入、约束、结果和例外，不只展示最好看的结果。
• APSer-Aps 也应按同一套方法接受评估。本文给您的是可复用的核验办法，不以未经客户验证的效果数字替代试点证据。

如果您正在采购 APS，服务商演示通常能让您看到排程结果，却不一定能回答更关键的问题：工厂自己的缺料、换模、工装共用和急单插入，系统是否按约定处理？结果不理想时，双方能否说清是数据、规则还是模型的原因？

签约前安排一轮范围有限的试排，可以把这些问题提前摊开。试排应让双方使用同一组、可复核的数据，核验关键业务规则是否真实生效，并记录所有输入假设与结果。关于约束排程本身，可参见《从 Excel 排产到约束排程：门槛在数据、习惯和维护》和《排程为什么交给确定性求解内核，大模型只在外围工作》。

一、试点开始前，先把范围写成一张表

试点范围太大，问题容易互相推诿；范围太小，又可能恰好避开最难的业务规则。建议先选一条产线、一个瓶颈工序段或一类代表性订单，并把下面几项写清楚。

数据最好来自实际业务，但要遵守双方约定的数据授权和保密要求。可以脱敏客户名称、价格等无关信息；不能把会影响排程结果的数量、日期、工时和资源关系随意改掉，否则验证的就不是现场问题。

二、用同一组场景检查关键约束

排程模型需要把现场规则转成明确约束。Google OR-Tools 的 job-shop 示例将工序先后关系与设备同一时段只能处理一项任务列为基本约束，并把缩短总完工时间作为优化目标[1]。这说明了模型表达的一类问题；示例不包含您工厂的物料、换型、工装、班次等全部规则，具体数据和规则仍须现场确认。

仅看正常订单，常常发现不了系统最需要处理的差异。试点场景应从现场挑选，覆盖一两种正常排程，也覆盖容易出错的边界情况。

每个场景最好都有一张小卡片：输入是什么、想核实哪条规则、预期看到什么、实际结果是什么、差异由谁判断。预期结果不必事先规定每一张订单的精确开工时刻，但必须规定不能违反的业务事实，以及哪些取舍需要业务负责人确认。

三、先区分硬性验收与方案比较指标

试点指标可分两层。第一层是不能违反的条件，例如同一台设备不能同时加工两张订单、物料未到不能按约定规则开工、共用工装不能被重复占用。第二层用于比较不同方案，例如交期表现、换型次数、计划改动幅度和人工调整量。

硬性条件要明确到能逐项核对，不能只写「符合现场需求」。比较指标要先定计算口径和基线，例如「按哪一天的订单承诺日期计算」「缺料是看开工时还是看齐套时」「计划变动与哪一版计划对照」。如果双方对口径理解不同，试点后的数字就无法比较。

还应把限制写在结果旁边：数据不完整、规则尚未确认、某类例外未纳入时，结果只能说明当前范围内的表现。不能把一轮试排直接当成全厂上线效果，也不能把算法给出的可行解说成全局最优，除非服务商能说明相应的证明依据。

因此验收时要分别问两个问题：结果是否满足全部硬约束，优化目标是否已达到或有何差距。OR-Tools 文档展示了符合约束但总工期仍非最优的排程示例[1]。您可以要求服务商说明求解状态、目标值、停止条件，以及无法证明最优时如何报告当前解的边界。

四、比较服务商时，统一输入和展示要求

向候选服务商发同一份试点说明、同一组脱敏数据和同一套问题。要求每家按相同结构交付：

1. 数据与假设：哪些输入直接使用，哪些由服务商补齐或推定，缺失数据如何标出。
2. 规则对应表：业务规则对应哪些数据字段或系统配置，哪些规则暂时无法表达。
3. 场景结果：每个场景的输入摘要、排程结果、未满足条件和人工处理项。
4. 差异说明：与计划员现有方案有什么不同，差异是规则、数据还是目标权重造成的。
5. 试点边界：需要哪些接口、现场配合和后续实施工作，哪些属于另外报价。

报价也按同一范围拆开：软件许可或服务费用、数据整理、接口、定制、培训、维护与后续变更分别列明。对方不愿展示输入假设、只给结果截图，或把试点结果直接包装为收益承诺时，您应先要求补齐证据，再进入报价比较。

这套办法不要求每家使用相同算法，也不预设哪家一定胜出。它要求候选方案面对相同的业务事实，让差异可以解释、验收可以复核。APSer-Aps 作为我们交付中的排程产品，也应接受同样的真实数据、约束场景与验收口径。

五、把验收、维护和退出条件写进合作约定

签约前应把试点与正式交付的关系分开说明：试点通过代表什么，哪些内容仍须在实施阶段完成，正式验收需要哪些环境、数据和人员。至少把以下内容落到书面约定：

• 试点通过条件：哪些硬性约束必须全部通过，比较指标采用什么口径，未通过时如何记录和复核。
• 范围变更：增加产线、订单类型、接口或规则时，如何评估时间、费用与原验收标准的影响。
• 数据与成果：输入数据、试排结果、规则清单、配置和定制成果分别由谁保管，结束时怎样导出或删除。
• 接手与维护：上线后由谁确认规则变化、维护基础数据、受理故障和评估新增需求；响应时段和费用如何约定。
• 退出条件：试点延期、关键数据无法提供、硬性条件未通过或双方无法确认规则时，如何停止、结算已完成的工作并交回资料。

试点前先约好这些条件，遇到问题时双方就能依据记录讨论，而不是临时争论「结果看起来行不行」。关于系统上线后的责任划分，可继续阅读《系统上线之后，谁来对它负责》。

试点前检查清单

在启动试排前，您可以逐项确认：

• 试点只覆盖一段明确的产线或工序范围。
• 双方确认了数据快照、字段口径、脱敏方式与数据保管责任。
• 缺料、换型或工装、急单、停机等关键现场场景至少各有一个核验例子。
• 每项业务规则都标明「必须满足」或「参与权衡」，并有确认人。
• 验收条件能逐项核对，比较指标有一致的计算口径和基线。
• 服务商提交输入假设、规则对应、场景结果和异常说明，而不只是演示截图。
• 报价拆分到软件、实施、接口、定制和维护范围。
• 试点不通过或无法继续时的退出、结算和资料交接方式已书面约定。

试点的价值不在于尽快得到一张漂亮的计划，而在于尽早发现双方对数据、规则和责任的理解是否一致。把这些分歧留在签约前，远比上线后再追问「当初说的能不能做到」更容易处理。

参考来源