Customer Identification with DUNS
Subset//data
Information Management Magazine, March 2009
Assigning a customer (or vendor) unique identification is a challenge organizations have struggled with for many years. Larger organizations with multiple customer access points often don't correlate their customer lists. Credit has been extended to customers well beyond credit limits because different departments are unaware they are dealing with the same customer.
Furthermore, as companies are being bought and shuffled with regularity, there is the problem of customer depth. Many companies still work with their B2B customers as a flat list, but this is no longer a valid practice. With company hierarchies possessing an unprecedented number of levels, internal rules are needed to establish who is really a customer (or vendor) and what the rules of engagement will be for different levels of customer. The maintenance of such lists at a reasonable level is well beyond the capabilities of most organizations that rely strictly on customer input. D&B calls this corporate linkage.
The syndicated data vendor community has existed for a while, but it has mostly been sourced by organizations with a very specific need, such as a marketing list for a promotion. This is changing as organizations are making the move to the leveragable data store that is MDM. With MDM, organizations have an artifact to document where their efforts in data quality, sourcing syndicated data and organizing a superset of attributes are rewarded. Where single applications routinely incorporate data omissions and defects, organizational requirements taken together can cause quality and quantity of data to increase. With MDM, syndicated data has found not only its home in information architecture, but also possibly its killer app.
Advertisement
Customer is not the 90 percent market share first port for MDM that you may hear from listening to vendors, but it is usually first, and it is very important. With some effort, it is possible and even desirable to use services from companies such as D&B to uniquely identify and expand upon customer lists while placing each customer into the corporate hierarchy. There are competitors to D&B with similar services, but due to sharing and reselling it is quite likely that customer identification from many vendors comes back to the D&B DUNS number.
There are about 150 million businesses uniquely identified by DUNS. These numbers are never reused, and unique DUNS numbers serve as the grain for which all D&B attributes are attached. While not court-tested to my knowledge, in these days of compliance, it is probably a solid step toward managing your customers.
Syndicators get their information from many sources, including public records and through copious collection of the breadcrumbs businesses leave behind in Yellow Pages advertisements, newspaper reports, court filings and the Internet. But remember, this is not a perfect science; be careful not to place undue trust in the data.
Matching is the process of comparing your list to the vendor's and is an important part of the process of sourcing syndicated data. Unfortunately, low levels of matching usually indicate the need to work harder on internal customer data quality so that the matching algorithms pick up more matches. It is a worthy exercise, though none of my customers have achieved a 100 percent match.
There are many reasons for a low match. Companies often store customer data with colloquial names rather than the legal entity names used by the data service. Company name changes have not been maintained. People names and other errata often end up in customer name fields. And, of course, there is the usual assortment of typos and mishearings (was that "scuze me while I kiss the sky" or "scuze me while I kiss this guy"?). Finally, smaller companies and companies in developing nations do not necessarily have a DUNS number unless someone has requested it. For this, and other reasons, I surrogate the customer key in MDM and do not rely on the DUNS number except as a non-key attribute. Others might "impose" a DUNS number with similar benefit.
Conflicts between your data and the syndicated data will always arise. Which phone number or primary business code should we use? The answer might be both, with detailed attribution in the column name and/or the metadata to sort through the various data origins. I find myself violating one of the main rules in data warehousing for MDM - source independence of data. There is simply too much duplicate content you want to keep, not to mention the more sophisticated business users who have the skills to deal with nuanced data.
MDM can link and harmonize customer and vendor data using a unique customer ID as the touchstone for matching records to get a company-wide view. Identification of the most profitable customers, total customer credit risk and accurate cross-sell can be possible with MDM and a unique customer ID. Hopefully this also serves to explain why I can see future consolidation between MDM vendors and syndicated data providers, and possibly data appliance vendors as well.
William is Partner, Information Management at McKnight Consulting Group. William functions as Strategist, Lead Enterprise Information Architect, and Program Manager for complex, high-volume full life-cycle implementations worldwide utilizing the disciplines of data warehousing, master data management, business intelligence, data quality and operational business intelligence. Many of his clients have gone public with their success story. William is a Southwest Entrepreneur of the Year Finalist, a frequent best practices judge, has authored more than 150 articles and white papers and given over 150 international keynotes and public seminars. His team’s implementations from both IT and consultant positions have won Best Practices awards. William is a former IT VP of a Fortune company, a former engineer of DB2 at IBM and holds an MBA. William is author of the bestselling book “90 Days to Success in Consulting.” He may be reached at 214-514-1444 or www.williammcknight.com.
For more information on related topics, visit the following channels:
