Preserving and Unlocking the Value of Acquired Database Assets

Acquisition Marketplace Review - The Journal of Applied M & A Theory

One of the benefits of merging with or acquiring another company is the potential for gaining new customers. The information regarding these customers will most likely be found stored in a database of one sort or another. While databases have made the movement of information and, consequently, intellectual capital, easier and more fluid than ever before, they also present a host of potential problems when the task of integrating two different systems is undertaken.

Savvy buyers know that it is too easy to lose customers in the period right after a deal. Speed and agility are essential. Although database integration is easily overshadowed by the financial aspects of the transaction, it needs to be included as part of due diligence and the post-acquisition operational plan. The faster the data can be integrated, the faster it can be used to maintain and develop customer relationships.

Database Integration
Integrating the IT resources of two merged companies may prove as daunting as integrating the companies themselves. The myriad options available for storing and working with data have created an environment that is as complex and non-standardized as they come.

The problem is not just hardware or even software because most databases can be exported into a format that can be manipulated and imported into another database program. In fact, a database that couldn't move the data it holds to anything other than an identical system would be essentially useless.

Problems can arise, however, because data is organized in a specific manner, one that is usually determined by the user. Data is input into a field of some sort and that field has specific attributes that are set up intentionally. Perhaps the buyer's company only does business in the US and, consequently, their "phone number" field in their client records hold exactly 13 characters: the parentheses around the area code, the hyphen between the prefix and the ten-digit phone number. The target company, however, may have been working with clients overseas and, therefore, some of their contacts will have phone numbers that exceed the field size limit in the buyer's database. Trying to merge the data will result in the longer phone numbers failing to be imported properly.

This problem, obviously, could be easily resolved by simply expanding the size of the field in the buyer's system. However, if there proves to be a great deal of these simple problems, they could combine to create a complex and time-consuming project. Consider this short list that details only a few of the possible variations in databases.

Size of the field.

Field definitions, properties and attributes (Text, number, etc.).

Completeness and consistency of the data in a field. (Some databases have "required fields" that aid in keeping information consistent.)

Rules for searching, sorting and using the data, for example, customers could be grouped according to combined purchase amount or location.

The graphic user interface.

The capability to generate standard and customized reports.

Other applications that interact with the data such as contact managers and report generators.

While the buyer's company may have a specific goal where customer data is concerned, the purchased company may have had a completely different goal and, thus, a different idea of what data is important and what data isn't. For example, if your company relies upon extensive telemarketing and the acquired company did none, you may find that your preferred means of contacting your new customers is severely crippled: The seller's company had no need to require a phone number for every customer.

The last thing a buyer needs is to waste valuable time trying to "make do" with two or more incompatible databases. While the integration process may be involved and time-consuming, the alternative of limping along with two systems that can't even introduce themselves to each other will likely prove to be a headache that never ends.

Several companies now sell database integration as a product, an indicator that however large the scope of this aspect of M&A is, it is certainly large enough to have created a market for consultants and IT professionals.

Making use of outside consultants may avert some of the problems associated with merging the data, systems and personnel. It may also prove valuable in that a specialist will likely have already dealt with problems similar to those you may find coming to the surface. While the IT departments of both companies may have knowledgeable professionals in their ranks, merging the company databases will most likely involve administrative and procedural aspects they may have little or no experience with.

The Value of Data is in the Details
One of the most important aspects of data is the detail of the information it provides. For example, an acquired company's 20,000 customer data files may seem like a large asset but they may be essentially useless if they only contain information as general as addresses, telephone numbers, etc. A well-planned and solid customer database should not only contain customer contact information, it should contain information specific to the customers' buying habits and features that encourage the customers' loyalty. A good example is Amazon.com. Even though they are struggling toward profitability, they have constructed a database system on their website aimed at encouraging impulse-buying. Customer purchase information is stored in a profile that allows the customer to make purchases without re-entering shipping, contact and sometimes even credit card information. Presented with the option of convenience or a lack of it, most customers will choose a web store that offers ease of purchase.

Acquiring a database devoid of intelligent features such as these may prove as useful as acquiring a disorganized file cabinet full of very general customer information. One way to ascertain the level of customer convenience features a target company offers is simply to do business with them and see if they collect and use customer data. While it will do nothing to give an estimate of how many customers the company actually has, it will give the buyer an idea of how much consideration has been given to the customer in the design of the IT systems.

Beware of Redundant Customer Lists
You may well find that many of the customers in the acquired company's database are the same as your own. Naturally, this lessens the benefit of combining the customer information and could adversely impact the ROI from the price paid for so-called "marketing synergies." Further, because a company facing acquisition is unlikely to share their customer data with the buyer, it could be hard if not impossible to determine the numbers of mutual customers. Still, it's in the best interest of the buyer to try to make an educated estimate. In making that estimate, the usual rules of doing solid research and analysis remain indispensable.

Organizational and HR Considerations
Data storage systems at the technical level are not always designed with doing business in mind, nor are they necessarily designed to be user-friendly; they're designed to store and move data. Any large-scale database system is going to require a staff of specialists to maintain it. When the integration of the databases takes place, chances are the database staff from both companies will also be expected to integrate.

Along with the usual differences in corporate culture that may cause conflict, the procedures for data handling between the two companies might be extremely diverse and possibly completely incompatible. One company, for instance, may have five categories their customers fall under while the other may simply have active customers and inactive customers. Who decides how long a customer must go without making a purchase in order to lose their "active" status?

Moreover, while both companies might have database programmers on staff, they might be trained in different database languages making them right for one system but wrong for the other. For example, the buyer might store all of their information on an SQL system and have the appropriate programmer on-staff. The acquired company, however, might have used an AS/400 database for their customer information, which requires a different kind of programmer. This example only addresses programmers, but could be applied to database staff working at any level.

Add to this that it's likely the merging companies use different data systems. This brings up the technical aspect of database integration. Assuming that the existing staff members in both companies are specialists in whatever data systems in currently being used by their respective companies but not in other systems, it might prove necessary to bring in a third-party consultant to integrate the systems, thus increasing the expense (possibly significantly) of the acquisition.

In addition to the people, software, and hardware costs, there may also be a need for training personnel to work with the new system. It is advisable for the buyer to attempt to quantify these costs prior to closing.

Cisco Systems, Inc. and other like entities have made a business of keeping data flowing. While there is a drive toward more universal systems for storing data, much of what's currently available remains proprietary. The technical aspects of a database merger are myriad and complex. A small company that is being acquired may have a data storage system that was more than adequate to meet its needs, however, following the acquistion that company's system may prove hopelessly small for the increase in business.

Preserve Existing Relationships and Unlock Value
The best-case (and most unlikely) scenario, of course, would be that both the buyer and target companies have intelligent customer data stored on identical systems.

In reality, there are three likely situations that a merger or acquisition will bring about:

The buyer's data systems are far more advanced and capable and the purchased asset will be integrated into the buyer's;
The target company's system will be more advanced and the opposite situation will occur; or,
Neither company will have an effective data storage and handling strategy and an altogether new system will have to be devised.

Another critical question: Is it always necessary to combine databases? If the operations are going to be combined and if there are significant marketing synergies, then it is probably advisable to consider the time and expense of data integration. On the other hand, if the companies are going to continue to operate on a stand-alone basis, then the costs of integration should be evaluated against the anticipated benefits in productivity and revenue creation.

The process of merging data and databases may prove daunting and expensive, but it also presents a tremendous opportunity to expand, improve and update the systems of both companies. If included as part of the acquisition plan, the integration and use of acquired customer data can preserve existing relationships and unlock future value.

Chris Dufek
MoneySoft, Inc.

Back to Main

Printer Friendly Version (Full Article)

Terms and Conditions / Privacy Policy

For more information contact MoneySoft.

MoneySoft.com ~ Sign-Up to Recieve this E-Journal FREE ~ AMR Archives