上线之后留两三周护航，是多数项目的惯例。实施方驻场或半驻场，现场有问题喊一声就有人来看，上线初期的小毛病多半是这么压下去的。
容易含糊的是结束那一刻。多数项目撤场凭一句「最近没什么问题了」，没人说得清这指的是没新问题，还是没人再报了。
一、撤场之后为什么会反弹
护航期的问题大多散在群里。谁发现谁发一句，实施方看到直接处理，回一句「好了」。快是快，但清单没有、状态没有，哪些真解决、哪些只是绕过去，过两周谁也记不清。
响应也不分轻重。单据卡住、字段想改名、报表想加一列，混在同一个群里排队，真正影响业务的被淹在消息里。
再是接手的人。护航期一直是外部在答，内部只记住了「找谁」。人一撤，同样的问题冒出来，不知道从哪查起，只能重新开单等回复。
二、把问题分成三级
- 阻断：业务走不下去，比如单据保存不了、领料过不了账。当天要有处置或临时办法，写清绕行步骤。
- 口径：能走通但结果不对，比如成本差一截、库存数对不上。这类最容易被当成小问题拖着，其实要追到规则。
- 优化：界面、字段名称、报表列，不进护航期必办清单，登记下来排到后续。
分级的好处是撤场条件能写得具体：阻断类清零、口径类有明确结论或临时口径、优化类有清单和去向。三条对着看，不用再靠感觉。
三、清单收拢到一个入口
群里可以继续讨论，但登记只走一处。每条写清谁提的、影响哪个环节、当前状态、谁在处理、结论是什么。字段不用多，缺了「结论」这一栏最麻烦——过一个月回头看，全是「已处理」，等于没有记录。清单还有个用处：同一个环节被问了七八次，多半不是操作不熟，是当初口径没讲清或者界面反着来，这类要在撤场前补一次说明。
护航的价值不在解决了多少问题，在撤场那天内部能不能自己走完一遍；走不完，就还是没结束。
四、交接别只交文档
手册厚不等于接得住。更实用的是把被问最多的十来个问题整理成一页：现象、查哪张单、改哪个配置、什么情况必须找外部。还要指明一个人，不是「IT 部门负责」，是具体到谁有权改配置、谁判断要不要升级。
模块单一、问题一周内清完的项目，一本共享清单加一次复盘就够。判断该不该正式做，看两个信号：问题是不是跨了三个以上部门，撤场后一个月内有没有同类问题重新报上来。
