In this post I want to draw attention to a situation which results from “small view” data quality thinking that can occasionally wreak havoc for upstream or downstream information users.

My personal data quality journey mirrors what most organisations go through. Initially I was completely unaware of the need for data quality. I got started by exploring how defective data impacted me and my immediate team. As I matured my philosophy towards data quality I realised that data is like a river, it crosses organisational boundaries, picking up “pollutants” as it flows to multiple destinations.

Over time I realised that to measure, analyse, improve and ultimately control the root causes of data quality defects there can be no “small view” thinking, you need to examine the entire information chain, the “whole view” as it were.

Failure to do this, by focusing improvements in one location without considering the journey of your data, can often lead to failures elsewhere in your business.

Several years ago I was responsible for improving data quality on a set of financial instruments. I spent several months identifying all the possible information chains that would be impacted by the change and eventually implemented the new rules. Almost immediately we received complaints from the furthest recesses of the organisation. One of the downstream data sources actually supplied a quarterly feed to another part of the business which I had simply not discovered (the organisation was large and there was little documentation of the process, well that’s my excuse anyway).

My newly standardised, accurate, complete, timely and immaculately presented data was causing a complete failure for a processing function that relied on the old data quality rules I had been tinkering with.

This is a perennial problem with data quality.  There is quite often no “single version of the truth” when it comes to data quality rules as they can become highly contextual. David Loshin raised this point recently in this very community when discussing “Data Streams and Data Rules“:

As the knowledge base and rule base grow, the possibility that there are conflicting assertions or competing rules increases.

My new set of rules were in direct conflict with the rules that this far-flung business unit had developed at some point in the distant, undocumented past. As organisations increasingly connect data sources and develop ever more complex information chains I don’t see this situation going away any day soon.

So, of course in my example above far better data governance was required to create a set of rules that would encompass all uses of the data. If the company had matured their data quality management strategy to include information chain management, data quality rules management and domain stewardship then the remote data consumers would have been known and we could have created a “service level agreement” structure to monitor and prevent these issues arising.

Another example of how data quality can actually damage business is when we inflict improvements on an unsuspecting customer in the upstream process.

Take the typical web sign up form that is used to capture prospective customer details. If we force the user to navigate various drop-down menus and other data quality enhancing controls we can damage our business directly – the prospect simply refuses to enter their details and walks away. One of our readers on Data Quality Pro (see comment by J Schriber in this post) claims they witnessed a 55% drop in leads when they switched from a free-form text field to a rules-based form obviously designed with data quality in mind.

The lesson here is that ultimately your data quality efforts must serve the goals of the business. If you improve customer record accuracy and completeness to 100% but lose half of your prospects then this can hardly be classed as a success. You also need to thoroughly test any new rules and ensure there is a fallback strategy so that in the event your new rules inflict a failure within the business you have a plan B.