实施方怎么选:先分清谁能改变什么
上一章从个人成长看FDE需要练习什么;换到采购一侧,问题变成怎样判断一支团队是否真的具备这些能力,以及谁有权作出改变。
一份AI合作方案可能同时写着模型、咨询、集成、Agent和FDE。名称越来越多,采购者反而更容易漏看一个问题:当流程需要改变时,究竟谁有能力和权限把它改掉?
前面第二篇帮助判断是否值得组织FDE团队,本篇进一步看外部实施方。这里不按公司规模排座次,而是沿着真实工作分工观察:谁提供平台,谁重画业务流程,谁接通现有系统,谁在现场处理例外,谁承担长期运行。几种能力可以来自同一家公司,也可以由几方共同提供;合同上的总负责人仍要说明它们怎样接续。
合作网络扩大,责任不能跟着变模糊
2026年2月23日,OpenAI的Frontier Alliances把BCG、McKinsey、Accenture和Capgemini与其FDE团队放在同一合作网络中。公告区分研究与产品经验、经营及组织转型、系统集成和全球交付。它证明一种分工安排正在形成,不能证明四家已经替每个客户实现同样的结果。1
另一种组合来自财务咨询。2026年10月13日,Accordion宣布收购软件工程公司Stride,称约50名FDE将加入,并计划将工程团队与其财务、运营专家配合;Stride在拉丁美洲的团队也会进入其交付网络。2 这说明企业可以通过收购组合领域与工程能力,却不证明团队整合已经产生客户收益,也不能把收购公告中的人员计划当成某个项目的实际配置。
对采购者而言,要核对的不是两种头衔是否同时出现在组织图上,而是财务专家能否确认业务规则、工程师能否修改系统,以及两者对客户的同一项结果怎样共同负责。
选实施方时,可以据此形成一张能力地图。下表是本书的采购分析框架,不是上述公司的独占能力或承诺。
| 卡住的工作 | 优先检查的能力 | 请候选团队拿什么说明 |
|---|---|---|
| 模型或平台内部能力不够 | 厂商产品工程与升级通道 | 谁能改产品,现场问题如何进入产品排期 |
| 各部门目标互相冲突 | 业务重设计与变更管理 | 谁决定新流程,哪些旧步骤和指标随之改变 |
| 资料、身份、订单系统接不起来 | 集成与数据工程 | 哪个系统为准,跨系统失败怎样恢复 |
| 本地例外无法用总部模板处理 | 现场领域知识与工程修改权 | 哪个例外由谁解释,远程团队如何收到可执行决定 |
| 软件能跑但团队不会接手 | 运行与能力转移 | 客户能否独立改一项规则、定位一次错误 |
| 问题已标准化 | 现成产品或常规实施 | 更简单方案能否达到同一验收要求 |
这里最容易误买的是第三种和第一种的混淆。连接ERP很熟练——ERP是管理采购、生产、库存和财务等业务的基础系统——不意味着团队能修改基础模型;与模型厂商有伙伴关系,也不意味着它拥有客户财务系统的变更权。采购前要请双方指出具体接口和负责的人,而不是只展示伙伴Logo。
真正要购买的是一条改进路径
AWS在2026年6月30日的伙伴FDE公告中,提出初期由AWS工程师与伙伴深入共建,后续转为帮助伙伴扩大自身实践;交付工具、领域模型和评估等知识形成由伙伴持有的可复用体系。公告当时仅覆盖有限伙伴。3
这有助于解释大规模交付为什么不只靠增派人手:前一项目留下的判断与工具,能够降低后一项目的重复建设。但“伙伴留下知识”与“客户获得自足能力”是两个命题。采购者要另问:自己得到的源码、配置、测试、权限说明和故障处理办法,是否足够支持下一次修改?实施方保留通用资产可以合理,客户也需要知道运行依赖在哪里。
不必要求每一项底层工具都归客户所有。需要写清的是,当当前团队撤离、第三方模型更新或合约到期时,谁能继续操作客户专用系统,哪些能力仍需订阅或授权,替代路径要花多少工作。这些问题应在试点时取证:让客户工程师独立改一项业务条件,再由原团队检查结果。若连小改动都不能完成,“移交培训完成”就不足以证明接手能力。
用反对意见检查自己的采购理由
9月29日,Gartner对供应商FDE构建的Agentic AI提出一项反对意见:成本可能上升,客户也可能难以独立演进。公开页面没有提供足以复算预测的样本与方法。4
这些风险值得用来检查方案:如果范围和接口已经清楚,常规实施是否更合适?若现场发现不了共同产品问题,FDE溢价购买了什么?如果客户永远不能独立改变规则,快速上线节省的时间是否换成了长期等待?
一种相反的判断也有道理:复杂平台仍需要供应商长期参与,完全自建会损失专业支持。关键不在于强迫供应商离开,而在于客户能否作知情选择。要续约,应当因为对方持续解决了值得付费的问题,而不是因为只有对方知道系统怎样运行。
把第一次合作做成可比较的试验
下面是教学示例:一家批发企业要改善订单核对。候选方案A购买现成文档提取工具;B由集成商连接订单系统;C由厂商与客户共同工程,处理尚未解决的跨系统语义问题。示例没有虚构任何公司的报价或结果。
首先让三方使用同一批经授权的订单,包含少发、退货、跨币种和客户简称。比较目标不是谁的演示最像真人,而是哪些请求可完成、哪些须人工决定、错误如何发现、内部人员能否修改规则。工具若能解决主要问题,就缩小共同工程范围;若接口是障碍,先补集成;若标准产品和常规集成仍无法解决关键业务含义、运行条件或产品能力的不确定性,再购买范围相应的FDE投入。
确定合作后,把交付写成几个可检查的动作:数据负责人确认字段和访问边界;业务负责人确认冲突怎么处理;实施方修改系统并提交证据;客户批准上线并安排运行者。异常一旦跨越几方边界,指定一个负责人把它追到恢复,不能把“等待厂商”当成工单的终点。
下一章先读Palantir从现场工程到AI FDE的演进,再比较大型实施伙伴的做法。读者可以带着同一问题去读:这家公司在这个案例里实际改变了哪一段工作,又有什么仍留给客户?
-
OpenAI,Introducing Frontier Alliances,2026-02-23;2026-10-01重读32–61行。联盟安排与分工,不是客户成效证明。 ↩
-
Accordion,收购Stride公告,2026-10-13;2026-11-04读取第5–26行。公司对收购、团队和计划的披露,不证明项目经营成效。 ↩
-
AWS,Introducing Forward Deployed Engineering for Partners;页面日期2026-06-30,访问2026-10-01;读取243–263,共建、partner-owned harness、支持转移。初期有限伙伴公告;知识归伙伴与客户自足不等价;未证明全部执行完成。 ↩
-
Gartner,Gartner对供应商FDE交付的预测;页面日期2026-09-29,访问2026-10-01;读取142–174;预测、退出与客户能力。预测非已发生失败率;页面未公开样本与模型。 ↩