Preserving and Unlocking the Value of Acquired Database Assets
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.
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.
Back to Main
For more information contact MoneySoft.
Copyright © 2000 - 2002 MoneySoft, Inc. All Rights Reserved Worldwide.