一家老牌服务商的身份焦虑
Endava 是一家拥有超过 25 年历史的全球技术服务公司，长期以来的核心能力是帮助企业客户用技术解决复杂业务问题。当生成式 AI 在 2023—2024 年快速渗透软件工程领域时，Endava 面临的问题不是"要不要用 AI"，而是"如果客户自己也能用 AI 写代码，我们作为服务商的价值在哪里"。
CTO Matthew Cloke 在官方访谈中把这个问题说得很直接："我们必须回答，在新的 AI 世界里如何继续做一个有意义的组织。"这不是一个技术选型问题，而是一个商业身份问题。Endava 的应对策略是把 OpenAI 设为企业级 AI 平台，向全公司员工开放 ChatGPT Enterprise 和 Codex，并提出一个组织行为要求：解决问题时，先考虑 AI 能否完成，而不是最后才想到 AI。
这个决策的激进之处在于它不是一个工程团队的试点，而是一个全公司的行为预期。Cloke 的原话是："在 Endava 做到 AI-native，意味着 AI 是你做的第一件事，而不是最后一件事。"
编码加速之后，瓶颈去了哪里
Endava 的 AI 转型从软件交付团队内部开始。开发者最先接触 AI 辅助编码和智能体工作流，编码环节的产出速度确实提升了。但团队很快发现，工程产出不再是瓶颈——需求收集、业务分析、项目规划和利益相关者协调才是。代码写得再快，如果需求文档要等两周、业务方案要反复对齐、治理报告要手工拼接，整体交付速度仍然受限。
这个发现改变了 Endava 的推进方向。团队开始追问：能不能用同样的速度产出需求？能不能更快地为客户生成正确的业务方案？Cloke 在访谈中说，他们"开始挑战需求产出和业务方案产出的速度"。
这个瓶颈转移的逻辑对所有软件服务商都有参考意义：AI 编码工具提升的是工程环节的局部效率，但如果上下游流程不同步加速，整体交付周期的改善会远低于预期。Endava 的选择是把 OpenAI 技术嵌入整个 DavaFlow 生命周期——从会议准备、业务规划到产品发现、软件工程和部署。Cloke 的说法是："DavaFlow 没有任何一个环节不使用 OpenAI 技术。"
DavaFlow：AI 嵌入交付全链路的实际样貌
DavaFlow 是 Endava 的软件交付方法论框架。官方材料描述了 AI 在其中的嵌入方式，但没有披露完整的技术架构或系统集成细节。从已公开的信息来看，AI 的应用覆盖了以下几类工作：
在工程环节，开发者使用 AI 辅助编码和智能体工作流。在项目管理环节，项目经理使用 Codex 生成治理报告并总结工程进展。在商业环节，团队用 AI 生成的轻量级应用替代了以电子表格为主的规划工作。一个具体的例子是：在一次内部定价讨论中，员工跳过电子表格，直接构建了一个可交互的单页定价应用。Cloke 说这"完全改变了对话"。
AI 的应用也扩展到了非工程团队。法务团队开始使用 AI 简化研究和文档工作流。领导团队使用智能体总结项目、自动化沟通、管理收件箱并异步协调工作。Cloke 本人在访谈中说："如果我没有一个智能体在后台运行，我会觉得自己在浪费时间。"
不是软件部署，是行为变革
Endava 在推广过程中形成了一个明确的判断：AI 采用是行为变革，不是软件部署。这个判断体现在两个具体的组织动作上。
第一，Endava 把 AI 熟练度纳入了全公司的招聘和晋升期望。这意味着 AI 使用不是可选的个人偏好，而是组织对员工的正式要求。第二，Endava 要求领导者本人积极使用 AI，以此驱动全组织的采用。官方材料中总结的经验包括：为实验创造空间（即使结果不完美）、尽早让非技术团队参与、把 AI 融入日常工作流而不是作为独立项目。
这些组织动作的覆盖范围是 Endava 的 11,000 人全球员工队伍。但需要注意的是，官方材料没有披露实际的活跃使用率、不同职能的采用比例，也没有说明 AI 熟练度在招聘和晋升中的具体评估标准。"向 11,000 人推广"描述的是推广范围，不等于 11,000 人都在日常使用 AI。
另一个值得关注的结果是：非工程团队开始能够在没有专门工程支持的情况下构建内部工具和应用。定价应用的例子说明，当商业团队可以直接用 AI 生成可交互的工具时，他们不再需要排队等待工程资源。这改变的不仅是效率，还有组织内部的协作模式和资源分配逻辑。
已报告的结果与未披露的口径
Endava 官方案例的结果摘要包含五项陈述：通过把 AI 智能体集成到工程工作流加快了软件交付；把 AI 采用从工程扩展到法务、财务和运营团队；通过 AI 辅助工作流减少了手动报告和协调工作；使团队无需专门工程支持即可构建内部工具；把 AI 熟练度纳入招聘和晋升期望。
这五项陈述中，没有任何一项附带量化数据。"加快了软件交付"没有披露基线交付周期、加速幅度、观察期或项目样本。"减少了手动报告和协调工作"没有披露减少的比例或工时。"扩展到法务、财务和运营"没有披露各职能的采用深度。这些都是方向性陈述，不是可复现的效果度量。
从证据结构来看，这个案例的价值不在于效果数字，而在于组织决策的逻辑：一家万人规模的技术服务商如何把 AI 从工程工具扩展为全公司的工作方式，以及在这个过程中遇到了什么（瓶颈转移）、做了什么取舍（行为要求而非可选工具）、改变了什么协作模式（非工程团队自建工具）。
什么条件下这个路径可以参考
Endava 的路径有一个关键前提：它本身就是技术服务公司，员工的技术素养基线远高于多数行业。当它要求"解决问题时先考虑 AI"，这个要求落在工程师和技术顾问身上的阻力，与落在制造业或零售业员工身上的阻力完全不同。把 AI 熟练度纳入招聘和晋升，在技术服务公司是自然延伸，在其他行业可能需要先解决基础培训和岗位重新定义的问题。
瓶颈转移的发现具有更广泛的参考价值。任何已经在工程环节引入 AI 编码工具的组织，都应当检查需求、规划和协调环节是否成为新的约束。如果只加速编码而不处理上游，整体交付改善会打折扣。但 Endava 用 DavaFlow 全链路嵌入来应对这个问题的方式，依赖于它对自有方法论的控制力——为客户做项目的服务商可以改自己的流程，但不一定能改客户的流程。
对于考虑类似路径的组织，有三个问题值得在启动前回答：第一，你的 AI 推广是工具部署还是行为要求？如果只是提供工具而不改变组织期望，采用率可能停留在早期采用者。第二，你是否已经识别了编码加速后的新瓶颈？如果没有，先做一次端到端交付链路的时间分析。第三，你的非工程团队是否有足够的技术基础来使用 AI 自建工具？如果没有，可能需要先投资于低代码/无代码的 AI 应用层，而不是直接开放 Codex。
补充信息与证据说明（1）
本文基于 OpenAI 官方案例页面（openai.com/index/endava-frontiers）的公开信息编写。所有企业事实和引述均来自该来源。官方案例未披露软件交付加速的量化幅度、活跃使用率、质量指标、权限控制、审计机制或异常回退方式。文中人机协作图的人工决策层为 DataHub 基于行业惯例的合理推测，不代表 Endava 的实际流程。迁移判断中的前提分析为 DataHub 编辑观点。