用数据解释一张订单为什么延期

前面四篇分别留下了产品变更、经营订单、执行过程和仓储记录。到了订单复盘会上，这些记录需要回答一个具体问题：客户为什么晚收到了货，下一次应该在哪个环节提前处理。

本文继续用 SO-200 的 200 台风机，将 40 台旧配置、160 台新配置以及两台返工产品放进同一条履约链。为分析交期，另加一组明确标注的模拟时间；所有数量、日期、判断和图示都是参考案例，不对应真实客户或岗位责任结论。

先确定延期在比较什么

客户要求、确认承诺和内部计划分别保存

“原来答应哪天交”至少可能指客户最初要求、双方确认的日期，或计划员排出的日期。还要说明交付节点是离厂发运、到达约定地点，还是客户签收。用计划完工日与实际签收日直接相减，会把正常仓储和运输时间一起算成生产延期。

本例约定全量 200 台同批发运，以客户签收作为交付完成节点，不采用分批交付。新增时间轴用 D0 起的连续自然日表示，所有日点采用同一日界，不对应此前各篇 JSON 里的演示时间，也不模拟周末、节假日与班次截单时间。

基线或记录	本例设定	后续怎么使用
客户最初要求	D6 签收 200 台	保留需求来源，不替代已确认承诺
首个确认承诺 C0	D7 签收 200 台	本篇延期指标的固定比较基线
内部计划 P0	D5 全量可发、D6 发运、D7 签收	核对各阶段偏差及计划依据
实际履约记录	D8 全量可发、D9 发运、D10 签收	回顾实际发生的过程

因此，本例相对 C0 晚了 3 个自然日；相对最初要求则晚了 4 日。两个数字回答不同问题，报告里都要带上比较基线，不能挑一个更好看的数字。

Microsoft 的销售交期计算说明区分按提前期、ATP 和 CTP 等方法计算交期，并说明计算状态与计划运行有关。产品算出的可承诺日期仍有输入和配置前提，项目需要另行确认哪些字段代表客户已接受的业务承诺。

修改承诺不能覆盖此前的履约历史

如果后续客户同意改为 D10，应保存新的承诺版本 C1、批准与沟通依据、适用数量，以及它取代哪个版本。按 C1 衡量可以得到另一种结果，原始 C0 的偏差仍需保留。

内部将计划从 P0 改成 P1，也不等于客户已经接受新交期。系统里如果只剩一个不断被改写的日期字段，事后会很难区分最初计划是否合理、风险何时出现、谁在什么时候知道了什么。

本例在 D10 已签收后做回顾分析。若当前时间只有 D6，D10 只能是预测日期，不能填进“实际签收”字段。预测应标明所用计划、计算时点、未满足条件与尚未确认的部分。

把 200 台产品接到同一条履约证据链

数量范围沿订单行、工单和单件逐级关联

SO-200 的供给包含旧配置 MO-0040 的 40 台，以及新配置 MO-0160 的 160 台。新配置范围中，138 台首轮通过，20 台晚开工后通过，另 2 台经过返工再检。最终合格的不同产品仍为 200 台。

工单报工、成品收货、发运明细与客户签收要能够关联到这组产品或可核对的数量分配。一个销售订单关联多张工单、多次收货或多个包装单元时，需要保留映射；不能把数据库查询后的重复行直接求和。

需求与供给的关联也有时点。Microsoft 的净需求与需求关联说明展示了计划如何用供给覆盖需求，并要求选对计划、在供需变化后更新计算。复盘应取当时采用的关联与实际履约记录，今天重新运行得到的供给分配，不能自动充当过去的依据。

每个事件保留对象、业务时间和读取时间

工程批准何时完成，物料何时可领，人员与设备何时满足条件，产品何时通过终检，仓库何时交给承运人，这些事件来自不同系统。关联它们时，至少保留来源、对象身份、数量范围、适用版本、业务发生时间和读取时间。

接口接收时间也应单列。MES 在 D7 完成报工、ERP 在 D8 才收到消息，可能表示同步迟到，不能直接推断车间多生产了一天。需要核对原事件、接收记录、目标处理结果以及必要的人工证据。

供应商承诺、实际发货、仓库实收和物料可领也有不同含义。Microsoft 的采购日期说明分别列出请求与确认的发货、收货日期。判断是否影响开工，还要继续查询检验、库存状态、配送与其他前置条件。

订单、版本与履约证据怎样关联独立窗口查看 ↗

时间之间有空白时先列为待核对区间

从异常登记到返工完成相隔四天，不代表四天都花在维修。期间可能包含等待处置、等料、等返工工位、执行、再检和待放行。没有这些事件，就只能报告已知起止点和缺少的记录。

设备日历显示可排产，也未必能证明现场当时立即可用；还应核对实际占用、故障、工装与人员限制。反过来，一条停机记录与延期同时发生，也不足以认定它延长了这张订单的最终交付。

按实际数量和前置条件还原时间线

为前文案例增加一组回顾用时间

下面的时间只用于本篇推演。尾批 20 台的装配资源与两台产品的返工工位分别计算；共同资源竞争和其他订单暂不纳入这个简化模型。可发后的次日安排发运，再过 1 日签收，两个间隔在本例中固定。

对象与节点	计划 P0	实际记录	需要核对的证据
旧配置 40 台就绪	D3	D3	旧工单与成品状态
新配置首批 140 台首轮结果	D4 全部通过	D4 有 138 台通过、2 台挂起	单件与首轮终检记录
尾批 20 台的物料可领	D4	D5	批次放行、状态与配送条件
尾批 20 台的装配资源可用	D4	D6	资源日历与实际占用记录
尾批 20 台放行	D5	D7	开工、执行与终检记录
首批中 2 台的最终放行	D4 首轮通过	D8 返工再检后通过	处置、返工与再检记录
全量 200 台满足可发条件	D5	D8	全部单件及仓储交付条件
200 台发运	D6	D9	出库复核与承运交接
200 台客户签收	D7	D10	签收数量与有效凭据

本例进一步假设，除表内条件外，包装、单据、交付限制等其他可发前置已及时满足。实际项目要把这些条件补入，不能仅凭生产放行就认定订单已经可发。

数量与前文一致：D7 尾批完成后，已有 40 台旧配置和 158 台新配置就绪，仍缺两台返工产品；D8 两台放行后凑齐 200 台。两件替换支架增加了材料耗用，没有增加整机产量，也没有形成两台整机报废。

并行条件取较晚时点，不能直接累加晚到天数

尾批需要物料与装配资源同时满足条件。物料从计划 D4 推迟到 D5，晚 1 日；资源从 D4 推迟到 D6，晚 2 日。尾批最早开工时点是两者中较晚的 D6，相对原计划晚 2 日。

把 1 日和 2 日加成 3 日，会把重叠等待重复计算。尾批再经过本例固定的 1 日执行与检验，到 D7 放行；这仍然不能直接决定整张订单的可发时点，因为另两台返工产品到 D8 才满足条件。

尾批开工 = max(物料可领 D5, 装配资源可用 D6) = D6
尾批放行 = D6 + 1 日 = D7
全量可发 = max(旧 40 台 D3, 新 138 台 D4, 尾批 20 台 D7, 返工 2 台 D8) = D8
实际签收 = D8 + 仓储交接 1 日 + 运输 1 日 = D10
相对 C0 的延期 = D10 − D7 = 3 日

这段计算表达固定前提下的依赖关系，没有复现完整车间调度。若允许部分数量转入后续工序、共享资源需要重新排程，或者发运存在截单时间，就要按实际对象与日历重新建模。

并行条件怎样共同决定全量可发时点独立窗口查看 ↗

Microsoft 的计划延期说明介绍了物料、产能、提前期和参数如何参与计算最早履行日期。这样的计算是给定输入下的结果，不应直接拿来替代实际事件复盘，也不能假定所有层级的影响都会自动完整传播。

发生了等待，还要继续核对它怎样影响交付

将事实、依赖判断和原因假设分别列出

本例可以确认的事实包括：物料 D5 才可领、装配资源 D6 可用、两台返工产品 D8 放行。按当前模型，可以判断全量可发受 D8 的两台产品约束。

“供应商为什么晚到”“资源为什么被占用”“两台产品为什么损伤”还需要进一步证据。工程切换、供给变更、检验、排程、现场动作可能共同参与，不能从最终约束直接跳到“全部由质量部门导致”。

原始故障、发现时点、限制措施和恢复动作也要分开。质量挂起可能是在阻止不合格产品交付；若要改进交期，应继续查缺陷形成、处置等待和恢复资源，不能把正常执行的质量控制本身当作应当取消的障碍。

用条件重算判断改进是否会改变交付

在本例固定其他前提的情况下，可以分别替换一个条件，观察签收日是否变化。它回答的是这组假设下的结果差异，不计算岗位责任，也不等于已经找到了完整根因。

条件重算	保持哪些其他条件	计算签收日	相对实际 D10 的变化
物料恢复为 D4 可领	资源仍 D6、返工仍 D8 放行	D10	0 日
装配资源恢复为 D4 可用	物料仍 D5、返工仍 D8 放行	D10	0 日
两台无需返工，D4 首轮合格	尾批仍 D7 放行	D9	提前 1 日
上述条件均恢复为 P0	仓储和运输间隔不变	D7	提前 3 日

前两项暂时不改变最终日期，说明还有别的条件覆盖了改善空间，不代表物料或资源问题从未影响过生产。单项变化的效果也不能简单相加，得出整张订单的责任分摊。

真实重排还可能改变资源占用、批量与其他订单的交期。若尾批和返工共用同一工位，上表固定独立资源的前提就不再成立，需要把相关任务一起重算。本例不将这些未建模影响隐藏在一个精确的“原因占比”里。

恢复方案与预防动作使用不同验收标准

当时的恢复方案可以包括缩小返工范围、寻找合格资源、提前准备交接，或评估经客户确认的分批交付。每个方案都要重新检查物料、工艺、质量、资源、物流和授权条件。业务规则改变后，原来的整批计算也要保留，另建方案版本比较。

预防动作则可能是提前识别工程切换的缺口、完善资源日历、缩短处置等待、改进装配控制，或设置更早的风险提示。验收要观察它是否在后续订单中减少同类阻断、缩短实际等待或提高预测可靠性，不能只以多了一张看板作为完成依据。

将分析做成可复核的记录和 Agent 输出

分析结果包含范围、基线、证据与未知项

每次运行保留分析时点和证据快照，区分“当时能够知道什么”和“事后补齐了什么”。本例回顾使用相对日，下面的 JSON 也只表达概念结构，不对应任何厂商接口：

{
  "analysis_id": "SO-200-C0-REVIEW-01",
  "mode": "retrospective",
  "scope": {
    "sales_order": "SO-200",
    "plant": "A",
    "quantity": 200,
    "unit": "EA",
    "delivery_rule": "single_full_delivery"
  },
  "time_basis": "relative_calendar_days_same_cutoff",
  "promise_baseline": "C0",
  "plan_baseline": "P0",
  "confirmed_receipt_day": 7,
  "actual_receipt_day": 10,
  "delay_days": 3,
  "evidence_refs": [
    {"system": "ERP_A", "object": "SO-200-C0", "kind": "confirmed_promise"},
    {"system": "WMS_A", "object": "TAIL-20-AVAIL-D5", "kind": "material_available"},
    {"system": "MES_A", "object": "TAIL-20-RESOURCE-D6", "kind": "resource_available"},
    {"system": "MES_A", "object": "RW-0021-RELEASE-D8", "kind": "rework_released"},
    {"system": "DELIVERY", "object": "SO-200-POD-D10", "kind": "customer_receipt"}
  ],
  "unknowns": ["详细等待区间的原因分解", "模型外共享资源与其他订单的影响"]
}

这些引用编号为本篇新增的模拟标识。实际记录还需包含可定位的来源对象、查询范围、业务与读取时间、版本及必要的凭证校验信息。未知项保留为未知，不能用零值或一段推测补成完整答案。

Agent 先整理履约状态，再给出有条件的判断

Agent 可以先回答“截至当前时点，200 台分别到了哪里，距离已确认交付还缺哪些条件”。查询按订单供给、适用版本、单件状态、库存交接与物流凭证逐级展开，来源不可用时列明影响范围。

做历史复盘时，Agent 还需要比较原始承诺、当时计划与实际事件，标出同步迟到、缺失与冲突。给出“如果提前某个条件会怎样”的答案时，应同时返回被替换的条件、保持不变的前提，以及尚未建模的约束。

不允许把查询到的最新日期覆盖旧基线，也不能把“暂未读到签收凭证”写成“客户尚未收到”。修改客户承诺、调整订单优先级、释放库存、批准返工和触发发运都有各自的业务权限与前置条件，分析结论只提供处理依据。

验收用例覆盖正常、冲突与证据缺失

验收情形	应得到的结果
客户要求 D6、确认 C0 为 D7、实际 D10	分别计算并标出基线，本篇相对 C0 为 3 日
后续客户接受新承诺版本	保留原承诺偏差，单独比较新版本，不覆盖历史
40 台旧配置与 160 台新配置、多张单据关联	最终不同产品去重为 200 台，范围不漏不重
物料晚 1 日、资源晚 2 日且并行等待	本例尾批开工晚 2 日，不相加为 3 日
尾批 D7 放行，但两台返工到 D8	全量可发为 D8，不能按多数产品完成时点判断
消息晚一天到达目标系统	区分业务发生与接收时间，不自动认定现场多耗一天
当前只有 D6，却有预计 D10 的日期	标为预测，不伪造实际发运或签收
返工区间缺少详细过程记录	保留起止事实和未知区间，不直接归给某个岗位
单独改善物料日期未改变最终签收	报告模型条件与其他约束，不认定物料问题无影响
来源失败、时区冲突或数量范围不一致	标为待核对，停止生成无依据的精确归因

首批四套系统已经能串起一份交付复盘，但产能、换型、插单和共享资源还只保留了简化条件。下一篇进入 APS，继续拆这些条件怎样进入排程、重排和方案比较。相关系统可以回到制造业数据地图，选题记录保留在全景目录。