We’ve spent some time now talking about what an SAP carve-out is, as well as some of the nuances that makes these types of projects unique. I think it’s time we dive a bit deeper into the topic and touch on some of the general business scenarios customers may come across during a carve-out project.
It is generally agreed that SAP shops face one of three business scenarios. Keep reading to understand what these are, and when they may or may not make sense to pursue during your project.
Business Scenarios for SAP carve-outs
These are just high level, general insights into the different business scenarios. Interestingly, the second business scenario is what led to what is now called Selective Data Transition for SAP S/4HANA.
So, let's have a closer look on the technical approaches for Carve-Outs now.
Technical Approaches for Carve-Outs in SAP
You might have performed Carve-Outs in the past with a phase-out or new implementation scenario migration master data only in a fresh SAP system. This is, of course, a way to implement a carve-out, but obviously not the best way to do it with regards to avoid business disruption and efficient handling of such projects.
As I see it, there are four beneficial technical approaches for SAP Carve-Outs – and they come in two flavors: system clone and selective carve-outs. What’s the difference? System clones can be executed with standard SAP technology (basis and SAP LT) whereas selective carve-outs must be performed using specialized software such as the cbs ET Enterprise Transformer.
Option 1: Clone and Run
This system copy includes all configuration/customizing, repository, users, authorizations, and data. This option works well for internally driven carve-outs where the source system isn’t too large, as the hardware would need to be doubled in order to support the copied system. However please be aware that you will hand over a ton of data, z-codes and other potentially confidential stuff to an usually independent third party.
Option 2: Clone and Delete
Like option one, you start by performing a full system copy. Again, hardware needs to be doubled up to support the full copy of your productive SAP environment.
Next step is to delete obsolete data from the target system using tools such as SAP LT or cbs ET. As opposed to option one, the result is a system that only includes the data in scope. However, this option is not ideal for customers with large databases. Not only due to additional hardware costs, but licenses for SAP LT software can get expensive as they are based on database size (may not apply to other software products such as cbs ET). There is also always a chance that not all data and/or customizing is deleted correctly and ends up in the hands of a competitor.
Option 3: Selective Carve-Out in Empty Shell Copy
This is where it gets interesting. Unlike the first two options, this approach requires an empty shell copy instead of a full system copy. This shell only includes system configuration and customizing without any data whatsoever. This has two advantages when compared to the earlier approaches: 1) the target system does not require as much space (hardware) as the source system due to this being just a “skeleton” copy, 2) confidential data that is not in scope will never touch the target system, ensuring no proprietary information exchanges hands.
The second step is where it gets a little more complex, and would require a standalone blog post to explain, but I’ll try to summarize as best as I can. By means of specialized software (standard SAP tools are not capable of this) you may set selection criteria to extract only the data in scope from the source system and import this into the target system. In this case, considering the target system is configured the same way the source system is, no mapping or data transformation is necessary. Selection criteria can be set based on different parameters such as company codes, plants, profit centers or cost centers just to name the most common ones used. This allows customers to surgically select very specific subsets of data to ensure only the necessary data is handed over to the buying party.
Option 4: Selective Carve-Out in new System
This is essentially the same as the shell copy approach, with the added caveat that the target system is a different from the source. This could be a different release, or a system that is configured differently (ie. a shell copy of the buying party’s SAP environment for example) or an SAP S/4HANA system.
The steps are almost the same as above. Only difference is that after extracting data from the source, it needs to be mapped and transformed into the target system structures. This mapping and transformation is software-driven and automated, with robust validation features that guarantee data quality and consistency.
Option 5: Selective Carve-Out in non-ERP legacy system
In the spirit of full transparency and completeness, we can’t forget about scenarios where the target system is not SAP (or in some cases it is not known what the target system will be). In this case, we can follow the same steps as the selective carve-out approaches, with the added caveat that the data in scope will be extracted in flat files so they can be handed over to the buying party.
This scenario is actually only the first half of doing a full SAP-to-SAP Carve-Out as the work will only be done on the source side. The only challenge is to select, export and present the data in a way that the buyer can use it right away for a migration in their non-SAP Legacy system.
Sounds easy, but in fact there may also be additional challenges. You don't want to hand over more data than agreed on in the TSA, and need to make sure the full data structure and dictionary of the objects are included, so they are usable by everybody who is not an SAP expert.
This approach typically ends in about 30% cost reduction on the SAP side due to not having to work on system configuration or data validations on the target side but requires a lot of thoughts though around when and how the data will be extracted, validated and handed over. And, of course, it will take more effort, cost and time for the buyer to migrate the data into whatever system they will use in future. But this is a different story again.
By the way: Options 3 and 4 lay the foundation for Selective Data Transition to SAP S/4HANA which I will explain in my last post blog of this series in two weeks. Before that I will talk about the things to be considered beyond SAP Core in a Carve-Out in my next post blog. Stay tuned.
It is generally agreed that SAP shops face one of three business scenarios. Keep reading to understand what these are, and when they may or may not make sense to pursue during your project.
Business Scenarios for SAP carve-outs
- Carve-out in SAP clone: this is simply a 1:1 copy of the productive SAP system and results in no functional change. This is by far the least complex of the scenarios, and at times may require zero external assistance as it can be typically executed with experienced in-house basis resources. Perfect solution for small systems, in internally driven carve-outs, since you don’t have to worry about proprietary or confidential data ending in the wrong hands. Making a full system copy is not always feasible, especially when talking about large databases, as you must double the hardware required to run a full copy of a productive SAP system. There are additional task related to data deletion that can be performed in post using specialized tools such as SAP LT or our very own cbs ET Enterprise Transformer.
- Carve-out in new SAP: this is a move to another SAP ECC, SAP S/4HANA, or a different SAP system with different configuration. The key here is that data needs to be transformed into new SAP processes, or in the event of SAP S/4HANA new data structures and functionality. This is the most common scenario for two party M&A deals. Here you have two options, you can use the clone approach described above, and then resolve conflicting configuration and z-codes to match the target system. You can also selectively carve-out the relevant data in scope, transform it on the fly, before importing into the target system or a shell copy. At the end of the day, there is always some configuration and z-code work that needs to be performed before the data is compatible with the target structures.
- Carve-Out in any new ERP: here we are dealing with an unknown target ERP system or a non-SAP ERP. This scenario is quite common as well. On the target side this will be quite similar to a carve-out in a new SAP. Selection criteria determines with SAP objects and data need to be carved-out, then raw data is extracted into flat files and handed over to the buyer. Note, last two scenarios apply to master data only using standard SAP LT software. There are no limits on historical transactional data using 3rd party software such as cbs ET.
These are just high level, general insights into the different business scenarios. Interestingly, the second business scenario is what led to what is now called Selective Data Transition for SAP S/4HANA.
So, let's have a closer look on the technical approaches for Carve-Outs now.
Technical Approaches for Carve-Outs in SAP
You might have performed Carve-Outs in the past with a phase-out or new implementation scenario migration master data only in a fresh SAP system. This is, of course, a way to implement a carve-out, but obviously not the best way to do it with regards to avoid business disruption and efficient handling of such projects.
As I see it, there are four beneficial technical approaches for SAP Carve-Outs – and they come in two flavors: system clone and selective carve-outs. What’s the difference? System clones can be executed with standard SAP technology (basis and SAP LT) whereas selective carve-outs must be performed using specialized software such as the cbs ET Enterprise Transformer.
Option 1: Clone and Run
This system copy includes all configuration/customizing, repository, users, authorizations, and data. This option works well for internally driven carve-outs where the source system isn’t too large, as the hardware would need to be doubled in order to support the copied system. However please be aware that you will hand over a ton of data, z-codes and other potentially confidential stuff to an usually independent third party.
Option 2: Clone and Delete
Like option one, you start by performing a full system copy. Again, hardware needs to be doubled up to support the full copy of your productive SAP environment.
Next step is to delete obsolete data from the target system using tools such as SAP LT or cbs ET. As opposed to option one, the result is a system that only includes the data in scope. However, this option is not ideal for customers with large databases. Not only due to additional hardware costs, but licenses for SAP LT software can get expensive as they are based on database size (may not apply to other software products such as cbs ET). There is also always a chance that not all data and/or customizing is deleted correctly and ends up in the hands of a competitor.
Option 3: Selective Carve-Out in Empty Shell Copy
This is where it gets interesting. Unlike the first two options, this approach requires an empty shell copy instead of a full system copy. This shell only includes system configuration and customizing without any data whatsoever. This has two advantages when compared to the earlier approaches: 1) the target system does not require as much space (hardware) as the source system due to this being just a “skeleton” copy, 2) confidential data that is not in scope will never touch the target system, ensuring no proprietary information exchanges hands.
The second step is where it gets a little more complex, and would require a standalone blog post to explain, but I’ll try to summarize as best as I can. By means of specialized software (standard SAP tools are not capable of this) you may set selection criteria to extract only the data in scope from the source system and import this into the target system. In this case, considering the target system is configured the same way the source system is, no mapping or data transformation is necessary. Selection criteria can be set based on different parameters such as company codes, plants, profit centers or cost centers just to name the most common ones used. This allows customers to surgically select very specific subsets of data to ensure only the necessary data is handed over to the buying party.
Option 4: Selective Carve-Out in new System
This is essentially the same as the shell copy approach, with the added caveat that the target system is a different from the source. This could be a different release, or a system that is configured differently (ie. a shell copy of the buying party’s SAP environment for example) or an SAP S/4HANA system.
The steps are almost the same as above. Only difference is that after extracting data from the source, it needs to be mapped and transformed into the target system structures. This mapping and transformation is software-driven and automated, with robust validation features that guarantee data quality and consistency.
Option 5: Selective Carve-Out in non-ERP legacy system
In the spirit of full transparency and completeness, we can’t forget about scenarios where the target system is not SAP (or in some cases it is not known what the target system will be). In this case, we can follow the same steps as the selective carve-out approaches, with the added caveat that the data in scope will be extracted in flat files so they can be handed over to the buying party.
This scenario is actually only the first half of doing a full SAP-to-SAP Carve-Out as the work will only be done on the source side. The only challenge is to select, export and present the data in a way that the buyer can use it right away for a migration in their non-SAP Legacy system.
Sounds easy, but in fact there may also be additional challenges. You don't want to hand over more data than agreed on in the TSA, and need to make sure the full data structure and dictionary of the objects are included, so they are usable by everybody who is not an SAP expert.
This approach typically ends in about 30% cost reduction on the SAP side due to not having to work on system configuration or data validations on the target side but requires a lot of thoughts though around when and how the data will be extracted, validated and handed over. And, of course, it will take more effort, cost and time for the buyer to migrate the data into whatever system they will use in future. But this is a different story again.
By the way: Options 3 and 4 lay the foundation for Selective Data Transition to SAP S/4HANA which I will explain in my last post blog of this series in two weeks. Before that I will talk about the things to be considered beyond SAP Core in a Carve-Out in my next post blog. Stay tuned.
- SAP Managed Tags:
3 Comments
