All Things Data

Master Data Management and Merger of Necessity

I recently came across an article by PricewaterhouseCoopers stating that M&A activity in 2009 would be fueled by Merger of Necessity.  According to the article, “Troubled companies will look to align with larger, stronger players in order to survive, creating the perfect storm for mergers of necessity,” stated Robert Filek, a partner in PricewaterhouseCoopers’ Transaction Services group.  Further, Greg Peterson, a partner in PricewaterhouseCoopers’ Transaction Services group, stated, “Historically, it has been during a downturn when strategic buyers and private equity firms have their best buying opportunities, yielding the best return.”

When an organization acquires another organization as part of a “Merger of Necessity” strategy, understanding the overlap and uniqueness of the customer and prospect bases of the merging organizations is pivotal to developing the up-sell, cross-sell, and cost reduction strategies that are the drivers of the merge.

Utilizing the matching processes and number schema from a Master Data Management solution, an acquiring company can achieve the expected return on investment in a timely fashion by: 

Securing Market Share
Integrating the acquired organizations locations and contacts into existing database systems or brand new systems in a quick, organized, and complete fashion to ensure that the acquired customers are properly serviced and marketed to prevent loss of customers after the merger

Decreasing Costs
Properly allocating the appropriate number of resources based on the proper counting of customers and prospects of the two merging organizations

Increasing Sales
Developing a single customer view so that representatives can see information from the combined organizations utilizing information across multiple data silos to help up-sell and cross-sell

Executing Marketing
Understanding the overlap and uniqueness of the customer bases of the merging organization to develop target marketing campaigns based on the opportunities created by the merger

Data Quality
Identifying data quality issues such as duplicate records, building more complete and accurate records, develop master records for reporting, and other data quality issues

Master Data Management Discovery Summary

At this point, we have typically completed the Discovery Phase.  Before moving on to the Design Phase, we complete the Discovery Document and send it to our client for review.  The Discovery Document provides the background detail that is necessary so that Design & Prototyping of the master data management solution can take place.  In addition to being a valuable project management tool for our team, it also helps keep the client informed of the project details.  Further, the Discovery Document helps make sure that the client and our team are on the same page.

The last part of the Discovery Document is the Summary.  The Summary provides an overview of the master data management project goals, the tasks performed during the Discovery, and the project deliverables.

It should be pointed out that even during the Discovery Phase that we perform some of the initial Design work.  Some initial prototyping is necessary even before all the facts are discovered, as taking a look at the preliminary Design helps uncover the details and determinations that need to be made in order to develop the Design of the eventual “go live” system. 

Further, Discovery does not stop even when the Discovery Phase comes to completion. Discovery is an on-going process and certain elements shall also be discovered in the other phases.  However, based on the Discovery Document’s completion, we are now at the point where we can begin to configure and develop the client’s prototype master data management system.

Master Data Management Initial Matching

While setting up the Master Data Management match is primarily a Design phase function, it is necessary to at least do some matching during the Discovery Phase.  Doing some initial test matches provides an initial view of the data in match clusters.  These views help determine what data do you need for the import and match, hierarchy levels, and other determinations during the Discovery process. 
 
Also, we find that providing an initial match result helps demonstrate the potential of the Master Data Management system.  While you can talk about it all you want, until you start seeing results, it’s hard to get your head around it.  The initial test match can provide a clearer picture and build enthusiasm that is needed for the project.  With this enthusiasm, you can start to get the commitment and participation needed from the client in order to truly dive into their needs.  Therefore, even before we have completed all of the Discovery documentation, we start with initial match results.

Within our Master Data Management software, SingleVision, we have default match rules for both entity matching and contact matching.  Typically, we start with our default rules for our initial look.  As the Discovery process continues, we start to determine the definitions of the Hierarchy.  Once the hierarchy definitions have been set, the match rules can be adjusted to reflect the determined hierarchy levels. Then, as more and more Discovery is being completed, we further fine tune the initial match.

Master Data Management Import Mappings

At this point in the Discovery process, we have documented the data sources at the table and record level.  Now, we are ready to document the mappings of the fields for the import of each of the data sources that are going to be imported in to our Master Data Management software, SingleVision. 

The match rules for our Master Data Management solution are created by a series of algorithms that are based on combinations of the fields of data from the client’s data sources.  Therefore, we examine all of the fields from each data source in order to determine which fields may be potentially beneficial for the match.  Once determined, we can begin to plan for the importing of those fields. Since different data sources use different field names for the same information, we need to map each data sources’ fields to the corresponding field in the Master Data Management software so that it can be properly transformed and then matched based on the matching criteria that is selected. 

Additionally, there may be other fields that we may not necessarily need for matching purposes; however; we still may want to import them because they are potentially valuable as reference data.  Reference data is information that is not being used to help the master data management software match records, but provides valuable information for someone to see as part of their view.  You may want to import reference data to help you determine if records that are potential matches are in fact actual matches after a person takes a look. 

Another reason you may want to import reference data is the development of a single customer view.  One of the common goals of a Master Data Management solution is to provide representatives a view of all the authorized entity and contact records with authorized information across multiple data sources to help them do their jobs better.  For example, you may want to set-up a single view of the customer in a CRM system that lets a sales rep see all the products and revenue in the financial systems so that the rep can plan for potential up-sell and cross-sell opportunities.  The view in the CRM system would be developed from the Cross-Reference Table from the Master Data Management solution. 

Master Data Management Data Hub

Now that we have examined the data and started to make determinations with the data, we now need to correlate our data into a Cross-Reference Hub as part of our Master Data Management solution.  In order to correlate the data, we import the separate files into our Master Data Management software application’s central database.

As discussed in the previous post, some of the data may need to be pre-processed for better match results.  Based on the data determinations, in addition to running the import process, we also choose the MDM solution’s data transformation processes that are relevant to the client’s data and goals.  

Once the data has been pre-processed and imported, we can run an initial Match Project.  The Match Project generates a Cross-Reference Table by linking every record in the database based on their relationships as indicated by the Entity Level IDs and Contact IDs.

With a Cross-Reference Table, the client can: 

1.  View - See matched and linked records from multiple data systems.  For example, a company may want to give a sales rep a view of all the authorized records and information that are part of the same organization regardless of the data source in order to help up-sell and cross-sell.

2.  Report – Analyze data utilizing information across multiple data systems and properly counting the number of entities and contacts based on their Level and Contact IDs.  For example, a CRM system could be linked to the Cross-Reference Table in order to generate a report indicating how many unique entities that are customers or prospects within a certain market.

3.  Data Quality – Various data quality reports can be developed.  For example, a duplicate record report can be generated.  Then, as the system gets updated, subsequent reports can indicate the progress being made on cleaning-up duplicates as there should be less duplicates each subsequent day, week, or month that you run the report. 

4.  Operational System Enhancement – As part of the Master Data Management project, you may reformulate the data for matching purposes in order to get better match results.  The reformulation does not impact the operational system of origin.  For example, you may want to remove Department data that is in an Address field in the operational system of origin for the Match.  However, if desired, you can then use the Cross-Reference Table to help change the data back in the original operational system. 

In addition to creating a Cross-Reference Table, some organizations need to take the Master Data Management solution a step further and create a Master Record.  Sometimes the Master Records are also referred to as the Record of Record or the Golden Record. 

A Master Record is a record that uses information on the record from any of the data silos that have been linked by the Cross-Reference Table in order to create a record that is complete, accurate, and acts as the standard for that record based on the best available information across the data silos.  Many times a Master Record is created so that reports can be created with a uniform record representing that entity or contact within all reports.

When it comes to creating a Master Record, you can choose a record that already exists and deem it to be the Master Record or you can create one by taking the best information from the different data sources and then build the Master Record.