Okay. Good morning, everybody. I'll start off day two of our conference here in San Francisco. Thank you very much for joining us. My name is Adam Wood. I look after European software and payments research here at Morgan Stanley. It's a great pleasure to have Muhammad Alam with us. Muhammad, thank you very much for joining us. Muhammad is executive board member at SAP, responsible for product and engineering. Thank you.
Thank you for having me.
I'll try and get these out of the way as quickly as possible. A few disclaimers. For important disclosures, please see the Morgan Stanley Research Disclosure website at www.morganstanley.com/researchdisclosures. If you have any questions, please reach out to your Morgan Stanley representative. On the SAP side, during this fireside chat, SAP will make forward-looking statements, which are predictions, projections, or other statements about future events. These statements are based on current expectations, forecasts, and assumptions that are subjects to risks and uncertainties that could cause actual results and outcomes to materially differ. Additional information regarding these risks and uncertainties may be found in SAP's filings with the Securities and Exchange Commission, including but not limited to the risk factors of SAP's 2025 annual report on Form 20-F. With those out of the way, we can get on to more interesting things, hopefully.
Maybe just to start off with, there's been some recent news on your side that you're not gonna be renewing your contract at SAP next year when it expires. I wonder if you'd be able to elaborate just a little bit on what the reasoning was behind that.
Yeah, I mean, I think not to go into too much detail, but there's a few things going on on the personal side.
Right
For me, which made it a little bit hard for me to commit today, a contract extension. German governance requires, once the contract's coming up for renewal that one year in advance you have those discussions. I just wasn't at a place personally to be able to commit to that, and we thought it was still, from a transparency perspective, the right thing to communicate both to our colleagues as well as externally, too. I mean, listen, the way I look at this, we still have more than one year left in the contract. One year, as you all know now in today's environment, is a lot of time to make some pretty amazing impact. That's what we're focused on both at SAP internally as well as for our customers.
Well, best of luck for the next 12 months. Yeah, looking forward to seeing the impact that comes through. I was at a dinner last night, I think we were all asked, you know, the big theme and thing we wanted to get out of the conference. I think half the room said, "How do we understand the moats for incumbent application software vendors?" That was where I wanted to start off, was the kind of elephant in the room.
Mm-hmm
you know, how you protect what you have already in your moat. How at risk do you think incumbent software vendors are from GenAI disruption, and what do you think SAP's biggest moats are?
I mean, I think, listen. I mean, let's start with GenAI does pose significant has significant impact on existing software vendors. I think that's clear. Nobody's debating that. I think the thing that I feel like we lose in that discussion is not all SaaS vendors, not all applications are created equal.
Right.
Nor do they play the same role within a customer's environment. While it is true that a certain class of SaaS applications are going to be a lot more prone to risk, disruption, transformation, I think there is a class of SaaS applications, and from an SAP perspective, we deeply believe we play in that class that are extremely mission-critical for an organization to operate. When you think about financial management, when you talk about General Ledger, you talk about treasury, you talk about GL, AP, AR, and then you get into the supply chain side, where you really run your shop floor, your logistics environments and things like that. That's a different class of applications. At least in my mind, sort of the moral equivalent, the way I think about it is, listen, there's a class of apps.
If you think about, you know, maybe even Windows, for example, right? It's an application at the end of the day, but it's sort of the OS of what consumers use every day on a device.
Mm-hmm.
SAP is very much like the operating system of a business. There's certainly a set of apps that are built on top of it. A lot of our partners do that. A lot of integrations exist, if you will. But it's hard to sort of go take out the OS, if you will. While you could go build an OS with GenAI, are you gonna go now start writing your own OS, to be able to run your own devices? That's not necessarily true. But apps on top of it, sure, and custom applications, those lend themselves a little bit better to be able to go do. From an SAP perspective, while, listen, even in the class of applications we work in, there's phenomenal opportunity to create incremental value that now is possible with GenAI that wasn't possible before, and that's what we're focused on.
We do believe that the risk of disruption is different. This is where I think the conversation that's happening today out there is, hey, all SaaS apps are treated similarly. That's sort of the initial reaction. We fundamentally, when we speak with customers, when we look at our portfolio, the reality seems very different.
That brings me very nicely into the next question, which is, you know, this idea of there's a set of applications that already exist, the operating system that you talked about, but then there's this amazing white space that this new capability and technology opens up. You know, maybe first of all, you know, how difficult would it be to replicate that operating system that you talked about? Then what advantage does the operating system give you as you think about moving into the white space and automating things that couldn't be automated previously?
Again, a very good question. Let's decompose sort of this class of applications and why they're different. That's sort of the crux of the question, right? If you think about the things that makes this class of applications different is, sort of 50 years of logic, and business processes that are embedded not just in the horizontal domains that we talked about, which is finance, SCM, spend, supply chain and so forth, but it's the deep industry capabilities in oil and gas and what we've done in manufacturing and what we do in media and others, if you will. That collective knowledge, as well as the data that's around it, the semantic understanding of it, the business process definition of it, sort of creates... Not just that, right?
For us as an enterprise player, 'cause our history is we run some of the most mission-critical, largest organizations across industry. The level of sort of enterprise readiness, the governance, the security and the privacy, and the fact that we're localized in so many countries around the world creates this moat, this barrier of entry to say, "Hey, I'm gonna go build something and put on top of it." That's one aspect of it, right? There isn't necessarily an immediate threat to say, "Hey, somebody's gonna go build maybe a GL system, localize it around the world, and be able to sort of comply with all the statutory requirements." I mean, that even exists in parts of our portfolio like Concur. I know there's been some discussion as to, is Concur more prone to disruption?
If you look at Concur and you decompose that business, it's expense management. Expense management may sound simple to the layperson, but there is a phenomenal amount of statutory requirements around the world that we spend a significant amount of our R&D investment keeping up to date on a very regular basis. Sure, you can go create a forms over data application that allows you to capture expenses, but who's gonna go do the compliance to the statutory requirements? Who's gonna maintain that over time? Who's gonna make sure all of that is integrated across your core OS for it to work? That's why even if you sort of look back over the last decade and a half, from an expense management perspective, you'd think if it's that easy, the space would be pretty proliferated, but it's not.
Even there, it's a mode from an enterprise perspective, from a localization perspective. That said, you know, that's more of a barrier to entry mode. The question is, there is now an opportunity to create tremendous value on top of it, and that is what we're deeply focused on. I think the thing that makes me sad, honestly, for the first question you asked me, is this is a once in a lifetime sort of, to me, in a tech space, in a business application space, opportunity to create some phenomenal impact and value for customers and hence value back for SAP and our shareholders. We're deeply focused on that. If you think about sort of the opportunity that exists on top of it, certainly automation is one big one.
There's intelligence that sort of requires that data context, that process context, that context graph to be able to come with automation, to be able to sort of create autonomous experiences as well. As you would expect, you know, what we're working on, Sapphire for us is around the corner, right? I'm sure everybody would expect. Like, what we have coming up is one of our most ambitious launches in terms of now taking the opportunity and what's possible with GenAI and AI in general, putting it on top of this sort of core OS of applications that are unlike any others with its enterprise readiness, localization, breadth, industry depth, and creating value, which is what our customers are looking for.
Again, you know, I like analogies a bit, so I'll also sort of give another analogy here, which is, you know, if you think about autonomous applications in some ways, right? Autonomous not just meaning automation, but autonomous has a significance of intelligence that's baked into it, as well as being able to do things that frankly, maybe humans weren't able to go do, because now you can do that at scale across massive amount of data that's very hard for humans to go do. If you think about sort of this autonomous concept of an autonomous business application, it's not very similar to take autonomous self-driving cars, right? In sort of that core mission-critical set of applications, can you really go buy autonomous software to put on a non-autonomous vehicle and feel like, "Listen, this is perfect.
I'm just gonna go make my own car autonomous and drive it around the town." It just doesn't work like that. There's a level of seamlessness in the app data agentic experiences that really creates phenomenal value that's very hard to plumb on top. Can you do it in certain business processes? Yes. You have to also be aware of the TCO impact to the customer on the other side. Because what the customer is then doing is saying, "Listen, for this core area, this, you know, think of it as the OS of the business, I'm gonna go pick something else, a PaaS provider," which everybody and their brothers today is building an agentic PaaS platform, right? That somebody can go plumb on top of whatever exists underneath.
You take on the cost of understanding the data model, which is very hard to go do, doing the integrations, figuring out does the context exist, and then taking the risk of the decision and the recommendation that came out to your financial management, to your supply chain processes, to your spend, which are pretty. You need to be very deterministic. You can be probabilistic like you can be maybe in some of the front office business processes, right? In lead opportunity, and so forth. You have to be very deterministic here because a simple error could be pretty costly for the organization. You really build, add to the iceberg that exists for organization in terms of maintenance costs, integration, and things like that, which in some cases is even preventing application of the agentic layer.
Again, to summarize, to me, I think this app data agentic experience that sort of creates that value seamlessly with the core OS, the systems of mission-critical applications that exist underneath, not just creates value that's unparalleled by just PaaS providers that you can hook into your environment, but it also leads to more deterministic outcomes 'cause we feed it. The thing you talked about the modes, and we can go a bit deeper into it. The modes that we have, which is deep process understanding, the data that we have, the data model, the SAP Knowledge Graph and so forth, that we're sort of building into as a post-trained model to work with what you can find off the shelf. Those two together then sort of create that value that we believe is very unparalleled.
I think the confidence that we have, again, I think the debate is raging out there in terms of, you know, what does that mean for SaaS applications. For us, what we're focused on, again, you know, as you would expect to hear a bunch of things coming out of SAP Sapphire, the proof's gonna be in the pudding. I think the feedback that we're getting from customers is, "Hey, listen, I wanna go run an autonomous finance organization or an autonomous supply chain or autonomous spend." There's a level of credibility connectedness that comes to make sure that the whole vehicle is autonomous.
Not that you buy a layer on top of it and say, "Hey, I'm gonna put it on my 1990 BMW with this new software that's there and I'm just gonna sit back and let it drive me home." You could do that, but there's a lot of risk to it.
Not a car that you would want to get into yourself.
Yeah, yeah.
No, that makes sense. You've already alluded to this, but I mean, I think that this is a big investor concern, that it's not that we actually replace the systems of record underneath, but rather the user interface shifts to probably a chat-based LLM interface that sits above it. There's more interaction there, maybe more value gets created. The people that are running multiple systems of record, investors start to think, "Well, that could make sense." How do you think about that risk? How much do you wanna collaborate with those companies to enable, you know, data access? And how, you know, the value of the intelligence that you have in the system, how much do you protect that rather than wanting to collaborate?
Yeah, I mean, it's a loaded question, so let me see. If I forget one part of it, remind me. The first part you asked is that.
That layer above, yeah.
Yeah. The, the agentic experience, the interaction layer. Because I do. I think one of the things we also believe is for the first time in sort of a long time, the shape of the stack is changing because there's a new layer now on top, which is sort of this agentic experiences layer that sits on top of everything below. Then arguably, everything below it becomes more platform, more commoditized, and the value shifts up, if you will, both in what it creates for customers and the organizations that can charge premium for it as well, and that's really where then the interaction layer happens. We, we used to sit at the top as an application layer, I would say. I mean, we're still there. The world hasn't completely changed yet, but we see the signs that it's changing.
For us, again, it's not that, as you said, the lower layers are going away, like the application data, the PaaS and the IaaS layers. They're not going anywhere. They're still there from that perspective. The question is, for this new layer to work, how does the most value get created? We believe, again, this agentic layer, the application that needs to exist, 'cause that's where data gets created, that's where action gets taken, that's where compliance happen, that's where statutory requirements happen, if you will. Particularly, again, for the class of apps that SAP is in. If you take a small single-lane application that just maybe does an HCM or does some front office application, I think that's a fundamentally different.
Right
... landscape. I mean, we stood on stage, I think it was last SAP Sapphire, and talked about, listen, we believe that the best of breeds will struggle in this world. Where SAP's mode exists, even in this sort of new stack, layer, if you will, is the application layer becomes, again, a platform, if you think about this, right? 'Cause value shifts up. From an application platform perspective, what organizations are telling us, this sort of sweet message to say, "Hey, at this platform layer, we need finance, spend, sourcing, supply chain, HCM, CX to work sort of seamlessly across." SaaS becomes effectively a new platform.
We're, you know, one of the very few you can count on one hand with maybe a couple of fingers that can sort of go across that breadth of the business processes to provide that SaaS platform to power the experiences on top of it end-to-end. If you pick and choose in that SaaS platform six different providers, guess what? You have to build the integrations. You have to make sense of the data model yourself. You have to necessarily push the data somewhere else to be able to connect the two. That's resonating with customers 'cause that also allows them to melt the iceberg, right? The complexity and the TCO that they maintain. That said, it's clear to me, certainly as a product leader into SAP, that we have to have a play in the agentic layer as well.
We wanna make sure that when somebody comes to Joule, they can ask a question about finance or supply chain and spend from the same pane and get the right answer back through the SAP Knowledge Graph, through the sort of fine-tuned model that we talked about, to get the most best response. Then the agentic experiences, again, leveraging that mode, encompassing in that agentic layer for us, sort of creates autonomous experiences that's very hard to build as a PaaS story on top of it, right? So that's what we're working on really unlocking, working with customers and unlocking for our customers as well.
Sort of this redefinition of the applications, these core applications as agentic experiences is as you would imagine, something that we're working very aggressively on, and you'll hear a lot more about that too from a product innovation perspective. Through this, you know, what we don't aspire to become is to say, "Listen, we're just gonna now play in this SaaS as a platform layer." We do wanna play in this agentic layer. But we'll of course be compliant with A2A that if you have other things, as you come understand the SAP data, you come through our agentic layer, if you will. It then creates this sort of stickiness for SAP's agentic layer through everything else that happens in the organization.
While we're mission critical, we're in 99 out of 100 cases, not the only application that exists. There's some deep industry stuff. If you take oil and gas, upstream, downstream. If you take pharma, there's other things that happens as well. There's some industries we're actually pretty complete, like discrete manufacturing, that can mostly run on all SAP and things like that as well. It allows that level of interoperability, if you will, on the moat that we have.
You've alluded to this a few times, this idea of the data, the business context. That semantic business context, how much does that still matter? The question I get is, can these models not come into the system and infer that structure themselves?
Yeah. They can. I mean, I think they can. Again, the difference is, for which kind of application, right? You can even put an MCP server, for those that are familiar with how MCP server works, in front of a, what I call a single- lane, single- domain application. It will do actually a pretty nice job in translating the natural language query that's coming in into what is the answer that needs to come back. Soon as the MCP server has more than X number of tools underneath it, the accuracy just goes haywire. You can't rely on it.
If you look at the SAP landscape, the SaaS platform across finance and supply, even within one of them, the complexity is so vast, the data model, the table, the entities, the extensions customers build is so massive that it just doesn't work with a simple MCP server that you can put on top of it and think, as you might read in some LinkedIn posts, "Hey, this is sort of going to be amazing, and game-changing." Listen, I say that, but this understanding of the context to me is one of our deepest moat.
It's very hard even for us as publishers of the software to sort of solve it in a way where the SAP Knowledge Graph, the SAP Process Graph, the context graph through the interactions and the behavior of the application is available at scale for all the agents, all the natural language interactions. We've been at this for now a year and a half is when we initially said, "Listen, we're actually getting pretty close to our SAP Knowledge Graph," and this is what we've solved for. As hard as it is for us to go solve, this is where our confidence comes in, that at scale to sort of solve for what S/4HANA has, what Ariba, what our supply, it's a very hard thing to go do, and hence that creates the moat.
You have the raw data, but it's the relationship of the data and the semantical richness on top of it, and then how it's used in the processes is what create fine-tuned models that, of course, the agents and Joule works on top of it to, again, address a very vast surface area of an enterprise that otherwise is not easily understandable. What you could do is take the raw data, put it somewhere, and customers do that today. By definition, A, you take in a lot of burden because you don't have the semantical context. B, you also lose the permissions and the authorizations, right?
Because soon as you go put it into a Databricks or a Snowflake or an Azure, or a Google BigQuery, then all it is is sort of flat data that doesn't have that permissions and authorizations, which is also very critical. All of a sudden, because of GenAI, you're not gonna start sharing your payroll data with all of your employees or your financial data everywhere, your supply chain data, at scale from that perspective. We maintain that as well. Our partnerships, particularly with what we've done with Databricks, allows our customers to maintain the data gravity with the semantical richness within SAP Business Data Cloud that we launched last year to be able to then create scenarios that are far more powerful, from their perspective.
This is all about the difference between a point SaaS solution and then the breadth of complexity and solutions that you're delivering, the compliance and governance that sits all around it that really differentiates you from peers. Again, move on to data, and that's obviously a big moat for you. You mentioned Business Data Cloud. Could you talk a little bit about how you think about, you know, how customers lever the data responsibly and how that works through Business Data Cloud, how you're managing those partnerships?
Yeah. I mean, I think, listen, we launched Business Data Cloud less than a year ago, initially with our partnership with Databricks, then we announced our partnership with Snowflake, Azure, and Google as well. You know, for a first-year offering, it's actually been phenomenally successful and no surprise to hopefully anybody here because data is the fuel that sort of powers the value that comes from AI. The way we've sort of designed the architecture, it allows for two things, right? Clearly. One, we want to make sure that we bring to our customers best-in-class data engineering tools that we at this point don't feel like it's a battle we wanna go win in and organically build data engineering tools because that market's both become pretty mature and pretty commoditized.
We brought those tools natively sort of embedded, in some cases OEM, within Business Data Cloud, maintaining the data gravity, the semantic richness, so our customers can go use that to be able to sort of create value from it. We're focusing on the things we add value on, which is harmonized data model across the applications, the connectedness, the Knowledge Graph of it, the semantical richness, partner on the things that have become commodity in data engineering, if you will, for two reasons, right? One, if you want to create value on top of that data through somebody else's AI tools, BDC is still the way to go do.
We become in that flow of value that gets created by anybody a customer may use, and by definition that it gives us a level of both attach, stickiness with the value that we provide on top of that data, which hopefully, as we just discussed a few minutes ago, is far different than sort of taking raw data out of the database somewhere else and trying to plumb on top of it. There's value on top of it, and now we're in the flow of value that's being created theoretically by somebody else.
The second part of it is because we now have that data, available the way we do, bringing now some of the things we talked about earlier, you can help create agentic experiences and value on top of BDC with our AI platform that again covers majority, in some cases, of your core business processes with the right partnerships on top of our platform, where then we actually are the primary, partners to create that interaction layer, that agentic layer, and hence the value for the customer and premium value back to us and our stakeholders. In both cases, this allows us to be part of the value chain. In one, of course, you can go do something, but there's BDC and there's other things, and the others, we're sort of core as the, as the agentic layer, if you will.
Again, what you'll find us do, and we talked about this at our SAP Connect event last fall, you know, we've got some good customer examples for it, is what we can uniquely do than the past agentic players are not able to go do is we can say, we will come up with out-of-the-box agents, right? That work in the seamless app data agentic experience that you can extend if you have other tools, you need to add some pre-post logic because every customer is unique. You can get to value far quicker in a lower TCO way than to say, "Hey, I'm gonna buy this PaaS platform," and then go figure all of that out, if you will.
That also becomes on top of the other modes that we've talked about, a value proposition for customers to say, "Hey, the leading provider of business applications is the one that understands my processes the best, industry, horizontal, and my extensions," because we know extensions built on our platform I can help create this agentic experience and not just create, but use out-of-the-box AR agents, AP agents, spend agents, supply chain agents, and extend them to fit my need is pretty phenomenal. You know, while there's pressure, and I'm sure you guys know this, right? I think this is still very early innings for GenAI, right? There's a lot of board pressure on CIOs and CEOs and CXOs to show value, like, what have you done lately in GenAI?
There's a lot of organizations picking a bunch of different things, cobbling something together and say, "Hey, listen, here's value." The lifetime TCO for that is pretty massive. What we're doing is saying, "Hey, we'll help you unlock agentic layer value out of the box with the right extension, so you don't end up maintaining the burden of that till the end of time," if you will.
Just to make sure I understand properly on the Business Data Cloud, there's obviously gonna be an environment. You talked about discrete manufacturing, SAP can run pretty much end-to-end. I guess in that case scenario, there'd be less need for people to want to do Business Data Cloud. Where they're working with other systems of record, with other applications, would that be more where you could bring value and say, "Well, okay, yes, this is an environment now that's more heterogeneous. You can bring different data sets and then build on top of that." Is that the right way?
No, I mean, I think no, no. If I give that perception, it's not that.
That's my misunderstanding.
Yeah, I know. Thanks for clarifying it. The value of Business Data Cloud is there if you're an SAP shop in whichever form or fashion. What it does is it sort of brings the data harmonized with the semantical richness, with the authorizations and the permissions intact with the SAP Knowledge Graph that you can then go either build or consume the out-of-the-box agentic layer that we provide. What's different, and that's what BDC allows you to go do, is in industry like discrete manufacturing, most of the data would come from SAP, can come from SAP anyway, so it's sort of there. In oil and gas, the SAP data is there, and you can zero-copy sharing with non-SAP data in a seamless fashion. BDC allows you to be sort of that data layer and app data agents for all customers.
In some cases where there's a lot more data outside, you can do zero-copy sharing with some of the, again, the data engineering and data platform tooling that are out there with our partnership to bring it together.
That makes sense. We
It works on both flows, if you will.
Okay. We heard from one of the Business Data Cloud partners yesterday. You know, they talked about starting in the analytical OLAP world, adding OLTP, moving into transactions, talking about an application layer. My question is, how do you keep control of that environment from an SAP point of view? Because I imagine some of those partners might also have ambitions to start to build the applications, the agents on top of that. How does SAP manage that as a partnership, you know, potential competition with those partners?
Yeah, I think in a simple way, I actually found out that this person wasn't wearing a suit, so I probably should have followed his example and not dressed up here. To me, again, you have to go look at the nature of the partnerships, right? With Databricks, for instance, we have Databricks available within BDC. That allows us the ability of those data engineering tooling with our data within the framework of the data gravity staying with SAP to build those agentic platform. Now, if you have other data, you can sort of zero-copy share it and build stuff. Same with Snowflake as well, to be able to go to.
Our partnership sort of allows for leveraging the best of their platform within BDC for the value layer to be built. If there's a massive amount of data stayed outside or if customers have already bet and put a lot of data out there, then you can zero-copy the SAP data in BDC to that, but then keeps us into the flow of stuff. Then I think if you go back a few questions ago, I think the piece that again, it's and I know that's not exactly what you were asking. The piece that where we feel like isn't necessarily going to be a reality in customers' environment is because the data is there, somebody's gonna start building applications on top of it in the class of applications we work in.
Can they go build custom applications on some of those platform partnerships? Yes. We also talked about the value of what comes out of the box because there's deep context graph, there's the model that we're taking, there's SAP-RPT-1 that we launched at SAP TechEd last week that allows you to do data science, but in the flow of the transactions. Like, there's enough value proposition there to say, "Hey, what you build with BDC, with our agentic platform for the landscapes that we work in creates most value." Of course, there's always other things out there that those platforms can fill the gaps on.
Makes sense. You've actually given us some numbers around, you know, the total contract value of BDC. One of the things I was interested in is what's the time to value on those projects? How quickly can you go from signing a contract to getting people up and live and generating revenue with them?
I think, again, Alexander can sort of provide some of that offline, but more than half of our BDC customers are in usage today. The time to value from BDC is very quick. It's not, like your typical think of it as an ERP implementation that says, "Hey, it's gonna take X number of months for the value to show." That's primarily because the way we've sort of built the product is if you have the SAP landscape, the data product that we've built start feeding into BDC, and then all the tooling is available for you to be able to sort of create value on top of it. We can also help you in your modernization journey for BW as well.
With both of those value propositions, we actually see a very healthy amount of usage and time to usage for BDC.
That's helpful. Maybe just to finish off with, I think, you know, one of the other things that's happened is we've kind of reduced software companies to just how they generate code, and if we can generate code more cheaply and more quickly, the value goes away. It seems to me that software companies are much more than the ability to generate code. Could you talk a little bit about, you know, how you think about that reduction in cost of producing code, how customers will be willing to pay for that in future? How does the structure of the industry change in terms of, you know, how you monetize, you know, going from seats to consumption? How do you think about all of that?
Yeah. I mean, I think it's an area we're spending a lot of time thinking through what evolution that we may or may not need to make. I think if you look at the models that we have today, we have multiple models as well. We have a sort of significant part of value that's just embedded in the application for Joule base that says if you're running an SAP application, you can go interact and get value from it. There's a more premium capability that per user per month that says, "Hey, we wanted to give you predictability to say, 'Hey, anything that we ship in this class, you can go try and use without having to feel like you need to add for this feature.
The consumption's gonna be this," and sort of come up with a complicated math. The reality is, I think the ROI, just broadly speaking in general for some of these things, are still to be really proven at scale. What we don't wanna go is get into this debate to say, "Hey, to unlock this feature, it's this much consumption, so you need to show this much." It's about, "Hey, here's a set of capabilities that's continuing to get better, and you can sort of go use and consume as much of it you like." Then we have consumptive measures as well on top of it as well for scenarios that are deeply more consumptive, if you will. I think there are things around sort of now more outcome-based measures that we're looking at. We have usage-based metrics even today.
Not everything. Even our per user per month is user-based. It's usage-based as well, even in our core applications where, when you think about Ariba, we're talking about the spend that goes through as opposed to the number of users that are actually using the application. I think, as you would imagine, as the industry is, we're gonna continue to see where things are going and then evolve based on customer feedback, on what we need to go do.
The aim is to demonstrate the value.
Yeah.
-charge.
Clearly, I mean, I think on the AI space, we at least believe at SAP, we both have the responsibility sort of running, again, these mission-critical applications to sort of prove and show the value. We have the ability to be able to sort of have the value show and then figure out sort of, based on feedback and discussion, what's the right business model in the fullness of time.
Perfect. Well, there's lots more we could discuss. We're bumping up against time. Wanna thank you very much for joining us again.
Thank you for having me.
Thank you.
Thank you.