Alinee sus sistemas de prueba SAP con los de producción para realizar pruebas precisas

What is a system shell? So we're going to start looking at what a shell is in order to understand what Shell Sync does. If we look at an SAP system, it'll look something like this. We have lots of transactional data sitting on top of some master data and client dependent customization. But if we strip that vast majority of data away, we end up with what we refer to as the shell. This is the repository and the client independent customizing. Now, the repository is the structure definitions and the programs that make up your SAP system. How do we create these shells? The first approach is SAP's standard system copy. We can do two approaches here. We can make use of the normal SAP system copy software or we can follow the approach of doing a database backup and restore. Now, when we do that, we end up with a mirror image of the production system in this case, and we need to actually go and delete the transactional data clients away in order to get the shell. The drawback here is overhead. We need equivalent storage space to Production in order to build this preproduction environment. In addition to that, clearing out that Production client also takes quite a bit of time and resources. So this is less ideal. Now before the S/4HANA world, we made use of System Builder to address this problem. So System Builder allows you to create shell systems, and those shell systems are installed using the SAP software provisioning manager. So, System Builder will create exports compatible with the SWPM installation process. Now, coming to S/4, this picture has changed somewhat. So SAP has actually narrowed their focus in on only using the HANA database, and along with that meant they no longer needed to support database agnostic technologies. And the idea is we have two existing systems and we're only going to refresh or replace that repository in place of the target environment. So you no longer have that overhead of installing a new system. You can replace it on one of your existing systems. As part of that process, we are going to remove all of your data clients, so you will end up with a proper shell. That shell, you can then populate with test data using similar approaches as before with Client Sync, with Data Secure for masking and so forth. Visually looking at it, this is what it's going to look like. So you already have a pre-production system. That pre-production system already contains a reduced client, and you just want to replace that with now a shell of your Production system. So with Shell Sync, this is what's going to happen. We take that existing system and replace it in place with the shell from the Production system. In summary, we often use shell systems when performing realignment actions to make sure we have the same programs and dictionary structures on our preproduction environment as on Production, in order to increase the quality of our testing. Before the S/4HANA world, we made use of System Builder to create our shell systems, and they were created using the installation process, creating new systems. After S/4, we now use Shell Sync, and this is an in-place realignment. So no more needs for new installations.