🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.
Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!
Overview
📖 AWS re:Invent 2025 - Transforming SAP with AWS AI services: AxFood and Harman’s AI journey (MAM214)
In this video, Erik Kamman from AWS's SAP team introduces how enterprise customers are using AI to transform SAP operations. Gustav Hilding from Axfood, a Swedish grocery retailer, shares how they run over 100 machine learning models in production on AWS to optimize forecasting, warehouse operations, and e-commerce personalization, achieving 30% better accuracy than standard systems. Their 6TB HANA database and AI platform built on SageMaker process data from S/4HANA and SAP CAR systems. Varada Reddy from Harman International explains their S/4HANA migration challenge: documenting 30,000 custom ABAP objects developed over 25 years. Using AWS Bedrock and Amazon Q Developer, they reduced documentation time from 15 months to 2 months with 70% cost savings and 6-7x speed improvement. The session highlights 2025 as a pivotal year for GenAI adoption in SAP, with customers moving from proof-of-concepts to production deployments using services like Amazon Q Developer, Quick Suite, Bedrock, and the new ABAP Accelerator MCP server.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Introduction: SAP on AWS and the Evolution of GenAI Adoption in 2025
Today's session, you're going to hear from two large enterprise customers about how they use SAP as well as AI to transform and innovate for their business. You're going to hear from Gustav Hilding, who is the Chief Technical Architect at Axfood. Axfood is a large grocery retailer headquartered in Sweden. You're going to hear from Varada Reddy. Varada is the Director of SAP Technology and Transformation at Harman International. Harman is a professional and consumer audio company that owns well-known brands such as JBL speakers and Harman Kardon stereos and many more. My name is Erik Kamman. I am a member of our worldwide SAP on AWS team. We have more than 7,000 customers today that run SAP on AWS. I lead a team of solution architects that are focused on building solutions and services and guidance to support all of our SAP customers on their journey to the cloud.
From an agenda perspective today, I'm going to give a brief overview of some AI services and solutions and use cases for SAP. Then we're going to hear from Axfood about how they're using AI and machine learning to analyze SAP data and their business processes. Then we'll hear from Harman. They're going to talk about how they're starting their S/4HANA journey and how they're using GenAI services to analyze and transform their ABAP code. We will have some time for Q&A. It's not going to be live on stage. It will be kind of behind the seating area after. So please stick around. I'd love to talk after if you have time.
Quick show of hands. Who is here for their first re:Invent? Quite a bit. What about more than one? Quite a bit as well. Good. So for those of you who attended last year or even in 2023, if you attended any sessions about GenAI for SAP, this is a very different message than what you heard last year. Last year, we had a lot of questions from customers asking what can I do with GenAI and what are the possibilities. We showed you what you could do with GenAI for SAP and demonstrated a lot of demos and art of the possible.
Fast forward to the end of 2025, and we now have real customers like Harman and Axfood sharing real stories about the value that they are bringing now. 2025 is a very pivotal year. We started the year with a few customers that were early adopters. We had a lot of customers that were doing proof of concepts or evaluations. But fast forward to the end of 2025, we're exiting the year with a lot of customers that are moving GenAI solutions into production. We're starting to see mainstream adoption of many GenAI services and a lot of other production-ready services that we have ready to go.
This was made possible by rapid advancement across a few areas. First is the maturity of large language models. I'll call out Anthropic. We use Anthropic Claude, their Sonnet model quite a bit. It does a great job of analyzing and interpreting SAP data as well as SAP ABAP code. At the beginning of the year, Anthropic Claude Sonnet was on version 3.5, then it went to 3.7 to 4.0 to 4.5. Each of those releases was a major step change in the maturity and the capability to analyze and interpret SAP business context.
We also saw industry adoption of some open standards and protocols across the industry and adoption within AWS services. For example, you see MCP up there. MCP, if you're not familiar, is Model Context Protocol. This is an open standard that when you build AI agents, it shows you how you can communicate with backend data sources. We're starting to build solutions. We have some available that use MCP to communicate with SAP using the OData interfaces or the ABAP test cockpit. Overall, 2025 is a very pivotal year. I'm really excited about where we're exiting and seeing a lot of customers adopting GenAI for SAP, and this will accelerate further as we go into next year.
Core AWS AI Services for SAP: Amazon Q Developer, Quick Suite, Quiro, and Bedrock
We have more than 200 services. You've probably heard that before. When you start to narrow it down to say what are the main services I should be looking at for GenAI for SAP, here's the shortlist. There are more services than just these four, but these are the four core ones. Starting on the upper left is Amazon Q Developer. This is an AI coding assistant. It works across almost all programming languages and does a very good job with all of SAP's programming languages and frameworks, including their Cloud Application Framework CAP and Rapid Application Development Framework RAP. It also works really well with ABAP.
We released an MCP server called the ABAP Accelerator just recently. The ABAP Accelerator allows you to do some really interesting use cases with Q Developer. For example, it will automatically generate unit test cases for your ABAP code. It will also take legacy ECC code and automatically convert it to S/4HANA compliant code.
Q Developer overall can really help you on your S/4HANA journey if you're moving to Clean Core, and there are many interesting use cases that can help, and then many more beyond that.
In the upper right is Amazon Quick Suite, and that family of services also includes Q Automate and QuickSight. Quick Suite is an AI business intelligence platform. It allows you to aggregate data from multiple sources such as your own emails, your own files, as well as interface with enterprise data like SAP, Salesforce, ServiceNow, and many more. Once you gather the data, you can chat with it agenentically, you can drill down, you can build your own dashboards. You can even build your own agents with Quick Suite. We're seeing some really interesting use cases where customers are starting to build to automate accounts payable, accounts receivable, and month-end close processes using Quick Suite.
The bottom two are Amazon Quiro. You'll probably hear a lot about Quiro this week at re:Invent. This is our new Agentic IDE, or integrated developer environment. We're seeing some really interesting SAP use cases with Quiro such as building BTP applications or Fiori or UI5 front ends. Then there's Bedrock and Bedrock Agent Core on the bottom right. Bedrock is our main AWS service for integrating with large language models like Anthropic or Amazon's Nova models or even OpenAI now. Bedrock Agent Core is a runtime environment for AI agents. You could build AI agents and run them in Agent Core, which allows you to deploy them into a highly scalable, highly secure, highly performant runtime environment.
We have sessions and workshops this week on all of these services. We have sessions that are SAP specific and of course, we have some that are not SAP specific as well. If anyone has any questions about any of these, come find me after the session and I'll point you in the right direction. So without further ado, I want to get into our customer success stories. Gustav, I would like to bring you up to the stage and hand it over to you.
Axfood's SAP Landscape: A Leading Swedish Food Retailer's Technology Foundation
Eric, thank you for the introduction. Axfood is a leading food retailer located in Sweden, Europe. We're on the other side of the ocean, back where the time difference is nine hours, so I'm here at midnight right now. We have around 800 stores and meet millions of customers every week. Axfood is one of the top 60 companies on the Swedish stock exchange.
Our company consists of different brands, and our customers recognize us as supermarkets, grocery stores, and convenience stores with different logos, different prices, and different concepts. We operate both within B2B and B2C businesses. We are a family of brands, but we share common operations when it comes to purchasing, logistics, business development, IT, and other supporting functions. Our market share is continuously growing. We currently sell about 25 percent of the food that is being sold in our country. This means that both growing volumes and keeping a tight focus on our costs is key for our success, since retail, especially food retail, is a business with high volumes and low margins. So we try to standardize whenever possible.
Our SAP landscape consists of a vast amount of systems. Mainly we're running SAP S/4HANA and SAP CAR. In SAP S/4HANA we're running the industry solution retail as an add-on. This means that we can keep much of our most important data in S/4HANA, so we keep our articles, our assortment, our prices, our promotions, our sales orders, purchase orders, inventory, and point of sales data in SAP, besides the traditional ERP data, of course. For maintaining our forecasts, we're running SAP EWM and SAP FNR. Besides traditional systems, we are also running SAP Commerce Cloud and SAP SuccessFactors. Here we keep our e-commerce orders, our employee data, and our content services.
Looking at a process view, we can categorize our systems into different application layers. S/4HANA is the basis of many well-established flows. We do a lot of custom development in S/4HANA as well. SAP CAR has more unique capabilities and is used for retail-specific operations.
CAR is the abbreviation for Customer Activity Repository. It contains most data objects besides customer data. We keep our customer data outside of SAP. AWS is used to enhance our systems with analytical AI, machine learning, and composite applications. We also keep our data stack on AWS. The systems on AWS typically have a shorter application lifecycle.
I've also depicted some other recipe systems to the left, depending on their uniqueness level. We manage our SAP suite ourselves. We're currently running the S/4HANA on-premise edition without the involvement of any third parties. We have our own staff and employees, and we do everything ourselves. Our business processes that need differentiation are custom developed in ABAP and have been for quite some time, over 15 years. We have full control over the code, the logic, and the development. We're building integrations on SAP BTP with integration suites.
Machine Learning in Action: Axfood's 100+ Production Models Driving Forecasting and Personalization
To give you some numbers, our HANA database is over 6 terabytes in size. We're running over 4,000 CPUs and 140 virtual machines. In retail, many flows are about moving goods from point A to point B. We also handle fresh items, so we really need to have the right products at the right place at the right time. Therefore, a lot of our focus is on optimizing forecasts and volumes. We currently have more than 100 machine learning models in production.
We anticipate that we can get around 30 percent better accuracy in our custom-built models than we get in our standard systems, especially when it comes to irregularities or deviations in our flows. This is because we can build them with more history and more data. We're currently running around 20 different use cases in forecasting for both stores and our warehouses. Furthermore, we use simulations for our assortment planning and use forecasted volumes in combination with customer data to get the desired outcomes for both us and our suppliers.
In e-commerce, AI helps us deliver the relevant products for our customers. By using AI, we get better stability, better sustainability, less food waste, and a positive impact on the environment. A few examples of our optimized flows are being realized by traditional machine learning. We use AI for campaign forecasts, seasonal forecasts, sales forecasts, and e-commerce forecasts. A simplification is that all forecasts that require more data than we keep in SAP are custom built.
In our warehouses, we optimize where to place items depending on how much they are sold. In that way, we can get the shortest picking routes for our manual pickers. Regarding e-commerce, we personalize the user experience online and in our customer journeys. This is done by building models with article relations, for instance, related items, and predicting the next best action. This can be used to drive cross-sell, upsell, and other forms of recommendations.
Our shopping baskets are normally around 50 items, so clicking add to basket 50 times is quite a hassle for our users. Everything we can do to simplify the user experience is of big value here. We also present users with their most commonly purchased items and inspiration on what their peers are buying. In our assortment planning, there is a constant tug of war between different parameters. We use simulations a lot here. For instance, we simulate what happens if you change the price. Your volumes are probably going to go up somewhere, but then again, another item will sell less.
We try to optimize for the optimal outcomes with machine learning models in our assortment planning. We improve our customer offers by creating clusters of customer groups, and we also allocate personalized offers for our customers to bring them to our stores.
In our support functions, we make data-driven decisions and we share aggregated sales data with our suppliers. We never share customer data, but we share it on an aggregated level. This helps our suppliers plan their flows better and it also helps us get our flows better in turn. We also use a couple of AI models for our internal decision making here. Of course we're also using GenAI for employee productivity tools such as chatbots and similar applications.
Another example of GenAI usage that we built is a design tool for creating images. It's a fine-tuned stable diffusion model on Bedrock, trained on our design language of our own brands. We gave this to our business and they played around with it and actually created package designs for milk cartons. These are actual items that were sold in our stores. This was all about bringing attention to what can be done with AI and also got our leadership on board with what can be done. So awareness in departments outside of IT was a key benefit here.
Building Mimer: Axfood's AWS-Based Self-Service AI Platform and Data Ecosystem Journey
Our SAP history started way before 2010. We started building our current data layers in 2012 when we introduced a loyalty program and an enterprise data warehouse. A few years later, Axfood decided to go into e-commerce. We needed a solution that could scale up and scale down according to our purchase patterns. So this was when we introduced AWS back in 2014.
Being on AWS made us see amazing launches like SageMaker, Lambda, Fargate, and other cool technology within AI. So we decided to place our entire AI platform on AWS a few years later. However, running AI in the cloud and having a warehouse on-premises wasn't really the perfect solution. We got into scaling issues and decided to move our entire data platform to AWS back in 2022. Since then, we've been building lots of innovative solutions and composite applications on top of both SAP and AWS. Our cloud journey started in a small corner of our company with e-commerce and currently covers most major processes.
Since we introduced our loyalty program back in 2010, we had needs for creating traditional reports. We introduced the principle to export all data, SAP data and non-SAP data into our data stack. On top of our data stack, we run AI models and return the results either as machine learning models or through APIs or as result sets back into our enterprise systems. It's a simple picture, but I'm going to go into more details.
One key part of our AWS AI stack is a self-service platform that we call Mimer. Mimer is a suite of AWS tools, mainly SageMaker and Airflow. We both create and run ML models in Mimer. We also use AutoML to choose the optimal machine learning models and produce the optimal results for each use case. With Mimer, we can build data pipelines, either through manual files, through third party data, from our warehouse, or even through web scraping.
All data is imported into S3 where it can be used for further AI development. Our data scientists work in SageMaker Studio and can explore large amounts of data. We prepare inputs in SageMaker. We train models, evaluate the results, and deploy artifacts. When results have been calculated, we return them either as machine learning models through APIs or as result sets into our source or into our target systems.
Currently our data stack has grown from being just a data warehouse into an entire data ecosystem. Data is generated in our application layer, mainly in our SAP systems. After that it's integrated through the integration layer, either through EventBridge, Event Mesh, or integration services from CPI as messages. When data lands in our BI stack, we use DBT and Glue, amongst others, to calculate our ETL and data layers.
On top of the BI layer, we place our machine learning layer where we can do traditional ML with Mimer or generative AI applications with our AI gateway. On the bottom of the picture, I've depicted our analytics layer where we use Micro Strategy to analyze data from our warehouse and Subanalytics Cloud to go directly to our SAP systems.
Our data stack is continuously evolving. Some of the key points for future extensions are better focus on data integration with SAP. We always want to have more data in our data warehouse layers. We also need to improve our business with more AI models, more real-time capabilities, and new use cases. A lot of our focus right now is on building data products. Building data products also requires data governance and has an impact on our semantic layers, which are continuously evolving.
Furthermore, we need to support the world of Agentic AI better than we do today, so we have an initiative to look at MCP servers and other technology to have our data AI ready. Finally, we need to do some rearchitecture of legacy systems, for instance, SAP PW.
I would like to introduce some of our lessons learned. We've treated data as a foundation for improving our business since 2012. This has led to a long-term focus on building multiple layers of data. Data needs to have a single source of truth, be clean, and ready for AI. We also introduced some high value use cases early on. This made our leadership understand what can be done with AI.
When our leadership was on board, it became much easier to get funds released and to create the teams for the necessary machine learning development. Last of all, I would like to thank AWS for the amazing AI technology that we're using and for the enablement services and good collaboration. I would also like to reach out to my colleagues and say a big thank you.
Harman International's SAP Environment: A Complex ECC Landscape Supporting Global Audio Technology Operations
Thank you. Thank you, Gustav. Stay up here though. I have one question for you. I love your story. You were early adopters in AI for SAP. A lot of the work you did started before mainstream adoption of large language models. Could you just share a little bit about your thoughts about transitioning from some of your homegrown machine learning models and what you're thinking about with adopting some of the large language models in the future?
We're already looking into Q Developer. We're using that for development in all our teams, be it SAP or non-SAP right now. We're also looking at the world of Agentic AI like I said. We really need to get more generative AI use cases on board with agents. So that's really an area for exploration for the future for us.
Awesome, awesome. Well, thank you again for coming here and sharing your story with everybody. Thank you. So next we have Harman International. I'd like to bring Varada Reddy up to the stage. Good afternoon everyone. My name is Varada Reddy. I work as Director of SAP Technology at Harman International.
Thank you, Erik, for the introduction and Gustav for a nice presentation. So first I will start with a quick summary of what my company does, and then I will explain what SAP products we are using at Harman International, followed by our S/4HANA implementation approach, and then I will highlight one of the key challenges we faced during our S/4HANA implementation and how we solved it with AWS capability.
So a brief introduction about my company: Harman International is a global company specializing in connected audio technologies, providing speakers and audio systems in automotive and consumer divisions. It is headquartered in Stamford, Connecticut, and the company was founded about 75 years ago. The parent company is Samsung Electronics. The company was acquired by Samsung Electronics in 2017 and since then has been part of Samsung Electronics.
Some of the well-known brands of Harman International are JBL, Harman Kardon, AKG, and also there is a recent addition, Bowers and Wilkins.
You might be familiar with some of these products. The company has two major business segments. In automotive solutions, we provide infotainment systems, advanced driver assistance systems, and connected car platforms. In consumer audio, we offer headphones, speakers, soundbars, and multi-room audio systems. Professional solutions is a subdivision of our lifestyle division that provides audio equipment for studios, live events, and enterprise environments.
Let me give you a quick overview of Harman's SAP applications. We have two SAP ECC landscapes, both running on ECC 6 and EHP 7. We have SAP BW for data warehousing and IVP for supply chain planning and optimization. We use SAP Ariba for indirect procurement and BPC and BW 4 Hana for planning and consolidation. We have several manufacturing integration, intelligence, and manufacturing execution systems for managing operations at our global plants. We also have Business Technology Platform, or BTP, with integration suite enabled and other modules for process automation, work zone, and related functions. We use Data Services and Information Steward for data profiling and cleansing, SAP GRC for user provisioning and governance and risk compliance, and Supplier Business Network. Additionally, we have SAP technical solutions like Solution Manager for change management, custom code lifecycle management, and NWDI for Java development and portal systems.
The Custom Code Challenge: Documenting 30,000 Objects and the Limitations of Manual Approaches
Let me zoom in on our ECC landscape. We have two ECC landscapes, both running on ECC 6 EHP 7. I'm going to highlight a problem very specific to custom code, so I'm only covering details related to our customizations. We have 30,000 custom objects in one ECC landscape and nearly 20,000 custom business objects in the second landscape. As part of our migration, we have several key considerations. We want to improve business processes running on the current environment as part of our S/4HANA migration to improve efficiency. We also have a finance transformation plan aimed at improving our enterprise architecture.
As part of this finance transformation, our goal is to consolidate some company codes and harmonize our chart of accounts. We also want to reduce technology debt by eliminating unused or low-use third-party solutions and replacing them with standard S/4HANA functionalities. We plan to eliminate unused or less efficient interfaces and improve our code and configurations. Another goal is to reduce the database footprint significantly. Even with regular archiving on our current ECC environment, we are unable to reduce the footprint significantly beyond a certain point. This is mainly due to third-party related tables that have grown rapidly over time and several custom tables that are not part of the archiving scope, which have contributed significantly to the database size.
Reducing the database footprint is another key objective. We also want to streamline the custom code we have by eliminating unused customizations or replacing them with standard functionalities wherever possible. One of the drivers to reduce the database footprint is downtime minimization during go-live. Since our manufacturing plants operate 24/7, downtime causes significant business impact. Reducing downtime to a weekend is necessary.
Regarding Harman's S/4HANA implementation journey specifically, as I mentioned, one of our key objectives is to reduce the data footprint and perform finance transformation while improving business processes. We selected a selective data transition approach. As part of this, we are migrating only the open transactions along with master data and customizing data.
As part of the finance transformation, we are planning to consolidate the company codes, harmonize the chart of accounts, and adopt SAP best practices wherever possible. Regarding custom object rationalization, the objective is to streamline the customizations by eliminating unused code and replacing less efficient custom code with standard functionalities to improve code efficiency.
The landscape build is being done with a shell approach, using SAP DMLT services to migrate selective data from the ECC source to the S/4HANA environment. One of the key challenges we face is that our ECC systems were implemented more than 25 years ago, and over that period, we have added a lot of customizations to the system. The majority of those customizations have very poor documentation, and in some cases, minimal documentation.
It is extremely important to clearly understand what customizations we have today in the system so we can efficiently migrate them to S/4HANA and understand what to test. We need to identify where there is a possibility to replace some of those customizations with S/4HANA standard functionalities and where we can adopt some of the innovations available from S/4HANA. This determines the need to document all those customizations that are in place today.
Some of the key objectives include eliminating unused custom code. After doing the initial analysis, we determined that nearly 40 percent of today's code is not even in use, which requires thorough cleanup. We also have a requirement to analyze the interfaces and dependencies, as many programs were developed as part of building interfaces for systems connected with the ECC environment. We need to clearly understand the dependencies so we can take care of all the interface mapping and dependencies when we migrate the code from ECC to S/4HANA.
Another objective is to identify what simplifications are happening in S/4HANA and where we can eliminate some of the customizations we have. As we built these customizations over 25 years, SAP may have released many of those functionalities as standard functionalities with subsequent ECC releases or as part of S/4HANA. Having a good understanding of what we have today will help us understand what standard functionalities can replace some of the customizations.
Another advantage of documenting these customizations is that we can limit the testing effort by clearly knowing what is really important for the business and what is being used. We can focus our testing efforts accordingly. When we are troubleshooting issues as part of SAT and UAT, we clearly understand the dependencies and the purpose of the code, so we can troubleshoot quickly.
Not doing this documentation will have a business impact because it can bring operational inefficiencies and escalating costs. We would have to focus on more objects without clearly understanding the purpose of the current code. There are also missed opportunities for innovation because without knowing what we have today, we cannot adopt what is available in future releases. Additionally, there are integration risks if we do not understand the dependencies and mappings in place, so we cannot take care of those.
This documentation also has strategic importance. By fully documenting and eliminating unused code or replacing it with standard S/4HANA functionalities wherever possible, we can optimize system performance and reduce the cost of ownership even with future upgrades. We have a smaller custom code footprint to deal with and we clearly understand where there are risks and what are the key areas to focus on. With clear documentation, we can quickly adopt whenever there are new standard functionalities available and replace the existing customizations.
With all this clear understanding, we know that now we have to document all 30,000 custom objects.
There is no alternative for it. Initially, we started documenting the custom code manually. There were some key challenges with that approach. We started with 6 consultants and began documenting, but the performance was very poor and extremely time consuming. In order to meet the project timelines, we initially planned to achieve this in less than 6 months. As we were not meeting the goal at the rate of speed we needed, we ramped up the size of people working on the task to 12 consultants. Even with that increase, there was only minor improvement in the speed. The estimation to achieve the goal was still 15 months. The cost of paying 12 consultants over 15 months was expensive.
Additionally, the consultants were collaborating with several functional teams to understand the purpose of the code developed over the period of 25 years and trying to document it. However, the output was very inconsistent and missing uniformity because each person was documenting in a different format, and it was not providing the value we were looking for. These were the practical challenges we faced. We realized this approach was not working at all. We were unable to meet the timelines for the subsequent tasks planned based on this documentation, such as mapping the custom documentation with business processes, documenting or linking it with the L1 to L4 processes like order to cash and record to report. The plan was to use this documentation in association with different business processes during unit testing, SAT, and UAT. But this was not working, so we looked at alternative opportunities to solve it with less manual effort and to bring in high consistency.
AWS Bedrock Solution: Achieving 70% Cost Reduction and 6-7x Speed Improvement in Code Documentation
We started exploring AWS AI capabilities, mainly the AWS Bedrock tool. The initial output from the tool was not up to our expectations. Even though it was doing the work automatically, it was only producing technical details like scanning the program and providing only the tables that the program was utilizing and a few technical details. We then collaborated with the AWS team and significantly improved the results by improving the prompt and outputs. We were able to achieve what we wanted. By utilizing AWS Bedrock to quickly scan all 30,000 objects at a rapid speed, we significantly helped achieve the goal within a short period. The speed compared to manual processing was much higher. The speed was improved by 6 to 7 times, and we reduced the total timeline from 15 months to 2 months. The total cost reduction was more than 70 percent. The outputs are very structured, easy to interpret, and very consistent. This was all achieved with AWS Bedrock. Later, we tried Amazon Q Developer with the latest version of Claude on it, and it was even providing better output.
Let me show you a quick sample. On the left side, what you see is the manually generated output by the 12 consultants. This is one sample program output. As you can see, it is very difficult to understand unless a technical person looks at it and completely puts effort into understanding it. It is very difficult for a business person or a functional person to understand what the purpose of the code is. What you see on the right side is the AI-generated output. It is very structured. The top 4 or 5 lines provide a key summary. Then at the bottom, it provides a business scenario description of the program. When a business person takes a look at it, they can quickly understand what the purpose of this program is and understand it because it is written in business language. Then there are the key functionalities. If one of the SAP functional team members looks at it, they can quickly understand what the key functionalities of this program are. Then at the bottom, as you can see, there is detailed step-by-step documentation from a technical perspective.
If a developer wants to understand each snippet of the code, they can review this documentation and understand the complete functionality of the code in technical terms. You can see the difference in the output quality.
The AI-generated output is very easy to consume and is also very consistent across all instances because the same prompt was used across all 30,000 custom objects. The output was very structured and consistent.
One of the key lessons learned from this experience is that whenever you are dealing with a task that is highly manual, highly repetitive, and consuming a lot of your resources, you should think of AI as the first option. Evaluate thoroughly what possibilities are available from AWS and determine whether you can automate the task completely or at least reduce the manual effort to some extent before considering manual approaches. In our case, it took some time for us to explore this, but I want to share this lesson with you so that if you are going through an S/4HANA journey, whatever task you are dealing with, if it has high manual effort and is repetitive in nature, consider AI as an option.
Thank you. I have a question for you as well. I know you are on a multi-year journey for your S/4HANA implementation, and what you are doing with generative AI analyzing ERP code is part of your assessment and early phases of the project. How are you thinking about use cases for generative AI for the next phases of your S/4HANA journey?
Some of the use cases we have already started evaluating include unit testing in the development environment. After we perform code remediation using SmartShift to automatically remediate the custom code in the S/4HANA environment, and as part of our finance transformation where we need to perform functional code remediations as we consolidate company codes and harmonize the chart of accounts, we need to perform a certain level of unit testing in the development environment. This is highly manual work, so to reduce the effort in unit testing, we would like to use the MCP capability of Amazon to automate some of that work. This would allow us to quickly scan the remediated code and verify that it is consistent, efficient, and compatible with S/4HANA.
Another use case is for any new code we develop as part of the S/4HANA implementation. We would like to use Bedrock or Q Developer to document it. Manually documenting new custom code can lead to inconsistencies, and developers sometimes do not fully document all the details required, which later becomes very challenging for troubleshooting. To maintain consistency, I would like to introduce these tools and make them a mandatory step for all developers to use with a specific predefined prompt. This way, all programs will have the mandatory details in place, which can be easily referred to later for troubleshooting or making further enhancements to the code.
The third use case we are considering is using the agentic capability of AWS to scan historical transactions in the SAP ECC environment and capture the data used in different transactions. We would then use the same data to automate testing in the S/4HANA environment. Manually generating test data is a very large and difficult task, so if we are successful in doing this, it will significantly help with automated testing.
Thank you for the answer. Thanks for presenting here today, and I look forward to hearing how the next couple of years of your S/4HANA journey progress. I would like to take this opportunity to thank the AWS team for their significant help in utilizing these AI capabilities.
Please complete the survey in the app, and I hope you enjoy the rest of re:Invent. Thank you for joining today.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)