If you’re still following along, you’ve noticed there has been a very heavy focus on data in my pas blog posts. Specifically, on how we segment and prepare data for carve-outs from the source system using two general techniques: system clones or selective extractions. We’ve also covered some of the questions that will determine how these carve-outs should be executed based on the terms of the M&A contract.
While understanding these specific requirements is critical for the successful execution of said projects, there are a few other things that should be considered. As you probably know from experience, ERP landscapes are typically a complex web of SAP software and external applications spread out across on-premise hardware and the cloud. Even more complex when there are interfaces to 3rd party systems which have also to be shared or separated after the Carve-Out.
M&A contracts are also rarely as simple as Company ABC buys part of Company XYZ and the carve-out should be executed within 5 months. I’ve seen many cases where a Transactional Service Agreement (TSA) is in place, and the seller agrees to continue handling certain operational aspects of the business for a specific period of time. There is also the question of what to do with all customizations like z-transaction and z-reports. How do these things come in to play? Let’s take a closer look.
Transactional Service Agreements
TSA’s are pretty common when a large company sells part off their business to a smaller, less established organization. Makes sense, since in this case the buyer likely doesn’t have the IT infrastructure in place to support merging the newly acquired business into their current environment. Or, in case the buyer is not prepared to integrate the infrastructure and staff of the acquired company which is often the case with large companies on the buying side.
A TSA allows the buyer some time to get their system ready for a merge, all while the seller continues managing the back-office operations for a nominal fee. They are also common in Spin-Off scenarios where the newly formed company sort of rents infrastructure from the parent company for a year or two. The idea is to facilitate this transition for the buyer (or spin-off company), who may not be able to immediately support these systems on their own.
You may be asking yourself, so what? Well, there are a few things to consider here when setting up the new SAP instance. Should it be in its own separate environment, so it is accessible for the buyer during the TSA phase? Should this environment be moved into the cloud to save costs? Or, even more complex from the IT side, would the buyer work on the seller’s system for some time and take over the carved -out system some months after the actual closing date – a 2-phase approach with two different systems involved?
TSA’s are just another wrinkle to consider during SAP carve-outs, and can play a significant role in how we execute them from a broader, landscape perspective. And they may make SAP Carve-Outs even much more complicated. My advice is to inform your M&A department about options for M&A projects on the IT-side regularly and make them aware of what is an easy to cover scenario from the IT side and what may be harder – if not almost impossible to achieve.
What about customizations like custom z-transactions or z-reports?
This is often overlooked but is very important to understand. I’d say it is safe to say that no SAP customer exists without their own special z-transactions or z-reports. Why? Because this is part of their DNA, their way of working and approach towards their customers and processes. Something that makes every company special.
Some M&A agreements may include the transfer of all SAP customizations to the buyer as part of the agreement. Some on the other hand, do not. In some cases, these transactions or special customizations are considered intellectual property, and could reveal a competitive advantage to a rival entity during an unfriendly carve-out. Especially when selling to a competitor, it is extremely important to home in on these very granular details, as small as they may seem. You never want confidential data, or proprietary SAP custom code in the hands of a competitor.
Are Z-codes part of the agreement?
If they are not, it is important to understand the additional effort that will be required to configure these in the new target system. This adds yet another layer of complexity, and something else to keep an eye out for prior to executing an M&A deal. More complexity always means more effort which means additional cost. If configuration wounds up being different between source and target system, mapping and validation become crucial to ensure data integrity and business continuity are maintained.
What about 3rd party software and interfaces?
Many organizations have taken a best-of-breed approach when it comes to their ERP landscape. Let me just name some examples I have seen in the past. For Customer Relationship Management, organizations may be using Salesforce, Sugar CRM, or Zoho for example. For Human Capital Management they may be using SuccessFactors (owned by SAP, but cloud-based and not part of core SAP ERP), Workday, or BambooHR. This applies to a variety of other different functions like Warehouse Management, Transportation Management, or external Business Warehouse systems for analytics and reporting. It is not uncommon for organizations to have a 2-digit number of external systems connected via a web of interfaces to ensure they work cohesively as intended.
You don’t need an expert to tell you that it is necessary to understand what interfaces will be necessary in the target system, to know what to do in the source system. Some interfaces may be ok to be carried over, some may need to be rebuilt (ie. SuccessFactors on the source side, to Workday on the target system). How do you ensure continuity during the handover? Can the third-party products even be split? If so, who’s responsible for this? What about other interfaces to involved parties like EDI with customers and vendors?
It is important to understand these aspects of the carve-out early on, to avoid costly surprises during an already tight project timeline. Remember, unexpected bumps in the road come at an extremely high cost, since timeline cannot be moved in most cases.
These are some of the reasons why engaging specialized partners with vast M&A experience on both the technical and business sides of the equation will help better prepare for mergers or acquisitions. Stay tuned for next weeks final post on how all these things tie into a Transition for SAP S/4HANA.
To stay connected follow me here @lorenzpraefcke
