If there is one time when business value is front and center in a conversation, it is during a merger or acquisition process. The acquiring company wants to know the true value of the company it’s acquiring and the company being acquired wants to prove its value as a viable option for acquisition. In the case of a merger, both companies have these same two concerns – what is their real value and what is the value of the company with which they are potentially merging?
In today’s organizations, technology, and more specifically, software is an aspect that needs to be carefully assessed to determine its value to the M&A deal as an asset or potential liability (i.e. requiring significant upgrades or maintenance or performing poorly).
To begin the evaluation process, I recommend looking at the software in relation to the business functions of the target company. Is the software unique to the company’s line of business or is it used for a business function that is common between the two organizations (i.e. HR, payroll, CRM). Most likely, the software that is performing the same function in both companies will be of little business value to the acquiring company as they will choose to keep their existing software.
However, a software solution that is unique to the target company could have tremendous value. The challenge is that the acquiring company may not be familiar with the software and have a limited understanding of its value or the risk associated with that software. In addition, if there are only a few individuals who understand how to use and maintain the software (especially with proprietary software) there is a risk that they will not remain at the company and as a result there will be no knowledgebase to maintain and/or enhance the software.
I recommend taking four key steps during the acquisition process to determine the value of the target company’s software:
1. Software Asset Due Diligence (ADD) – determine how the target organization relies on the software.
2. Software Asset Risk Management (ARM) – assess the risk involved in transitioning to the target organization’s software.
3. Software Asset Maturity Analysis (AMA) – determine the future ROI for the acquired software.
4. Software Asset Integration Management (AIM) – analyze how to integrate the acquired software into the current environment.
A software assessment needs to be an integral part of the M&A process – no matter what end you’re on. It can no longer be an after-thought. Software can provide significant value or pose a huge risk for an organization and that needs to be determined up front.
I’m always interested in hearing from others about your experiences on how your organization has handled the software assessment process during a merger or acquisition. What lessons have you learned?