Keeping Data Accurate
This weekend I got a new windshield on my car. A few weeks ago a rock chipped the windshield and propagated and 18 inch crack within a few minutes so I arranged for a windshield repair company to come to my house to replace it. Things were going along pretty smoothly at first. They removed the old windshield, took off the various registration and safety inspection stickers and prepped the car for the new windshield. Everything was going well until it came time to put in the new windshield. That's when they found out that the windshield they brought wasn't the right one for my car.
The repairmen called their office and verified that all of the ordering information was correct. The problem turned out to be that the database of auto glass parts that they subscribed to had the wrong information. They finally were able to figure out the right part number, brought it out to the house and installed it. All turned out well except that it cost them an extra 2 hours of delay. As they were about to leave one of them commented that they recalled that they ran into this same problem the last time they worked on my model of car. It turns out they had to work with an inaccurate database that didn't have a good means for them to update or correct when errors were found. In this case an inaccurate database became a customer service issue.
It's a fact of life that errors will find their way into our databases. There are things we can do to minimize this but it difficult to entirely eliminate errors. So this begs the question - "What do we do about the errors?"
Since we are not typically the users of the databases we set up we are not usually the ones that find the errors. In the corporate environment we usually have an helpdesk problem reporting system that can be used for reporting and hopefully correcting problems. With users outside the company this is not always the case. Do they have a way to report errors or suspected errors? I've seen many cases where data is provided but there is no effective reporting mechanism. In a few cases where there was a "Contact Us" form it appeared to be useless as I never heard anything back. So the first key to database error reporting is:
Provide an effective means of reporting errors.
The complication in this is that when users find errors they don't always bother to report them even if we provide a reporting mechanism. This could be because they don't believe we will do anything about it, or they are too busy or they just don't care, or some other unknown reason. For whatever, reason, users won't always bother to report errors. We need to give them a reason, whether it is explaining accurate data is in their benefit or some other incentive. I once subscribed to a database of names and addresses. To keep the data accurate the provider gave a cash rebate on the subscription if you were the first one to report an address returned as undeliverable. This gave him an effective way to keep his database updated and accurate which is a key factor in his ability to sell it. Thus our second key is:
Make sure users have an incentive to report errors.
One of the pesky problems with having users report all these error is that it may turn out they aren't errors at all. Just because the user believes the data is wrong doesn't mean it really is. Some data maybe obviously wrong, e.g. my phone number is listed incorrectly, which we can believe because of the user's "ownership" of the data. In other cases it needs careful analysis to determine if there is an error, e.g. the accumulated depreciation figure for your fixed assets. We need to evaluate the suspected error and let the user know what we doing about it if it truly was an error or explain how it really is correct after all. Otherwise our users will assume we are doing nothing about their reports and stop reporting any new ones in the belief that it is a waste of time. Which leads to our third key:
Give user feedback on their error reports.
What ways have you found to be effective in keeping your database error reporting effective?
"Apple //e binary" photo by mlovitt
If this topic was of interest, you might also like these:
















A friend of mine encountered a similar database error in their company. She told me that she almost lose her job because of that incidence. Her supervisor even insisted that computers are smart and the particular computer that they are using in the production is reliable for the past 7 years.
Good thing that my friend manually record the quantity of chemicals that she used and she were able to verify that the damage is beyond her control as it is really a computer-error. And upon reading your recommendations, I think that I need to forward this to her as your suggestions are truly applicable to her situation and can help her a lot in her work.
Posted by: Elvis Kovacic | Elvis Kovacic | May 2, 2008 10:32:40 AM
Elvis,
Thanks for commenting. I'm glad you found this post useful. As you point out some people fall in to the trap of thinking that just because it was generated by a computer that the answer must be right. As you've seen it's only as good as the way you use it.
Mike
Posted by: Michael Schaffner | Michael Schaffner | May 2, 2008 7:55:13 PM