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.
can you list out some third party tools available in market for business unit split scenarios apart from above mentioned tools and SLO?
The tools I mention above are the ones that I have had direct experience with. SAP’s System Landscape Optimization (SLO) is a line of services that SAP offers to help customers re-shape their SAP installations — including divestiture activities. I can’t list any other tools specifically designed for divesting organizations within SAP. If there is a list of such tools, I would wager that it’s a short one due to the unique nature of divestiture projects. If I were designing an approach for a divestiture project, I would define my approach first and then determine the appropriate toolset to enable it. That said, I’ve worked on divestiture projects that involved SAP Archiving as a step in the process to purge un-necessary data from the new system.
Michael, Very Interesting article on SAP Divestitures . In fact was also involved in Many Divestitures and our approach was to Copy the Clint and Load the data Via ETL and ALE . Though it was hectic once your ETL programs are ready , subsequent divestitures become easy .
As you rightly said every Divestitures a new learning . How did you address the Historical Data Demand from the Divested company ?
Thanks for the comment. The question of data retention can be a complex one. In almost all cases, the historical data belongs to the former parent organization and only the data created AFTER the divestiture belongs to the divested entity. However, there are certain legal requirements which may impact ownership of data. One example is batch traceability; a chemical company NEEDS to have that historical information on hand in order to comply with potential product recalls. Other data, such as customer sales history, may clearly fall outside of those types of exceptions and become “lost”. Unfortunately, it becomes a legal battle. Some consultants may remind the user base that they have access to data extraction tools in SAP (SE16, SE16n, SQVI, etc.) and that they have the authorization to make local copies of critical business data prior to being kicked out of their former system. It would be up to the users to discard that data by the required deadline. …unless they forget. 😉
Thanks Michael . Also you have mentioned about some tool . How was your experinace working with that ? One of our client needs historiocal Data …So we trying out some option like full System Copy and get rid of the Parent Company’s data etc…..
The tool that we used is/was called ‘Gold Client’ by a company called ‘Hayes Technology’ (I think). However, it was responsible for selectively pulling in data from an external system. It sounds like your client is trying to remove data. I’ve been on a project where we were trying to do just what you describe. We first brought in an Archiving resource in order to purge as much as possible from the database. The problem was that there was a LOT of “leftover” that couldn’t be cleaned out with archiving — incomplete documents, old invoices that were “stuck” due to invalid configuration, etc. We ended up resorting to direct table deletions in order to remove the parent company’s customer, materials and transactional documents. I have yet to hear of an easy way to do this. Let me know if you do! 🙂