设备适用性应属于排程引擎

每一次规划会话都从同一个安静的问题开始：这道工序上哪些设备能运行这个产品？它每个产品被问一次、每道工序被问一次、每份生产排程被问一次，答案来自记忆，或来自一份人人都见过、却无人拥有的电子表格。答案是工厂事实。它不随工作量、星期或计划员而改变。它是设备与产品族的一个固定属性。然而在许多工厂里，这个事实活在排程引擎之外，每一份生产排程都靠手工重新应用它。

当适用性住在引擎之外时，生产排程继承了些什么

每一份生产排程都依赖回忆。机制很平常：计划员构建生产排程，在每道工序处咨询同一个未被建模的来源，一个头脑、一位同事、一张记录纸。检查很快，所以它被不断重复，而每一次重复都是一次答案偏离工厂实况的机会。即便答案是对的，这份检查也在每份生产排程上消耗规划时间，因为它要被重新应用到工艺路线中的每道工序和生产排程上的每个产品族。重新运行就要重复检查。新计划员在没有旧背景的情况下重复它。陌生的产品族得到的是一次最佳猜测，而不是一个经过验证的答案。

当猜测是对的，一切看起来没什么不对，而这恰恰是失败一直不可见的原因。生产排程把一项作业分配给一台不能运行的设备，失配只在生产排程遇上产线、设备无法接下这项作业时才浮出水面。到那时时间已经花掉，生产排程必须返修。这里没有任何离奇之处，也不需要坏人或坏工厂。依赖一个人回忆的生产排程是脆弱的，而把适用性放在一份未被建模的电子表格里的工厂，等于让回忆成为一种永久性的输入。

适用性是结构性知识

适用性是结构性知识，而结构性知识属于模型。排程引擎只能尊重被赋予它的约束。不给它适用集合，它就无从把一台设备当作任何产品候选之外的东西。那就是未被建模的电子表格的失败模式，被复制了出来。更好的计划员或更严格的检查清单修复不了它。修复之道是停止把适用性当作生产排程内容，开始把它当作工厂结构。

分配这个词里藏着两个问题。第一个是什么能运行：适用集合，即此工序上真正能处理该产品族的设备。第二个是什么会运行：这个集合之内的设备分配。两者在性质上不同。什么能运行是关于工厂的一个事实。什么会运行才是生产排程。工厂决定一次适用性。引擎应当承载它，并在之后的每一份生产排程上尊重它。

引擎如何对它建模

适用性以能力记录的形式进入引擎，一台设备一条记录。一台设备为它能以 flow（连续流）工序运行的各产品族携带一条产线速度，为它能以 batch（批次）工序运行的产品族携带一个批量大小和批次周期时间。这些条目就是记录。产品从其产品族继承能力，因此适用性按产品族、按工序定义，绝不全局定义：一个产品族只流经它所需的工序，每台设备恰好属于一道工序，也没有逐产品的能力。条目说明两件事：这台设备能在此工序处理该产品族，以及要花多长时间。条目存在时，这台设备是该产品族在该工序的候选。不存在时，则不是。

执行直接来自记录。在 Auto 与 Semi-Auto 模式下，引擎把设备分配限制在真正能在该工序处理该产品的设备。未为该产品族登记能力条目的设备，不作为该产品族的候选，其他产品族仍可流经完整的设备池。没有叠加上去的独立适用性规则；限制从哪些条目存在中直接得出。

优化随后在适用集合之内工作。Auto 模式把生产顺序与设备分配一起优化。Semi-Auto 模式保持生产顺序固定，并在其中优化设备分配。两者都最小化总生产时间。有一个事实留在模型之外：一台设备为什么能或不能运行某个产品族。这个理由在工厂里决定，作为能力录入。能力是一个静态的、配置化的事实。引擎不测量它，也不学习它。

对计划员来说什么发生了变化

有了由条目隐含的适用集合，计划员的工作发生了变化。规划时间流向计划员自己拥有的决策：运行哪些作业，以及在 Semi-Auto 中它们按什么生产顺序运行。引擎持有能运行什么，因此计划员不必在每份生产排程上重新验证它。应该运行什么以规划判断开始；引擎随后把这种意图变成一份可执行的生产排程，在 Auto 中还同时选择生产顺序，在 Semi-Auto 中保持顺序固定并在其中优化设备分配。无论哪种方式，目标都一样：最小化总生产时间。

值得精确说明这种变化发生的边界，因为它只在边界之内才真实。把候选集合限制在搜索的一部分，并在其中优化分配，是 Auto 与 Semi-Auto 模式的行为。Manual 模式不运行任何算法，所以这两件事都不会发生，但同样的设备兼容性检查仍作为逐行校验运行：输入一台不能处理该产品族的设备，系统就拒绝该行。适用性也不是整个分配问题。它是引擎建模的若干结构性事实之一：换线、工作日历、可用性与物料供应都塑造真实的分配。要点不是能力是唯一的约束。而是一个引擎没有建模的约束，就是计划员要手工携带的约束。

变化带来一个义务。适用性由档案上有什么来表达，因此条目是一份工作文档。能力数据必须像任何其他工厂配置一样被录入和维护。引擎不从任何其他地方推断一台设备的能力，而从未录入的能力会让这台设备被排除在适用集合之外。当这个遗漏是有意的，那是模型在按预期工作。当它不是，那就是数据必须保持最新的原因。

适用性在你们的工厂里住在哪里

所以在关键之处提出这个问题：当计划员需要知道此工序上哪些设备能运行该产品族时，答案从哪里来？如果它来自一个头脑或一份电子表格，生产排程就继承了回忆，一次重新应用接着一次。如果它来自模型，工厂已经决定了一次，而每一份生产排程都尊重那个决定。同样的检验适用于你评估的任何排程工具：适用集合是引擎尊重的一个输入，还是计划员必须手工重新应用的一个细节？在工厂里、以能力的形式，一次性决定适用性。然后让引擎在每一份生产排程上尊重它。