很多PMC每天最头疼的，不是不会排计划，而是所有人都觉得自己的订单最急。

销售说客户催得厉害，老板说这个客户不能丢，生产说换线太频繁，采购说关键料还没到，仓库说半成品堆不下。

最后PMC夹在中间，排早了现场不认，排晚了销售追责，今天刚排好的计划，明天一个插单又要全部重排。

真正难的，不是把订单塞进生产日历，而是当交期、产能、物料、设备、插单同时冲突时，PMC到底依据什么决定谁先做、谁后做。

这也是排产算法的价值。

最短工期解决的是现场怎么快速清理积压；最早交货期解决的是客户承诺怎么守；Slack解决的是哪些订单看似不急，实际上已经没有多少缓冲；CR值解决的是当前订单到底紧急到了什么程度。

但算法只是判断顺序，不是自动替PMC做决定。

基础数据不准、工艺路线不清、剩余工时估错、现场进度不回传，公式算得再漂亮，也只能得到一个准确的错误答案。

所以这4种算法，不需要死记硬背。真正要掌握的是：它们分别在回答什么问题，以及什么时候该用。

​文中用到的简道云生产管理系统在这里>>https://s.fanruan.com/b9zng

一、最短工期

最短工期，也就是SPT，Shortest Processing Time。

核心逻辑很简单：把同一资源上的待生产订单，按照剩余加工时间从短到长排列。

例如一台设备前面有5个订单：A需要1小时，B需要2小时，C需要8小时，D需要1.5小时，E需要10小时。

按最短工期排，就是A→D→B→C→E。

它的直接效果，是短时间内完成更多订单，让设备前的等待队列迅速缩短。

它最适合解决的是堵，不是急。

生产现场经常出现这种情况：订单总量不算特别大，但设备前堆着十几个待加工单，每个只差一两个工序，结果质检、入库、包装、发货全跟着堵。

这时候如果一味按大单、长单优先，现场会越来越拥挤。最短工期可以先把短单快速清掉，让在制订单数量下降，减少等待和流转压力。

它尤其适合三类场景：

一是短单、尾单积压严重。

很多订单已经做了80%、90%，只差最后一道工序，可以先集中处理一批短工时订单，快速清掉队列。

二是瓶颈设备前排队过长。

当订单都堵在同一台设备上，先加工短任务，可以更快释放设备处理能力，减少平均等待时间。

三是企业需要快速降低在制。

短单完成后，可以更快进入检验、包装、入库和发货环节，让生产链条重新流动起来。

但最短工期有一个明显问题：它容易让长订单持续往后排。

假设每天都有新的短单进来，PMC每天都觉得先处理1小时、2小时的订单更划算，10小时、20小时的大单就可能不断被往后挤。等真正轮到时，交期已经很近，后面很难追回来。

所以最短工期不能理解成谁工时少谁永远优先。

更稳妥的用法，是把它当成清理队列的规则，而不是唯一排产原则。实际排产时，可以增加交期保护条件，例如接近交期的订单禁止继续后移；同等条件下，再用最短工期处理积压短单。

还有一个容易被忽视的问题：最短工期到底按什么时间算。

如果只算纯加工时间，可能会失真。

比如A加工1小时，但换线要2小时；B加工1.5小时，不需要换线。单看工时A更短，但算实际占用能力，B反而更适合先做。

因此真实现场不能只看机器运行时间，还要根据企业情况考虑换线、调机、首检、批次切换等额外时间。尤其换线成本高的产线，不能把公式里的工时理解得过于简单。

最短工期真正回答的是：怎样用较短时间，先完成更多任务，降低现场拥堵。

但它回答不了订单到底谁更急，所以一旦涉及明确交期，就要结合其他规则判断。

通过简道云搭建生产订单与排产流程，可以将订单工时、交期、当前进度、生产状态统一管理，让PMC排产时有真实数据可依据，而不是靠Excel、群消息和电话反复确认。

二、最早交货期

最早交货期，也就是EDD，Earliest Due Date。

逻辑非常直接：谁的交期最早，谁优先生产。

例如：A周三交货，B周五交货，C周二交货，D下周一交货。

优先级就是C→A→B→D。

这是很多企业最容易接受的排产方式，因为它和客户承诺直接对应。

所以在订单结构相对稳定、换线成本较低、物料齐套率高的企业，最早交货期往往是基础排序规则。

它最大的价值，是保护交期。

但问题也在这里：交期只是一个日期，生产却是一套资源约束。

例如一条产线同时有4个订单：A周一交货，B周二交货，C周三交货，D周四交货。

看起来按交期排没有问题。

但A做完要换线3小时，B又要换一次，C还要换一次。为了严格按日期切换产品，可能造成设备利用率下降、调机频繁、首件增加，最终连原本能按时交的订单都开始延误。

所以最早交货期最容易出现的误区，就是把日期当成唯一优先级。

实际至少要确认三件事。

第一，交期是不是可信。

如果销售没有经过产能、物料和工艺评估就直接承诺客户日期，PMC后面按最早交货期排，也只是在兑现一个源头不合理的承诺。

第二，剩余工时够不够。

一个订单5天后交货，但剩余生产只要半天；另一个订单3天后交货，却还需要2.5天。虽然日期不同，但真正的风险未必和交期远近一致。

第三，订单切换代价是否合理。

如果两个订单交期只差1天，但其中一个可以和当前设备连续生产，另一个需要长时间换线，单纯按日期排序，很容易为了保护一个订单牺牲整条产线的效率。

因此，最早交货期更适合做基础排序，而不是最终判断。

它回答的是：谁的客户承诺更靠前。

如果现场还有设备约束、换线损失、缺料、异常和多工序协同，就要继续判断这个订单到底有没有真正的交期压力。

这时候Slack比单纯看日期更有价值。

三、Slack

Slack可以理解为订单还剩多少时间缓冲。

最基础的计算方式是：

Slack = 距离交期的剩余时间－完成剩余工序所需时间

例如，一个订单距离交期还有5天，剩余生产需要3天：

Slack = 5－3 = 2天。

另一个订单距离交期还有3天，剩余生产只需要0.5天：

Slack = 3－0.5 = 2.5天。

虽然第二个订单交期更近，但缓冲反而更多。

这就是Slack和最早交货期最大的区别：最早交货期只看终点什么时候到，Slack还会看从现在开始到底还剩多少可以浪费的时间。

很多延期不是到了交期才突然出问题，而是订单明明还有几天，实际剩余工序已经把缓冲吃光了。

比如一个订单还有4天交货，但后面还有4天生产时间。

看交期，好像还没到；看Slack，已经等于0。

意味着现在开始，只要设备停一次、物料晚一次、质检卡一次，订单就可能延期。

如果Slack已经为负，则说明按照当前剩余产能和正常生产节奏，理论上已经赶不上交期。

这时候就不能再靠普通排序解决，而要进入补救决策，比如增加班次、调整设备、外协、拆批交付，甚至重新沟通客户交期。

所以Slack特别适合做提前预警。

可以把订单分成三类：

Slack较大，当前还有缓冲；

Slack接近0，已经没有多少犯错空间；

Slack小于0，按当前条件已经存在明确延期风险。

但Slack最关键的不是公式，而是数据。

如果剩余工时填得不准，Slack就会失真；如果系统显示还有8小时工作量，实际因为返修、等待和调机还要12小时，算出来的缓冲就是假的。

如果工序已经完成但现场没报工，PMC看到的也是错误状态；如果关键物料没有及时反馈，算法甚至会把一个已经无法生产的订单继续当成正常订单计算。

通过简道云搭建订单进度、车间报工、缺料反馈和异常处理流程，可以将订单当前做到哪道工序、还差多少工作量、卡在哪个环节统一管理，让PMC基于真实进度判断余量，而不是每天靠电话和群消息拼状态。

这也是为什么Slack不能被理解成一个单独的公式，它依赖订单、工序、进度、异常持续更新。

另外，Slack最好不要只算一次。

订单是动态的。今天还有2天余量，明天设备停机4小时，余量就会快速下降；关键物料晚到一天，Slack也可能从正数变成负数。

所以Slack更适合滚动计算：今天排今天，明天根据新的现场状态重新计算，而不是一张周计划排完之后一周不动。

Slack真正回答的是：哪些订单表面上还没到期，实际上已经快没有缓冲。

四、CR值

CR值，也叫关键比率，Critical Ratio。

计算方式是：

CR = 距离交期的剩余时间 ÷ 完成剩余工作所需时间

例如：

距离交期6天，剩余生产3天：

CR = 6÷3 = 2。

距离交期3天，剩余生产3天：

CR = 3÷3 = 1。

距离交期2天，剩余生产4天：

CR = 2÷4 = 0.5。

它和Slack有点像，但看问题的角度不同。

Slack直接告诉你还有多少时间可以缓冲；CR则比较现在剩下的时间，和剩余工作量是否匹配。

可以把它理解成订单当前紧急程度的比例信号。

通常可以这样判断：

CR＞1，当前还有一定缓冲；

CR≈1，剩余时间基本刚好够做完；

CR＜1，按当前节奏已经存在明显延期风险。

例如两个订单Slack都只剩1天。

订单A还剩2天工作，订单B还剩8天工作。

两者都是只剩1天缓冲，但危险程度不同：A的CR是0.5，B的CR只有0.125。

B需要更早进入处理范围。

所以CR比Slack更适合做滚动优先级判断。尤其订单数量多时，PMC不可能每天人工分析所有订单，可以通过CR值快速筛出当前最紧迫的订单。

但CR值不能只算一次。

周一CR=1.8，说明暂时有空间；周二设备停半天，可能降到1.5；周三物料晚到，可能降到1.1；再发生一次异常，可能直接跌到0.8。

因此CR真正有价值的用法，是每天重新计算、持续滚动。

同时要给CR值配合实际动作，而不是算完就结束。

CR接近1，需要重点关注；CR小于1，需要立即确认问题在哪里。

是前工序没有完成？是瓶颈设备排不上？是缺料？是品质检验卡住？还是剩余工时本身估错？

通过简道云搭建订单交期、剩余工时、现场报工、异常提报和处理流程，可以将订单变化与异常处理统一管理，让PMC发现CR值下降时及时跟进具体问题，而不是算出一个紧急结果后继续等延期发生。

这里还需要注意：CR值只是比例，不代表绝对安全。

因为它不会自动解决换线、等待、设备故障、人员不足、品质返工、物料短缺等问题。

尤其当剩余工时长期估得过于乐观时，CR会持续高估订单的安全程度。

所以实际使用时，CR更适合作为动态优先级信号，而不是自动排产的唯一依据。

它回答的是：现在这个订单，到底紧急到什么程度。

五、4种算法到底怎么用？

最短工期看效率，最早交货期看承诺，Slack看余量，CR看紧迫度。

四种算法关注的是不同维度，不存在一个公式可以替代全部规则。

真正成熟的PMC，不是把4个公式背得滚瓜烂熟，而是知道当前最需要解决的问题是什么。

现场短单堆积，就优先考虑最短工期。

客户交期压力大，就重点看最早交货期。

担心哪些订单会突然失控，就看Slack。

每天要快速筛出最危险的订单，就看CR值。

最终排产，还必须回到真实现场：物料是否齐套，设备是否可用，换线代价多大，剩余工时是否准确，前后工序是否衔接，异常是否有人处理。

因为排产从来不是一道公式题。

它真正要解决的是：在有限资源下，今天到底应该先做谁、为什么先做、谁可以往后放，以及哪些订单已经不能再等。

算法只是把这种判断，从拍脑袋变成有依据的排序。

结尾

PMC真正要掌握的，不是4个公式本身，而是4种判断视角。

最短工期，帮你清理积压；最早交货期，帮你守住承诺；Slack，帮你提前发现余量正在被吃掉；CR值，帮你快速识别已经进入危险区的订单。

但算法的准确性，最终取决于数据是否真实。

订单、工序、进度、物料、设备、异常都不准确，再高级的排产规则也只能算出错误的优先级。

所以好的排产，不是把公式算得多复杂，而是让每一次让单、插单、调整，都有清晰依据。

Q&A

Q1：四种PMC排产算法没有绝对最优解，实际生产中我到底该优先用哪一种？有没有通用选型标准？

核心答案：算法没有万能通用款，核心根据工厂核心生产目标选型，抓准「交付优先、效率优先、负荷均衡、紧急优先」四大核心场景即可精准匹配。如果工厂当前核心诉求是保障客户交期、减少订单延期，优先选用EDD最早交货期算法，优先排布交期靠前的订单，最大程度降低逾期风险，适配订单杂、交期紧张的多品种小批量生产场景；如果核心诉求是提升设备利用率、缩短整体完工周期，选用SPT最短工期算法，快速消化短工序订单、减少设备空置积压，提升整体生产流转效率；如果需要兼顾全局、均衡产能负荷，避免部分工序过载、部分工序闲置，选用Slack松弛时间算法，统筹剩余缓冲时间，平衡整体生产节奏；如果面对多订单冲突、优先级难判定的复杂场景，选用CR临界比值算法，通过标准化比值精准判定订单紧急权重，适配复杂混排生产场景。简单来说：保交期看EDD、提效率看SPT、平负荷看Slack、判优先级看CR值。

Q2：四种算法可以单独使用吗？实际生产工况复杂，单一算法会不会适配性不足？

核心答案：基础场景可单独落地，复杂生产场景必须组合搭配使用，单一算法存在明显短板，组合排产才能规避短板、兼顾多重需求。四种经典算法各有优劣、各有侧重：SPT最短工期容易导致长周期订单持续滞后，EDD最早交货期可能造成设备频繁换线、产能浪费，Slack和CR值算法更侧重优先级判定，对生产效率的优化有限。在工序单一、订单规整、产能充足的简单生产场景下，可直接单用对应算法快速排产，降低PMC工作难度。但制造业现场大多存在订单穿插、设备有限、物料波动、插单改单等突发情况，单一算法很容易出现顾此失彼的问题。行业通用落地方式为主算法+辅助算法组合：以EDD保交期为核心，搭配SPT优化生产效率，再用CR值筛选紧急插单、Slack均衡产能，多重算法互补，既保障交付底线，又提升整体生产效益。

Q3：这些算法听起来偏理论，一线PMC不会公式、不会计算，能不能直接落地套用？

核心答案：算法底层是理论逻辑，落地无需手动计算，核心是吃透规则、借助工具自动套用，零基础PMC也能直接落地。很多现场PMC误以为排产算法需要手动算公式、算比值，门槛极高，其实完全不用。本文讲解的四种算法，核心价值是统一排产逻辑、明确判定标准，解决以往凭经验、凭感觉排产，导致排产混乱、争议不断的问题。实际工作中，无需人工计算，可通过ERP、MES、排产工具，直接录入订单交期、工序工期、剩余时间等基础数据，系统即可依托四种算法逻辑自动完成优先级排序、产能排布。PMC只需掌握每种算法的适用场景，根据工厂当下生产目标切换对应规则，就能告别经验排产，实现标准化、科学化、可追溯的智能排产，大幅降低排产失误率和现场协调成本。