How to deal with multiple ERP systems. Part 2 - Acquisitions
Posted by Jonathan Travers
Acquired or sold? Dealing with multiple IT ERP systems? We discuss some of the steps we take when helping acquired businesses sort out their ERP strategies
The scenario when we’re dealing with the acquisition of a company, is altogether different to the company sale approach outlined in Part 1. In this case, the first step is to determine whether we continue with one or two ERP systems. We have found that the preference is generally for a single ERP system; that of the company making the acquisition (the acquiring party.)
For our clients, this means that a new company and ‘new’ business processes must be added to the existing JD Edwards model. It makes a difference, in this case, whether the acquired company runs on JD Edwards ERP or another ERP application.
Scenario 1: The acquired company does not use JD Edwards ERP and abandons their old ERP system
If the acquired company does not use JD Edwards, we are basically dealing with a regular JD Edwards implementation. In this case we need to be mindful, however, of the existing set-up and processes and procedures at the parent company, which already uses JD Edwards.
An analysis is required in order to identify, and compile a list of, all the business processes of the acquired company. Are these processes aligned with the existing JD Edwards processes, or are they different? These processes tend to be incompatible, even if the business of the acquired company is identical to that of the new parent company. Every production facility or distributor tends to have their own procedures in place, or sometimes certain attributes, which may or may not be country-specific. Regulatory requirements can often also come into play.
The trick is to identify and mirror this as soon as possible with the existing processes (and documentation.) Change management or decisions at the appropriate level are key elements here when it comes to causing the least amount of resistance to the integration. This should be based on an integration of systems instead of an all-new second implementation. At the same time, it is also important to factor in the identity and independence of the acquired company.
Another important factor is data conversion: this process should not be underestimated, as it involves the collection, clean-up, elimination or closure of data from clients, suppliers, prices, product data, outstanding invoices, and so on. These are eventually converted into a dataset to be imported into JD Edwards ERP. It may be necessary to deduplicate items if both companies stock identical products.
Another area of focus is on documents used by the company (including invoices, packing slips/waybills, purchase orders, payment reminders, etc.). Have we checked that all documents comply with the relevant government regulations, or are there specific reasons to print certain data? The biggest pitfall in this process is the old “We’ve been doing it this way for years, so why change?” chestnut.
We are obviously not interested in turning all business processes on their head: we simply recommend that clients use their common sense in finding reasons as to why certain things need to be done a certain way, or why they would choose to organize and manage business processes that way.
Scenario 2: Both companies using JD Edwards as their ERP system
You might think this should be easier, but this is not always the case. While the data conversion may be less complex because the table structures are identical, the set-up could be completely different. This might include for example, the use of category codes for items or clients. There is a need for a thorough data conversion analysis and data conversion process. This involves some of the same operations as described above, including data clean-up, deduplication of identical data, etc.
We often also have to deal with two different system versions, for example, JD Edwards EnterpriseOne E9.0 and E9.1. So what is the preferred strategy in these cases?
Do we choose to upgrade one of the companies and downgrade the other?
Which customized software do we copy from what systems, or do we combine various customized solutions instead?
Will we upgrade to a new version together, e.g., E9.2?
In this ostensibly more straightforward scenario, we essentially encounter exactly the same problems as with the integration of two different ERP systems. This creates a need for prioritizing process analyses, documents, formatting/layout, government regulations, sales tax regulations, data conversion, customized analysis, security, menus, etc.
Don’t think this is all there is to it – it’s really just the tip of the iceberg. This outline of the process involved in ERP separation or ERP integration does not factor in the consolidation of hardware or networks – or aspects such as email integration, for that matter. These are issues that JD Edwards ERP consultants may not deal with directly, but which do play a key role in these processes. The infrastructure, office software and the integration or division of this infrastructure are at least as important, and each of them have their own impact on the ERP projects.