by Angela Guess
In a recent article Nari Kannan discusses one of the root causes of bad data quality, namely bad software implementations: “Everybody has their own story about Software Implementations lurching, stagnating, going forward at incredible speeds when deadlines are near and bad software quality ensues! It can pass all the Quality Assurance tests but Bad Data Quality is not one of them EVER done to most of them, at least not as a routine effort. The primary contributor to bad data quality is not just Field Level Validations, Form Level Validations and Semantic Validations alone.”
Kannan continues, “Field Level validations need to be designed into the form itself to check whether you are accepting alpha inputs into a numeric one, etc. Form Level validations do things like checking the city against the Zipcode or required fields are filled up if one field is filled up. Semantic validations check if a customer number entered is available and the information being entered is checked against a backend database and then accepted.”
He goes on, “But bad data quality could also arise due to not designing in all the Use Cases possible, into your software. When you enumerate your users and use cases, have you allowed for generic exceptions? Are the generic exceptions used only rarely? If generic exceptions are used 50% of the time, you can see where the bad data is creeping in. Your shortcuts for exceptions is being overused and spoiling the data you have. Exceptions need to be just that, Exceptions! Another root cause of bad data quality is the ensuring of single identities within your system – Do you have two or more accounts for the same customer? Happens all the time, right? Especially if they are in two different divisions of the company and you don’t know that they are all one and the same person!”
Kannan notes, “Bad software implementations also can arise out of not checking out software packages thoroughly for root causes of how they can happen. You may be buying off-the-shelf packages without kicking the tires for Bad data quality possibilities. Have the screens and forms been designed to keep these problems out? Have you checked this before you bought the package? Looking at root causes always helps in fixing problems thoroughly. Spending enough time and energy with evaluating software implementations with respect to their propensity to create bad data always pays off.”
photo credit: Ivan Walsh
