This issue alone can lead to so many problems with integration later down the road. Had the acquiring company evaluated the target’s existing software, they would have had grounds to negotiate a better purchase price because of the significant investments that can be required when the target doesn’t have an adequate software solution in place.
It could mean implementing a Customer Relationship Management (CRM) solution such as Salesforce when customer data is spread out among sales personnel’s phones and devices and needs to be aggregated into one accessible and analyzable repository. It could also be Order Management Systems are messy, and pricing is not well understood, and contracts are difficult to find.
The fact is, unfortunately, the proprietary, operational data of any firm might not be contained in the Enterprise Resource Planning (ERP) application; it might just be in a bunch of people’s heads. So without knowing it, without probing into the technology, an acquiring firm could be relying on a set of people who are about to go through an acquisition, and who have yet to establish rapport and trust with the new owner.
On our most recent episode of The ERP Advisor Conference Call Series, we dove into Mergers and Acquisitions and the important factors to consider when merging software and data. There are a lot of factors in M&A where you need to consider ERP, whether you are the acquirer or the target. Even if you are on the sell side, this article will help you get more money into that bottom-line deal because you will be able to articulate the value of your organization’s solution.
If you’re on the buy-side, it’s really important to perform due diligence on business applications before you acquire the company. Your applications are most likely an important part of the reason why you are able to acquire them, and they are at the very least a storehouse of your value.
Operationalizing business transactions is a difficult process, and a company that is looking for a purchaser might not be at that stage.
Look at the organization’s enterprise software. See what the key data is, and see if it’s in the apps, or does that methodology exist only in somebody’s head?
You will be able to tell by asking the organization for detailed reports that drive into key systems, such as the order management system, the manufacturing execution system, the professional service automation tools, resource allocation and resource scheduling.
Pay attention to how the target company is answering your questions. Who’s answering the questions? Who’s able to pull the information together? What systems are being used? Are you receiving a lot of spreadsheets that look pretty but might be manipulated, or are you getting real data?
Looking at ERP will really tell you the undisputed facts of the business. It is really difficult to falsify financial statements in a transaction system, or even in a manufacturing or service application, because you have years of history. Make sure you are asking your acquiree for that information upfront. Their response will also tell you how well they know their systems, and it will show you the relative ease of access. All of these data points, not only the facts of the business, but the metadata regarding how quickly those facts can be analyzed, will be useful.
After doing the due diligence on the acquiree's data and understanding what they do on a deeper level, you see real enterprise value and make the decision to acquire them. There are a number of next steps that you should be taking.
There are a slew of organizational change management issues to walk through that, ultimately, are handled best by senior leadership. In our experience, if senior leadership makes it through, almost everybody else will also make the transition. There will always be a handful of people who end up leaving. We’ve seen this at clients from Fortune 50 companies all the way down to much smaller startups. The organizational issues are workable when senior leaders are committed to proceeding in the right way.
Change management is a red herring. The silent killer is enterprise software integration. While an integration might appear quick and easy, the methodology could be very different.
Traditionally, when organizations would go through an integration effort, you would have two organizations at the conference table, with one organization on one side, and one on the other.
One organization would say, “This is how we do procurement. We do purchase requests, etc.”
Then the other company would take a turn, “Well, here’s how we do it. We don’t do purchase requests, we do purchase orders. And when the purchase orders aren’t approved, we do X, Y, and Z…”
Then they would reach this moment where they would look at each other, stuck in trying to find what the new processes should be, because systems integration is not about adding organizations together; it is about delivering a system that can meet the needs of an entirely different, unified organization.
Ultimately, you need a subject matter expert who knows the process on both sides to objectively decide, this is what the new organization should be. Get that blueprint in front of key people to make sure you don’t miss anything. You can take that new business process and can look at the existing systems and decide what it would take to update either acquirer or acquiree to what this unified organization will need.
If there are a lot of gaps on both sides, then bottom line is you won’t be able to use either system, and you will need another.
If the solution does call for a new system, it will be expensive, and you need to know this before the acquisition. The new owner is going to need to front that cash. And no one wants to be that person who says, right after the purchase, we need to spend an additional half-million or million to integrate a new solution.
We do this all the time, and we can look at an organization very quickly, and we can evaluate whether you will need to replace a software application or not. So please let us know if we can help.