跨部门审批造成的研发等待，往往不是某一位审批人慢，而是请求在提交、受理、审批、回写之间反复停留。本文按这四个时间段拆解等待，找出占比最高的审批类型，再用分级授权、并行会签、超时规则和审批前置压缩等待，并用同一口径的周期分布与超时占比验证改进是否生效。
要点总览（TL;DR）
- 把跨部门审批等待拆成提交、受理、审批、回写四段，分别记录时间点，才能定位等待集中在哪一段、由谁持有。
- 等待要分成排队等待、审批人处理、返工重提三类统计，混在一起看平均值会掩盖真正集中的环节。
- 改进按等待占比最高的审批类型优先：先做分级授权和并行会签，再做审批前置，超时默认规则只用于低风险审批。
- 分级授权依赖清晰的风险分级标准，超时默认需要可追溯记录，统一入口需要各审批方接受同一套状态定义。
- 验证沿用同一时间口径，逐类对比等待中位数、超时占比和退回重提率，观察窗口建议四到八周。
先量清楚：跨部门审批的等待到底花在哪
改进的第一步是把“审批慢”这个笼统判断换成可观测的时间段。建议以单个工作项为记录单位，为每一次跨部门审批记录四个时间点：研发方提交时间、审批方受理时间、各审批节点的开始与结束时间、审批结论回写到工作项的时间。四个时间点之间的间隔，分别对应提交到受理的排队、受理后的处理、节点之间的流转，以及结论回写的延迟。缺少任何一个时间点，等待就会被归到错误的责任方身上。
在四段时间的基础上，还要把等待分成三类，分开统计：
- 排队等待：请求已提交，但尚未进入审批人的待办队列，或排在队列中未被打开。这类时间反映的是受理机制和队列容量。
- 审批人处理：审批人已开始处理，到给出结论之间的时间。这类时间反映单节点的判断成本，包括材料阅读、跨部门确认。
- 返工重提：审批被退回后，研发方补充材料、重新提交，再进入下一轮等待的时间。这类时间反映提交质量与审批标准的清晰度。
三类时间的改进手段不同：排队等待靠受理规则和授权分流，处理时间靠材料完整度和审批人负荷，返工重提靠审批前置和标准统一。混在一起看平均值，容易被少数超长审批拉高，掩盖真正集中的环节。建议同时看中位数和超时占比，中位数反映常态，超时占比反映尾部。
统计维度上，按审批类型（如需求变更、上线发布、跨团队接口调整、资源申请）和审批部门分别汇总，找出等待占比最高的两三类审批。改进资源有限时，优先处理这几类，收益最直接。本文的口径只覆盖工作流动中的等待时间，不涉及研发人员的主观体验评价，也不处理单个项目的进度纠偏；这两类问题需要另外的方法。
一张可用的基线表可以按下面的结构组织，数字来自实际记录；没有记录时，先用一周的样本手工采集，再逐步固化到系统中。
| 审批类型 | 样本数 | 排队等待中位数 | 审批处理中位数 | 返工重提占比 | 超时占比 | 主要持有方 |
|---|---|---|---|---|---|---|
| 需求变更审批 | — | — | — | — | — | — |
| 上线发布审批 | — | — | — | — | — | — |
| 跨团队接口调整 | — | — | — | — | — | — |
| 资源与排期申请 | — | — | — | — | — | — |
如果审批请求散落在群聊、邮件和各类表单里，采集本身就会成为负担。把审批请求承载为工作项上的状态流转，提交、受理、审批、回写各环节在同一处留痕，等待时长和超时记录可以直接从状态变更时间中读出。ONES 的工作项状态流转可以承载这类审批请求，让等待时间的采集与后续改进共用一套记录，减少手工补录带来的口径偏差。
常见瓶颈：等待为什么反复出现
等待反复出现，多数情况下源于流程结构，而非个别审批人的态度。把原因归到“某部门配合度低”，会掩盖真正可以改动的设计问题，下一次换人仍然复现。下面几类瓶颈在跨部门审批中最为常见，每一类都对应可观测的现象。
串行会签拉长总等待。多个部门依次审批时，总等待等于各节点等待之和。即使每个节点只花半天，五个节点串起来就是两三天，而其中大部分时间研发方只是在等前一个节点放行。可观测现象是：审批链路上节点数量多，且相邻节点的开始时间严格前后相接。
审批人不在岗或权限集中。审批请求进入个人待办队列后，如果该审批人出差、休假，或所有请求都集中在一两位负责人手里，任务就会在队列中滞留。可观测现象是：同一审批人的待办积压量明显高于其他人，或等待时间在特定日期段集中升高。
信息不全引发退回重提。提交材料缺少影响说明、测试结论或回滚方案，审批人无法判断，只能退回。退回后研发方补充、重新排队，形成二次甚至三次等待。可观测现象是：返工重提占比高，退回原因集中在少数几类材料缺失。
审批标准分散、每次重新判断。审批依据散落在文档、历史邮件和口头约定中，审批人每次都要重新确认标准，处理时间被拉长，不同审批人给出的结论也不一致。可观测现象是：同类审批的处理时间差异大，退回理由表述不一。
这四类瓶颈可以整理成一张清单，每类标注对应的可观测现象和当前数据，作为后续改进动作的选择依据。清单的价值在于把讨论从“谁不配合”转到“哪一段等待可以被设计掉”。
优先改进动作：从等待最长的环节开始
改进动作应按基线表中等待占比最高的审批类型优先实施，而不是一次性铺开所有规则。下面五项动作按实施难度和风险从低到高排列，前两项通常先做，后三项在条件具备时再引入。
分级授权。按变更的影响面设定审批层级：影响范围小、可快速回滚的变更，由一线负责人直接放行；影响跨团队接口、线上稳定性或合规要求的变更，才进入跨部门审批。作用机制是减少进入长审批链的请求数量，把审批资源集中到真正需要多方判断的事项上。落地时先梳理现有审批类型，为每一类标注影响面判断标准，再确定对应的审批层级。
并行会签。对彼此没有先后依赖的审批节点，同时发起而不是依次流转。作用机制是把总等待从各节点之和压缩为最长节点的等待。落地前要确认审批项之间确实无依赖，例如安全评审与资源确认可以并行，而涉及同一接口的两方确认可能需要先后。
超时提醒与默认规则。为每个审批节点设定时限，超时后自动提醒、升级到上级，或在满足预设条件时默认通过并保留记录。作用机制是减少请求在个人队列中的无限期滞留。默认规则应只用于低风险审批，高风险审批保留人工确认，所有超时与默认通过都要留痕，便于事后复核。
审批前置。把评审材料、影响说明、测试结论、回滚方案作为提交时的必填项，随请求一并附上。作用机制是减少因信息不全导致的退回，把返工重提的时间前移到提交之前。落地时可以按审批类型整理一份材料清单，作为提交模板。
统一审批入口。让所有跨部门审批请求进入同一工作项状态，而不是散落在群聊和邮件中。作用机制是让等待时间可被记录、可被统计，也让审批人有一个固定的待办来源。这一项是前四项能够持续度量的基础。
| 优先级 | 改进动作 | 改变机制 | 主要影响的等待类型 |
|---|---|---|---|
| 1 | 分级授权 | 减少进入长审批链的请求数量 | 排队等待 |
| 2 | 并行会签 | 总等待由求和变为取最长节点 | 节点间流转 |
| 3 | 审批前置 | 提交时补齐材料，减少退回 | 返工重提 |
| 4 | 超时提醒与默认规则 | 限制请求在个人队列中的滞留 | 排队等待、处理时间 |
| 5 | 统一审批入口 | 让等待可记录、可统计、可追溯 | 全部 |
统一入口与超时记录需要系统承载。ONES 可以把审批请求作为工作项状态流转的一部分，提交、受理、审批、回写各环节的时间在同一处留痕，超时提醒与升级路径也能围绕状态变化设置，使改进前后的对比有同一套记录可用。这样，分级授权和并行会签带来的变化，可以直接从状态时间中读出，而不必依赖人工统计。
适用前提与代价：哪些条件不满足就先别改
这些改进动作都有成立条件，条件不满足时强行推行，可能把等待换成返工或风险。下表把每项动作的前提、投入和主要风险放在一起对照，便于判断先做哪一项。
| 改进动作 | 成立前提 | 主要投入 | 不满足时的风险 |
|---|---|---|---|
| 分级授权 | 有清晰、可执行的风险分级标准 | 梳理审批类型与影响面判断规则 | 分级变成随意放行，高风险变更绕过评审 |
| 并行会签 | 审批项之间确实无依赖 | 梳理节点依赖关系 | 并行结论相互冲突，需要二次协调 |
| 超时默认规则 | 有可追溯记录，且仅用于低风险审批 | 设定时限、升级路径与留痕机制 | 高风险事项被默认通过，事后难以追责 |
| 审批前置 | 材料清单稳定，审批方认可清单内容 | 按审批类型整理提交模板 | 清单频繁变动，提交方反复补材料 |
| 统一审批入口 | 各审批方接受同一套状态定义 | 跨部门协调状态与字段口径 | 入口统一但状态各说各话，数据不可比 |
分级授权是最先被考虑的动作，也是最依赖标准的动作。风险分级标准需要写明哪些变更类型、影响范围、回滚难度对应哪一级审批，并且定期复核。标准模糊时，一线负责人不敢放行，分级授权形同虚设；标准过宽时，高风险变更可能被直接放行。建议先用历史数据回测：把过去一个月的变更按新标准分级，看有多少高风险变更会被划入低风险层级，据此调整标准。
超时默认规则要区分审批类型。低风险、可回滚的审批可以设定超时默认通过，并保留完整的超时记录和通知记录；涉及线上稳定性、数据安全或合规要求的审批，超时后应升级而非默认通过。默认规则一旦启用，需要有定期抽查机制，确认默认通过的请求没有出现质量问题。
统一审批入口涉及跨部门协调成本。各审批方对状态名称、必填字段、完成标志的理解可能不同，需要先对齐一套最小共识的状态定义，再逐步扩展。协调本身会占用时间，这部分投入应计入改进计划，而不是当作额外负担回避。
改进初期出现审批质量波动是正常现象。分级授权后放行的变更、并行会签产生的结论，都需要一个观察期来验证。建议设定四到八周的观察窗口，期间保持抽查，确认没有出现因审批放松导致的事故或返工上升，再决定是否扩大适用范围。
效果验证：用同一口径判断等待是否真的下降
验证的核心是沿用 S1 建立的时间口径，用同一套记录方式对比改进前后，而不是换一套指标证明改进有效。主要看三个指标：等待中位数、超时占比、退回重提率。中位数反映常态等待是否缩短，超时占比反映尾部是否收敛，退回重提率用于确认等待没有转移成返工。
| 指标 | 口径 | 改进前 | 改进后 | 解读要点 |
|---|---|---|---|---|
| 等待中位数 | 提交到回写的中位时长，按审批类型分列 | — | — | 总量下降时仍需逐类查看 |
| 超时占比 | 超过设定时限的审批数占该类审批总数的比例 | — | — | 关注尾部是否收敛 |
| 退回重提率 | 被退回至少一次的审批数占该类审批总数的比例 | — | — | 上升说明等待可能转移为返工 |
| 各节点处理时长 | 审批人开始处理到给出结论的时长 | — | — | 区分排队改善与处理改善 |
按审批类型分别对比，是解读数据的关键。总体等待下降，可能只是某一类高频审批改善明显，而另一类审批反而恶化。逐类查看可以避免总量掩盖结构问题，也能帮助判断下一轮改进应投向哪里。
退回重提率需要与等待中位数一起看。如果等待下降的同时退回重提率上升，说明部分等待被转移成了返工，研发方的实际交付周期未必缩短。这时应回到审批前置环节，检查材料清单是否覆盖了审批人真正需要的判断依据。
观察周期要足够长，以排除季节性波动。月末、季度末、大版本发布前后，审批量本身会变化，单周对比容易得出错误结论。建议以改进上线前后各四到八周为观察窗口，并标注窗口内的发布节奏和人员变动情况。
所有对比数字都应来自实际记录。如果团队尚未建立完整记录，可以先做一次小样本手工采集，并在结论中明确标注为演示假设，例如“假设某类审批改进前等待中位数为 3 天，改进后为 1.5 天”，用于说明验证方法，不作为改进成效的结论。等记录机制稳定后，再用真实数据替换。
常见问题
审批请求散落在群聊和邮件里，时间数据采集不起来怎么办？
先做一次小样本手工采集：选两三类高频审批，用一周时间记录提交、受理、各节点开始与结束、回写四个时间点，得到一份可用的基线。手工采集的样本量有限，结论只用于判断哪类审批等待最集中，不用于对外汇报改进成效。
同时推动审批请求进入同一工作项状态，让时间点随状态变更自动留痕。入口统一之前，手工记录和系统记录不要混用，否则前后口径不一致，对比会失真。
超时默认通过会不会让高风险变更绕过评审？
默认通过规则应只用于低风险、可快速回滚的审批，例如常规配置调整或小范围文案变更。涉及线上稳定性、数据安全或合规要求的审批，超时后应升级到上级或指定责任人，保留人工确认。
启用默认规则后需要配套定期抽查，确认默认通过的请求没有出现质量问题。抽查发现异常时，先收紧该类审批的默认条件，再评估是否暂停规则。
并行会签之后，各部门结论互相冲突怎么处理？
并行会签的前提是审批项之间确实无依赖。如果两个部门的结论可能相互影响，例如同一接口的两方确认，应保留先后顺序，或先做一次联合预审再并行发起。
已经并行且出现冲突时，需要指定一个裁决方，把冲突点记录到工作项上，作为下一轮梳理节点依赖关系的输入。冲突频繁出现，说明并行范围划得过大，应收窄到真正独立的审批项。
改进上线后等待下降了，但研发方感觉交付并没有变快，是什么原因？
先看退回重提率。等待中位数下降而退回重提率上升，说明部分等待被转移成了返工，研发方的实际交付周期未必缩短。这时应回到审批前置环节，检查材料清单是否覆盖了审批人真正需要的判断依据。
再按审批类型逐类查看。总量下降可能只是某一类高频审批改善明显，而另一类审批反而恶化。逐类对比能判断下一轮改进应投向哪里。
团队规模小、审批类型少，还需要做分级授权吗？
审批类型少、审批人集中的团队，等待往往集中在个人队列滞留，而不是审批链路过长。这类情况优先做统一入口和超时提醒，让请求有固定待办来源、滞留可被看见，收益更直接。
分级授权适合变更类型多、影响面差异大的团队。类型少时梳理分级标准的投入产出比不高，可以等审批类型增加后再引入。
