很多PMC每天最头疼的不是不会排计划而是所有人都觉得自己的订单最急。销售说客户催得厉害老板说这个客户不能丢生产说换线太频繁采购说关键料还没到仓库说半成品堆不下。最后PMC夹在中间排早了现场不认排晚了销售追责今天刚排好的计划明天一个插单又要全部重排。真正难的不是把订单塞进生产日历而是当交期、产能、物料、设备、插单同时冲突时PMC到底依据什么决定谁先做、谁后做。这也是排产算法的价值。最短工期解决的是现场怎么快速清理积压最早交货期解决的是客户承诺怎么守Slack解决的是哪些订单看似不急实际上已经没有多少缓冲CR值解决的是当前订单到底紧急到了什么程度。但算法只是判断顺序不是自动替PMC做决定。基础数据不准、工艺路线不清、剩余工时估错、现场进度不回传公式算得再漂亮也只能得到一个准确的错误答案。所以这4种算法不需要死记硬背。真正要掌握的是它们分别在回答什么问题以及什么时候该用。​文中用到的简道云生产管理系统在这里https://s.fanruan.com/b9zng一、最短工期最短工期也就是SPTShortest 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、群消息和电话反复确认。二、最早交货期最早交货期也就是EDDEarliest 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比单纯看日期更有价值。三、SlackSlack可以理解为订单还剩多少时间缓冲。最基础的计算方式是Slack 距离交期的剩余时间完成剩余工序所需时间例如一个订单距离交期还有5天剩余生产需要3天Slack 53 2天。另一个订单距离交期还有3天剩余生产只需要0.5天Slack 30.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则比较现在剩下的时间和剩余工作量是否匹配。可以把它理解成订单当前紧急程度的比例信号。通常可以这样判断CR1当前还有一定缓冲CR≈1剩余时间基本刚好够做完CR1按当前节奏已经存在明显延期风险。例如两个订单Slack都只剩1天。订单A还剩2天工作订单B还剩8天工作。两者都是只剩1天缓冲但危险程度不同A的CR是0.5B的CR只有0.125。B需要更早进入处理范围。所以CR比Slack更适合做滚动优先级判断。尤其订单数量多时PMC不可能每天人工分析所有订单可以通过CR值快速筛出当前最紧迫的订单。但CR值不能只算一次。周一CR1.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值帮你快速识别已经进入危险区的订单。但算法的准确性最终取决于数据是否真实。订单、工序、进度、物料、设备、异常都不准确再高级的排产规则也只能算出错误的优先级。所以好的排产不是把公式算得多复杂而是让每一次让单、插单、调整都有清晰依据。QAQ1四种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只需掌握每种算法的适用场景根据工厂当下生产目标切换对应规则就能告别经验排产实现标准化、科学化、可追溯的智能排产大幅降低排产失误率和现场协调成本。