I have actually been involved with several different Divestiture projects throughout my career. Rather than discussing individual projects, it is probably best if I discuss the divestiture process in general.
For those unfamilar with the concept of a ‘Divestiture’, I will define it as simply the selling off / spinning off of one particular segment of an organization. In terms of IT infrastructure, this usually involves “standing up” that portion of the business in its own system. In general, the divestiture projects that I have been involved in have several common components:
Analysis
The analysis phase typically involves a detailed discovery session in which the scope of the business to be carved out is defined. Often times, this is not a difficult process as those types of details are usually spelled out during the sale of the entity. From an SAP consultant’s perspective, we typically try to answer the following questions:
- High level strategy for migration
- List of relevant Organizational Structure objects to be migrated
- Key dates for determining when the project must be completed
- Key date(s) for which data is kept vs discarded
- Define the process and requirements for data cleansing
- Identify any legal requirements/challenges for access to parent company data.
Standing up the new Server
The first step during realization is to find a temporary home for the current live system. This can either be hosted by the parent company or by a third-party hosting partner. As a consultant working for the divested entity, you must be careful. The configuration and the data may still be largely “owned” by the former parent company. Be sure to get permission to access that system.
Configuration / Remediation
There are most likely going to configuration changes needed in order to stand the entity up. This can either be the addition of new Organizational elements or their removal. At minimum, you will most likely want to adjust things like Company Code names, Plant names/addresses, etc.
Development
There will most likely be forms that need to be modified to show the new company name. In some cases, we modified report headers to either change or remove hard-coded titles and labels to reflect the new organization.
Also in the Development realm are system interfaces. A thorough review of legacy interfaces should be performed to determine whether the interface should be retained, replaced, or removed. Examples include EDI, bank interfaces, and other “bolt-ons” previously used by the parent company. For complex interfaces, retention and replacement can often be projects on their own. I have found it wise to place a lot of focus on such efforts.
Data Cleansing / Archiving
This can be the most challenging activity to complete. Chances are, you will receive specific instructions on what type of data CANNOT be retained by the new company. This is commonly customer information, vendor information, financial transactions, pricing records, and transactional history. All this data will have to be removed from the new system. I have had experience with two different approaches for achieving data cleansing:
- Third-party Tools
On one project, we were legally prevented from accessing any data belonging to the former parent company. In this case, we had to make a config-only copy of the system and bring over only the cleansed data. To achieve this, we leveraged a tool called Gold Client developed by and facilitated by Hayes Technology Group. Using the Gold Client tool, the team developed a set of rules to selectively migrate only the relevant data into the the config-only system. While the tool worked well, the large number of affected tables made migration a bit of a trial-and-error process. During cut-over dozens of tables were found to be lacking critical data making it necessary to do on-the-fly data migrations. - SAP Archiving
In my experience, SAP Archiving is definitely the most straight-forward approach, but can also be time-consuming. Since SAP has very strict criteria for archiving tables — especially transactional tables — it is necessary to get all the documents into a ‘completed’ status. This sounds like a simple process, but can be troublesome in mature systems where hundreds of documents can remain open for myriad reasons. Making things more complex is if configuration has changed since the erroneous documents were created. In many cases, we were forced to resort to manual record deletions from tables to complete cleansing. While this is NEVER recommended, it was the only alternative.
Summary
This turned into more of a lessons-learned exercise than a project profile. My opinions above are a result of involvement in 4 divestitures — some of which were highly successful, and some of which were less successful. Ultimately, the simpler the migration strategy and the less red tape you have, the better.