先定停止条件
停止条件要在启动时写定，通常包括错误率超过上限、使用者持续绕行、出现数据合规问题、关键人员撤离。为什么必须事先写：身处其中的人容易为已投入的时间辩护，把明显该停的项目拖成消耗战。
停用要留观察尾巴
停用后不要立刻收回全部权限，留一到两周观察业务是否反弹、有无遗留任务。为什么这么说：部分流程已按系统改写，突然抽掉会出现断点；留出缓冲期，既能让业务平稳回落，也能发现哪些改动值得保留。
人员归位要提前沟通
参与者往往从原岗位抽调，退出时需要与其主管确认回归安排与工作量。为什么不能事后再说：沟通不到位，人会悬在两个团队之间，既影响业务也影响评价；归位时间要写进试点方案。
数据与权限要处置
试点产生的样本、日志与临时账号要按约定清理或移交，脱敏副本明确销毁方式与记录人。边界在于：数据处置方案由客户方数据负责人确认，我方执行并留存记录，不擅自保留任何含客户信息的样本。
结论归档比停止本身重要
把失败环节、成立条件与建议整理成一页，连同证据一并归档。为什么值得做：下一个场景立项时可以直接复用这批判断，避免在同一个地方再试一次；没有归档的失败，等于把学费交了两遍。
适用与不适用
适合谁
- 试点出现明显异常、需要判断是否继续的项目
- 参与者已开始绕行、使用率持续下滑的验证
- 涉及数据合规风险、需要立即收缩的场景
不适合谁
- 指标短期波动但总体趋势正常的试点
- 尚未定义停止条件、也无过程记录可依的试验
典型场景
某制造企业的排产建议试点在第四周出现使用率下滑。观察记录显示班组长开始手工改单，理由是新建议与实际产能不符。项目组按事先约定的停止条件判定暂停，通知生产与信息中心，保留一周只读权限观察，随后清理样本并归档结论，写明该场景在产能数据补齐后可重试。
可执行步骤
- 对照启动时写定的停止条件，逐条判断其中是否已有任意一条被触发
- 由试点负责人统一对外通知，说明停止范围、原因与后续安排时间表
- 停用功能但保留一到两周的只读权限，观察业务是否反弹与遗留任务
- 与每位参与者的主管逐一确认归位时间、岗位安排与后续需要承担的工作量
- 按约定清理样本、日志与临时账号，同时留存销毁记录与执行人签字
- 输出一页结论，写明失败环节、成立条件与后续重试建议，归档备查
常见坑
- 明知已经触发停止条件仍继续跑，理由是沉没成本太高，结果拖到观察期结束，团队士气与信任一起耗尽。
- 停用后立刻收回全部权限，业务出现断点，一线被迫手工补录，怨气转移到下一轮项目上。
- 参与者没有归位安排，人在两个团队之间悬着，绩效评价出现空档，下次报名试点时没人愿意来。
- 试点数据与临时账号没有清理，半年后在安全审计中被点名，需要额外投入做追溯与说明。
自检与验收清单
- 停止条件是否在启动时写定，并已告知全体参与者
- 是否逐条对照停止条件判断，而不是凭感觉决定
- 停用后是否保留一到两周的观察期与只读权限
- 参与者的归位安排是否已与各自主管逐一确认
- 样本、日志与账号是否按约定清理并留下记录
- 结论是否归档，并写明失败环节、成立条件与重试条件
常见问题
试点停止会不会影响后续立项？
处理得当反而有利。把失败原因、成立条件与证据写清楚，下一轮立项时判断依据更充分；真正影响立项的是拖着不结论、最后不了之，那种情况下管理层只看到投入没有产出，也不清楚问题出在哪。
能不能只停一部分功能？
可以，而且更常见。把出问题的环节单独关闭，保留其余可用部分，既能验证剩余价值，也减少业务断点；但要在结论中写清停用范围与替代方案，避免使用者以为整个系统都不能用而全部退回人工。
停用后原来的流程怎么恢复？
启动时就应保留原流程的可执行状态，常见做法是不拆旧系统、只调整入口。恢复时按预案把入口切回，并确认积压任务的处理方式；若原流程已被改动，需要在试点方案里写明恢复步骤与责任人。