$SAP SE(SAP)$
Deepshikha Agarwal
高盛集团（Goldman Sachs Group, Inc.）研究部
那就接着你提到“节奏很快”的点，现在关于 Agentic AI 可能会如何颠覆应用软件的讨论明显加速。你怎么看当前的局面？在你看来，谁会成为相对的赢家或输家？
Sean Kask
是的。房间里的大象，对吧？问题基本就是：SaaS 死了吗？现在确实是个大争论。
不，我的意思是，看，我认为有两点。从 SAP 的角度，一是我们承认这是一项颠覆性技术，我们正在积极拥抱它，在某些领域主动进攻。AI 肯定会颠覆用户界面，也就是你如何与计算机交互。
你可以拥有意图驱动的 ERP 系统：你告诉系统要做什么，对吧？你输入意图、输入提示，它就会去执行并完成事情，对吧？所以你可能不再需要在 UI 里点来点去了，对吧？此外，用户界面里会越来越多地包含“生成”的元素。我们已经宣布过，我们把它叫做 Gen UI（生成式 UI）。实际上 Joule 里已经有一些这样的元素了，对吧？
比如你调出一个图表之类的，它其实是应用当场生成出来的。未来，我们也可能会出现这样一种情况：不是人类在和 SaaS 对话，而是智能体在和 SaaS 对话，人类只是收到通知。于是 UI 在某种程度上会被颠覆。但我确实认为 UI 仍然有一定粘性。
人们——我太太的朋友在苏黎世一家贸易公司工作，她跟我抱怨，因为他们从她用了 10 年的 ECC 系统迁走了，而她已经完全知道该点哪里，她就喜欢那套，对吧？这些东西会一直共存，对吧？所以你总会有 UI。而且其中的逻辑仍然可以被智能体和生成式 UI 等访问。我们在积极拥抱这一点。我们已经推出 Joule，所以我们在这方面有很扎实的基础。
第二，这项 AI 也会颠覆软件如何被构建和维护，对吧？毫无疑问。我们看到 vibe coding（氛围编程）和 AI 结对编程的进展非常快。这带来一些机会——我想这也驱动了一些关于颠覆的恐惧，对吧？对我们来说，我们也在用 vibe coding，对吧？我们已经把它推给公司所有开发者，并且看到生产力大幅、显著提升。
但我们用 vibe coding 写出来的东西，会在进入生产前通过我们 388 项产品标准和测试，对吧？所以这是企业级软件。但我们既能 vibe code，也能把这种能力提供给客户，让他们快速构建扩展，对吧？比如我们有 SAP Build。我们发布了 Joule Agent Builder。作为用户，你可以进去用 vibe coding 给 SAP 系统做一些小扩展。从我们的角度看，这会提升我们系统的价值。
第三，我认为 AI 也会在某种程度上颠覆商业模式，对吧？目前有一个很大的争论：未来基于座席的订阅和许可会怎样？从 SAP 的角度，有几点。第一，我们现在的 AI 商业模式其实是基于消耗（consumption）的。我们几年前就谈过。内部做了大量工作：我们构建了能力，可以对系统里运行的每一个智能体或用例进行计量（meter）。
所以如果有人用 AI 处理发票，或者在装运场处理送货单之类的，这都会被计量，并计入这些 AI 单位（AI units），对吧？我们基本上采用的是一种“承诺—消耗”（commit-to-consume）的模型。你订阅一定数量的 AI units，然后这些会汇总成一个池，你再去消耗，对吧？而且每一个 AI unit 都与一个业务结果绑定。某些地方可能跟消息数之类挂钩，但只要我们能做，我们都会尽量把它绑定到业务结果上。我们其实已经把这套做出来了，对我们来说已经落地了。
另外一点，我认为我们座席制的占比不到 50%。我不确定我们披露的是 50% 还是 40%。其余部分其实是基于不同业务指标，比如“受控支出”（spend under control）、系统里的业务单据等。所以在这里我们也是在主动进攻。
而我也认为我们有防守型护城河。一个当然是我们拥有的数据，这有点像老生常谈，对吧？“你拥有数据”。但不仅仅是数据，而是拥有数据模型本身，以及围绕数据的语境含义，对吧？我们在利用这一点。我们构建了知识图谱。我们现在有业务数据云，可以把 SAP 和非 SAP 系统中“语义丰富”的数据暴露出来供智能体消耗，对吧？
我们有这些数据，客户也信任我们把它交给我们。另一个防守护城河是客户信任，对吧？我听过一个可能最强的反对 vibe coding 的论点：周五晚上 8 点你必须关账，但总账对不上。你打给谁？你是打给 SaaS 供应商让他修？还是打给那个 vibe coded 某个东西的人，让他去搞清楚到底发生了什么？所以我们系统显然拥有大量客户信任。
所以我认为——我当然有偏见——但我确实认为我们处在一个很好的位置，能够在这一波里成为赢家。
Mohammed Moawalla
高盛集团（Goldman Sachs Group, Inc.）研究部
有一种观点认为，横向软件相对更暴露在这种风险之下，而纵向软件更不容易。但你也可以说，我们也见过纵向软件用例被挑战的情况。你们很有意思：你们卖横向软件，但也为特定行业构建产品。当然制造业是你们重要的终端市场。
如果用云时代发生的事情类比 AI 现在发生的事情，我们应该如何看待你们的演进、以及你们驾驭这一轮周期的能力？你提到了数据护城河，还有流程知识。当应用层发生颠覆、我们所熟知的模块和业务线应用明显变化时，从你们的角度，SAP 要穿越这一轮，你觉得我们应重点观察哪些关键点？Joule 最终会不会成为“最终答案”？但很多客户可能并不想用 Joule，他们会说“我用别的智能体”。请帮我们理解这种边界模糊——在 AI 世界里应用层的界线正在变得模糊——我们该如何看待？
Sean Kask
是的。我有点不太愿意把我们完全放进“横向玩家”的盒子里。因为如果你看我们在财务领域做的事情，其实非常深。比如你想知道如何在巴西处理一张发票并满足 Notifiscala 之类的合规要求，我们都覆盖。我们确实很深。当然，我们也有很多行业解决方案，比如零售里的客户活动库（customer activity repository）之类。
这也很有意思。有些应用你会以为可能被颠覆，但比如一些带网络效应的消息类应用，看起来对颠覆非常有韧性。我有个原则是不谈竞争对手。但如果回顾 SAP 的历史，2016 年左右吧，我记得我们在 Sapphire 大会上请过 Clayton Christensen 上台——他在去世前谈过《创新者的窘境》。
我们有很强的传统，就是主动颠覆自己的商业模式：从客户端服务器架构，到内存数据库，再到云和 SaaS——那基本就是在颠覆一个利润很好的模式：卖许可证，再收 20% 的维护费，客户自己做安装。我在这里也看到同样的精神。我们正在拥抱生成式 AI 带来的机会。
Deepshikha Agarwal
高盛集团（Goldman Sachs Group, Inc.）研究部
从你的视角，你怎么看整个 agentic AI 世界里总体格局的演化？在既有巨头、新一代 AI 原生玩家、LLM 提供商，甚至企业一定程度自建之间，会如何变化？
Sean Kask
是的。我脑子里想到的是波特五力模型，对吧？替代品、竞争之类。
看，我们看到模型在商品化，对吧？这已经持续一段时间了，token 的价格一直在降，能力也在收敛、趋同，这并不奇怪。模型提供商至少会尝试向上走一点“堆栈”。
所以我们看到他们开始做第一批 PaaS 产品，比如 OpenAI Frontier。顺便说一句，Gartner 两周前发了个说明，提醒客户要小心，因为他们可能无法规模化——我只是复述 Gartner 的话——还有 Claude Cowork 之类。于是他们当然会向上推一点。
从我们的角度看，超大规模云厂商和 PaaS 供应商多年来一直试图向应用层上爬，老实说，他们并不怎么成功。我认为构建这些应用需要的知识不能低估。对我们来说，我们对待模型提供商和超大规模云厂商的方式和过去一样：把他们当合作伙伴。
比如我们积极参与 A2A 协议、MCP，我们是 MCP 协议的创始成员之一。我们和他们合作。当然他们会试图向上爬一点。我们也看到 AI 原生领域现在大概有 600 家初创公司在涌现，这是我们在关注的。我觉得它们可能也面临很多初创公司的共同挑战：要达到企业级就绪（enterprise readiness），才能和我们竞争。
Deepshikha Agarwal
高盛集团（Goldman Sachs Group, Inc.）研究部
追问一下。你觉得传统厂商策略会怎样？会去收购这些 AI 原生玩家，还是会选择把这些 AI 能力都在内部自建？哪边会更重？
Sean Kask
是的。我觉得过去两年 Salesforce 和 ServiceNow 做了一波从 AI 公司收购的“买买买”。老实说，我不觉得市场因此奖励了他们。我们这边——我们去年收购了 SmartRecruiters，在 HR 领域，是为了增强我们的招聘模块和 SuccessFactors。但对我们来说，现在做并购挺棘手，因为对所有人而言这些东西都很新。
我们还没看到一家初创公司，让我们觉得“他们有某种惊人的能力，而别处完全没有”。大家基本都在用同样的水做饭，而且现在初创公司的估值非常离谱。所以从我们的角度，我们会监控它们。我们和它们保持很紧密的合作。我们也和很多初创公司广泛合作，但目前我们更多是在观察市场。
Mohammed Moawalla
高盛集团（Goldman Sachs Group, Inc.）研究部
明白。我想回到你关于数据护城河的评论。系统记录（system of record）是“单一事实来源”（single source of truth），很难被替代。但我们越来越看到像 Claude Cowork 和 OpenAI Frontier 这样的东西，希望坐在系统记录之上，作为一种抽象层。
未来这会不会成为可行方向？它们就坐在上面，但最终——因为数据访问也是另一个关键特性，许可协议等会扮演关键角色——是否存在一种情景：系统记录变成一种“傻管道”（dumb pipe）——抱歉用这么强的词——还是说不会？因为你们还有业务逻辑、元数据等等。所以我想问，这会不会成为下一个大的战场？
Sean Kask
每个人都想成为那个抽象层，对吧？想成为坐在其他应用之上的编排器（orchestrator）。但我认为现实里，未来会是：大玩家都会有自己的智能体、自己的 Copilot，在自己的系统里做编排。而这些编排器和智能体之间又必须协作。
比如 Joule，它能访问 SAP 系统里的数据、上下文、授权、计量、日志等一切东西，而第三方智能体坦白说做不到。并且我不确定我是否愿意——我也不确定我们的客户是否愿意——允许某些第三方智能体对 SAP 系统有不受限制的访问，因为那会变成安全和审计的噩梦。
所以我看到的未来是：你会有这些助手、copilot，它们在各自领域里很强，通过 A2A 等协议彼此协作。我不认为会有人真正成为那个“超级编排器”接管一切。
我也补充一点，我们其实很开放。我们算是第一家——我想我们是第一家——与 Microsoft Copilot 做双向集成的公司，这现在已经 GA（正式可用）了，也包括 Joule。比如我在 Copilot 里说“帮我订行程”，它会去调用 Joule 和 Concur，然后在 Outlook 日历里创建条目，反过来也可以。
所以我们在这方面是开放的，但我不认为有人能现实地接管。听起来很有意思，因为 Anthropic 和 OpenAI 其实有点像“聪明但很笨”，对吧？你把你最聪明的朋友雇来，让他去操作 SAP 系统，他也不知道该干什么，对吧？所有关于如何运行流程的知识都被编码在我们的系统里。这就是它有价值的原因。
Mohammed Moawalla
高盛集团（Goldman Sachs Group, Inc.）研究部
对。顺着这个再追问一下，显然你们有 BDC（Business Data Cloud），大概是一年前发布的。请帮我们理解它在更广义的数据模型里扮演什么角色。
Sean Kask
当然。业务数据云（Business Data Cloud），先说清楚，它是一个 SaaS 产品。而且它和市场上的东西有点不一样。它不是一个数据湖（data lake），好吗？你不是把数据抽取进去，然后再在里面构建数据模型和 PaaS（就像其他方案那样）。当然你也可以抽取，它也包含这部分组件。但它实际上是坐在上层，或者说与合作伙伴方案集成，比如 Snowflake、Databricks、BigQuery，因为客户已经在 Snowflake 上投入了时间，对吧？SAP 和非 SAP 数据、外部数据，做汇总，对吧？
Business Data Cloud 坐在上面，遵循一个叫 data products（数据产品）的理念。我们会发布大约——我记得我们目标是 500 个来自 SAP 系统的数据产品。比如你如何一致性地定义“销售订单”或“采购订单”，因为它的数据模型可能不同，取决于是 Ariba 系统还是 S/4 系统等。我们把这些作为数据产品暴露出来。客户也可以把他们在其他数据湖里构建的那些数据，以数据产品形式暴露出来。这样就变成了语境丰富的数据。
于是你就可以把智能体放在上面。比如我在做规划——比如人力规划、招聘规划——我可能需要知道销售预测，对吧？我需要招多少人？这些数据可能在 Workday 系统和 S/4 系统里。现在我们就可以通过 Business Data Cloud，把 Joule 原生放在这些数据产品之上。所以它把 SAP 和非 SAP 数据汇聚起来，我们当然也会以一种能被智能体轻松消耗的方式对它进行变现。因此这是一个非常重要的组成部分。
Deepshikha Agarwal
高盛集团（Goldman Sachs Group, Inc.）研究部
你提到了 Joule，而且 Joule 的客户数量在 2025 年几乎增长了 9 倍。能否谈谈你看到的、正在出现的一些有趣新用例？以及在生产力方面，有没有任何可量化的提升？你们是如何衡量的？
Sean Kask
是的。我想我们去年讨论过，采用曲线其实没什么特别的，就是典型的采用曲线：你发布产品，客户评估、购买、上线。于是你会看到一个类似“冰球杆”的曲线，对吧？客户采用 Joule 的数量增长了 9 倍。
我觉得现在在 Joule 里我们发布的最令人兴奋的东西是智能体。让我先岔开一下：我们不想玩“智能体数量”的计数游戏。我们对“什么叫智能体”设了非常非常高的门槛。因为你可以把任何 RAG 用例（比如信息检索）叫做智能体。我在 SharePoint 就经历过：它说“我是你的 SharePoint agent”，但它唯一做的就是把 SharePoint 页面总结一下。我就觉得这不太有用。
对我们而言，智能体必须具备 agency（自主性）：它必须能够规划，并迭代地通过多个步骤和工具完成任务，我们才称之为智能体。现在智能体在一些“范围窄、约束强”的用例里效果非常好，也已经达到生产级。
例如我们发布的一些智能体：财务里的应计（accruals）会计。也就是你什么时候入账成本和收入，对吧？做应计会计时，可能取决于一份 PDF 政策文件，可能取决于一些邮件往来、过去的决策等。这很难自动化，但智能体可以迭代推理完成，并且还会提供解释，让会计去看它怎么得出结论，然后说“对，是这样”。
我们认为，对一家中型公司来说，季度末可能要花 12 小时做应计入账，这可以缩短到 2 小时。生产计划智能体也是类似。你在做生产计划时，可能出现交付延误、缺零件，或者来了一个必须优先的大订单，然后你得回去重新排产，这是个优化问题。我们有一个智能体可以迭代推理并优化生产计划。这样你就可以更频繁地做排产，比如一天做几次都行，公司就能卖更多、交付更多。
不过去年真正的明星是 Joule for Consulting。它上个月在世界经济论坛拿了一个奖，叫 MINDS Award，用于表彰具有变革性的行业用例。我们和 KPMG（合作伙伴/客户）一起做的。
我们今年的一个首要重点是：AI 辅助云迁移和 AI 辅助云转型，让客户用更少的投入、更快上云，并且进入标准化的 SAP 架构。Joule for Consultants 的基础是所有 SAP 帮助文档、内部知识库文章。客户也可以用自己的“业务蓝图”（SAP 术语）扩展它。它还利用我们训练在 SAP 代码上的专有大语言模型，叫 ABAP LLM。它可以解释遗留代码、编写单元测试、做很多事情。
长话短说，西门子是参考客户。他们说这能为每位顾问每周节省大约 10 小时。如果顾问每周工作 40 小时，那相当于 25% 的生产力提升。我以前也做咨询，我的日费率大概 2,000 或 2,500 一天，做 SAP 转型。那就是一个巨大的生产力提升。
Mohammed Moawalla
高盛集团（Goldman Sachs Group, Inc.）研究部
很好。那我们开放给现场观众。我相信大家有问题。谁先来？
Unknown Analyst
Helena，来自 Millenium。关于你最后提到的 Joule for Consultants。你觉得这会加速还是拉长 SAP 核心业务的销售周期？我这么问是因为我们的客户有一种想法：哦，我能快 25%，那就做；或者他们会说等等，先别动，也许很快会出新迭代，成本更低、速度更快之类。
Sean Kask
是的。问题是：客户会不会等 AI 彻底把上云转型全自动化，对吧？老实说，这个问题并不完全不合理。我认为客户会把这点与他们上云后能获得的好处一起权衡，因为上云后才能用更多 AI。
坦白讲，Joule for Consulting 现在做的其实只是“可实现之事的冰山一角”。我们也宣布了集成工具链。比如用 Signavio 和机器学习自动绘制流程图。我们也将发布基于 AI 的数据去重与数据一致化，这可以带来巨大的测试自动化。还有很多东西会出来，帮助云迁移。
但我确实没看到有客户在“等待”，觉得如果等一年迁移成本就会少 50%，因为 AI 会完全自动化。我觉得更相反：现在上云本身就已经带来很好的收益，客户也有动力上云，因为在那里能实现更多 AI。
Unknown Analyst
你对 quick commerce（即时电商）具体怎么看……？
Sean Kask
已经有一些协议——我想有两三个。Google 刚发布了 UCP。还有 agentic commerce protocol。它基本上允许智能体替你购物并完成金融交易。
我们在 SAP 的 CX 产品组合以及 SAP Commerce Cloud 中支持它。SAP Commerce Cloud 我们也会开放 MCP servers，因为这会为客户创造更多价值：让智能体更容易在网站上找到商品。是的，我们肯定会支持该协议。我认为这是个很好的机会。
Unknown Analyst
在 SAP 之上构建起来的生态有 1,000 亿美元市值。如果你相信 AI 会把研发/开发的边际成本降到接近 0，而历史上你们一直难以覆盖这些由第三方做的 upsell 和模块。你认为这现在会成为一个真正可解锁的机会吗？还是你觉得还很远，需要很多变化？比如你们去年做了 BlackLine。那类东西现在是否更容易用 AI 在内部做出同等质量？未来几年能做到吗？还是你觉得还离得很远……
Sean Kask
所有迹象都表明，AI 能把开发效率提升大概 20% 到 50%，也就是构建东西的生产力提升。换个角度，也确实存在威胁：会不会出现新进入者挑战 SAP？或者——我在你没完全说完前猜一下——客户会不会因为 vibe coding 太容易而更愿意自己内部构建？
但我认为，我们拥有的资产——我们自己也在应用这些工具，对吧？所以我们是不是可以进入更多市场？我认为，建立在我们已有能力之上，加上产品标准、企业级就绪、知识等这些基础资产，是进入市场的重要底座。你需要这些才能进入。我们也在采取一些措施去做这件事，这也已披露过。
我们在做更多 FTE（全职员工）的“部署式工程”（deployed engineering）。这是产品与工程董事会领域推动的一项举措，OpenAI 和 Palantir 现在也在做。基本上就是派工程师去客户那里，用 90 天冲刺解决他们的真实问题，然后尝试构建东西。对我们而言，我们希望构建可复用的解决方案。
这并不是新事，但有了 vibe coding 和 AI，确实更可行在 90 天冲刺里做到。所以我们可以进入这些市场，未来会提供更多行业解决方案，去覆盖那些我们确实能构建的领域。因为客户和其他人确实更容易构建了，但我们也更容易了，而且我们还有互补资产：客户关系、行业知识等都已经在位。所以它有潜力扩展我们的产品组合。
Mohammed Moawalla
高盛集团（Goldman Sachs Group, Inc.）研究部
这是一个 best of breed？那我们继续。Dominik 提到 SAP 在若干行业或板块里有大约 10 亿美元的增量收入机会。显然，AI 产品（尤其 cross-sell、upsell）中一些过去属于业务线解决方案的内容，现在变成了一些 AI 解决方案。请你讲讲你们看到的牵引力如何？它在多大程度上已经真正起飞？以及现在客户看到其他 LLM 后，会不会更倾向于走自建路线，而不是从你们这里买现成的？
Sean Kask
是的。我想我们披露过——比如非常高的 attach rates（搭售/附加率）。比如 2/3 的订单录入量都带了 AI；最大的前十大交易里有 90% 带了 AI 和 BDC。AI 已经是销售周期中非常重要的一部分，说实话，它本身就是一个激励。
我们当然也支持客户去自建。这一直都是 SAP 系统吸引人的地方之一：客户喜欢进去做定制（不论好坏）。他们可能需要用非标准方式处理销售订单之类，于是他们就进去构建。
所以我们现在也提供工具，比如 SAP Build，其中包含客户端集成，是一种 vibe coding 应用，客户可以用它围绕 SAP 系统构建和扩展。当然我们给他们这个选项，这一直也是我们产品组合的重要组成部分。但我认为它仍然需要建立在“标准核心”（standard core）之上。
Mohammed Moawalla
高盛集团（Goldman Sachs Group, Inc.）研究部
明白。我们接着往下——抱歉，你先说。
Unknown Analyst
关于一些初创公司。当你们提供类似产品时，定价沟通会怎么样……
Sean Kask
好问题。两点。第一，对于我们提供的嵌入式 AI（embedded AI）——不是 vibe coding，而是嵌入式 AI——我们按 AI units 来卖。明确一点，这不是 token。token 是成本的一部分，但商业价值也是利润的一部分。
当我们发布——大家总是给我推用例点子，我感觉我现在都看过了——我们把这些做进产品里。嵌入式能力我们只需要构建一次，包括测试、伦理审查、基准测试、UI 集成等。我们只做一次，然后就可以发布给 5,000 个客户。我们在这之上获取的就是利润。
token 成本、模型成本只是其中一部分。并且我们有一个策略：非常广泛地合作。我们能接入所有前沿模型。我们与 Mistral、Cohere 等都有合作。我们在底层可以按需切换到最便宜、性能最好的模型，某种程度上有“套利空间”。所以在这一块我们能保持利润，客户也能受益。
至于纯 vibe coding，我们的产品并不只是“vibe coding”这一点。比如 SAP Build，里面确实有 vibe coding 组件，别人可能会压价或试图低于我们。但 SAP Build 还有很多其他组件：你需要起数据库、需要构建 CI/CD 流水线等等。我认为这些周边组件是我们盈利所在，也是我们能提供超出他们的地方。
Unknown Analyst
那在客户在边缘（edge）自己 vibe code 的情况下，你们如何保护交叉销售机会？谈谈这个……
Sean Kask
是的。SAP 系统本来就被设计成可定制、可扩展，我们支持这一点。我们优势之一在于我们产品组合很广，再加上 Business Data Cloud，很多增值用例不再是点解决方案，而是会触及多个业务流程和业务应用的解决方案或扩展。
比如我之前提到的规划场景：你可能需要物流、财务、HR 的数据。我们可以用 Business Data Cloud 把数据汇总起来并变现。你可以用 vibe coding 扩展，再在这些方案上扩展智能体。我认为这会强化“套件故事”。至于客户在边缘自己构建，这本来就是我们一直支持的，也是 SAP 的吸引力之一。
Unknown Analyst
我想驱动 SaaS vs AI 争论的一部分，是因为很多创新似乎发生在实验室或初创公司层面。比如微软已经有 Copilot，我也在用。我想问从你的位置看，你觉得你们是否有合适的团队来保持相关性并站在前沿？因为最终切换成本很低，如果有人用 Claude code 而不用 SAP 的 agent builder。虽然客户的数据集对他们更难，但强迫客户用某个产品当然不是好主意。我只是想理解：为什么现有的软件公司在 AI 创新节奏上这么慢，感觉都落后于新产品和各种头条……
Sean Kask
有人在你电脑上装了 Open Claude 吗？天哪，你挺勇的。安全噩梦。不过它确实很厉害。
是的，我并不同意切换成本那么低。再说一次，我认为如果你在构建 SAP 扩展，我们很多大客户本来就是 SAP 体系，他们习惯在系统里工作，也正是因为我们系统在企业级就绪上很成熟：审计等各种需要的东西都有。
关于创新这点，我也想挑战一下。比如我们发布的 Rapid 1 模型、这个表格模型。它是全球顶级 AI 会议上的 spotlight 论文，价值巨大。有家公司——我想他们叫 Frontier——刚从 stealth mode 走出来，做表格 AI 模型，估值超过 10 亿美元。而我们基本有同样的东西，老实说我觉得甚至更好。
所以我认为，不能说大公司没有创新。但我们的重点更多是把东西做成企业可用、产品化。并且我们策略的一大部分是非常广泛地与公司合作。我们与 OpenAI 有合作，我们宣布过。比如我们在德国的主权云上托管 OpenAI 模型。我们是 Anthropic 的投资者，我们是早期投资者，我们也参加了最近一轮融资。所以我们会和他们保持很近，让他们去实验、失败、在某些领域成功。当他们在某些领域成功时，我们就在那里合作。
Unknown Analyst
在一个 ERP 转型可能从“短期几个月”而不是“几年”的世界里——按你说的，AI 甚至可以完全管理——那你对系统集成商（systems integrator）的前景怎么看？
Sean Kask
是的。我一直听到一个说法：SAP 每卖出 1 美元软件，会在生态里产生 6 到 10 美元的迁移、维护等收入。
不过老实说，值得肯定的是，他们也在积极颠覆自己。他们拥抱 Joule for Consultants，所有大型系统集成商都在用。客户也会要求。他们的视角是：他们可以在更短时间做更多项目。迁移项目并不缺，客户也很多。他们也缺人才。所以他们很快在调整商业模式。说实话，他们确实也在积极拥抱并自我颠覆，因此我认为他们会看到很多增长和成功。