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.
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.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access