Infosys、TCS与Fujitsu：规模交付怎样保留现场知识

服务很多国家，不等于每个国家使用同一套工作方式。全球实施公司的难题，是让共同技术能够复用，同时保留决定业务是否成立的本地知识。本章观察三个不同层次：Infosys的具名应用推出、TCS的跨国整合计划，以及Fujitsu明确的FDE伙伴安排。

三家公司来自不同总部地区，本章不据此推断当地企业文化。要观察的是项目在哪里实施、客户一方谁有决定权、哪些能力已经交付，以及哪些仍是计划。

Infosys与ATP：新AI应用长在已有资料上

2026年1月12日，Infosys与ATP宣布推出Ally。公告把它接入已有ATP Stats Centre，提供赛事、球员和历史资料问答，并描述内容过滤、个人信息移除与上下文检查。双方数字合作始于2015年；Ally是2026年的新应用，不能把十年合作时间算成十年AI运行记录。¹

案例没有明确FDE称谓，也没有公开足够的测试样本证明防护可以消除幻觉。它能说明一个建设路径：新界面依托既有业务资料与长期数字关系，而不是从零凭模型记忆回答。旧资料系统的意义、更新节奏和权限因而需要进入新应用。

按这一入口设计验收，可以先检查一个会变化的事实：赛程改动后，系统读取的是哪份记录，怎样说明更新时间？再检查同名球员、已结束赛事与无记录的问题。这里是本书的教学建议，不能写成Ally已经公布的测试方法。验收目标也要分开：资料正确、检索正确、表达清楚与使用体验，并不是同一指标。

TCS与METRO：集中治理不等于取消本地决定

9月3日，TCS宣布被METRO选为战略伙伴，以AI相关方案支持各国独立系统向更集中治理的技术环境演进，并进行变更管理。METRO的CIO同时强调本地相关性与中央治理。公告描述的是合作及未来工作，不能写成欧洲、亚洲各市场已经完成迁移。²

这份材料把全球交付的重要矛盾说得很具体：共同系统能够减少重复，但市场仍可能有必须保留的差异。哪些差异应形成共享配置，哪些需要本地规则，哪些只是旧流程留下的偶然做法，需要客户作业务判断。实施方不应把“统一”作为默认正确答案。

以发票核对作教学例子。不同市场可能有不同税务字段和审批角色；同一订单对象可以共用，放行条件却不能只复制总部设置。首先列出数据结构、业务规则和权限三类差异，再确定每一类由中央还是当地负责人批准。对共同部分建立统一测试，对地方差异保存各自例外与依据。

若现场人员只有提出问题的渠道，却没有确认规则的权力，远程团队容易反复等待。相反，如果每个国家都能修改全部逻辑，共享系统又可能失去一致性。项目需要一张决定表，让修改进入适当层次，而不是把所有差异扔给“本地化”这个词。

Fujitsu与Palantir：FDE合作要落在客户环境

Fujitsu与Palantir在9月10日公告中明确使用Global FDE Partner安排，并把数据、模型、业务流程和治理放入客户控制的执行环境。本书采用这项组织与技术方向，不采用公告中的匿名制造商成本与生产率数字。³

伙伴身份能够说明双方怎样提供能力，仍不能替客户证明权限、审计和运行条件已经满足。应当请实施团队展示一次真实授权：谁可读取哪些数据，Agent能做哪些动作，谁批准业务例外，日志怎样交给客户检查。客户控制环境也需要具体解释；账号属于客户，却只有供应商掌握配置和故障知识，接手依赖仍然存在。

Fujitsu材料与前两案的区别，应保留下来。ATP是具名应用推出；METRO是具名整合任务公告；Fujitsu是明确FDE伙伴与治理方向。不能把这三种证据相加，算成三个独立证明“全球FDE效果”的成功案例。

留下统一接口，也留下解释权

从采购者角度看，大规模交付至少要留下两类资料。一类解释共同部分怎样运行：数据对象、接口、部署与测试。另一类解释为什么存在差异：谁确认某条地方规则，它何时复查，变更会影响什么。只有前者，接手者可能把重要例外删掉；只有后者，下一次工程修改又无从下手。

可以在交接前做一次小演练：中央团队修改共同字段，当地人员确认本地规则，工程团队运行两类测试，最后由接手者解释影响。发现冲突时，记录由谁决定保留、统一或暂缓；不要让最有经验的工程师凭记忆替客户作长期决定。

采用全球服务商，不意味着客户必须外包全部判断。其价值可以是提供可复用技术与足够交付能力；客户需要保留的，是能够定义业务差异、检查结果和继续改变的能力。两者的接续，比总部属于哪个国家更能说明项目能否维护。