In my previous article, I explored some of the economic and political trends that are shaping the global M&A market and touched on the impact on SAP customers and their systems. Here, in this article, I would like to delve deeper into what happens when a company divests of a business and needs to separate, or “carve out”, the relevant parts of its SAP landscape in order to provide them to the buyer.
What do these projects involve and how do they differ from, say, an implementation project? And what can the involved parties do in advance to prepare?
Background and history
For around 15-20 years, from the mid-1990s when large and multinational companies around the world started adopting SAP R/3, by far the biggest driver of data migration was the implementation of SAP R/3 (or later SAP ECC). Then, once we reached a critical mass of organisations running SAP, it started to change. I remember Andreas Schneider-Neureither making the case in 2016 that we had passed from an era of implementation to an era of transformation where the priority of SAP customers was to remodel their systems in response to new developments in technology (HANA, cloud, artificial intelligence, etc) and changes in their business.
I thought that was right then and I still do now. In my next article I will look at S/4HANA, which looks like being one of the most important technological changes in the market over the next 10 years, but for now, I would like to focus on business change, specifically the impact on SAP customers and their systems when companies sell, or divest, a part of their business and need to separate, or carve out, their SAP landscape.
One of the most significant changes that a company can undergo is an acquisition or a divestment. It fundamentally affects what a company is, what it is and maybe even how it behaves. A carve-out project is similarly transformational, recasting the shape, size and scope of a company’s SAP landscape.
Technical approach
So, at a technical level, what is it? While occasionally the term “carve-out” is used very generally to mean any project that involves extracting data from SAP following a sale or a spin-off, it is normally used to mean something much more specific. For me, a simple data extract is not a carve-out.
A carve-out has two core components: first, the cloning of the SAP application itself (including the technical repository and the configuration and customising of the system) and second, the migration of all (but only) the application data which relates to the divested business. This generally includes the full set of historical transactional data. There are two ways to achieve this: you can either take a full clone of the original system and then delete the application data which is not relevant to the sale, or (and this is, in my opinion, almost always the superior option) you can create an empty clone of the system before migrating only the relevant data. Both options require the deployment of a landscape transformation software.
It is that combination of a system clone plus the use of a landscape transformation software to selectively migrate or delete the application data which defines a carve-out project. This approach is incredibly powerful. The cloning of the original system – recreating the new environment ex materia – avoids the requirement to design and build from scratch which cuts effort, time and risk; landscape transformation software allows us to safely modify SAP systems at a table level through an in-built understanding of the SAP data model, which delivers high performance and the ability to replicate entire sections of a system; and the effective decoupling of the application from the data provides real flexibility, allowing us, for example, to combine a carve-out project with a move to cloud and an upgrade to S/4HANA, all in one single event.
As with many new developments in SAP, the concept of landscape transformation software came out of Germany. SAP’s own DMLT team (formerly SAP SLO) specialise in this kind of approach but a lot of innovation in this area takes place outside of SAP in two or three specialist technology companies. At Xmateria, we use Natuvion’s excellent DCS landscape transformation software to help customers separate their SAP landscapes in the event of a divestment or a spin-off.
Project considerations and characteristics
I mentioned earlier that there are two possible approaches to a SAP carve-out: you can either clone the entire system and then delete what is not relevant (“clone and delete”) or you can create an empty clone and then selectively migrate what is relevant (“selective carve-out”). In my view, the second approach is far more flexible and controlled. You can derive more value from the project through incorporating technical improvements (cloud, upgrade, etc) and process change (eg chart of accounts transformation). And you have more control over what data is transferred from the seller’s landscape to the buyer’s. This ability to define, control and validate the data which leaves the original system is typically of prime importance to the selling party.
I have touched on the concerns of the buyer and the seller. One of the defining characteristics of a carve-out is the complex and competing set of priorities that lies behind the project. The buyer will normally want a cleanly separated and fully functional SAP landscape as a result of the project; it may even want to drive further value through an upgrade or a package of process improvements to be delivered as part of the carve-out. However, unless it has committed to delivering a carve-out under the terms of the deal, the seller may be reluctant to provide a carve-out of its own system and prefer to deliver only a bundle of data extracts. For the buyer in particular, it is important to understand and agree requirements at the earliest possible opportunity.
However, both parties will be under similar pressure to complete the project within the timelines set out in the transition services agreement (the TSA). Whereas most technology projects operate left to right – first define the objectives and the business case, then the requirements, then the plan, etc – carve-out projects are highly date-driven and run right to left. One of the first things a customer will emphasise when we are discussing a carve-out is the date by which they need to have separated the systems. Everything else (plan, approach, even requirements) works back from that deadline.
Risks and challenges
As you can see, carve-out projects bring many challenges. They are highly sensitive, often visible all the way up to the CEO as the closing of a multi-billion deal can depend on the successful completion of the technology separation. They are highly confidential ahead of the announcement of a deal but then carried out under enormous time pressure. There are often two “customers” with both buyer and seller having competing priorities. They touch on issues of data privacy and confidentiality and perhaps post-deal competition, particularly if the buyer is a trade buyer rather than private equity. There is commercial complexity – who is paying, and for what? Finally, it is important not to overlook the human factors at play: a separation goes to the heart of what a company represents with career-defining ramifications for the people involved and their job security. All of these issues outweigh any technical complexity.
Given all of this, you want the technical component – the carve-out of the technology landscape – to run as smoothly as possible with all parties confident in the outcome. How to achieve this? There is work to do across all the normal streams of a SAP programme – technology, solution, change management, integration – but given that there is generally minimal process change, the most important component of a carve-out from SAP is the data, closely followed, I would suggest, by interfaces. As always, it pays to prepare in advance.
If you are a seller, or working sell-side, you need to understand what data you have, what data you will need to migrate, what approach you will take, how you will ensure accuracy and completeness, and what all of that means for a costed plan. For example, are the perimeters of the business you are selling neatly drawn around defined legal entities (company codes in SAP) or is the sale comprised of assets which form only part of a company or companies? If it is the latter, you have the choice of logically separating the assets into a discrete legal entity prior to the system split or embarking on a more complex carve-out project. Understanding the shape and complexity of a future carve-out is something you can get started on, confidentially of course, ahead of agreeing a sale. This is a topic we address at Xmateria with our data discovery software, Pioneer.
If you are a buyer, you should be clear about your own requirements with regard to the seller’s SAP environments and asking the seller, as part of the sale, to commit to delivering those requirements. This means that the CIO and IT department need to be involved in acquisition and divestment deals before they are signed.
What’s next?
In this article, I have tried to explain what defines a SAP carve-out project: the business background, the technical approaches and options, and the project challenges and considerations. At the heart of a carve-out project is the technical concept of landscape transformation. In my next article, I will go beyond M&A and look at some of the other applications of landscape transformation technology, in particular a customer’s journey to S/4HANA.
