协办流程与规范：PMO任务分派协同管理关键指标

去年我帮一家年营收约 40 亿的装备制造企业做 PMO 流程诊断，翻他们月度经营分析会的协办任务台账时看到一个反常识的数字：系统里协办任务的“完成率”是 91%，但同一批任务的“验收一次通过率”只有 48%，而“协办人明确接单确认”的比例只有 57%。也就是说，超过四成的协办任务，是在协办人从未正式承诺的情况下被推进、被催促、最后被“默认完成”的。

这不是个例。我在过去六年里陆续接触过三十多家制造、医药和软件企业的 PMO，只要协办流程是靠“群里 @ 一下 + 表格里打个勾”跑起来的，最后都会收敛到同一个结果：PMO 变成了人肉路由器，协办变成了一个谁都不认领的责任黑洞。

这篇文章讲的是协办流程与规范的落地方法，以及 PMO 在任务分派协同中真正应该盯住的关键指标。我会先给结论，再讲我看到的真实场景、踩过的坑、指标的取值口径，最后给不同规模组织的行动建议和取舍逻辑。

一、先给结论：协办管理的核心不是“派了多少”，而是“责任有没有转移”

1. 协办流程的本质是一次责任转移

很多 PMO 把协办理解成“通知”或“协助请求”，这是最根本的认知偏差。协办不是通知，通知的终点是“对方知道了”；协办的终点是“对方承诺交付一个具体的东西，并且有人验收”。

一旦按“通知”来设计流程，你的成功标准就会自然滑向“已读率”“回复率”“群里有没有回‘收到’”。而这些指标全部可以在不产生任何实际交付的情况下被刷满。我见过最夸张的案例是：某企业一个跨部门协办任务，11 个协办人在群里全部回复“收到，马上跟进”，三周后交付物为零。

2. 四个必须盯住的责任型指标

如果你的协办管理只能看四个指标，我建议是下面这四个，而不是“完成率”。它们分别回答四个不同的问题：责任有没有被接受、有没有被履行、有没有被验收、有没有在时限内闭环。

• 协办责任确认率（ACR），回答“责任有没有被接受”。协办人明确接受或明确拒绝并说明理由的任务数，除以派发总数。
• 协办一次通过率（FPR），回答“交付有没有被验收”。首次提交即通过验收的任务数，除以提交总数。
• 协办闭环周期（P50/P90），回答“有没有按时闭环”。从派发到验收通过的中位数与 90 分位天数，只看中位数会被长尾骗死。
• 协办负载偏离度（CV），回答“有没有在同一个部门里被少数人扛着”。部门内协办任务分布的标准差除以均值。

3. 为什么“协办完成率”会系统性骗人

因为完成率是一个由系统口径定义的指标，不是由质量定义的指标。在大多数工具里，只要协办人回了一句话、上传了一个附件、或者任务到期被管理员批量关闭，这个任务就算完成。口径越松，完成率越漂亮，而管理者越安心，这恰恰是最危险的组合。

我在诊断时习惯做一件事：把同一批协办任务按四种口径分别算一遍完成率，然后把四个数字并排放在会议室大屏上。产生的效果，比讲一小时方法论都管用。

二、背景与真实场景：协办为什么会“派得下去、收不回来”

1. 场景一：把抄送当协办

我在一家医药企业的项目管理平台里看到过一个典型设置：协办任务可以选择“知会”类型，但“知会”和“协办”共用同一个任务模板，共用同一套催办规则，甚至共用同一个完成率统计口径。结果是大量本应是知会的消息被当成协办派发，协办人的收件箱里堆积着几百条“需要你协助”，久而久之全部被忽略。

正确的做法是把角色拆干净：负责人（对结果负责）、协办人（对交付物负责）、审批人（对结论负责）、知会人（只需要知晓）。这四类角色的时限、催办、考核、是否计入统计，必须是四套不同的规则。

2. 场景二：协办任务没有验收人

这是我在中小规模企业里见得最多的问题。任务派下去了，协办人也交了东西，但“交得对不对”由谁判断？没有定义。于是出现两种结局：一种是协办人交什么就算什么，PMO 不敢退回，怕得罪人；另一种是发起人反复退回，协办人反复重做，同一个任务在三周里改了六版。

我的判断标准很直接：如果一个协办任务在创建时没有明确写清“谁验收”，它就不应该被派发出去。验收人不明确，等于这个任务的闭环条件是空的，它在系统里完成得再漂亮，业务上也是悬空的。

3. 场景三：PMO 变成人肉路由器

在一家 800 人规模的智能硬件公司，我做过一次 PMO 团队的时间日志统计，连续两周，7 名 PMO 成员的平均时间去向是这样的：42% 用于在群里催协办进度、18% 用于手工核对各部门提交的表格是否齐全、15% 用于给不同部门解释同一个流程该怎么走。真正用于项目规划和风险分析的时间不足 20%。

这个结构的本质是：流程没有承载协同，人肉在承载协同。协办任务的分派、提醒、升级、归档，如果没有被系统化和规则化，PMO 的人头数就是流程容量的上限，组织规模一涨，PMO 就必须扩编，扩编之后沟通成本又二次上涨。

4. 协办任务生命周期的六个流失口

我把协办任务的完整生命周期拆成六个节点：派发、已读、明确确认接单、提交交付物、验收通过、在 SLA 内闭环。每一个节点都存在流失，而且流失率并不均匀，真正致命的是第二到第三个节点之间的断层。

三、拆解六个常见误区

1. 误区一：协办完成率越高越好

完成率高的团队，往往不是协作最好的团队，而是口径最松的团队。我在两家业务相似的企业做过对比：A 企业完成率 94%，验收一次通过率 51%；B 企业完成率 76%，验收一次通过率 79%。半年后回看，B 企业的项目按期交付率反而高出 18 个百分点。

原因是 B 企业允许协办人“明确拒绝”，拒绝会被记录，但不会被视为绩效污点。协办人在接单前就会认真评估自己能不能做、什么时候能做。拒绝产生的信息，比虚假的接单更有价值。

2. 误区二：协办任务拆得越细越好

拆得细在项目管理教材里是对的，但在协办场景里容易反噬。协办任务一旦拆到“提供某份数据的某一行”这种颗粒度，任务数量会指数上升，而每条任务的确认、催办、验收成本是固定的。结果是管理成本的增长快于协同效率的提升。

我的经验阈值是：单个协办任务的预期投入时间低于 30 分钟的，不要单独建协办任务，合并到同一批交付物中。单个协办任务预期超过 5 人天的，必须拆成带里程碑的多个任务。

3. 误区三：用即时通讯工具承载协办流程

即时通讯工具最大的问题不是不稳定，而是它没有状态机。“我昨天在群里说了”这种话，在协办纠纷里几乎没有裁决力，因为消息会被新消息淹没，且无法证明对方是否看过。

更麻烦的是，聊天记录里的协办约定无法被统计。你无法从聊天记录里算出责任确认率、返工率、闭环周期，也就无法做任何改进。这不是工具优劣问题，而是协办流程必须落在有状态、有时间戳、有责任人的系统里，才有优化空间。

4. 误区四：只考核协办人，不考核发起人

这是我认为最不公平也最低效的一条。协办交付质量差，很多时候根源在发起方：需求描述模糊、交付物定义不清、给的时间不现实、验收标准临时变化。只压协办人，结果就是协办人用最低成本应付，能糊就糊。

我建议在 PMO 的协办指标里，为发起方单独设一个指标：协办需求清晰度，用“协办任务被协办人提问澄清的次数”和“退回返工中归因为需求不清的比例”来近似度量。这个指标一上线，你会立刻发现协办返工率下降，因为发起人开始认真写需求了。

5. 误区五：把“已阅”当“已确认”

已阅是一个技术状态，确认是一个责任状态，两者之间隔着一整个承诺。系统里如果只有一个“已读”按钮，协办人就会习惯性地点它，因为它成本最低且没有后果。

正确的设计是：确认动作必须包含一个显性输出，承诺的交付时间 + 交付物的具体形态。协办人点确认时需要填写或确认这两项，而不是单纯点一个对勾。这个改动看起来很小，但它把“我知道这件事”变成了“我承诺在某天交付某个东西”。

6. 误区六：协办没有升级（Escalation）机制

协办超时了怎么办？大多数企业的答案是“PMO 再催一次”。催到第三次还不动，PMO 就只能上报，上报的时机完全靠人的判断，没有规则。

我的建议是把升级做成硬规则：SLA 到期前 4 小时自动提醒协办人，超时 0 小时自动通知其直接上级，超时 24 小时自动通知部门负责人，超时 72 小时进入 PMO 周会议题。规则一旦确定，PMO 的角色就从“催办者”变成“规则维护者”，工作量下降明显，且不再需要看人脸色。

我把上面六类误区导致的协办失败做过一次归因统计，结果比预想的更集中。

四、专业判断逻辑：协办流程的四层责任模型

1. 第一层：任务定义层

这一层解决的问题是“这件事到底谁负责”。核心动作只有一个：协办任务的协办人必须落到具体的人，不能落到部门或岗位。如果必须派给部门，那就同时指定一个部门内的接收人，由他在 4 小时内转派或自行承接。

我见过太多“派给质量部”的任务在部门内漂流了一周。部门是一个抽象概念，它不会对你的任务承诺任何东西。

2. 第二层：承诺层

这一层解决“他有没有答应、什么时候交”。设计要点是给协办人一个明确的选择集，而不是一个模糊的是非题：接受并按期交付、接受但需要调整时间（须写明理由）、拒绝并说明理由和替代建议。

允许拒绝是这一层最关键的设计。一个不允许拒绝的协办流程，等价于一个所有任务都被默认接受、但实际无人承诺的流程。

3. 第三层：证据层

这一层解决“交的东西算不算数”。协办交付物必须可验证：一份意见书、一组数据、一个签字确认的结论、一段可复现的操作记录。口头结论和“已经在群里说过了”不算。

在系统层面，这一层对应的是“提交时必须关联交付物字段”。如果工具允许协办任务在没有任何附件的情况下被标记完成，这个流程就是漏的。

4. 第四层：升级层

这一层解决“超时了怎么办”。升级规则必须是时间触发的、自动的、有明确接收人的，而不是靠 PMO 主观判断。升级不是惩罚，是把决策权交给有资源调动能力的人。协办人卡住往往不是不愿意做，而是他调不动他需要的资源。

四层逐层建立，协办纠纷工单量会呈现明显的阶梯式下降。我给一家企业做过这个改造的过程记录。

5. 协办规范文本怎么写才不是废纸

我见过太多写满八页纸的协办管理办法，实际执行率不到三成。原因是这些文件在写“应当、必须、原则上”，但没有写“系统里怎么配”。真正有效的协办规范，应该是一份可以直接落到工具字段配置上的清单。

下面是我在多个项目里反复使用并迭代过的协办任务字段模板，可以直接作为配置蓝本。

协办任务定义模板（字段配置示意）
task_id: PMO-2025-0417

initiator: 供应链计划组 / 张某

assist_owner: 工艺工程部 / 李某 # 必须落到具体的人

assist_type: 评审类 # 评审类 / 数据类 / 执行类 / 决策类

deliverable: 工艺可行性意见书 v1 # 明确形态、版本、必含要素

deliverable_must: [产能瓶颈判断, 风险点≥3, 替代方案≤2]

acceptance_by: 供应链计划组 / 张某 # 谁验收，谁对闭环负责

sla_confirm_hours: 8 # 责任确认时限（工作小时）

sla_deliver_days: 3 # 交付时限（自然日）

escalation_l1: 工艺工程部负责人 # 超时0小时触发

escalation_l2: PMO 主任 # 超时24小时触发

meeting_escalation: 超时72小时进入PMO周会议题

reject_policy: 允许拒绝一次，须写明理由与替代建议

rework_policy: 退回须写明缺失要素，同一任务退回不超过2次

这份模板的价值不在字段本身，而在于它把“协办”从一段口头请求，变成了一条有起点、有承诺、有证据、有兜底的记录。凡是不能被这条记录描述的协办，实际上都还没有被管理起来。

五、关键指标怎么定：8 个指标的口径、阈值与采集方式

指标设计最容易犯的错误，是只写名字不写口径。同一个“协办返工率”，按“被退回过的任务数占比”算和按“退回次数除以提交次数”算，可以差出十几个百分点。下面是建议的完整口径表。

1. 协办响应时延（ATR）：最先恶化的指标

在所有协办指标里，ATR 是最敏感的先行指标。它恶化的时间通常比交付延迟早 5 到 10 个工作日。原因很朴素：协办人没有及时确认，往往意味着他不知道要做什么、或者知道但优先级排不上。两种情况都会在后续演变成交付问题。

需要注意的是口径里必须用“工作小时”而不是“自然小时”，否则周五下午派发的任务会在周一早上集体超标，指标失去意义。

2. 协办责任确认率（ACR）：反映了多少任务在裸奔

ACR 低于 85% 的组织，我基本上可以直接判断它的协办是失控的。因为这意味着每 7 个协办任务里就有 1 个以上既没有被接受也没有被拒绝，处于一种“派了但没人认”的状态。

这个指标还有一层用法：看拒绝的分布。如果某个部门的拒绝率显著高于其他部门，可能不是态度问题，而是它的资源已经被协办任务占满了。这时候 PMO 要做的不是施压，而是重新分配或者向上争取资源。

3. 协办一次通过率（FPR）：反映需求表达质量

FPR 低有两种可能：协办人能力不够，或者发起人需求不清。区分方法很简单，看退回记录里的理由分布。如果退回理由集中在“缺少某类要素”“格式不符”“口径不一致”，那问题在需求定义；如果集中在“结论不成立”“数据错误”，那问题在交付质量。

我的经验是，在协办场景里需求定义问题占七成以上。所以提升 FPR 最快的方法，往往不是培训协办人，而是给发起人做需求模板。

4. 协办返工率：不能压到零

返工率不是越低越好。一个健康的协办体系里，返工率在 15% 到 25% 之间是合理的，因为这意味着发起人在认真验收。返工率长期低于 8% 通常不是好事，而是验收形同虚设，发起人根本没看，直接点了通过。

5. 升级触发率：两头都要警惕

升级触发率太高（超过 15%），说明 SLA 定得不现实或者资源确实不足；太低（低于 1%），要么是 SLA 定得太宽松，要么是升级机制根本没被执行。我建议把它当成一个区间指标，而不是单向指标。

6. 协办负载偏离度（CV）：看不见的团队风险

这个指标能揭示一个很隐蔽的问题：同一个部门里，协办任务是不是压在少数两三个人身上。CV 超过 0.8 的部门，通常会出现两种次级问题，被压的人开始拖延（因为做不完），没被分配的人能力逐渐退化（因为不参与）。

我建议把 CV 放到部门月度看板上，不是为了考核，而是为了让部门负责人在派任务时看一眼分布。

7. 协办链路平均跳数：跨部门协作的隐形税

每增加一跳交接，就增加一次信息衰减和一次等待。我在一家企业做过统计，跳数从 2 跳增加到 5 跳的协办任务，平均闭环周期从 4.1 天拉长到 11.6 天，接近线性关系。减少跳数的最有效手段不是加强沟通，而是缩短链路：把串联改成并联，把中间转述环节删掉。

8. 协办闭环周期 P90：比中位数更重要

只看中位数的管理者会低估风险。P50 是 5 天的体系，P90 可能是 22 天，那 10% 的长尾任务往往就是项目延期的真实原因。我建议所有协办周期指标都按 P50 和 P90 双值上报，并且把 P90 作为风险预警的主要依据。

六、数据观察：一家 1200 人企业的协办流程改造实录

下面这个案例来自我全程参与的一家智能制造企业。它有 1200 名员工，PMO 团队 7 人，同时并行 30 到 40 个项目，跨部门协办任务月均在 250 条上下。改造周期六个月，我按月记录了数据。

1. 改造前的基线

改造前他们用的是“Excel 台账 + 即时通讯群”的组合。协办任务由 PMO 在月初统一登记，然后在各个项目群里 @ 相关人。台账上有任务描述、责任人、截止日期三列，没有交付物定义，没有验收人，没有升级规则。

基线数据显示：协办闭环周期 P50 为 9.8 天，P90 为 21.4 天；PMO 用于人工催办的工时约 42 小时/月；协办返工率 31%；协办责任确认率无法统计，因为系统里根本没有这个动作。最后一条是最能说明问题的：当你连指标都无法采集时，说明这个流程在管理上是空白的。

2. 具体做了什么

我们把协办流程整体迁移到了一个支持私有化部署的项目管理平台，PingCode 上。选择它的原因有三个很具体的考量。

第一，他们服务中大型企业及 100 人以上组织，协办场景里的多角色、多层级、跨部门边界处理相对成熟，不需要我们在配置层做大量变通。第二，支持私有化部署，这家企业有军工背景的客户订单，研发和生产数据不能出内网，这一点是硬门槛。第三，支持从 Jira 平滑迁移，他们原本有 4 年的 Jira 历史数据，我们不想让历史项目记录断档，也不想让工程团队重新适应一套完全陌生的操作习惯。

对这类企业来说，国产替代最怕的不是功能少，而是迁移断档和团队重学成本。

具体落地了五件事：

1. 把协办任务的角色拆成负责人、协办人、审批人、知会人四类，四类角色的通知规则、时限规则、是否计入统计全部独立配置。
2. 上线责任确认机制，协办人必须选择接受、申请延期、拒绝三种状态之一，且必须填写承诺交付时间，系统不提供“已阅即完成”的快捷路径。
3. 为四类协办（评审类、数据类、执行类、决策类）分别建立交付物模板，提交时强制关联约定的交付物要素。
4. 配置三级超时升级：超时 0 小时通知直接上级，超时 24 小时通知部门负责人，超时 72 小时自动进入 PMO 周会议题池。
5. 上线协办负载看板，按部门展示协办任务分布与 CV 值，作为月度资源协调会的输入。

3. 六个月后的数据

我把逐月的数据整理成了下面这张对比，其中 1 月和 2 月为改造前的观察期，3 月起陆续上线各项规则。

4. 三个我没预料到的发现

第一个发现：改造初期协办任务量会不降反升。3 月到 6 月任务量从 268 件涨到 318 件，涨了 18.7%。一开始有人质疑是不是流程太重导致大家都在走形式，但结合周期数据看，实际是过去靠私下沟通、口头承诺消化的协作需求被显性化了。这部分需求以前不被看见，但一直在消耗时间。

第二个发现：升级触发率稳定在 5.8%，但升级后的处理速度差异极大。一级升级（通知直接上级）平均 1.4 天解决，三级升级（进入 PMO 周会议题）平均 6.8 天解决。这说明绝大多数超时不是资源问题，而是优先级没被看见。真正需要资源协调的只占很小一部分。

第三个发现：负载偏离度是最难改善的指标。六个月下来，闭环周期的改善幅度接近 45%，但 CV 只从 0.79 降到 0.62，仍高于健康阈值 0.5。原因是部门负责人在分配协办任务时会习惯性找“靠谱的人”，这个行为惯性比流程惯性更难改。

七、不同规模与成熟度下的行动建议

协办规范不是一套模板走天下。我按组织规模和 PMO 成熟度分成四档，给出不同的建议强度和优先级。

1. 100 人以下：先解决“谁负责”，别的都是次要的

这个阶段的组织沟通成本天然较低，走重流程反而会拖慢速度。我建议只做两件事：一是协办任务必须落到具体的人；二是交付物必须写清楚要什么形态。不要上 SLA，不要上升级机制，不要上负载看板。

指标只看两个：协办责任确认率和协办一次通过率。两个指标月度看一次就够，不用做周报。

2. 100 至 500 人：开始建立时限与拒绝机制

这个规模是协办问题开始集中爆发的阶段，因为跨部门沟通要经过中间层了。建议在角色定义和交付物模板之上，增加责任确认 SLA（建议 16 工作小时）和明确的拒绝机制。

指标增加到四个：加上协办响应时延和协办返工率。这个阶段还有一个重要动作是：把协办流程从即时通讯工具迁移到有状态的管理系统里。没有系统承载，后面所有指标都采集不到。

3. 500 至 2000 人：必须上自动升级和负载分布

到了这个规模，PMO 靠人催是催不过来的。必须上三级超时自动升级，同时把协办负载偏离度纳入部门月度看板。建议责任确认 SLA 收紧到 8 工作小时。

考核指标扩展到六个到七个。这个阶段的选型重点会明显偏向支持多角色权限、支持私有化部署、支持与现有研发工具链打通的平台。对中大型企业和百人以上组织来说，协办流程往往不是孤立存在的，它必须和需求、迭代、测试流程共享同一套数据底子，否则会形成新的信息孤岛。

4. 2000 人以上或多法人结构：规范要能跨主体执行

这个规模的核心难点不是流程设计，而是跨法人、跨地域的责任认定。协办任务在 A 公司发起、B 公司承接，绩效归属怎么算？超时升级到哪一级？这些必须在制度层面先明确。

建议责任确认 SLA 收紧到 4 工作小时，升级层级扩展到三级，考核指标扩展到八个。同时必须做数据权限的精细设计，确保不同法人主体只能看到自己权限范围内的协办数据，但 PMO 能看到全局分布。

八、取舍：协办规范做多严才合适

1. 三种必须做的取舍

第一种取舍：严格度与响应速度。SLA 定得越紧，平均闭环越快，但升级触发率会上升，管理层的注意力成本随之增加。我通常建议把 SLA 定在“历史 P75 水平”，也就是让四分之三的任务能自然达标，而不是按理想值定。

第二种取舍：系统化与灵活性。把协办流程搬进系统会带来规范性和可统计性，但会牺牲一部分临时协作的灵活性。我的判断是：凡是需要跨部门、跨周期、涉及绩效归因的协办，必须进系统；同一部门内、一天内能闭环的临时协助，允许在沟通工具里解决。强行把所有协作都塞进系统，会催生大量走过场的假任务。

第三种取舍：指标数量与管理成本。每多一个指标，就多一份数据采集、核对、解释、争议处理的工作量。八个指标差不多是一个 7 人 PMO 团队在不增加人力的前提下的上限。超过这个数量，指标本身就会变成负担。

2. 规范强度与三类成本的对应关系

我整理过一套按规范严格度分档的对比数据，用的是三家企业（规模相近，均在 900 到 1500 人之间）的六个月观察值。这张图里最值得注意的是最后一行：规范过度之后，闭环周期出现反弹。

3. 我的默认建议

如果只能给一条建议，我会说：把协办流程的严格度控制在“能让责任显性化，但不增加额外审批节点”的水平上。具体表现是：角色清晰、交付物明确、SLA 合理、升级自动，但不要为每一个协办任务增加审批环节。

审批是防止出错的，协办是推动交付的，两者目标相反。在协办链路里塞太多审批，等于给每一段接力都加一道闸门。

九、30 天落地清单

如果你打算下个月就在自己的组织里推动协办流程改善，我建议按下面的节奏推进，不要一次性全上。

1. 第 1 周：采集基线。从现有台账和沟通记录里，尽量还原过去三个月的协办任务量、平均闭环周期、返工比例。哪怕数据粗糙，也要有一个起点数字。
2. 第 2 周：定义角色与字段。把负责人、协办人、审批人、知会人四类角色的权限、时限、是否计入统计确认下来，并对应到系统字段。
3. 第 3 周：上线责任确认与交付物模板。这是投入产出比最高的一步。先把四类协办的交付物模板做出来，再开启责任确认动作。
4. 第 4 周：跑一次小范围试点。选一个跨部门协作最频繁的项目作为试点，跑满两周再决定是否全面铺开。试点期间重点观察责任确认率和一次通过率两个指标。
5. 第 2 个月起：上线超时升级规则，并按月复盘。升级规则不要一开始就设成三级，先做一级，观察两周升级触发率再决定是否加层。

需要特别提醒一点：不要在第一周就宣布考核。协办规范刚上线时，数据往往很难看，如果立刻挂钩绩效，团队会迅速学会用最低成本把指标刷好看，比如协办人一律点“接受”，但实际不做事。先跑两个月让数据稳定，再决定哪些指标进入考核，是更稳妥的路径。

十、常见问题答疑

1. 协办任务被拒绝多了，是不是说明流程有问题？

不一定，甚至可能是好事。拒绝率在 5% 到 12% 之间通常是健康的，说明协办人在认真评估而不是无脑接单。真正需要警惕的是拒绝理由的分布：如果集中在“资源冲突”“优先级不够”，那是资源分配问题；如果集中在“这不是我们部门的职责”，那是职责边界定义问题，比前者更麻烦。

2. 协办指标应该考核到部门还是到个人？

我的建议是分层：责任确认率、响应时延这类行为指标考核到个人；闭环周期、负载偏离度这类结构指标考核到部门。把结构指标压到个人身上，会让被分配任务多的人天然吃亏，反而激励大家推脱协办。

3. 历史数据在旧系统里，迁移过来会影响指标连续性吗？

会有影响，但可以处理。迁移时至少要保住三样东西：任务的历史状态变更记录、原责任人和协办人信息、原始时间戳。有了这三样，历史任务的周期指标就能重建。如果只迁移任务标题和当前状态，历史数据基本失去分析价值，指标只能从迁移后重新起算。

4. 协办 SLA 定多少天才合适？

不要凭感觉定，用你组织的历史数据来定。方法是：把过去三个月的协办闭环周期排序，取第 75 百分位作为初始 SLA。这样一开始就有 75% 的任务能达标，团队不会觉得规则不可理喻；然后每季度按实际数据收紧一次，每次收紧幅度控制在 15% 以内。

5. 小团队只有十几个人，还需要做协办流程吗？

需要，但只需要最轻的一层。最小可行版本是：协办任务写清楚交付物和验收人，任务派给具体的人而不是部门。这两条做到，十几人团队的协办混乱就能解决大半。不需要 SLA，不需要升级规则，不需要看板。

回到最开始那个问题：为什么协办任务完成率 91%，验收一次通过率只有 48%？因为这两个数字量的根本不是同一件事。前者量的是系统状态，后者量的是责任履行。协办流程与规范的建设，本质上就是把这个差距一点点压小的过程。它不需要一次做完，但需要从今天开始，把第一个协办任务的交付物和验收人写清楚。