Learn how to modernize your customers’ ERP journeys on RISE with SAP & AWS

Team,

Good evening. Thank you so much for joining us today. It's 7pm on a Wednesday evening. This is true dedication for which I really, really appreciate your attendance.

My name is Soulat Khan. I'll be your host and with me is my colleague, Sunny Patwari. Sunny, introduce yourself.

I've been with AWS for about four years. I lead our global technical alliance and innovation for SAP and also support our Americas partner business.

It's super important for me to get your feedback. My team works on the partner activation framework and we're focusing on partner profitability for SAP workloads on AWS. So looking forward to sharing your perspective with you on how you can modernize our customers' ERP journey with Rise on AWS and moving forward.

If you have any questions, please note them down. We'd love to get to the content but this is an intimate setting on a Wednesday evening. We'd love to take your questions towards the end of the session.

With that, we'll get started. I'm going to go to the agenda slide.

We'll start off with a quick summary of what does it mean that Rise with SAP is activated and what does that impact to your customers?

We'll go a little bit in detail into how AWS and Rise means success for your customers with SAP.

We'll dive deep into the go-to-market motion for keeping the core clean with BTP, what that stands for and how you can complement that, enrich that with cloud native services on AWS.

We'll dive a little bit further into the AWS global infrastructure for Rise and BTP and how that's the backbone to deliver new innovations globally for you and your customers on AWS.

And then we'll talk about our partner community, how you can raise the bar in creating new innovations and tapping into the partner acceleration.

Then we'll go into working together with AWS to identify incentives and programs, which we have built a mechanism with the bill of materials.

And then we'll do an overview of the Rise investments.

Oops, sorry.

So without further ado, we'll dive into the commercial construct.

Traditionally SAP was sold as a software and support, infrastructure management, technology management service with advisory and application management services delivered in a separate contract. You could actually identify partners and businesses for each of these areas in a traditional contract motion.

And what SAP heard from customers is that simplifying that contract is the future for our customer journey. And they introduced a new go-to-market, simplified contract mechanism called Rise.

With Rise, customers have the opportunity to bundle technical management services, so if you think of the operating system and below infrastructure consumable services on the cloud infrastructure management life cycle management software and support into a single contract.

As partners, your customers still have the opportunity to work with you in creating application management services and advisory implementation services separately.

Rise itself though is a subscription license model that's delivered directly from SAP. Customers have the choice of running those workloads at different hyperscalers. And we have five key platform differentiation and reasons where SAP on AWS will provide the best experience, the highest reliability and best performance.

Let's dive deeper into that. For over a decade, SAP and AWS have been engineering and building innovations for our customers in areas of optimization and scalability.

SAP has been using our services and applications for popular products like Qualtrics, Concur, SAP BTP which we'll talk a little bit more about Business Technology Platform, and the latest solutions like SAP Hana Cloud, SAP Data Warehouse Cloud and many many more.

We also, in fact, five years ago, we delivered the first SAP Hana Cloud offering on AWS and we have the largest deployment of SAP Business Technology Platform (BTP) on AWS across nine global regions.

SAP is the most critical workload which is deployed on AWS and leverages our scalable and reliable global infrastructure. The SAP applications leverage the EC2 instances running Nitro which provides better price performance in the cloud and we have a global footprint and the most competitive and large AWS partner program and ecosystem.

There's four customer use cases I'd like to share with you:

Manchester Airport Group, also known as MAG, moves to the cloud to overhaul and streamline their extensive and complex business processes and enabling best in class experiences for their finance teams. MAG went live on Rise in March of this year, marking the organization's first step on the road to transformation with SAP for the next five years.

Revlon announced their SAP on AWS journey for Rise last year and they saw a 40% increase in e-commerce over the last year and they remain focused on enhancing their end-to-end digital capabilities to support this channel.

Ballance is a New Zealand based farmer owned co-op where they produce agri nutrients that deliver greater business value to their farmers. They were able to reduce demand on internal resources by 10% shifting focus from delivering operational support and maintenance to driving value through digital services for its customers.

We'll talk more about that throughout the presentation.

So how does this impact your decision making and creating new business services for Rise?

By a show of hands, how many are partners in the room and how many are customers in the room?

Ok, so majority are partners and customers. I guess you could blend that forward.

It's super important to get a focus on the Rise go-to-market because you have an opportunity to define your own partner profitability and services that can be hosted on BTP marketplace, AWS marketplace and even your own to deliver new innovations.

Traditionally, our focus has been working on the infrastructure layer, providing management tools, primitive core services and infrastructure. And with that working with SAP, we've been providing application services that leverage that infrastructure layer.

If you think about ECC, S4 on HANA, S4 on AWS S4HANA, BW on HANA and traditional BW. That's been the core application layer delivery model and where partners can provide differentiation is by delivering your own industry expertise on top to dive, to dive a little bit deeper on those services.

I'm gonna hand it over to my colleague Sonny Pari to go into how you can deliver that innovation, Sonny.

Sonny: Thank you. So myself Sonny Pari, SAP technical alliance lead for Americas. I focus on SAP technology and go-to-market around Rise with SAP on AWS.

Thank you for the detailed explanation of Rise with SAP on AWS and customer success stories for Rise with SAP.

As mentioned, we have spent more than a decade to work with customers and partners to provide core infrastructure services and instances which are compatible and certified for SAP and SAP Hana instances to run your core business SAP systems like ECC, S4 on HANA, S/4HANA systems like BW, BW for Hana, BW and Hana and all third party systems, which can integrate with SAP.

Today, we are working closely with SAP and partners to use 300+ AWS native services and 83+ BTP services running across nine AWS regions to deliver the business value on top of SAP critical systems running on AWS.

And the key message here is keeping the core clean. Why it is important for customers and partners to follow the message of keeping the core clean and innovating around the core.

Customizing the code is not a one time investment or one time cost. It's a long term technical debt of maintaining that custom code, testing cycles during upgrade projects, risk of upgrade projects because you have to test compatibility of custom code with new innovation in the core. It's a long, long technical debt and that's why it's very important for customers and partners to leverage AWS native services, BTP services to give that joint innovation to customers for their business processes.

Let's look at the key initiatives, as per one of the insider surveys for Rise customers, what they are looking for:

• 54% of customers said business transformation
• 47% said business agility and responsiveness
• 44% said infrastructure, they need secure reliable infrastructure to run their critical SAP applications

How AWS is helping in all these three areas:

Business transformation by simplifying the S/4HANA journey and simplifying the S4 HANA journey. And once they move to S4, I think that's the first step towards the transformation.

Customers are looking for AI services, IoT services, RPA services to automate and optimize their business processes.

Business agility - I think the key insight here is data. Customers are looking for data insights to make those data driven decisions in their business processes.

And the last aspect, and we'll talk more about it, is infrastructure giving that increased reliability, increased security to run mission critical SAP systems.

Let's dive deep into these areas - how SAP, AWS and partners are coming together to deliver that business value on all these three key initiatives for customers, customers who are on their S/4HANA journey.

They are looking for ways to reduce their technical debt of custom code, keeping the core clean for their future advancements or future development. But still they want to maintain their past developments. They don't want to lose that right. And this is challenging as per one of the surveys, 90% of SAP customers use custom code. And when I say custom code, I'm talking about thousands of custom objects.

You can use AWS native services to replace those custom code to serve those business problems or business processes. You can also use BTP services like SAP AppGyver low code, no code to deliver those or create those business applications to solve those business problems or solve those business processes.

Similarly, customers are looking for ways to maintain their ABAP code. They can use BTP ABAP Environment to move their on-premise ABAP transformations to cloud. And by the way BTP ABAP Environment and AppGyver both are only on AWS as a BTP service.

Last aspect of simplifying this S/4HANA journey from a custom code and data perspective.

And one of the aspects is data. Customers are looking to safeguard their migration and during migration, the biggest concern is data - how to maintain, create the master data seamlessly. Customers can utilize another BTP service called BTP Master Data Service to create high volume, high quality master data and maintain that.

So we talked about simplifying the S/4HANA journey for customers around custom code, talking about data, I'm talking about master data as of this moment. But again, as I said, this is just the starting point. Once you move or transform to S/4HANA, customers are looking for ways to utilize IoT/EIML, robotic process automation (RPA) and more to create those customer experiences, to create those experiences which are new to customers, stakeholders and employees and increase the process efficiencies.

End of day, this creates a differentiated experience for them in this industry because they are creating those extra customer experiences including innovation and modernization on top of SAP application with SAP BTP services running on AWS and 300 plus cloud native services. Customers can now make their ideas a reality.

In quick moments, we are, we are working with many partners to create those joint reference architectures to deliver those business value on top of SAP deployment, be it RISE or on premise. Oh, in fact, nine out of 10 BTP, IoT/AI or RPA service run on AWS. Another example is SAP Conversational AI which runs on AWS. SAP Intelligent RPA, which was used to create 233 solution use cases which are in store to automate repetitive manual S/4HANA transactions. They are based on SAP Intelligent RPA. This is on AWS.

Additionally, you can utilize AI/ML services. Amazon Forecast can integrate with CPS for HANA, SAP APO and IBP to give accurate forecasting for any industry function.

Let's talk about an important aspect of AI/ML - look out for equipment, think about predictive maintenance. Like today, customers are doing manual equipment checks in their warehouse, in their manufacturing shop floor every minute or hour. Your equipment is down, it leads to millions of dollars of loss to customers. These are reactive in nature. Predictive maintenance, on the other hand, helps customers to automate that process, be more proactive in their equipment maintenance and it can integrate with SAP Asset Management.

So you are notifying SAP system of a predictive maintenance or maintenance of equipment scenario and creating work orders and finishing there. So end to end workflow to automate predictive maintenance.

Other aspect, Amazon Lookout for Vision that automates the quality inspection. A lot of customers today they are doing manual inspection, they are error prone. Think about customer experience - the sooner you find those defects in quality of product, you will have better customer experience. Manual process of inspection of quality leads to those bad customer experiences.

Amazon Lookout for Vision integrates with SAP Quality Management to give that end to end flow to the customer to have automation around quality inspection.

So we talked about simplifying the S/4HANA journey, we talked about innovation around AI/ML and RPA, but one other important pillar in your S/4HANA or business transformation is data insights. For any business transformation, data insights, how soon or what kind of data lakes you're creating to get that business value is very important.

Today, if you look at the supply chain processes, manufacturing processes, you need analytics, intelligent analytics on top of it to give that insight to you - what is the impact of one container coming late to your facility? What is the impact on revenue for next three months? You need that data insight to take those important decisions.

SAP BTP analytics services like SAP Analytics Cloud - Embed Edition and SAP Data Warehouse Cloud run on AWS cloud on almost 7 regions. Additionally, there are AWS native services like Amazon S3, Amazon Redshift, Amazon Athena, AWS Glue to help SAP customers analyze SAP and non-SAP data together.

AWS provides Amazon AppFlow which can help to automate data flows securely and integrate with SAP applications. More importantly, without code connectors are available to integrate with the SAP applications through AppFlow.

So we talked about simplifying the S/4HANA journey, utilizing AI/ML or RPA services to innovate around the core, having data insights to take those data driven decisions.

Now let's talk about the core infrastructure. I would like to take this moment to talk about global infrastructure and then relate this to why it is important for RISE and BTP customers.

AWS has an uncompromising approach to designing data centers. We start with AWS Regions which are geographical locations across the globe and each AWS Region is comprised of multiple Availability Zones. Each Availability Zone in turn is a cluster of data centers which have redundant power and networking to give that extra reliability to customers.

So think about that approach. Traditionally, what we have seen in the last two decades is customers might have one primary data center and a secondary data center is maybe 100 miles away or 200 miles or 300 miles away. Now, we are talking about multiple data centers clustered to create one Availability Zone and then multiple AZs leads to one Region.

So this intuitive design of Availability Zone within a Region gave SAP the flexibility for customers to create those short range DR and long range DRs offered under RISE with SAP and we'll talk about that in a moment, but we have been hearing from customers their feedback.

We launched three extra regions in last one month, we have been understanding their needs - the flexibility around deployment of RISE with SAP on AWS. So this global infrastructure foundation helped SAP to offer 83+ services across 9 AWS regions globally. This gives customers that extra flexibility to deploy RISE and BTP together on AWS.

Another important aspect, RPO zero - in the last few months I had numerous conversations with customers and partners making them understand why it is important. I'll take a moment here.

RPO is Recovery Point Objective that means amount of data loss in case there is a business continuity or disaster recovery scenario in case of RISE construct - RISE with SAP on AWS. If you are deploying a short range DR, AWS offers RPO zero, that means no data loss.

Think about a 30 minute data loss for any company - number of financial transactions committed that will be lost for 30 minutes, sales orders, warehouse shipment orders, all those things are key to customers business. We have worked closely with SAP to offer this as part of RISE construct short range DR and we'll talk about the architecture in a moment.

Last but not the least, when you run RISE and BTP together on AWS, you are using AWS backbone to connect. So you are using AWS global network to connect RISE and BTP systems. That's another very important aspect when you are as a partner talking to a customer about why it is important to run RISE and BTP together on AWS.

So starting with flexibility of number of regions of deployment, number of services of deployment of BTP and then number of reasons for RISE deployment across the globe providing RPO zero and then connecting all these things together in a single AWS backbone network.

So we talked about backbone network, we talked about the whole global infrastructure deployment. Let's talk about connectivity patterns for customers.

We have heard a lot from customers and partners that what happens when a customer is already an AWS SAP customer or an AWS customer and looking to go RISE - if they have invested in their account already, they have a Direct Connect, they have a VPN connected to our AWS account and they have their user connectivity, they have business system connectivity from their corporate data centers to AWS account already.

They can leverage VPC Peering to connect to RISE account and integrate the RISE systems with AWS cloud native services and BTP services. Again, very important - again, connecting the dots to the flexibility of deployment to flexibility of number of services on BTP and cloud native services to keep the core clean and innovate around the core.

Second option is if the customer is going RISE with SAP and then they realize that ok, I've taken the first step. I'm now an S/4HANA customer. But I want to innovate, I want to modernize my manufacturing process, supply chain process using AWS native services or BTP services.

They can continue, continue to use their backbone infrastructure, what they have established, connect with VPC Peering to their AWS account and start the modernization process. So both options are available. Customer need not rework this.

Another option - a lot of customers have given this feedback that they utilize Transit Gateway to simplify their network topology, and they are already an AWS customer. They are connecting through Direct VPN, Direct Connect or AWS Site-to-Site VPN from their customer data center.

They can continue to use Transit Gateway to connect to RISE account and utilize that option as well. So you are simplifying your network topology, you continue to use your investment, you continue to modernize further and further. So you're not taking a step back in your modernization journey.

You started with S/4HANA, wherever you were, you were already an AWS customer, you are already a RISE customer, you are trying to leverage your connectivity patterns, you are trying to leverage your Transit Gateway. There are options on this one. This is again, very important for partners to understand.

I think I have talked to multiple partners and even SAP on this - when we talk about RPO and RTO, this is not for one system, this is for business process. When you're running P2P, Procure to Pay, Order to Cash any manufacturing process which is hitting your S/4HANA system, and let's say a third party system and a legacy system, you need an RPO and RTO for that business process.

So as a partner, you have to amplify that message, and you have been working great with customers to make them understand why it is important to align your application RPO and RTO together when it's time for high availability discussion.

When it's time for disaster recovery discussion, this is very important because let's say you define an RPO and RTO of, let's say RPO for 0 minutes and RTO for 4 hours for SAP HANA, you need to align that with your legacy system also because end of day, if you have a bigger RPO/RTO for legacy applications, your business process is impacted from that perspective, right?

Same thing goes on backup strategy. Think about when you are restoring your SAP systems, you need that point in time backup for SAP HANA and non-SAP HANA and non-SAP systems together because they are normally in sync. When you're, you're restoring SAP systems, you need those point in time backups. So making sure working with SAP that the backup frequencies, the point in time backups are in sync.

Another option. Another aspect, operational planning. When you start thinking about your IT landscape SAP HANA is helping you accelerate, but you have to think about your operation planning as an IT landscape. There might be more non-SAP system, there might be more non-SAP HANA system in your own AWS account on customers account. You need to work with a partner or a partner like yours. You need to work with customer to define end to end operation planning. You don't need to have multiple outages. You don't need to have different patching cycles. You don't need to have different backup strategy. These processes need to align. So that when you are talking about your IT strategy, you are taking care of your SAP applications, you're taking care of your non SAP applications, you're talking taking care of your non SAP HANA applications running on your AWS account. So end to end thought process around RPO RTO backup strategy. Operation planning is very important.

When a customer is thinking about going SAP HANA with SAP, we talked about our global infrastructure short range disaster recovery, long range disaster recovery. Let's dive a little deeper and explain why and how it is achieved. In case of SAP HANA on AWS. As I said, short range disaster recovery is within a region between two Availability Zones. So when I say short range DR and long range DR, these are disaster recovery options. There is a third option called high availability, which is 99.9% SLA that option is achieved by putting a cluster on top of short range disaster recovery, that is between two AZs. So important for, again, important for partners and customers to understand that. What do they need? We have done this 1000 times with customers, different customers, their RPO and RTO requirement might be different. They might be needing a hybrid approach to their DR situation and a HA situation, right? So understanding from customer that do they need a cluster solution, do they need 99.9% SLA what is their SLA requirement? What is their RPO and RTO requirement based on that? You can define a short range DR, a long range DR or a high availability solution or an and it can be both, I'll extend this further and talk about long range DR. So you can extend the same similar architecture across two regions now and we, and again, going back and connecting the dots for global infrastructure. When we say two regions, we are talking about AWS regions, it can be us east one, us east, two, us west one. So there are different pairings for long range DR in case of SAP HANA on AWS.

So overall with SAP HANA when you're talking to a customer, normally the way we have talked to partners and customers is what is your RPO to requirement? What is your SLA requirement? Let's pick and choose and or between these three, is it a short range DR is it a long range DR is it a combination of a long range DR and high availability? So you, depending on your situation, depending on customers need, you will pick and choose one versus the other or both.

For, let's talk about SAP HANA AWS investment. We have done a lot of work behind the scenes to help partners and customers adopt SAP HANA and to talk about um AWS investment. Let's let's talk a little bit further on AWS investment.

Before I dive into the investment aspect of the conversation. Let's understand what is a SAP HANA BOM. How does it look like? What does customer start? What, what happens when customer wants to understand SAP HANA?

So the first conversation in our traditional days, I'm sure you will, you will remember that is how many users are you talking about? So user based sizing, we used to do that in the past and then transactional based sizing and whatnot. So traditionally that user based sizing is equivalent here to FUE that is Full User Equivalent. So customers will explain that scenario to SAP that my overall requirement for users for full user equivalent is this much that will give them a logical t shirt size. Let's say an example is if you have 551 full equivalent user requirement, it is more or less small size of S/4HANA same. And depending on different categories, like I think it's 135 up to 135 and then 136 to 555 151 to 1001. So it gives you that logical t-shirt sizing.

Once you've passed that, then you try to understand, ok. From a user perspective, I'm covered. But from a data perspective, I need more. My HANA database size might be, might be bigger than the, the initial logical tearing. Then you start talking about infrastructure add-ons like memory extensions. So you can expand your S/4HANA system S/4HANA database by adding 256 multiples of memories. So by default, let's say by FUE based sizing, you might got small, which is let's say 512 or 256. And then you can add memory extensions to get to another logical tier of sizing. You might need more application servers that you realize that ok, you know what my logical tier of large had five app servers, but i needed four, right? So you start playing around with those numbers that what if you base sizing gave you that initially? That logical tier and then you start working around. What is my additional app server need? What is my additional memory extension need? What is my additional storage need that is called infrastructure add on.

And then there are other add ons and industry add ons and LB add ons which are more user activation for licenses. Why i explained this is very important because when we talk about SAP HANA with SAP AWS investment, we want to understand what was the AWS run rate annually based on that? We give a percentage to customers and partners to offset that migration cost and sometimes help them modernize the SAP applications in the AWS account.

So we talked about modernization throughout the throughout the session. And that's the key that we want to help customers adopt AWS services running on when they are running a SAP HANA and AWS. So these extra investment from our side help them offset their either migration cost or help them modernize for future.

So now we talked about our BOM structure. How exactly does BOM looks like? And where is the infrastructure cost? Right? Your FUE based sizing and then memory extensions and then app servers and storage and whatnot. Let's understand our own program.

I remember the date January 27th 2021 when SAP HANA came out, we started working towards SAP HANA program on AWS. We work with SAP and we, we started talking about t shirt size initially that ok, this t-shirt size is small based on small, this is the amount of amount of investment from our side to help customers. We realized that we are not doing enough, we can do more. Then we built our own tool internally to to consistently and accurately define that AWS spend or AWS run rate.

So we have a tool internally. We build that where we key in the SKU the SAP HANA SKU what you're what you're buying and the quantity that's it. We are not looking for price, we're not looking for anything. We key in that and that tool automatically comes up with a number that this is the expected annual run rate based on this SAP HANA BOM.

So we work towards that to give that consistent and accurate funding or accurate investment to customers and partners. Why it was important. First of all, to speed up the process, we didn't want to delay any SAP HANA opportunity or SAP HANA conversation with customers and partners just because it's taking time to understand what this BOM means, right? So that was one thing, an accurate and consistent SAP HANA investment. The second was fast turnaround time. Very important. A lot of times you understand, as a partner that you have to give that initial numbers to customers to understand, give them an idea of what we are looking at what kind of offset they can get as part of SAP HANA funding.

And more importantly, in this case, we we talked to SAP as well that we are not looking for any private data. We are not looking for any cost of SAP HANA BOM itself. What we are looking for is what all SKUs are part of SAP HANA BOM and what is the quantity? And when i say quantity, i mean, let's say if you are buying a S/4HANA. What is the number of you are buying 551,000, 1 2001 based on that, we do our internal calculation to give customers that initial understanding of SAP HANA investment from our side.

One of the important aspect of this uh this tool internally, what we have is the SAP HANA BOM validation itself. So when you are buying memory extensions, keep in mind that you have to be on a logical tier, right? If you by default, as part of FUE base sizing, you got 512 gig let's say on a database. And you are buying memory extension, you cannot buy three memory extension to get to 1.25 terabyte, right? You have to be in a logical sizing tier.

So we build those the tool with that internal logic of where this memory extension can lead you to like when you, when you are a small, if you add two, it can go to medium. But if you add three, it's taking you nowhere because you are 1.25 terabytes, either go 1.5 or two or one terabyte, a logical sizing tier of instance. So that's very important that instance validation making sure customers are getting what they want to, right?

So as part of working closely with partners to to help them accelerate any SAP HANA opportunity, we build this internal tool, we keep investing on this tool to make sure it is up to date. We are giving the best and the most most investment wherever we can to the customers and partners and to talk further about call to action. I'll hand it over to Sonali Sanyal.

Thank you so very much. I appreciate you covering all those topics very eloquently.