Mergers and acquisitions create an inevitable — and sometimes immediate — need to realign IT systems and landscapes. The key to a successful realignment project is preparedness. Understandably, this is not always a simple and easy task due to the confidential nature of the underlying merger and acquisition (M&A) business transaction. The goal of this article is to provide you with some basic information so that you can become better prepared for such realignment projects in your organization and potentially anticipate changes before they occur.

Based on my experience, I’ll discuss various types of realignment projects and evaluate the kind of SAP system changes and requirements that might arise after a merger or acquisition. I’ll describe the various characteristics of each change and explore how mergers and acquisitions impact master data and structural elements (e.g., company codes, plants, or sales organizations).

In the last section, I’ll examine tools and best practices available to assist you with realignment projects, including advice for performing a comprehensive analysis that accelerates project preparation and system landscape optimization (SLO) tools that accommodate the unique modifications required during realignment.

Common Characteristics of a System Realignment Project

I’ll delve into some characteristics of a typical IT and systems realignment project that results from a merger and acquisition (M&A). The three key aspects I’ll focus on are confidentiality, short time lines, and business process realignment.

Confidentiality

M&A transactions are generally very confidential until immediately after closing the deal. Terms and exact timing are vague and unknown to anyone — except for a small group of negotiators — until the very late stages of the deal. This fact poses tremendous difficulties for all aspects of the project preparation and project planning. To appropriately plan and prepare any IT project, you need to establish an understanding of functional scope, the organizational and procedural changes that result from the transaction, and a realistic time line.

As deals are in negotiation, such information is not readily available — and even if it is available, it might change along the way. For example, in one of my recent realignment projects, we were tasked to start preparing for a carve-out of a business unit (BU) that was being divested. After the closing date, the business unit was supposed to have its own SAP system with access only to the data relevant to that business unit. The seller’s IT organization would support this SAP system for the buyer for a period of time.

Although this information initially gave us some information to start the thought process, it actually generated more questions than it answered. Some of these questions included:

• What degree of separation would be appropriate for this carve-out?
  
  
• Would a separate client on the same ERP instance suffice, or would the terms of the deal necessitate a completely separate instance?
  
  
• Would they need historical data at the transaction level or at least summarized sales and profitability numbers for comparison and trend reporting?
  
  
• How long would our IT organization support the divested BU? Would it be long enough to require a long- term plan in terms of support capacity and hardware sizing, for example?
  
  
• What would happen after the support period? Would the business unit get off the ERP system and possibly migrate onto the buyer’s own ERP platform, or would they keep the carved-out ERP system for the foreseeable future?

As with every project, there is always a plethora of questions that must be answered. Finding the answers and agreeing on an approach is always a difficult and daunting challenge. This is exacerbated in an M&A scenario, in which a third party is involved and sensitive, high-level negotiations are taking place. To make matters worse, the confidential nature of M&A transactions often prohibits open discussions at the lower levels of the functional areas where all of the business process details, and many of the questions, require extensive discussion.

These kinds of projects are usually planned on ambiguous and fluid information or requirements. You often find yourself preparing for several potential scenarios while waiting for requirements to be firmed up.

Short Time Lines

Once the deal is finalized, the timing parameters are generally unfavorable from an IT and system realignment perspective. Certain aspects of change take immediate effect and must be implemented almost instantly because organizational changes are ramped up and implemented. These changes are typically in the reporting and financial areas because the final closing is being prepared. All time lines following the formal announcement of any M&A deal are relatively short and all deadlines are firmly fixed. Missed deadlines are commonly associated with penalties towards the causing party. Therefore, IT realignment projects following an M&A transaction are under tremendous pressure to deliver the expected results without the slightest delay. This reality underscores the importance of the preparedness factor I mentioned earlier.

To exemplify this scenario, I’ll provide you with a situation from one of my recent projects. A business unit was being divested to a financial investor without any internal IT capabilities. The ultimate goal of the project was to create a new, fully functional SAP instance for the business unit that was being divested. It was of utmost importance to ensure that the new system and the users were completely ready on the first business day following the closing date, as constituted in the sales agreement. These are the types of deadlines that are absolutely non- negotiable and require a prepared team of experts.

Business Process Realignment

Often only parts of a company (e.g., business units, product lines, or geographies) are acquired or divested. Such projects are not limited to system realignment. They also include significant business process realignment to cope with both the segregation of operating business units from a corporate structure and their integration into a new one. It might even create situations in which an organization must perform tasks or provide services that are completely outside of its core business and primary capabilities.

The selling party might find itself providing IT hosting and application support services to the buyer for the divested business unit. This is frequently the case when the buyer is not interested in or capable of integrating the new business into its corporate and IT structures immediately. For example, financial investors who don’t have an elaborate corporate structure to support the variety of businesses in their portfolio are managing these hurdles. Deals are also often structured with transitional periods to minimize the disruption to the operations. During the transition, the seller agrees to continue providing certain services to the business unit for an agreed period of time. These types of deals create similar situations in which the seller might need to implement new business processes or change existing ones to comply with the terms of the deal.

I’ll use an example from one of my most recent realignment projects to illustrate this point. A business unit was divested to a financial investor. In this case, a shared warehousing and distribution facility was used among several of the seller’s business units. The divested business unit would continue to use the facility and the services after the closing date. Shared warehouse space had to be realigned to allow for due segregation of inventories and inbound or outbound movements.

Although this example depicts typical business process changes and system realignment, the change also constituted a major shift in business processes and system modification in the seller’s organization. For the selling party, a facility that was previously a warehousing and distribution facility for internal purposes required a complete redesign to become a public warehouse. A public warehouse is one in which the warehouse and distribution center operators provide services to multiple tenants. This change necessitated the implementation of processes that allow more detailed cost controlling mechanisms, sale of warehousing and distribution services, the legal aspects of conducting such business, and many other details that demand consideration.

Solutions to Avoid Pitfalls

The following section contains a few common M&A scenarios, potential solutions, approaches, and key considerations that should help you prepare the IT realignment projects that would follow. While it will take many hours of detailed discussions to determine the most suitable approach in each individual case, I’ll attempt to point out the types of decisions required and the types of major and minor considerations that facilitate the process. Of course, there are many more conceivable scenarios beyond the ones mentioned in this article. The common criterion for the scenarios I’ll discuss is: they all represent separating organizational units into different legal entities and companies (carve-out projects), or merging organizational units or companies (system mergers).

Key Considerations

To establish the best approach in any of these scenarios, you must answer a series of critical questions. Keep in mind that the answers will likely be tentative at first, so you should consider them with appropriate likelihood. The combination of all available information and the careful assessment of short- and mid-term needs determine the one approach or potential approaches.

Transaction roadmap and longevity of each transitional stage: Is the target structure a transitional step? If so, is the realigned IT system design expected to be temporary, or should it last for the foreseeable future? If it is expected to be temporary, what is the expected next step? IT projects with any kind of system cut-over can be a burden on the business operations and the people involved. The process always includes manual steps, loss of history, change management, and a learning curve. To address the transaction roadmap question, I suggest evaluating how the following steps could be prepared during the first step so you can reduce the amount of cumbersome tasks in subsequent steps.

Target level of segregation (or conflation, in the case of a merger): What level of both organization and system segregation is required or desired? There are many ways to structure separate legal entities within an SAP system landscape — from the least segregated units represented by business areas, to individual company codes to separate SAP ERP clients on the same instance, to distinct SAP ERP instances. The more independent the units or the more likely it is that a complete separation will follow an interim structure relatively soon, the more one would lean towards the most segregated org structure and landscape options.

Relevancy of historical data: One of the issues that is always discussed during the preparation phase of a carve-out or merger project is: What happens to the historical data? Historical data can include summarized figures of sales, profits, cost-center and cost element budgets, and detailed transactional data. The answer to this question depends on the terms of the M&A deal and the needs of the business. If a business is sold in its entirety — including all history and liability for the historical operations — then at least one aspect of this question is easy to answer: let’s keep or carry over as much of the historical data as feasible.

If the transaction is an asset deal, then the answer is not as clear. In this case, historical data at the transactional level is often not considered as part of the deal. Instead, it remains on the books of the selling party. The other important aspect when dealing with this question is what the business requirements are to function properly in its new form and structure. Summarized sales and budget numbers are a likely resource for future planning purposes and performance trend reporting.

Applying Best Practices

Next, I’ll review common carve-out and merger scenarios and examine how you can apply these key considerations.

Business Unit Is Converted to Distinct Legal Entity

In this example, the business unit is restructured into a separate legal entity. Although this scenario might not be defined as a true M&A transaction — rather, it is a restructuring measure — it is still worth mentioning here because it is often performed to prepare for a potential divestiture. A separate legal entity with its own transparent financials and some level of independence is of course much easier to divest than one that is completely intertwined within a large corporate structure.

For this situation, the question of longevity is a strong determining factor. This is a typical scenario in which segregation at a company code level is most likely to offer the best fit. However, based on my experience, if a divestiture follows in short order and the divested business unit must continue to operate on the system that is being designed and built in this project, then a separation into another client or instance is probably the better approach. The consideration of level of segregation and historical data are more relevant for the potential next step, divestment.

Business Unit Is Divested

In this example, the IT realignment project depends largely on the terms of the deal. For instance, if the purchaser is planning to integrate the acquired business unit into their IT environment and business system immediately, the realignment project will be reduced to a data extraction exercise and a subsequent retirement of all organizational elements associated with the divested business unit.

On the other hand, if the divested business unit is provided with an IT system, then you need to look at both the longevity and level of segregation and the historical data considerations. The expected longevity determines whether more effort is put into building a solid system landscape and support structure or if a quick and less than perfect solution is preferred. A solid system for the long run would be one that is not only copied, but also adapted to contain only the design and the data relevant to the divested business unit. As a quick solution, you could define this as an identical copy of the seller’s system, where irrelevant configuration and data still exist and are only made inactive or inaccessible.

Although this approach results in a less than ideal system (carrying the baggage of the old parent company forever), it simplifies the retention of historical data. It is also the approach with the least amount of effort for a cut-over. In my experience, I’ve seen companies favor the short-term advantages of this ap­proach, which leaves the business with a less than desirable system for the long term.

Business Unit Is Acquired

This scenario is similar to when a business unit is divested, only it’s considered from the buyer’s perspective. Therefore, I’ll focus on system merger options. All the remarks under the previous section apply to this scenario, including the ability to integrate the newly acquired business unit into an existing system landscape and the hist­orical data requirements that drive the decision of what to ask of the buyer as part of the deal.

Assuming that the acquired business unit comes with an existing SAP ERP system landscape, there are generally two methods of integration into the corporate SAP landscape. Following a traditional approach, the new business unit is set up in the existing corporate SAP landscape with the creation of company codes, plants, and sales organizations. Then the relevant master data is copied or migrated, and a typical cut-over scenario completes the process. The only downside to this approach is that no consideration can be given to historical transactional data. This means that in addition to going through two cut-over steps (carve-out from the old landscape and integration into the new), the acquired business unit could lose its historical transactional data if it’s not already lost during the first step of the project.

As an alternative, SAP and third-party vendors offer technical merger tools. These tools facilitate the migration of transactional data by copying the data records through operations at a database level. These tools, also known as SLO tools, offer assistance with other realignment scenarios, such as company code mergers; company code splits; and the reassignment of plants, sales organizations, and purchasing organizations from one company code to another.

Entire Company Is Acquired

This scenario is similar to a business unit acquisition, only in this case, the acquired company always comes with an existing IT system landscape. The same two merger approaches apply, namely the traditional approach, in which one system is considered a legacy system, and the technical approach, in which the systems are merged technically to create one system that contains the history of both systems.

Additional considerations to ensure your project’s success are:

• Dealing with licensing issues
  
  
• Managing interfaced peripheral systems
  
  
• Coming up with smart organizational structure designs that allow the operations of shared services and facilities under the changed structure
  
  
• Coping with change management
  
  
• Working with the human aspect of these highly stressful and often politically charged projects

Ali Sarraf

Ali Sarraf is the managing partner at Enowa Consulting. He has 15 years of experience as a senior consultant for SAP Business Suite applications and 20 years of IT experience. During much of his career, he has focused on helping customers optimize their logistics business processes by analyzing and explaining cause-and-effect relationships and by bringing the machine and the human sides of IT closer together.

You may contact the author at ali.sarraf@enowa.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.