ATRIUMsearch → argument graph
Audio · 2026-04-23 · 46m · 12 moments

SAP: Bringing the ‘Operating System’ of a Company into the AI Era with CTO Philipp Herzig

More than fifty years ago, the modern idea of the standard enterprise software was birthed at SAP. Now, after managing companies through technological shifts from the mainframe to mobile, SAP is at the forefront of closing the AI adoption gap for their customers. SAP Chief Technology Officer Philipp Herzig joins Sarah Guo to talk about how SAP has remained a durable end-to-end “operating system” for its more than 400,000 customers from finance to supply chain. Philipp argues that the AI transiti ✦ AI generated

timeline · colored by role

01
Context

SAP is the 'operating system' of a company, running everything end-to-end — from finance and HR to supply chain, manufacturing, and sales — for 400,000 enterprise customers.

Philipp Herzig describes SAP as the market leader in enterprise software, serving as the end-to-end 'operating system' for 400,000 customers across finance, HR, supply chain, manufacturing, logistics, sales, services, and procurement.

transcript

Philipp Herzig: SAP is the market leader, right, in enterprise of software applications and platforms, right? So 400,000 enterprise customers and usually I just running their finance, HR and, you know, supply chain, manufacturing, execution, logistics, warehouse management, and then, of course, everything on the customer side, sales, services, commerce, procurement, you name it, right? End to end, right? Like SAP, we always say we have the broadest portfolio in terms of end to end, running the business end to end. This is where SAP started with, right? Giving real time insight. And usually I really describe this as it's not just software in itself, it's kind of the operating system, right? Of a company essentially, in order to get, you know, from everything from order to cash or source to pay, right? End to end managed for companies around the entire globe.

explains mechanism · 1

02
Context

SAP's durability comes from the core idea of standard software — reusing the same finance system across customers rather than rebuilding it from scratch each time — which has endured through mainframe, client-server, internet, mobile, and now AI transitions.

Philipp Herzig explains that SAP was founded in 1972 because its founders saw that rebuilding the same finance system for each customer didn't scale. The idea of standard software was born, and it has survived every technology transition because what customers seek — outcomes and return on investment — hasn't changed.

transcript

Philipp Herzig: what makes it so durable, right, at the end of the day, I mean, if you think about this, and it's happening a little bit the same way also when we talk about the SARS estate narrative or the SARS apocalypse, right? I mean, anyway, I have the feeling like in this market last year, AI was in a big bubble and everybody was kind of saying, no, it's not. And this year, SARS estate and so on and so forth. Look, the reality is Now, of course, with the costs of building being so low, right, with specifically agentic coding and all these latest powerful models, I mean, something has always prevailed over the years because even when SAP was founded, right, in 1972, right, a long time ago, I mean, why was it started? Because actually in the 70s, when the founders of SAP worked still at IBM, what did they do? They went to each customer, right, and they implemented the finance system again and again and again and again. And then he said like, hey, this makes no sense, right? Because the economics, it doesn't scale, right? Because of course you can do this, right? But you can only add so much value, right? In any given time. And by the way, we are basically programming the system very similar. Of course, there's always a little bit that is specific then to the customer. And this was the idea where standard, the notion of a standard software was born essentially, right? And then of course, that stood the test of time, right? Because there is simply things and companies that need to get managed, right? End to end. And that also has transformed throughout the years. You've mentioned that, right? First from the mainframe to client server, right? Then to the internet, then mobile, and now of course, AI. So of course, the software has changed and evolved all along with these technologies. What hasn't changed is what customers are seeking for, which is Outcomes, right? Outcomes and return on their investment in order to get the things done, right?

03
Claim

AI is driving a three-layer re-engineering of enterprise software: generative UI that is dynamic and proactive rather than click-driven, business processes that blend structured and unstructured worlds via agents, and a harmonized data layer that combines SAP's structured data with external data to fuel AI.

Philipp Herzig draws a parallel to the cloud transition: just as companies initially thought cloud meant putting on-prem software on the internet, now they are learning AI requires re-engineering at three levels. First, the UI shifts from click-driven interfaces to dynamically generated, proactive interfaces. Second, business processes become more flexible as agents blend structured and unstructured worlds. Third, the data layer must harmonize SAP's structured data with external data to create a unified semantic view.

transcript

Philipp Herzig: When we moved from on-prem to the cloud, originally everybody thought, Hey, we just take the on-prem software we already built, we put it on the internet, call it cloud, right? But then, only over a certain period of time, people realized, Oh, what does actually CI/CD mean? deploy daily or multiple times per day. And then you realize, oh, hmm, we always had multi-tenancy in the on-prem software already. But then, of course, in the cloud, you have to learn how to scale it up and down, right? And all of a sudden, the software kind of got re-engineered, right, to really build real SaaS software that with all the concepts in cloud computing. And with AI, the same is happening. And then it's happening on three levels. It happens, of course, on the UI side. The time is clearly over where you design software, where the dump software that requires the intelligence to sit in front of the computer. So I mean, if you look at classical software, what did you do? You decide a user interface. trying to, hopefully you did some user research, try to figure out in the easiest way or the most intuitive way to teach a human how to get their tasks done by clicking through the UI, essentially. And this is over, right? It's now We call this generative UI, so the UIs get dynamically generated. If you have analytical questions, for example, or if you want to do your deep research, not just the deep research you find on Perplexity or the usual chatbots, but deeply rooted, let's say tariffs are being introduced or new taxes or the strata form was, what does this mean for my supply chain? And then you can analyze this in conjunction with your SAP data. So there's a lot of exciting opportunities and new things you can build that we only dreamed of in the last, I don't know, 20 years, at least since I'm a developer, where now the system becomes much more multimodal, much more proactive, because it can run overnight. And then only if you wake up in the morning, tell you, hey, Sarah, have you looked at this? Here's a problem on the sales side. Maybe the order entry is going down. You should do something here. And here are some recommendations already for this. Or here, there's a problem in the supply chain. Because now if you're an oil and gas customer, obviously you want to know what are my options you need to replan. So all these things become super important for customers and that changes the UI. Then the second one is, of course, the business processes like an order to cash in the past. Of course, it has variances and so on and so forth, but it was a rather rigid process. like the standard operating procedure of a company. But now, of course, with these agents, right, we can blend the structured and the unstructured world more seemingly, so to get actually more work done. So this whole move from software as a service to some call it service as a software outcome as a service, that is, of course, what these agents are building for us. And then, of course, below that, you have the whole data layer, right? The whole data layer of bringing, of course, SAP has a lot of super valuable data for a company, like all your general ledger and your invoices and your warehouse and inventory information, et cetera. But of course, you now want to combine this, right, with the plethora of other data, right, in order to kind of build this one harmonized semantical view, because only, we always say AI is only as powerful as the data is, right?

extends · 1provides context · 1supports · 1

04
Mechanism

The biggest engineering challenge at scale is not the AI itself, but teaching the AI to do the right thing at scale — a POC on 10 documents is easy, but at 1000 documents or 20,000 APIs the engineering challenge grows enormously.

Philipp Herzig argues that while building AI proofs-of-concept is easy, the real difficulty for SAP lies in scaling AI across thousands of documents, 20,000 APIs, and user-specific master data (location, payroll, country) to deliver correct, personalized responses at enterprise scale.

transcript

Philipp Herzig: Well, the biggest challenge, quite frankly, is, of course, when you look at this is how do you, it's actually not the AI so much, right? But it's actually teaching the AI to do the right thing at scale, right? Because, I mean, you can, look, you can build two years ago, right? Everybody build a rack service, right? And you could easily with a POC blew off everybody's, Like the CEO socks and they're like, look how easy it is to build a chatbot on 10 documents, right? But SAP and these large customers, right, they always have a problem of scale. Okay, what do you now with 100 documents? What becomes a little harder? 1,000 documents becomes a big engineering challenge. And now if you go into Joule, you are Sarah, you're maybe an SAP US employee, right? Of course, if you ask a question, Of course, for travel policy, for example, of course you expect a very different answer than me as a German employee would get. So you now need to connect this actually with your master data, like where are you located, in which country are you, under which payroll are you actually, which taxes apply to you, and so on. So all of a sudden it becomes a very, very tricky problem. Same with MCP. Last year, oh, everybody could build an MCP server. It was so super simple to hook up your MCP server and do amazing things with it. But that's becomes very, like for 10 APIs, not an issue, 100, you'll get already context bloat and all these challenges, but we have 20,000 APIs. Oh my goodness. So it becomes this like, because it's so huge, right? There's so much things. So it becomes this problem of scale, right? And doing this really end-to-end for the customer, because what we also build is really an integrated experience across so you can ask your finance question, your HR question, your supply chain, you can correlate that. Like this is the biggest challenge to bring that, so to speak, together, and design it then really for the right outcome.

explains mechanism · 1extends · 1

05
Claim

The biggest engineering challenge at SAP is not AI itself, but teaching AI to do the right thing at enterprise scale — where a demo on 10 documents is trivial, but 20,000 APIs, context bloat, and country-specific policies make it exponentially harder.

Philipp Herzig argues that while building a demo chatbot on 10 documents is easy, scaling to 100, 1,000, or 100,000 documents — each with context-specific requirements like country-based travel policies, payrolls, and taxes — is a massive engineering challenge. He cites the example of MCP servers: easy with 10 APIs, but SAP has 20,000 APIs, creating context bloat and complexity.

transcript

Philipp Herzig: Well, the biggest challenge, quite frankly, is, of course, when you look at this is how do you, it's actually not the AI so much, right? But it's actually teaching the AI to do the right thing at scale, right? Because, I mean, you can, look, you can build two years ago, right? Everybody build a rack service, right? And you could easily with a POC blew off everybody's, Like the CEO socks and they're like, look how easy it is to build a chatbot on 10 documents, right? But SAP and these large customers, right, they always have a problem of scale. Okay, what do you now with 100 documents? What becomes a little harder? 1,000 documents becomes a big engineering challenge. And now if you go into Joule, you are Sarah, you're maybe an SAP US employee, right? Of course, if you ask a question, Of course, for travel policy, for example, of course you expect a very different answer than me as a German employee would get. So you now need to connect this actually with your master data, like where are you located, in which country are you, under which payroll are you actually, which taxes apply to you, and so on. So all of a sudden it becomes a very, very tricky problem. Same with MCP. Last year, oh, everybody could build an MCP server. It was so super simple to hook up your MCP server and do amazing things with it. But that's becomes very, like for 10 APIs, not an issue, 100, you'll get already context bloat and all these challenges, but we have 20,000 APIs. Oh my goodness. So it becomes this like, because it's so huge, right? There's so much things. So it becomes this problem of scale, right?

extends · 1provides context · 1

06
Mechanism

Agentic coding works well because code outcomes are verifiable (does it compile? do the unit tests pass?), but building reliable AI outcomes in domains like finance requires capturing the right input-output data so the agent can validate against a known correct result — this demands a mindset shift toward writing evals and boundary conditions first.

Philipp explains that agentic coding works because you can verify whether code compiles or passes tests. For reliable outcomes in finance and similar domains, developers need to define the correct input-output data and boundary conditions (security, privacy, code quality) so the agent can validate against them — a return to test-driven development principles.

transcript

Philipp Herzig: But the most important thing from a development perspective is actually that people start writing their evals. That is like I was on this tour for a very long time because the problem and why does agentic coding work so well, Sarah, is of course you can verify the outcome, right? You can either say, hey, is the program compiling or are your unit tests, right? Does it work, et cetera. And of course, combined with a little bit of taste, and a lot of hard engineering work and Tropic and OpenAI built these phenomenal code generation models. The problem is if you now want to build a reliable outcome in finance and so on, you need the data that say, hey, with this input, that's the output, right? In order so that the coding agent can validate that and assert that against the reliable outcome. And that's something where there's a mindset shift in terms of how you describe the right boundary conditions to your coding agent, the harness. All the boundary conditions need to be true from a security perspective and from a data privacy perspective, all the code qualities, because you also still want to maintain that code on day two and day three and day four, not just get the first version vibe coded. And then, of course, these evals that then tell you, Hey, this agent is actually doing what it's supposed to be doing in a variety of ways.

explains mechanism · 4extends · 2supports · 2

07
Mechanism

Enterprise agents can achieve verifiability by leveraging the system of record (the database) to define expected outcomes, but to progress toward autonomous agents, you must capture the 'tribal knowledge' that lives in people's heads or Slack channels — creating a data flywheel where every agent interaction generates new data for evals and process improvement.

Philipp describes a two-lane approach: first, use the existing system of record (the database) to verify agent outcomes by checking expected results. Second, agents ask users clarifying questions, and those decision traces get stored — turning 'process mining' into 'agent mining.' This creates a flywheel where captured data becomes new evals, which can either flag anomalies or be elevated into new standard operating procedures.

transcript

Philipp Herzig: That's exactly the point. That is where the starting condition is great, right? I think in terms of like 2 lanes. The first lane is, of course, you have the system of record today, right? You know exactly. in the system, hey, given this or that instruction, right, what is the outcome, right? Because you can see it in the database, right? And then you can construct, hey, if the order to cash process runs like this, then you need to expect, right, that the cash, like the accounts receivable, needs to come in this way, right, with the following taxes and so on and so forth. So that gives you verifiability. Now, the challenge, of course, is, rather, this is never enough, right? Because If you just look into the system of record today, that data is insufficient for this grand vision that everybody has, that it becomes this autonomous enterprise, or the agency of these agents is increasing over time. So at the beginning, the agents, of course, are coming back to you. Some people call this human in the loop or whatever, right? So they need to come back to you, like also still with Cloud Code or Codex, and still ask you some clarifying questions. Hey, I could now go this way, I could do that way. And with that, what you want to design for is that you start to capture more of that context. I always call this the tribal knowledge, the stuff that is not in the system, stored somewhere, that just lives in people's heads or maybe in Slack channels, maybe in Teams channels, maybe it was just a discussion on the phone. So it's not stored anywhere. So how can you drive a decision from that? And then so the question is, the agent needs to come back, ask you for input, now you wanna store that. And now what we do, in the past we called this process mining, now we call it agent mining, because you record all these decision traces, these contexts, what the users are entering into the system. And then you can either use it to say like, Hey, wait a minute, this is actually an anomaly. The folks in, I don't know, in UK from our company or the folks in Australia shouldn't do this because the standard operating procedure is this. Or you say like, that's actually a very good improvement. And then you can elevate this to be the new standard operating procedure, maybe not just for Australia, but maybe for the rest of the world or more countries to run your company more efficiently, because now you'll learn something how the organization behaves, because it can go two ways, right? It could be either good. Or it could be a bad thing, and then you maybe want to streamline the process, how people then actually conduct the process in a different way. And that then leads to this kind of, I call this then this data flywheel, so to speak.

explains mechanism · 1extends · 4gives example · 1provides context · 1

08
Claim

Large language models are not made for predictive analytics; for forecasting demand, cash flow, and classification-regression questions, classical machine learning approaches like XGBoost or AutoML are still necessary, and SAP has developed a new transformer architecture called RPT (Relational Pre-trained Transformers) to democratize predictions over structured data.

Philipp Herzig explains that while LLMs excel at unstructured text and images, enterprise planning requires predictions — demand forecasting, cash flow prediction, classification of customer payment behavior, regression of payment delays. LLMs are not designed for these tasks because they generate one token at a time in sequence-to-sequence modeling. Classical ML approaches like XGBoost work but don't scale because they require hiring data scientists and training separate models per country. SAP's RPT (Relational Pre-trained Transformer) applies the transformer architecture to structured tabular data, enabling accurate predictions with small amounts of data.

transcript

Philipp Herzig: Now, first of all, from a business motivation, it's a great question, right, Sarah? I mean, first from the business motivation point of view, right? Again, LLMs, unstructured world, that's all good, right? But most of the time, if you want to plan forward, right? If you want to make good decisions in a company, you need predictions, right? You need predictions in terms of, oh, what's my demand, right? For, oh, is this depending on the seasonality effects and so on? What's my demand forecast maybe, right, for my products in the retail store? Or what's my demand, right, for my products so I can plan accordingly my manufacturing, right, if I'm a manufacturing customer. Or you want to predict your cash flow, right? You want to predict, and that has a bunch of input variables like, oh, what are actually my day of sales outstanding, right? And that is determined based on Are customers paying yes or no? That's a classification question. And if you then say, okay, if a customer is not paying within the payment terms, what's the payment delay? A classical regression question. And so on and so forth. The problem is, of course, still today, if we look at these predictive questions, right? And then you wanna maybe do a what if analysis from it, right? Now, if you want to do these predictions, quite frankly, then the challenge is large language models are not made for this, right? The way how they generate just one token after another, essentially, in a sequence-to-sequence modeling. I mean, they're language models, right? And they do this phenomenally well. But if you still want to do these predictors, you have to go back to these classical machine learning approaches. You use XGBoost or AutoGluon and many of these AutoML approaches that are still out there. The problem is just it doesn't scale. So we haven't seen in the predictive space the same level of democratization. You still need to hire a very good talented data scientist, right? And then if you, for example, if you're a large company, we did this, for example, at a pharmaceutical company, if you just want to solve the payment delay prediction problem I've mentioned, right? They are running in 90 countries around the world and they need these two models. So you end up with 180 models you need to train. You need to curate the data, you need to train the models, figure out, right, what the right model is, feature engineering, like the classical, machine learning kind of approach, right, that was used in the past. And what we said all the time is, okay, look, we have all this data stored in these tables, right? Thousands of tables, right, where all this information is stored. Can we not apply the same idea that large language models or multimodal models did for the unstructured world, actually for the structured in order to start predicting things? So you can just basically provide a little bit of context, a small amount of data, not a large amount of data, because that will always a problem, small amount of data, and then starting making high accurate predictions, so to speak, in that domain. And that led, actually, it was two years of research. We published that also at NeurIPS and a bunch of other conferences. We call this RPT1, so RAPID1 stands for relational pre-trained transformers. It's still based on the transformer architecture, but with a very different architecture. We released this and we see some, meanwhile, some very, very good results from that in various domains where, as I said, classification and regression, sometimes time series, and so on are concerned. And we believe this will be huge because it obviously will allow way more people from a business impact to make these predictions, which large language models have a really hard time with.

explains mechanism · 1supports · 1

09
Claim

Large language models are not suited for predictive analytics tasks like demand forecasting or cash flow prediction — they generate one token at a time as sequence-to-sequence language models. For structured data predictions (classification, regression, time series), classical ML approaches like XGBoost are still needed, but they haven't been democratized the way LLMs have.

Philipp argues that while LLMs excel in the unstructured world of text, they are fundamentally not designed for predictive tasks on tabular data — demand forecasting, cash flow prediction, payment delay classification. These still require classical ML (XGBoost, AutoML) and skilled data scientists, a gap SAP aims to fill with its Relational Pre-trained Transformer (RPT) research.

transcript

Philipp Herzig: Now, first of all, from a business motivation, it's a great question, right, Sarah? I mean, first from the business motivation point of view, right? Again, LLMs, unstructured world, that's all good, right? But most of the time, if you want to plan forward, right? If you want to make good decisions in a company, you need predictions, right? You need predictions in terms of, oh, what's my demand, right? For, oh, is this depending on the seasonality effects and so on? What's my demand forecast maybe, right, for my products in the retail store? Or what's my demand, right, for my products so I can plan accordingly my manufacturing, right, if I'm a manufacturing customer. Or you want to predict your cash flow, right? You want to predict, and that has a bunch of input variables like, oh, what are actually my day of sales outstanding, right? And that is determined based on Are customers paying yes or no? That's a classification question. And if you then say, okay, if a customer is not paying within the payment terms, what's the payment delay? A classical regression question. And so on and so forth. The problem is, of course, still today, if we look at these predictive questions, right? And then you wanna maybe do a what if analysis from it, right? Now, if you want to do these predictions, quite frankly, then the challenge is large language models are not made for this, right? The way how they generate just one token after another, essentially, in a sequence-to-sequence modeling. I mean, they're language models, right? And they do this phenomenally well. But if you still want to do these predictors, you have to go back to these classical machine learning approaches. You use XGBoost or AutoGluon and many of these AutoML approaches that are still out there. The problem is just it doesn't scale. So we haven't seen in the predictive space the same level of democratization. You still need to hire a very good talented data scientist, right?

supports · 1

10
Prediction

SAP's business model is transitioning from seat-based licensing toward a consumptive and eventually outcome-based model, but this is a joint journey with customers — many enterprises still demand cost predictability and are not yet ready for purely consumptive pricing.

Philipp explains that SAP is clearly moving toward consumptive and eventually outcome-based pricing (like Sierra's model), but in practice it's a hybrid today — a mix of seats and consumption. Customers are not uniformly ready: some demand predictability for budgeting, others fear exploding costs, and not all trust the outcomes enough yet.

transcript

Philipp Herzig: It does, absolutely. I mean, there's no question, and we have prepared for this already. So for me, it was always very clear. I mean, for the most part, SAP software is seed-based, licensed today, with a few exceptions, like Concur or Fieldglass, for example, or the business network. But, you know, very clearly with AI, it was very clear for us that, you know, step by step, it will go towards this consumptive world, right? At first consumptive and then maybe in the next step, once we have more verifiability in the system, then also towards maybe an outcome-based license model to, for example, what Sierra is doing and so on and so forth. But the reality is also, it is today for us, it's a hybrid model. It's consumptive, but it still has a certain element of seats in there and so on and so forth, because also it's a joint journey with the customer. Because the customer is saying they are not yet ready. in many cases, for a purely consumptive model, right? Because they need one predictability, right? And then, of course, they are not yet fully also everywhere trusting the outcome, right? Or node and also, of course, is the value already there, but then they are afraid of that the costs may explode from a consumptive perspective, et cetera, et cetera. So at the end of the day, what we have designed is a hybrid that is basically ready for this consumptive world, but actually meets the customers where they are today knowing that they demand still a lot of predictability in the enterprise space in order to cost control the whole thing for themselves as well.

11
Claim

The winners in enterprise software will be those who make the technology disappear and focus relentlessly on customer adoption and business outcomes — not those who over-index on any specific AI technology, since technology itself gets commoditized.

Philipp argues that the key to enduring through AI disruption is focusing on customer adoption and outcomes, not technology itself. SAP deliberately avoids over-indexing on any specific AI technology, maintains partnerships across the board, and invests only in what is differentiating for customers. The goal is to make the technology invisible and let customers turn capabilities on instantaneously.

transcript

Philipp Herzig: I think at the end of the day, it's all about adoption and the outcome you bring to the customer, right? I mean, the technology, Look, the reality is for most companies, the technology doesn't matter. I always tell to my developers all the time, our job at SAP is to make the technology disappear. We need to get the outcome in front of the customer. And of course, not just the value itself. Of course, you'll also be able to produce and price it in a way. So it's a win-win situation for the customer, and of course, the vendor at the end of the day. So what we are really trying to do, and this is also from an architecture, we are so flexible. We don't over index on a specific element. We have partnerships with all of them, right? And really only invest in the things that are actually differentiating for our customers versus the things that anyway will likely get commoditized in the tech stack. And then try to make sure that we, of course, bake the enterprise qualities in and the integration is there and the customers can turn these capabilities on almost instantaneously in order to benefit from it. Why is this important? Because if you take a lot of time time to reap the value, then your return on investment is essentially gone, right? Or the business case becomes harder, right? And therefore, what we are really focusing on is to deliver these outcomes to the customers. And I think that will differentiate the winners from the losers at the end of the day to really focus on the business outcomes for the customer at the end of the day.

explains mechanism · 2provides context · 3rebuts · 1supports · 5

12
Prediction

The winners in the AI transition will be determined by who can deliver business outcomes to customers — making the technology disappear — not by technology superiority, because most customers don't care about the underlying technology.

Philipp Herzig argues that SAP's strategy for enduring through the AI transition is to focus on customer outcomes and make the technology disappear. He explains that for most companies, the technology doesn't matter — what matters is delivering value, pricing it as a win-win, and enabling customers to turn capabilities on instantaneously. SAP avoids over-indexing on any single element of the tech stack and partners broadly, investing only in what differentiates for customers.

transcript

Philipp Herzig: I think at the end of the day, it's all about adoption and the outcome you bring to the customer, right? I mean, the technology, Look, the reality is for most companies, the technology doesn't matter. I always tell to my developers all the time, our job at SAP is to make the technology disappear. We need to get the outcome in front of the customer. And of course, not just the value itself. Of course, you'll also be able to produce and price it in a way. So it's a win-win situation for the customer, and of course, the vendor at the end of the day. So what we are really trying to do, and this is also from an architecture, we are so flexible. We don't over index on a specific element. We have partnerships with all of them, right? And really only invest in the things that are actually differentiating for our customers versus the things that anyway will likely get commoditized in the tech stack. And then try to make sure that we, of course, bake the enterprise qualities in and the integration is there and the customers can turn these capabilities on almost instantaneously in order to benefit from it. Why is this important? Because if you take a lot of time time to reap the value, then your return on investment is essentially gone, right? Or the business case becomes harder, right? And therefore, what we are really focusing on is to deliver these outcomes to the customers. And I think that will differentiate the winners from the losers at the end of the day to really focus on the business outcomes for the customer at the end of the day.

supports · 2

Highlight slides
AI is Driving a Three-Layer Enterprise Re-Engineering✦ from: AI is driving a three-layer re-engineering of enterprise software: generative UI that is dynamic and proactive rather than click-driven, business processes that blend structured and unstructured worlds via agents, and a harmonized data layer that combines SAP's structured data with external data to fuel AI.Layer 1: Generative UI – From Click-Driven to Proactive✦ from: AI is driving a three-layer re-engineering of enterprise software: generative UI that is dynamic and proactive rather than click-driven, business processes that blend structured and unstructured worlds via agents, and a harmonized data layer that combines SAP's structured data with external data to fuel AI.Layers 2 & 3: Agents Blend Processes; Data Harmonizes✦ from: AI is driving a three-layer re-engineering of enterprise software: generative UI that is dynamic and proactive rather than click-driven, business processes that blend structured and unstructured worlds via agents, and a harmonized data layer that combines SAP's structured data with external data to fuel AI.The Real AI Challenge Is Scale, Not AI✦ from: The biggest engineering challenge at scale is not the AI itself, but teaching the AI to do the right thing at scale — a POC on 10 documents is easy, but at 1000 documents or 20,000 APIs the engineering challenge grows enormously.Personalization Magnifies the Scale Problem✦ from: The biggest engineering challenge at scale is not the AI itself, but teaching the AI to do the right thing at scale — a POC on 10 documents is easy, but at 1000 documents or 20,000 APIs the engineering challenge grows enormously.API Scale: From 10 to 20,000 Endpoints✦ from: The biggest engineering challenge at scale is not the AI itself, but teaching the AI to do the right thing at scale — a POC on 10 documents is easy, but at 1000 documents or 20,000 APIs the engineering challenge grows enormously.Scaling AI: From Demo to Enterprise✦ from: The biggest engineering challenge at SAP is not AI itself, but teaching AI to do the right thing at enterprise scale — where a demo on 10 documents is trivial, but 20,000 APIs, context bloat, and country-specific policies make it exponentially harder.Context Complexity at Enterprise Scale✦ from: The biggest engineering challenge at SAP is not AI itself, but teaching AI to do the right thing at enterprise scale — where a demo on 10 documents is trivial, but 20,000 APIs, context bloat, and country-specific policies make it exponentially harder.Enterprise agents: verifiability through the system of record✦ from: Enterprise agents can achieve verifiability by leveraging the system of record (the database) to define expected outcomes, but to progress toward autonomous agents, you must capture the 'tribal knowledge' that lives in people's heads or Slack channels — creating a data flywheel where every agent interaction generates new data for evals and process improvement.Capturing tribal knowledge as the path to autonomy✦ from: Enterprise agents can achieve verifiability by leveraging the system of record (the database) to define expected outcomes, but to progress toward autonomous agents, you must capture the 'tribal knowledge' that lives in people's heads or Slack channels — creating a data flywheel where every agent interaction generates new data for evals and process improvement.The data flywheel: from captured traces to evals✦ from: Enterprise agents can achieve verifiability by leveraging the system of record (the database) to define expected outcomes, but to progress toward autonomous agents, you must capture the 'tribal knowledge' that lives in people's heads or Slack channels — creating a data flywheel where every agent interaction generates new data for evals and process improvement.
Related episodes