Real-world SAP transformations with lean SDT and PRISM: targeted, business-driven approaches to selective data migration

Everyone, and welcome to our webinar. So glad to have you here. Today's session is real world SAP transformations with lean, f d t, and prism, targeted business driven approaches to selective data migration. My name is Sarah Enders. I'm on the marketing team here at the US Labs, and we're so happy you can join us. We are recording the webinar today, so we'll send it out, after so you can view it again. So we have, two speakers with us today. First, we have Jamie Milen. He is, with FPU's Labs, and he's the, SAP transformation global service line leads. Jamie has twenty years of SAP experience, and he specializes in prism, which we'll talk more about today, and SLO, leading global projects, focused on data and transformation. Also joining him, we're thrilled to have a special guest, Thorsten Spillman. He is the head of business development, for BTC at SAP. Thorsten, super excited to have you with us today, so thank you. He's joining us from Germany today. So before I hand, hand it over to the speakers, I just, wanna let you know that we'll wait until the end of the session to answer any questions you have. But throughout the webinar, just feel free to type your questions into the GoToWebinar control panel, and we'll take those at the end. So I will go ahead and turn it over to you, Jamie. Thanks, Thanks, Sarah. I should've probably should've shown the, the pictures of at least me looking about ten years younger at the stand up there. So, as you said, I lead the, the transformation service, Milena Labs, but we'll come through. We're as you said, we're honored to have talks to here with us, who's really a specialist in this area for a long time, for SAP. But we'll hand over to him to properly introduce himself for BTC in just a few slides. The point of the agenda today is to go through, the status for the s four journey, what is selected data transition, and what is the options or what are the options the clients are looking at, so that we can position how you can use a group of unified softwares to address that project, what SAPBTC can do for you, and why SAPA created it to help with the s four journey, and what Prism is, and what Labs have created as a range of solutions that can complement, BTC with our software and our knowledge of this space. And we'll come to a case study to give you an example of real world transformation. And we'll talk about how this applies to both, two key functional areas, the core of the system, your company codes and finances and sales distribution of materials, so on, but also the HCM and payroll side that our software helps to, complement BTC in. So who I'll be as Labs is where we'll start. You'll all know SAP, I'm sure, but not everybody will know Epiuse Labs for this particular space. But Epiuse is one of the oldest partners of SAP. We've had a relationship since late eight late eighties and early nineties when we started in the HCM space for SAP. And since then, we've become a gold partner. We're both a sell and a build partner of SAP. They're parts of what we call in their group Elephant, which used to be known as the EPUSE Group. And Labs is the software heart of the group. So we build software and then use software to do specialist kinds of projects, really just in the data and privacy and transformation spaces for SAP clients. And that's grown out of the initiation of our business as a software company first. Many people will know us for our data sync manager product, and it was the basis for our transformation suite called Prism emerging. But there's a few other project products we use with DataSync Manager, to enable Prism transformations. We've got over eighteen hundred clients in the SAP space, all SAP clients that use our software and services worldwide for rep b e s labs. And a lot of our revenue, over twenty three percent, goes back into r and d activities. I've got a large development center that's in Pretoria, in South Africa where the company started. But we also have key centers in Boldorf in the Parton port in Germany, in Manchester, where I'm sat today, just between the Old Trafford Cricket Ground and Stadium, as well as in Atlanta, South America, and Asia, Australia, New Zealand, and also with people in Korea and Japan. It's a broadly spread but specialized business. And this is an idea of our global footprint. So in recent years, we've been really focused on the European region and Africa for growth and transformation projects. That's been going since two thousand and three when we were first asked to use our transformation capability and software to come out of the test data space and also create environments selectively. It was for a food company in the UK, for which we did a divestiture by company codes in the year two thousand and three. That really expanded the European operations. But recently in the Americas and in Asia, Australia, New Zealand, Oceana, in recent years, we've also gone into transformation much more vigorously in those regions. And because our origins of the business are a payroll origin, a payroll is somewhere where you really need localized expertise, we have a very broad geographical base with consultants all over the world. So it's a really diverse company as well as being a software focused one, but one that really has the majority of its transformation now in the in many functional areas from the core of S4HANA through to payroll, SuccessFactors, Datasphere Bridge, and other such environments where our software can help to initiate transformation, mainly because so many clients use our software first in the test data space. So we're gonna start with a poll, and it's all about what kinds of data you are thinking about taking to S4HANA, assuming you've not gone there already. The art the answer is meant to be a little bit of a hard one. So we might have to think about it for a moment, but we really appreciate you doing so. And, I won't try and talk through it. I'll just see if you can read through and see if something speaks to you. See, see what people say. Our focus is, of course, primarily on data, but your approach to taking the S4HANA journey really affects the data options that are open to you. Go about thirty five percent. Sarah, don't we just give that a minute more and we'll come back to that in terms of the kind of options, what it means for data migration a bit further through the presentation. We find that some people misunderstand sometimes the impact on complexity of data migration depending on the particular selection for data they make. Sixty five percent. So it looks like over half want to have new config, but keep current processes primarily, but with selective data. So I'd call that more of a hybrid like a brand shell approach. So leaning more towards mostly brownfield processes, the way I talk about it, but with targeted change and selective data to minimize the data footprint. We've got nine percent on a pure more of a pure brownfield, but open selective data. Eighteen percent with minor process changes, only nine percent, indicating greenfield. Nine with no interest in, selective options currently. I guess, Sarah, maybe if we close it there, we have enough time for people. So, yeah, that's interesting. We even find in many projects people change their mind, even in the first few weeks of the project, and switching often to a more greenfield approach from Brownfield. But it depends on your requirements and the number of systems in scope. So why move now? And when we ask this question, we're really thinking about more than just your core ECC environment. We're thinking about payroll and BW, for all of which the end of support dates are quite similar. Although there's a few extra options for payroll, and there's the PET options coming through for SSAT licensing, really, there's pressure for everyone to look at how they move now and every delay basically creates technical debt. So although it's a new problem for us for Hannah, the idea of technical debt from not upgrading and maintaining systems has always been there and has always caused a lot of the same issues from security to outdated processes being there. And then when you do choose to make the move, the larger the gap, the higher the cost and probably the higher the cost versus smaller amounts of projects. We certainly think that now the time is the time to move, but that selective approach can always help with the cost and the return on investment for that project. So writing the same customizations twice is always a concern. Missed innovation is really a concern for clients. We are finding that, some clients really are going pure greenfield and are willing to try and go completely back to standard. For many businesses, they have to keep customized processes, whether they're already moving into BTP or not. The hidden cost of inaction is quite large. We're here to basically say data migration can be de risked, and there are lots of software options out there to help you be able to take data selectively no matter which approach to the Sfour journey you're taking. And that can be quite highly automated And to clarify the cost of additional, options, so, is there a difference between master data and open items versus two years of history? That, for example, is actually quite a big difference to the complexity of data migration. And the most people will be looking at one of these two journeys, the rise with SAP journey or grow with SAP. And as grow is for new SAP customers, it's not including a data migration from a legacy SAP system anyway by default. You're really looking at mostly if there's a sample source, it being some kind of rights journey. And as a software provider on that platform, we can offer both tools to complement BTC as options to get to your RISE platform. But our software in the test data realm, which is the same technology base, is also certified with SAP through to twenty eight and certified with RISE. So giving you options to derisk, minimise, and secure data during migration, including anonymising it, and to manage and minimise it in day to day operations before and or after the migration. So in both scenarios, tools can help. With BTC, you have options across the board. I'm sure with SAT anyway. With Prism, we're really focused on right specific journeys. I think that will mostly be the case with BTC as well. And so this is a little bit wordy, this slide. I'm gonna go, backwards and forwards, but try and keep this one relatively light. The point to ask about what selective data transition is to try and break the idea of the wording being too simple. Sounds very obvious. It's simply taking data and migrating it, but selectively. Yet we find it's actually something a little bit more than that. People sometimes assume that a selective data transition is something that happens more towards a greenfield or hybrid type approach. But, a, you can take a Brownfield approach and be selective because you can automate it with softwares. But also transformation, is a word that really should be in the thinking of an SDT project. Because as you separate the data migration from a technical conversion, you create the ability to alter your configuration in a system and remap data to fit it. So if you want to change your general ledger key structure or your company code arrangements or even the currencies you have assigned to company codes in the system, it is still possible to bring your history into that system, because you can use softwares to transform data in flight, not just to move it selectively. But what options you require mean you need to pick the right mix of solutions to most effectively deal with the scope of your project. And we're here to help you pick the best mixture of solutions to do that project. In the past, that really meant picking a vendor, SAP themselves, or Repucelabs, or one of a handful of other vendors who specialize in this area. But now with BTC, there's more in the SAP toolbox to help us. Us. In the past, we would have used Data Migration Cockpit and LSMW and a number of SAP built tools anyway for specific, kinds of transformation. But BTC really gives you something in addition to look at using the PTP platform and modern data modeling techniques to look at additional ways that you could potentially migrate data, without having to consider it being such a complex task. And so when we say in this slide, we think Greenfield and Brownfield fall short. I think it's an interesting point. Almost every client in recent times that we speak to wants some kind of hybrid or selective approach. To me, this makes sense because for a greenfield, it's a huge company project in most cases, to go back to some kind of vanilla system. It would usually mean moving all your custom code to some kind of tightly coupled or BTP solution, but all within one project. And so it's a bit misleading to think of it that way. And I've been working in this space actually twenty five years now. And there was many, pre S4 project where going vanilla on ECC was also a target and, really turned out the same way as originally stated in the early project meetings. Brownfield, it's a technical conversion. So it is simple, but many people have a long history of data in SAP. Much of it never referenced or used for years and years. Even if you need it to be there, much of it you don't. So even if you take a purely Brownfield approach, my contention is that is a business process choice or a change in cost of change choice. It is still quite simple to selectively move data without having to interfere with the business. And therefore taking everything across in a brownfield conversion to our mind is to make a choice to carry a lot of costs you don't require forward into the s four HANA world. So whilst we do position the difference of greenfield hybrid and brownfield conversion like this, and we do use different solutions across the patch, and are looking at testing at how we use BTC alongside our prism solutions. Actually, our contention is more that we would encourage people not to think of hybrid as a separate approach to greenfield or brownfield, but rather to think about how much change they require in business processes. Branfield being almost zero business process change or as little as you can manage from what is necessary for S4HANA. Things like that. And the new GL being necessary, for example. Greenfield being totally trying go to a standard middle of the process and to actually further get about selectivity of data being something separate from that, but rather to speak to a specialist about if you have an interest in selective data and bringing lean amounts of information across that you aren't tied to one data strategy dependent on the type of field that you're targeting for your system. Now business transformation center is something we heard about a couple of years ago. We've spent a few days involved off with, different parts of SAP from our offices there. And it really is quite an interesting, initiative. So at this point, I'll just say what we see from it, but then hand over to the expert here who we're happy to say is joining us from SAP today after some interesting challenges, testing out GoToMeeting together here today. But being a purpose built solution for getting you to S4HANA, was particularly interesting. A lot of the tools that Saba built in the past are incredibly useful. Desktop tools, very powerful. Things like LSMW, data migration cockpit in the hands of a consultant are incredibly powerful but do require also expertise to use correctly. BTC seems like the first effort to automate at a higher level data migration in a way that's very human readable by, almost a less technical user. And so it's something that interests us very greatly, and we're looking at how we can, integrate it, and build not, to replicate, but to complement where SAP are building. And perhaps at that point, I'll hand over to Thorsten, to speak for SAP and PTC himself. Thorsten, if you can see my screen, I'm going on to your first slide showing how you accelerate your customers' kind of transition. Thank you. Yeah. Thanks, Daniel. And welcome also from my side. So I'm Dustin Spielman. I'm based in Waldorf, and I think also over twenty years of experience in consulting. So I run large customer, transformation project for SAP service in the DMLT SLO space for many, many years. And now we moved on with a couple of people from consulting to development because we identified also here that for sure, there are some standard tools available for conversion. There are standard tools for new implementation. But there's no solution beside the service approach from SAP for the selective direct transition view. And that's why we started to build on, the SAP business transformation center. And we moved in an organization which already developed the migration cockpit for the new implementation and the software update manager for the conversion. So we complement now the portfolio for the transition of our customers here in this, area, which is called cloud lifecycle management. And so that's why the SAP business transformation center is much more than lean selective data transition. For the lean selective data transition is one part of this portfolio. You see here, it's a unified transformation methodology. Just on very short, we start always on top with the data driven analysis of the system in combination with questions because pure on only on data, you will never derive the best transformation part because there's always a business goal on top. So you're on the history. You cannot decide what's the best for the future. Yeah. So it's a mix of both. So and based on this, we give a recommendation what could be probably the best, transformation path. Then integrated, in one methodology, we have the scoping where you can then decide which data, for example, is relevant, which data I will take over to the new system. And so it's our digital blueprint, so called, which is was the first feature we released here. And, based on this, you can really make all scope decisions for the project and automatically start the project then, the conversion project or the migration project. Next steps, we streamline system transition. For sure, if you are on prem, for example, with ECC, you, at a certain point of time, you had need to move the system to the cloud or to our RISE environment. And, therefore, we also created a special tool called WIP system transition workbench, which guides you, with all these steps needed to move to the cloud. Yeah. And then for sure, we have to do scenarios. I told you system, conversion with the software object manager, lean selective data transition for the selective data transition approach, and the migration cockpit for the new implementation. And last but not least, independent from, any kind of project. At the end of a project, we know if there's a go live. There's always this kind of go live deficient. No go, no go. And, therefore, we provide now tool. It's called data transition validation where we can really then also, validate the correctness of the business data based on standard reconciliation reports, for example, for open items or balances and all the stuff, know, our dealer, all this report, standard report from our LOBs. Yeah. And this is also automated, and we all included this in the business transformation center so that we have a unified methodology. Yeah. Next slide, please. Just need now, you see here based on our experience, I told you, we are a couple of people from consulting move to development. We collected all our experience. So what's necessary independent from the kind of project, even in, independent if it's four or if it's Ariba, whatever. At the end, if you have, a successful solution, you all have to get access to the old stuff to analyze it, to profile it, to get all the insights of the solution. Yeah. You have to make the efficiencies, which data, for example, is necessary, which processes need to be changed. You have to pro write the data. This means deploy the data, so migration. And at the end, as mentioned before already, you have to confirm the correctness with the validation tool. Yeah. And all these steps in one solution and the business transformation center orchestrated across all the different steps. So one entry point, it's not like before. You have here a readiness check. You have here the migration cockpit. You have here the validation tools. So we our goal is to integrate it everything into one flow, and you can orchestrate it from one central place. And maybe to the next slide, please, Jamie. The idea behind this here that we provide this solution, our central transformation platform, which is meanwhile the SAP cloud, LM solution here. So, you know, also Verizon of its moment, meanwhile, really the central platform, current platform, where you have the right dashboard and all this stuff. And so we developed the SAP business transformation center on top of cloud ALM. We want to reduce the complexity, and we want to speed up here also the transformation approach because we know it's for many customers, it's really a pain, a lot of effort. And, also, we want to streamline the process. I think, Jamie, you mentioned it before. We recognize, okay, there are processes we can really easily stream and automate. Yeah. Because we know there's also bottleneck for the expert in the market. And I think there are other tasks which are still necessary up front or afterwards or whatever. Yeah. We can make use of this expert better than for the, you know, standardized process that we could also automate. Yeah. That's more of a goal to really automate and speed up what's possible. Yeah. And to reduce this bottleneck. Yeah. So overall, if you speed up a project, if you need maybe for the migration, analyze this part, whatever, left expert, you can also, for sure, lower the cost of the implementation. And if you have the standardized tool, which is really guides you, there's no left or right. I will explain it in a couple of minutes. Yeah. For sure, you have also this repeatable group reliable results. It's not like, yesterday, I had consultant a. He knows it better than b. Whatever. Yeah. It's really it's an automated process with clear boundaries, so it's repeatable and reliable. And for sure, it's part of the Cloud ALM platform, we follow the terms of use of Cloud ALM, so it's included, in the service subscription or a cloud service subscription or enterprise support or, for sure, if you have a wise contract. Then you get Cloud ALM, and with CloudLM, you get the business transformations handled for free. Next slide, please. So what did we do here? I think it also resonates somehow with the poll we had at the beginning. So we said, okay. For sure, SDT, as Jamie explained, has a lot of different flavors here. It's not one shot and just selective. You could also, include transformation topics there. You can do mappings there, reorganize somehow the process or re redefine the process, and you can support at least to a certain point of, you can really redesign the process. So it's not one hundred percent. Yeah. Sometimes you have also to do somehow a mix of posting and, migration. But, at the end, the FTT has a, different flavors here. With lean selective data transition, we offer a standard approach which is scalable and available to for the market, not for experts. And this means our starting point was when we released the first end to end scenario, it was you can select company code because it was, let's say, the MVP for our product. You can select for example, you have some, yeah, old, company code, which are not used anymore or maybe the business is already sold a cup many years ago. We know if you do a conversion, you just take over all the stuff. Yeah. And if it's still in the system. And so we said, okay. First, topic is you go to the blueprint, collect the company code we want to have. In the blueprint, you have a lot of information about the usage of the tool, of the company codes, data volume, and all the stuff. You can select it and, deselect the company code you don't want to have anymore. So this was the first one. And begin of gen end of January this year, we released the time slot, which is very powerful because now, you can add, the second dimension on the data reduction keys. Yeah. You have the company code for sure. You see on the third pillar, the time slot is the fourth, and you combine both. You can really heavily reduce the system size, which means at the end, you can avoid cleaning up all data, for example, which would be necessary for conversion because you have inconsistencies and all this stuff. You can reduce the system size. You will save money. So it's not only TCI, but I mentioned before, it's also TCO. So, also, here you have a big benefit. At the end, it's really, a very powerful method to reduce the system size and to only move on the data you need for your future business. So, also, I have to have force for sure for, you know, the buzzword AI here. You have the future, solid foundation for your AI. You don't need to train maybe your LLMs on very, very old twenty year old data. Yeah. That's why all the year you can really, in terms of data, also work in the direct super clean core. So, next slide, please. I told, you actually the scope, miss, company code and time flies is data reduction. You see that, the blue colored so the dark blue colored, boxes are already released. Actually, what's planned for this year so we are still working on further topics. We have the domain mapping where we can apply easy mappings, one to one more mix mappings, for example, during the migration. We now release a tool because we recognize some part of customers didn't have problems with creating a shell, you know, for the standard SDT project. It's always a, a shell conversion approach where you build up a shell based on your system as a target system. So we release here also soon a tool in October or September end of September to create a shell. And then the bigger transformation topic now, which are also on the road map and actually, in testing and final development is the chart of account unification where you can really harmonize the chart of accounts and the account to lecture approach where you can move from the account solution to lecture solution here on the fly. And that's it more or less from our side for linear at selective data transition. What we cannot support, and this is something here, Jamie, you are also expert in all this, mergers. So consolidation of system, five system in the one, which is also a big, climate from our, customers, if they have a big landscape. Or even, we can also not support this, kind of phased approach where you can go company code by company code, for example, live and not in the big bang. Yeah. So this is the road map on the inflection. As mentioned, it's only one part. We have a bigger road map for the business transformation center at all. And maybe final slide, Jamie, I will speed up here a little bit to save some time. Number twenty one. At the end, as mentioned before, just a summary, you want to forward your transition, reduce the complexity, and speed up the migration project. This means also we want to, reduce the TCI and, to make it much cheaper to move to the to the cloud, especially, you know, SAP is also I think Jamie mentioned before, pushing for sure end of maintenance, pushing our customers to cloud out. That's why we want to make it as easy as possible. Yeah. And we want to guide it, as much as possible from finding the right approach until, bringing the data over and validate the data. So this just means as much as possible guidance from SAP. That's what customer asking for. You are SAP. You should know the best. And this is, let's say, our main goal as a business transformation center, make it easy, straightforward, and as much as possible guidance here. And for sure, also cheap as possible. With that, I think, there are more topics as mentioned before, more complex topics. This is not something we cover in a standard tool. That's why we need experts, and that's why there's Jamie with the prism tool here. Handing over back to you. Mason. Thanks, Austin. Yeah. It's really, really interesting to watch that. So I remember going to see Orlando two years ago to Sapphire and seeing that released, and it got an awful lot of, attention in the room. Yeah. It's really interesting to see how it's developing. So I'll talk then about Prism Press for HANA. So this is our solution set and methodology for using Labs tools and technologies to help clients complete a transformation journey, which we'll now use in combination with BTC to find the best solution for clients to choose use Labs as a data partner in their journey to these platforms. And the idea is to I mean, always for us find the best way to get clients to the target to their goals effectively. Best TCI, best TCO is absolutely the goal. It's been that way for Labs for a long time. And the way we do this is very different than how SAP have come to focus on transformation and bring that consulting experience in. We've come from a test data space that started in ninety seven. We're using the experience of software developed across a very wide client base of SAP, businesses who use the software to then use what we've learned in test data and building software in very large scale to a transformation scenario. And it's interesting that test data is actually harder in some ways. Quite often, you don't have a big project around building a non production system. So you need high levels of automation. Because we've been pushed in so many directions by our clients there, we have very good coverage outside more than just the core. So where we would see ourselves as particularly, useful alongside BTC, as Torsten says, we do a lot of things like merging and splitting systems apart, adding in separate waves and those places where you have something like a posting engine for handling finance and assets. We have a pipelining technology for SAP DMC if we're merging systems together. And but we also have data models that cover more than just ECC and S4HANA. We have versions of our software for payroll, which quite often is going to ECP in the cloud alongside SuccessFactors at the same time as s four HANA. And, actually, that's another kind of selective data transition because the new payroll systems don't have the same kind of organizational data that old payroll systems have that now exist in SuccessFactors. So you can have a triple target. You may have one ECC system, and it may have been multiple of those, but you could still have s four HANA ECP payroll, and SuccessFactors, which are three technical systems, all as the target. And our software can handle, all of the system types alongside PTC. Now we also have versions of this that can handle BW, so we can select move data and transition it into the bridge for Datasphere. We can handle contract accounts and utilities, and we have all kinds of data models from other clients in areas like defense and oil, student life cycle management, many others we've developed over the years. So we really look to bring that experience, out of test data and privacy into transformation. And that's where we think we can merge our technology together with BTC. And in these projects, even with the simplest scopes, I'd also say there's a very specific project planning you need to do around these projects. If you're taking certain years of history, you need to know the impact of taking one or two fiscal years versus four or five. And you need to understand technically the impact, but be able to have the conversation with the business. And that's some of what we think we can help our clients as well. So the reason we say then derisk is because these other aspects then tend to come into the story. You think it's one system, but then there's payroll, and you realize it's coming from the same source. But success factors is coming in as well, and then there's BW. Quite often then as companies start to look at the target, they look at things like, what BDC team are working on, the chart of accounts rationalization, the integration of different currency setups in the target, the change of general ledger key structure or document splitting types. There can be a range of marginal new configurations that may on may not be changes to the legal structure of company codes in the system, but the companies want to have set up an s four HANA. So not necessarily greenfield for processes, but maybe a rationalization of a company and enterprise structure that has been inefficient for a very long time, and potentially affecting things like fiscal reporting, auditing, enterprise, and business strategy coming through out of the data that's in the system. And these are the things where our solutions can complement the SAP solutions to help build the most efficient plan and to derisk and automate as much as possible the data transformation solution. I think this slide is what I'm already speaking to. But, basically, bringing software to each of these spaces to help get to the target system. BW can be particularly interesting as well. It's not often talked about in these sessions as well, but some customers have one or two or three ginormous BW or BW behind systems with many, many cubes and lots of layered data. And although there are standard migration solutions for that as well, taking it selectively and moving it to the bridge for data sphere can be complex. You might want to slice BW data also by enterprise structure, but there isn't a native enterprise structure in BW, so you need to find it, which our software can also do. You might want to time slice VW. But if you time slice it, you may want, for example, a longer time slice in VW. You might take two or three fiscal years into West Forana. But if you got twenty years of history, you might take seven years in VW if you VW, for your analytics. You might never need to reload that from your transactional system, but your analytics system might want a longer slice. So these sort of things, are things you need to understand from day one. It doesn't take too long, usually to go through and understand what would be best for your business, but it takes out a significant cost versus moving all that data across to the target. And that's why we come from the original slides with three or four solutions, brownfield and hybrid, to really just thinking about if it's more brownfield or greenfield. To us, it's a way of starting with the shell that was dimensioned. Either a copy of your system effectively or code, start from there with targeted changes. That to us is more brownfield or brown shell approach, and it changes the technology we use. If it's pure greenfield, it's a brand new installation, it might be public cloud, Then already you're into a selected data transition process effectively because some data will be not migrated at all, but created anew. Other data will need to be selectively brought in. But generally, tools are needed to help automate a pipeline of data then to the data migration cockpit for the public account. So the major choice for a data migration partner, we believe, is just as simple as where's your starting point? Is it a copy of your system? Is it a brownfield starting point or greenfield starting point? After which data could be selective either way. And if you see our literature through online, you'll see we start from one or two points on any of these projects. We go either down a business or a technology line. And the simple difference for us is whether you're driven by some strong mergers, acquisitions, business restructuring drivers, or whether you're driven more primarily as an IT and technology project. Either way, our software is used broadly across mergers, divestments, business reorganizations, perhaps, in readiness for some of those activities in future years and for technology driven and migration projects. And here's a list of the software solutions that we have to complement BTC. There's quite a few. So the description will be brief. System builder and shell sync is our technology. You know, at the moment, right until BTC does that, we continue to use these technologies to build the shell of the system. System builder works if your system is ECC already and uses the r three load binary out of the SAP kernel, which I believe other vendors may as well. Shell sync is a brand new solution that works on S4HANA, where that binary does not exist anymore. And it's quite a cool solution as it will reinstantiate a system. So if you point your current production system at a vanilla image of the same version of SAP, it will magically reinstantiate that into a copy of the source without any reinstallation being required. Quite a nice tool. Client sync is then the software developed over many years at a large client base of test data clients taken into the transformation space. SNL three, which gives us a single slicing run. This is effectively also what BTC is doing, so it may not be needed for your core financial systems anymore. But it works across utilities, BW, payroll, and other system type data models. And it has a transformation engine built in that comes from the privacy space that does large scale transformations. And we would look at where this can add value. Object sync and object extractor gives us a chance to take out object by object data. This can mean perhaps if you're taking out data to an archive, or if you buy a business that isn't on S4HANA yet, they're going to be splitting up between different application types. We can take data out into industry standard form. That's JSON, XML, CSV, and make it easy to extract data from the system. It's the same base of what we'd use to pipe run data into DMC. Or people know it still sometimes as, SAP migration cockpit or LTMC to load data into a target s four or public cloud system. Archive Central, we would solution alongside these things basically that if you're not migrating all your data to your live transactional system, you may still want to keep it somewhere to reference. And this is our platform built with our many years of SAP expertise that gives you transaction like access to the history. It takes structured and unstructured multisystem data into one instance. So it's a high cost effective way if you have to archive off multiple ECC systems before moving to one biggest four hammer system, for instance. Bringing history is especially difficult from all, and therefore, you need some work to put it. Particularly interesting example that we always reference was, an airline in Scandinavia that we worked with who had payroll results back to the seventies, which surely must be some kind of legacy, data take on Internet systems. So we moved data selectively there, but, took decades of data they didn't require to the archive. Query manager and variance monitor are HCM built solutions that include the HR database, which is quite unique in SAP, accessing all kinds of cluster information that's hard to get to. This gives you an extra reporting facility. We use Query Manager to help do data validation across all functional area types, and variance monitor to report on payroll period to period. But Query Manager can also be a extraction technology for moving into SaaS type solutions. So where we're taking data to see SuccessFactors selectively, for example, we would either extract that and transform it with query manager. Or in a complex scenario, we would use the data orchestration solution, which is slightly further around the wheel, which is a BTP app to help with moving data to success factors. Data transform is, the transformation engine that's coming from the privacy space. This can transform data in large volumes in place or in transit. It can do its source as we extract, target site before conversion to the s four in a data model, or after conversion. It's used broadly in the ECC and s four worlds, even for other kinds of SLO projects to transform data in place. And it really comes from huge investments made during the years of GDPR laws in Europe that improved our in place transformation technologies. And finally, in the last year, we acquired a technology we've long partnered with called the posting engine from a partner company in Germany, that moved out of this space. It is a posting engine for high volume finance open items and assets. Something that's generally required in either a merger and acquisition project or if you're merging SAP systems to S4HANA or you have a reason to take master data and open items without a transactional history, which is more complicated generally, then you need to find your open finance items and functionally post them to the target. This helps us not only move data selectively technically, but to post finance items between systems and company codes. And this is the suite of solutions we bring together with BTC and SAP Options to find the best solution for the clients to get to their target environments. And basically what you're trying to do is this, massively reduce the dataset. Years of redeveloping the test data version of our software meant that we were always creating the minimum viable dataset. And this is because the reason you would buy software like ours in non production environments is to massively reduce the size of those systems and often reducing in fifty, sixty or more, eighty or ninety sometimes percent of productions versus production systems. Once you take the minimum amount of transactional data, master data being sliced by company code, if that's a selection. But also there's a lot of technical and transient data in SAP systems that you need to exclude to get the minimum data footprint. And so you should be looking at really a significant with all of these solutions, significant reduction. If you've run SAP for five, six, seven years or more, then you should be looking at fifty percent plus reduction by using these kinds of technologies. And if you extend that across the environment, looking at your analytics platform, your core transactional platform, and perhaps the way you build dev and QA at the same time, you can often be looking at sixty, seventy, eighty percent reductions versus using production as the golden source for data and creating a whole Sfour environment just as a copy of production, which, I've seen in several cases and can lead to truly enormous data footprints across the estate. And how does this work with downtime? Basically, by building packages. So the shell is built before the data is migrated. If you take particularly the brownfield instance where the benefit is seen as being a simple technical conversion, Actually, there is some benefit to selective movements past just the subactivity. It allows you to stand up a system without data that can be technically integrated, high availability tested, and proven to be completely working before the data is moved in. After that, it's a case of parallelizing data extractions and looking at things like pre and post downtime data loads to give you a highly robust, outage, usually in a weekend or a day if you're lucky to move from your target environment to your source. So what's, the first step? Well, for us, it's an automated free flight assessment. This is a bit lighter weight than BTSC. And actually, one of the things we really like about BTSC is the blueprinting capability, which gives you multiple, variants for data selection. So what we'd often do now is run our automated assessment. It's a bit lightweight because you only need one transport. No SAP notes are required. And this gives us full breakdown of data from purely our perspective. So it's narrower. We're not looking at functional business process. We're gonna look at accounting document history and company codes and how much customization you have in your system. We use that as a first step normally. And then in a early engagement, go further into blueprinting and use BTC as well with this. We wrap our whole methodology around this process as well. Even simple things as asking the right questions at the right stage with the IT department or with the business is important around these projects. So no matter what technologies you use, expertise in this particular niche, I think is particularly important. And even the biggest size and with exceptionally good and talented teams, many of whom are our partners being most of their channel business, often have quite limited expertise in this particular niche. And it really is a niche. Data itself, I would say, has about ten niches within it from master data governance to privacy to migration and selective move of data, especially, has many as well. The difference, for example, between taking a two year slice of master data and open items is a significant gulf in the difference of complexity and one that people often fail to understand. So why do we think that we would be a part of a Sablan? We're really looking to keep only the parts of the system that work for you. When we say the parts, we mean mostly the data parts. Business process is something we would generally partner on with external or internal group partners. But we're looking to see what business process changes mean to data. We're looking always for the leanest possible data for print and the most automated that a data migration process can be, taking really only the relevant data. And it's the years of years and years of work really originally test data space and then transformation that give us this competence. And we do find with consultants that we would put through usually, test data arenas first and privacy and transformation to come to the biggest projects of this type. That it takes a long time working in this space to be able to visualize, all the possible benefits, the right decisions, and the possible pitfalls, best done at the start of a project before dates are set with the business with different, different approaches. And often wave approaches, for example, are necessary. It's often not the case that businesses can take a big bang approach to S4HANA going live. But who's the sort of things you need to know upfront and that affect and change data migration strategy. And the final point I put in, it's rarely part of a, an RFP or a budget, even for a S4HANA project. Now the data anonymization and privacy is a continuing and interesting space, one that's, continues to grow rapidly for us and one that's often not considered. It's hard to anonymize test data, but that is our recommendation and it's in the SAP DPA's SAP's recommendation too. But anonymizing data, either historical or your test data, is something that takes a while to set up. But actually a multi year S4HANA project is quite a good time to set up the landscape the way you'd like it to be. Because for a while, you'll have two landscapes, your ECC and your S4HANA. And I would strongly recommend people to consider that it is a time when you can say to your partner, we'd like to move selectively, but by the time we're live in S4HANA, we'd like our non production data to be anonymized, to be in line with the privacy laws that are either in existence already, in Europe, parts of America, in the UK and South Africa, and in parts of Asia now already, along with many new laws coming through. Because once a system is live, once every system is being used by the business, your project tracks, your dev, your QA, it is then much harder to implement these things in a live and running environment. So it's quite an opportunity to me to consider embedding privacy as an option. Not everyone will want to, but if you come to a software vendor like ourselves, that is something that's possible to embed with one project team and one project budget. So final takeaways. Yeah, we would really encourage doing avoid regretful spend. We would often be brought in over the years since twenty fifteen, the best four Hano environments for clients to list they've set up and it's working, but there's far too much data, their platform. And they didn't expect, the systems to be this big. They've used production as the golden template for their business, but now they've got all this data that's not used that they're paying for. And it affects everything. It affects, computational time, run time of reports in the system, the ongoing cost, of the business running SAP, related systems and data lakes, where you have to either take all your data or selectively move it out. So it really is important. And I would almost say that almost every SAP client that's already had a system for a few years, in my view, should be considering a selective approach. I find it hard to consider as much of an argument for not doing that unless you actively use the vast majority of your data from the system every year. Include us in your advisory stage is our general advice. We would be a very small component of that versus any other partner you have in the room, but we would encourage you to have us or another partner in this space involved early on and separate to your other partners as there are some conflicting incentives between, what a data specialist that minimise your environment is looking to do and what other people are helping you to buy. And match the approach to your business. Greenfield or Brownfield, either way is possible, but the data approach shouldn't drive or affect that decision. It just needs to be understood. And whether you think phased or big bang is really a case of how complex your business is, actually, the way we market the business and put together is think phase, not big bang. I would maybe rephrase that to think phased first, see if big bang is possible. There are many advantages to going big bang with a go live. It's a lot simpler and faster. I think more the issue is that people start big bang and haven't talked to the business enough and then have to change their plans once they're told that it's not going to work and they have to have a phased approach. It doesn't just affect the project plan. It affects the technological approach to data migration. And I think with that, we'll get onto just what else is next. If you come to our website, there's a free transformation assessment you can get access to. We've created a simple s four and a cost savings calculator as well, which looks at minimizing the landscape from production through test, and quality systems. And we have an information sheet for things to consider. We also really welcome, questions and inquiries about how projects have gone in this space before. We've got a good set of examples from, major transformations and merges to simpler selective moves of data. And that's something we'd be very keen to talk about people with, or you can join us one of our Inspire events where we'll often present on topics like this. And finally, the set of materials that SAP provide. And, Torsten, perhaps if you want to, talk to this tool in terms of what people can access to the SAP. Sure. Yep. There are just a couple of links where you can find further information. There's also a quick start guide, exact especially, I really recommend your blueprint in a very early stage how to get the blueprint for the five step, PDF file, that explained how to request continent and what needed to get the blueprint, which really gives you a lot of insight about your system and how it feels. Really highly recommended. There are also two short videos about, the blueprint as well as the link selective data transition, very, yep, really easy to understand and, nice illustrated here. And you will find further, links about what's in scope, what's not in scope, as mentioned before. So it's the standard tools of every complex scenarios in scope. So you will find a lot of information here. And there's also community, called data transition and transformation with blog posts and also from partners, not only from from our side, which is also really interesting. So definitely worth to have a look. Excellent. Thank you. And we'll share that after, don't we, Sarah? So there's active links in this deck that people can use to easily find this information. I guess it leaves us to whether there's, any questions, Sarah? You're muted. I don't know if, okay. Can you hear me now? Yep. We can hear you now. I said I think everyone's processing everything. We don't have any questions. But, yes, we will share the deck with you, and, we've recorded the session, and we'll share that with you as well if you wanna go back and watch anything. And, of course, we're around for questions, so please reach out to me. And, thank you, Jamie. Thank you, Thorsten. Appreciate it so much, and, enjoy the rest of your day, everyone. Thanks for joining us today. There is as we wrap it up, there is there's one note I'll make, and there's one question that saw just came through as we were saying that. So I'll just address it before we close there. Sorry. So there was a question that, whether SAP believes there's enough human and technology resources to meet the wave of demand, which is it's interesting. I think everyone must be seeing the constraint in demand. We've grown. And even with that, now we have to set moratoriums on projects sometimes because there's so many and so many people are moving. And it's it is the payroll and analytics and core at the same time. So I think there's a real crunch coming in. It really encourages actually the partners to work together to try and get the clients to complete these projects. What I'd add as sort of question to myself, just for the benefit of the audience is, it's just worth understanding. Because I mentioned the difference to master later open items time slices. If you have relatively short accounting cycles, if you leave most of your open items not for more than a couple of years and then they're closed. Yep. Tight accounting processes or you don't have long term outstanding debtors, then the level of automation you get taking two years of data, this is master data and open items, is quite significant. And it not just derisks the project, but makes much more cost effective the move to the target. So if anyone is considering whether they might just want master data and open items in the target system and not need fiscal years of history in there, I'd encourage them to at least become educated about what the benefits are of taking a time slice as opposed to that and having some localized history, but not all of it, as it makes automation much easier to execute. Okay. Thanks, Jamie. Alright. I think we'll close it out. Thanks again, and we'll see you at another session soon. Definitely. Yeah. And thank you, Tosta, for joining us. We appreciate it. Yeah. Definitely. It's a pleasure. Thanks for inviting me. Yeah. Bye. Of course.