Automating data transition in SAP S/4HANA

Thank you again everyone for joining today. So as you know, this is one of our webinars in the series for our de risking SAP transformations. Today's session is all about automation and we've got our speakers today, Jamie, Neilan and Ramesh Mandel. They are experts on this topic all the way from the UK. So there was a change in scheduling it may hit a little bit later otherwise it would have been four am for their time so you'll have to excuse some darker lighting behind them because it's very early in the morning for them but they are absolute experts and we're very lucky to have them join us for this session today. And hopefully you're excited about the following sessions that will come over the coming months as well. So Jamie is the Managing Director of our Labs Prison Transformation Project service line. He's based in Europe. So, basically, what that means is the big SAP transformation projects that happen, Jamie is sort of the one that sort of leads those and leads that whole part of the business. And Ramesh is our landscape transformation technical architect. So he's the technical one of the technical people behind the scenes who does a lot of the work as part of those projects. So we have a really powerful session today. It's probably going to be slightly longer than our standard sessions, maybe potentially. We're usually about twenty five minutes for the content. It might be more like thirty-thirty five minutes. Please feel free to ask questions as we go through and at the end I will answer them here for you as well. If you have to drop off early, we will send this recording through and you'll have the ability to ask questions after you watch the end of the replay via email as well. So I am going to stop stop chatting and hand over to Jamie and Ramesh to start this session. Thanks again, guys, and over to you. Thanks, Kat. Yeah. And thank you so much for joining us, and thank you everybody else that's joining us on this webinar. So as Kat said, I'm Jeremy Neelen. I've worked for EPI-USE Labs now for just over ten years. Previously, I worked for you at PACCARD for fifteen, all of those years in the SAP space. So as Kent said, I now lead the business that runs transformation projects with our software. And we're gonna talk about automating data transition in different kinds of S4HANA projects and across different functional areas today. And Ramesh is someone who's joined us to really accelerate in technology in the space of transformation. So Ramesh, if you wanna say hello and briefly introduce yourself, and I'll get into the main presentation. Yeah. Thank you. Thank you, Jamie, and hi, everyone. Myself Ramesh Mandel, and, you know, as part of journey S4HANA transformation, so more than eighteen years of experience throughout into SAP technology, looking into different, you know, technology transformation domain starting from ECC, now S4HANA, where things are moving around. So helping into finding a right accelerator, which will help all our partner customers to accelerate this transformation journey. So throughout into looking at the data, looking at the integration, looking at the different aspect of our transformation, which we will see in the session, which cut across multiple different domain. So helping to bring those tools and technology to the team. Thank you. Thanks, Ramesh. So as per the title of the presentation, we'll talk about automating data transition in S4HANA projects. And we're going to talk about five pillars that we recommend people consider when planning how to handle data transition for their projects. So you may know us as a software company in EPI-USE Labs. We'll certainly talk about software and how it can be used for that automation. But the point of this slide is to talk about the specialist mindset that's needed and the importance of when you consider data transition in planning your S4HANA project. It's something data that's heavily impacted by functional decisions. And there's many functional decisions in SAP S4HANA projects. But it's also something that can enable functional goals or transformation goals. So although we'll talk about selective data transition, it's important to realise that most selective data transitions or any kind of S4HANA data transition normally also has a transformation goal for data. And because of the changes that are mandatory in any kind of S4HANA project and because the kind of benefits people are normally looking to achieve as they go through the S4HANA project, It's certainly a project that comes with a significant cost, but also significant opportunities as it opens up new technologies that you can connect to SAP and use from SAP as you move to the S4HANA platform. However, data is also something people often leave to the end. We often get contacted by businesses a good percentage of the time after they already have a plan or a go live date without yet having really delved into whether the data transition can support the functional goals of the business. And when this planning is done poorly, it can drastically increase the rising OpEx costs that most IT budgets face pressure from. Whereas data transition planned carefully can drastically reduce those costs. We'll talk about how and why. And so just a little bit about the market at the moment first. This is the kind of wave of projects we've been seeing over recent and previous years. The first SAP S4HANA wave seemed to come for the payroll space. It's a space that our group knows very well. If you know the EPI-USE brand, they are the globally largest private company working with time and payroll in the SAP space. And Labs, although it's not the majority of our business as a software and data specialist, we still have a range of specialist options within our software and our preach payment payroll solutions. And we saw a lot of lack of clarity from SAP at first about how payroll was going to be handled in the new world. There's been talk of whether that would become part of the SuccessFactors brand, and you have SuccessFactors Employee Central Payroll. You also have Private Cloud Payroll, which used to be an ECC and is now based on S4HANA. And we've certainly seen that wave coming through very strongly in the last two years for payroll. Whereas S4HANA projects for the large larger clients, for core systems that have a long history in SAP, we saw those moving more slowly to S 4HANA. And we see that as the second wave, which is the systems that have decades of data in them, the systems and the associated non production and DevOps landscapes that have terabytes of data in them, their move to S4HANA was slower. And now we're starting to see that wave move, not perhaps as quickly as was targeted by SAP at first. And you may have seen that there's further news about the move to two thousand thirty three for different ways of licensing your ECC system before actually upgrading it. But that's certainly a wave we see continuing on for a few years to come. That seems to have come slightly after the payroll wave. And third wave we see is analytics. And we'll talk a little bit about how people are looking at migrating data from large analytics platforms. There's quite a few clients out there with large or multi system even SAP BW or BW for HANA landscapes who are looking at what kind of analytics technologies to use and perhaps don't want to recreate all of their business critical analytics, but rather would want to migrate them. We see this as the third wave, something that's only really just starting due to there being less maintenance state pressure. But each of them has a similar kind of need in handling data. Now what we see an awful lot with these projects is that the functional design is the visible surface. So what things do we have to change in S4HANA in our business? People know a lot about the changing financial data model in SAP. People look at simplification items and what areas of their business will have to change. They may know that asset accounting is going to change. There may be other customized parts of SAP or third party solutions in their environments that won't work in the same way with S4HANA. So there's an enforced level of functional changes beyond what there was in the CC world with the HP upgrades. And so people quite often are looking for the value to the business user quite understandably. However, this often results in a rapid plan to adopt as quickly as possible pushed by maintenance dates and doesn't always consider how data will be handled or how data could be handled within that process. And this often leads to a reliance on semi manual traditional data transition techniques that come with quite a high manpower cost that can potentially sit there rising as a project cost over time. And there's two kinds at a broad brush stroke view, two kinds of projects we're seeing from people who have larger SAP landscapes. The more common is for the core systems like ECC, a consolidation. People often have multi ECC system landscapes that they are unifying into a singular central maybe paired to central instances of S4HANA. Data transition and business process design become a question of unifying processes, which means merging data between systems. That consolidation path really needs a very careful consideration of how data will be handled to enable that system landscape simplification for clients. And on the other side, we also see decoupling. You have the new composable ERP architecture that most people use. With SAP, payroll is normally split out if it isn't already into a separate instance in those target environments. In analytics, you're often looking at a more distributed analytics platform across multiple vendor technologies. And quite often, this means a decoupling of systems. So because effectively S4HANA is such a big question for clients, it comes with the cost driving careful decision making and opportunities that the cost is there because of, it tends to drive decisions about optimizing the landscape at the same time. What this means is the projects are ambitious and really looking to get value for the business directly from their S4HANA investment, but it means the data transition becomes more complicated. Now, in terms of dictating the architectural timeline, what we normally see is that means that in a simple sense, there's two kinds of projects you get with an s four HANA go live. One is trying to work towards a kind of big bang go live. So one or multiple systems transitioning across with a single go live for the business. We do see this and it is something that can be successfully done. But it's a difficult ask for many companies because of the amount of functional change that's coming with S4HANA. The other thing we see is phased go lives. Now this may be multi phase, multi year go lives where the phases are just singular systems, where you have a split landscape and split integrations in between, or it can be the multi phase go live of different companies in a group that all use SAP. So we would call these company codes in SAP. Sometimes people are moving single or groups of company codes from one or multiple Sfour sources into a target landscape. And that kind of multi phase multi year go live can have benefits for the incremental rollout to different business units, controlling the scope of the business change per go live and therefore reducing the risk of each go live. But it also changes completely the different technical approaches you can take to handling data. We would just really encourage any client that's looking at those transitions to always talk to a data specialist, of which we are one of a group of people who really live in this area, to really understand the differences in your data transition automation options for these different kinds of implementations of S4HANA. And by S4HANA, we mean all the kind of S4HANA estate systems. So that may be payroll on S4HANA base. So if you're using SuccessFactors Employee Central Payroll, it actually runs on an S4HANA architecture. It may be your core ERP system, your finance logistics and other functions moving to Sfour. Or it may be an Sfour associated analytics platform. Now one of the core insights from this is that when you're moving to a new Sfour system, you'll probably move into a form of a RISE license. And as things move to more of a subscription basis, the tie in from the start usually means that the amount of data you take in is hard to reduce over time in such a way that you can be assured of reducing your costs. So what data you take to the S5HANA estate right at the first point in design can have massive ramifications for the ongoing OpEx costs running those environments. And this is something that can't be understated. You may know our company also for our test data management solutions, we'll mention today, known as Data Sync Manager. We've had many clients since twenty fifteen when S4HANA came out asking to reduce the cost of a running S4HANA estate after go live. And this is entirely feasible, but quite hard to do. Once you have a technology that can minimize data, it can take months or years to rationalise and minimise your whole state of test and production systems. Whereas if you take a data minimised approach to how you design the target landscape as part of your planning, you can avoid significant costs from day one. The same goes to some degree for embedding privacy and data anonymization concerns from day one, which we'll also mention. Now there are five pillars we'll cover today. We'll try and do them at a reasonable clip so this isn't weightier presentation. Hopefully they'll be interesting. The first is data quality and talking about the importance of planning in these projects for data. Then we'll talk about the automation of data transition, the embedding of data minimization within that automated transition, the embedding of transformation and sequencing that with functional change in a transition, and the potentially huge values of embedding data privacy concerns into how you design the landscape so that those considerations are also part of the data transition. And it is really the automation in step two that lowers the overheads in data transitions such that there is the thinking and design space in your project and your landscape management to consider the last three pillars. So pillar one is data quality. And this is a really important thing for me. Cat mentioned that I do many of these projects. I more manage the people that do these projects now. Maybe when I was the age I was in the photo at the start of this presentation, I did them myself. But I get more involved in talking to clients about what they want, what they need or what their problems are in the S4HANA journey. And quite often the problems I see when there are problems on these projects and there commonly are, are that actually the preparation and data and functional planning hasn't been done to a high enough degree and it causes problems during the project. And for this I want to talk about briefly a Gaelic story. Now most of my family is Irish or Scottish, albeit that I was born in England. And you may have heard of the fable of the tortoise and the hare, the fable that talks about the importance of planning and not running ahead too fast. Well, there's a Gaelic story as well called Benekraken, the bare skinned fox. And it's a similar story about a group of animals in the forest and the large and strong ones trying to push the others around to get the food they need, to get the resources they need to survive. And the fox who took his time and planned and hid from those animals and eventually found a way to survive through his intelligence, his consideration. It's an interesting fable if you want to go and look at it. Many people haven't heard of it. And so I've always think it's an interesting one to mention. But I see these same kind of stories being told hundreds of years ago not being followed in Sfour projects, I think because of the pressure of the maintenance dates coming from SAP. And the problem with that is that if you try and get to S4HANA too quickly, you can quite often end with large project running with lots of people attached from the internal organisation, from business unit lines for testing, from consultancy companies who will then charge you potentially by the time, all attached to a project that grinds to a halt at multiple points because systems aren't well enough repaired and can't go live. And what this results in is a high meter running on the project because things weren't dealt with before the project started. And I think this is a really important concept to consider because SAP are still moving the United States. The ECC two thousand thirty three licensing options are out there now. And although there's pressure on the payroll systems, analytics itself has a little bit longer. And I would really encourage all the customers out there to really plan as much as possible before going into implementation for S4HANA. And we call that today just a few simple things to consider. There's many more than these, but these are things we commonly see haven't been really considered properly. One is the CBI implementation. This is the mandatory pre step. It's been around since the early days of S4HANA to integrate customers and vendors into a business partner data model. It's not very sexy for business value, but actually it's incredibly useful for governance of data in your systems to have a singular master record as a business partner for all these different people or businesses in your system. It's not that large a project. Although some people promote technologies within a transformation for this, I really strongly recommend that people sort it out before the migration. It reduces the risk and simplifies those projects. And no vendors like us want to be stuck on a project that's hitting problems and overrunning. But this is something that doesn't need to be part of the scope of transformation. It should be done upfront. Similarly, there's major changes in finance. The new GL has to be considered. And if you don't understand the classical new GL, it's really worth taking some time to understand it and what the implications are for it. Similarly, asset accounting. All of these things, although they have technical steps to complete them, there are functional ramifications. And so you need to take time with functional experts to consider how those things are handled. Although you can do them during the project because you don't have to, you can reduce your risk by handling them early. Now there are other data hygiene concerns. Financial quality issues in your historical systems or historical fiscal years in your systems can cause problems during the projects. So closing down open items in the systems is a massive benefit to these projects. Also, you check your balance carry forward values, we've seen some people implementing UGL and messing up historical entries. So no problem financial audit, but technical problem in your transformation project. Strategic archiving can be really important. And if you have very high volume transactions going through your environment, this can be very worthwhile. But we'd add that as moves can be selective, if you haven't got archiving set up, it may be possible that it's better to do that once you get to S4 where the method of archiving will anyway change slightly. All of these things that are done upfront really simplify that project. The latency trap we see without that is that if these things aren't considered, they cause multiple stops in the plan. But also, if the functional plan you carefully make then considering those items is laid out in such a way that you then communicate a go live date without speaking to data transition experts about whether that's viable for the data transition, then you may come up with a plan that is not viable. And this is another thing we see. We're often trying to help our clients the best we can, but they say, actually, we want to look at software to help with data transition. And we have to tell them your go live data does not look viable currently in the plan you shared. So you really must not think of an s four transition like an upgrade in the traditional sense. It really is more like a mixture of a migration, transformation, and upgrade all in the same time and space. And it's a unique chance to minimize data. Some people take master data and open items only, and that helps with the OpEx costs we mentioned. Other people take slices of certain fiscal years. And all those things and decisions can change the technological approach to data. So we really, really strongly recommend people consider that. And finally, we'll go into a little bit real data versus manufactured data. Now we're going to talk about data privacy too. This is just a point on synthetic data. Because data transition is hard, we've seen many people set up S4HANA systems for the business and then green light functional testing on synthetic data they've manufactured in that system. Please do not do this. It creates seriously false green lights on S4HANA being viable for your business. You need to test S4HANA a business using real data from your source environment or you won't find the problems the project would like to hit. And so finally, to summarize this in a visual way, what we're suggesting is to make sure that in these waves, perhaps it's a payroll way first and S4HANA coming afterwards or with it, that you really consider a data transition stream. We're quite often brought in client side as a data specialist alongside a functionalist side. We think that works very well. Also generally leads to lower margins on top of our work. It can be beneficial to use us through a partner just like other companies in our space. But either way, I would really strongly urge clients to at least talk to a specialist in this data transition area. It's really a hugely complicated space, especially with the enterprise structure rationalizations people often are trying to bring through at the same time. And I think then if you do this planning right and upfront, then before you get your huge project team or hopefully maybe just a large project team on the meter, you can do planning that will really expedite a successful project and lower the cost of delivering it because there's less people on the meter and working before you've really got the system landscape ready to successfully go live. So be the bare skinned fox is the message. I can't say how much people haven't usually done the preparation. By my rough estimates, I would say eighty percent of clients we speak to really haven't done all of the recommended prerequisites. Although they aren't prerequisites that are business functionality, so the business won't see the value of them. They're technical pre steps with some functional change that if they aren't done will cause your project significant problems, that will then become an issue down the line. So it's pillar two, then the automatization or the automation of that data transition. Now there's certain tools in the market out there that SAP provides. There's still s LS and W and this data migration **** which is developing standard for loading data. You've got BTC now from SAP and we're working with them in Voldorf on this, which is used for carving out company codes direct to S4HANA and will work very well for small to medium sized businesses that aren't too customized. And it's a very nice option free from SAP. Also has a brilliant data analytics piece within it so you can look at what data you have and create a blueprint for what data you want to take. We would use that too with our clients. It's actually very nice. And this done plugged that into AI, but with limited options for how it slices data. There are multiple data quality solutions in the market from the business process tools like Sync Navia having data quality analytics within them to specialist data quality solutions. We focus more on the very efficient movement and minimization and anonymization of data, not data quality per se. And for people with large landscapes, we would encourage them to also look at those data quality solutions. And finally, we'll talk about direct point to point solutions. So true automated transitions, automating the migration of data to a highest level possible for your projects. What you'll see with standard migration techniques is they're semi manual. It tends to be stages where in between source system target, have spreadsheets, CSV files, XML files, and therefore also multiple stage gates of testing and checking data to make sure it's ready to load. All of which are needed because the process is semi manual. Now it is possible to avoid that completely and direct your pipeline data into all forms of target S4HANA systems. It does depend to some degree on whether you're merging them or doing something more complicated and where functional loading is still needed. But it's possible to be selective, whether it's brownfield, greenfield, or something in between. In all those types of scenarios, a selective move can be fully automated that minimizes data. And so what we look at is things like legacy slicing in those systems, the same way we've done for now almost three decades in Test Data. We look at whether there's time slicing. We look at whether there's contract account related slicing. We look at whether there's company code slicing in the system or custom slicing and build automated routines to move data to different S4HANA target systems in a way that doesn't require multi stage checks in between source and target. And what's important to consider within that is automation that can also remap data. So if you're making changes to your general edukey structure or other parts of configuration, which is very common, You have to consider that data must then be remapped if you're to take it and load it automatically into that target system. So we look at where if there's a merge or something complicated, we help clients automate a direct extraction of data selectively from source, pipeline that into SAP Data Migration Cockpit ready for functional loading. Whereas if there's a singular system moving selectively, we can use technologies that point to point, source to target, completely automate the data transition without that need to functional loading. And that can significantly reduce the cost of data transition as well as minimizing data. And the faster you can move the data, the more easily you can get that real data. I mentioned before real data for the first round of testing, for the functional verification of SAP. So I go back to the point of not using synthetic data at this stage to make sure when you sign up s four HANA in all its functional variances working for your business, you sign it off knowing that you used real data from your source environment. Again, I cannot state enough that is not what people always do. Data automation is important and it's different whether you went for that big bang or waved approach to going on with S4HANA systems of all types. Now, we talk a bit about data transformation and sequencing because people come to us and talk about greenfield brownfield selected data. Is that a hybrid of the two? And for us, selected data transition is completely separate from what color of field the project aligns to. The color of the field is to do with business process to me and what kind of business process change level you are considering. No matter what the answer to that question is, data can be selective. And no matter what the answer to that question is, you'll have to probably transform data to at least some degree. So it won't just be a case of transitioning data in full or in part. It'll be a case of remapping data to ensure you can match it to altered configuration. Now you can't alter data in the system that's running in line for the business very easily. But during a transition, there's that opportunity to alter your configuration and remap data as it comes in such a way that you're still completely auditable and you have proper handling of data, but you maybe remap parts of it to meet a new configuration in a way that your financial reports stay the same. But way your enterprise structure is set up is more well aligned to the real world. So there's a non negotiable sequence around this. Once the system is set up, you get the real data in from the source. You inject that data from the source before you adapt configuration ideally. Or if you're making configuration changes, you make a very clear plan with the data transition team at what point you can change config before loading data and at what point you must change config after loading data. It's a really important key part of the planning and again one people sometimes miss. So we really emphasize in that part, please make sure you know for your project the sequence of functional configuration change and data transition steps. That knowledge is very important to everything you do in data transition succeeding. Now the last couple of pillars has to do with areas of data we focus on. The first is data minimization by design. And what we mean by this is to consider production and non production systems for your total gigabytes you hold or terabytes in your SAP landscape. So first, I wanna make sure you have a map that you know. How much data do you hold across the entire estate? And then look at data strata, data layers. What does your business need to perform testing and release a more innovative change of speed? And what's it going to cost you to hold that data? Pull together a few statistics and AI has made this a lot easier. So there's numbers in this that talk about the cost of every gigabyte your business holds. As a caveat to that, we've done AI and website and news research on this. They're only indicative numbers. So whatever your discounts or providers costs are, they may be different to this. But the general trend certainly matches what we're seeing. So when we started in data minimization, storage was getting expensive for clients because they had so much data. So it wasn't that the cost per gigabyte of storage was really going up. Now storage is incredibly low cost. But IT budgets are still buckling and we often get people talking about the cost pressure of S4HANA and general IT costs coming up. Now the metric we look at is how much data you hold. Do you have twenty gigabytes or twenty terabytes rather across the whole estate? Do you have two hundred terabytes across your whole SAP estate? Do you know what that figure is? Because as costs have gone down for storage, this gives you a rough idea of just along the general lines, just how cheap storage has got in general terms over the enterprise. Now for enterprise class storage, it may be a bit more than this. And like I said, these are general statistics. But the trend is the same, that the cost per gigabyte of storage has gone down and down to the point where now quite often a SAP system I would have started working on twenty five years ago would probably fit on the phone in your hand or maybe even the watch in some cases. However, there's other costs attached to data in your SAP system. So you have the idea of parking data where you hold it. It has to go into a backup as well onto the system. But now you have movement costs very different to what they used to be. If you're using the scale and adaptability and AI features of some form of public cloud, you also need to consider your ingress and egress costs from those clouds. And every piece of data you move in will need to be moved out again in some way, shape, form. And this really creates a multiplier effect quite before you get to whether you're going to have additional token costs in AI because you're gonna utilize that data in some way to make smarter decisions in the future. So the cost of a single gigabyte has really gone up significantly. And this bit of research we did suggested four hundred percent in the last period of time since the 90s that we looked at. Some metrics suggest potentially even more than that. What I usually find is people don't know how much data they hold across the estate. It's not just what kinds, but how much. Because much of it is often kept in high cost platforms and really never touched. And that goes from production and down to across all the nonproduction environments. And this is really down to all kinds of paradigm shift. They move to the in HANA database. So in memory HANA database, sorry. The in memory moved created a much higher memory need across the states and although servers and hardware behind our data centers and clouds became capable of holding more memory, cost of memory is recently going up significantly, along with chips. So if you wanna hold most of your data in memory for high performance processing, your cost of data is most certainly going up and that is before the AI considerations. So we're looking at up to about sort of ten to twenty pounds, I think, per gigabyte per month. Once you add all the different considerations, all different costs of holding, moving, processing every gigabyte of data you have in your system. And a lot of those costs are hard to reduce once you set them out on some lease related contract for your ERP systems. And this is some statistics to give you a general idea. This shows to some degree the reduction of storage costs per gigabyte, whilst the costs of your business holding each gigabyte across different overlays, backups, replication technologies, across RAM, across AI token metering going up and expected to go up further. So what you really want to have in your SAP environments is precisely the right good quality data and only that data in the environment. That will help make you more agile, and it will help when we come to the idea of privacy very much also with ensuring that you reduce your risk to the business of how you're handling data that's now covered by many data privacy and stewardship laws around the world. Something much harder to do if you have replicated data you don't need that is potentially sensitive as worse high cost across the environment. So the cost of inaction. You've got data, like it says here from nineteen eighty up to twenty six, what you really want to look at is having a strategic plan for your data footprint. And this probably is a separate thought stream to the functional adoption of s four HANA, but now is the time to do it before you move to these target platforms. And so how do we try and simplify this these concepts? We suggest this triad of value as it were. So to make sure you've got a plan for data minimization in an automated data transition, that you've got a plan for privacy, and we strongly recommend trying to think of that actually part of your S4HANA roadmap, and we'll say why in a moment, And to consider agility. There's many innovations around DevOps and bringing the non SAP world of DevOps type release of change into the SAP world. It's all other topics on that. However, a lot of the problem with the traditional DevOps is matching DevOps to the structured change that's always been an excellent component of SAP and the handling of data within structured change. And so if you plan for all three things, I think you can certainly say you will reduce your OpEx costs significantly, having really planned for each of these things. So finally, we wanted to squeeze in a data privacy here as well, because when you're moving data selectively, when you're bringing in automation for data transition, it can free up the thought space, the head space in your project for planning how to set up your S4HANA state with data privacy already considered. Now you can consider it after you move to S4HANA or before. However, you consider it afterwards, you're potentially embedding a problem that's harder to deal with. And it's a problem that's really growing rapidly in the industry and I think this should not be ignored. So my suggestion to all businesses is to embed data privacy concerns in the S4HANA project. If that's an RFP, put it in there and look for different solutions to make sure that you set up your S4HANA estate with data privacy already considered. Now there's been all kinds of recent lawsuits coming out. Meta's faced the privacy lawsuit as it says just there, Trizetto. There's been quite a number of different cases just in recent months and those are all from the last six months new data privacy concerns coming out to businesses. Sadly, if you've not seen this, do you have in the data protection agreement in almost all countries, maybe all of them now, this statement for you, which is that you should not store personal data in non production environments, which means that legally you as the client are going to be responsible for making sure data privacy has been considered in line with the rapidly growing laws in this area. Now, to give you an idea of where those laws sit, they're really growing. It really started as the GDPR in Europe. But now this is a brief look at all the data privacy laws that have come through different parts of the world. This is an area we really work in. A colleague of mine runs a whole area of this in the business rep use labs, but we often work separately to each other. And what we're often saying over a drink in the evening in some country where we're looking at growth for the business is that clients often suffer from not planning privacy alongside the S4HANA project. It becomes a separate project for them. Now, actually, before an S4HANA estate of any kind goes live, there's a period of time where a project team can consider in the stages of testing, putting in place a scrambling or privacy rule for test data environments that's applied and built into landscape management processes before you go live. What this does is mean that once your business starts running at full speed on those environments, these things are embedded before you have that business pressure on the environment. And if you consider this only after going live, you will then have to make a change to how you're handling data on the s four environment after you go live, and this will attract a much bigger project planning and budget cost for the business. And so the two things are really tied. We found that the data minimisation and privacy areas we work in are intrinsically tied together. If you have less data, the right data, it is much easier to consider privacy on a smaller dataset. And that goes across the entire environment and right back to what I said about planning carefully for the project and knowing how much data you hold. So we should only be a few minutes more. Now this is just gonna talk briefly about our solutions to this space, and then I'll pass over to Ramesh who's going to then talk about how he's helping drive forward faster and faster technology for labs in this area. We should then be done in just the next four minutes, four or five minutes. So we call these solutions and our service line in space Prism. This is our branding within labs for data transformation for selective and automated data transitions to all kinds of S4HANA payroll, VW, VANNA analytics platforms. And it's something I've been leading for the last two years, something rapidly developing over recent years. It's also the same technology stack that we use for mergers and acquisitions, and there can be MLA considerations within these projects. You may know our Data Sync Manager suite. I won't go through it today. It's well documented and there are other webinars about that. It's been around since nineteen ninety seven. It's in its fifth major iteration. It has thousands of clients using it globally now. And actually, what I really want to emphasize here is just how hard test data is to automate. The level of automation you need to minimize test data is incredibly high. It actually becomes much more difficult than transformation because you have to handle it with minimal people checking it, testing it. So it has to be very accurate. And it is those solutions we've taken into the transformation space since two thousand and two. We first were asked to use them for a divestment project. This then rolls into a broad portfolio of transformation related technologies we have. The DSM technologies are landscape transformation versions of DSM with some extra add ons and features like the DMC pump for merging systems together or extraction routines that we can use to move data to non SAP platforms. Then there's our archive central platform, separately licensed, but we can use our same technologies to redirect data to archiving and sunset platforms if you need to refer to that data but don't want to migrate it to the high cost core of the new S4 world. And we also query and variance technologies originally from the payroll space but usable across all kinds of areas. We have our Transformation Engine which is originally from Privacy but now used broadly for M and A and Transformation in Flight to S4. Settle is a code name for something Ramesh will talk about briefly in a moment. And our posting engine is something that helps with high volume open items in finance. Something we don't need for test data space, but this required if you need to move open items between company codes or between systems. If you're taking only open items across, and this engine really helps us handle data in that way, more information on all solutions in the Prism Suite can be obtained from our website and through inquiries with us. And finally, a statement on that technology. I believe we're the only company in this space who has the strength of functional breadth. That means we can automate data transition in the ERP core, know, all variants of HR payroll recipe and the extraction of BW and BW for HANA data and for your analytics wave. So we expect to see continued interesting projects in this space in all corners of the world. It's a real growth area for us in recent times. And there's a small handful of vendors, each with their own strengths. I believe this functional breadth is ours, and it comes really first from the test data space and the fact that we built so much automation for a large client base in that space. But those of us working in transformation benefit hugely from the work that was first done in technology and tested data. Now I want to that point hand over to Ramesh. Ramesh, was just as quick as I can make it, slightly longer than I hoped. But I hope that's it'd been interesting content. But if you can now speak briefly, please, about our roadmap, and I will run the slides for you. Yeah, thank you Jamie. And yeah, it was really interesting content. And then since you've said the already background about what are the different challenges we are facing when we look at the transformation, it is not just one part of it. So literally about we talk multiple things, you know, complex landscape transformation where data is coming from SAP, non SAP, data is coming from multiple SaaS application. And as part of transformation, it is not always one to one. It is cutting across multiple different technology, business, and even integration domain. So because of having these many different challenges and also when things are infused with the AI at this moment, so we also started innovating our product and Prism Suite where we can add new tools and capabilities. So this is more talking about the challenges and which is not just seven. So in the number two, you can see *** meaning there are many more which we can add into this one. So this is the foundation which added our, you know, innovation as a key point which we have to start. I feel yeah. So and then also from this is the second glimpse about when we think about end to end data orchestration architecture or process, we look at the different type of source system, you know, and even when we look at the source system, it is going through different type of object somewhere, you know, it is passing via API, someone coming to non SAP where how do big data clusters are coming even because of decades of SAP presence, you know, more IoT sensors, are also there, which needs to be considered as part of transformation. So it is not just a data. And when we look at the transformation, it passed through multiple different data processing element. Somewhere data cleansing is quite needed, validation harmonization because data is when multiple source systems are coming. Also, when we do with the transformation, how we can govern the complete end to end process. So all these are contributing a key element to our new innovation, which I'll talk in the next slide. Yeah. So this is the glimpse over here where in our innovation, what we are bringing at this moment. So a toolset which is infused with the AI and then that has all the capability to do the data transformation, which will plug and which will kind of any to S4HANA, if I'll say in simple word, where you will able to integrate or migrate data from any kind of source system. Also scenario like where multiple source system needs to be merged in advance, moving into S4HANA system. So all will be managed by this toolset, and this toolset will take care about all the mapping from a d DMC point of view. So we are appreciating even if the customer requirement is kept via DMC because of multiple greenfield innovation and transformation point of view. So it convert the data into DMC format, and from there, it'll the data will get loaded into S4HANA production system. And also, there's another in some of the set where we can load the data using API. So it has both the integration method and apart from that, fully workflow enabled solution. So it will go based on the right governance, right approval, right audit process, and then it will help us to move the data into S4HANA system. But as This is, if I understand or make to make it clear for the audience. So this is a new non ABAP cloud stack that EPI-USE Labs is developing under a new name to be released in May. That's correct, isn't it? That's right. Thanks for adding this point, absolutely. And even when we talk about non ABAP stack, so it has opened multiple different innovation which we are making and adding into that. So thanks for adding that. Yes. So Yeah. So now as part of this product, it is very simple six step process. So when we talk about scope of this tool set, which will able to cover any 2S4HANA system, we have simplified the process only cut across six steps, so it is not going through like multiple setup steps. So just onboard your system, onboard the metadata, all are the process baked into that toolset and also, know, to most extent it has been automated and then convert that data into, you know, DMC format. So everything will be done by the tool set. It is just click, click, click. So in the next I mean, in the six step process, it will enable us to get the data ready for migrating MPAS4HANA system. Yeah, and yeah, we can so this is a similar content, but, you know, we have just added like different source system which will be, you know, contributing for all these steps and applicable. Yeah, we can move to the next. Right. And I think that probably takes us through to the point of hopefully coming to questions. I think the last slide is talking about whether you should engage a partner like us through client side or the SI. I think the question is just to consider both, Both have benefits and to make sure that there's a strategic look at what tools that are out there to help you for this space. I think at that point, it'd be best given the time to look at whether there are any questions. Cat, I don't know if you're still able to look across it if there's questions whilst I'm sharing the screen here. Can we hear the audience? Should we wrap this up? No. So no questions have come through at this stage. This is a new test time that we had to do a little bit later in day than usual. So I would say what will happen is we'll have a number of people that will watch the replay as well, and there might be some questions that come through by email. So that's fine. We can wrap it up here and share the replay for anyone else that wants to watch in their time and send through some questions then. Excellent. Thanks to those who did join us. I hope you found it interesting that the technologies that Ramesh has talked about can also be demonstrated. People would like to see some of the stuff behind the screen, but the concepts are important to consider when planning a project. Yes. So we have something coming very soon. So those that are still on the call, you got a bit of a sneak peek before we announce it more publicly, which is in a couple of weeks. Thanks again for joining, and I'll have the talking sensory shortly as well. Thanks again, Ramesh, and Thank you. Everyone. Excellent. Thank you.