物料齐套这四个字，在制造现场的分量比很多宏大词汇都重。计划员在群里发一句“明天这条线能不能开”，仓库回“还差两个料”，采购回“在途”，品质回“在检”，最后产线停在那儿，一天几十万的产值就在等待里蒸发掉了。物料齐套高效模型，说白了就是把“到底齐不齐、什么时候齐、缺哪一项、缺多少、谁来补”这几个问题，从每天早上的人肉对表，变成系统里秒级刷新、能追责、能预警的一套机制。这是数字化工厂建设里绕不开的关键要素，因为计划排得再漂亮、设备联网率再高、看板做得再炫，只要料不齐，一切都是空转。这篇内容面向三类人：正在做工厂数字化规划、被要求“上个齐套看板”的负责人；每天手工拉Excel算缺料的计划与物控人员；以及负责把业务逻辑翻译成数据模型的开发与实施同学。我会按业务定义、数据地基、算法内核、工程落地、踩坑排查、参数调优的顺序往下拆，尽量把每一步“为什么这么干”讲清楚，让不同基础的人都能拿走能直接用的东西。
1. 先把“齐套”定义清楚，否则模型必然跑偏
1.1 齐套不是“库里有料”，而是时间、数量、品质三件事同时成立
很多团队一上来就写代码，结果做出来的东西没人用，根子往往在定义没对齐。齐套真正的含义是：在某个明确的时间点，为完成某个明确的生产对象，所需的全部物料在数量、时间、品质状态上都满足要求。三个限定词缺一不可。
只算数量，就会出现“账上有料但还在供应商车上”的假齐套；只算时间，就会出现“明天到货但明天早上八点就要上线”的错位；只算库存不筛品质状态，就会把待检、冻结、不合格品算成可用资源。我见过一家做五金结构件的厂，系统里齐套率常年显示96%，产线实际停机等待的比例接近三成，后来一查，他们的齐套计算直接把“待检区库存”当成了可用库存，而这家厂的来料检验平均要压两天。指标好看，现场照停，这就是定义没做实的代价。
所以建模之前，我建议先把这句话写在需求文档第一页：齐套 = 在需求时间窗口内，扣掉一切不可动用部分后，可用供给能够覆盖的需求数量。后面所有的表结构、取数逻辑、预警规则，都要能回溯到这句话上。定义一旦含糊，开发和业务后面会无休止地扯皮，而且扯不清楚，因为双方心里的“齐套”根本不是同一个东西。
1.2 三种口径各管什么：按工单、按订单、按产线节拍
实际项目里至少存在三种齐套口径，它们服务不同角色，不能混用，也不能只做一个。
按工单齐套，是最常用的一种，对象是生产工单，判断这张工单需要的物料是否都能在开工时间前到位。它服务于车间执行层，回答“这张单能不能开”。优点是颗粒度清晰、责任明确，缺点是对多工单争抢同一批库存的情况不敏感，容易出现两张单都显示齐套、真开工时只有一张能开。
按订单齐套，对象是销售订单或客户订单，把订单下的所有工单汇总后再判断。它服务于销售和计划层，回答“这个客户能不能按期交付”。这种口径会把共用料的需求叠加，更接近真实交付风险，但计算量大，且一个订单跨多个车间时归责困难。
按产线节拍齐套，对象是某条线某班次要生产的全部品种，按上线顺序逐小时推演。它服务于精益排产，回答“这条线今天几点会停”。这种口径最贴近现场，也最难做，因为它依赖精确的工序节拍、换型时间和批次流转数据。
我的经验是分三期落地：一期先做按工单，把数据链路和基础算法跑通；二期叠加订单口径，给销售和管理层用；三期再做节拍级推演，和排产系统联动。指望一步到位做出节拍级齐套，往往在数据质量那一关就阵亡了。
1.3 齐套模型在数字化工厂里的位置：它是连接器，不是孤岛
很多厂把齐套当成WMS或者MES的一个小功能，这个定位会害了它。齐套模型的本质是一个横向连接器，它同时吃ERP的订单与BOM、采购的到货计划、仓库的实时库存、品质的检验状态、生产的工单进度，输出给排产、车间执行、采购跟催、销售承诺四个方向。
它的数据流向大致是：主数据与BOM从上游系统同步，需求由生产工单和销售订单生成，供给由库存快照与在途在制数据汇总，计算引擎按时间切片做匹配，结果落地成齐套结果表和缺料明细表，再推给看板、消息和排产接口。任何一个环节的数据延迟，都会让齐套结论失真。所以做这个模型，本质上是在做一场数据治理，算法只占两成工作量，另外八成在打通与清洗。想清楚这一点，项目排期才不会定得那么天真。
2. 模型地基：主数据不干净，算法再花哨也是白搭
2.1 BOM展开里最容易翻车的四个点
BOM是齐套计算的分母，它错了，后面全错。实际项目里出问题最多的有四处。
第一处是虚拟件。虚拟件在物理上不存在，只是工程管理的分组节点，展开时必须穿透到它的子件，绝不能当成一个真实物料去要库存。我见过系统把虚拟件当成采购件挂在那里，导致每张工单都显示缺这个料，缺了半年没人发现。
第二处是替代料与替代组。A料和B料可以互换，计算时要按替代组聚合供需，不能各算各的，否则会出现A缺B呆的荒唐结论。替代关系还分单向和双向、完全替代和部分替代，建模时必须把替代比例和优先级一起考虑进去。
第三处是损耗率与单位换算。注塑、冲压、线束这类行业，损耗率动辄3%到8%，如果齐套计算用的是净用量，上线时一定会差一点。单位换算同样坑人，采购按公斤、领用按米、BOM按卷，换算系数一错，缺口偏差就是数量级的。
第四处是可选件与配置件。按单配置的行业，同一产品型号下不同配置对应不同物料，必须用配置特征把BOM裁剪到具体工单，否则需求会被整体放大。这四点在建模初期就要定好规则，写成明确的展开算法说明，比事后打补丁省力得多。
2.2 库存可用量到底该怎么取
这是齐套模型里争议最大的一段。很多系统的做法是直接取库存现有量，然后被现场骂到不敢开看板。正确口径应该是：
可用量 = 现有库存 − 已分配给其他工单的预留量 − 冻结与待检数量 − 不良与待处理数量 − 安全库存 + 可确认的在途量。
每一项都有讲究。预留量是防止“抢料”的关键，没有预留机制，两张工单会同时把同一批库存算成自己的，齐套率必然虚高。冻结与待检必须扣掉，因为它们在物理上不可领用。安全库存要不要扣，取决于企业策略，我的建议是在齐套计算里扣掉，但在报表里单独展示“若动用安全库存可提升多少齐套率”，给决策留出弹性空间。
在途量更微妙。采购订单在途不能全信，要按供应商历史准时交付率打折，甚至按订单逐笔打不同的折扣。我们做过一个粗略但有效的处理：对每个供应商维护一个滚动准时率，把在途量乘以这个系数作为“可信在途”，同时对超过承诺交期仍未到货的订单标记风险等级。这套打折机制上线后，齐套率从虚高的94%回落到更真实的81%，一开始业务很不适应，但两个月后停线次数明显下降，因为他们终于开始按真实情况提前跟催了。
2.3 物料主数据的必备字段清单
齐套模型对主数据的依赖很具体，不是“数据要干净”这种空话，而是要有明确字段。下面这张表是我在多个项目里沉淀下来的最小字段集，缺哪一项，模型就会在对应环节出偏差。
| 字段类别 | 关键字段 | 缺失后果 |
|---|---|---|
| 基础属性 | 物料编码、名称、基本单位、物料类型 | 无法区分采购件、自制件、虚拟件 |
| 计划属性 | 采购提前期、检验周期、最小起订量、批量倍数 | 需求时间倒排失真 |
| 库存属性 | 安全库存、ABC分类、是否批次管理 | 可用量计算口径错乱 |
| 质量属性 | 检验方式、免检标志、保质期 | 待检品被误算为可用 |
| 替代属性 | 替代组编号、替代优先级、替代比例 | 替代料无法聚合 |
| 用量属性 | 损耗率、换算系数、固定用量与变动用量 | 需求量偏差 |
这张表看着朴素，但每一条都是被现场教出来的。比如“是否批次管理”这一项，如果不区分，先进先出的分配逻辑就没法落地，齐套算出来的数量到了拣货环节会被批次规则推翻。再比如固定用量与变动用量，某些工艺辅料是按工单固定消耗的，不随产量变化，混在变动用量里算，小批量工单会严重虚缺。主数据梳理这活儿枯燥、费时、不出彩，但它是唯一没有捷径的部分。
3. 算法内核：从需求展开到缺口判定的完整链路
3.1 需求侧：把“哪天要”变成“哪一刻要”
齐套计算的时间精度决定了模型的实用价值。按天算，只能回答“明天齐不齐”，现场需要的是“明天早上八点这条线开得了吗”，这中间差着一个班次的准备时间。我的做法是把需求时间倒排到“上线时刻”，再往前推三段：备料时间、检验时间、到货缓冲。
具体算法是：上线时刻 − 备料提前期 = 需求可用时刻；需求可用时刻 − 检验周期 = 要求到货时刻；要求到货时刻 − 供应商运输天数 = 要求发货时刻。这条时间链条上的每一段都要从主数据取，不能拍脑袋估。对于共用料，同一物料在不同工单上的需求时刻不同，必须逐条保留时间标签，不能简单汇总，否则早期需求会被后期需求稀释，出现“总量够但当时不够”的误判。
时间切片还有一个隐藏难点：时区与班次。跨班次生产的企业，一天可能有两到三个班次，班次之间的物料交接规则不同。我们在一家两班倒的厂里就吃过亏，系统按自然日聚合，结果夜班开线的需求被算到了第二天，齐套结论整整晚了一个班。后来改成按班次切片，问题才解决。这类细节不看现场是想不到的，所以建模阶段一定要去车间蹲两天。
3.2 供给侧：三个池子和各自的打折系数
供给侧的建模思路是把所有可能的来源分成三个池子，分别赋予可信度。
第一个池子是现有可用库存，可信度最高，但必须按2.2节的口径做过扣减，并且要考虑批次、库位、是否在同一个物理仓库。跨仓调拨需要时间，不能当成即时可用。
第二个池子是在途采购，包括已下达未到货的采购订单、委外加工回收、供应商寄售库存。这个池子的可信度需要用历史准时率打折，同时对超期订单单独标记。
第三个池子是在制与预计产出，包括生产工单的预计完工量、半成品库存、返工可修复量。这个池子最不可靠，一般只对自制件启用，并且要乘以一个完工可信系数。
三个池子合并时要注意去重。同一批物料可能既是库存又在途（比如部分到货），需要有清晰的到货登记机制来消除重复计算。我们曾经因为部分到货没有回写，把同一批料算了两遍，齐套率虚高了好几个点，产线连停三天才定位到。这类问题不是算法错，是数据流没闭环，所以供给侧的建模重点其实在单据流转的严谨性上。
3.3 木桶原理：齐套数量与齐套率的正确算法
一张工单能不能齐套，取决于它最缺的那一项，这是典型的木桶效应。算法上就是：
工单可齐套数量 = MIN（各物料可用供给量 ÷ 该物料单位用量），对所有必用物料取最小值，再向下取整到工单批量的整数倍。
这个公式简单，但里面的坑不少。首先是除零和用量为零的物料要排除；其次是必须区分必用件和可选件，可选件缺失不应阻断齐套；再次是取整规则要和工单批量对齐，比如工单是100台一批，算出可齐套87台，实际意义是“一台都开不了整批”，这时候指标应该体现为“缺口13台的物料”，而不是简单报个87。
齐套率则要分两个指标同时看：工单齐套率 = 完全齐套工单数 ÷ 计划工单总数；物料项齐套率 = 已齐套物料项数 ÷ 总物料项数。前者反映整体健康度，后者反映缺料集中度。只看前者，会掩盖“只差一个料但全线停摆”的情况；只看后者，会掩盖“大部分工单都差一点点”的系统性风险。我的看板上这两个数字永远并排显示，再配一个“缺料工单的缺料项数分布”，管理者一眼就能判断是普遍性缺料还是个别卡点。
3.4 分配策略：先到先得、优先级优先还是公平分摊
当供给不足以覆盖全部需求时，怎么分配直接决定了齐套结果的合理性。常见三种策略。
先到先得，按需求时间排序，早的优先拿料。优点是简单、可解释，符合直觉；缺点是紧急插单没有空间，大客户订单可能被小订单挤掉。
优先级优先，按工单优先级、客户等级、订单金额排序。优点是保障重点，缺点是低优先级订单可能长期饿死，形成呆滞。
公平分摊，按各工单需求比例分配有限供给。优点是相对公平，缺点是所有订单都齐套一半，一个都交付不了，实际最糟糕。
我一般推荐混合策略：先按优先级分层，同层内按需求时间排序，同时对每层保留一定比例的机动量给插单。这个机动比例是个经验参数，通常在5%到15%之间，订单波动大的行业取高值。另外一定要做“分配快照”，即每次分配的结果要落库留痕，否则事后追责时说不清当时为什么把料给了A单没给B单。这个留痕功能看起来不起眼，但在跨部门扯皮时是唯一的裁判依据。
3.5 落到表结构和SQL：一个能跑起来的最小实现
概念讲完，给一段可以直接参考的实现。核心是三张表：需求明细表、供给汇总表、齐套结果表。
-- 需求明细：工单 × 物料 × 需求时刻 × 需求量 CREATE TABLE req_detail ( work_order VARCHAR(32), item_code VARCHAR(32), need_time DATETIME, req_qty DECIMAL(18,4), is_optional TINYINT DEFAULT 0, -- 0必用 1可选 sub_group VARCHAR(32) -- 替代组 ); -- 供给汇总：物料 × 可用时刻 × 可用量 CREATE TABLE sup_pool ( item_code VARCHAR(32), avail_time DATETIME, avail_qty DECIMAL(18,4), src_type VARCHAR(8) -- STK库存 PO在途 WO在制 );齐套计算的核心SQL按工单聚合，取最小覆盖率：
WITH req AS ( SELECT work_order, item_code, sub_group, SUM(req_qty) AS need_qty FROM req_detail WHERE is_optional = 0 GROUP BY work_order, item_code, sub_group ), sup AS ( -- 只取需求时刻之前可用的供给，并做可信度打折 SELECT r.work_order, r.item_code, COALESCE(SUM(s.avail_qty), 0) AS supply_qty FROM req r LEFT JOIN sup_pool s ON s.item_code = r.item_code AND s.avail_time <= (SELECT MIN(need_time) FROM req_detail d WHERE d.work_order = r.work_order) GROUP BY r.work_order, r.item_code ) SELECT work_order, FLOOR(MIN(supply_qty / NULLIF(need_qty,0))) AS kitted_qty, MIN(supply_qty / NULLIF(need_qty,0)) AS coverage_ratio FROM sup GROUP BY work_order;这段SQL只覆盖了单层逻辑，真实环境还要处理替代组聚合、多层BOM展开、在途打折。但结构是清楚的：先算需求，再算供给，最后取最小覆盖率。替代组的处理方式是把同一sub_group内的需求先合并、供给先合并，再回填到各物料，避免重复计算。这套写法在千万级明细上跑起来会有压力，性能优化放到下一节讲。
4. 工程落地：从每天跑一次到分钟级预警
4.1 数据链路怎么搭，刷新频率怎么定
齐套模型的数据链路有两条路可选：一条是从各业务系统直接抽数到计算库，另一条是走统一的数据中台。前者快、轻，适合单厂区、系统少的情况；后者规范、可复用，适合多厂区、多系统。
我倾向于分阶段：一期直接抽数，用调度任务每天凌晨全量+每小时增量，先把模型跑出价值；二期再往数据中台迁移，做成服务化。
刷新频率上，全量计算一般放在生产低峰期，比如凌晨两点；增量计算按小时或按事件触发，比如采购到货登记、检验放行、工单变更这三类事件发生后触发局部重算。这里有个关键设计：不要每次都全量重算，那样既慢又没必要。做成“脏工单标记”，只重算受影响的工单，能把单次计算时间压到原来的几十分之一。
还有一个容易被忽略的点是库存快照的时间戳。如果库存数据是每小时抽一次，但齐套计算用的是两小时前的快照，结论就会滞后。要在结果表里带上数据截止时间，并在看板上明示，避免使用者拿一个过时的结论去做紧急决策。这个小小的透明度设计，能省掉大量“系统不准”的投诉。
4.2 性能优化：把两小时压到四十秒的实操记录
某电子装配项目一开始的全量齐套计算要跑接近两小时，业务完全没法接受。优化过程大概是四步，效果是叠加的。
第一步，砍掉无效计算范围。只算未来30天内要开工的工单，历史工单和远期预测不进计算池，数据量直接降了七成。
第二步，把BOM展开结果预物化。多层BOM的递归展开是最耗时的部分，改成每天全量物化一次，白天增量维护，计算时直接查展开结果表，省掉大量递归。
第三步，加索引与分区。需求表和供给表都按物料编码加索引，按时间做分区，联合查询的扫描量明显下降。
第四步，把逐行循环改成集合运算。原先的存储过程里有大量游标遍历工单，改成批量SQL加临时表关联，这一步收益最大。
四步做完，全量计算从118分钟降到6分钟，增量计算稳定在40秒以内。这个数字带来的直接好处是刷新频率可以从每天一次提到每小时，甚至关键时段十五分钟一次，齐套结论真正具备了指导现场的能力。我想强调的是，性能优化不是靠换硬件，而是靠想清楚“哪些数据真正需要参与计算”，大部分慢的系统都在算不必要的数据。
4.3 看板、预警与责任到人
齐套结果出来了，如果只是躺在报表里，等于没做。要让模型产生价值，必须做到三件事：看得见、追得到、推得动。
看得见是指看板要分角色。计划员看“未来七天缺料工单清单”，按缺料项数排序；采购员看“按供应商聚合的缺料明细”，直接对应到自己跟的供应商；仓库看“待检待上架清单”；车间主任看“本车间今日开工工单齐套状态”。同一个数据，切四个视角，每个人看到的都是和自己有关的。
追得到是指每条缺料记录必须带四个要素：缺什么、缺多少、什么时候要、卡在谁那里。缺料原因要分档，是采购未下、供应商未发、在途延误、检验未放、账实不符还是需求变更。分档之后才能统计出主要矛盾，否则永远是“什么都缺一点”。
推得动是指预警分级。我的做法是三级：红色表示三日内必需物料缺口且无可靠在途，直接推给部门负责人；黄色表示三到七日缺口，推给责任人跟催；绿色表示有缺口但已有明确到货计划。分级阈值按行业调整，但一定要有，全部红色等于全部不红。
另外加一个机制：缺料单的关闭必须由系统校验，不能人工点“已解决”。只有实际到货登记或需求变更生效后，缺口才自动消除。这条规则看着严苛，但它是防止数据腐烂的关键。
4.4 和排产联动：缺料驱动的调序与插单
齐套模型最高阶的用法，是把结论反哺给排产。做法是把每张工单的“可齐套数量”和“齐套时刻”作为约束输入排产引擎，让排产不去排那些明知要缺料的工单，或者把齐套早的工单往前调。
这个联动要小心，不能全自动。因为排产还受产能、模具、人员、客户承诺多重约束，单纯按齐套调序可能把产能排成碎片。我的建议是做成“建议+确认”模式：系统给出调序建议和理由，计划员一键采纳或否决，否决原因要记录，用于后续优化规则。
我们在一家注塑厂做过这个联动，效果是把因缺料导致的换型浪费降了不少。原来经常是排好的单开不了，临时换另一个产品，换模时间白白浪费；有了齐套约束之后，排产阶段就避开了高风险工单，临时换型的次数明显下降。这个功能的技术门槛其实不高，难的是业务方愿不愿意把排产权交一部分给系统，这属于管理问题不是技术问题。
5. 踩坑实录：齐套率虚高与虚低的排查表
5.1 虚高的五种典型情况
齐套率虚高是最危险的问题，因为它让人误以为一切正常，直到停线才发现。我总结出五种高频原因。
一是待检库存被算进可用量。来料检验周期长的企业尤其严重，账面库存充足，实际在待检区压着。
二是预留机制缺失，多张工单重复认领同一批库存。系统里每张单都显示齐套，实际只够一张。
三是在途量未打折、未过滤超期订单。供应商明明已经逾期两周的订单还在被当作有效供给。
四是虚拟件未穿透，或者BOM版本用错。用旧版本BOM算需求，漏掉了新增物料。
五是单位换算错误。采购按箱、领用按个，换算系数写反或者漏乘，需求被严重低估。这五种情况我都遇到过，其中第二、第三种最隐蔽，因为数据看起来完全正常，只有交叉核对工单明细才能发现。
5.2 虚低的三种典型情况
虚低同样有害，会导致过度采购和紧急空运，白白抬高成本。
第一种是库位隔离。物料明明在仓库，但因为在另一个库位、另一个仓别，系统没有纳入可用范围。多仓企业常见。
第二种是批次与状态过滤过严。为了保守把所有非良品状态的库存都排除，结果把可返修的、可让步接收的也算成不可用。
第三种是需求重复计算。同一物料在多层BOM里被展开两次，或者工单变更后旧需求没冲销，导致需求虚增。虚低的问题排查起来更麻烦，因为它往往表现为“业务觉得该齐了系统说没齐”，需要拿着实物去对账。
5.3 问题速查表
下面这张表是我在实际项目里反复用到的排查清单，按症状反查原因，能省掉大量摸索时间。
| 症状 | 优先排查项 | 快速验证方法 |
|---|---|---|
| 齐套率突然大幅跳变 | 数据抽取是否失败、快照时间是否错位 | 对比前后两天的库存快照总量 |
| 个别物料永远显示缺料 | 虚拟件未穿透、物料类型配置错误 | 手工展开该工单BOM逐层核对 |
| 齐套工单实际开不了线 | 预留机制、待检库存口径 | 抽三张工单查明细可用量构成 |
| 明明有料显示无料 | 库位范围、批次状态过滤、单位换算 | 按物料编码查全部供给池明细 |
| 在途量明显偏大 | 超期订单未过滤、部分到货未回写 | 导出在途明细按超期天数排序 |
| 计算结果越来越慢 | 未做增量、BOM重复展开、缺索引 | 看执行计划，定位全表扫描 |
表里的“快速验证方法”都是能在一两个小时内完成的动作，不需要改代码。我的习惯是遇到问题先做这三步验证，确认是数据问题还是逻辑问题，再决定动哪里。很多团队一上来就怀疑算法，改了半天代码，最后发现是某张单据的状态没同步。
6. 参数调优与几个容易被忽略的细节
6.1 安全库存、采购批量与齐套率的三角关系
齐套率和库存周转是一对天生的矛盾体。安全库存设得高，齐套率好看，但资金占用大、呆滞风险高；设得低，周转漂亮，但停线概率上升。
我的处理思路是把安全库存从“一刀切”改成“按缺料影响度分级”。具体做法是给每个物料算一个缺料影响分，综合三个因素：该物料历史缺料频次、缺料导致的停线时长、是否有替代料。影响分高的设高安全库存，影响分低的甚至可以设为零，靠频繁补货。这个分级不需要多精确，粗分三档就够用，效果比全部按统一公式算要好，因为它承认了物料之间的重要性差异。
采购批量同样影响齐套。最小起订量大的物料，往往会一次性到货很多，短期内齐套率飙升，然后长期占用库存。这时候要看的是“齐套的时间分布”，而不是某一天的齐套率。我在看板上加了一个“未来四周齐套率预测曲线”，管理者能看到波动形态，而不是被一个瞬时数字误导。
6.2 替代料和替代组的建模细节
替代料处理不好，齐套结论会两头错。建个替代组是基础操作，但有几个细节必须处理。
替代优先级要明确。主料优先还是替代料优先，取决于成本和品质策略，不能默认。系统里要能配置优先级顺序，并在齐套计算时按序消耗。
替代比例要支持。有些替代是100%可换，有些只能换一部分，比如某材料最多允许30%的替代比例。这个比例要作为约束进入计算，否则会算出超出工艺允许的替代方案。
替代的单向性要标注。A可以替代B，但B不能替代A，这种情况在电子料里很常见。建表时用一个方向字段标识，避免双向误用。
还有一个实操细节：替代料的库存要能“共享消耗”。当主料不足时，系统按优先级依次动用替代料，动用了多少要回写到分配结果里，否则下一次计算又会把同一批替代料算成可用。这个回写机制是替代料建模里最容易漏的一环，漏了就会反复出现“系统说能齐、实际没料”的情况。
6.3 怎么衡量这套模型到底有没有用
模型上线之后要有一套衡量标准，否则没法证明价值，也没法持续优化。我通常看四个指标。
第一是缺料导致的停线时长，这是最硬的指标，直接对应钱。上线前后做对比，一般能看到明显下降，但要排除订单波动的影响。
第二是齐套率的稳定性，也就是波动幅度。好的模型不是把齐套率做到最高，而是让它可预测。如果齐套率忽高忽低，说明数据或口径有问题。
第三是缺料预警的准确率，即预警的缺料有多少最终真的发生了。这个指标低于七成，说明模型过度保守；高于九成五，可能过于宽松。
第四是计划员的工时节省。原来每天两小时手工对表，现在十五分钟看板确认，这个节省是实实在在的。我一般会把这个数字换算成人力成本，写进项目验收报告，比讲一堆技术指标有用得多。
最后分享一个我在多个项目里都验证过的小技巧：上线第一个月，别急着关掉原来的Excel对表流程，让系统和人工并行跑两周，每天对比差异。这两周的差异清单，就是最好的模型校准材料，能一次性暴露出八成以上的口径问题和数据问题。等差异收敛到可接受范围再切换，抵触情绪会小很多，因为大家亲眼看到系统是怎么一步步变准的。比起开会宣讲，这种“并跑对账”的方式更能让人信服。
