InfiniSynapse
什么是准时交付？
准时交付（OTD）是指：相对于约定的需求日、承诺日或合同日期，在批准的交付窗口内完成的合格交付，占统计期内所有应交付对象的比例。
这个简短定义包含四个政策选择：哪些对象进入统计、以哪个日期为准、哪个业务事件算“交付”、允许窗口有多宽。没有固定这些选择，供应商、客户、工厂、产品或期间之间的 OTD 百分比就不可比。
OTD 可用于供应商评分卡、客户服务监控、承运商与线路分析、生产到客户的交接，以及承诺日期治理。它回答一个范围明确但重要的问题：定义好的对象是否在应到时间到达？
准时交付率公式
分母通常应按统计期内应到期的对象确定，而不是按该期实际收货的对象确定。如果 7 月报表只统计 7 月收货，那么本应 7 月到货但到 8 月仍未交付的订单可能同时从分子和分母消失。按到期日建立队列，才能保留逾期未结对象。
对每个合格对象，可用双边规则判定：实际事件时间必须落在“基准日期减允许提前量”与“基准日期加允许延迟量”之间。若要求必须当天到达，则把两侧容差都设为零。
先写清指标合同
一个可长期使用的 OTD KPI，需要一份让分析、运营、采购、销售、财务和供应商都能以同一方式理解的指标合同。应将合同与仪表板放在一起，并在政策变化时进行版本管理。
客户需求日、供应商确认日、合同承诺日、计划到达日或预约日。
发运确认、承运商到达、签收证明、入库过账或客户验收。
提前与延迟容差、时区、截点、周末、节假日及站点日历。
订单、订单行、计划行、发运或数量；以及排除、取消、冻结和期间规则。
需求日期与承诺日期怎么选
客户需求日衡量是否满足客户需要；供应商确认日或承诺日衡量是否兑现已接受的承诺。两者都有价值，但回答的问题不同。供应商可能兑现了一个宽松承诺，却没满足客户最初需求；也可能未满足不现实的需求日，却按双方确认日期交付。
不要用最新修改日期静默覆盖原始承诺。如果日期允许变化，应保留历史并定义冻结点，例如订单接受时的承诺日，或交付前七天的承诺日。承诺日期的迟改应单独跟踪，否则反复重排可能让服务指标变好，却没有改善实际物流。
定义“实际交付”的业务事件
“准时发运”不等于“准时交付”。发运确认衡量仓库出库，承运扫描衡量运输节点，签收证明衡量到达，入库过账还受客户操作影响，验收则可能在检验后才发生。应选择最贴近服务承诺的事件，并披露数据来源。
例如，Oracle 的供应商绩效文档把预计到达日与首次收货日比较；SAP 文档则展示了其他有效配置，包括把需求发运日或交付日与 ASN 的发运日或交付日比较，并设置提前和延迟窗口。重点不是哪套系统永远正确，而是比较的日期对必须明确。
订单、订单行与数量加权 OTD
| 口径 | 公式单位 | 适合场景 | 注意事项 |
|---|---|---|---|
| 订单 OTD | 合格订单 | 客户承诺视角 | 一条晚到可能使整单失败 |
| 订单行 OTD | 订单行或计划行 | SKU 与供应商诊断 | 大订单行数权重更高 |
| 数量加权 OTD | 应交与准时数量 | 体量与物料流 | 高体量品项可能主导结果 |
| 发运 OTD | 发运或停靠 | 承运商与线路运营 | 拆分发运会改变计数 |
不要直接平均分母不同的分组百分比。应先汇总准时数量与合格数量，再相除。当管理层需要客户级结果、运营人员需要诊断明细时，可以同时报告多个粒度。
交互式准时交付率计算器
输入同一到期队列、同一规则下的汇总数量。计算器并排展示订单、订单行和数量加权结果，让权重差异清晰可见。
该工具验证算术，不验证日期逻辑。发布前应抽查记录，并确认每个分子都是对应分母的子集。
OTD 完整计算示例
某企业 6 月共有 250 个到期合格客户订单。按照冻结承诺日与签收证明口径，218 个在批准窗口内到达。订单 OTD 为 218 ÷ 250 × 100 = 87.2%，还有 32 个迟到或不合规订单。
这些订单含 600 条合格订单行，其中 552 条准时，行 OTD 为 92.0%；合格数量为 12,000 件，其中 11,040 件准时，数量加权 OTD 也是 92.0%。订单率更低，说明延迟集中在较少订单中，可能是小型多行订单，或整单因一条晚到订单行而失败。
提前交付不一定等于准时
“只要不晚于截止日就算准时”的单边规则很简单，却可能奖励造成月台拥堵、仓储成本、劳动力扰动、库存持有成本或提前占用资金的交付。双边窗口更能体现“按预期时间到达”的运营含义。
示例：承诺日为 6 月 12 日，允许提前一个自然日，不允许延迟。6 月 11–12 日属于准时；6 月 10 日过早；6 月 13 日迟到。如果采用工作日逻辑，应使用正确的站点日历与时区，而不是直接减时间戳。
一致处理部分交付与拆分发运
如果 100 件中有 80 件在承诺日到达，剩余 20 件随后到达，可以有多种合理结果：整单口径可因未齐量而判失败；数量加权口径可给 80 件准时信用；行口径可逐行评分；首次收货口径甚至可能判为通过，但无法说明是否完整。
应选择与服务承诺一致的规则，并建立稳定的订单—订单行—计划行—发运—收货—数量父子模型。除非分母本来就是发运次数，否则不要把每次拆分发运当成新的达标机会。
准时交付与 OTIF 的区别
OTD 衡量“何时”，OTIF 同时衡量“何时”和“多少”。如果订单在承诺日到达但仅交付 80% 数量，它可能通过纯日期 OTD，却会在 OTIF 中失败；齐量但迟到的订单则两者都失败。
当团队需要分别诊断时间与齐量问题时，应保留两个 KPI；当客户承诺要求二者同时满足时，再使用组合指标。关于齐量规则、数量容差和联合通过逻辑，请阅读独立的 OTIF 指南。
准备可审计的 OTD 数据
至少应保留订单与订单行标识、客户或供应商、产品、站点、需求日、确认承诺日及其历史版本、计划数量、发运标识、事件时间、收货或签收证明时间、实收数量、状态、取消与冻结标记、时区、日历和原因代码。
将时间戳统一到约定业务时区，同时保留原始值；去除重复扫描与收货；区分空值与“尚未交付”；应用排除前先映射状态代码；记录每行使用的政策版本。可信任比例之前，应把合格数量与源系统到期订单队列对账。
七步建立 OTD KPI
- 明确服务问题。供应商可靠性、客户交付、承运到达和仓库发运需要不同事件。
- 冻结基准日期规则。选择需求、承诺、合同或计划日期，并保留修改历史。
- 定义事件、窗口、日历与时区。同时明确提前与延迟容差。
- 选择粒度与分母队列。优先按期间到期对象统计，并包括逾期未结。
- 记录排除项。一致处理取消、客户冻结、无效日期和批准例外。
- 对账并抽样。将准时、延迟、过早、未结、部分、改期及排除记录追溯到源事件。
- 同时发布比例与诊断。展示分母、缺失数据量、提前/延迟分布、趋势与原因结构。
常见 OTD 计算错误
- 按实际收货月确定分母，导致尚未交付的逾期订单消失。
- 在同一趋势中混用需求日、原始承诺、最新承诺、发运、收货和签收日期。
- 未考虑月台和库存影响，就把提前交付全部算作成功。
- 在供应商或期间之间改变部分交付或排除规则。
- 直接平均百分比，而不是汇总分子与分母。
- 发布目标时不披露粒度、窗口、分母或数据完整性。
脱离合同、产品关键性、交期、市场和指标设计，不存在通用的“良好” OTD 百分比。只有在定义一致后才能做基准比较，再结合客户要求、基线能力、风险与改进经济性设定目标。
用原因分析改善准时交付
比例只能指出差距，不能解释原因。应按供应商、客户、产品族、站点、线路、承运商、计划员、承诺跨度、订单规模、优先级和延迟天数分层，并结合缺料、产能约束、质量冻结、计划变更、拣选延迟、错过承运截点、运输中断、客户预约、主数据错误和收货过账滞后等原因代码。
优先级不仅看事件数量，还要看客户影响与可挽回体量。可用控制图或稳定趋势带区分持续性流程变化与普通波动。针对最大的可行动原因指定负责人和截止日，并验证措施是否改善后续到期队列，同时没有增加过早交付、加急、库存或成本。 准时交付率只衡量时间表现；当客户承诺同时要求按时和足量时，应结合 OTIF 准时足量交付率使用联合通过规则。若需把交付结果连接到订单、物流、库存与供应商事件，可通过 供应链数据分析继续追踪端到端原因。
InfiniSynapse 如何支持 OTD 分析
InfiniSynapse 可作为分析层，连接订单导出、发运文件、收货记录、供应商评分卡、备注和异常证据。分析人员可以比较供应商、客户、产品、站点、线路和原因，检查异常值，并为运营复盘准备有治理依据的摘要。
边界：这里描述的是分析支持，而不是物流执行。InfiniSynapse 不被描述为订单管理系统、WMS、TMS、供应商门户、派车排程、承运控制、自动通知工作流、库存分配、交付确认或 ERP 回写机制。
把交付记录转化为可审计的 OTD 视图
准备订单行、需求与确认日期、日期变更历史、发运与收货事件、签收时间、数量、取消、冻结、站点日历、供应商或承运商字段和原因代码，再使用 InfiniSynapse 探索关联证据并调查延迟模式。
在线体验 InfiniSynapse准时交付常见问题
它是相对于约定基准日期，在批准窗口内完成的合格交付占全部到期合格对象的比例。
用统计期内准时的合格交付除以该期应交付的全部合格对象，再乘以 100。
只有政策允许时才算。双边窗口可以把过早交付判为不合规。
可以要求整单齐套、逐行评分或按数量加权，但必须记录规则并保持稳定。
OTD 检查时间，OTIF 同时检查时间与齐量。
不是。这里将其定位为分析层，而非 OMS、WMS、TMS、供应商门户或 ERP 执行工具。
使用前注意
本文提供可调整的指标框架，不是通用会计或合同标准。当地协议、国际贸易术语、客户日历、系统行为与监管义务可能要求不同定义。在把 OTD 用于激励或处罚前，应与运营、采购、销售、财务、法务及相关贸易伙伴共同确认政策。
权威来源
以下资料用于核对本文中的定义、计算方法与实施建议：