Muhammad Alam（产品与工程）
Adam Wood（摩根士丹利）
好的。各位早上好。我将开始我们在旧金山举行的会议的第二天。非常感谢大家的参与。我叫Adam Wood。我在摩根士丹利负责欧洲软件和支付研究。
非常荣幸能邀请到Muhammad Alam。Muhammad，非常感谢您的参与。Muhammad是SAP执行董事会成员，负责产品和工程。谢谢您。
感谢邀请我。
Alam，我想尽快把这些说明讲完，有一些免责声明。关于重要披露，请访问摩根士丹利研究披露网站：www.morganstanley.com/researchdisclosures。如果您有任何问题，请联系您的摩根士丹利代表。
在SAP方面，在本次炉边谈话中，SAP将发表前瞻性陈述，这些陈述是关于未来事件的预测、展望或其他陈述。这些陈述基于当前的预期、预测和假设，存在可能导致实际结果和成果发生重大差异的风险和不确定性。
有关这些风险和不确定性的更多信息，请参见SAP向美国证券交易委员会提交的文件，包括但不限于SAP 2025年Form 20-F年度报告中的风险因素。好了，说完这些，希望我们可以进入更有趣的话题。
那么，或许我们可以从最近的一些消息开始，有消息称您明年合同到期后不会与SAP续约。我想知道您能否稍微详细说明一下背后的原因。
是的。我的意思是，我不想过多地深入细节，但就我个人而言，有一些事情让我现在很难承诺续约。而且德国的治理要求，一旦合同即将到期，需要提前一年进行讨论。
所以我个人目前无法做出承诺。我们认为，从透明度的角度出发，向我们的同事以及外部人士传达这一点仍然是正确的做法。但是，我的意思是，听着，我是这样看待这件事的，我们的合同还有一年多的时间。正如大家现在所知，在当今环境下，一年的时间足以产生一些相当显著的影响。所以这就是我们的重点，无论是在SAP内部还是为我们的客户。
好吧，祝您未来12个月一切顺利，是的，期待看到所产生的影响。我昨晚参加了一个晚宴，我们都被问到会议的大主题以及我们想从会议中获得什么。我想房间里有一半的人说，我们如何理解现有应用软件供应商的护城河？
所以这就是我想开始的地方，关于如何保护你们已有的东西和你们的护城河这个显而易见的问题。那么，您认为现有软件供应商面临来自生成式AI颠覆的风险有多大？您认为SAP最大的护城河是什么？
是的。我的意思是，我认为，听着，生成式AI确实对现有的软件供应商产生了重大影响——具有重大影响。我认为这是明确的。没有人对此有争议。我觉得在这个讨论中我们忽略的一点是，并非所有SaaS供应商、所有应用程序都是平等的，它们在客户环境中扮演的角色也不尽相同。
因此，虽然确实有一类SaaS应用程序将更容易面临风险、颠覆和转型，但我认为还有一类SaaS应用程序，从SAP的角度来看，我们坚信我们属于这一类，它们对于组织的运营至关重要。当你想到财务管理、总账、资金管理、GL、AP、AR时。然后你进入供应链方面，在那里你真正管理你的车间或物流环境等等，这是另一类应用程序。
至少在我看来，类似的，我的理解是，听着，有一类应用程序——如果你想想甚至Windows，例如，对吧？它归根结底是一个应用程序。但它有点像消费者每天在设备上使用的操作系统。SAP非常像企业的操作系统。
当然，有一组应用程序是建立在它之上的。我们的许多合作伙伴都在这样做，有很多集成，如果你愿意这么说的话。但是很难替换掉这个操作系统，如果你愿意这么说的话。虽然你可以用生成式AI构建一个操作系统，但你现在会开始编写自己的操作系统来运行自己的设备吗？不一定是这样。
但是它上面的应用程序，当然，还有客户应用程序，这些更容易去做。从SAP的角度来看，虽然，听着，即使在我们工作的应用程序类别中，生成式AI也带来了创造增量价值的巨大机会，这在以前是不可能的，这就是我们的重点。我们确实认为颠覆的风险是不同的。
这就是我认为今天外界正在进行的对话，嘿，所有SaaS应用程序都被同等对待，这是最初的反应。但当我们与客户交谈，查看我们的产品组合时，现实情况似乎大不相同。
这很好地引出了我的下一个问题，即存在一组已经存在的应用程序，也就是您所说的操作系统。但然后这种新的能力和技术开辟了令人惊叹的空白领域。也许首先，复制您所说的操作系统有多难？然后，当您考虑进入空白领域并自动化以前无法自动化的事情时，操作系统给您带来了什么优势？
是的。再次，这是一个非常好的问题。那么让我们分解一下这类应用程序以及它们为什么不同。这是问题的关键，对吧？如果你想想使这类应用程序不同的因素，是50年来嵌入的逻辑和业务流程，不仅在我们谈到的横向领域，如财务、人力资源管理、支出、供应链等等。还有石油和天然气、制造业以及媒体等行业的深厚能力，如果你愿意这么说的话。
现在，这些集体知识以及围绕它的数据、对它的语义理解、业务流程定义，再加上——不仅仅是这些，对吧？作为一家企业级厂商，因为我们的历史是我们为各行业一些最重要的、最大的组织提供支持，这种企业级就绪程度、治理、安全性和隐私性，以及我们在世界上许多国家的本地化，形成了这个护城河，这个进入壁垒，也就是说，嘿，我要去构建一些东西并放在它上面。
现在这是其中一个方面，对吧？所以不一定存在直接的威胁，比如说，有人要去构建一个总账系统，在全球进行本地化，并能够遵守所有的法定要求。我的意思是，这甚至存在于我们的部分产品组合中，比如Concur。我知道有一些讨论说，嘿，Concur是否更容易受到颠覆？
但是如果你看看Concur并分解其业务，它是费用管理。对门外汉来说，费用管理可能听起来很简单，但全球范围内有大量的法定要求，我们投入了大量的研发资金，定期更新。当然，你可以创建一个基于数据的表单应用程序，允许你记录费用，但是谁来遵守法定要求呢？谁来长期维护它？谁来确保所有这些都与你的核心操作系统集成以使其工作？
这就是为什么即使你回顾过去1.5十年，从费用管理的角度来看，你认为如果它那么容易，这个领域会非常繁荣。但事实并非如此。因为即使在那里，从企业角度、本地化角度来看，也有一个护城河。话虽如此，这更多的是一个进入壁垒的护城河。问题是现在有机会在它之上创造巨大的价值。这是我们非常、非常关注的。
老实说，对于你问我的第一个问题，让我感到遗憾的是，在我看来，这是科技领域、业务应用领域一生只有一次的机会，可以为客户创造一些非凡的影响和价值，从而为SAP和我们的股东带来价值。我们正深深地专注于这一点。
但是如果你想想它之上存在的机会，自动化肯定是一个重要方面。有一种智能需要数据上下文、流程上下文、上下文图谱来实现自动化，从而创造自主体验。
正如你所期望的，我们正在开发的Sapphire即将推出，对吧？我相信每个人都会期待，我们即将推出的是我们最雄心勃勃的发布之一，现在利用生成式AI和一般AI的可能性，将其放在核心应用程序的操作系统之上，这些应用程序凭借其企业就绪性、本地化广度、行业深度而与众不同，并创造客户所期望的价值。
再次，我有点喜欢类比，所以我再举一个类比，如果你以某种方式考虑自主应用程序，对吧？自主不仅仅意味着自动化，还意味着内置的智能，以及能够做一些坦率地说人类可能无法做到的事情，因为现在你可以在大量数据上大规模地做到这一点，这对人类来说很难做到。
但是如果你想想这种自主——自主业务应用程序的概念，它与自动驾驶汽车不太相似，对吧？在这类核心关键任务应用程序中，你真的能在非自动驾驶车辆上安装自主软件，并觉得，听着，这很完美，我要让我的车自主驾驶并在镇上行驶。事情不是这样的。应用程序、数据、代理、思考体验之间存在一定程度的无缝性，这创造了难以构建的非凡价值。
你能在某些业务流程中做到吗？是的。但你还必须意识到对客户的总体拥有成本影响。因为客户然后会说，听着，对于这个核心领域，这个——把它看作企业的操作系统，我要选择别的东西，一个平台即服务（PaaS）提供商，如今每个人和他们的兄弟都在构建一个代理PaaS平台，对吧，有人可以将其构建在任何现有平台之下。
但是你承担了理解数据模型的成本，这很难做到，进行集成，弄清楚上下文是否存在，然后承担决策和建议的风险，这些决策和建议会影响你的财务管理、供应链流程、支出，这些都非常——你需要非常确定。
你不能像在一些前台业务流程中那样具有概率性，对吧，在潜在客户机会等方面。在这里你必须非常确定，因为一个简单的错误可能对组织造成相当大的损失。你实际上增加了组织在维护成本、集成等方面的潜在负担，在某些情况下，甚至阻碍了代理层的应用。
但再次总结，对我来说，我认为这种应用程序、数据、代理体验与核心操作系统、关键任务应用程序系统无缝地创造价值，不仅创造了无与伦比的价值，而不仅仅是可以连接到你的环境的PaaS提供商，而且还带来了更确定的结果。
因为我们提供，我想你谈到了护城河，我们可以更深入地探讨，我们拥有的护城河，即深厚的流程理解、我们拥有的数据、数据模型、SAP知识图谱等等，我们将其构建为后训练模型，与你可以现成找到的模型一起工作。这两者共同创造了我们认为无与伦比的价值。
我认为我们的信心，再次，我认为关于这对SaaS应用程序意味着什么的争论正在激烈进行。对我们来说，我们的重点是，正如你期望听到的，Sapphire会有很多东西出来，事实将证明一切。我认为我们从客户那里得到的反馈是，嘿，听着，我想运行一个自主财务组织、自主供应链或自主支出。
为了确保整个“车辆”是自主的，需要一定程度的可信度和连接性。不是你在它上面买一个层，说，嘿，我要把它放在我的1990年宝马车上，用这个新软件，然后我就坐下来让它开车送我回家。你可以这样做，但这样做有很多风险。
这不是一辆你想自己坐进去的车。
是的，是的。
不，这有道理。您已经提到了这一点，但我的意思是，我认为这是一个大的投资者担忧，不是说我们实际上替换了底层的记录系统，而是用户界面可能转向一个基于聊天的LLM界面。那里有更多的互动，也许创造更多的价值。
对于运行多个记录系统的人来说，投资者开始认为，嗯，这可能有意义。您如何看待这种风险？您想与这些公司合作多少以实现数据访问？以及您系统中的智能价值，您如何保护它而不是想要合作？
是的。我的意思是，这是一个复杂的问题，让我想想。如果我忘记了其中一部分，请提醒我。但你问的第一部分是交互层——是的，代理体验交互层。因为我确实——我认为我们也相信的一件事是，在很长一段时间里，堆栈的形状第一次发生了变化，因为现在顶部有一个新的层，即这个代理体验层，位于下面的所有东西之上。
可以说，下面的所有东西变得更平台化、更商品化，价值向上转移，如果你愿意的话，无论是为客户创造的价值还是能够为此收取溢价的组织。这确实是交互层发生的地方。
我想说，我们过去位于应用层的顶部。我的意思是我们仍然在那里。世界还没有完全改变。但我们看到了变化的迹象。所以对我们来说，再次强调，不是像你说的那样，较低的层正在消失，比如应用数据、PaaS和IaaS。从这个角度来看，它们不会消失。
问题是，为了让这个新层工作，如何创造最大的价值？我们再次相信，这个代理层，需要存在的应用程序，因为这是数据创建的地方，是采取行动的地方，是合规发生的地方，是法定要求发生的地方，如果你愿意的话，特别是对于SAP所处的应用程序类别。
如果你拿一个小型的单通道应用程序，可能只做人力资源管理或一些前台应用程序，那是——我认为那是一个根本不同的领域。我的意思是我们站在舞台上——那是去年的Sapphire，我们谈到，听着，我们相信在这个世界上，同类最佳产品将举步维艰。
但SAP的护城河即使在这个新的堆栈层中也存在，如果你愿意这么说的话，应用层再次成为一个平台，如果你考虑到这一点，对吧，因为价值向上转移。从应用平台的角度来看，组织告诉我们，这种甜蜜的信息是说，嘿，在这个平台层，我们需要财务、支出、采购、供应链、人力资源管理、客户体验能够无缝协作。所以SaaS实际上成为了一个新的平台。
我们是极少数的，你可以用几根手指就能数过来的公司之一，能够跨越业务流程的广度，提供SaaS平台，为端到端的顶层体验提供动力。因为如果你在SaaS平台中选择6个不同的提供商，你猜怎么着，你必须构建集成，你必须自己理解数据模型。你必须将数据推到其他地方才能连接。这引起了客户的共鸣，因为这也允许他们融化冰山，对吧，他们维护的复杂性和总体拥有成本。
话虽如此，对我来说，作为SAP的产品负责人，很明显我们也必须在代理层发挥作用。我们希望确保当有人使用Joule时，他们可以在同一个窗格中询问有关财务、供应链和支出的问题，并通过SAP知识图谱、通过我们谈到的微调模型获得正确的答案。然后代理体验再次利用那个护城河，包含在我们的代理层中，创造自主体验。这很难作为一个PaaS故事构建在它之上，对吧？
所以这就是我们真正致力于解锁的，与客户合作并为我们的客户解锁的。这种将核心应用程序重新定义为代理体验的做法，正如你想象的那样，是我们非常积极努力的方向。从产品创新的角度，你也会听到更多关于这一点的信息。
但通过这一点，我们不想成为的是说，听着，我们现在只是想在这个SaaS作为平台层发挥作用。我们确实想在这个代理层发挥作用。但是，当然，我们将遵守A2A，如果您有其他东西，当您了解SAP数据时，您可以通过我们的代理层，如果你愿意的话。然后它通过组织中发生的一切为SAP的代理层创造这种粘性。
因为虽然我们是关键任务，但在100个案例中有99个，我们不是唯一存在的应用程序。有一些深厚的行业内容，如果你拿石油和天然气来说，上游、下游。如果你拿制药来说，也有其他事情发生。有些行业我们实际上相当完整，比如离散制造业，它基本上可以全部在SAP上运行等等。但它允许这种互操作性，如果你愿意的话，在我们拥有的护城河上。
您已经多次提到了数据、业务上下文。这种语义业务上下文，它仍然有多重要？我得到的问题是，这些模型难道不能进入系统并自己推断出那种结构吗？
是的。它们可以。我的意思是，我认为它们可以。但再次，区别在于：针对哪种应用程序，对吧？你甚至可以在我称之为单通道、单域应用程序前面放一个MCP服务器，对于那些熟悉MCP服务器工作原理的人来说。
它实际上会很好地将传入的自然语言查询转换为需要返回的答案。但是一旦MCP服务器下面有超过x数量的工具，准确性就会变得非常糟糕，你不能依赖它。
如果你看SAP的领域，跨财务的SaaS平台——即使在其中一个领域，复杂性也是如此巨大，数据模型、表格、实体、客户构建的扩展是如此庞大，以至于你不能简单地在它上面放一个MCP服务器，然后像你在一些LinkedIn帖子中读到的那样想，嘿，这将是惊人的和改变游戏规则的。
听着，我这么说，但对我来说，这种对上下文的理解是我们最深的护城河之一。即使对于我们作为软件的发布者来说，以某种方式解决它也是非常困难的，SAP知识图谱、SAP流程图谱、通过应用程序的交互和行为的上下文图谱，能够大规模地用于所有代理和所有自然语言交互。我们已经为此工作了1.5年，当时我们最初说，听着，我们实际上已经非常接近我们的SAP知识图谱，这就是我们解决的问题。尽管我们解决它非常困难，但这就是我们的信心所在，即在规模上，解决S4、Ariba、我们的供应链所具有的东西，是一件非常困难的事情。因此，这创造了护城河。
所以你有原始数据，但数据的关系和上面的语义丰富性，以及它在流程中的使用方式，创造了那个护城河。这就是我们正在构建到微调模型中的，当然，代理和Joule在它之上工作，再次解决企业非常广阔的表面区域，否则不容易理解。
你可以做的是获取原始数据，把它放在某个地方。客户今天就是这么做的。但根据定义，A，你承担了很多负担，因为你没有语义上下文。B，你也失去了权限和授权，对吧？
因为一旦你把它放到Databricks、Snowflake、Azure或Google Big Query中，那么它就只是没有权限和授权的扁平数据，这也是非常关键的。突然之间，因为生成式AI，你不会开始与所有员工共享你的工资数据，到处共享你的财务数据，大规模共享你的供应链数据。
所以我们也维护这一点。因此，我们的合作伙伴关系，特别是我们与Databricks所做的，允许我们的客户通过我们去年推出的SAP业务数据云，保持数据引力和语义丰富性，从而能够创建更强大的场景。
所以这一切都是关于点SaaS解决方案与您提供的解决方案的复杂性广度之间的区别，以及围绕它的合规性和治理，这真正使您与同行区分开来。
再次，我们转向数据，这显然是您的一个大护城河。您提到了业务数据云。您能谈谈您如何看待客户负责任地利用数据，以及业务数据云如何运作，您如何管理这些合作伙伴关系吗？
是的。我的意思是，我认为当我们在不到一年前推出业务数据云时，最初是与Databricks合作，然后我们宣布了与Snowflake、Azure和Google的合作。对于第一年的产品来说，它实际上非常成功。希望在座的任何人都不会感到惊讶，因为数据是推动AI价值的燃料。
我们设计架构的方式允许两件事，对吧？显然。第一，我们希望确保为客户带来同类最佳的数据工程工具，在这一点上，我们觉得这不是我们想要赢得的战斗，也不是有机地构建数据工程工具，因为这个市场已经变得相当成熟和商品化。因此，我们将这些工具本地嵌入，在某些情况下OEM，在业务数据云中，保持数据引力、语义丰富性，我们的客户可以使用它来创造价值。
所以我们专注于我们增加价值的事情，即跨应用程序的协调数据模型、连接性、知识图谱、语义丰富性，在数据工程方面与已经成为商品的事情合作，如果你愿意的话，原因有两个，对吧？
第一，如果你想通过别人的AI工具在该数据之上创造价值，BDC仍然是实现这一目标的方式。因此，我们成为客户可能使用的任何人创造的价值流的一部分。
根据定义，这给了我们一定程度的附加和粘性，以及我们在该数据之上提供的价值，正如我们几分钟前讨论的，这与从数据库中取出原始数据到其他地方并试图在其上构建完全不同。所以它上面有价值，现在我们在理论上由别人创造的价值流中。
第二部分是因为我们现在以我们的方式提供了数据，带来我们前面谈到的一些东西，你可以帮助在BDC之上创建代理体验和价值，使用我们的AI平台，再次覆盖大部分，在某些情况下，你的核心业务流程，与我们平台上的正确合作伙伴，然后我们实际上是创建交互层、代理层的主要合作伙伴，因此为客户创造价值，并为我们和我们的利益相关者带来溢价价值。所以在这两种情况下，这使我们能够成为价值链的一部分。在一种情况下，当然，你可以做一些事情，但有BDC和其他东西。在另一些情况下，我们是代理层的核心，如果你愿意的话。
再次，你会发现我们所做的，我们在去年秋天的SAP Connect活动中谈到过，我们有一些很好的客户例子，我们独特能做的，而PaaS代理层不能做的是，我们可以说，我们将提供开箱即用的代理，对吧，在无缝的应用数据代理体验中工作，如果你有其他工具，你可以扩展，你需要添加一些前后逻辑，因为每个客户都是独特的，但你可以以更低的总体拥有成本更快地获得价值，而不是说，嘿，我要买这个PaaS平台，然后去弄清楚所有这些，如果你愿意的话。
因此，除了我们已经谈到的其他护城河之外，这也成为客户的价值主张，即，嘿，领先的业务应用程序提供商最了解我的流程，行业横向和我的扩展，因为我们知道在我们的平台上构建的扩展可以帮助创建这些代理体验，不仅创建，而且使用开箱即用的AR代理、AP代理、支出代理、供应链代理，并扩展它们以满足我的需求，这是非常了不起的。
因为虽然存在压力，我相信你们都知道这一点，对吧，我认为生成式AI仍处于非常早期的阶段，对吧？董事会对CIO、CEO和CXO施加了很大的压力，要求他们展示价值，比如你最近在生成式AI方面做了什么？有很多组织挑选了一堆不同的东西，拼凑在一起说，嘿，听着，这是价值。但它的终身总体拥有成本非常高。我们正在做的是说，嘿，我们将帮助你开箱即用地解锁代理层价值，并进行正确的扩展，这样你就不会最终一直维护那个负担，如果你愿意的话。
所以为了确保我正确理解业务数据云，显然会有一个环境，您谈到离散制造业SAP几乎可以端到端运行。我想在那种情况下，人们对业务数据云的需求会更少。但是当他们使用其他记录系统、其他应用程序时，那是不是您可以带来价值并说，好吧，是的，这是一个更加异构的环境，您可以带来不同的数据集，然后在此基础上构建？这样想对吗？
不，我的意思是，我认为——不。不是的。感谢澄清。业务数据云的价值在于，无论您是以何种形式或方式成为SAP用户。因为它将数据以语义丰富性、完整的授权和权限、SAP知识图谱进行协调，然后您可以构建或使用我们提供的开箱即用的代理层。
现在，不同的是，BDC允许您去做的是，在离散制造业等行业，大多数数据来自SAP，无论如何都可以来自SAP，所以它就在那里。在石油和天然气行业，SAP数据在那里，您可以与非SAP数据以无缝方式零拷贝共享。因此，BDC允许您成为所有客户的数据层和应用数据代理。在某些情况下，当外部数据更多时，您可以通过我们的合作伙伴关系，使用一些现有的数据工程和数据平台工具进行零拷贝共享。
这有道理。
但它在两种流程中都有效，如果你愿意的话。
好的。我们昨天从业务数据云的一个合作伙伴那里听说，他们谈到从分析型、OLAP世界开始，添加OLTP，进入交易，谈论应用层。所以我的问题是，从SAP的角度来看，您如何保持对该环境的控制？因为我想其中一些合作伙伴可能也有雄心开始在其上构建应用程序、代理。那么SAP如何管理这种合作伙伴关系，与这些合作伙伴的潜在竞争？
是的。我认为一个简单的方法，我实际上发现这个人没有穿西装，所以我可能应该效仿他的例子，不在这里穿正装。对我来说，再次，你必须看看合作伙伴的性质，对吧？例如，对于Databricks，我们在BDC中提供Databricks。
这使我们能够在数据引力留在SAP的框架内，利用他们的数据工程工具与我们的数据构建那些代理平台。现在如果你有其他数据，你可以进行零拷贝共享并构建东西。Snowflake也是如此。
因此，我们的合作伙伴关系允许在BDC中利用他们平台的优势来构建价值层。但是如果有大量数据位于外部——或者如果客户已经支持并将大量数据放在那里，那么你可以将SAP数据和BDC零拷贝到那里，但这使我们进入了流程。
然后我想如果你回到几个问题之前，我认为这一点——我知道这不完全是你问的。这一点——我们觉得在客户环境中不一定会成为现实的是，因为数据在那里，有人会开始在我们工作的应用程序类别之上构建应用程序。
他们能在一些数据平台合作伙伴上构建自定义应用程序吗？是的。但我们也谈到了开箱即用的价值，因为有深厚的上下文图谱，有我们正在采用的模型，有我们上周在TechEd上推出的Rapid one，它允许你在交易流程中进行数据科学。
有足够的价值主张说，嘿，你用BDC构建的，用我们的代理平台为我们工作的领域创造最大的价值。但是，当然，那些平台上总有其他东西可以填补空白。
有道理。您实际上已经给出了BDC的总合同价值的一些数字。我感兴趣的一件事是，这些项目的价值实现时间是多久？从签订合同到让人们启动并运行并从中产生收入需要多长时间？
所以我认为——再次，我不——Alexandra可以在离线时提供一些这方面的信息。但我们一半以上的BDC客户现在正在使用。所以BDC的价值实现时间非常快。这不像典型的ERP实施，说嘿，价值需要x个月才能显现。
这主要是因为我们构建产品的方式是，如果你有SAP环境，我们构建的数据产品开始馈送到BDC，然后所有工具都可供你在其上创造价值。我们还可以帮助你进行BW的现代化之旅。因此，有了这两个价值主张，我们实际上看到了BDC的大量使用和使用时间。
这很有帮助。也许只是为了结束。我认为发生的另一件事是，我们有点将软件公司简化为它们如何生成代码。如果你能更便宜、更快地生成代码，价值就消失了。在我看来，软件公司远不止生成代码的能力。
但是您能谈谈您如何看待这种代码生产成本的降低，客户未来愿意为此支付多少？那么行业结构在从席位到消费的货币化方面会如何变化？您如何看待所有这些？
是的。我的意思是，这是我们花了很多时间思考的领域，我们可能需要或可能不需要做出的演变。我的意思是，如果你看看我们今天的模型，我们也有多种模型。我们有很大一部分价值嵌入在基于Joule的应用程序中，也就是说，如果你运行SAP应用程序，你可以进行交互并从中获得价值。
然后有一个更高级的功能，每月每用户，它说，嘿，我们想给你可预测性，说，嘿，我们在这个类别中推出的任何东西，你都可以尝试使用，而不必觉得你需要为这个功能添加费用。消费将是这样的，然后想出一个复杂的计算。
因为现实是，我认为一般来说，其中一些东西的投资回报率在规模上仍有待真正证明。所以我们不想陷入这样的争论，即解锁这个功能需要这么多消费，所以你需要展示这个。这是关于，嘿，这里有一组不断改进的功能，你可以根据自己的喜好使用和消费。然后我们也有消费性措施，用于那些非常、非常消耗的场景。
我认为我们正在研究一些基于结果的措施。我们今天甚至有基于使用的指标，不是所有的。甚至我们的每月每用户也是基于使用的，即使在我们的核心应用程序中，当你想到Ariba时，我们谈论的是通过的支出，而不是实际使用应用程序的用户数量。所以我认为，正如你想象的那样，随着行业的发展，我们将继续观察发展方向，然后根据客户反馈来发展我们需要做的事情。
但目标是先展示价值。
显然。我的意思是，在AI方面，我认为我们至少在SAP相信，我们既有责任运行这些关键任务应用程序来证明和展示价值。但我们有能力展示价值，然后根据反馈和讨论，在适当的时候找出正确的商业模式。
完美。好吧，我们还有很多可以讨论的。我们时间快到了。非常感谢您再次加入我们。
感谢邀请我。
谢谢。
谢谢。