jump to navigation

Today’s Linkedin Discussion Thread: Enterprise Data Quality April 28, 2009

Posted by Peter Benza in Data Analysis, Data Elements, Data Governance, Data Optimization, Data Processes, Data Profiling, Data Quality, Data Sources, Data Standardization, Data Synchronization, Data Tools, Data Verification.
Tags: ,
add a comment

Here is my most recent question I just added to my Linkedin discussion group = Enterprise Data Quality.

QUESTION: What master data or existing “traditional” data management processes (or differentiators) have you identified to be useful across the enterprise regarding data quality?

MY INSIGHTS: Recently, I was able to demonstrate (and quantify) the impact of using an NCOA updated address for match/merge accuracy purposes when two or more customer “names and addresses” from three disparate source systems were present. The ultimate test approach warrants consideration especially when talking about the volume of customer records for big companies today number “hundreds” of millions of records. It is ideal to apply this test to the entire file not just a sample set. But, we all know today its about: money, time, value, resources, etc.

For testing purposes, I advised all individual customer address attributes were replaced (where information was available) with NCOA updated addresses and then loaded and processed through the “customer hub” technology. If you are not testing a piece of technology, then constructing your own match key or visually checking sample sets of customer records before and after is an alternative. Either way, inventory matches and non-matches from the two different runs – once with addresses (as-is) and once with addresses that leverage the NCOA information.

My goal was to establish a business process that focused on “pre-processing customer records” using a reliable third party source (in this case NCOA) instead of becoming completely dependent on a current or future piece of technology that may offer the same results, especially when the methodology (matching algorithms) are probalistic. My approach reduces your dependency, as well, and you can focus on “lift” the technology may offer – if your are comparing two or more products.

Where as, inside a deterministic-based matching utility (or off-the-shelf solution) adding extra space or columns of data to the end of your input file to store the NCOA addresses will allow you to accomplish the same results. But, for test purposes, the easier way may be to replace addresses where an NCOA record is available.

Remember, based on the volume of records your client may be dealing with, a pre-process (business process) may be ideal, rather than loading all the customer names and addresses into the third party customer hub technology and processing it. Caution: This all depends on how the business is required (i.e. compliance) to store information from cradle to grave. But, the rule of thumb of the MDM customer hub is to store the “best/master” (single customer view record) with the exception of users with extended search requirements. The data warehouse (vs. MDM solutions) now becomes the next challenge… what to keep where and how much. But, that is another discussion.

The percentage realized in using the updated customer address was substantial (over 10%) on the average based on all the sources factored into the analysis. This means several 10’s of millions of customer records will match/merge more effectively (and efficiently) followed by the incremental lift – based on what the “customer hub” technology enables using its proprietary tools and techniques. This becomes the real differentiator!

Advertisements

Summit 2008 – San Francisco January 10, 2008

Posted by Peter Benza in Data Accuracy, Data Governance, Data Integrity, Data Metrics, Data Processes, Data Quality, Data Stewardship, Data Strategy, Data Templates, Data Verification, Data Warehouse.
Tags: , ,
add a comment

If you have not attended a Summit then mark your calendars for:

CDI-MDM Summit Spring 2008

Please post and share your comments about this upcoming summit or if you have not attended and want to learn more then link using the above reference.

What kind of data references are being bolted-on to enhance record matching inside the customer database? August 17, 2007

Posted by Peter Benza in Data Elements, Data References, Data Strategy, Data Verification.
add a comment

Organizations are turning to compiled reference data to compliment the match/merge/optimize routines inside their customer data hub.  A score/rank is also being pre-assigned (appended) to each customer record to make this process easier when it comes to building match-logic for use during the file build process.

A good example of this is aggregating surname into various geographic levels – block group, census tract, zip code, county, and so on.  The resulting surname statistics by geography are used as part of the overall algorithm applied during the integration/update process to improve the decision making process which brings two or more customer records together, referred to as a household.

Note: Surname is only one data element – others exist and vendors in the informations services industry have packaged this concept into licensed modules for use in organizations master data management landscape. 

How do you prevent data errors in your database today? August 16, 2007

Posted by Peter Benza in Data Errors, Data Hygiene, Data Processes, Data Sources, Data Templates, Data Verification.
add a comment

Data errors can be reduced but not totally eliminated, so be realistic.  First consideration must be given at point of entry and depending of the size of your organization this could be many.  Once your data is consumed, a number of other places should be considered to monitor data errors, such as: data convertion, data preparation, data migration, data integration, data reporting, data analysis, and finally when it is consumed and displayed for use in a dashboard.

Collectively, once you document where most of these errors are orginating from – then and only then will you be able to classify data errors given the entire end to end process from point of entry to using the data in its original or transformed state in a report, analysis, or dashboard.

Now, that you have compiled all these data errors (specific to your organization) you can begin to feed some/most of these findings back into your data quality, data governance, and data management frameworks.