Reimagine S/4HANA implementations with a strategic SDT approach

Okay. I think we'll go ahead and get started. Thank you again, everyone, for joining us today. We welcome you to our webinar on how to optimize your SAP data transformation projects. My name is Kris Burke with EPI-USE Labs, and delighted to have you here. Just wanted to give you a few reminders before we get started. So we are recording this session, and after we are, done today, you will be able to, rewatch it through a link that we'll provide. If you have any questions throughout the session today, please submit them through your chat. In the top right corner of your screen, you should see a little box that's marked questions. I'll be monitoring that as we go along, and we will discuss those at the end of the session. And with that, we'd like to let you know about some other sessions that we have, made available on demand. And so you'll see here, you can access those through our partner workspace. We'll be talking a little bit more about that later on in the session today. But you can go out and watch any of our previous webinars at any time at your convenience. So we just wanna remind folks that is available to you. Alright? And as, we move along, I wanna go ahead and introduce our speaker today, who is Jamie Neilan. He's the Head of our transformation services here at EPI-USE Labs. He's gonna be walking you through some great information. And like I said at the end, we will be, answering your questions. So, Jamie, please take it away. Thanks, Kris. Good afternoon or good morning to anyone that's joining from different parts of the world. We're gonna just talk through a little bit today about s four HANA projects and our selected data transition approach and how we enable partners to use a software approach to give them a USP in doing these projects in a more efficient and effective way. And this is a brand we call Prism in Abuse Labs. It's the methodology for using software to effect selected data transitions. Other people call them hybrid or mix and match or blue field ways of moving to S4HANA. But we like to simplify this down to really more of a brownfield or greenfield approach, with the contention that any of those approaches will end up being a hybrid approach of some kind. And so to simplify discussion, we say, well, you know, either you're starting with a brownfield conversion, I. E. A version of your current system adapting to s four HANA, or you're starting with a new implementation of SAP and bringing your data into meet that implementation. Now the idea is that in either approach, it's always beneficial to have a selective data approach to that migration. Almost every SCP client of any size has data that will never be touched again in a transactional way. It's only really there for reporting, and you don't need it to be in an s four platform to report upon it. So whether you're taking a brownfield approach or a greenfield approach, we have a software powered prism methodology that can help you to do that project in a way that data migration is automated, it's derisked, and the data is lean and secure by design, by which we mean the minimum data product for the target system. And with option a scrambling and privacy embedded and with transformation embedded as well so that other project goals can be met, such as parallel mergers and acquisitions considerations or transformations of data. And this is one of the main six hexagons that represent the kind of services that EPI-USE Labs provide. They cover SAP data privacy, security, and risk, which we have a whole another area of software and services, suite of specialist HR solutions. And this selective data transition approach includes payroll and success factors type systems. We have specific customized tight innovations, a way of modernizing subsystems onto the cloud. We provide our own cloud, and we're a partner of other cloud providers. And we optimize SAP data in environments normally through data methods to reduce data footprints, to make data provisioning agile, and to link our software with things like testing automation and to make general development operations in SAP more efficient. But where we're focusing with the Prism brand within EPI-USE Labs is on that purple tile down there, which is on transforming SAP landscapes. And for that, Prism falls into one of two categories for us. Either Prism for technology, where we're talking about selected data transitions to any kind of new s four HANA ERP platform or even to go into non SAP from SAP, And Prism for business, where your goal is more mergers and acquisitions project, a business focused transformation. Although we're focused on s four HANA today, the journey to s four HANA is, usually at least a year or it's a multi year journey for clients. And so most large clients will also have mergers and active acquisitions activity during that period of time. And so we'll have to handle mergers and acquisitions and the Sfour project, all within a parallel period. And so we use the same kind of technology that affects a selective, ETL process for SAP data to help in both scenarios. And we started in this space a long time ago. Our first carve out was in two thousand and three with breaks in the UK. They came to us and suggested our software was so good at separating data. Maybe we should work in the divestiture space. We said okay, and we did that project. We've been in the carve out space ever since. It's the same carve out technology that means we can take only certain company codes to S4HANA. Then we expanded into transforming as the cloud became prevalent in the early two thousands, taking data selectively to new cloud platforms. Around the same time, an energy company asked us to take data from four point five to four point seven SAP, and we did our first selected data transition, albeit that we didn't call it, SDT or prism at the time. So all of these developments, then funneled through into a period where we focused on privacy and transformation. So we have an engine for anonymization, but that is, in effect, a localized transformation technology. And that's taken us into the mergers and acquisition space for things like plant reallocations and transformations on the SAP enterprise structure internally. And these are things often are wanted within an s four HANA project. So people may want to collapse company codes down to equal one legal entity, merge of company codes. They may want to change general ledger key structure. SAP now recommend an eight digit, a general ledger key structure, an s four HANA. And commonly, they may want to change other things that are suboptimal in the enterprise structure, be it controlling area or document splitting types or other aspects of data. And where we specialize is in creating the surgical data solution that automates the provisioning of data into the target system, whether it's a brown or green shell starting point, but still enabling history and data to come in the amounts you want even if we have to remap it to meet that new configuration of the system. So Prism is an approach that helps with both mergers and acquisitions and with how you get to Ansible Hammer. And it's founded on this software primarily, which is DataSync Manager. It was released in nineteen ninety seven, and the four components help, customers every day work with test data systems provisioning, and they're also used with a landscape transformation key within our Prism suite. So system builder lets us build a system with no data. Great for many scenarios, but also building a system that will be a production or S4HANA system once the data comes in separately. Client sync allows us to take a one run extraction selectively from a system. It's where the heaviest weight of our IP is. Within one day, we can put it in your system and extract just data from certain years and company codes. And on day two, that will be already ninety percent accurate. And with slight modifications, we'll get exactly the right selection for your s four HANA system. So this is a highly automated it's not a toolset. It's a software automated approach to go into Escohana built on all those years of mergers and acquisitions and transformation. Object sync lets us copy individual objects, by which I mean a sales order of a business partner, for example. And data secure, as I mentioned, is the privacy engine. Now we can stand up an s four landscape with all the test data systems scrambled from day one. That could well be, something quite attractive to a company with any concerns about data privacy because it's harder to scramble systems used in BAU than it is to stand up a landscape that will always have them scrambled and to scramble the data before we release this for to the full, business. Now those data sync manager components have, thousands of clients globally already using every day. And in every kind of industry solution in SAP and back stack. And that's the foundation of the software that makes our prism set of solutions. So here where we list DSM, you have those same components in the context of transformation. System builder to build the shell, client sync to copy your data with an extra feature turned on to allow it to copy into s four HANA, convert the data to be remodeled to your configurations. So it's selective and transformative. And then to call SAP functions finally to convert data into the s four HANA data model. Then object sync is complemented by object extractor, which means that if you don't wish to take certain data to s four HANA, which if we're involved, there certainly wouldn't be all of it going. This gives us a way to extract data to file so that you can either keep data that wasn't migrated on a file basis or in an archive platform such as our archive central platform, which we've also built as a SaaS service so that when clients use us to take only certain data to a target, there's a place for the other data to go. So you can still report on it, refer to it, but paying a far lower price for keeping it. Query manager, then some people in the watching this may know. It's a technology often used for reporting on the HCM data model and payroll data model and SuccessFactors HCM data model for SAP. It's actually a great extraction technology for data moving from ECC integrated environments to success factors. And so if your s four journey includes more than S4HANA, it includes payroll and success factors, data sphere, and other systems, we have these technologies to also support a selective data transition approach to those environments. Data transform is then our data secure product. It would actually look like data transform used in a production environment, but it's based on the same technologies. Data orchestration is an addition to the suite. It allows us to do selected data transition to SaaS solutions. Initially, SuccessFactors, it's a BTP based app, one that will be expanding for other SaaS solutions. Finally, there's our posting engine, and this is used for high volume finance postings. This is particularly useful when there's an m and a kind of element in your SaaS portal project, such as, for example, moving a key manufacturing site between companies where you need then need to post the finance functionally between different company codes that may be different legal entities. And so this is, another visual for how we use that software. It should be emphasized that client sync especially has been heavily optimized and tuned over the years to run a very precise but also efficient extraction process. We've gone through all of the common, challenges in large systems such as s four HANA systems having billions of rows in the new finance data model structure. So that's less of an issue if you're not on s four HANA yet. We've optimized the software to logically split tables and handle optimization of different database types. So whether you're coming from Oracle or you're already on HANA or you're on DB two or MaxDB or Sybase ASE, We have clients with those databases, so we have optimized this software for them. So here's a brief look at the how the process would look normally for more the brown shell approach to a selected data transition project. And that's where we'd normally start. If a client's unsure about whether they're going more greenfield or brownfields, we would usually suggest that they start with a hybrid approach that is a brown shell copy of the existing system. Why? Because then they can focus on spending money just on optimizing the processes where they'll see a business benefit from the project, whereas a greenfield approach is going to force them to, adopt a far greater range of standard processes, many of which may not potentially benefit the business. And so we think it's a safer starting point, and it may well then prove that a greenfield approach is better. We'd normally start like this. So we do our assessment. We run an automated assessment of your client's systems. This gives us very quickly a fair view of their data that can run-in a rec environment and any related adapt system, that is also in scope for the project. We then build a shell copy of that system with system builder that's converted to s four HANA, and any data is handled in terms of CBI data around this. And then we convert that to s four HANA with our partner company. Any basis jobs there is something we are, you know, more than happy for our partners to execute. We focus just on handling the data. Then once the system's converted to s four HANA, it has its customizing, it has its company codes existing within it, and things like its fiscal years, but it has no master data. It has no transactional data. And this is where we optimize the approach of a selective data transition, taking data from just certain company codes and just certain fiscal years as needed or can be master data in just open items along with a range of other selections that may be useful such as excluding temporary or transient data or data from third party applications that will be replaced in the target solution or e indeed SAP solutions that will be replaced in the target system. Those things can be excluded and put into the extractor file and a profile. The data is then loaded into s four her. And before it gets converted to the SAP new data model, it is held in memory, the entire ECC data model, and we apply that transformation technology to remap any data that needs to change altered company codes, currency setups, controlling areas, configurations so that this can be not just a selective process that can hugely minimize the size of the target landscape, but a transformative one that meets the needs perhaps of the business to fix some problems in how business is set up in SAP during this project and therefore achieving more value. So not only saving money on the size of the appliance and saving money by achieving two project goals from one s four Hannah project. And we should emphasize, I think, there are other ways to do selective migrations without software, with just tools, or with a lot of people. And there's maybe two other vendors that also have software related approaches along with us. But I think we're the only vendor that can also say that they're a market leader in the test data space as well as having selective data transition technology. And that means that we will instinctively build the target landscape smaller. So not just reducing the target production system, which may be two or three or four terabytes smaller, let's say, for a big environment because the approach is selective. But also looking at dev, pre prod, sandboxes, QAS, and systems that just have even less data in them, only certain years of history within them, and no transient data that was retained in production in them. Therefore, if we're saving two, three, four terabytes of production, we hope to save you eight, twelve, sixteen terabytes over an entire landscape. And we certainly have had clients call us before having taken production as their source to build this for landscape and having several instances of the same multi terabyte production system as they do in production, meaning multiple terabytes of data, never that will never be looked at, touched, or used, and it will be refreshed in every refresh process. And changing that, optimizing that environment is far harder to do after you go live on s four hana. Our method will design a target landscape instinctively from a data perspective to have less data at every layer. And I'll give you just a few examples in the next few minutes before we go back to Chris. So this is one of our earliest selected data transitions. It's for part of a consumer goods and technology group in the Netherlands, where one of the big four, operations there was working on big project to integrate S4HANA. And one of their treasury and central systems was going live first, but they decided that the initially greenfield configuration they had needed history. It wasn't possible to just go live with open items and, master data. But it wasn't possible for them to migrate history in with standard tools because they had a different configuration to the source system. Therefore, what we did, we used the software we have to migrate in fifty different company codes. There's a selection of three on the screen. And then to remap millions, tens of millions of records of data to respect the changes they needed to optimize issues they had from previous mergers and acquisitions. In this example, you can see three company codes, a one hundred, b two hundred, and c three hundred. Each has different primary and secondary currencies. The second one has no secondary currency. Each is in a different, controlling area and chart of accounts. But the target aim was to have these aligned to a single controlling area, a single chart of accounts, and to have a mixed primary currency, but the same secondary currency of US dollars on every one of these. So we not only updated history, we even wrote in historical line item values against these currencies based on the valuations that the accountants gave us. So a lot of functional changes made where data was selective, but maybe even a bigger benefit than the platform cost savings, was the changes that we enabled that previously were being stopped because data couldn't be migrated in with standard tools. Now as I said earlier on, our software is great really because of the test data space. So although we've been doing transformation since two thousand and three, it's the vast number of test data clients that make it possible for us to address many system types. So not only can we do selective data transition with Prism for S4HANA, we can do it for payroll as well. And whether that is a PCE environment or an ECP environment or an h four s four environment, Whatever flavor of SAP payroll you're moving to, the software can also move data selectively direct to those versions of SAP payroll. And finally, our technology has also been around for a long time for SAP BW and for SAP BW for HANA. And we've done quite a number of projects here and there on things like separating and splitting companies in mergers and acquisitions environments for BW and BW for HANA systems. The way it works is that the same software goes in, but instead of giving it a certain, company code or time structure, you select certain characteristics in a cube, and it will slice the data, into all the preceding data store objects. So you get a consistent slice through a BW type system, whether it's your previous DSO or your, a DSO structure that goes into BW for HANA. And then data can be copied excluding by time or finding the company code, excluding the company code or excluding specific cubes as data is copied. And our vision for this now is to work with it so that it can also be a selective transition method for the data sphere bridge, which is in effect, BW4HANA system. They don't need the bridge, if you go in with a sort of greenfield load, but if you are going to need data from historical BW or BW for HANA systems, this enables you to automate also a selected data transition approach for data sphere bridge. Now finally, the way we start, if our partners want to go and look at a requirement for a customer, we provide two things, an automated report that requires no SAP notes to go in and is backwards compatible to quite early versions of SAP and the solution architecture team that then can come in and talk with you and your clients about their requirements. Now if they put this report into their system at the moment, they want to probably run two things for an S4HANA project. They have an SLOA that will give us the enterprise structure, showing such things are on screen here. And that will show us the company codes, but also how well the data is adhering to the normal way that it defines where a company code exists. And that allows now it's just a very quickly see how simple it will be to copy company code data from, the source to target. And then we would also ask for the s four HANA, and that's just to be run because we're looking normally at both m and a and s four considerations. And that will go a bit more into the accounting data history, the open items in the system. It will also tell us about the CBI data, the customer and vendor integration that's required for the system. It will tell us if the new GL has been fully adopted, which is another mandatory step for s four HANA. And so these are all useful things that can lead to a conversation about what a selected data transition approach could look like for the client and what it can mean in terms of data reduction on top of the initial data reduction that the S4HANA platform will give them. Now the final slide, I think, before I hand back to Kris is just another example. I've shown you one before that was more of a selective data transition to a hybrid system. And we also have done a pure greenfield solution for, a leading transport provider in the UK in recent times. In this instance, when it's pure greenfield, we don't load data mostly to the target system because, a, if it's real public cloud, you can't. You have to go through some data services. If it's private cloud, greenfield still you're better to load data functionally with SAP data services, although, we do load data that is problematic for SAP data services in that instance, such as large files, say PO attachments. However, there's still a problem for clients, which is how they extract selectively data from the source system ready to load its app data services, which doesn't provide a way to selectively extract easily the data into the file format of XML normally that data services requires. So here we've been the, extract transform and partial loading partner and providing a way to automate that process for this company. So there's software and technology, whether it's more the greenfield end of the spectrum or more the brownfield end where transformation is minimized, but there's still a value in minimizing data and applying some level of transformation to it. And with that, Kris, I think I've just about hit the mark on timing, and I'll hand back over to you for the partner workspace overview. Great. Thank you so much, Jamie. Very informative. Thank you, everyone. Before we jump to our questions, which we do have a few in the queue, I did wanna remind you of our client central partner workspace. This is a collaborative portal where you're able to go out and find out more information about Prism for s for HANA and all of our other products as well. And in addition, we have some, you know, news articles. And, like I mentioned earlier on, the previous webinars, you can find the recordings out here. And when you do run across that opportunity for Prism for S4HANA, there's a way to register that lead with us so we can review it with you, and that is all available to you on the partner workspace. And if you're not familiar with it, that's okay. Reach out to me. Happy to walk you through it or hold a session for your organization as well to explain to you how it works. So it's a really great tool to have at your fingertips, and I do wanna encourage you to take a look at that after this session. And with that, so I do have a couple of questions for you, Jamie. So, if you don't mind, the first one is, which industry verticals or company sizes, really are best suited for this type of approach? I think in terms of company sizes, if I start with the second part, I think it's anyone certainly with kind of a terabyte plus in system size. I think for smaller companies, it can still provide a value, but it's a smaller value because a lot of the value in the software is minimizing the data on the target. It may be those clients if they also have a small system want privacy embedded, which still could be a reason to use the software. But mostly, it's the large and very large systems. With those systems, the data reduction itself could almost pay for a large proportion of the project itself. And there are industry verticals. Usually, the industries with larger data footprints can benefit most from this software, but there are specific industries with different data models such as utilities or oil and gas, where they have things like contract accounting data structure. Because the software's client base is so big and test data, we do have versions of the software for most industry solutions including those ones. So the same approach can still be taken, except you might have a question like, can I take all of the, different contract accounts from this state in the US only first, excluding maybe other ones that we no longer service? That would still be possible with the software. Right. Okay. Thank you. Next question is, how do we ensure data consistency and integrity during this transition? Basically, by using a software approach because it means it's completely repeatable, and we eliminate human error by configuring all changes into the software and then effectively by testing well the target system. It is certainly true when it's selective. You can't make such a simple calculation as the same number of records from source and target because they are, of course, different, having been selectively moved. But because, we run a clear methodology around the project with our partners that is, very precise and almost military in its precision, anything in the raid log and the issue log that goes to a change in data selection is then configured in the software. So it's not a an Excel sheet we've gotta go and look at and track the project. We've build the changes in, and then when it gets to production go live, in fact, we just have to press go and make sure Basis is watching system performance. Great. Alright. We have time for just one more question. What are the estimated timelines and resource requirements for typical projects? That's hard to say. The projects normally run from I guess the quickest might be something like nine months for an S4HANA project. But a lot of that depends on how well prepared the system is. Other projects I've seen, you're looking at one years, two years, sometimes four or five. But like I said, there's so much change that's possible within the process that quite often the timelines extend once they realize what other benefits they could get whilst they move to S/4 HANA that are best done before they go live. And then like I said, the larger companies are also, if they're private companies versus government, probably gonna go through mergers and acquisitions and need to make a plan for how to build that in as well. So our smallest footprint of people is three, project manager and one and a half consultants essentially to do all the data work, and that extends as more complex variables get brought in. For sure. Okay. Great. Thank you so much, Jamie. For anyone else who has questions, we'll attack those in a post session for you through email. We will be providing you an email with links to the webinar as well as, you know, that link to the partner workspace, but we're very happy to have you today. We thank you for being our partner and your continued support. Really do appreciate your being there. And if you have any questions at all, feel free to reach out to Jamie or myself, and we'd be happy to set up a session with you one on one. So, again, thank you so much, and take care, everyone, and stay safe out there. Thanks, Kris. Thanks, everyone.