SAUG Solution Series: Mastering RISE: optimising systems and compliance in your SAP transformation

Good morning, everyone, and welcome to our SAG solution series webinar. Thanks to everyone for joining in such big numbers. First,ly, letting you know this session is being recorded. The recording and a copy of the presentation will be made available on the SAEG website shortly and we'll notify everyone when it's ready. This series of course has been created for our partner members to showcase their solutions and show how they can assist with optimizing your SAP systems and projects. Big thank you to s epiuse. Labs for their continuing long term support of SAUG and for making this session possible. Today, we're looking at something very topical and top of mind for a lot of people, and it's around really getting on top of RISE, understanding RISE, and we're looking at optimizing systems and compliance in your SAP transformation. Everyone is on mute, but you can ask questions at any time using the question function on the right of the screen, and we'll go through questions at the end. There'll also be contact details on the slides, so if you'd like to ask any questions in the future, you can email the presenters directly, or you can even come to us. We always welcome your feedback, so if today's topic makes you think of other topics you'd like to see, please also let us know in the question section. Now I'd like to introduce our presenter for today. He's an expert in this area, and his involvement with SAUG goes back many years. Daniel Parker, who's a senior SAP solution architect at Epiuse. Thanks, Thank you, Michael. Hi, everyone. Welcome to the session. Yeah. So as mentioned, I've been working with Epiuse. Labs for nearly ten years now, but in the SAP space for a good twenty or so in the industry. So showing my age a little bit there. But Epiuse. So if you haven't heard of us, we've been sort of in the IT world and specifically in SAP for well over twenty years. And we sort of focus around predominantly SAP related areas, but looking into r and d and development and software solutions to help people manage and run their SAP environments. But also within what we call our greater group of businesses, our group elephant, we provide a lot more services across the IT ecosystem in general. Another thing we do as well is if you are a customer already or may maybe become a customer in the future, we channel one percent of our global revenue into what we call ERP, which is a elephants, rhinos, and people program. So that's helping alleviate poverty, helping save elephants, helping save rhinos, and elevate people out of poverty in Africa. So that's how we sort of give back and help the world within our organization. So without ado, I'll jump into sort of what we're going to talk about today. And as Michael mentioned, we're looking around RISE and how things we can do to help with the management of systems and as part of that Rise journey. So Rise is a little bit of a confusing things at times for people. But, essentially, if you're running ECC now or S4HANA now in on premise or maybe in your own cloud deployment, AWS or Azure, the support and the management around those is sort of dropping, and SAP are wanting you to take a RISE journey, which is essentially moving into cloud hosting managed by them, managing the system in sort of a SaaS type scenario. So today, we'll talk about some of the areas and some of the pain points that we typically see. But there's a link at the bottom of the page, and you'll get that in the slides that come out, which is a nice little learning journey from SAP, which is sort of fifteen, twenty minute discussion on what RISE is, where it fits, and what it means for different customers. So to today, I'm gonna talk through what we see as the common pain points around S4HANA and RISE as well. So some of these you could apply so generically. So maybe you're moving to s four, but maintaining it yourself as well as moving to RISE. So some of these things are sort of general stuff in terms of managing an SAP landscape, but at the same time, they're very much areas which are pain points in a RISE journey. So what I'll talk about today in terms of these five areas, so from left to right, we've got about general cost saving, reducing risk, effectively managing the service, some other cost optimizations around risk and users, and then lastly, on the right, streamlining the migration into Rise. But today, we'll focus on the first three. So we'll talk a bit about how we can reduce ways we believe you can reduce the Rise contract, ways you can reduce the risk of the sensitive data or p r PII data you have in your systems when we think about structures of the RISE contract, and also how we can more effectively manage the systems in terms of roles and responsibilities between you and SAP against the RISE contract. So that's where we'll focus having a chat today. A few or about a month back, our partner, Ceterion, they ran a session through Sorg. So if you go back into the previous Sorg sessions and look at content from Sutterion, you'll see them talking about FUE or full user equivalent. So this is another area which people are sort of struggling or having a bit of trouble understanding. So as you move into RISE to a RISE style contract, the user licensing had goes through some changes and some adjustments. So they've got a good session. I encourage you to have a look at in terms of what it means to manage your FUEs and also managing risk management as you move into s four RISE. And then this last point here is actually a session we're gonna run next month. So this is more about when you move into RISE. So what can I do? So greenfield, brownfield, selective data transition, ways that I can manage my production system as it moves into S4HANA and moves into RISE. So that's some content I'll be covering during August. But without further ado, we'll focus on the first three items today, and we'll just sort of talk through them and give you some ideas and some content and link links to follow-up on. So first of all, we'll talk a bit about saving cost. So in this concept, we're thinking about the cost impact of moving to HANA hardware. So if you've looked into this, whether it's to host yourself, maybe you're already on HANA hardware, maybe you're already on s four, or maybe you're still on a traditional or a legacy database, you'll be aware that there is a cost implication. There's a cost difference between something like an Oracle database or d v two database, which are effectively legacy database styles within the SAP ecosystem. So if we take a like for like system, and bring it across to our target environment, and then we convert that to S4HANA, that could be sweet on HANA, so it's still ECC, or it could be a pure S4HANA system, we're going to see an uptick in hardware cost. It's kinda no matter what we do. That's just a fact of life in terms of the infrastructure that we're gonna consume for the different database types and how we host it and how we management manage it. So that in memory database model of a HANA database is essentially more expensive to manage. So if you're taking ECC on premise, self hosted in the cloud, moving it to RISE, there's a cost implement implication in terms of how you might be managing or looking after the landscape now, which isn't going to set you up well potentially for managing things in a Rise con context. So we see two simple or two key areas to help with that cost reduction. So the first one is around just making nonproduction systems smaller. So when you move to RISE, you're gonna set size points for your systems. So you'll set a development system as a particular size, a test system at a particular size, and that aligns you up for the cost point. So if you can create smaller versions of those systems that still suit you and still help you in terms of managing your landscape, you're going to yourself an opportunity for a lower cost point. So simply having a way to refresh and rebuild a test system that's smaller than production, that's still relevant for all your testing use needs is gonna save you for success. The other one we see is around the development system. So if you like any typical SAP landscape or SAP shop, you may have an ECC system that dates back to when it was upgraded from four six c, and it's got data in it, is not very relevant. It's got a whole bunch of workbench and configuration in it, which might date back to previous file sets of work, things that just never went to production. So in reality, what happens is people don't really do much in that system. They make config changes. They make Workbench changes, and then they immediately move them to the next system in the landscape which has data where they perform testing. So by rebuilding that development system, we make it relevant in terms of your landscape, in terms of Convy Workbench, and we can also put good data in it at a reduced size. So immediately, you can reduce the need for additional systems by having a relevant development system. So these are two kind of basic areas we see that people can benefit from as part of moving to RISE or general landscape management. So it cuts down the size of the systems and cuts down the potential need for extra systems. So the way we help solve that is with what we call our data sync manager suite. So this is a SAP specific test data copy and management solution. So this has been in active development for well over twenty years. It started in the early two thousands, late nineties, late nineteen nineties. So a very long term solution that's been growing and evolving and keeping up with SAP as they have grown and evolved over the years. So we have over eight hundred clients. It's certified for use in Rise, so integration with Rise and also certified with S4HANA for on premise or Rise deployments. This is the thing that helps us with that test left. So we can make a more relevant development system, make a more relevant test system. So you're doing more testing on better data, better systems earlier in your change process and less reliant on pushing transports up a landscape to get testing done. And we also support automation and orchestration tools. So this is a common place that comes up these days. So people are looking to automate refreshers, automate the movement of data, automate other operations the solution can do like scrambling. So we can support testing automation or automation tools and orchestration tools pulling the strings on DataSync Manager. So there's two key components of the solution suite as well that help in this area. So client syncs, so that helps us reduce the size of the test system. So making the purpose client within an existing system, and then also object sync. So that can be made available to consultants or developers or testing teams, and they can add a hoc top up small sets of data for themselves. So they might copy some business partners or customer or vendor into a development environment to help with the testing need without being reliant on a basis team or having to move transports to get a testing to get the testing done. There's a link there as well to a lot more information about Data Sync Manager, but this is the key kind of products we use to help manage the landscape in general. If we have a look at what that means in terms of keeping a system small and controlling the cost over time. So if we think about a basic landscape here, test, and dev. So I might have a, say, seven, eight hundred gigabyte production database, which means I'm likely gonna have something around a one terabyte HANA appliance to control that or to manage that and run that. So whenever I run a refresh of that one terabyte system, I effectively need a one terabyte appliance in the QA system. So I'm setting myself up doing a full database refresh where I need like for like hardware within reason between prod and QA. So I've got a fairly high price point for my QA infrastructure. And then production being production, it will grow over time. So maybe it adds a few hundred gig over a year or two. And before soon, we're looking at a two terabyte appliance size in production. So that gives us the space for the database and some overhead to active operation. So then what happens if I run a refresh? I'm now looking at potentially needing a two terabyte appliance in QA. So I'm not controlling the cost or spend of my QA system. I'm having to keep it in step with the production cost and spend for infrastructure whenever I run an upgrade. So this is where client sync comes in. So we can do what we call time slice. So we take a subset of the data along with master data and configuration and build a consistent client in the target, which is smaller size. So that way, I can control the QA system size. So I might keep that at, say, a five hundred or seven fifty or a one terabyte style appliance size and control that cost point over time and not have to grow it as production grows it. So how that kinda looks in action in terms of running a time slice, we take the transactional data. So I might start the sync today, and then I'll take twelve months or six months of data. So we grab that data from things like a Doka mat doc, and then we analyze it, and we get related items. So I might have open items, purchase orders, sales documents outside of that time period. We bring all that together along with all the master data and all the configuration, and that's loaded to the target client. So I have a consistent working target client without all of the legacy data. And we can apply that same approach as well to a company code slice or an enterprise slice. So sometimes this comes up depending on the type of industry you're in or how you built your system. You might get benefit from copying just a particular company code, a time slice with related objects with just the subset of master data that relates to the company code and all the configuration, and then building a client, a small link client in a QA system for a particular project need or a particular testing need. So we're getting relevant data to the particular scope and spec that you need without having to bring across a full copy of a system or making multiple copies of a system. It's essentially how we can help with that. The other way to think about this as well is in just in terms of the general move into S4HANA and the move into the cloud. So what we can do with the landscape. So, typically, what you might find in a very standard approach that people might do so I'm gonna go from on premise ECC. I'm gonna go to s four. I'm gonna go to Rise. And it's essentially people will take multiple copies of the full production system and use that to build out their new landscape. So they've achieved, you know, one goal in terms of they've got config and workbench alignment across the systems. They've got good data in dev. They've got good data in QAS, but they've kind of failed a little bit because all of the systems are full production size, full production datasets, and a little bit harder to manage over time if we wanna refresh and rebuild because of the concepts we were just talking about in terms of the side. As prod grows, those other systems potentially need to grow. So how we generally help around a brownfield s four conversion with people is you do an initial mock conversion of the copy of production. And then from that, we're using DataSync Manager to build out a lean QA system and an appropriate dev system. So we can build out a small shell, and then into that say development, we'll have a config and workbench client. We'll have a unit testing client and a sandbox client. And each of those will be very small and lean. So the size of the system as a total is quite small, but it's still relevant. Same with QA. We might have one or maybe two clients depending on testing and training needs of the project. So the end outcome is we've got smaller devs, smaller QA, but they're still very relevant. They're still aligned in terms of workbench, still aligned in terms of config and relevant to production, but we haven't picked up the bloat and the full size of the production system as part of that copy across. And then over time, we can continue to refresh them using client sync and getting that smaller subset of data as part of the refresh process. So that's one way we can apply that product set into building the export landscape as well as managing it to helping control the cost of the infrastructure, which relates back to your RISE contract costs. Okay. I'll move on to our next point then, which is around risk reduction. So if you're not aware, a few years ago, a lot of the data processing agreements with SAP changed and adjusted, and you will pick these up as part of a rise move if you haven't already picked them up in some manner. But they do include language now around not storing personal data in nonproduction environments. It's quite a complex little paragraph that goes into this, and there are a few ways in and out depending on the circumstance. But the end story is that SAP are telling us that outside of production, it's best not to store personal data. So, essentially, they're saying to deidentify or maybe manufacture data or change the data in dev and test so it's not a copy of production. Production. I do understand that I just spent ten minutes telling you how to copy production to other systems, so it's a little bit ironic. But what I'll talk about now is exactly how we can help with that as well. So I created a problem, and I was gonna solve it for you there. So perfect. So common question we see that come up is around exactly what PII or what sensitive data do I have in my SAP system. So if you've been running SAP for fifteen years, you know, maybe it's ECC, you're looking at s four, you might have a an attached CRM, you might have an attached BW. So across that, over many years, you've added a lot of data changed, you know, created business processes to support, change things, edit things, remove things. So what is in there? It's it's own little puzzle to solve. So, generally, when people think about this, the immediate point they start is something like the employee data. So maybe you're running HR payroll, so you'll definitely have employee data that'll extend out to maybe next of kin information. You'll have payroll information, payroll results, pay levels, that kind of information, as well as just simple information like names, address, telephone number. Even if you don't have a full payroll information payroll implementation, you might just have employee mini master. So all of your organization's employees might exist so that they can get expense claim reimbursement or attached to an org structure. So you might have a thin layer of that. So if you're doing something like expense management through SAP, that employee will be linked to a vendor to help with that payment process. So I've now duplicated that data. So Daniel Parker is an employee. Daniel Parker is a vendor. I've moved that into two locations. If you haven't already converted to s four, you may or may not have a business partner. When you convert to s four, that's a mandatory thing. So customer vendor integration is enforced, and you'll end up with business partners. So there's another location where that data is duplicated. So my name appears in those three locations. And then, of course, customers. So these might be external facing. They can be individuals as well as businesses. So they might have names, addresses, telephone numbers, which personally identifying, which is linked to the business partner. They might be a vendor as well. So the end result is it very quickly spirals out of control. So the top level objects, employee, business partner, vendor, customer, is just the object concept of that data. Underneath them, there is a myriad of tables and fields which contain the actual data. So it quickly spirals out to hundreds of fields, you know, tens, fifty, a hundred tables as well, which have PII, which you might need to think about in terms of a scrambling context or a management context in your nonproduction systems. And as alluded to, this is all connected. So I can't think about these things in isolation. So if I want to manage the sensitive data against an employee, I've gotta find its linked business partner, maybe its customer, maybe its vendor, and very much the underlying address tables. So all of these things are linked and interrelated and need to be managed. So, again, how we help in this space is what we call our data privacy suite, which is part of the greater data sync manager solution set. And there's three kind of key ways that we help. First, is around privacy workshop system analysis. So it helps in terms of that, where is my data? So we can run some analysis tools on your system. We can map out the PII and help work with you in terms of defining an approach to manage that. So that approach is generally around test data scrambling, which is data secure. So this allows us to mask and anonymize data in nonproduction systems. So for those systems I was just talking about, we get a lean copy of QA. We get a relevant development system. Within that, we can mask and anonymize the data with Data Secure. So I have different names, different bank account numbers, different telephone numbers, and so forth in those environments. So they're still relevant from a testing, training configuration purpose, but they're not exposing real PII in terms of how we manage things. And that's a flexible solution we can customize, add Z tables, add Z fields, those kind of concepts. And then lastly, which we're starting to see a little bit of traction with in the region, so we've got a couple of customers in Australia making use of this and more in New Zealand and across Asia looking into it as well. But we have the ability to manage production data. So this is driven by things like GDPR, which came out of Europe, general data protection regulation, which is right to be forgotten. So we can redact or remove surgically data, PII data from a production system. So how this is being used at the moment with an Australian customer is to help clear down the PII from a contracting legacy workforce. So they've got a whole bunch of contractor data in a HR system, and they're gonna use DataRedact to clear down the PII from that. But we still re retain the core of the record. So if they want to look back at financial information about paying them or when a person, you know, how many resources existed at a point in time, they still exist as shell of the record, but it's no longer identifiable. It's not Daniel Parker anymore. It's redacted. We also helped a large online retailer in Germany with one time vendors. So they're doing web retailing. Not everyone is an ongoing customer. They had a whole bunch of one time vendor data. So, again, we're redacting the PII from the one time end one time vendor information without impacting the financial line items and the results. So they can still look back and see sales history, but they don't know that they sent whatever widget it was out to a particular person as part of the site. So that is where the redact, retain, disclose is potentially helping on a production site as well. So as I said, that's kind of an emerging space that we're seeing more and more of in discussions across the region. But main context is around test data with Data Secure. So how that works, if we just visualize it a little bit, is we can work across a range of systems supporting s four as well, as well as other things like SRM, CRM, BW. So we have a concept of business objects within DataSync Manager. So I can map out the tables related to customer, business partner, and also the customer entity in b w, and then we define what we call an integrity map. So across that, I have all of the tables and fields in integrity maps which relate to a customer name, and we can link them together. So if I change the name from Daniel to Barry, I can follow the links across the ERP customer to the ERP business partner, CRM business partner, and then across to the BW customer and keep all of that data aligned. So not only are we de identifying it, but we're keeping things aligned and consistent as part of that scrambling process. So that is how we can sort of help manage the test data and help with that question around not storing personal data in nonproduction environments, which is something that comes up in the current data post processing agreements from SAP. Okay. And then last point I'll jump into is effectively managing the RISE environment and managing your responsibilities in terms of some of the roles and responsibilities for the contract and what happens when you move into Rise. So at the end of the day, whether it's correct to say it or not, Ryze is kind of SaaS with a choice. So where we're being sent is to more of a SaaS type delivery model for the Ryze solution, whether that's private cloud or even the pure public cloud version. So most of what I'm talking about today is relevant for the private cloud deployment. So you're taking your ECC into RISE, and it's being wrapped in what is more like a SaaS style delivery. But within that, we do get some choice, so we can pick the hyperscaler. You might even get to pick the other partner that's helping you as well behind the scene. But you might go Azure or Amazon or GPC GCP. Sorry. But underlying that, very much SAP is doing the infrastructure as a service and a platform as a service. So from a contract point of view, you're seeing them manage the base layer, operating systems, databases, most of the basis style management, and then handing it across to you within the contract in terms of the application management, business process management, running the system to do what it is that you need it to do for your organization. So around that, you are then working with what they call enterprise cloud services, and then we have different service categories. So within the contract agreement, you're you're seeing a roles and responsibilities list with different service categories as to what SAP will do and what you need to do as their customer. So at the top there, we've got standard services, things that are bundled, which just occur. We've got optional services, so you might choose to take them on as part of the contract management or something you pay for later on. These are things that only can be performed by SAP. So it's not something that you can step in and do. So maybe it's managing a database or, you know, man managing the kernel of the SAP system, those kind of concepts. That is standard service, what SAP are gonna provide, and only they can provide it. There's also additional services. So these are one off tasks, again, only performed by SAP, and you might ask them to do it rather than you doing it. So that's a bit more of a gray area. And then down the bottom here, we have what we call the they call the package services and excluded tasks. So this is where you need to begin to take over and take on the work. So these are areas which you can do. So you might pick up a package service and say that could be maybe something around helping to manage the refresh process. There's some package services in that area. So SAP might take on some of that for you. Otherwise, you can do it. And then the excluded areas, it's things you have to do. So they're breaking this stuff down within the roles and responsibilities of what occurs. So if you follow the links on the bottom of the page here, you will find copies of these cloud services matrices in terms of roles and responsibilities, and you get a bit more of a feel for actually what's happening. So what they will do, the types of tasks, who's the responsibility, you know, what the gaps are, what potential packages you can buy, and what can happen. So what we essentially see happening is people finding a bit of a gap around some of the technical areas of the system. So what was traditionally basis type work, most of that's falling to SAP, but there are clear gaps. So if you're changing how you're managing the SAP system, what your internal organization looks like to support that, you might have less of that technical role internally anymore. And your business analysts, your functional consultants, your trainers and testers might still be around, but they don't have the technical area that we're seeing a gap. So, essentially, we're calling that a bridge service or a RISE bridge service, which is helping manage that basis gap between the realities of the Rise roles and responsibilities and where you sit as a customer and what you need to do. So there's clear sections in there around things like refreshing, scrambling. So those last two concepts I was talking to, SAP will provide refreshers, but they won't provide space reduction as part of that, you know, leaner system. They don't have things around scrambling anonymization. You might need more help in terms of pre and post work around an upgrade or patching or around a refresh. Again, they're not specifically in the roles and responsibilities as taken care of by them. So these are the gaps that we see. So if we sort of break that out into sort of the key areas, we do see here on the left the main concept, if it's part of the standard Rise offering, and where we can fit with a managed service around Risebridge. So as I mentioned, some of the obvious areas there Awesome. The next page, actually, around refresh. But, yeah, things like daily checks. So there is Cloud ALM. There's those kind of concepts, but you might want someone watching the system each day, health checks, short dumps, printer issues, security notes, job monitoring. This is where we can bring in people and solutions to help manage that style of area. Also, advisory. So if you're focusing more to running your business and business processes, you might not have the skill sets around network storage, OSDB. Again, SAP take care of that, but having advisory services to help manage SAP in that area can be very helpful. And there are gaps. If you go and look at the contract, you'll see things around backup the store, startup shutdown, dust, data recovery. They're all mentioned and listed in the roles and responsibilities matrix, but there are clear areas where you need to take responsibility. Again, they might not be areas that your organization has the technical coverage for. Upgrade support packs, system copies, I mentioned those. So there's pre and post steps. SAP will run the bulk of the work that you might want to do, maybe transport, cleanup, and alignment beforehand, post steps with third party integrated products or third party products in the solution, refreshes, pre and post. And as well because we work beyond RISE landscapes, so our managed services team, our tech ops team cover a wide variety of SAP systems, self hosted or RISE. We can start to do things as well. So you might have a hybrid landscape, still have some on premise systems not moved to RISE that are looking to run for a few years before they retire. We can begin to help with those as well as things like transport control. So we bring some automated transport management as well to that process to help you out. So there are the areas. So when we send out the PDF, you'll see links out to those roles and responsibility matrixes. So do have a look through them and sort of be aware where the gaps are, what the packages are that you might need to consider, and what it means in terms of your the breakdown and the makeup of your teams or where you might look to external vendors to help to cover some of those gaps. Alright. Excellent. So that was just a quick talk through on those first three items on the left around simple cost reductions in terms of the contract, reducing risk around PII, and then thinking about how you can better effectively manage the roles and responsibilities between you and SAP with the contract. As mentioned, the optimized costs, have a look for Soteria and recent sessions in your SORC web page and the content there. And then next month, we're gonna talk about selective data transition. But for all of these kind of areas, we have assessments that we can run. So these are free available to any SAP customer running a system so we can help you get some insights on the nature of your system as it is at the moment, and then help give you some ideas around these different pain areas that might help on a RISE journey or any sort of landscape transformation style journey. So these are system analysis reports. So as you see on the picture on the left on the right, sorry, on the loop, it's just a web based report. So we load a small transport into your system, extract some metadata, no business data, or personally identifiable data, and it gives us a breakdown of technically what's in the system, you know, patch levels, whether it's Unicode or not, largest tables, footprint of the data. And these can be very helpful just in terms of understanding, do you have cleanup opportunities? What would a smaller QA system look like? Where is your potential PII ideas around, you know, moving to smaller or leaner production system as well. So these are available. Again, there'll be a link in the PDF we send out, or you can just find them on our website as well. And you basically run the report, send us the data, and then we set up a session just to have a chat with you for thirty minutes, forty minutes, and talk about the contents of the report and different ways we can potentially help. Alright. And then lastly, I've mentioned about a dozen times, I think, but, yeah, next month, we're gonna talk more on the actual transition into RISE and some ways that we can help with selective transition of the data. So not taking the full copy of the system of production, maybe slimming down, dropping some old company codes, removing legacy data, transforming, sort of doing a hybrid move. So brownfield without the legacy data, those kind of ideas. So the link's there to the registration page for as well as that QR code if you wanna grab that. That'll help you jump through to the registration page. I think that's coming late August, that one. Yeah. Alright. And that was all I had to talk through. So I'll wind up there, and we can sorta open up for some questions. Great. Thanks. Thanks, Daniel. Fantastic presentation. The slides will be available on this information. And thanks, Daniel, you're doing upcoming events for me. Really appreciate it that the webinar you talked about, selected data transitioning twenty first of August. And you rightly said there are, there's quite a few recordings, presentations from ceteria and from others around related areas, you know, just go to the SAEG website, log in. There are things around, you know, the FUEs, licensing optimization, a whole stack of things, you know, paths to S four, rise, a whole lot of things. So it's a big, big resource there. It's a big area, so have a look there. Yeah. If you have any questions, we have time for a few. Just use the question function. Daniel, I've got this look. I've got quite an interesting question here. It says, if we scramble all PII data in the QA, will this not affect the quality of UAT? It's like comparing the results before and after a change. Yeah. Yeah. I mean, that's a fairly common question. So we kind of refer to that as like the scrambling dilemma. So there is a line where and it's different for every business. So you need to find how much can you scramble without impacting the integrity of the data for testing. So the simplest way to think about that is things like a telephone number or a bank account number. Typically, as long as it's a long string that is like a normal telephone number or bank account number, you don't really care what it is. You just de identify it. Names, usually, they're kind of okay. Again, we pick from lists of names. As long as they're de identified or changed, it's generally okay, and it's not really a problem. Where it can get tricky is things like pay results. So sometimes people want to adjust a pay result value or, like, an info type eight pay level or fourteen or fifteen. That begins to impact the transactional data if you're trying to do, you know, variance comparisons with payroll results, that's gonna impact that. And that becomes a negative impact in terms of what you're trying to achieve for testing. Another area might be around addresses, something like utilities organizations. If I change an address, it drastically impacts what happens to, you know, billing for gas or electricity if I move the address or made it a non real address. So, yeah, scrambling dilemma. We need to find enough to deidentify without breaking what it means for you in terms of testing or UAT. Sometimes what can happen as well is people might have a very light scrambling rule set for something like a preproduction or a UAT and a much stronger scrambling rule set for a development system. So they're more accepting of issues around testing with the data in dev, but they're wanting just a very light scramble in pre prod or test because of that UAT type question. So, yeah, it's a common thing we work through. Yeah. Great. Another question, Daniel, is the data sync manager solution you talked about, is it supported for use in S4HANA RISE private cloud edition? Yes. Very much. Yeah. So that's that certification around the that works with RISE, works with SAP. I think it's got different language now. But, yeah, S4HANA certified and allowed for use in RISE environments as well. Yeah. You talked about, you know, what doing a refresh with the data sync manager. But what does it do that a full system copy that's included with the rise contract card? So what what does it do that the SAP card, basically? Yeah. The main difference is that we will keep the data size of the QA system more consistent so we can reduce it. So you might have a QA system that's, you know, forty percent, fifty percent the size of production, but still completely valid for testing needs. Whereas the standard copy that's part of the RISE contract, you're gonna get a full copy of production every time, and you're potentially setting yourself up for that larger price point for the QA system. The other thing it'll help us do is it removes a lot of the post processing work. So things where traditionally a basis person might come in and adjust connections to middleware or other third party systems, we can remove the need to do that or automate that. So, again, if SAP are giving you the standard full refresh, they won't typically do that post processing. That'll be left for you, and you need to do it every time. With Data Sync Manager, we can make a smaller system and remove the need for doing that manual post processing. Great. Daniel, I wanted to ask you this question because it's come up in a number of discussions that we've had recently, and you mentioned it briefly as where do you see customers most struggling with the gap between their capabilities and what with the Rise support scope? You know, it's come up a number of times, you know, and where are you seeing the main issue? I mean, yeah, that's kinda where that bridge managed service comes in. So that's where we see the main issue. So it's around what traditionally would have called the SAP basis role. So some of that role sits with SAP, and they'll take care of it. So things like patching, kernel management, profile parameter changes, you know, changing settings on clients, all those kind of areas, even some of the refresh stuff. SAP take care of that. But there's a whole bunch of stuff which is still where Basis would have worked, but becomes your responsibility. So in a move to RISE, people might be, you know, less dependent on Basis resources in their system. So they might be looking to a business analyst or a functional analyst to try and cover that, and it becomes a gap. So it's that technical area. So in the past, you're troubleshooting a problem. It looks performance related. You go and sit with the basis team. Now it becomes ticket management with SAP. So having our service in the middle there is a basis person you can talk with, liaise with, help manage the ticket, help with the performance problem. So that kind of space is where we see there's it's a little bit less consultive. It's a little bit less there's less for you to do, but what you need to do is a bit more you need to think about it, be a consultive, and having that advisory service, having people to take care of the functions in what was traditionally the basis spaces where we see the kind of the biggest gap at the moment. Daniel, we've come to a bit a little bit over time. We've got we one more question came through. I'll I'll tell you the question if you can answer it quickly. If not, we'll we'll share the question. We'll and the question is, will can Epiuse assist with the business case for DSM? Yeah. Definitely. Yeah. So, yeah, if you're struggling to work out how it fits in terms of, you know, the cost of our product versus the cost of, you know, not doing things differently in rides, we can certainly help around that. So that's where the analysis reports comes in. We can get our presales teams and our account execs to have a discussion, look at what your potential rise costs are, what our costs are, how we can manage things differently. So, yeah, definitely, we can help on that stuff. Yep. Excellent. Thanks, Daniel. And look, we went over a little bit, but I think it's very worthwhile. Some great discussion there. Yeah. Just quick announcements. Fourteenth of August webinar deep dive into Signavi and WalkMe. A lot of people are registering with that, so have a look at that. And as Daniel mentioned, yes, we do have twenty first of August. Daniel will be back for another webinar, the smarter path to S4HANA and looking at selected data transitioning. Big one, second of September national summit in Sydney open, registration's open. There'll be a lot of discussions, a lot of presentations around RISE, around your paths, your options, business cases, data analytics, business data cloud, BTP, lots of AI, of course, dual generative AI and much more. Check the website for some special deals. Thanks again to Epiuse Labs for their support. Daniel and Cat behind the scenes. Hope to see you at another event soon. Thank you.