For those who don't know me, Fred Boulan, I lead software research here at Bank of America. Thank you all very much for coming. We're delighted to be hosting SAP. We have Philipp Herzig, CTO, who's probably one of the leading AI experts and architects in SAP, so it's extremely topical. Before we go into the Q&A side of things, I've got a quick disclaimer to read. We'll first start with the conversation on some of the key topics, and then we'll open up for Q&A. All the mics are open, so just during the session, just bear that in mind. Want to make sure you keep that in mind. Quickly on safe harbor. During this fireside chat, SAP will make forward-looking statements, which are predictions, projections, and other statements about future events. These statements are based on current expectations and assumptions that are subject to risks and uncertainties that could cause actual results and outcomes to differ materially. Additional information regarding the risks and uncertainties may be found in SAP's filing with the SEC, including but not limited to, the Risk Factors section of SAP annual report for 20-F for 2025. With that, thank you very much, Philipp. Thank you, Alexander, as well. Maybe starting high level, would be great to hear from you key points around SAP's AI roadmap. You introduced the kind of autonomous enterprise, I think vision at SAP Sapphire. What does it bring to your current capabilities? Yeah. First of all, thanks a lot for taking the time here in this big round. I really appreciate that. Look, the vision in my mind has just now emerged right to the overall company strategy, right? The AI strategy so far was, of course, it was very consistent, but I think now we have really taken it to the next level. If you look at this overall AI strategy from SAP, what we are bringing to the customer is that we really strive with the whole strategy to directly bring business outcome to the end customers. That we do on four levels. With Joule Work, that's the kind of new 2.0 version we have, and we can talk more about that in detail. That's our new version that also both from a technology perspective, but also from a user experience perspective, is our next version of how users in the business will interact with SAP software and also with non-SAP software if they choose to. Underneath, we have all the Joule assistants and Joule agents. We announced that we will bring 50. So there's this taxonomy that we are using. First, we start with the autonomous domains. We have the autonomous domains for finance and for HR, and for spend, and for customer experience, and supply chain. Underneath each of these autonomous domains in the suite, we have assistants, and assistants are representative of today's personas in the enterprise. Think of a treasurer, for example, in finance, or an HR Manager, or an HR Business Partner in the HR organization, or just a demand planner, for example, in the supply chain, in the COO area, for example. We aiming to release by Q3 50 of such assistants across these autonomous domains, where then underneath each of such assistants, these assistants are kind of orchestrators of a bunch of agents that are necessary in order to fulfill the assistants' capabilities, in order to make that persona more efficient, or to help them to achieve more, for example, on the sales side, with less resources. We have, underneath these 50 assistants, 200 agents that we are delivering all coming out of the box with the underlying SaaS applications that we are shipping because, what we are striving for is a fully SAP-managed software-as-a-service offering where such agents don't need to be built, right? You can basically right away start consuming them out of the applications and the landscape that you have today. All of that is where then the third element is coming in is, of course, doesn't work without a comprehensive platform. You see this everywhere, right? That the big problem is, people spend a lot of tokens building agents, don't even know what to build for, what's the return on investment, what's the outcome that they are building for. Of course, also, how do you then, once you figured out a few agents that you maybe ship to production, how do you then also consistently govern them, improve them, and also manage that across agents from SAP, but also non-SAP agents? This is where we announced the SAP Business AI Platform, which brings together, of course, our existing SAP Business Technology Platform, as well as the SAP Business Data Cloud as kind of the foundational element. We put on top a new version of Joule Studio as well that will, together also with SAP Signavio, allow customers to, first of all, study as part of their existing business processes, where is there an opportunity to become better with AI. Directly from this analysis from SAP Signavio, finding maybe inefficiencies in the process or finding opportunities in the business to, for example, sell more with some improving their existing products. They can take this over directly as a product requirements definition into Joule Studio to build the right agents with the right context with much less tokens, compared to what they can maybe achieve with other platforms. Once they are ready with these agents, they can bring this into our SAP AI Agent Hub, and from there, observe and continuously improve the agents in that platform. I think with all of these three main elements, I think we have a very not only compelling vision but also very differentiated offer where you get the best of both worlds, out-of-the-box agents that directly make your business better, while simultaneously building custom and bespoke solutions that are deeply grounded in the business process and the business data that many of our customers obviously have already. Which they can use to not only build better AI experiences, but also far more efficient AI experiences in the next few years. Great. Before we move into the whole kind of monetization and pricing side of things, I think on Joule, you were actually, you SAP, fairly self-critical at Sapphire about some of the limitations of the initial products you ship. Would be good to understand a little bit with the kind of new version that's coming up soon, what that can unlock for your customers. Sure. First of all, what were the limitations? In that sense, look left or right, everybody is using more or less the same technologies. Of course, Joule suffered from the same limitations any other chatbot in the enterprise space presented, right, in terms of limitations. Too few integrations, right? Sometimes it was not getting then sometimes the right information, or maybe the coverage was not broad enough, right? Depending on if you're looking specifically in the ERP space, right, where there's a lot of scope, right, that needs to be covered, where simply, more often than not, Joule came back and said, "Oh, I cannot provide the answer because maybe the integration is still missing," and so on and so forth. Of course, specifically in half year two last year, and also beginning of this year, there was a tremendous progress on the technology side of the house. You have studied that all intensively. The models got better, right? Starting with the Claude models 4.6, right? Tremendous progress on that side. Obviously there was a lot happening on the harness side with most prominently, obviously, OpenAI, right? Forget about the enterprise problems, right, with security and integration and so on, but it showed us how a better orchestrator looks like beyond the pure RAG-based system. For example, skills, like there are many puzzle pieces on the technology side that came together that allows us to build just simply a better orchestrator and build better integration, right, with the SAP system. At the same time, what we also clearly did is, and we invested in that for quite a while now, is of course also the thing that you don't get just by off-the-shelf technology components out there, such as, for example, with our Knowledge Graph. The Knowledge Graph is very key to provide actually the right metadata, right, the right structures to the AI model, so they need to guess less. They don't need to guess through MCP, for example, all the various APIs all the time, but they directly get at the first pass already the right API, just call it, right? Which saves you tokens and gives you a far more accurate answer. That combined with the latest harness methodologies, with the latest models, that gives us the big boost from an accuracy and a performance perspective. While simultaneously, we also have realized some of our research work from last year, like our generative UI, where we are now able to actually, it's not just a conversational experience, but also things that, for example, also OpenAI did recently with Sites and so on, that we can generate just the applications basically on the fly. If you have an analytical question, you don't need to model anymore the chart or the KPI, right? You just get a visual representation that gets generated on the fly. We call this concept now Spaces in Joule, but that's basically our generative UI approach to move slowly but steadily away from classical UIs that were designed for humans, to an AI-led approach to generate UIs, for example, on the fly. We are also now shipping as part of that, by the way, that has been generated, 95% of that code has been generated with AI, is we are also not just delivering it for the web and mobile, we're also going to release a new version for the desktop as well, so it runs on Windows, as well as also on Mac. You can even contextualize further with what people have on the computer, invoices, other business documents that need to be processed in context with the rest of the business. These are some of the innovations that we're bringing for you. Great. Can you talk about, in order to address the kind of agentic orchestration there, we had OpenAI yesterday. That's one of their play. Microsoft has a play around that, with their Frontier AI platform solution. To what degree is there an incentive for enterprises to deploy agents that can then manage multiple applications? To what degree you think you can play in that orchestration layer and directly help your customers? Look, I think there are two dimensions here, right? One is the, what's the UI that is being used, right? Also, of course, what is the underlying orchestrator, so to speak. Yeah. I don't believe in a world where there's just essentially just one UI and one orchestrator, right? Of course, depending on where a user types its prompt, right, or where maybe an email gets sent to, if it's a system triggered agent, asynchronously. Of course, it's then the orchestrator, first of all, that's being addressed right by that event. Yeah. That orchestrator needs to be able to talk to other orchestrators, because there will be not this single. I think this is a very naive idea, that there will be this one uber orchestrator that just orchestrates everything on top. There is opportunity, or there are other orchestrators that are required to do the heavy lifting, because all these orchestrators, to me, they form like a hierarchy, right? You go from the highest level orchestrator and branch out to bunch of other ones, which then again, delegate to other orchestrators and so on. I show this all the time in my keynotes. There's kind of a hierarchy of nested loops of orchestrators, right? Because the problem is still with AI, you want to keep on each level the things as narrow as possible for better accuracy and performance essentially. That is why we are saying, look, you can consume also the Joule orchestrator, which does the heavy lifting, let's say, for the SAP part. It also is possible to branch out if customers choose, as we believe in choice. If customers choose to also use that orchestrator to orchestrate non-SAP agents, they can do this as well. You can consume Joule orchestration itself through A2A, so through the A2A protocol, and tap into any of the SAP provided agents. That's, of course, associated, we can talk about commercials, I think in a second, of course, then the meter spins in terms of our consumptive model, in such a headless experience basically of Joule, which then gets also orchestrated into another orchestrator. We heavily did this already. If I talk to customers, what most customers demand is that at least SAP Microsoft Teams/Copilot and/or Gemini do work. This is what we are seeing, and of course, we built these integrations already out. From an SAP perspective, the more casual users probably would rather go through Gemini or would go through Copilot/Microsoft Teams. The more power users, they usually start in Joule, and the SAP screens. Of course, they want to complement that also with non-SAP data from any of these other orchestrators, so to speak. This is what we are predominantly seeing. Again, there will be customers that consume other experiences also from OpenAI, from Claude, and so on, and we are open in this regard. Great. Let's move to your monetization strategy. If you can share a little bit your approach, your philosophy, what's the kind of pricing model, how has it changed? How do you see it evolving? Yeah. Let me start from the basics. I felt, and also in the previous conversations, there are some misconceptions overall as it relates to our overall commercial approach with AI. The way how we commercialize, and first of all, we divide between base and premium AI. That's probably known. Base AI comes just like, for example, expense it with Concur. When you have the Concur app, and you upload a receipt or your taxi receipt or whatsoever, that's part of the base subscription, basically at no extra charge. There are a bunch of these capabilities that are just table stakes from our perspective, that customers come to expect as part of the product. Of course, there are premium capabilities where there's a willingness to pay by customers because there is great value that this provides to the customer in addition to what the underlying base software, SaaS software brings to them. All these premium capabilities that we are shipping, roughly 200 as of today, that are there. You find 400 roughly, it's roughly 50/50, I would say, maybe 60%- 40%. I need to do the accounting on that. That you find also on this AI discovery. If you go to Google and say SAP AI features, you'll probably land on this catalog. You You see roughly 400 AI capabilities, and then you see there what is premium, what is base. If you want to get entitled to use any of these premium AI capabilities, you have to purchase this construct, this SKU called AI Units, that you probably heard of. With that AI Unit, you basically get entitled for all premium capabilities across the entire portfolio of SAP. No matter whether it's a capability in supply chain and finance and for the IT function, that's true for consultants, true for developers, all of them roll up into this AI Unit concept. The AI Unit concept, by nature, is a consumptive model with consumptive revenue recognition. To make that clear, it's by nature, it has been from the get-go designed as a consumptive model, because it was very clear already when we released this in 2023. It was very clear to me, there will be some headwinds because customers don't like consumptive model, but the AI value will be consumed in a consumptive way. I think we were fairly early in that assumption. What we do underneath, how do we price? What we don't do is we don't directly just consumptive, but we are not just passing on tokens. Our customers really don't like tokens. They like business outcomes. This is what SAP stands for. What we basically do is when we commercialize something like Document AI or let's take Joule for Consultants, which by the way, is still per user per month, seat based today, but under AI Units. It's seat based, charged consumptively under AI Units, if you understand what I mean. What we are doing when you talk about value, first of all, you need to have a hypothesis, what is the value? Just let me make the example of Joule for Consultants. It has tremendous value because it directly translates into reduced billable hours that customers can spend with their SIs on an SAP implementation. They can say, okay, if I use Joule for Consultants, I pay SAP so much money for my IT staff, so many 100, 200,000 users, and that translates directly into 20%-30% reduced cost in terms of billable as measured by billable hours towards the SI. Very simple deal, win-win situation, so to speak, from a business model perspective. Whatever the price now is, or whatever the value is, could be EUR 1, could be EUR 1 million, could be EUR 10 million. We say 100% of that value, 70%-80% is for the customer. We apply a take rate of 20%-30% that gets charged with the customer. Value based. That's, again, numbers of day sales outstanding reduced, numbers of days in consulting, and billable hours reduced. And so on. Something the business can measure, where you can go to a CIO, to a CFO, to a CHRO, and say, "Hey, we're going to deliver that value against you." What we need to make sure, that's exactly the beauty of this commercial model. In this take rate of 20%-30%, we need to charge, of course, make sure that the tokens. The cost of goods sold structure that's required to produce it, of course, the costs need to be in the margin profile structure that we need. That within the price boundaries of this 20%-30% take rate, we can of course produce the outcome with the respective margin profile, with, of course, the respective cost of goods sold profile. That's kind of the overall principle on how we approach commercialization for SAP, value-based and then working backwards. The question comes, I get this a few times earlier today, what does this mean now for margin? What does this mean? Can you actually uphold an 80% cloud gross margin, for example. That's very usual. In software development throughout the years is, of course, in an early product, that is a different statement than in a very mature product. Take again Joule for Consultants, very mature product with meanwhile more than 1,000 or a couple of thousand customers on that product, with customers who are using it every day. I'm not sure if I'm allowed to say this, just anecdotally, take it as an anecdotal, that is a very mature product. We have optimized the hell for the token optimization, we are running with margins beyond 95%. 95% on a very differentiated product because we sell on value, we optimize the tokens that are required to produce that value. If you turn towards Joule Studio and any of the new releases that we are doing, of course, we communicated at SAP Sapphire that this will be free until the end of the year. I can tell you what the margin is. Will it always stay this way? Absolutely not. Right? Of course, we favor adoption in the first place because only an adopted product will then lead, of course, once it paid to the realization, "Oh, it actually provides value," then people are willing to pay money for that, so we can recognize revenue. In the next step, I can optimize the margin because the beauty is once adoption sets in, we can collect data, much data about how the users are using it, which scenarios are being used. We get data that we can use to fine-tune post-train models and so on. We can then get actually the same experience that maybe requires to start with an Opus 4.8 model that burns through a hell of tokens at a very high price. We can actually start to reduce and optimize because under the covers, we are switching that. Right? To give you just again, the Joule for Consultant s example. Of course, we started two years ago on the latest Opus model, right? The margin profile wasn't there. Today, Joule for Consultants runs on five different models, maybe tomorrow on seven different models. They're all very small, and they're all doing different tasks in order to do that. With that, you can start optimizing the overall system, that becomes an architectural problem. It's not an AI model problem, it becomes an architectural problem. This is how we approach this in general, also in order to make sure that from a cost perspective over time for mature products, we are then also converging towards the margin profile that is our ambition. Great. One question that I think we get a lot on SAP is, what is the kind of killer app on the AI side? I think it would be interesting to understand what you see your most advanced users doing, people that really embrace that at scale. Probably some of your most advanced cloud users, in what area do you see the fastest deployment of AI at scale? Yeah. Look, I talked already. Coding obviously. Yeah that's also true for us, also with Joule for Developers because, there are a bunch of reasons why development is kind of natural good candidate as an AI killer use case in that sense. The same, of course, for SAP Joule for Consultants, lots of unstructured data. Usually, I would say the killer cases are in the world of unstructured data. SAP Document AI, we have huge. It's fairly simply explained, right? It's a service that basically instead of people keying in information into an SAP system, right, coming from an invoice, coming from a purchase order, coming from a bill of lading, a delivery note, right? If a truck comes with all the goods into a plant in an automotive company, right? Still, people need to enter stuff manually into the system. Unbelievable, right? That actually was even mind-boggling for me why that is, it has a very simple reason. Now we are basically processing this all with SAP Document AI. We have processed alone in 2025, 750 million documents. I think the run rate is roughly 70 million-80 million now on a month that we are processing it. If you would just stack this paper all up, you have the height of the Mount Everest. By just processing through SAP Document AI every single month, in an automatic fashion, with AI. Again, unstructured, right? Of course, high value with respect to the amount and time that you save, right, by just entering stuff into the system or reconciling business processes that are disconnected from a variety of sources. Clearly HR, customer experience, SAP Sales Cloud, SAP Service Cloud, SAP Enterprise Service Management. This is of course where we see the biggest adoption. It's a bit harder still. We're getting there, still a bit harder on the, let's say, more structural things like think finance, for example, or think supply chain where there's a lot of optimization also involved, where there's a lot of number crunching involved, and so on and so forth. This is exactly where our investments also with our own tabular foundation models, also the recent acquisition that we announced with Prior Labs are coming in to also solve that at a more systematic fashion. Great. One topic in the AI debate is all the kind of token maxing and cost of really AI being a problem now. How do you help enterprises frame their return on investment on the AI products that you deploy? How do you give them visibility on those kind of SAP AI Units and avoid them kind of fearing a bit consumption side? Well, first of all, the problem is with tokens themselves, tokens is not yet the outcome. Right? You want to, that's exactly, again, I talked already as part of the commercial model about this. That's the beauty, in my mind, of our commercial model. I always say, "Hey, look, if you have runaway costs, and if you have runaway tokens, you never know really." Token is like measuring the performance of the company based on how much electricity they are consuming, right? That's not the performance indicator. You can consume a lot of electricity and still, maybe just because you keep the lights on the entire night, nobody's been here, right? That's not a good measurement, right? It maybe serves as a proxy variable, but it's not a good measurement. In our commercial model, it's beautiful because you see now, aha, you have saved so many hours. Yeah. You got your days outstanding down by one, two days, right? You can directly translate that into your business metric, what that means. If you have runaway costs, it's almost certain that you also have runaway value, right? That's the first thing. Of course, still customers, specifically at the beginning of the journey, when they don't trust yet that return on investment, of course, they need visibility, they need the experimentation. That is exactly why we're saying with a new product where customers still first need to gather trust, we give it away for free. Yeah. They get used to it. They see how much cost it is in terms of AI units. They see this, we have this thing called SAP for Me. Not sure if you're aware of this, like every customer can log in and sees across the entire portfolio what they spend on AI and see their finances, their T&Cs, and see which agreements they have with us, like all the contractual and financial things that customers have with us. There they of course see their unit consumption. They can also budget. We don't have this yet, they will also be able to budget end of this year, then the consumption in the various buckets as well. Of course then if they see, aha, the consumption is going up, obviously people are using it. They also see the value that is associated with it. Yeah. Right? That, of course, is the trust-building exercise you need, so that then also basically the upsell and the renewal becomes a no event, right? Because they see the value, and of course then they purchase more and expand more as a result of that motion. Great. Anything you can share around the kind of upsell or spend increment you've seen with some of those kind of early users? To give us a bit of an order of magnitude of what that can represent. I think as a firm you shared some ambition in terms of AI revenue, but it would be good to understand a little bit how meaningful that is for some of your customers. I'm not sure if I fully understand the question. Well, how much in terms of people that are actually paying and using- Yeah AI credits. To what degree that's a meaningful change in terms of their overall spend with SAP. It's hard to say. I think this is difficult to overall put at this point in time into context, right? Yeah. There are so many other factors, right? That are also playing into that. We are overall very happy with general uptake, right? Yeah. In terms of our customers are not only purchasing these AI units, of course also the uptake, right? We measure very consistently also the consumed ACV, so what is actually. Yeah Then consumed by the customers, that's a very clear hockey stick that we are seeing, without disclosing our specific numbers, I think it will only grow from there. Anything you can say around your industry AI roadmap as well? You presented that. Sapphire as well. I think you have a number of industries that you've identified. You were talking about the kind of. Yes 10x growth in that piece of business as well. It would be good to understand a bit differently. Yeah. No, look, in all honesty, I think we neglected industries. Yeah For a bit too long, in that sense, as a company. That was always a big strength also of SAP, to be very present in certain industries. Obviously, in some of the core industries that we are supporting, oil and gas, retail, public sector, right? Professional services and so on. Of course, there's financial services, so with Fioneer, there's a big focus. I think from an AI perspective, we haven't done enough justice to industries. What we do, of course, with industries really is also to go in these high value. Obviously in the industry, when you really go into the core processes and the core value creation of that industry, there usually also is the highest. We see a lot of the high-value scenarios, right? Take, for example, asset management, right? In oil and gas, for example. There are very high-value scenarios there. The challenge on the other side is, with AI, you really, and I don't want to use the forward deployed engineer term because it is so both ill-defined and conflated, but what you really want to do is to sit with the customer, right? Design with AI this value creation together in these industries. This is exactly what we are aiming for there. We have created a dedicated team, that really is, works in this kind of forward deployed engineering fashion closely in those industries with the customers to build high-value scenarios, which then again, once they work for the first five customers, we're bringing them back into the standard, into this commercial framework that I outlined, right? It then from there on scales to more customers via the platform, and in the commercial boundaries, because then we have better proof point about how differentiated it is from a value perspective, and as well as also we already have some optimization applied already, so we can really then scale this more consistently for other customers in such industries as well. Great. Last one from me, and then we'll open up for Q&A. One concern out there Is that some of your customers will try to extract value from your data and develop agents using either internally or using other providers. BDC, for instance, is one tool that you're actually offering to help customers extract data and manage any Databricks environment. To what degree is the kind of market missing some of the issues around that ability for an external provider to help leverage SAP data driving insights? Is this a realistic threat, or you think this is a complete misconception? It works for some use cases, but it certainly doesn't work for all. Unfortunately, almost no topic in IT or in software is a binary zero or one thing, even though we program in zeros and ones. Not anymore. Now we have floating point numbers and GPUs anyways. The problem really is, how do you still connect this with the transactional system? Now I've seen the craziest ideas then all of a sudden that emerge out of this thought that, hey, you put everything into one central data lake and have all the data there. That is great for read, if you can accept that it's maybe not real time. That's great. The question is, people then say, like, "Oh, yeah," I even have the discussions in BDC. I can write back to BDC." The agent, the result that the agent has, can actually write back to the data lake of BDC. No. How should it work? It still needs to go and check all your transactional rules and check the validity and check the referential integrity with the rest of the business if this is actually legit. It needs to go to the other one, like all these things. It needs to run through the transactional system. It cannot just be stored in the lake. You need to close all the time the loop. You need to remodel authorizations. It becomes this very complicated thing that you are creating with a lot of effort. I'm not advocating against doing that. Obviously what we are trying to do is to minimize and make it much, much easier for the customer, like for example, with these SAP data products. Yeah. That you don't have to build your ETL, your extract, transform, and load pipeline, and remodel all the authorizations on top, but you basically connect BDC to S/4, SuccessFactors or Ariba, Concur, and boom, you directly have access in the lake with full referential integrity and real-time updates as well. That's the first angle to really make it simple for the customer from a manageability perspective, and I think this is why BDC works pretty well. On the other side, that's exactly where, again, the tabular foundation models are coming in. I think we have an amazing opportunity here to disrupt also in that space in general. If you think about Forget LLMs for a second. Gen AI, agentic stuff based on Claude and OpenAI, forget it for a second. Nobody really has cracked the nut on structured data yet, i.e., on tables, on all these 100,000 tables that are on SAP systems and on Oracle systems, and S/4 systems, and in your dusty old SQL Server that is standing somewhere in the corner and use that. There's a lot of business data and a lot of data that's required for decision intelligence in the enterprise. What happens today, you still need to resort for such things to classical machine learning. Classic LLMs will not help you in this if you want to do a good demand forecast, for example, or a good cash flow forecast, or predictive maintenance and asset management. What we have built, and also we are doubling down now on this with the acquisition of Prior Labs, is I think we can do the same for predictive and structured data, what large language models did for the unstructured world. Because if you look at the results, they're actually pretty phenomenal. In classical machine learning, the predominant algorithms are XGBoost, Random Forest, if you're a little bit into that, and it's AutoGluon. The reason models with our own RPT 1.5 as well as Prior Labs, we beat XGBoost with a small amount of data already in 100% of the cases, and AutoGluon that runs for five hours in 80% of the cases. I believe by end of this year, we will beat them in 100% of the cases as well. While simultaneously, this tabular foundation model, actually, you don't need to be a machine learning expert at all anymore. You just provide your table into then boom, you can start making predictions, asking questions on top of your table and reason over the structured data. Because what happens today still is, and that's why we are doing this, is if you have such a question, a CFO asks for a cash flow forecast or whatever, or the CEO asks for a demand forecast in your stores, then of course, you go to the data science or the machine learning COE, and they build their stuff in a Jupyter Notebook or whatsoever, because this is where they live and breathe. Of course, as a result of that is why the gravity is like in order to train such models, you need to get the data. Some of SAP data, some of non-SAP data, and so on. Otherwise, you cannot train these machine learning models. Now, with the tabular foundation models, the plan is to flip this around because with tabular foundation models, everybody can do this now. You don't need to be a machine learning guy anymore. You put this on top of BDC, where you can call out into any data lake that is out there, is exactly what I said at Sapphire. You get tables on the fly for BDC and then predictions on the fly, and I think this will be pretty powerful technology going forward to build something that is technologically very differentiated and provides a lot of value to businesses. That is today, for me, the other big missing part of the coin that nobody's really talking about yet. Great. Thank you. Do we have any questions? I have a lot of questions, there we go. I understand, and please correct me if I'm wrong, that one of the customer frustrations with Joule has been that it's not been possible to access the data that sits in SAP on-premise systems until recently. Is that correct? Well, look. Part of the value, I guess, is for customers over the years in terms of the data. Yes and no. What we always said is, first of all, the frustration more was coming from that we haven't yet been able, specifically in S/4, to cover the broad range of cases that customers would come to expect. It worked quite well, for example, in sales and distribution. For example, we had flaws in classic, good old direct procurement, material management, and so on and so forth. Right. This is where. Then back to what I described earlier with the advances in SAP Knowledge Graph and with the new harness and skills and so on and so forth, we see a lot of improvements that are coming there. The on-premise frustration, well, first of all, we always said, and we are staying true to this, the out-of-the-box capabilities only come with the cloud, right? It's not a technical argument, it's a lifecycle management and speed of innovation argument. Only in the cloud we can ensure that the customers are getting the latest and greatest, basically overnight. Right. Case in point, I tell this to every customer, who doesn't believe that, I have a good friend, the CIO of a small, medium-sized company. He is always on the latest and greatest of SAP, and when we showed Joule Work, the mobile app, he has everything on mobile. He doesn't even have Joule and S/4 and so on, and then SuccessFactors. Everything just in the central mobile app with, so far it was Mobile Start, and then you had this little Joule icon in SAP Mobile Start, where you could open Joule and then talk to your SuccessFactors, Concur, ERP behind that, right. He did that work very well. He's a big fan. He's on the latest and greatest. He just pulled out his phone at Sapphire, clicked on Mobile Start, it opened, it said, "Hey, Mobile Start is now Joule Work. Here's a new icon. You want to have the new experience?" Click, boom, you got the new experience. That is not usually the experience customers have with SAP, specifically if they have this good old on-prem ECC or even S/4 estate. That's, of course, where we want the customers to get into, right, in order to participate with the speed. This is where it's still solvable because this is why we also said value while modernizing. We are just now messaging this a bit maybe clearer. It was always there because obviously you can use the platform and our extensibility mechanisms to always connect and build custom things against your ECC because it's a platform, because there is no technical boundary condition. Of course, that's then work the customer needs to do. We have many customers who have used the former Joule Studio, for example, or the Joule command line interface to build custom skills to do whatever, to integrate an ECC system, to integrate with ServiceNow, to get a bunch of stuff out of Salesforce and integrate that into Joule. Technically, that's all possible, right. Of course, it requires work by the customer, and it's not this out-of-the-box capability that we are shipping, what we are calling SAP managed as opposed to customer managed. The customer has to do the work. Hope that makes sense. Thank you. We're going to leave it there. We're on time. Thank you very much, Philipp. Thank you, Alexander, for coming, and that's everyone for Enjoy.