In both good economic times and bad, mergers and acquisitions are a fact of life. And as any IT manager who has worked through a merger will tell you, there are many thorny issues involving data and its management that must be tackled during mergers and acquisitions. Managing an ever-increasing mountain of data is not a simple task in the best of times, but doing so while combining formerly separate entities during an economic slowdown can be a monumental challenge.
Of course, the first M+A-related challenge for IT must be to determine how to merge data center operations. Assuming that larger questions (such as which data center will survive) have been answered, IT management will need to analyze systems and eliminate redundancies. For example, you won’t need two HR systems post-acquisition, at least not in the long run. From a data management perspective, this is easier said than done because of platform and formatting differences.
After an acquisition is completed, IT managers are forced to support a number of dual systems and applications. Be sure to plan for the proper personnel and support to keep redundant systems running for the period of time needed. And try to keep that period of time to a minimum, but without leaving too little time to make informed, intelligent decisions regarding what stays, and what goes.
Generally, the more functional applications should survive, but this is not always the case. Most mergers are actually acquisitions, meaning that one of the companies is the dominant one. As such, sometimes the applications of the dominant company win out. If you can, try to avoid these types of bad decisions. One way of doing so is to form evaluation committees consisting of employees (including management and rank + file employees) of both merger participants.
Sometimes functionality is not the only, or even the best decision point. The desire to rationalize the set of system software and utilities to reduce cost post-acquisition can be a potent decision-making criterion. But reducing software acquisition costs by consolidating vendors is only part of the equation here. Be sure to consider the long-term effects of locking in a small set of software vendors who can exert significant influence on future decisions. Also, TCO (total cost of ownership) is more important than the initial software cost, so take care to build policies and procedures for determining TCO.
Getting a handle on all of the data that the now-combined organization must manage requires time and effort. The task at hand will be simpler if both organizations practiced strong data governance, meaning they know what data they have, where it is stored, what it means, and have documented all of this information. This is rarely the case though.
So the first step needs to be defining what data you have and where it is stored. Without tools like data dictionaries and repositories you will need to rely on the subject matter experts (business users, programmers, data architects, etc.) for this information. Consider using the acquisition as a means to create stronger data governance policies and procedures. The sudden lack of insight that comes from an acquisition can motivate IT and business managers to improve data management practices.
An often-overlooked aspect of data management is the evaluation of your backup and recovery plans. In all the excitement of an acquisition evaluating recoverability could be easily bypassed in favor of day-to-day operations and application viability.
Even in well-managed IT shops it is a common situation for some data not to be backed up appropriately. Assuring that all of your business data is backed up, and on a schedule that assures its recoverability within the expectations of the business users, is not trivial. Furthermore, the on-going viability of your backup plan must be regularly monitored and validated. Processes need to be implemented to assess questions like these:
- Are the backups registered? That is, do we know where to find them?
- Do the data sets for the backups still exist?
- If on tape, are the tapes readable?
Assuring recoverability is not just making copies of data, but examining the entire IT environment with respect to backup and recovery. For example, you may have taken appropriate backups of your databases, but do not have sufficient tape drives to recover them within your stated recovery service level agreements.
For a successful and systematic review of your recoverability it is helpful to include an examination of backups, an evaluation of IT hardware and software specification, and to match objectives to reality. The process of assuring recoverability is exacerbated due to the hectic nature of a merger or acquisition, and recoverability will certainly be impacted if it is ignored.
So if you are one of the “lucky” ones undergoing a merger or acquisition, it is a good idea to use the opportunity to improve your data management practices. After all, when will you get another, better chance to do so?