取消落地方案：管理层开展任务执行的制度设计案例解析

2023 年 11 月，我以外部顾问的身份参加了一家制造企业的年终复盘会。会议的主题是一个推进了 7 个月的渠道数字化方案被叫停：总裁办公会用 40 分钟做完决定，但接下来 6 周，公司动用了 1900 多人天做收口，赔掉两份供应商合同，两名核心骨干在春节前离职，还有一个已经承诺给经销商的功能上线时间，最后是用一封措辞含糊的邮件糊过去的。会上有位高管总结说“还是执行力不行”，但我当时心里很清楚：这不是执行力问题，而是这家公司从来没有设计过“取消”这件事该怎么执行。

我们花了大量时间设计立项流程、评审流程、验收流程，却几乎没有人设计终止流程。

这篇文章想讨论的，就是被绝大多数管理制度忽略的那一半：当管理层决定取消一个已经落地的方案时，怎么把“停止”变成一条可执行、可交代、可留痕、可复盘的任务链。我会结合自己经手的 20 多个终止与降级项目，拆解决策授权、责任矩阵、沟通口径、合规处置、复盘沉淀这几块制度设计，也会引用一个使用 PingCode 的中大型研发组织在终止收口上的具体数据观察。

一、核心结论：取消不是一次表态，而是一条执行链

先把我的核心判断放在最前面：取消落地方案失败的原因，九成不在决策本身，而在决策之后的执行链断裂。决策只占用整个过程的 5% 到 10% 的时间，却消耗了 90% 的注意力；真正决定结果的是那些看起来琐碎的动作，谁发书面指令、谁冻结预算、谁通知供应商、谁回收账号、谁向客户解释。

1. 结论一：取消的真实成本，八成发生在决定之后

很多管理者对“取消”的成本直觉是错的。他们以为取消就是止损，省下的钱就是收益。但在我跟踪的终止项目里，取消带来的直接支出往往并不低于继续推进三个月的边际成本，只是这些支出分散在不同科目下，很难被一眼看见。

下面这组数据来自我对 6 个已脱敏终止项目的成本归集，金额做了等比缩放处理，属于情景模拟而非某家企业的真实财报，但结构比例与我观察到的实际分布高度接近。

我在复盘时经常问管理者一个问题：如果重来一次，你能压缩的是哪一块？答案几乎永远是后四项，而不是第一项。沉没成本改不了，但解约时点、收口人力、数据处置、对外沟通这四块，全都可以通过制度设计提前锁定。

2. 结论二：制度设计只需要回答四个问题

我不主张把终止制度做成一本厚厚的管理手册，那是没有生命力的。真正需要被制度固定下来的只有四个问题，剩下的都可以交给项目管理工具去承载。

• 为什么取消：证据门槛是什么？什么级别的数据不达预期、什么样的合规信号、多大的预算缺口，才构成取消的正当理由。
• 谁有权决定：授权边界在哪里？哪些取消项目经理可以拍板，哪些必须上升到分管副总，哪些必须上董事会或合规委员会。
• 谁负责执行：责任矩阵怎么定？停止、清算、交接、关停四类任务分别由谁负责、谁审批、谁被咨询、谁被通知。
• 怎么交代：对内对外口径、时间节点、责任人，以及哪些话绝对不能说。

这四个问题回答清楚了，取消就不再是“领导一句话，下面乱成一锅粥”，而是一条有起点、有节点、有交付物、有终点的任务链。

3. 结论三：没有留痕的取消，会变成二次危机

我见过最典型的翻车场景是口头取消。分管领导在会上说“这个先放一放”，项目经理理解为终止，开始遣散外包；结果三个月后领导问“那个方案进展怎么样”，项目经理说“您不是说停了吗”，领导说“我是说放缓”。这时候供应商的合同还在续签，数据还在按旧口径上报，客户还在等承诺的功能。

口头取消最大的风险不是执行偏差，而是它无法被追溯到任何一个人的责任。在劳动仲裁、合同纠纷、数据合规审计这三类场景里，“当时领导口头同意了”几乎没有任何证明力。所以我坚持一条：任何取消决定，必须在 48 小时内形成书面指令或经审批的系统记录，明确生效时间、范围和责任人。

4. 结论四：取消能力是组织纠偏能力，不是失败标签

这一条是我最想改变的认知。很多企业把取消等同于失败、等同于有人要被问责，结果是谁都不敢提终止，带着一个明显跑不通的方案继续烧钱，直到它自己烂掉。这种组织的真实成本，比取消本身高一个数量级。

下面这组对比是我对 11 个有明确终止制度的项目和 9 个完全靠临时协调的项目做的对照观察，属于样本推演数据，用于说明差异方向而非精确统计。

二、背景与真实场景：哪些取消最容易失控

不是所有取消都一样难。同样是叫停，撤回一项内部政策和管理一个十方参与的战略级项目终止，工作量差着数量级。所以在设计制度之前，先要分清自己面对的是哪一类场景。

1. 五类典型终止场景

我把常见的取消场景归为五类，它们的制度重心完全不同。下面这张判断表是我自己在项目启动时会填的第一张表。

这张表的价值在于：它逼你在动手之前先判断“我面对的是哪一类”，而不是上来就用同一套流程。用处理市场活动叫停的方式去处理合规撤回，几乎必然出事。

2. 为什么一百人以上的组织更痛

小团队取消一个方案，往往是一顿饭、一次谈话的事。但组织一旦超过一百人、跨三个以上部门，取消就变成一个协调问题：信息传递链路变长，责任边界变模糊，每个部门都倾向于认为“这不是我的事”。

我观察到的规律是：终止项目的失控程度，与参与方数量的平方成正比，与制度清晰度的平方成反比。参与方从 3 个增加到 9 个，协调复杂度上升约一个数量级；而一套清晰的授权表和 RACI，能把这部分复杂度压回原来的三分之一左右。

下面这张雷达图对比了三类终止场景在六个制度模块上的复杂度评分。评分为 1 到 5 分，分数越高代表该模块越需要正式的制度和工具支撑，属于我基于项目经验的评分，不是行业统计。

3. 一个 1200 人研发组织的真实场景（已脱敏）

我去年深度参与过一家软件企业的终止收口。这家公司研发体系约 1200 人，分布在四个产品线，两年前从 Jira 迁移到了 PingCode，属于典型的中大型组织使用国产研发管理平台的案例。他们当时要终止的是一个已经投入 11 个月、涉及三条产品线协同的中台重构方案。

方案本身没有错，问题是业务侧的产品路线在半年内变了两次，中台的抽象层设计反复重做，到第 11 个月时，团队已经连续三个迭代在还技术债，交付节奏完全被拖住。管理层最终决定终止，但真正棘手的是：三条产品线共有 47 个已排期任务挂在方案下，两个外部技术供应商还在按合同提供支持，公司级的 API 网关有一部分已经按新方案改造过。

他们最终能相对平稳地收口，靠的不是谁喊得响，而是一套被固化在工具里的终止工作流。这部分我会在第五章详细拆解。

三、拆解四个常见误区

在讲具体制度之前，我想先把几个反复出现的认知误区拆开。这些误区不是能力问题，而是“从来没人教过”导致的默认反应。

1. 误区一：把取消当成一次通知

最常见的一句话是“我通知一下就行了”。但通知只是链条的起点。我统计过自己经手的 20 多个终止项目，从“宣布取消”到“正式关账”，中间平均要走六道关卡，而绝大多数项目在第三道就卡住了。

2. 误区二：先谈赔偿，再谈交接

这是我见过代价最高的一种顺序错误。取消消息一出，法务和采购被拉来谈赔偿，业务和技术团队等着看结果，交接工作原地冻结。等到赔偿谈完，往往已经过去两三周，技术人员的注意力早已转移，交接质量断崖式下滑。

正确的顺序是交接与赔偿并行启动，但交接不依赖赔偿结果。合同可以慢慢谈，但代码仓库、数据权限、客户对接人、未完成的承诺，必须在取消宣布后的第一周内完成冻结与清点。赔偿谈三个月不影响交接，交接拖三个月一定影响赔偿，因为拖得越久，对方为你保留的资源越多，索赔基数越大。

3. 误区三：只对事收口，不对人交代

管理者往往把注意力全放在任务和合同上，忽略了人的部分。但终止最贵的成本恰恰在人：被取消项目的成员，会经历一段目标真空期，他们最关心的三个问题是，我接下来做什么、我原来做的事算不算数、这家公司会不会又这样。

这三个问题如果没有被正面回答，最先流失的一定是能力最强的那批人，因为他们最容易在外部找到出路。我见过一个终止项目后团队流失率 19% 的案例，事后访谈发现，离职原因排第一的不是薪酬，而是“没人告诉我这件事到底算不算白干”。

4. 误区四：把取消污名化，导致没人敢提终止

如果一个组织里，凡是提到“要不要停”的人都会被贴上“不坚定”“没担当”的标签，那么这个组织一定会积累大量僵尸项目。它们不会死，因为没人敢宣布它死；它们也不会活，因为资源早已不再有效投入。

取消制度的最高价值，不是让取消变得更容易，而是让“提出取消”变得安全。这需要在制度里明确区分两件事：决策错误和执行错误。基于当时信息的合理决策，即使结果不好，也不应该被追责；而隐瞒风险、伪造数据、明知不可行仍推进，才应该进入问责范围。

四、专业判断逻辑：一套可复用的制度设计框架

下面这套框架是我在多个终止项目里反复迭代出来的，共五个模块，每个模块只保留最必要的动作和交付物。它的设计原则是：能用一张表说清的，绝不写成一篇文；能在系统里跑的，绝不靠邮件推动。

1. 决策与授权：先设证据门槛，再划授权边界

取消决定最常见的两类问题，一是拍脑袋，二是不敢拍。前者导致资源浪费和反复取消重启，后者导致沉没成本陷阱越陷越深。两者都可以通过“证据门槛 + 授权边界”这组设计来缓解。

证据门槛解决“凭什么取消”。我推荐的实践是给每一类方案预设三类取消信号，只要命中任意两类即可启动取消评估：一是核心指标连续两个评估周期低于基线的 60%；二是出现无法在现有授权内化解的合规风险；三是外部条件发生不可逆变化，例如核心渠道终止合作或关键政策调整。这三条写进制度，能挡掉大量情绪化决策。

授权边界解决“谁有权定”。下面这张授权表是我在客户现场使用频率最高的一张表，它把取消决策分成三个层级。

这张表最关键的一栏是“必须留痕形式”。我坚持认为，没有留痕的授权等于没有授权。一级可以只在系统里改状态，但二级以上必须留下可被第三方理解的书面记录，这是给未来可能出现的争议预留的防火墙。

2. 任务执行：用终结 RACI 把取消拆成任务包

取消之所以执行不下去，是因为它在大多数人的认知里是一个“事件”，而不是一组“任务”。制度设计要做的事，就是把它拆开。

我在实践中把终止工作拆成四类任务包：停止类（停止投入、停止对外承诺、停止采购）、清算类（预算核销、资产盘点、合同处置）、交接类(知识转移、代码与数据移交、客户对接人变更）、关停类（系统下线、账号回收、数据归档）。

每一类任务包都需要一个明确的 RACI。下面这张表是终止 RACI 的骨架。

这里我想强调一个容易被忽略的细节：终止项目的 A（最终问责人）不能是项目经理。项目经理是被取消方案的原负责人，让他们同时承担终止的最终问责，等于让输球的人自己吹终场哨。A 必须上移一级，由分管领导承担，这样既保证了收口有足够的权力资源，也避免了角色冲突。

下面这张折线图展示的是一个设计良好的终止收口在 6 周内的推进节奏，三条曲线分别是任务关闭率、沟通覆盖率和合规闭环率。它说明的是三件事必须在同一时间段内并行推进，任何一条滞后都会拉长整体周期。

3. 沟通与利益相关方：分层、分时、分口径

终止项目的沟通有一条铁律：不要让同一个口径去面对所有对象。对核心客户说“我们战略调整，资源转向优先级更高的方向”，和对内部基层员工说“项目取消，人员重新分配”，是两种完全不同的语言。

我通常按“影响力 × 受影响程度”两个维度画一张沟通优先级矩阵，把所有相关方放进去，然后决定谁先沟通、谁由谁沟通、说到什么颗粒度。

沟通工具上，我建议准备三件东西：一份统一口径说明、一份分层问答库、一张沟通排期表。问答库要覆盖最难回答的那几个问题，比如“为什么现在才停”“之前的投入怎么办”“负责这个项目的人会被处理吗”。这些问题不提前准备答案，一线管理者一定会在客户或员工面前说错话。

4. 合规与风险控制：四类高风险事项必须走专业审

这是整篇文章里我最谨慎的部分。取消涉及的法律与合规问题因行业、地域、合同条款而异，我在这里列的是一份“检查清单”，不是法律意见，具体处置必须由法务、财务、人力资源和信息安全专业角色审核。

1. 合同与供应商：核对解约条款、最低消费承诺、已交付部分的验收标准、知识产权的归属与交付。
2. 劳动与人员：涉及岗位调整、外派人员回撤、绩效评价口径，需提前与人力资源对齐流程与话术。
3. 数据与信息安全：数据导出、归档、销毁的合规路径，账号与权限回收，第三方系统里的数据残留。
4. 财务与税务：已发生成本的确认、预付款的追回、资产减值处理、发票与合同的一致性。

我把这四类称为“沉默成本”，因为它们的风险不会在取消当天显现，而是在三个月到一年后的审计或纠纷中突然爆发。它们的共同特点是：处置成本很低，但不处置的代价极高。

5. 复盘与组织学习：把取消变成资产

取消项目最可惜的地方，是它带来的信息量其实远大于成功项目。一个成功项目的复盘容易变成庆功；一个失败或被取消的项目，能暴露出决策机制、假设验证、协同效率、资源计量上的真实问题。

我的复盘会议题清单只有五问：当初立项的核心假设是什么，它在什么时点第一次出现证伪信号，我们为什么没有在那时做出反应，这次收口的实际成本是多少，下次遇到同类信号我们该在哪个节点介入。前两问解决决策质量，后三问解决执行与制度缺口。不改制度只改态度，下次一定重演。

6. 数据留痕：让工具承担记忆

前五个模块的所有动作，最终都需要一个承载物。靠邮件和聊天记录是撑不住的，因为它们在三个月后基本无法检索，也无法形成统计。这就是为什么终止制度必须落到项目管理工具的任务结构和状态机里。

五、具体案例与数据观察：PingCode 场景下的终止收口

回到第二章提到的那家 1200 人研发组织。他们在终止中台重构方案时的做法，我认为是目前我见过的中大型组织里比较成熟的一套，值得拆开来看。需要说明的是，以下数据来自项目结束后的内部统计，已做脱敏与四舍五入处理。

1. 案例背景与终止触发

这个中台重构方案最初立项时，目标是为三条产品线提供统一的权限、数据与流程抽象层，预期能减少约 30% 的重复开发工作量。立项后第 4 个月，公司业务重心从标准化产品转向大客户定制交付，中台的抽象方向与定制化需求产生了结构性冲突。

第 7 个月，团队在 PingCode 上的需求流转数据已经能明显看出问题：方案下的需求平均滞留时间从 9 天上升到 26 天，跨产品线的协同任务完成率跌破 50%，三个迭代连续出现“已完成任务被重新打开”的情况。第 11 个月，管理层基于这些客观数据做出终止决定。

这个案例里我印象最深的一点是：终止决策不是靠汇报感觉做的，而是靠工具里积累的过程数据做的。需求滞留时间、任务重开率、协同完成率这些指标，在方案健康时就是风险预警，在方案要终止时就是决策证据。

2. 用状态机把“取消”变成可执行任务流

他们做的第一件事不是写通知，而是在 PingCode 里建了一个独立的终止工作流，把所有与方案相关的工作项批量关联进来。这个工作流的状态定义大致如下（YAML 示意，便于理解结构）。

termination_workflow:
states:

id: identified

name: 待处置确认

owner: 项目经理

exit_criteria: 已确认该任务是否需要交接

id: frozen

name: 已冻结

owner: 任务责任人

exit_criteria: 停止一切新增投入，锁定当前产出

id: handing_over

name: 交接中

owner: 任务责任人 + 接手人

exit_criteria: 交付物清点完成，接手人签字确认

id: compliance_check

name: 合规处理中

owner: 法务 / 财务 / 信息安全

exit_criteria: 合同、数据、资产三项均有结论

id: closed

name: 已关账

owner: 终止项目 A 角色

exit_criteria: 复盘归档完成，指标口径统一

id: archived

name: 已归档

owner: 项目管理办公室

exit_criteria: 进入组织知识库，可被检索

rules:

任何状态下暂停超过 5 个工作日自动升级至 A 角色

进入 closed 前必须挂载复盘记录链接

涉及外部合同的任务强制经过合规处理中状态

这个状态机看起来简单，但它解决了一个过去完全靠人盯的问题：取消不是把人组织起来开一次会，而是让每一项任务自己走完它的路径。停滞超过 5 个工作日就自动升级，这一条规则直接消灭了“任务没人管”的情况。

3. 数据观察：工具承载终止流程前后的对比

这家公司在这次终止之前，也经历过两次规模较小的方案取消，但那两次都是靠邮件和线下会议推动的。两组数据的对比很有说服力。

4. 从 Jira 迁移到 PingCode 带来的额外收益

这家公司两年前从 Jira 迁移到 PingCode，当时的主要动机是私有化部署和数据合规要求，以及国产替代的整体规划。迁移本身做得比较平滑，工作项、状态、字段映射基本保持一致，团队几乎没有经历明显的适应期。

但在这次终止项目里，我发现迁移带来的两个额外收益比预想中重要。第一是私有化部署让历史数据的检索与归档完全自主，终止项目涉及大量客户数据和内部技术文档，如果数据在外部 SaaS 上，合规处置的沟通成本会高很多。

第二是统一的数据模型让终止统计变得可能。他们能算出平均关闭周期、滞留任务数、复盘覆盖率这些指标，前提是所有工作项在同一套状态和字段体系下流转。如果数据散落在多个系统里，这些指标根本算不出来。对于一百人以上、跨多产品线的组织，这一点尤其关键，PingCode 服务中大型企业的定位，在终止收口这种低频但高风险场景里反而体现得更明显。

5. 案例结果

最终这次终止用了 7 周完成全部收口，比预期多了一周，超期部分主要来自一份供应商合同的谈判。47 个在途任务中，43 个完成关账归档，4 个转为新方案的子任务继续推进。两条产品线的核心成员没有出现流失，其中一名技术负责人后来成为新方案的负责人。

我认为这个案例最值得借鉴的不是工具，而是他们把“终止”当成一类独立工作流来设计，而不是当成项目的一种异常状态来临时处理。这个视角的转变，比任何单个流程都重要。

六、不同情况下的行动建议

制度是统一的，但动作必须分场景。下面我按四类最常见的终止触发原因，给出对应的行动建议和优先级排序。

1. 战略转向型取消：先对齐中层，再宣布全员

这类取消最大的风险不是员工不理解，而是中层管理者的解读偏差。他们掌握着信息传递的关键节点，如果他们在正式宣布前只掌握了半截信息，整个组织会在两天内传遍各种版本。

我的建议顺序是：决策形成后 24 小时内完成中层面谈，48 小时内完成全员正式沟通，72 小时内完成一对一去向沟通。同时要尽早给出新方向，哪怕只是方向性描述。人对“失去”的容忍度，取决于对“接下来”的确定感。

2. 合规触发型取消：先固定证据，再谈其他

合规类取消的第一动作永远是证据固定和数据处置，而不是发通知。我建议的顺序是：立即停止新增数据处理，完成受影响数据范围盘点，法务与信息安全同步介入判断是否需要主动报备，然后才是对内对外沟通。

这里有一个反直觉的判断：合规类取消中，沟通延迟几天通常是可以接受的，但数据处置延迟一天可能就无法挽回。因为数据的继续流转会扩大影响范围，而沟通只影响感受。

3. 数据不达预期型取消：先把证据讲清楚

这类取消最容易引发团队不服。因为团队会觉得“再给我们两个月就好了”。化解的关键是把证据门槛提前公之于众，并且在取消前至少给过一次明确预警。

我的建议是：取消沟通必须包含三个要素，触发取消的具体指标及数值、预警的历史记录、以及这次取消不影响对团队专业能力的评价。没有第三点，团队一定会把取消解读为对个人能力的否定。

4. 预算收缩型取消：先算清停止成本，再算节省金额

预算收缩驱动的取消，最常见的错误是只算省下的钱，不算停止的钱。前面第三章的成本瀑布已经说明，取消耗掉的钱往往比想象中多。

我的建议是让财务在决策会上就给出两组数字：停止推进后 3 个月的净节省额，以及一次性停止成本。如果净节省为负，那就要重新讨论是否应该改成“降级”而不是“取消”。

5. 任务降级：必须重新指定责任人，否则等于烂尾

降级是最容易被忽视的一类。表面上方案还在，只是范围缩小了，但实际上原负责人往往会把它当成次要事项，新范围又没有明确的验收标准，最终变成无人认领的僵尸任务。

处理降级只需要三个动作：重新出具一页纸的范围说明、重新指定唯一责任人和验收人、把新范围重新排入迭代。缺任何一个，降级就等于取消，只是没有人愿意承认。

七、不同情况下的取舍：哪些必须做，哪些可以放

制度设计最难的部分不是列出所有该做的事，而是在资源有限时判断哪些必须做、哪些可以简化。下面五组取舍是我在项目里反复做过的判断。

1. 速度 vs 合规：合规永远不能让位于速度

有些管理者希望“一周之内把这个事结干净”，这种诉求可以理解，但合规处置是不能压缩的。我的判断标准很简单：凡是涉及合同、劳动、数据、财务四类事项的动作，只能加速排期，不能减少环节。其他动作，包括沟通、交接、复盘，都可以通过增加人力来提速。

2. 止损 vs 士气：止血和留人是两个独立目标

很多管理者认为把项目停得越快，团队士气受损越小。我的观察恰恰相反：草率快速的取消，往往造成更大的士气损伤，因为员工看到的是“公司做决定可以这么随意”。

正确做法是把两个目标拆开管理：止损由财务和采购负责，目标是尽快停止资金流出；士气由直接上级和人力资源负责，目标是让每个人在两周内明确知道自己的下一件事。用一套动作同时解决两个目标，通常两个都做不好。

3. 统一口径 vs 分层沟通：同一事实，不同颗粒度

统一口径不等于所有人听同一套话。我主张核心事实必须一致（取消的事实、生效时间、对个人的基本影响），但颗粒度可以分层。对客户只需说明服务连续性方案，对员工要说明岗位与评价口径，对供应商要说明合同处理路径。

判断标准是：凡是可能被截图转发的内容，必须先确认它在所有对象那里都不会造成误导。

4. 工具投入 vs 人工台账：超过一百人就必须上工具

取消是低频事件，所以很多组织倾向于用 Excel 应付。但取消恰恰是高风险、强审计、多参与方的事件，低频不代表低要求。我的经验判断是：参与方超过 5 个、任务数超过 50 个、或者涉及任何外部合同，就必须用系统承载，否则一定出漏项。

这也是我在中大型组织里推荐私有化部署平台的原因之一。以 PingCode 为例，它支持私有化部署，也支持从 Jira 平滑迁移，在需要自主掌握数据、同时又要保留完整工作项流转记录的终止场景里，是国产替代方案中被较多中大型企业选择的一个。当然，工具只解决“记忆”和“推进”，制度本身还是要靠人设计。

5. 追责 vs 学习：先分类，再分别处理

取消之后要不要追责，是管理层最纠结的问题。我的建议是先给事件分类，再分别处理：属于信息不足下的合理决策失误，进入复盘学习流程，不追责；属于隐瞒风险、伪造数据、明知不可行仍推进，进入问责流程；属于执行层面的流程违规，进入流程整改。

这三类混在一起处理，结果一定是：该学的没学到，该罚的没罚到，组织下次还是同样的错。

八、结语：把“停止”变成一种可复用的组织能力

写到这里，我想回到开头那家制造企业。他们后来做了两件事：一是把终止决策的授权和留痕要求写进了项目管理办法，二是在自己的项目管理平台里建了一套终止工作流，把停止、清算、交接、关停四类任务做成模板。今年他们又叫停了一个方案，从决定到关账用了 23 天，没有产生任何劳动或合同纠纷。

我的核心观点可以浓缩成一句话：取消落地方案不是管理的失败，而是组织纠偏能力的一次实战检验。判断一个组织成熟不成熟，不要只看它立项多快、推进多猛，要看它停止得多干净、交代得多清楚、复盘得多透彻。

如果你现在正面临一个需要取消的方案，我的下一步建议是这样排序的。

1. 今天做：把决定从口头变成书面或系统记录，明确生效时间、范围和最终问责人（A 角色必须上移一级）。
2. 三天内做：完成在途任务清点，为每一项任务指派唯一责任人，并冻结新增投入。
3. 一周内做：完成核心客户与供应商的第一轮正式沟通，同步启动法务、财务、信息安全三条合规线。
4. 两周内做：完成人员去向的一对一沟通，给出明确的评价口径，避免关键人才在信息真空期流失。
5. 收口结束后：把这次的终止任务清单、RACI、沟通问答、成本数据归档成模板，让下一次取消有迹可循。

最后提醒一句：制度的价值不在于写得漂亮，而在于下一次危机来的时候，你的团队不需要临时发明流程。能把“停止”做成标准动作的组织，才有资格谈持续投入。