Should I force our ERP onto an acquired company

Anonymous,

The last time I did this, in a pretty similar situation, I tried getting my sub onto our ERP. It was honestly easier to keep going on their old system, so I kept it live during the transition. This allowed the team to keep the old processes alive while transitioning to the new (and very largely similar) processes, along with having a live failover in case the new system had hiccoughs (which it did). The downside was the duplication of effort.

Manual consolidation has three big downsides for me. 1) Effort...it takes a lot of time. 2) Third wheel problem...if you are on two systems then you can consider the consolidation to be a third part of that, which will need to be frequently and carefully attended to. And it may well break. 3) Information...if your acquisition is part of the larger picture, giving a live consolidated picture to your team is either not possible or requires yet another system.

I personally don't like the transition at all...in a way it is expending a lot of effort to fix something that is not broken. The problem is, that thing that isn't broken isn't what you need to really operate efficiently.

Contrary example: another acquisition that I was a part of we kept the old system. The new parent *deliberately* wanted us to have our own systems and processes. Any synch would be at the strategic level. There would be (and is) no live interaction at the tactical level. In that case, keeping the old systems (and their processes) reinforced the idea that the acquired company was to keep doing business as usual.

Note, this one was bumpy as the acquiree is public...so having that lack of visibility, and honestly lack of synchronicity in reporting (we even kept a separate close cycle) required serious aircover from exec management on the acquirer side. With that aircover, and the effective separation, the acquired business was able to continue to run as a *going concern* which was the intent.

Conclusion: I suggest you decide if this needs to be integrated or not. If not, let it thrive. If so, take it slow.

I was involved in three major M&A transactions between 2000 and 2009. In my experience the answer breaks down into three main areas: technical, strategic and HR/Cultural.

On the technical side, post acquisition there were numerous ERP systems (various versions of SAP, Oracle, JDEdwards and even bespoke systems) and consolidation systems (versions of Hyperion). There was a lot of debate about which system was best with each side fighting hard for their answer. As long as they were able to send in accurate numbers for consolidation in the timeframe set by corporate there was no rush to uniformity, but anybody who held up the process had to conform to the corporate process or be fired.

On the HR/Cultural side, firing people early in the integration process can leave you without detailed knowledge of what you've acquired at a time when you are hard pushed to work on synergies and understand the numbers you do have. If the culture you're aiming for is de-centralized then forcing compliance will work against that, but if you have a culture of conformity and centralization then forcing one system on all will help build that culture and identify the folks who aren't going to fit. If your finance team are also implementing changes to procurement, payroll systems, GAAP, then implementing new ERP systems and Charts of Account could be a huge distraction.

On the strategic side, the acquisition must have certain targets/ justifications and it's unlikely that accounting conformity was one of those targets. If you start trying to change systems and that interferes with operational success nobody's going to thank you.

The answer depends to a large extent on the size and complexity of the new organisation. If you do decide to implement one system make sure you have a good change management process and team.

There are many businesses that are contemplating this same situation, where the claim is their legacy system is optimized for current use. Things to consider in that scenario boil down to cost to maintain the on-premise system and scalability. (High relative cost, low relative scalability). If you haven't actually analyzed the total operating costs for their system and compare it to your system, perhaps your gut has already done it for you. Your cloud based solution is the solution if your Company want to save money and operate most efficiently. And if your ERP solution is already unified with your other systems, you are already way ahead of many businesses who are still working with many on-premise, integrated systems which they need to maintain.

Why not perform a best practices analysis of the needs of the sub and the needs of the parent; how the software they are using and any interface needed in moving roll-up data and see whether the dollars and needs reduce TCO and improve the ROI while NOT affecting productivity?

Lots of great insights here; one dimension I would add is that you closely examine your software and support agreements with both your cloud provider and the target company's ERP vendor to evaluate the additional user license fees etc arising from adding the target company users.

Ultimately, make sure your argument for a single solution rests on a solid business case, including the costs of changing processes, risks of non-fit, adding more functionality, re-training, data conversion/migration etc.

I second Mr. Spivak's comments, you need to perform detailed analysis on the needs of your company, the acquired company and any customizations that they have performed to their ERP systems.

In your original posting, you said you are on a cloud-based ERP solution, to me this is a "red-flag". If the acquired firm has made some significant modifications to their ERP system and you can not make those changes in your system, you may hinder or destroy their business.

Typically, cloud-based vendor will not or do not like to customize their solutions to their clients. If a vendor allowed for customizations, they would have to support many, many different iterations of a single ERP version. For the vendor, this poses a problem in supporting their hosted ERP solutions and when the ERP systems is upgraded (need to make sure the customizations are still functioning after the upgrade for each and every client).

Most people claim the cloud-based solutions have the lowest "total cost of ownership" but a cloud-based solution can hinder a business from performing at an optimal level (i.e. causing business process inefficiencies; a cost that is hard to quantify).

Bottomline (like Mr. Green stated), you need to build a solid business case, after conducting some detailed analysis. In the end, you may find it easier to migrate everyone to a totally different ERP system all together.

Similar considerations for HR / HRIS integrations and question should be posed (under same scenario above) whether the customizations were required and if a more vanilla version would have achieved the objectives. Try to avoid having a "legacy manual workaround ". I have seen acquisitions that weren't well integrated and always viewed as an "orphaned" or "special" business unit (and in the extreme cased got divested / resold).

Hi all

I'd like to make a case for clarifying "customizations." I often encounter situations where people (whether business users, IT system support staff or software vendors) actually mean "configuration" not "customizations."

When we lead software evaluations for clients, we encourage people to understand the following:

1. CONFIGURATION is a desirable capability of software, whether SaaS or on premise. It means the ability of the user to make setup changes to the software so that it can support different business needs, or changes to the original business model. It means that you are NOT changing the code of the software or adding outside software to provide the desired functionality. You obviously need to learn how to do this, but that's a role for the power user anyway.
Example: adding a second order type to the sales order process; adding a new discount rule, or updating sales prices.

2. CUSTOMIZATION is undesirable and should be avoided as far as possible. It means that you can only get the desired functionality by:
a- adding a custom built application that needs to be integrated with the target package, and which will need IT involvement to design, develop, test, implement, maintain and modify when upgrades to the target package happen and/or
b- changing the core code of the target package, which means that upgrades are likely to be both time consuming and costly. It also means you have a unique version of the software, no other customer has what you now have.

In simple terms, you need to customize because a GAP exists. By definition, when you configure, you are simply exploiting the flexibility of a system with inherently better features to accommodate NEW needs.

Finally, these "rules" apply to both Cloud/SaaS and on premise ERP software.

Bottom line, you need to examine the overall information architecture (not the information systems or IT infrastructure), and how it is integrated. Don't look at your ERP system as a standalone system (or in CIO speak a data silo). Remember data is used through out your company and the acquired company, your task (and your CIO's) is to determine the optimal solution for BOTH companies.

This task can be a daunting one, considering the detailed analysis that needs to be done at both companies in short order. Unfortunately, without the detailed analysis you can not make an informed decision. Good luck!