急单插进来，原有订单会受什么影响
急单能不能接，不能只看它自己最早哪天做完。它占用的机台时间、物料和队列位置来自同一张生产计划。计划员要把急单放进当前订单一起重算，再看哪些原有承诺发生了变化。
先把一句很急变成明确的计划输入
急单进入排程以前，团队先要写清订单、数量、需求日期或交期、优先级，以及谁批准了这个优先级。不同系统可能使用订单优先级、need-by date、requested date 或人工覆盖值，落到客户现场时要按真实字段解释。
SAP 的文档说明订单优先级可由计划员修改，并用于优先级相关排序。Oracle 的文档说明 need-by override 等日期输入发生变化后需要重新求解。两者都把计划输入交给计算，却不会替企业判断哪个客户最重要。销售说一句很急，也不等于系统应该自动把它放到所有订单前面。
这一步看起来简单，实际上决定了后面在比较什么。优先级没有授权，候选方案只能说明一种计算结果，不能直接成为对客户和车间的正式指令。
先保留当前排程，再运行急单方案
影响分析需要一份不插单的当前排程作为基线。随后加入急单，保持同一数据截止时间、计划范围、资源日历和约束口径，再运行候选方案。Microsoft 支持多套主计划用于模拟，Siemens 的官方资料也说明计划员可以比较多个假设情景。
两张来自不同时点的排产表很难直接比较。中间如果同时更新了停机、到料、工时或其他订单，看到的日期差异就不能全部归到急单上。基线版本、候选版本和每一项额外变化都要留下记录。
第一轮只读验证可以沿用这个办法。凯沃普保留当前排法，再用同一时点的一组订单生成急单候选方案。这里验证的是影响能否被解释，文件对照还不能证明实时同步或正式集成已经完成。
有限产能让急单和原订单争同一段时间
有限产能计划会考虑资源已经被占用的能力。急单需要的关键机台在目标时段没有剩余空位，系统就要把它放到别的时段，或者移动符合规则的其他任务。Microsoft 的有限产能文档也说明，剩余能力不足时，计划日期可能后移。
因此，只为急单单独找一个理论空档不够。工序有前后关系，机台有班次和停机，原订单也已经占用了时间。重算范围要包含会争用这些资源的订单，才看得到急单日期和原有订单日期怎样一起变化。
急单不会必然推迟所有订单。它也可能落在现有空档，使用替代资源，或者改变一部分订单的顺序。结果取决于工艺、日历、已占用产能、优先规则、物料和计划时界，必须查看这一版的实际差异。
受影响订单要逐张列出来
候选方案完成后，先比较每张原订单的开始日、完工日、资源和顺序。日期变晚、变早、换了资源、换了队列位置或改变物料依赖的订单，都应进入受影响清单。保持不变的订单也可以保留，方便团队检查比较范围，并说明哪些订单没有变化。
Oracle 的生产排程文档提供晚工单、晚需求、资源利用、换型时间、短缺和供需 pegging 等分析方式。这些视图能帮助计划员追踪变化，但筛选范围和供需匹配规则也要看清。当前甘特图没有显示某张订单，不能据此认定它完全不受影响。
一张实用的差异表至少写出基线完工日、候选完工日、首个变化工序、主要约束和建议动作。日期变化只代表当前计划结果发生了移动。客户交期是否更改，还要由有权承诺的人确认。
资源、物料和换型要分开查
订单变晚以后，先定位它在哪道工序等待哪项资源。资源日历、已经占用的时间、停机、并行设备和替代资源都要核对。全厂平均利用率不高，也不能证明某台关键设备在急单需要的那几天有空位。
物料还会产生另一组影响。Oracle 的物料可用性文档说明，提高一张工单的分配优先级时，物料可能从较低优先级工单转移，并可以在实施前查看其他受影响工单。这是 Oracle 产品中的工作方式，不能直接写成凯沃普已经具备自动分料和事务写回。
顺序变化也可能改变换型或清洗时间。Oracle 和 Siemens 都记录了顺序相关换型规则。工厂只有在提供真实换型矩阵或现场规则以后，候选方案才适合计算这项差异。缺少规则时，应该把它列为待核条件，不能让系统从订单名称猜出换型代价。
已经固定或开工的任务不能悄悄移动
近期计划往往有一段相对稳定的区域。任务可能已经 firm、发布、备料或开工，也可能处于固定区或冻结区。SAP、Microsoft 和 Oracle 对这些状态使用不同术语，作用都与保护近期计划稳定性有关，落地时要映射到工厂自己的系统和流程。
业务仍然可以决定处理例外。此时要单独记录哪些任务被移动，谁批准突破原来的保护规则，车间和相关订单负责人是否收到通知。急单优先级高，不会自动取消这些责任。
如果候选方案为了让急单提前，移动了一项已经开工或已向现场下达的任务，这个方案的风险就和移动一张尚未确认的计划订单不同。差异表需要把状态带出来，不能只展示一条新的时间线。
方案比较要把取舍摆在同一张表里
最低限度需要基线版和急单版。资料和授权允许时，团队还可以检查改交期、换资源、调整班次、拆批、使用已批准替代料，或者后移低优先订单等做法。每种做法都要写明假设，不能把尚未获批的加班或替代料当成已经存在的能力。
每一版使用同一组结果字段。急单预计何时完成，哪些原订单变晚或变早，瓶颈落在哪里，物料有没有短缺，换型时间怎样变化，哪些固定任务需要例外。这样才能看清一张急单换来了什么，又把什么压力留给了其他订单。
这里不使用全局最优一类承诺。某个方案可以让急单更早，同时多影响几张原订单。另一个方案可能保住原有交期，却需要经过批准的加班或外协。系统负责把差异算出来，经营取舍仍要由企业自己决定。
确认方案以后，再决定怎样下达
Microsoft 的计划订单流程包含可选的批准步骤，以及人工、自动和按条件 firm。Oracle 的生产排程则提供独立的 Solve、人工调整和 Release 操作。两套产品的术语与配置不同，都说明排程结果可以在进入生产执行以前接受审查和控制。
凯沃普当前把急单优先级、现场例外和最终版本留给计划员或企业授权人确认。系统提供可比较的方案和风险说明，第一轮使用只读资料，不自动写回生产系统。
一次可审查的急单判断最终应留下四样东西。采用了哪一版，哪些原订单受到影响，哪些风险仍未解决，谁负责向现场下达并向客户确认交期。少了其中任何一项，新的甘特图都还不等于新的正式计划。
参考资料
本文依据以下官方资料说明急单重算、资源与物料影响、换型、计划时界和人工放行。各产品术语和功能范围不同，凯沃普的范围以本站公开的只读验证说明为准。
把当前排程和急单方案放在一起，先看原订单怎样变化。
用同一时点的一组脱敏订单做只读比较，记录急单日期、受影响订单、瓶颈与未解决风险。 风险解释只覆盖纳入范围内的晚单、瓶颈和插单影响。样本结论不能直接外推到全厂。文件或快照接入不证明实时同步、双向集成、冲突处理或生产系统写回已经完成。