Enhance your SAP data life cycle with Data Sync Manager (DSM)

Hello, and good morning. Welcome to this webinar, enhance your data life cycle with Data Sync Manager. My name is Evan Jones. I'm the managing director for EPI-USE Labs. I've been involved with EPI-USE Labs actually for twenty two years, and for SAP for twenty years. So I'm now responsible for the Northern European business of EPI-USE Labs. Also, it's great pleasure to introduce to you Paul Hammersley. Paul Hammersley is our SVP for ALM product portfolio for EPI-USE Labs. So Paul is a specialist in Data Sync Manager, and he actually manages that part of the portfolio. So, Paul, welcome, and thank you for joining with me today. Good to see you, Evan. Good to be with you. Fantastic. Okay. A little bit about EPI-USE Labs for people who don't know, anything about our organization. So, this is quite poignant year for us. It's forty years of existence, which I think is pretty impressive, in the SAP ecosystem. EPI-USE Labs builds specialist software for SAP, and also we offer respective services on our, IEP that we develop. We've got about fifteen hundred clients, globally, and probably about half of those actually reside in Europe. We operate in almost fifty countries around the world. Actually, quite a bit of our income that we generate goes back into R&D, and we're very, very proud of that twenty five percent nearly that goes back. Multilinguals support. Also, we have a Client Central, which is a online global community, where, we have about twenty seven thousand users actually are on that community. And EPI-USE Labs, I've just been sort of, in the UK and Europe, probably, yeah, about seven hundred and fifty, clients. And, actually, the oldest client we we have is back in nineteen ninety nine, which is Welsh Water, and they're still, client twenty four years ago today. In terms of today's topics, what we're gonna cover is we'll start off with, I think, the SAP life cycle and the demand for accurate test data. Then the need for Data Security Manager solution. Why did we actually create this solution? Then Paul will go through the solution in a bit more detail. What are the components that comprise the Data Sync Manager solution? And then I'll cover some recent client case studies and, business benefits that they derive from deploying that solution on their SAP system landscape. And then we'll wrap up with some questions and answers, too. And then also next steps that if you are keen on deploying Data Sync Manager in your SAP estate, what do you need, what needs to happen there? Okay. So the life cycle, is quite data thirsty for the SAP implementation. And actually, even before you go live, you've now got this sort of this this new era of adhering to data privacy laws. So, essentially, you're gonna have data, in your QA system, for example, which has potentially sensitive information. You're not even live yet. You're you're still doing all your testing. So employee, vendor, customer address, business partner information, which is sitting there. And also potentially authorizations could potentially be Alexa. You also might be using a system integrator to actually be doing your project and they may have access to view such sensitive information. And I think, essentially, this is gonna be an ongoing challenge throughout your life or your SAP life cycle is adhering to data privacy. Then when you go live, you get immediate production system growth. When you go live initially, your production and your QA system look pretty much the same. But what happens then quite quickly is life happens. You have transactions that then start to flow into your production system, interfaces, and start running. And quite quickly, your production system starts to grow exponentially. And, essentially, it then looks not that much like your QA system. And, that's so, again, if you're a manufacturing organization where it's fairly heavily, heavily transaction based as well, you can get quite phenomenal production system growth really quite quickly. Also, production support resolution too. If something goes wrong in your production system, such as you're running payroll at the end of the month and five employees fail, you really want to be, how do I deal with those five employees? I want to really bring back those particular employees that are relevant and bring them back to a test system where I can probably test humanely rather than trying to test in production. You might want to then clone that particular piece of data to then test it effectively and then you can then transport that fix back into production. So that's pretty much very reactive, a very, very reactive scenario. Then I think just creating training systems as well. I mean, you know, we often see that clients that will do that a full client copy to basically create a training system. And, that can be a stage hammer to crack a nuts, because what we find is that how much of that system are you really gonna use for training? Maybe one percent, five percent at best. You then got huge great data set sitting in a nonproduction system, and that data is not scrambled as well. And, that could be a big, big over overhead, and not really optimal. Applying support packs too, I think that's the necessary evil, unfortunately. And again, for maybe for the HCM scenario, those support packs are legal requirement and you want to do proper regression testing on that particular data. You want to test that effectively so it doesn't break your production system. Testing new developments as well. Often development systems do not have a big set of data. The usual approach would be to get the data from QA. So you could transport that data into QA, and that could be an iterative process. It might take you seven or eight transports to finally, you know, and get that correct, which means you've got six chunks of transports that are never gonna make it to production. So you're then gonna have an imbalance essentially of in your transport systems of transport that have not made production. And then new projects, you might have a project track of a dev and a QA system as well where that's gonna need test data to basically be able to fill those projects before they get moved into production. But, also, you might be offshoring that, and that happens quite a lot. You might be offshoring that particular project to outside of European Union. And, of course, that's gonna have data privacy in implications as well. You don't need to really scramble that client before it can be probably be, given to an offshore SI. Mergers and acquisitions as well. That often can happen. Data needs to be carved out from the buying side to sorry. From the selling side to the buying side, then you might want to need to archive data as well. And cloud strategy. You may have a public cloud strategy. And I think, you know, it certainly makes sense, I believe, but in it's gonna be in an optimal way where, you know, you don't really want to have full copies of production in nonproduction systems because, obviously, again, it's a heavy footprint, and you will get charged additional money by your cloud provider. Upgrade testing. Very similar to, support path testing. You need to have data where you can then test through that cycle of an upgrade. Rise of SAP is quite similar to, your cloud strategy. You know, get your house in order before you move from ECC to s four in terms of your nonproduction systems. I mean, ideally, you want to have lean, secure landscapes by design. So, if you did not have that, obviously, again, the HANA appliance costs would mainly make it cost prohibitive, to actually move to, RISE with full datasets in your nonproduction systems. Also, in some setting the systems as well, you might be leaving SAP, for example, you know, you would like to archive that information, and then you may want to use that information at an ad hoc basis. So I think, really, this is quite, it's a very, sort of a potential life cycle and invariably, it's very data, first E and D. So in terms of what are the current available solutions to provide test data, well, I think, you know, the traditional SAP methods have been around for many, many, many years, and they comprise an SAP client copy and an SAP system copy. But both can be merited, but they're essentially all or nothing approaches and have large data footprints and also the data is not scrambled. And I think really quite quickly, for clients, after they go live to do client copies can often just can't be achieved in the window that they require as well. System copy can be quite relevant for particular in a for stress testing, large integration testing, but they're not scrambled as well. Of course, that is particularly important. Now we obviously, most people would understand about SAP TDMS, and that's really, born from their SLO, side of the business. It's pretty much been shoe shoehorned to do copies, where, obviously, we need a staging server as well. But, actually, now it's not compatible with SCPS four HANA systems as well, I think, which is, you know, quite striking. So, you know, myself being here twenty two years, our first client was nineteen ninety, nine in the UK. And clients really, for the last twenty, twenty five years, have highlighted an intrinsic requirement to have test data, which is more regularly your nonproduction systems, and that's on demand, and it has to be secure. And also with less foot footprint, what do I need ten years worth of, data in my test system? What if I could be, to say, really quite granular and quite, you know, relevant? So, essentially, refreshing data from what clients are have been telling us is it's gotta be both proactive and also reactive as well. And, this actually led me now to hand over to Paul. So, Paul, Thank you very much, Evan. So we're gonna talk now about the solution to some of these challenges of having the right data in the right places and trying to make sure that the data you're using is minimal and not storing sensitive data where it doesn't need to be stored. This is based on a product suite that has been around a long time, nearly as long as Ilan and I been with the organization. And it is a solution that has different types of users. So it's not something that every organization will necessarily use in the same way. Organizations can pick and choose the parts that are most relevant for them. It is a SAP certified solution and is also works with RISE with SAP certified as well. Evan, can we move on to the specific components? So the first one is object sync, and this is something we often refer to as data on demand. So this is allowing the functional users, could be business analysts, could be, ABAP developers, could be support consultants within the organization to go and pick up the data they need when they need it and to copy that data typically from production into lower systems, but it could also be from a QA system into another nonproduction environment. But it's something that they can do without needing any type of system freeze. It's not going to affect other users. So this lends itself very well to DevOps and allowing people to get realistic data even down as low as the development system actually runs