高级计划与排程：一份排程计划必须满足什么

本文假定您熟悉自己的工艺，但从未采购过排程软件。

真实产线必须满足的生产排程约束

先从约束谈起，因为软件的价值，完全取决于它能把多少约束表达出来。一台设备同一时间只能跑一个作业，而从当前作业切换到下一个作业所需的时间，通常取决于这两个作业是什么。浅色换深色只需擦拭，深色换浅色则要清机和清洗。这就是顺序相关换型：换型时间不是某道工序的属性，而是某台资源上一对工序的属性——同样的换色，在大型压机和小型压机上代价并不相同，在有些产线上还取决于设备当前状态。它恰恰是系统台账里最常缺失的约束，这也是为什么 ERP 跑出来的计划往往更像一张排好序的清单，而不是一个顺序。

接下来是那些不挂在单台设备上的约束，在很多产线上，它们比换型矩阵卡得更紧。一副模具、一套模仁或一台试验台同一时间只能在一个地方，因此两个都能跑这张订单的单元，不可能同时跑它。持证操作员也是同一类稀缺对象：当班三个人、只有一人具备该焊接等级资质，那么这个等级的产能就是一。压缩空气、烘箱或行车则在整个区域内形成约束，两个单独看都排得下的作业，放在一起未必排得下。

物料齐套既是硬性前提，也是一个软性输入。零部件没到，订单就不能开工；但到货日期只是供应商的一个承诺，而供应商有自己的履约可靠性。因此排程应当显示出哪些订单依赖尚未到货的交付，让这份风险敞口摆在计划上可见，而不是被摊进提前期里平均掉，等到物料没来的那天早上才被发现。

日历所承载的信息比大多数人预想的多。班次模式往往按区域而非按工厂划分：热处理通宵运行，装配则不然；一次周五的换型如果在下班前完成不了，就得做两遍。保养窗口、节假日和年度停机，都是资源虽然在资产清单上存在、却无法供生产使用的时段。

还有一些与产能毫无关系的工艺规则。固化、干燥、冷却和待检会在工序之间强加最小等待时间，而且往往还有最大等待时间：至少固化四小时、二十四小时内完成涂装、调配好的胶黏剂必须在适用期内用掉、零件要在返锈之前清洗。一个只懂最小等待、不懂最大等待的排程器，会不声不响地生成让物料报废的计划。有些工序必须连续进行，因为零件不能半成品状态搁置；有些批次的批量必须按料罐容量而不是按需求数量来定。

为什么 MRP 跑出来的日期没人做得到

MRP 做的事确实有用，但那不是排程。它把需求沿物料清单逐层展开，与库存和在途订单做净需求计算，再按每个物料固定的提前期前推，告诉您要做什么、要买什么、大致什么时候开始。为了在成千上万个物料上完成这件事，它假定只要算式需要，产能就一定可用。

这个假设失效得悄无声息。两张订单都想在十点上压机，MRP 就把两张都放在那里。提前期偏移是一个一次性设定的数字，是排队、加工和转运时间在早已不复存在的条件下的平均值；而换型要么根本没被考虑，要么被打包成一个与顺序无关的固定余量藏在里面。结果是算式上自洽、物理上做不到——这比单纯算错更糟，因为它在系统里看上去是对的。

差额由车间来吸收。有人手工重排顺序，通常还排得不错，靠的是存在一两个人脑子里的经验，于是计划沦为一份建议。所有从计划派生出来的东西都继承了这个误差：承诺交期、采购时点、人员配置、报给销售的产能数字。当计划员用放大提前期来应对时，这份保护是真实的，代价也是真实的：被放大的提前期意味着工作提前投放，而提前投放就变成了堆在工位之间的在制品。

用来取代这些日期的电子表格，是一次真实的改进，但它有天花板。它之所以有效，是因为计划员把换型矩阵和工装冲突记在脑子里；而它会失效于规模、失效于他休假的时候，也失效于“接下这张订单会打乱什么”这个问题。

有限产能排程改变了什么

有限产能排程把问题反过来提。它不问“如果没有任何阻碍，这道工序应该什么时候开工”，而是把工序放到本来就有活的资源上去，同时遵守换型、日历、工装和工序先后关系，然后把由此得出的日期报出来。日期从输入变成了输出。

由此带来的结果非常务实。每台资源上的顺序是明确的，因此换型矩阵可以被利用起来：当换型占用了可用产能中相当可观的一部分时，把相容的产品归拢在一起，就能不花一分钱投资地把换型工时找回来。您的情况是不是这样，只需一个本周就能测出来的数字，而且值得先测——因为在一条换型只要五分钟、真正问题出在物料上的产线上，调整顺序几乎找不回什么。瓶颈会以负荷的形式被看见，而不再是各执一词的看法。因为计划是受约束的，新增一张订单会显示出它挤掉了什么，而这正是能够做出可信交期承诺的前提。

它同样改变了投放。无限产能计划按提前期允许的最早时间投放工作；有限产能计划则在约束资源能接得住的时候才投放，这会把在制品压下来，也缩短了“产生一个缺陷”到“发现这个缺陷”之间的距离。这一切都不是免费的：模型需要维护，而且它的诚实程度不会超过其中那些时间参数的诚实程度。

计划、排程与派工是三件不同的事

把这三者混为一谈，是排程项目最终交付出一个没人用的东西的最常见原因。计划以周和月为单位工作。它回答的是需求在总量上是否可行、三月份要不要上第二班、对供应商作出什么承诺。它的单位是产品族与周；再精细就是虚假的精度，因为需求本身也并不精确。

排程以小时和天为单位工作。它回答的是接下来几个班次里每台资源上的先后顺序，以及这个顺序所隐含的换型——这正是 APS 最确切的含义。

派工以分钟为单位工作。它回答的是这个单元的操作员下一步做什么：设备停了、首件检验没过、物料没到。它归属于操作员真正会去看的那个界面——MES 终端、派工清单、贴在机台上的一张顺序表——而关键在于它离作业足够近，并且被允许偏离排程，因为现实也有一票。

失效方式之一，是在错误的层级上使用工具：把三周之后的事排到分钟，或者拿派工清单去做产能规划。另一种失效方式，是在派工层禁止任何偏离，这会让系统变成障碍，并注定被绕开。

APS 需要哪些数据：工艺路线、节拍时间、换型时间

排程引擎本质上是一次基于您主数据的计算。数据如果只是摆设，输出就是一个自信满满的摆设。

工艺路线必须反映零件的真实制造方式，包括替代资源。如果一个作业能在三台设备上跑，工艺路线却只写了一台，排程器就会把活全排在那里，报出一个您其实并不存在的瓶颈。如果工艺路线漏掉了一道总会发生的工序——去毛刺、检验、等待冷却——那么每一个日期都会短掉这么多。

节拍时间必须实测，而不能沿用。大多数 ERP 里的标准工时是上线时录入的，反映的是可能早已不存在的一副工装和一位操作员。您不需要完美的时间，只需要误差小且不带系统性偏差的时间：一条每道工序都乐观同样幅度的工艺路线，累积到周末就是一份差了整整一个班次的排程。

换型时间是最常彻底缺失、却也最有价值的数据。维护一份涵盖所有产品两两组合的完整矩阵，通常做不到。行得通的做法，是按真正决定换型代价的因素——颜色、材料、工装、温度、幅宽——把产品归入产品族，然后定义族与族之间的时间，只在确实重要的地方设置例外。这份族间矩阵应当按资源组分别维护，而不是全厂只有一份，因为同一个切换在两台不同设备上很少是同样的代价。

当前在制品是人们最容易忘掉的一块。明天的排程起点，是今晚车间的状态：哪些是半成品、在什么位置、每台设备上装的是什么。如果这个状态是下班时照着一张纸单录进去的，那么排程器优化的是几个小时前的那家工厂。

坏数据会自己暴露。某一台资源永远满负荷、其余全都闲着，这通常意味着工艺路线人为地把活都灌到了那里。计划员每天都在改同样几张订单，这意味着模型里缺了一条约束。一批作业在同一分钟内被集中报工，这意味着报工是事后补录的，开工时间是编出来的。人的本能是去调引擎的参数，而原因几乎总在主数据。

如何判断一份排程的好坏

准时交付率是真正重要的结果，而且必须对照给客户的那个日期来衡量，而不是对照最近一次内部修订过的日期，否则这个数字会变好，客户的体验却不会。

每周换型总工时，是衡量顺序优化到底有没有起作用最干净的指标，而且可以直接换算成产能。

在制品与流动时间说明计划投放得是否合理。一份靠提前大量投放、把车间灌满来改善准时交付率的排程，只是把问题挪到了过道上。

排程达成率——一个班次计划要做的内容，实际按计划顺序做掉了多少——是衡量计划是否可信的诚实指标。一份理论指标漂亮、但车间没到午饭就不再照着做的排程，只是一份文件。

设备利用率是个陷阱。让每一台非约束设备都忙着，产出的是库存，而不是真正的产出；而一条处处都逼近产能上限的产线，没有任何余量去吸收波动，于是队列非线性增长，利用率数字越好看，提前期反而越差。只在约束资源上盯着它，其他地方基本可以忽略。

重排程策略与计划紧张

一个能在几秒内重新计算的引擎，会诱使人不停地重排。要忍住。如果任何风吹草动都让顺序变一次，车间就会明白八点的计划不是十点的计划，于是回过头去跑看着合适的活。这种不稳定叫作计划紧张，它摧毁信任的速度比一份平庸的排程快得多。

可用的模式是冻结期加上一套策略。在冻结窗口内，除非出现真正的阻塞因素，否则顺序不变，这样已经开始的换型不会白做；窗口之外，允许重新优化。经验法则是：重排的频率不高于冻结窗口的长度，而这个窗口的长度由两件您在现场就能观察到的事决定——一次换型要多久，以及真正的阻塞因素多久来一次。一家作业时长以小时计、几乎天天有工装冲突的机加工车间，会冻结几个小时、每班重排一次；一家以周为单位跑长周期连续批次生产的流程型工厂，则会冻结若干天。无论哪种方式，定时重排之外都要辅以事件触发的重排：设备故障、交付缺失或加急订单。

有两件事让这套策略真正跑得起来。例外清单必须写明确：什么才算打破冻结的理由，以及谁有权批准。以及，当排程确实发生变更时，主管必须能看到变更的原因，因为一次没有解释的变动，读起来就是“这软件不靠谱”。

APS 与 ERP、MES 的相邻关系，以及谁说了算

ERP 掌管商务与物料的世界，是“要做什么、什么时候要”的来源。APS 掌管顺序：需求和物料来自 ERP，约束来自它自己的模型，车间状态来自执行层。MES 掌管执行以及执行的记录，同时它也是 APS 的传感器，没有它，排程器对当下就是盲的。

只有双向都跑通，这个闭环才真正闭合：APS 到 MES 是排程，MES 到 APS 是实际发生了什么。一份每天一次的报工文件，足以用来安排明天，但不足以用来重排今天下午。

职责归属必须在上线前写下来，因为会吵起来的点是可以预见的。谁可以改交期。谁维护换型矩阵和节拍时间，按什么周期复核。谁可以在单元层面推翻顺序，以及这次推翻是否被记录。当 ERP 和排程器对现有库存各执一词时，以哪套系统为准。把这些留作默契，正是一个技术上没问题的实施最终停滞的常见原因。

做一次真能说明问题的评估

供应商拿自己的数据做演示，只能证明这个软件跑得起来。改用您自己的工厂来评判它；只要范围划得好，这件事成本并不高。

挑一个有真实约束的区域——换型显著、工装共用、订单相互争抢——而不是整个工厂，并选取过去四到八周、您清楚跑了什么、哪些延期了的一段时期。把您今天手上的主数据给候选系统，而不是为了测试专门清洗过的版本，因为您数据的真实状态，本身就是您要衡量的对象之一。

然后让它复现那段时期的排程并加以对比。这个模型能表达您的约束吗，还是需要把难处理的那几条简化掉？如果您的工艺涉及保质期或适用期，它处理最大等待时间是否和处理最小等待时间一样到位？它排出的顺序用掉多少换型时间，与您实际花掉的相比如何，以及对于那些您当初延期交付的订单，它怎么说？然后跑一遍真正重要的情景：瓶颈设备停机两天、周中来一张加急订单、一批交付晚到一周。

然后让一位计划员在它面前坐上一个下午。问题不在于引擎聪不聪明，而在于人能不能看出它为什么这样决策，并且不用跟工具较劲就能调整它；一个没人能跟它讲道理的排程器，就是一个没人会用的排程器。要问清楚：当一个产品、一台设备或一个换型时间发生变化时，维护这个模型的代价是多少，需要改动多少个地方。大多数排程之所以劣化，不是因为引擎算错了，而是因为项目结束之后没人再对模型负责。

Meta Smart Factory 在其中的位置

Meta Smart Factory 的 APS 与 MRP 模块承担其中有限产能的那部分工作，其约束模型涵盖顺序相关换型、共用工装、操作员资质和按区域划分的班次日历，并可针对上述各类扰动运行情景推演。由于它们与 MES 模块处在同一个平台上，执行层与排程器之间不存在隔夜文件交接，因此车间状态的实时程度，取决于您的报工节点设置以及操作员的报工纪律。这是一个前提条件，而不是一个细节：如果一半的报工是休息时间补录的，而手工装配环节根本没有扫描点，架构救不了您。这些节点设在哪里，属于实施工作，而不是实施的副产品。面向订单、物料清单和报工的 ERP 接口，同样是这项工作的一部分。

真正决定这一切是否奏效的那些部分，不是我们能提供的：实测的节拍时间、一份有人负责的换型矩阵、与零件真实制造方式相符的工艺路线，以及一份写下来的重排程策略。如果您还处在这件事的早期阶段，有用的第一步不是看演示，而是在一个受约束的区域上，用您现有的数据，做上面所说的那次历史对比。