瓶颈优先规划只有在瓶颈被建模为有限时才行得通

「找到瓶颈，然后围绕它排程。」这是一条常见的排程建议，而承重的那部分通常被省略。这个方法来自约束理论的传统：识别约束、利用约束、让其他一切服从它。这个传统不是问题。问题是当约束工序背后没有数字时会发生什么。

这个方法本就预设了一个被量化的约束

瓶颈优先规划从来不是「挑一道工序，然后叫它约束」。利用这一步，只有当你知道约束的速率、它的可用时间、以及什么会干扰它时才有意义。鼓-缓冲-绳中的鼓就是约束工序，它的速率为工厂定下节拍。缓冲是一个有尺寸的量，根据它必须吸收的干扰计算出来。绳控制着什么被释放进系统。这个方法的每一个活动部件，都是一个数字。

一个无法回答「约束工序的真实产能是多少，它何时能运行？」的计划员，并没有在实践这个方法。他们只是把标签贴在一个猜测上。

电子表格负荷计划把约束当作无限的

前提通常破裂的地方是规划面。一份电子表格负荷计划按平均速率把需求汇总到每道工序。它没有工作窗口，没有停机，没有按产品族的周期，也没有上游物料的状态。需求被陈述时，完全不考虑工序的产能限制。用行业自己的词汇说，这就是无限负荷：计算需求时不考虑工作中心实际能做什么。

当负荷还压在真实产能之下时，无限负荷是潜伏的。它恰恰在负荷逼近那个产能时变得可见。到达一道工序的工作，若其真实服务速率低于到达速率，就会累积起来，队列与等待来料的暂停在计划没有看的地方增长。瓶颈也会转移：当产品组合变化，或另一道工序的可用性下降，真实约束就移动了。一份依据平均负荷或记忆来固定约束的计划，可能把整个方法指向一道早已不再是约束的工序。

「被建模为有限」实际要求什么

当关于约束工序的四个问题得到回答——外加一个容易被忽略的第五个——瓶颈优先的生产排程就能在接触真实负荷后存活。

第一，这道工序的真实速率或周期是什么？不是跨产品的平均值，而是实际运行的产品的速率：flow（连续流）工序按它真实的产线速度，batch（批次）工序按它真实的批次周期时间。

第二，这道工序实际何时能运行？工作窗口来自工作日历及其例外，生产排程应当按工作时间推进，于是一份无法在班次结束前完成的作业，会在下一个班次恢复，而不是整夜运行。

第三，什么会夺走它的产能？用于维护、故障与停运的停机，应当在构建生产排程之前就从工作产能中扣减，让时间安排绕开停运，而不是假装工序在停运期间仍一直在运行。

第四，上游物料能否及时到达？当下游工序在更多物料到达之前就用完了物料，生产排程应当在断料所在之处显示等待来料的暂停，而不是静默地延长一根条。在混合流水车间中，有些工序并行运行多台设备，同一个问题适用于工序之间的每一处交接。

第五项是换线。在一条拥挤的约束工序上，相邻作业之间的准备时间是负荷的一部分。特定设备上依赖顺序的换线折入每项作业的开始时间，于是约束上的换线负荷保持可见。

凡是被建模的地方，计划员可以直接从生产排程上读出占用率与等待，并基于证据执行定位约束那一步。凡是没有被建模的地方，生产排程就是对一道从未被量化的工序许下的愿望。

这对规划工具意味着什么

规划面要么承载约束的有限产能，要么不承载。兑现承诺的，是那个决定，而不是那条建议。

一个为每台设备建模按产品族的速率或批次周期、对着真实工作窗口排程、在排程之前扣减停机、并在上游供应让某道工序断料时显示等待来料暂停的工具，给了瓶颈优先计划员这个方法所预设的东西：一个有数字的约束。计划员的工作变成决定哪道工序是约束，而生产排程让这个决定可检验，因为每道工序的占用率、队列与空闲时间都可见。

没有任何工具替你识别瓶颈。这一步留在计划员手里，这没什么不好。工具能做的，是让识别不再是对一道从未被建模的工序的猜测。

保留方法，验证模型

这些都没有说瓶颈思维是错的。聚焦约束是把改进引向回报最先之处的一种正当方式。主张更窄：这个方法能否兑现，取决于瓶颈背后的模型。

所以，在相信计划之前，对照上面的问题检查你的规划面。它承载约束工序的真实速率或周期吗？它的工作窗口？它的停机？为它供料的供应？压在它身上的换线负荷？如果其中任何一个是「不」，那你正在看的这份瓶颈优先计划，顶多和你把它装进去的那份电子表格一样好。当约束被建模为有限时，这个方法终于有了可以着手的东西。