Know before you go: How to cut SAP costs before moving to S/4HANA & SAP Cloud ERP

Hi, everyone. Thanks so much for joining, and, we will, we'll get started. We have Dan Bankman here with us, and I'll introduce him in a minute. But I'm Sarah Enders. I'm from the marketing team here at EPI-USE Labs. Today, our session is Know Before You Go, How to Cut SAP Costs Before Moving to S4HANA and SAP Cloud ERP, formerly known as RISE. So today, we're going to focus on what you can control before you move and sometimes after, and how that directly impacts your infrastructure costs, your licensing, and the overall success of your migration. I'm joined today by Dan Bankman. Dan's the director of ALM sales for EPI-USE Labs in the US. He brings years of hands on experience with their Data Sync Manager suite and works closely with clients to optimize their SAP landscapes, reducing risks, controlling costs before and during the move to S4HANA. So, we will take questions during the session, but we'll save them, till the very end. But in the meantime, please go ahead and pop them into the GoToWebinar question panel. You should see it on the right hand side of your screen. And, yeah. So I will turn it over to you, Dan. Thanks, Sarah. It's a pleasure to be with you all today. So we're gonna cover on few topics about how you can cut costs before you move to S4HANA and RISE, and luckily we have solutions at EPI-USE Labs for each of these. The three main pillars we'll be talking about today is includes your production data footprint, your non production landscape, and your licensing and roles. So we'll get right into it here, but first, just a little bit about us. So I see that there are some of our clients on and others that are partners, other folks that might be new to us. So we're EPI-USE Labs. At EPI-USE Labs, we are SAP and SuccessFactors software solution providers. Here at EPI-USE Labs, we've been doing our thing for well over twenty years, and we roll up to the greater group elephant, an organization that has approaching five thousand employees globally. And something cool that we do at Group Elephant, which has been doing our SAP thing for over forty years, we channel one percent of all of our group revenue to an ERP NGO that we really utilize to promote the conservation of elephants, rhinos, and uplift the rural people that might otherwise hunt these animals for their tusks, which is why you see the elephants in our backgrounds today. If you come back to EPI-USE Labs, here we're approaching two thousand clients worldwide and they use we have a great many different software and IP leverage services solutions. We'll be touching on some of them today. Again, primarily, we're here to talk about how we can help to save costs on s four HANA and RISE. So Sarah, we have a poll question So let me go ahead and launch it here. You'll see it on your screen. So go ahead and vote. Where are you in your s four hundred journey? Options, still on ECC, starting to plan, evaluating options, already started an s four project, or completed migration. So we'll give you just a little bit here to get those votes in. Looks like we have sixty seven percent of people voting, people still coming in. Okay. I think I'm gonna go ahead and share those results. K. Can you see those, Dan? Yeah. I can see them. So it looks like about half of organizations or folks that are on here are still on ECC and just starting the planning for the s four migration, not unexpected for webinar dedicated to cutting costs before you make the migration. And the rest of you all are somewhere between evaluating or starting or even a few folks have already completed the migration to s four HANA. Perhaps you're still on prem or maybe somewhere in the cloud but just not on Rise yet. This will be applicable to all folks that responded to the poll, and I think we'll get into some of the slideware now. So look, the end of ECC is near. If you delay your move to s four HANA, it doesn't buy you time. It just increases your risk and cost. It's going to lead to regretful spending. You're gonna rewrite the same customizations multiple times, and it's going to lead to rising maintenance on your legacy infrastructure, aging databases. It's gonna lead to missed innovation. You won't have access to AI, embedded analytics, the automation that comes with the migration. This is gonna lead to transformation bottlenecks, and the bottom line is while it may feel safer to delay your move, in the long term it's more expensive to really not make your migration. These are the hidden costs of inaction. So we'll be talking about three main pillars of impacts to your s four HANA and rise costs today, and luckily, EPI-USE Labs has solutions for each of them. Your production data footprint is going to have many years of data growth and unused historical data. Really, this leads to large production databases, which in the s four world and RISE world lead to higher memory requirements, which lead to increased cloud infrastructure costs, and it slows down your systems. We'll dive into each of these into greater depth, but we'll also be touching on non production landscape and how you can really minimize the size of your systems And what we see organizations in the ECC world have is multiple dev QA tests, sandbox, n plus one systems, n plus two. And those systems, if you're not utilizing software like what EPI-USE Labs provides, you're probably making full system copies for each of those nonproduction environments. This is oversized for most needs, and it's probably okay if you're in an on prem world where maybe you already own your hardware, but in the cloud world, this is going to lead to multiplied infrastructure costs. It'll lead to much slower refresh time, more manual workload, just longer testing cycles and delays with your projects, and it will expose sensitive data unnecessarily. Finally, we'll be touching on licensing and roles and the new way that in the RISE world, SAP calculates licensing costs. It's based on FUEs, full user equivalents. And, really, the way that SAP standardly derives the actual number of FUE licenses is typically going to lead to an increased cost and over licensing. We'll talk about how we can minimize costs on all three levels as we progress in this webinar. So first thing we're gonna touch on is your production data footprint. So your production data is driving your s four HANA and rise costs. Most SAP systems are going to have many years of unused data. Sometimes that's around for audit purposes, sometimes it's just around because you haven't gotten around to archiving it or doing anything else with it. Your data volume is directly going to impact your HANA memory. Your HANA memory is going to be one of the biggest core drivers of cost in the s four world. That unarchived data is going to increase your migration cost, the complexity and downtime. And if you go ahead and you move all this data that you're going to store in the s four and or RISE world, you're just gonna have too big of systems that are storing data that you're gonna pay for in infrastructure and cloud costs. The more data you have, the longer and riskier the migrations are and the increased downtime you're gonna have. So most organizations and folks on this call are going to be familiar with greenfield and brownfield migrations. A greenfield migration is really where you're going to rebuild your system from scratch. Your s four system starts from the ground up. It's going to it's gonna be great for data purposes because you start with a clean slate, no data. However, this is going to be a high cost, long run time for your project migration. Usually a full greenfield migration where you're migrating no data and rebuilding from scratch is often overkill for most use cases because you're not utilizing some of the ECC development that you've already got in place. A brownfield migration is really going to be a lift and shift, a big bang. It's a technical upgrade of your existing system essentially. What that means is it carries over legacy issues because there's not going to be much transformation at all. And as it relates to data, and here at EPI-USE Labs we consider ourselves data surgeons, you're going to be moving too much data and that's going to impact your costs as you move to S4HANA and RISE. So what do you do? Instead of migrating no data, greenfield, or migrating all of your data, brownfield, we can help you with a hybrid transition to S4HANA where you take the data that you need. This is called selective data transition or SDT. Selective data transition is where you take just one, two, three years of transactional data and migrate that over and also then leave behind all of the data that you really don't need in your S4HANA system. You may be thinking then, what do we do with all of that legacy ECC data that we may need for audit purposes, compliance for referential purposes. The EPI-USE Labs solution for that is to archive it to a cold storage that we call Archive Central. We'll talk a little bit more about Archive Central and how it can help in just a little bit. But suffice to say, with the selective data transition to s four HANA, you migrate only the data you need, saving you costs on both s four and Rise, and then it gives you the ability to archive off the rest of the data into the archive central solution so that you can always have access to the data that you need. So selective data transition is a hybrid migration strategy. It's gonna sit between greenfield and brownfield. It gives you the ability to really modernize without unnecessary risks and costs. With selective data transition, really you're gonna move only the data that you want. You're gonna filter out the redundant and irrelevant data and only bring forward what adds value in your s four HANA environment. Most organizations are bringing over a year, two years, maybe three years worth of data into their S4HANA environment when they perform an SDT. This enables you to migrate in phases, not all at once. You can migrate by regions, company codes, business units, plants, so that you can keep ECC running while you're bringing up pieces of S4HANA so that you can run them in parallel and minimize your business disruption. This reduces your data footprint. It eliminates the need to copy full systems, and it allows you to archive the historical data with the Archive Central or other solutions so that you can cut your HANA storage costs and really simplify your entire landscape. You can adapt your transformation to your goals because with an SDT, you're able to restructure your business entities, consolidate systems, modernize processes, and you do it on your terms and on your timeline. This is the power of the selected data transition. You get to make the choices as to what you're bringing over and what you're going to optimize. So then you have the question of what do we do with all that legacy data that we're leaving behind in ECC? If we're bringing over just some of the data, what do we do with the rest of it? And really, you're going to sunset your legacy ECC system so that you don't have to continue to pay for licenses for ECC. Support, you'd have to figure out support because we know that's coming to end of life through SAP. Maintaining your hardware and updating it, all of that goes away if you archive to something like Archive Central, which is a cloud based archiving software as a service solution. It has a web gooey front end and it enables you to not just archive your ECC system, but it also enables you to, if you have BW, CRM, SCM, EWM, I could go on with the alphabet soup, but you can archive all of these multiple systems into one simple archive solution, Archive Central, so that you have one centralized location for all of that data. Again, when we do these SDTs, we come with a full knowledge and understanding of the SAP data model. And with that, as we archive data to Archive Central, the data model will be extracted along with the data. So all of your custom database tables, all of the relevant custom reports, they all come over to Archive Central as well so that there's minimal disruption to your ability to reference the historical data in Archive Central. You can also be assured that you're going to comply with global privacy laws like GDPR, CCPA, and Archive Central also has built in retention policies so that you can periodically remove data from the archive so that you can continue to have only the data that you need. If you have twenty years of data to start, now as the years go by, you're gonna need less and less of that aging data, and you can do that with Archive Central. So the next pillar that we're gonna speak about is how you reduce your non production data footprint. So as I stated, we are data surgeons. We're highly knowledgeable in the data model of SAP and SuccessFactors, and really what we find in this non production world is that organizations before they move to s four HANA have all sorts of dev, QA test, training, sandbox, n plus one, etcetera systems that require full system refreshes in order to make copies into those systems of current data. These full system refreshes are large, slow, and totally disruptive. Your testing depends on waiting for complete copies, and really your data is duplicated across each environment. So if you have, let's just say you have dev, QA, a sandbox, and an n plus one, so that goes six non production environments, and you would have a full copy of your production database for each one of those. This is going to in the s four world and rise, it's gonna lead to higher infrastructure and cloud costs. And a lot of organizations don't think about this before they make the move to s four HANA. It is a hidden cost where you're wait where you just see the multiplying effects of having to host all of this data. On top of that, making these copies increases the manual workload for your basis teams. If you're familiar with the refresh process, you know how long these can take and the stress that it puts on not only the basis team, but the project and functional teams that are relying on current data. So the solution that EPI-USE Labs brings to bear is part of our Data Sync Manager suite of solutions for test data management. This specific solution is known as Client Sync. So big bold letters in red right there on the screen. Without Client Sync, you must make full copies of your production databases for your non production clients. So again, if you're making a full copy of production for QA, dev, sandbox, you're multiplying how much data you need to host in the cloud as you make that move. That's a hidden cost that organizations don't often think about. But with Client Sync, you're able to create what we call lean client copies. Client Sync copies at the table level and it's making a data client copy so that you're just copying over, you're customizing your master, and your transactional data. The way that Client Sync reduces and subsets that dataset is it takes a slice of your transactions because, let's be honest, to test, you really only need the most recent three, six, twelve months of data in the transactional data landscape. By reducing your transactions, that's where your the vast amount of data sits, you're able to manage your Ryzen s four HANA storage costs and that also impacts your memory. And what we show here on the screen is that you can save up to seventy five percent of disk space. The reality is that you can save more depending on how much data you wanna take over when you make that transactional data slice. You slice it by time or you slice it by company code, or you can slice it by both if you decide that you only wanna slice, you know, a certain company code and that company code by time. You reduce the downtime when you replace your refresh methodology with Client Sync because the way the Client Sync works is it first exports from the source client, typically production, a file that contains a subset of the transactions and as that export to file is going on there is no downtime on any of your target clients. The only downtime comes when the import begins. And if you have multiple clients on the same system, the only downtime is when the import is happening to that client. So if you have multiple clients, and let's say you have three, the only one that has downtime is the one that's being imported into. The other two would remain up and running. This is a different approach than the system restore, backup and restore methodology that most organizations are taking without the Client Sync solution. This enables organizations to have current up to date test data and only the data that's necessary and relevant, reducing the cost of hosting and storing all of that data in non production. So what we see here is really just a graphic that depicts how Client Sync can minimize your QA and dev systems. Really, if production is four terabytes in this depiction, you'll see that QA is two terabytes and dev is one terabyte. What Client Sync enables you to do is take a fit for purpose client copy so that you only take over the data that's relevant for that system, for that non production client. So in QA, you might say, oh, wow, we actually need twelve months of data so that we're comfortable, but in dev we only need six months, and in sandbox we only need three months worth of data. So you can make fit for purpose copies of production for each of these non production environments, or you can export once from production and make each of your non production instances the same size. That's really up to you and that's part of the power of client sync. In any scenario, client sync is going to greatly reduce the S4HANA and RISE data footprint for your non production environments. Again, reducing that hidden cost that most organizations aren't planning for when they are getting ready to make that migration to S4HANA and Rise. Just to give you an example, we work with many organizations. Data Sync Manager is in the hands of nearly a thousand different global clients, many of them using Client Sync and this case study here is for a global automotive organization. This manufacturer, when they made the move to S4HANA, they started with one plant and then their rollout was to bring plant by plant onto S4HANA. Well, when they initially brought on the first plant, they developed their non production environments. They quickly realized that as they brought more plants on, their production data was changing and to make a full system copy of their production database would require to continue to increase each of their non production environments. They decided, and rightfully so, that it would be too costly to support a full copy of production as their production data volume grew into the tens of terabytes for s four HANA. They quickly realized that these full system copies were not going to be sustainable. So they approached EPI-USE Labs for Data Sync Manager solutions, including Client Sync, so that they could reduce their non production data volume. And the results you can see in the center, they reduced a again, their data footprint is measured not in the singular terabytes, but in the double digit terabytes. They reduced their QA database by sixty two percent, integration systems by seventy five percent, and their sandbox by over ninety percent. They're literally saving on their cloud hosting costs over a million dollars a year. The impact here is that they avoided expanding their HANA memory and infrastructure costs, they have faster, more efficient data refreshes, Client Sync removes much of the pre and post processing steps, really just about all of them, and especially the end post processing steps of BDLS, which can take weeks to resolve. We have a much more elegant way of renaming logical systems. We can talk to you more about that at a later time. But really, it reduced the dependency on the full system copy and enabled the support of multiple parallel projects without bottlenecks. And finally, we'll talk about the licensing and roles. So in the new SAP Rise world, really, we've moved to full user equivalents for licensing. So full user equivalents are really the main driver of your licensing cost. What SAP will do is have you run a star report initially so that they can analyze the roles and authorizations that are assigned in your ECC landscape. And it's not going to measure the actual usage, it's just going to measure what roles and authorizations are currently assigned. There is a gap, I promise you. There is a gap between what users have access to, usually more access than is necessary, and what they actually utilize. This creates all sorts of risk and higher licensing costs because if you are licensing for more for higher level of authorization and usability, you're going to have more f u e's or as I like to call them f u e's, you're gonna have more f u e's than you need and the more f u e's you have, the higher license costs you pay. This is going to really drive your licensing costs at a level that is really unable to be reduced after you set it with Rise. Once you go ahead and you sign up, even if you redesign your roles, you're probably not going to be able to reduce your baseline licensing costs. So the solution that we bring to bear is really a comprehensive license audit so that we can help you to understand what your users are actually using versus what roles they've been assigned in ECC. It's best if we can analyze over a course of a couple of months via a trace and provide you a no obligation access risk assessment at no cost so that you can identify unused or over provisioned roles so that you can see how those roles will translate to your FUE count. And that way you can validate your numbers before you set your baseline with rise. The reality is, again, with without redesigning your roles as they are set today, you're probably going to have an FUE count that is greater than the number of FUEs that you need, and you're going to be paying more in RISE costs. Alright. Sarah, do you wanna talk a little bit about the upcoming events? Sure. Yep. So if anyone is gonna be attending the SAP Sapphire conference coming up in a few weeks in Orlando, our team will be there. So please reach out to us. And then we also have a reception at the Oceanaire, from five to nine. So I'll pop those registration links into the chat for you. We have a couple more webinars in this know before you go series. On May twentieth, we'll be talking more about, licensing and just go a little deeper on the FUI conversation. And then also, we're gonna be going, Dan talked about this a little bit, but we'll go more into the example and case study that we discussed today. So, and I'll pop those into the chat as well. And we did record today. Someone asked that, so we'll definitely be sharing that with you after. So I think we can take some questions. So, yes, the slides will be shared for sure. So first question here, someone asked how long will a refresh take using Client Sync? Yeah. So using Client Sync refreshes in the Sfour world. Look, you're running on a HANA database. They fly compared to, you know, d b two, Oracle, SQL Server, they're lightning fast if you have small data volumes. The larger your data volume, the longer it's going to take. So if you have a small data volume, you know, we're talking hours in the S4HANA world to make your refresh happen, start to finish. It's measured really for a larger database by the weekend. That's when most organizations that we work with want to have a refresh done. They want to do it in a quiet period so that on a Friday night they can kick off an export. Saturday morning, they can come in and do an import, and by Monday morning, they can feel confident that their nonproduction environment has been completely refreshed with a time slice or company code slice of transactional data. Okay. Great. Thanks, Dan. Someone else asked, what is the system downtime when using Client Sync? System downtime is going to be really minimized to when the import happens. So I talked a little bit about how the export import process works with Client Sync. So Client Sync is typically going to export to a file the subsetted number of transactions so that you can see really just the data that you need in that file. So as that data file is being exported, there is no system downtime in the lower tiered environments that are about to be refreshed. Refreshed. The only downtime that happens is when you start the import process to each client. I kinda mentioned a little bit about how if you have a multi client system, the only client that's going to have any downtime is the it's is the client that's going to be imported into as it's being imported. So in the aforementioned weekend refresh, the downtime would be limited to after the export happens on only the client where the import is going to occur. I hope that answers the Alright. That's I think that's all the time we have, and we don't have any more questions, so I think we can go ahead and close it out. As I said, we recorded this, so we'll share the recording, and slides with you later this week, and I popped those registration links, for the next webinar and the SAPHIR event, if you would like to attend either of those. And, we hope to see you at the next two webinars, and thanks again for joining today, and thank you, Dan. I appreciate it. Thanks, Sarah. Thanks, everyone. Take care. Alright. Have a great day. Bye now.