Modernising analytics beyond S/4HANA

Hi, everyone. Thank you so much for joining our session today, another webinar as part of our dis derisking s four HANA transformations series. Today, we are speaking about modernizing analytics, and I have my guest speakers here, Jamie Neilan and Kikai Reyes. This session will go for, like the last one, a little bit longer than our average session, so probably expect around forty to forty five minutes of content. During the session, there is a question box in the top right corner of your screen. You're welcome to ask questions throughout, and we will answer any questions at the end of the session if we have time. If not, we will respond to your questions via email. The session is going to be recorded, so if you need to drop off early, you'd like to share it with someone, etcetera, you will be able to access the recording after the event. We'll have that emailed through to you later this week. I'll give everyone just another maybe thirty seconds to join, so feel free to get comfortable. Maybe grab a pen and paper, and we will get started in just a sec. I believe Jamie will start off the presentation, and Kai will be presenting some slides towards the back end. I might hand over just to Jamie to do some introductions while we wait for a few more people to join. Alright. Thank you, Kenneth, and thank you for joining us. So today, we're gonna have a couple of people here with myself talking about BDC and how we can use software to help our clients and partners migrate to SAP Business Data Cloud from their historical b w and b w for hand at Landscape. And with me today is who's a long term associate of myself and has been with EPI-USE Labs for a long time now in technical spaces and is now the regional lead for transformation in the Asia Pacific region. Hay joins us as the marketing lead for the region. And although not with us today, Tony Philippe is one of our thought leaders in the SAP BW space with the company for over ten years. He's pioneered using our software, excuse me, in numerous different kinds of SLO transformation projects. We come here speaking as EPI-USE Labs, part of Group Elephant, and the part that is really the software company in our group. With over nineteen hundred clients using our software, it's those clients who use not tools, but really mature SAP ABAP based software to optimize their SAP landscapes, to minimize data, to transition and transform, and anonymize the data in their landscapes. And it's really our clients that have led us into the transformation space by helping us improve that software and then bring a greater level of automation into what we can do in prism transformations. SAP Use Labs is made up of these six areas primarily. You might know us for the privacy space where we apply transformation routines to do complex anonymization of private data. They started in Europe as it has proliferated throughout the world at many SAP clients, provide a lot of solutions in the HR payroll space, which may know our sister company at use very well for. We deliver a number of specific and not client specific solutions to cloud innovations. And critically, the hardware business we opt to may optimize test data in the speed landscapes, minimizing systems. And it is that automation in the test data space that we brought into the transformation space around two thousand and two in the first place. And really, we can characterize our business in a simple way by thinking about EPI-USE Labs as data experts who use software to optimize and manipulate data in SAP landscapes to the benefit of our clients. Value through innovation is the strapline of the company for that reason. Now these are all the different areas of data and how we help our clients handle them. So we help with reporting and verifying on a range of SAP data. We disclose and redact production data to help support privacy laws production systems. We extract data selectively to move it around to different places and locations, be that archive stores or other systems or into analytics platforms. We transform data. This is a significant area for us, especially since the privacy laws in Europe came through. Those developments in transformation led not just to us being at the forefront of data anonymization privacy, but also gave us much more powerful tool to use in transforming SAP landscapes to do what many would call SAP system landscape optimization or SMO projects, many of which are in the mergers and acquisitions or selective data transition space. Many of our clients will know this first for refresh. So this is the process of rebuilding or building selectively nonproduction systems. That'd be key to your understanding of our technology if you know that area. Quite a lot of people now know it's also for our archive central platform. So we've also started building cloud based software solutions for hosting data that is sunset and moved out of the main productive SAP landscape. And then every single one of our projects, our consultants leverage our own in house software to help do innovative things for our clients. We're always looking to see not how to best use standard technologies, but how to use our technologies to provide value directly back to our partners and clients. And this is especially useful recently in the selected data transition space where years of development using our software to divest companies selectively, to do things like migrating only certain company codes or uniquely only moving a certain time slice of data between systems, production to production or production to a test environment, has meant a lot more projects working not just on cloud migrations of moves where I first worked with many years ago, but also in moving people from their existing r three estates to any form of s four HANA estate. Be that the main s four HANA system or something like your BDC and analytics platform in the coming years. And as people move data selectively, we have often a need or an ask from our clients to help with hosting or handling the data. They do not migrate to the new platform. And that is where Archive Central comes in. That's a role based transaction like secure ISO certified cloud platform where we host and serve clients legacy data back to them in a touch enabled HTML five user friendly interface that can sit right by their new Fiori launch pads for SAP. So we're gonna talk about BDC and BW and how we believe we can help clients now in a new wave of transformations and migrations. We believe it's just beginning right now as many clients have got to S4HANA already. And we first were asked by our clients to do divestment, selective transition of landscapes by enterprise structure in two thousand and two when our clients realized that our Data Sync Manager technology can very accurately take a slice of an entire SAP system by the enterprise structure. And since then, our services have expanded to include all kinds of cloud migrations selectively, privacy transformations, internal logical separations and reorganizations by company code, all of which need extensive mass transformative ETL processes on data and SAP systems, functionally aware, but highly technical data manipulation processes. And because we bring this software into the test data space first, which we'll cover in a little more detail, We get to develop and test and use of our clients selective extraction routines on new SAP platforms from the very first months that they are released before anybody would ever migrate off them because we will first use that technology to build our production environments for our clients. And so we'll come to what we've experienced and done in the b w for HANA space and how we think that technology has a direct and high value usage in the BDC migration waves to come. Though we speak here as EPI-USE Labs, our brand within Labs for our global service line of specialized services for transformation is Prism. This is a simplified solution outline for how to use our technologies. Two primary different types of transformation. One we call Prism for Business, and this is for client requirements where there was a merger and acquisition or reorganization of a company requiring a systems transformation. The second our focus today is Prism for Transformation, and this is to do with moving you and your SAP system to a new platform. And years gone by, that could have been an ECC to a new enhancement pack upgrade, a move into the cloud selectively. And more in these last few years, this is about moving people from ECC to S4HANA and doing it in a way that is selective, highly automated. So we believe that after many years of S4HANA systems migrating and being implemented, there is a large impending BDC transition wave. We're going to our reasoning today. So as somebody who started with SAP in the late nineties, BW was something I became intimately familiar with as a technical consultant in earlier in my career. And it's a was a fascinating release by SAP as it created a complex but very smart layered structure for holding analytics data outside of the ERP systems. Originally released in ninety eight and known as the Business Information Warehouse originally. Those of you working with SAP for a while probably remember it being relabeled BWBI back to BW and then on to being BW for HANA. You might even remember some blogs and articles about whether or not BW would have a place as SAP HANA and operation analytics became a thing for clients. But certainly, these systems simply continued to grow larger. And now there's a very interesting future for analytics where the data stores, the power strategic decisions for businesses will have to be holding data in such a way that they are enabling AI routines to use that data and helping businesses make decisions. This means that if you're moving data through, you need a good understanding of historical b w seven point four data models and seven point five data models, which will come here a little bit. So the basic concept of BW structure, the architecture was the lead scalable architecture. And the idea was to create quite flexible, scalable architecture for people to build their own analytics and people customize BW just like ECC in many, many ways. They first had an acquisition layer where they could bring in data from SAP and non SAP sources into a persistent storage area. And then the layers of harmonization where data could be cleansed and refined into a portable format where it would then go into data stores and marts where it could be held in different ways, transformed in different ways for different analytical purposes. And then it would move into reporting cubes with many different perspectives of data or multi cubes, multi providers. And this rather complicated in some ways architecture created a very high performance reporting solution that led to many clients having more data in BW than in their ECC systems. And for multinationals, often, you'd have multiple regional terabyte or tens of terabyte data stores sitting in BW. And what's important to realize is that isn't just analytics data. These systems were from plumbed back into transactional systems such as your HCC core or your supply chain system. And so the spotlight in our view hasn't really been that heavily on b w in recent years. People have been very focused, understandably, on the s four HANA journey and what it means for them and where to get the value they need as a business from the necessary move to S4HANA. And they look at real time analytics and automation and now at what kind of value they can get from new technologies and AI if and when they move to s four HANA. However, this leaves a shadow if you like of b w and analytics data left behind due to less pressure on the licensing for b w and b w for HANA systems. It isn't the primary need for migration for most clients. And because like most SAP technologies, it's technically excellent and could basically run forever. People in many cases have lots of VW HANA systems still there in operation without yet a plan for how to move to a next generation of analytics technologies. And this can be not just terabytes, but petabytes of information potentially sitting in analytics stores. And so to emphasize, EW data is not just replicated data. It isn't purely a view. It has its own logic, its own custom ABAP code, generated data that a code provides. It can take non SAP data in with SAP. It can plug into transactional systems and affect processes. And for many people, though, we use it for BPC, business process consolidation as our business planning consolidation, and BFC, financial consolidation of systems. So active outputs and value for the business, not just analytics. Replacing these systems is not going to be just a case of regenerating your analytics data. And so there are three simple stages, if you put it like that, of analytics, are the SAP BW landscapes and technology coming out in ninety eight, the BW for HANA systems that were brought through to leverage the HANA database platform and brought in things like the advanced DSO concept, the compressed led scalable architecture, and the usage of native handler instances and nearline storage to try and provide even higher performance analytics for companies. The move to SAP Business Data Cloud is a significant change to this architecture. This legacy of internal, you know, big box analytics has changed enormously to an open ecosystem and an integration with industry leading technologies such as Databricks, Snowflake. So we see the waves for our clients like this. The payroll wave came first in our experiences. Although it was often integrated as part of ECC, the strategy became clear quite early and payroll in all of its many complexities is still less complicated than the financial transaction or manufacturing corp for clients. So many people were moving their payroll systems earlier than S4HANA to ECP, PCE. Then you have the S4HANA wave. We're still very much in the middle of this at the moment with many clients having moved subsidiaries or smaller systems to S4HANA with most bigger companies in the midst of doing this now or on the start of their S4HANA journey. And of course, the current end date depending on your licensing structure for needing to move is twenty thirty three depending on your agreement with SAP. Whereas for analytics, the end date for maintenance VW HANA is twenty forty. But for those of us with teenager adult children, you realize fourteen years goes by quite quickly. And many of these projects last five or six years. So the analytics wave will certainly be beginning, we think, in the next couple of years with significant transitions where the budget for transformation shifts from s four HANA to Analytics. So motivated by end dates, we see this wave as the next sixteen to twenty years being a common theme in SAP landscapes where data footprints are size. So we said the analytics world has exploded. What we mean is that in the past, you might have had one b w system or two. Maybe you had crystal reports, business objects. Now it's quite possible that you also have a Snowflake instance, that you have native analytics, that you have a native HANA store with b w HANA. Perhaps you have a BW seven point four system. Perhaps you have Data Sphere and BDC partly used, but without your legacy data moved into it. And so the transition journey is potentially more complicated in some ways than your S4HANA design, at least in terms of the architecture of your analytics data. And so where does Prism or selective data transition using our technology from Labs fit in? We are only focused on one very specific part of this journey. So if you look at SAP Business Data Cloud like this, you have the idea of live federation from Snowflake or other cross application and distributed computing analytics solutions. You have your historical b w for HANA landscapes where data is suggested to move into BDC and Datasphere to empower things like SAP Analytics Cloud to do your predictive analytics, and you've got the data still coming directly from your transactional core headed to DataSphere. And the place where we focus our technologies, I believe we can add significant value, is just right here. Just in the move of data from your historical landscapes of b w to b w bridge. And the b w bridge, by the way, is a b w four HANA technical stack within the fence of BDC that is the first step to moving your data in into a data fit model to empower AI modern analytics. Now the transition strategy for this for SAP so far is to move your data wholesale to the bridge and separating that data selectively is highly complicated. However, if you have many terabytes or petabytes of data in that system, costs could certainly be a concern as you move that data in And if the data system has never been cleaned up, archiving not being quite the same thing VW that it is functionally in ECC or S4HANA, then you may be looking at ways to at least selectively bring that data across. So Hannah the Hannah database definitely didn't kill. BW for those of us around for those blogs, how it's nice to see that BW survived. And there's a lot of people out with a strong skill set in this area, and I think a really interesting few years ahead for those people. And the data is absolutely critical. Critical to transaction processes, critical to business insights. And whilst DLP operates your business day to day and it makes it work, if you want to make strategic decisions about where your business is going, then b w and b c are vital. And if anything, this is an area where AI for me could potentially have a higher value than the nearest four hundred system as using AI to do complex analytics on your business may be similar to using AI to seek a cure for cancer or look at new ways of genetically improving the response to diseases. Using AI for analytics is a very good way of using its creativity and ability to crunch huge amounts of data from different sets. So regeneration of data, just in case that still isn't clear why you wouldn't do that, we don't think this is going to work for most systems and here's just a few points for that. So you have your raw ERP data and your OLTP system, but you need it to transact. You don't always retain it. Full history is rarely needed in the core of your system. And in fact, many people in the S4HANA journey are moving over selectively, taking only mass stage or open items, maybe using someone like ourselves to only take a time slice or company code slice to a system. Whereas in the analytics system, they do actively need those decades of history to inform analytics to help make decisions. And as I mentioned before, there's also data that exists only in the b w system from logic that's only coded there. So the idea of regeneration can absolutely work for some clients, but for many, it would be a concern to try and rebuild analytics from scratch. And so we get on to the question of selective data transition. And there, I'm very pleased to hand over to my long term colleague and friend, Okay. Do you wanna take it from here? K. Thank you, Jamie. Let me quickly share my screen. K. So I hope everybody can see my screen. K. So for the next exceeding slides, I will discuss why are we choosing, for example or why would you choose a selective data transition when you move from one system to another? And then I will also discuss briefly our PRESIM methodology, okay, that caters for the BDC STT. So, again, so why do we need to or why do you choose selective data transition? Okay. Selective data transition has already existed before S4HANA. Okay? And it always has the same considerations, the same, I the same target. Okay? So if you guys are familiar with the TDMS, SAP TDMS from way back, So the selective data transition actually migrates only selected data from one system to another. So means it doesn't carry unwanted data from your to your target system. Okay? So in when you do that, there's a lot of benefits that you can get. First, is that, recently, there's already a big data, okay, in the IT world. So with that big data comes the infrastructure cost. So if you have big data, infrastructure cost will also be higher. So the more your data grow, the more that your infrastructure cost will grow. K? So with the selective data transition, you can only move a subset of your data, thus reducing, you know, the cost of your infrastructure, okay, in terms of the hardware specs, the hard disk, memory, and everything. K? And then often also, as you all know, I think all of us are, like, not new to SAP, so companies retain their old data within their current subsystem. So if, for example, if a company is already twenty five years old, we'll still see up until now that the data in their existing EC systems are also there. So it's like Sorry. Twenty five years of data there. So since the modernization of SAP now moving to S4HANA, moving to cloud, you know, using VTP, CleanCore, companies are often have that complex task of making or creating a linear system for them moving forward so that they can leverage on, you know, the modern infrastructure and also AI. K? So if you have a date of twenty five years in your current system, the thing for you to do is to get into a complex archiving solution or complex archiving project. Okay? Because it's not that you can just okay. This object, I would just archive. This one, can put it archive. You need to design or you need the solution how are you going to do the archiving so that later when you sunset that those data, you can still read it, k, historically. Okay? You can still use it in audits. Okay? And you can always refer to that data as a structured information. K? So when you do selective data transition, it actually sort of instantly do an archiving for you because you only take a subset of your data, and you leave the rest of your data in your current system. K? So it eliminates actually that big cost of doing a complex archiving project. K? And so in terms of SDT, there's a lot of cost benefit that's aligned to it. K? So people usually think that SDT is complex. Yes. It is. But, actually, it will give you more benefit in the long run. K? So there are different so with the SAP modernization, there are different ways that SAP approaches this. Okay? There are three approach from SAP usually. The first is the full lift and shift. Second, is the pure regeneration or the greenfield, and then the third one is the SCT. So this also so this approach is also applies to, you know, s four conversion. K? So for BDC, the full lift and shift approach is actually moving as is your existing BW systems into the for example, RISE. Okay? You move it to RISE. Everything. K? So you don't if you have twenty five years of data and all of those old processes, new processes, altogether, you move it to the SAP price. Okay? And then from there, you transform your BW objects into the current BDC objects also. So you can use tools in that BDC in the BDC workspace for that transformation. And then once you transform those tools, you will need to transform next or innovate or update your existing data flows, your existing reporting. Yeah. All of your existing reportings. Okay? So that afterwards, you'll be able to get still an accurate analysis data for your analysis and your for forecasting. Okay? Another approach is actually do a greenfield. So this one is the regeneration. So you build your BW systems or your, yeah, your BW data entirely from your source s four data. K? But the I think the setback of doing that is that, normally, now when company with the SAP modernization, company moves their data, not all of their data. They only move a subset of their data, of course, with the consideration of the cost. And it's like, you don't need the twenty five years of data. You only need the current five years of data or depending on the country law, for example, taxation. Okay? So what's the impact when you move it to BDC? So you don't get actually your history. So, initially, with your current BW systems, you've already created, you know, your logic, your history, and whatever analysis that you want to do or forecasting that you can use for your business. Okay? So if you only use a subset of data, you won't be able to get that because it's going to break, you know, the logic of what Jamie mentioned earlier that normally in a, you know, in the old b w approach, you bring all of your r three data into b w, and that's where you build your b w. But now you move only a subset of your data, and then you aside from moving that subset, you only move the logical ones. Okay? So you at least can still use it for your assessment, reporting, and then forecasting. Okay? So the third approach is actually the SDT. So this one, the mechanism is only moving targeted logical sizes of historical data. So it's not actually a technical size, but a logical size. K? So what's the impact? So when you do the technique the logical sizing, it gets everything, every object, every information logically connected. K? So it will not leave behind, for example, a certain set of data because it's related to, for example, to time or it's technical. K? So the good thing about the STT approach is that it slices logically, k, not technically. K? So with the STT, EPI-USE Labs offers a solution which we call Prism for moving your data selectively from one system to another. So it's like a it's a data transformation. Okay? So we call it Prism for BDC. K? So what is Prism for BDC? So Prism for BDC so EPI-USE Labs has already built the Data Sync Manager for BW since twenty ten. And then when b w four came in, b w four HANA in the native all of the native HANA considerations, the d s the DSM was extended in twenty nineteen to cover for all of these changes in BW. K? And our Prism aside from that, our Prism solutions team has already gone through different projects for the SAP BW transformation. So it ranges from the simplest BW carve out to the most complex, okay, BW carve out. K? Because our engine actually automates the method of slicing up the entire system in one run, and it, of course, optionally lets you move data as a single object. K? And our usual time slicing and enterprise slicing also still exist with the Prism for BDC, k, with the of course, together with the layer layered cube of characteristics dicing. K? So the Prism solution actually has is using different softwares. Okay? This is where we leverage our approach. Okay? So first, we have the system builder or the Shell Sync. So the this tool actually creates a shell from your current system. So we from this tool, we can get your you know, the normal repository objects and then your customizing objects only and build the share from that. K? And then we also have the client sync, which this one, the client sync actually gets data on an enterprise level. So on the BWS side, we get it from Query, and then it slices from there logically. Okay? And then aside from that, we also have the object sync or the object and the object extractor, which slices or can get new data from a single object, one system to another system. K? Another product on our side is actually the Archive Central. So the Archive Central actually is a leverage on the leverage of this is when you want to sunset your data, Archive Central is ready for that. Right? So it's the archiving solution for PRISM. K? And aside from those four main tools, we also have other tools like Query Manager, Data Transformation, Semantic Flow, and LTPosting engines. K? So our products actually, Prism for BDC is actually available in the SAP store. K? So you can get more information in the SAP store. I will send the link later. You can check it. And if you have any questions, I will also provide my email address so you can send me directly any in any questions, any information, or if you want to set up a meeting so that we can discuss with you our Prism solutions, so including BDC. K? So for reference only, so this is the unique capabilities for the BDC service that we offer. We cater for the different PW sources, so from seven point four until the BW four HANA. And it's also compatible with the SAP nearline So this is similar to the warm storage on SAP HANA. Right? And then we also cater to the different scenario approaches. So yeah, different profiles to do the slicing, and then we can only copy data that are needed. Okay? Transformation is also part of it. So if you want to scramble your data when we do the transformation. K? And okay. So the as I mentioned, the slicing is a logical slice, so we can we also do the time slice, enterprise slice, and everything that slicing can do on a logical level. So as I mentioned, we do an intelligent slice, not a technical slice. So that means we we get all of the logical connections of one object and then slice it from up to the lowest object. So, for example, from the multi providers down to the ADSOs, so we carve out everything. Okay? So because it's not a technical slice. Then just to show you an initial screens on how we do the on our DSM. So first, you need to select the objects, what you the objects that you want to carve out. So, of course, data load to PSA is available, info objects, and the rest of the available objects that you can use for sizing. K? For the next feed, you need to select which options you want to size. Right? So here it where you define, k, which company code do I want to size? Company code one hundred one thousand. Do I want to size fiscal year nineteen ninety eight? Okay? So remember in BW, company code may not be referred to as b u k r s or company code. It can be referred to a different name. But even if it's like that, that's why we use a logical slice so that you can still slice. For example, company calls, risk carrier, Variance. Right? And then the next one is this is the scrambling part. So when we do the slicing, we can also scramble your data. Of course, sometimes even in the development system or test system, there's, what you call it, sensitive data, some personal a few of personal information added there for testing. Okay? So we can use scrambling for that. So at least when we do the move, whoever logs it to the system will not be able to interpret that data and use that data use that information, okay, outside of the system or the organization. So fueling the next era of intelligence. So with Prism, we do the selective data transition. K? And we do it on a logical level, okay, not on the technical level. So that means we preserve the whole logic of what we are carving out. So for example, when we carve out a multi provider, we car we carve out the whole logic related to that multi provider. That means that when we move it to the to BDC, we don't anymore include or bring the, you know, the nonimportant data or nonrelated data into the other system. So because when you bring in current data to the target system and then you leverage on AI, that means you can get the best information for doing your reporting, your analysis, your forecasting. And with AI, you know, it can already predict, okay, if you plan for five years from now, but five years from now, this might happen. This can happen. K? So that's the I think that's the advantage of our Prism for BDC methodology. So I'm going to turn it over to Jamie for the client discussion. So, clients, that we've already moved from the existing VW to the target BDC. Thank you. Thank you, Yeah. I'll just reshare my screen here. Okay. And there's gonna be some FAQs shared in these slides that people can access after the event. I'll put them on the screen towards the end. As I know, people these days can use a lot of pausing and AI replaying technologies to digest this content. But we'll start with a couple of client studies. So the first was very interesting m and a scenario a few years ago where company was decentralizing from one global system, ERP and BW, to having regional instances of those systems. So splitting out primarily by company code data to take one ECC and BW pair and create, I think, four different regional paired systems. So we help this company with slicing a data from ECC by the company code structure. But then came the question, well, we don't want to build rebuild b w. It'll take too long, and we have this high value data in there. How can we go about dealing with the b w system? And this is one of the first clients where we did multiple systems in one run, slicing b w. The way we do that which Kaki mentioned is we have a program that finds certain data types like the company code and then apply slicing through the cubes of the l s a and proceeding structures as well. So if you slice on a characteristic in a cube, our software will automatically slice proceeding structures like the DSOs appropriately for the same data. And it will do that by our standard kind of structures as can get said. After the search programs are executed, you then have the option to slice by company code or time or by any other characteristic of the W system. And so we applied the same kind of logic and built out these four global VW environments with only the data needed for those regional VW systems. And, of course, the key here is going all the way back to the test data explanation. Our method is not to use tools to simply empower smart consultants. This is really a software method. The engine of a software will find automatically preceding structures based on the selections you made. And then when you come to a transitional migration, the extraction is a single smart selective extraction that will run the same every time once it's configured appropriately. Another one I was really excited to be involved in was a great project run by SAP and CAP at a large energy operation that was splitting out one part of its company from the other parts. It had a forty terabyte b w system and a very similar need. How do we move only the data we need? It would take months to rebuild a system of this size. Our contact for EPI-USE Labs at SAP said, well, we believe that labs can do this with their software technology. I can remember still the anxiety of the client calling me saying, are you guys a way to relax? This is never gonna work effectively. And the eponymous Tony Philippe mentioned at the start of this presentation, worked on this project and went without a hitch at go live. And I think people are normally used to seeing with complex data transitions, lots of spreadsheets and testing and complex reports to get a handle around what the data was. Tony had it all built into software and ready to go and was proven to be the smoothest part of the project. Selectively moving from forty terabyte PW system across to this target environment. And that's very much because of the software approach and really proven from the test data space refining that solution. Our clients refining it for us. And because you need a much higher level of automation in building test environments, we don't have several cycles of testing before a plan to go live and get a great level of automation free into transformation. And the final was a large manufacturing company, again, in the m and a space, is where the transformation side of b w's really been refined. This was part of a sell off. This manufacturing business company code carve out again, this time with a global trade system ECC MBW. Here we had nearline storage as well, which I think was the first time we'd done this. Set a SAP IQ system providing the nearline storage for b w, b w for HANA. And we had to make sure that software would work with the nearline storage, which works like different in terms of how you extract directly from that data area. Now this is the first time we used the NLS component Data Sync Manager LT which is the core of the Prism software suite for b w, and with a few modifications for our exceptional development team. Again, the project went without a hitch. And it is from all these experiences primarily in transformation space that we're confident we have a very strong offering for the BDC move. We're really interested to find clients who would be willing to have a conversation about how we might be able to help them in this journey. And now finally, as we wrap up, there are some frequently asked questions that we put together that people often ask us when we talk about b w and the BDC journey and how we think we can help them. I won't talk through all of them today. I'm simply gonna put them on a slide and lightly cover them. And if anybody's watching this, they can pause and look through these. So recapping on the first slide, what is the drive? One people must soon start thinking about how they'll move off the b w for handout systems because the move is so significant and if you have completed your s four journey, this is something you should look at soon because otherwise the same pressures may apply to push you towards BEC whereas if you look at this strategically as soon as your s four HANA, it can certainly increase the value you get from the s four estate by making the most of your analytics. And the final part is coming back to how we develop this technology before the BDC wave has even begun. And again, I'll come back one more time to the test data space. Our clients use our software technology as soon as they're on a brand new version of a SIGV. They'll ask us, have you got a version of your software ready to build this a nonproduction system with a much smaller size slicing data? And BW has been a particularly complex area. We've got embedded BW in s four HANA systems these days. You've got BW and BW for HANA. You have nearline storage. You have a native HANA instance attached to BW but there's not an app stack. And our development team has spent the last ten years handling all these different data models. So thank you for joining us today. We hope that perhaps if you're looking at the move to BDC and what to do with your analytics data, you'll consider whether LAPS technology might be able to help you in that journey. Wonderful. Hi. Thank you so much, Kakai and Jamie. That was a great presentation. Right on time. We said about forty, forty five minutes. So I think we will wrap it up and any questions that came through, we will respond via email. You will have that recording also in your inbox in a few days, probably end of this week, if you'd like to revisit as well. Thank you so much for attending, and we'll see you at the next one. Thanks again. Thanks, Query. Cheers, Query. Goodbye.