Mergers & Acquisitions – How to deal with multiple ERP systems. Part 1
Posted by Jonathan Travers
Acquisitions are common across almost every industry today. But what impact do these mergers have on a company’s IT systems, specifically its ERP system?
How Does a Corporate Takeover Affect the ERP System?
Corporate acquisitions are par for the course across almost every industry today. But what impact do these mergers have on a company’s IT systems, specifically its ERP system?
A corporate takeover involves more than simply integrating different systems – usually the various systems need to be separated as well. As part of the acquisition deal, the merger party might agree to continue using the existing ERP system for another year, after which the demerged company will be left to its own devices. But will one year really be enough to integrate all business processes into the existing ERP system? Or are there strategic reasons for running two ERP systems side by side?
These are all questions Redfaire International regularly fields from clients. So what are some of the factors to consider? What sort of issues are you likely to encounter, and what approach will you use in resolving these issues? Below we have outlined our solutions for both scenarios: company sale versus company acquisition.
This is a scenario commonly encountered among our client base. Suppose Company X is running Oracle JD Edwards ERP and has used the application to configure multiple companies and business units, including manufacturing companies, distribution companies, service providers, or any combination of the above.
The solution depends, first, on the terms agreed by the parties when closing the sale. Will the new owner continue to use JD Edwards ERP, or do they intend to migrate to the acquiring company’s ERP system?
Obviously, we would prefer to continue using JD Edwards and consolidate the system with that of the acquiring party. We can divide this process into the following three stages:
Separating operating processes and security
Physically separating the systems
Cleaning up data in the separated systems.
Stage 1: Separating operating processes and security
We will start by investigating which processes will be separated for the companies listed in the JD Edwards system. The most common process here is the supply of goods between two or more affiliates or business units of the same parent company; other examples include Shared Service Centers in accounts departments (Accounts Payable and Accounts Receivable) or in customer service departments.
The first step in this process is the separation of the companies in JD Edwards by adding a company security feature. Once this step is completed, employees of Company A will no longer be able to access Company B business processes and data, and vice versa. And this is typically when the trouble starts... Shared customer databases, shared product databases and shared MRP for production control all contain a set-up and master data which turn out to be faulty following the security separation. In other cases, they may no longer even be available.
We therefore make a point of carefully checking all business processes first and analyze how the data is used. The next step is to start planning the unbundling of the processes and data and – if this is not in place as yet – make plans to separate security from the test and acceptance environments and the manufacturing environment. This separation of security allows us to test using security applications without immediately disrupting the manufacturing environment in case anything is overlooked.
In order to figure out intercompany supplies or transfer orders between operating companies and warehouses, the financial settlement process will also need to be carefully reviewed, along with logistics flows. We will set up a new intercompany supply process for this purpose, based on a scenario where Company A and Company B become each other’s customers/suppliers.
Once this entire process is completed, we will implement the separate operating processes and separate security feature in the manufacturing environment. The outcome? A single JD Edwards environment in which two companies can operate independently from each other.
Stage 2: Physically separating the systems
We then move on to stage 2: the actual, physical separation of the hardware. We generally purchase new hardware for this purpose, on which we then install a copy of the JDE instance system currently running. Besides JD Edwards, we also need to factor in all other applications connected to the ERP system via various interfaces. This also includes, for example, AP Scanning (e.g., ISP Invoice), document formatting software, external WMS systems, external production planning systems, and scanning systems.
As applications will need to be copied across the entire IT infrastructure to create an identical, mirrored situation, the process of copying all the systems also requires extensive testing and a long lead time. Once the system is up and running, there are two systems which can run independently of each other.
Stage 3: Data Cleanup
After the system separation, all the old data is still stored in both environments. While it is possible for the parties concerned to agree on a set of contractual terms, experience has shown that this data is always cleaned up in at least one of the two systems. There is an overlap in time between the sale and the physical division, which means the new company owner’s data is still stored on the old owner’s system – we generally leave this data intact.
When it comes to cleaning up the data, we prefer to use SQL queries. Caution is required here, as you cannot automatically clean up all data: specific data – including the above-mentioned customer data and product data – is always difficult to clean up. In addition, there are tables which do not contain Company or Business Units fields in JD Edwards and that require specific attention. Maintaining the integrity of the database is obviously a key priority.
Database in place at the time when stage 2 is completed.
Sector I, data from Company A preceding the sale → property of Company A and must be deleted from Company B’s system.
Sector II, data from Company B preceding the sale → property of Company A. Both environments will continue to contain data
Sector III, data from Company A dating from after the sale → property of Company A and must be deleted from Company B’s system.
Sector IV, data owned by Company B dating from after the sale → property of Company B. The question is whether this should be cleaned up in Company A’s database.
The most common scenario: in Company B’s database, we clean up sectors I and III. We leave Company A’s database intact, refraining from performing any operations. Data in sector II was property preceding the sale. Cleaning up the data in sector IV alone is complex and time-consuming; in addition, this data is largely similar to the data still contained in sector II, except it dates from a later period. We often skip this clean-up process because it is so labor-intensive; instead, we sign a contract with the party concerned to agree on the arrangements to be made.
If you’ve made it this far, well done! How about reading Part 2, where we cover some of the steps required for acquired companies? You will find it here.
Please complete the form and our Global Enquiries team will be in touch to help you.