When was the last time you opened up a customer record to handle an inquiry only to find the comment field populated with abbreviations and codes that made the documentation unintelligible? Or, as you are quality checking the data side of a call, you find entries into fields that “are not allowed” according to procedures but certainly are allowed by the database? If you have, then you probably agree with Howard (2007) “Data quality isn’t just a data management problem, it’s a company problem.” And, certainly it is a customer contact problem we have to address sooner rather than later.
In his article, Howard describes how he was in the process of integrating three new data sources into his enterprise customer database when he discovered the sad truth to the lack of data quality management. The first two files had the state code field correctly defined as a two-byte field however file number one had 64 values defined for state codes and the second file had 67 distinct values defined. The third file had the state field defined as 18 bytes with 260 distinct state codes defined. At this point he begins to ask, “whose problem is data quality anyway?”
To try to figure out his dilemma, Howard first looks to the data modeler who could have defined a domain table of state and commonwealth codes that would force anyone using the database to enter a common code set. He then considered the application development team whose “application edit checks failed to recognize the 50 valid state codes or provide any text standardization conversions.” He states that whether or not a company has a quality assurance team is largely dependent on the size of the company but goes on to say that data quality with these teams may not be better. In his example, the fact that the state code should be only two bytes in length and conform to the USPS standard was overlooked. Because there was no specific requirement to test, these data sources passed QA with flying colors. Howard says, “More than likely, someone assumed everyone knew the 50 state codes and that writing validation code was a waste of time. After all, everyone knows the state abbreviations for Michigan, Minnesota and Missouri. (Don't feel bad if you have to check - I did.)” Finally, he turns to the business users. An executive at one of Mr. Howard’s clients told him that data quality at their company was an afterthought. “Bad information was captured and passed on to the next application that assumed the first application had done its job. Bad data is persistently stored in multiple data stores.”
Mr. Howard’s article presents a valid question: Because data integrity is critical to the success in today’s corporations, who is responsible? Enterprise systems contain critical product, customer, and employee data. This data is integrated into management reports including dashboards and scorecards. Managers and executives use this data to make both tactical and strategic decisions. If someone does not take the responsibility to manage the quality of data quality, critical data elements / metrics may be incorrect or unusable thus jeopardizing the success of an organization. We all know what happens when a customer contact agent inputs undefined abbreviations and nonsense data into customer interaction fields. What can we do as customer contact professionals to ensure the quality of this precious data?
Reference
Howard, W. (2007). Data Quality Isn't Just a Data Management Problem. DM Review, 17(10), 16. Retrieved July 19, 2008, from ProQuest Computing database. (Document ID: 1413058121).
