甲方：什么时候值得引入 FDE

一家设备服务企业想让 AI 帮主管整理报修材料。它面前至少有几条路：购买工单软件的新功能，请原来的实施商接好数据，让内部工程师开发，或者和一家供应商共同探索。它也可以先整理报修流程，暂时不引入 AI。

这个教学情境没有一个预设正确的采购答案。若主管缺的是统一的设备编号，共同开发一个智能助手可能把简单问题做复杂；若系统已经能准确检索材料，主管却仍不知道怎样使用建议，单纯再买一个模型也没有解决采用问题。

甲方首先要买到或建立的，是改变这项工作的能力。FDE 是实现它的一种组织办法。决定引入 FDE，与决定长期养一支内部 FDE 队伍，又是两次不同的选择。

先说明缺的是什么

把“我们缺 AI 能力”改写成一件尚不能完成的工作，选择会清楚许多。维修企业可以先跟完一张真实工单：材料从哪里来，主管在哪里停住，错误由谁纠正，最后谁承担派错单的后果。此时要分清三个缺口。

缺产品功能，是现有工具没有需要的能力。例如系统不能把相关设备记录放在一起。缺工程连接，是能力已经存在，却没有正确连接本企业的数据、权限与流程。缺对新工作方式的认识，是团队还不知道什么建议有用、哪个时点应让人介入，需要边使用边修改。

这些缺口可以同时存在，但解决它们的人和钱不相同。购买产品可能填补第一项，常规实施可能填补第二项。第三项需要能接触一线、修改系统、取得业务反馈的人持续协作；如果探索又会改变供应商产品或企业自己的公共平台，FDE 的投入才有更清楚的去处。

2025 年发布的英国政府 AI Playbook 把现成产品、在既有技术上增加 AI、委托开发和与供应商共建列为可比较的选择；它先要求说明问题，而不是先指定一种采购形式。¹ 这是公共部门的指导，本书借用其中的比较方法，不将其采购制度移植为企业通则。

把几条路放在同一个问题下比较

下表是本书的决策分析。比较的方案应使用同一组正常工单和异常工单检验，不能让一条路回答简单问题，另一条路承担所有难题。

价格必须放在这张表旁边，但不能单独替它作决定。一个报价只含首次部署，另一个含运行与移交，两者不能直接比较。英国 DDaT Playbook 在交付模式评估中同时考察内部、外部与混合安排，并把建设、运行和退出纳入成本比较。² 《项目经济性：把双方的账算清楚》会展开算法；此处先确保比较没有漏掉甲方自己的工作。

平台与伙伴也不能只按品牌分工。平台厂商可能负责受维护的软件，行业伙伴理解设备业务，现场团队负责连接与试用，甲方决定业务取舍。若错误发生在这些边界之间，合同中每家都“完成了自己的部分”，主管却依然不能派单，甲方买到的就是一组部件。需要有人追踪整条工作，能够要求相关方定位问题，并有资源解决接口冲突。

这项整合责任可以由有能力的内部团队承担，也可以明确委托。改变承担者以后，甲方仍须知道怎样判断它是否做到了。

外部人进来，内部什么也不能空着

英国议会公共账目委员会在 2026 年 2 月对 NS&I 转型的审查中指出，机构缺少所需能力，招聘困难，大量借助顾问，却仍未形成明确的资源管理策略。³ 这是传统数字转型的相邻反证，不是 FDE 项目失败记录；它提醒采购者，买入人员不等于建立了管理这些人员、知识和依赖关系的能力。该项目的替换困难留在《边界、风险与退出》展开。

回到维修企业，即使技术工作全部由乙方完成，甲方也不能空出三个位置：有人决定维修工作优先改善什么；有人能确认数据和系统的使用边界；有人在试点结束后对运行安排作出选择。第一位不一定懂模型，第二位不一定开发应用，第三位也未必亲自值班，但他们必须能调动对应资源。

若目前没有人能承担，不必马上宣布项目永远不可行。可以先缩小到不改变生产动作的材料检查，安排内部人员和外部专家一起查明缺口，再决定是否进入试用。不能把这种准备工作直接承诺为生产上线。

还有一种合理选择：甲方愿意长期购买托管服务，而非全部接回。此时内部需要保留的是理解服务、监督结果、控制权限和更换方案的能力；不必为证明“自主”而复制供应商的每个岗位。长期依赖若是经过比较并有清楚代价的选择，与项目结束时才发现无法离开，是两回事。

先共建，再决定要不要自建队伍

内部 FDE 值得单独讨论。若企业多个业务单元反复遇到相似难题，一支能够进入现场、改动公共平台、再把经验带回来的内部团队，可能比每个部门各自买一套方案更合适。这里看的是工作机制；不能因为团队服务内部客户，就把所有企业软件开发都叫 FDE。

建立这支队伍之前，可以用一次共建检验三件事。第一，需求会不会持续出现，还是一次迁移做完便结束。第二，现场工作能否形成企业愿意长期维护的公共能力。第三，业务部门是否持续提供人员时间，而非在启动会后把项目交给技术部。

维修企业若只有一个区域需要已知接口，常规实施加现有系统工程师接手可能足够。若多个区域的派单规则不断变化，内部平台又需要吸收这些变化，可以让内部工程师先与外部 FDE 共同完成一轮修改和恢复，再决定哪些能力应留下。共建合同应允许这段学习，并给内部人员实际操作的机会；旁听演示不等于获得能力。

自建队伍也不会自动摆脱平台依赖。团队自己写了应用，仍可能依赖模型、云服务、专用工具和少数熟悉业务的人。真正需要回答的是：哪些部分值得自己掌握，哪些可以购买，哪些在供应商变化时必须能够替换。对这些边界有清楚答案，再决定招聘，顺序才不会倒过来。

在作出承诺之前，取得能够改变决定的证据

采购比较可以从一小包共同材料开始：正常工单、缺字段的工单、权限不满足的工单，以及主管目前完成它们的步骤。材料只能在已有许可范围内使用；缺少可用材料，本身就是实施条件尚未具备的证据。

请每个候选方案解释同一件事：哪些步骤现在就能完成，哪些要配置，哪些需开发，哪些尚不确定。让甲方的一线人员参与操作，记录新增复核与等待，不只看乙方熟练演示。再确认出现错误以后，由谁定位、怎样退回原流程、后续维护包含什么。

得到的决定可以是购买、内部建设、共建，也可以是先补数据、缩小问题或停止。每种决定都应留下一个可以复看的理由。例如：“现成系统能满足已确认的工作，先不建队”；或“建议如何嵌入派单尚未解决，批准有限共建，但不承诺自动派单”；或“本区域有改善，但不足以证明需要全公司常设部门”。

企业是否值得引入 FDE，就在这些区别里。它应当比可用的替代方式多解决一个真实问题，而甲方愿意为相应的协作、学习和长期责任付出资源。