统计供应商交付信息及时率，先要明确“应交付信息”和“应到时间”两个前提，再以每条信息为统计单元：用实际到齐时间减应到时间得到滞后时长，及时率等于滞后时长不超过0的条数除以应到信息总条数，缺失项单列为未到条数并计入分母。下面给出一套可直接复算的口径、公式和示例。
要点总览（TL;DR）
- 统计对象是供应商应交付的信息条目，先冻结应交付信息清单，再以单条信息为统计单元，逐条记录应到时间与实际到齐时间。
- 及时率 = 滞后时长≤0的条数 ÷ 应到信息总条数 × 100%；未到项和内容缺失项都计入分母，并单列条数。
- 滞后时长 = 实际到齐时间 − 应到时间，单位统一为小时或工作日；负值表示提前，保留参与均值计算，同时单列提前条数。
- 滞后时长同时报告均值和中位数，均值看总体拖期量，中位数避免个别严重滞后拉偏结论；分母为零时标注无应交付信息，不出比率。
- 及时率只反映信息到达快慢，解读时按供应商和信息类型拆分，区分供应商原因与需求方原因，用趋势和分项验证改进效果。
评估目标：回答“信息到得够不够快”
这套度量针对的是交付信息，例如供应商提供的接口文档、测试报告、物料规格书、变更说明、认证资料等，统计对象是信息到达的时点，实物到货、样品交付不在其中。把对象限定清楚，后续取数才不会把物流签收时间混进信息到达时间。
及时率和滞后时长回答两个不同问题。及时率回答“按约定时间到齐的比例有多高”，是一个频率指标；滞后时长回答“晚到的时候晚了多久”，是一个幅度指标。只看及时率，会漏掉少数严重拖期的影响；只看平均滞后时长，又看不出拖期发生的普遍程度。两个指标并列，才能同时看到面与量。
结果主要用于协同改进：找出哪类信息、哪个环节经常晚到，和供应商一起调整提交节奏、明确评审责任。单期及时率受项目阶段和信息类型影响较大，把它直接当作供应商整体绩效或考核依据，容易把需求方原因造成的延迟算到供应商头上，这一点在解读章节会进一步说明。
指标与范围：统计哪些信息、算哪个时间窗
第一步是确定应交付信息清单。做法是从合同附件、项目计划、供应商协作约定或接口协议中，把“供应商需要向需求方提交的信息”逐条列出，每条记录信息名称、所属项目、供应商、约定交付节点、信息类型。清单应在统计周期开始前冻结版本，中途新增的信息单独标注生效日期，避免事后补录导致分母漂移。
统计单元取单条应交付信息，不按供应商计数，也不按项目整体计数。按供应商计数会让提交信息多的供应商权重被放大，按项目计数则无法区分同一项目内不同信息的到达情况。以条为单元，每条信息有独立的应到时间和实际到齐时间，及时率和滞后时长都可以逐条复算。
时间窗按自然月或项目阶段固定。按自然月统计适合持续协作的供应商，便于形成月度趋势；按项目阶段统计适合节点集中的交付场景，例如设计冻结、样件提交、量产导入。两种口径不要混用在同一张报表里，切换口径时要在报告中注明。
纳入与排除范围需要事先写清。以下情形通常排除或单独统计：需求方发起的范围变更导致原交付节点失效；信息需求被正式取消；应到时间因双方书面确认的排期调整而顺延。排除项要有变更记录支撑，不能凭口头说明剔除，否则分母会被悄悄缩小，及时率虚高。
| 口径项 | 建议定义 | 记录要求 |
|---|---|---|
| 统计对象 | 供应商应向需求方提交的交付信息 | 逐条列入应交付信息清单 |
| 统计单元 | 单条应交付信息 | 每条有唯一编号 |
| 时间窗 | 自然月或项目阶段，二选一 | 报表注明所用口径 |
| 排除项 | 需求方变更、正式取消、书面顺延 | 附变更或取消记录 |
数据口径：应到时间、实际到齐时间与缺失判定
应到时间优先取双方约定的交付节点或计划日期，来源可以是合同附件中的交付计划、项目计划里的里程碑日期，或协作约定中确认的提交日期。取数时要记录来源字段，同一批信息尽量使用同一来源，避免一部分取合同日期、一部分取计划日期造成口径不一。约定只到日期不到时刻的，统一约定当日截止时刻，例如当日18:00。
实际到齐时间取信息完整可用、下游可以直接使用的时点，而非供应商首次提交的时点。首次提交后被打回补充材料、格式不符重传的情况很常见，若按首次提交计，及时率会偏高。判定“完整可用”需要有明确的接收标准，例如文档齐套、字段填写完整、通过需求方接收确认；接收确认的动作和时间要留痕。
缺失项与未到项要区分。未到项指统计截止时仍未收到任何可用信息，计入分母并单列条数；缺失项指信息已提交但关键内容缺失、无法判定为可用，同样计入分母，并在备注中说明缺失内容。两者都不从分母中剔除，否则及时率的分母只包含“已到且合格”的信息，比率失去意义。
时区、工作日与节假日口径在统计前固定。跨时区协作时统一换算到一个基准时区再计算差值；滞后时长以小时为单位时按自然时间计算，以工作日为单位时需明确工作日历和节假日安排，并在报表中注明。同一份报表内不要混用两种单位。
计算步骤：及时率、滞后时长与缺失项的公式
滞后时长按条计算：滞后时长 = 实际到齐时间 − 应到时间，单位统一为小时或工作日。结果为负值表示提前到达，负值保留参与均值计算，同时在报告中单列提前条数，便于观察提前提交的比例。未到项没有实际到齐时间，不参与滞后时长的均值和中位数计算，但计入及时率分母。
及时率公式为：及时率 = 滞后时长 ≤ 0 的信息条数 ÷ 应到信息总条数 × 100%。分母是时间窗内应交付信息总条数，包含已到、未到和缺失项；分子是按时或提前到齐的条数。分子分母都按条计数，单位是条，比率以百分比表示，保留一位小数即可。
滞后时长同时报告均值与中位数。均值 = 已到信息滞后时长之和 ÷ 已到信息条数，反映总体拖期量；中位数把滞后时长排序后取中间值，避免个别严重滞后把均值拉高。两个数差距明显时，说明存在长尾拖期，需要在分项中进一步查看。
分母为零时不出比率，标注“本期无应交付信息”，不要写成0%或100%。数据不可比的情形包括：时间窗内信息类型结构发生大幅变化、统计口径中途调整、排除项比例过高。遇到这些情况，应在报表中注明不可比原因，必要时把调整前后分段统计，而不是直接横向比较。
| 指标 | 公式 | 单位 | 边界处理 |
|---|---|---|---|
| 滞后时长 | 实际到齐时间 − 应到时间 | 小时或工作日 | 负值保留，单列提前条数 |
| 及时率 | 滞后时长≤0的条数 ÷ 应到信息总条数 | 百分比 | 未到与缺失项计入分母 |
| 滞后均值 | 已到信息滞后时长之和 ÷ 已到信息条数 | 小时或工作日 | 未到项不参与 |
| 滞后中位数 | 已到信息滞后时长排序后的中间值 | 小时或工作日 | 偶数条取中间两值平均 |
算一遍：一个月的供应商交付信息统计示例
以下为演示数据，仅用于说明计算过程，不代表任何真实供应商表现。某月某供应商应交付信息共10条，其中已到8条、未到2条，应到时间统一按工作日截止18:00，滞后时长以工作日计。
| 信息编号 | 信息类型 | 应到时间 | 实际到齐时间 | 滞后时长（工作日） | 状态 |
|---|---|---|---|---|---|
| A01 | 接口文档 | 第3个工作日 | 第3个工作日 | 0 | 按时 |
| A02 | 接口文档 | 第3个工作日 | 第2个工作日 | −1 | 提前 |
| A03 | 测试报告 | 第5个工作日 | 第7个工作日 | 2 | 滞后 |
| A04 | 测试报告 | 第5个工作日 | 第5个工作日 | 0 | 按时 |
| A05 | 物料规格书 | 第8个工作日 | 第12个工作日 | 4 | 滞后 |
| A06 | 物料规格书 | 第8个工作日 | 第9个工作日 | 1 | 滞后 |
| A07 | 变更说明 | 第10个工作日 | 第10个工作日 | 0 | 按时 |
| A08 | 认证资料 | 第12个工作日 | 第15个工作日 | 3 | 滞后 |
| A09 | 认证资料 | 第12个工作日 | — | — | 未到 |
| A10 | 接口文档 | 第15个工作日 | — | — | 未到 |
逐步计算：应到信息总条数为10，其中滞后时长≤0的有A01、A02、A04、A07共4条，及时率 = 4 ÷ 10 × 100% = 40.0%。已到信息8条，滞后时长之和为0 + (−1) + 2 + 0 + 4 + 1 + 0 + 3 = 9个工作日，均值 = 9 ÷ 8 ≈ 1.1个工作日。将8个滞后时长排序为−1、0、0、0、1、2、3、4，中位数为第4、5位的平均，即(0 + 1) ÷ 2 = 0.5个工作日。
缺失项单列：未到2条（A09、A10），占应到信息总条数的20%。结果说明：该月及时率偏低，主要拖累来自物料规格书和认证资料两类信息；均值高于中位数，说明存在个别较长滞后（A05滞后4个工作日），但多数信息滞后在1个工作日以内。改进动作可以优先针对规格书和认证资料的提交节点，与供应商确认前置准备时间。
解读与限制：哪些结论能下、哪些不能
及时率反映信息到达的快慢，不反映信息本身的质量。一份按时提交但内容错误、需要返工的文档，及时率上是满分，实际却拖慢了下游工作。因此及时率应与返工次数、评审通过率等质量指标配合看，不能单独作为供应商交付能力的结论。
滞后时长受信息颗粒度影响明显。把一份文档拆成十条子信息统计，与按一份文档统计，得到的条数和均值都不同。统计口径确定后应保持稳定，跨期比较时确认颗粒度未变；确需调整颗粒度，应在调整期分段报告，并说明前后不可直接比较。
解读时按供应商与信息类型拆分。整体及时率掩盖了结构差异，按信息类型拆分能看出哪类信息是主要拖累，按供应商拆分能看出问题集中在个别供应商还是普遍存在。拆分后样本量变小，单条信息对比率的影响变大，条数很少的类别宜看具体条目而非比率。
归因要区分供应商原因与需求方原因。需求变更、评审延迟、接收标准临时调整造成的滞后，应在统计中单独标注，不混入供应商责任口径。改进效果用趋势和分项验证：连续几个时间窗内，目标信息类型的滞后条数和滞后中位数是否下降，比单期及时率的一次波动更能说明问题。
当这些时间与状态记录在协作平台中流转时，统计口径更容易落地。ONES ALM 方案面向涉及供应商的多角色协作场景，将需求分解、任务执行、测试反馈和变更处理放在同一平台推进；应到时间可以记录在工作项的计划日期上，实际到齐时间可以取信息提交并通过接收确认的状态时点，再由 ONES Performance 对系统内流转的数据做汇总和自定义分析。供应商在系统外提交的信息需先录入系统才能纳入统计，具体字段配置和指标模板以实际产品为准。
常见问题
供应商在系统外通过邮件或聊天工具提交信息，怎么纳入统计？
系统外提交的信息需要先录入协作平台，形成可追溯的记录，才能进入统计。录入时至少补齐三项：信息编号与类型、应到时间及其来源、实际到齐时间及接收确认记录。如果只在邮件里确认收到、没有在系统中登记，后续复算时无法区分首次提交和补充提交，及时率容易偏高。
实际操作中可以把录入责任放在需求方接收人身上，收到信息并确认可用后当天登记，避免月底集中补录造成时间失真。
同一条信息被多次打回补充，实际到齐时间按哪一次算？
按最后一次补充完整、下游可以直接使用的时点计算，不按首次提交时间。打回补充期间信息处于不可用状态，如果按首次提交计，等于把返工时间从滞后时长里抹掉，及时率会虚高。
建议在记录中保留首次提交时间和最终确认时间两个字段，最终确认时间用于计算滞后时长，首次提交时间可用于分析返工次数，两者结合能看出是提交慢还是返工多。
统计周期内应交付信息只有两三条，及时率还有参考价值吗？
条数很少时，单条信息对比率的影响很大，一条未到就可能让及时率下降几十个百分点，比率本身波动大，不宜直接横向比较。这种情况下建议同时列出具体条目和滞后天数，用明细说明情况，比率只作辅助参考。
如果连续几个周期条数都很少，可以合并多个周期统计，或者改按项目阶段汇总，让分母达到可分析的规模，同时在报表中注明合并口径。
需求方原因造成的延迟，统计时怎么处理才不冤枉供应商？
在统计前给每条信息标注延迟原因，至少区分供应商原因、需求方原因和双方共同原因。需求方发起的范围变更、评审延迟、接收标准临时调整，应有变更记录或沟通记录支撑，这类条目可以单独统计，不混入供应商责任口径。
排除或单列都要有书面依据，不能凭口头说明剔除，否则分母被缩小，及时率失去可比性。报告中同时给出含需求方原因和不含需求方原因两个口径的及时率，读者能看清差异来源。
这套指标能不能直接用于供应商年度考核？
可以作为参考项，不宜单独作为考核依据。及时率只反映信息到达的快慢，不反映信息质量，按时提交但内容错误需要返工的文档，在及时率上是满分。考核若只看及时率，可能引导供应商赶时间提交、牺牲完整性。
更稳妥的做法是把及时率与返工次数、评审通过率等质量指标组合使用，并明确各指标的权重和统计口径，在考核周期开始前与供应商确认，避免事后争议。
