生产排程发生变化，怎样看清受影响的订单

先记住原计划和这次变化

排程变了以后，先保存变更前的订单日期、工序顺序、资源分配和数据截止时间。没有这份基线，团队只能看到新结果，很难回答哪些订单被提前，哪些订单被推迟，变化究竟来自新情况还是数据刷新。

这次变化也要单独记录。常见来源包括急单进入、数量或交期改变、设备停机、班次调整、物料到货变化和生产进度更新。记录至少要说明变更对象、生效时间、来源和确认人。几项变化同时进入时，还要保留各自的记录，免得最后只剩一句计划又变了。

分析范围随之固定。工厂、资源、订单状态、计划时界、冻结范围和时区都属于这份记录。Microsoft 的主计划文档说明，计划时界、冻结与 firming 设置会改变计划处理的范围。具体字段属于 Dynamics，其他系统仍要核对自己的定义。

把已经发生的生产事实核准

新排程要从当前事实出发。已经开工的工序、实际完成数量、实际工时、物料消耗、异常和完工状态，都会改变剩余工作。Microsoft 的生产反馈文档把这些内容列为执行反馈的一部分，并说明反馈可以通过生产日志或生产现场执行界面更新。

反馈记录进入分析以前要先核对来源和时间。工序已经完成却仍保留全部剩余负荷，会把后续产能压得过紧。现场已经消耗时间，系统还没有收到记录，又会让候选方案显得过于宽松。缺失信息应列出来，不能静默当成零。

停机、缺勤和临时换线规则也要经过确认。计划日历代表模型里的可用时间，现场事实可能已经改变。分析记录应把已确认事实与待核项目分开，让计划员知道哪些判断有记录支持，哪些地方还要回到现场确认。

分清刷新数据和重新计算

刷新与重新计算解决两件不同的事。刷新把新的工单、属性、资源能力和可用时间带入当前排程。重新计算根据这些输入安排工序，检查已经表示的约束，再形成新的候选排程。

Oracle 的生产排程文档把 refresh 与 solve 分开。文档还提醒，刷新可能清除当前排程解，日历事件可能移动工序，需求与供应的关联也要等求解完成后才准确。这些行为属于 Oracle 产品，不能直接套到其他系统，但它说明了一件很实在的事。团队应当知道看到的是刚刷新的数据，还是已经基于新数据完成计算的方案。

计划员有时会先刷新，检查订单和资源变化，再决定是否计算新候选。这样可以在输入明显有误时停下来修正。分析记录也应保留刷新状态和计算时间，避免把一份旧候选误当成当前判断。

沿着工序和资源查受影响范围

一项变更怎样传到其他订单，要看工序先后和资源竞争。NIST 的制造活动模型指出，某一步延误可能影响同一作业的后续步骤，也可能影响等待同一资源的其他作业。路线、资源、物料、工装、维护和人员日历则共同进入详细排程。

Oracle 的甘特分析把晚工单、晚需求、资源利用、换型和上下游关系放在同一个排程分析环境里。计划员可以从变更点往后查，看看哪道工序失去原来的时段，哪张订单占用了同一资源，哪个完成日期因此改变。

关联关系只能缩小调查范围。一个订单排晚了，原因可能来自资源冲突、物料时间、固定工序、已确认生产或路线数据。系统中的关系也可能漏掉现场规则。影响清单需要保留所用数据和规则，计划员再确认原因是否成立。

订单日期或优先级变化

查看该订单的新位置，以及原计划中使用相同资源和相邻时段的订单。

设备停机或班次变化

查看减少的可用时间落在哪些期间，并追到原先占用这些期间的工序。

物料或供应时间变化

查看哪些工序失去开工条件，以及资源空档会不会被其他工作重新占用。

报工和完工进度变化

先冲减已完成工作，再检查剩余工序、后续关系和资源释放时间。

用同一份基线比较候选方案

团队知道受影响范围以后，才适合比较处理办法。候选可以调整工序顺序，改用符合条件的资源，拆分数量，移动未保护的工作，或采用已经批准的班次变化。每一版都要使用同一数据截止时间和同一订单范围，随后只改动已说明的规则或条件。

Oracle 对 solve 与 repair 作了产品级区分。手工改序、移动工序和更换资源后可以修复排程，need-by date、最早开工、firm 状态、库存或供应发生变化时则需要重新求解。其他产品可能使用不同名称，文章可以据此说明变更程度不同，所需计算也会不同。

Microsoft 的主计划资料允许不同计划服务日常运行与模拟。它提供了一个可参考的控制思路。候选方案应与当前基线分开，比较时同时显示订单日期、资源分配、工序顺序和风险变化。只展示新甘特图，很难看出代价落到了谁身上。

把复核、确认和发布分开

Oracle 的生产排程流程依次列出创建、刷新、求解、复核调整和发布。这个顺序提醒团队，候选结果形成以后仍有复核环节。计划员需要检查冻结订单、客户优先级、现场限制和数据缺口，企业授权人再决定是否采用。

Microsoft 的 planned order firming 文档说明，在 Dynamics 中，firming 可以把计划订单转成实际的生产、采购或调拨订单。这个动作会改变业务记录，和查看一版候选的后果不同。Kavop 当前公开边界不包括自动创建订单或自动写回 ERP 与 MES，文章不能把计划员确认写成系统已经完成发布。

一份可复核的候选应保留版本、创建时间、所用快照、变更项、受影响订单和待确认问题。后来若采用另一版，团队还能查清当时比较过什么。授权决定仍留在人手里。

把变更影响写成逐单清单

影响清单要把基线和候选放在一起，逐单列出日期变化、被移动的工序、资源变化、首个影响位置和仍待确认的数据。没有变化的订单也应留在比较范围里，团队才能知道这次复核覆盖了谁。

几种处理候选可以沿用同一组字段，查看原有订单日期、资源和顺序怎样变化。结果只覆盖已经提供的订单、路线、日历、物料信息和规则。没有进入模型的现场条件继续交给计划员补充。

Kavop 当前使用公司提供的快照形成只读候选，并解释确认范围内的晚单、瓶颈、产能、物料和插单风险。候选由计划员复核，企业授权人决定后续动作。文件或快照接入本身不证明系统之间已经完成实时同步、冲突处理或生产记录写回。