边界、风险与退出

把一家供应商换成几家，能否让客户更自由？

英国国家储蓄与投资机构（NS&I）面向公众发行储蓄和投资产品。它的经历提醒我们，答案取决于客户是否有能力接住新的安排。它在 2020 年启动转型，希望从长期外包关系转向多个较小合同。原计划在 2024 年 3 月前完成大部分服务迁移；英国公共账目委员会 2026 年 2 月 13 日发布的报告指出，到那个原定节点，新服务尚未实现现代化并上线。委员会批评的核心包括：没有充分理解系统依赖、缺少整合计划、交付能力不足，以及过早签订合同。¹

这不是一个被证实使用 FDE 的项目，也不能据此断言多供应商模式更差。它是一面有用的镜子：减少对一家公司的依赖，并不会自动减少工作的复杂性。原先集中在一处的协调责任，很可能回到了客户身上。

第9章划分双方权责，第12章计算经济性，第19章检查产品复用。本章沿着另一条线走：合作已经开始，怎样保留停止、换团队和换系统的选择，而不把正在进行的工作丢在两者之间？

已经决定合作，还要保留什么选择

稳定接口的常规集成未必需要FDE，客户也不能把业务决定权交给一个没有相应授权的项目联系人。这些起步判断见甲方选择与双方权责。本章的独有问题发生在合作之后：资料拿得回来，是否也能带回资料的含义、未完成的承诺和继续使用的权利？

NS&I的比较材料把代价摆在合同之间。减少对一家供应商的依赖，会增加由客户承担的整合工作。FDE同样如此：外部工程师可以带来能力，也可能让许多关键解释只停留在合作关系里。退出安排需要把这些解释变成能由接任者核对的对象。

依赖不是一个开关

讨论供应商锁定时，人们容易只问数据能不能导出。能导出当然重要，但一套系统的依赖往往分散在几处。

一处在数据：历史记录是否完整、编号能否对应、不同表之间的关系是否保留。另一处在程序：哪些是客户可继续使用的代码，哪些需要持续许可，哪些服务停止后就无法调用。还有一处在知识：为什么当年设置这条规则，异常该怎样处理，究竟谁知道现有系统的真实状态。

最后一处在组织。即使文件全部拿到，客户若没有人排查故障、接受变更和维护权限，运行仍然依赖外部团队。这种依赖未必不合理。很多企业本来就选择购买持续服务。关键是双方知道自己购买的是什么，费用和退出安排与之相配。

把所有依赖都消除，也未必值得。客户自行开发每项能力，会承担额外的人力和维护成本；为了随时更换模型而维持多套复杂实现，也可能超过项目带来的收益。更实际的目标，是识别哪些依赖可以接受，哪些依赖会使关键业务失去选择，并为后一类保留替代路径。

例如，企业可以接受某个分析界面的替换需要时间，却不能接受供应商服务短暂中断后，已经收到的客户申请全部丢失。这两个要求不应被合成一句含糊的“系统要可迁移”。前者涉及迁移效率，后者涉及业务连续性，需要不同的建设工作。

一次可以真正执行的离场演练

下面是一项教学演练，不对应某家公司的已实施制度。假设一个售后团队使用外部共同建设的工单系统，合同还有半年到期。客户希望确认自己保留了更换供应商的选择。

第一步不是把整个系统关掉，而是挑选一条完整而普通的业务路径：客户提出申请，员工核实材料，主管批准，系统执行，最后记录结果。让接手团队解释每一步需要哪些数据、程序和权限。

第二步是带走一小批经过授权的测试记录。除了正文，还要包括状态变化、附件关系、规则版本和操作时间。接手团队尝试在新环境中恢复其含义。若只得到一张写着“已完成”的表，却不知道由谁、按什么条件完成，导出成功也没有实现可理解的迁移。

第三步最容易失败：处理尚未结束的工作。为此，教学团队在切换点T冻结旧系统的新写入，导出状态；新系统暂不自动执行，先逐条核对三项工单。下面的决定以这个隔离演练为限，并不意味着所有旧批准都能跨系统沿用。

这里没有一种统一的“待处理”状态。T01缺业务允许，T02缺有条件的执行接续，T03缺结果确认。若导出时把它们都压成未完成，新团队可能重复T03，也可能误把T01当已批准。若旧队列还可能恢复发送，T02也不能移交成“现在轮到新系统”；要先确认旧写入路径已经停止。

第四步再安排一项正常变化，例如主管更换，检查新团队能否修改负责人的配置，并保留原批准者的历史身份。恢复演练要同时回到相匹配的数据和程序版本，不能让一个旧程序读取它无法解释的新状态。

第五步才决定扩大迁移。教学团队批准T01进入人工审批，T02按核对后的批准继续，T03只补回执；没有对清单以外任务宣布迁移完成。中间任务与许可对象包保留导出记录、接任动作、停止条件与空白核对表，供读者逐项作决定。

迁移结束还要收回旧的访问。先由客户业务与记录管理负责人确认哪些资料需要保留、由谁保管，再由系统负责人盘点退出团队的账号、访问密钥和共享链接，按约定的接手顺序撤销或更换。在测试环境演练撤权，检查新团队运行是否仍偷偷依赖旧账号；通过后再安排正式切换。退出方持有的资料副本，则按适用的保存要求与合同确定保留、返还或处置，并留下完成记录。这里没有一条适用于所有项目的删除时限，必须明确的是谁做决定、谁执行和谁检查。新团队能够运行、旧团队不再保留未授权访问、所需记录仍可追溯，是三件分别需要确认的事。

英国政府的数字、数据与技术采购手册要求及早考虑合同结束，涉及知识转移、持续支持、资产和数据的移交，以及新旧安排之间的过渡。这是公共采购指导，并非适用于所有项目的统一法律要求；它对本章的启发是把退出当成前期设计，而非合同最后一个月的应急工作。²

退出日，哪些权利还在

探索与生产怎样分阶段、价格和变更如何约定，见合同与价格。这里继续追问：合同结束之后，接任者有权使用哪些具体对象？

知识产权同样不能只写一句“成果归客户”。客户提供的数据、项目新写的代码、供应商原有平台、通用组件和第三方许可，可能分别适用不同安排。英国政府 AI 采购指南把知识产权、支持培训与风险分配列入考虑范围。³ 在具体合作中，应当由负责合同的人将这些对象写清，而不是期待工程师在交付末期自行解释一条总括语句。

把对象分开，才有办法回答合同结束第一天还能做什么。下面仍是假定双方已逐项核对的教学安排，不表示法律会自动赋予任何一方这些权利。

“代码归谁”一句话覆盖不了这张表。客户拿到适配代码，仍可能依赖订阅平台；供应商允许内部使用，也未必决定第三方组件如何分发。工程师负责把依赖与实际对象列全，合同负责人核对权利范围，接任者验证能否使用。组件L未核清时，本例整体切换仍未通过，不能因三个工单都解释清楚就忽略另一类阻断。

停止条件不能等失败后才发明

合作开始后，人们很容易把已经投入的时间当成继续投入的理由。工程师说再修几个问题就好，客户说已经培训过员工，负责人不愿让前期投入显得浪费。于是项目不断延长，却没有重新判断继续的条件。

比较好的办法，是在还能冷静讨论时，约定哪些变化会触发重新评估。比如关键数据长期无法取得，业务负责人离任且无人接手，预期工作量大幅变化，或者系统需要越过原来未授权的决定边界。这些情况不必自动导致取消，但应当使“继续”重新成为一个需要理由的选择。

对于生成式 AI，美国国家标准与技术研究院（NIST）的风险管理资料提出，应明确停用标准，达到相应条件时向组织的风险负责人通报，并安排替代流程。它是一份风险管理指导，不能当成所有国家的法律，也没有替读者规定统一的可接受错误率。⁴ 对项目负责人来说，有用的是把这些措施翻译成自己的业务动作。下面缩小自动化范围的做法，是本书的应用推演。

例如，系统不能可靠确认申请人提供的材料时，可以转为帮助工作人员整理，而不再自动执行后续动作。某个工具反复产生无法解释的结果，可以停用那一部分，保留其他已验证功能。停止不一定是把全部软件关闭，也可能是缩小它可以独立决定的范围。

但替代流程需要真实容量。如果原来一天靠系统处理大量任务，所谓“有问题就转人工”却只安排一名员工，那么人工接管只是文字上的退路。负责人应当知道，降级后能处理多少工作、哪些先处理、剩余的人会等待多久，并提前安排可接受的服务方式。

完成退出，要同时看三种证据

运行证据说明任务有没有丢、重做或越过原批准；权利证据说明新团队能否继续使用相应对象；撤权证据说明旧团队已不再拥有超出约定的访问。三者分别成立，才能评价这次退出的范围。一个测试导出文件没有丢行，不能代替后两项。

本例的项目负责人因此作出一个并不漂亮却可执行的决定：维持旧队列停止、新系统受控处理的安排，先处理T01—T03，暂停整体切换，等组件L的许可与替代运行服务验证完成。若延长过渡费用超过客户愿意承担的价值，也可缩到较小路径，或重谈持续支持；不能靠继续消耗工程师时间让条件自动成立。

合作的良好终点因此可以有几种：客户已经能够独立运行；稳定工作转入明确的维护服务；共同建设的产品已覆盖主要需求；或者双方在条件不成立时及时结束。持续依赖可以是清楚选择，独立运行也需要持续维护。没有一种形式仅凭名称就天然正确。

回到本章开头，供应商数量只是表面。客户真正需要保留的是理解系统、判断结果和组织替代安排的能力。当这些能力存在，FDE 可以成为改变的伙伴；当这些能力全部空缺，再多的合同和再勤奋的工程师，也难以替客户承担经营本身。