|By Hollis Tibbetts||
|September 10, 2011 12:00 PM EDT||
In survey after survey, about half of IT executives consistently agree that data quality and data consistency is one of the biggest roadblocks to them getting full value from their data.
This has been consistently true all since the Chinese invented the abacus. I suspect it will be true long after quantum computing has solved every other problem that humanity faces.
Incorrect, inconsistent, fraudulent and redundant data cost the U.S. economy over $3 Trillion a year - an astounding figure that is over twice the amount of the 2011 Federal Deficit.
I've long been a proponent of healthy software - but healthy software can only function properly in the presence of healthy data. Does quality software even matter if the underlying data are defective? Agreed - that's pushing the point to the extreme.
The rapid, iterative, continuous testing model has measurably improved the quality of software development. Evangelists such as Kent Beck have had a huge impact on this. I recently posted a freely downloadable white paper on this topic. But where are the evangelists for data quality? Where is an open source "JUnit for Data" and if it's out there, why isn't everyone using it?
The Cost of Bad Data
Anyone care to make a guess at how much money is wasted every year due to dirty or duplicate / redundant data? I'll start by presenting one common user story - one you probably have also recently experienced. And then expand on it.
Recently, I went to my mailbox and waiting for me was yet another invitation from a major bank to join their credit card program.
This shouldn't come as a surprise, as people everywhere are deluged by credit card offers. Except that I already have the particular card in question. Not only that, but because the particular bank in question has managed to acquire a number of other banks and credit card lines of business, between my personal and my corporation, I believe I now have five Visa cards from this particular bank.
I also occasionally get mail from them offering me cash bonuses to open up a checking account at their bank. Probably wasted postage, as I already have two checking accounts there. I suppose I could open up a third, just to get the $100.
Every month, I get a significant number of expensive looking direct mail offers from this bank, often with slightly different variations on my name, which I promptly throw away. Aside from the impact on the environment and the wasted direct mail expense, it's a bit irritating to me. I hate junk mail, and I feel compelled to shred things like credit card offers. So they've burdened me (an existing customer) with yet another "thing to do". So they've spent money, hurt the environment, irritated an existing customer, and now I get to make fun of them online. Bad investment on their part.
QAS (an Experian company) estimates that the average company wastes $180,000 per year simply on direct mail that does not reach the intended recipient because of inaccurate data. But this is just one miniscule slice of the data quality issue. In fact it's only one small part of the "direct mail" data quality issue. A lot more money is wasted in "inappropriate offers" and "duplicate offers" such as the ones my bank sends. I also get offers from several companies that are convinced that I'm married to the previous owner of my house. Those offers reach me, yet are immediately shredded. No sense opening them. So the "big picture" just for direct mail is much larger than what QAS shows.
None of this accounts for the "irritation" factor - what is the cost of annoying existing customers (or potential customers) with badly targeted offers?
Yet direct mail and all other forms of advertising together add up to a tiny slice of the bad-data pie.
Fraud Is a Bad Data Problem
Some time back, the US Attorney General's office stated that they believed that 14 percent of health care dollars are wasted in fraud or inaccurate billing.
Why do I lump fraud in with "bad data"? Bad data comes in two forms - accidentally created bad data and intentionally created bad data (for example, fraudulent billing). Either way, it's bad data. It doesn't matter how it got there, it's defective. And a lot of it could be detected and remediated "at the point of entry".
Healthcare accounts for over 16% of the U.S. GDP (Canada is 10%, Australia is 9% as a comparison). The U.S. GDP is currently approximately $14 Trillion - therefore healthcare spending in the U.S. amounts to $2.25 trillion. And the cost of bad data in Healthcare- $314 Billion.
That's just for fraud or inaccurate billing. What about other areas in healthcare (e.g. lost data, "bad patient outcomes", duplicate patient testing, manual rework, etc.)? Even if we round down, we're still taking about $500 Billion for one industry alone. If I extrapolate that out to the entire U.S. economy, we're talking about a $3.1 Trillion problem. No matter how far off my estimate is (on the high side or the low side), it's a problem of astonishing proportions.
Cost of Bad Data to Business and IT
A classic but very worthwhile book from information governance expert Larry English posits that the business cost of nonquality data may be as high as 10-25% of an organization's revenue, and that as much as 50% of the typical IT budget may be spent in "information scrap and rework". If that is the case, then my $3.1 estimate is not out of line.
In the introduction to his book, English states "With this proliferation of information, the challenge of managing data and providing quality information has never been more important or complex."
That was in 1999. With so much more data today, and a surprising lack of attention to the data quality issue, I can only imagine the total economic impact of things today. I do not doubt that the cost of bad data has risen.
Dealing with bad data at the I.T. level is expensive. But if I.T. doesn't deal with the bad data problem, then the cost gets pushed downstream to the "business", where the business costs are geometrically higher. The model is not that different from that of "healthy software", where it costs $1 to uncover a defect during developer/unit testing, but $100 to fix that defect if the software is released to the end-users.
"Low Hanging Fruit" - Best Practices for Bad Data Avoidance
I am not saying that there are any easy fixes to the bad data problem. Even something as relatively simple as cleaning, standardizing and de-duping a mailing list with 10,000,000 entries is essentially impossible to get completely right no matter how much effort is put into it. Yet there are some relatively easy things that can be done to substantially improve the quality of our data. As with so many other problems in life, the some version of the 80/20 rule applies to this as well.
Best Practice #1: When integrating data, fix the quality problem during integration
As data are added or integrated, data should be tested. Profiling is a simple, fast, relatively easily implemented and highly effective way for eliminating significant volumes of defective data.
When developers write a new application for the input of some new data, it's normal for input fields to be "validated" - a simple "hard coded" form of profiling. Month number needs to be between 1-12. 13 is never correct. Not rocket science. And it's universally done.
Yet people have far fewer reservations about integrating data from here, there and everywhere - often not checking for even the most egregious data errors, and thereby polluting the organizational drinking water (i.e. all the data and applications downstream).
I strongly suspect that's why I get so many offers from my current mega-bank. Since the banking implosion, this particular bank has purchased every other bank around. And their credit card businesses. And their marketing databases. And (apparently) smashed them together. So I get offers for Hollis Tibbetts, Hollis W. Tibbetts, Hollis Winslow Tibbetts, Hollis Tibbets, Hollis Tibbitts and so on.
Integration of data isn't necessarily just a "big bang" event - like when one company acquires another and smashes all the data together, or when two divisional customer applications get merged. It can be more insidious and more when you have "trickle" integration - the slow feed of new data from one system into another (either within the organization or from customers/suppliers/partners). This is the class of integration that is causing a lot of the problems previously discussed with healthcare fraud.
Either way, FIX IT before integrating it. Once the poison enters the corporate drinking water, it's a lot harder to get out (not just technically, but especially politically/organizationally).
Best Practice #2: When migrating data, fix the data problem as PART of the migration project
Spending $1 billion to upgrade your Seibel system like the US Government is doing? Sounds like a great time to fix your data quality problem.
If you're doing something like migrating your customer data from Seibel to Netsuite or Salesforce.com, data quality should be a major element in your project plan (and budget). Fixing the problems during the migration are easier than fixing them later:
- You probably already possess a lot of knowledge about the existing legacy systems, the types of problems in the data. But your new system is relatively unknown to you. So it's likely to be easier to fix data issues from a technical perspective BEFORE they get loaded into the new system.
- As part of the data migration process, you can export the data to a staging platform (On Prem or Cloud), leverage any number of data quality tools/engines, and then import the data into the the application platform. This approach may partially pay for itself in an easier/smoother upgrade to the new application, but that's a rounding error in the overall scheme of things.
- Organizationally and politically, companies are much more likely to spend money to clean data if it's part of a project like "upgrade the CRM system". I'd hate to be the CIO that spends a mountain of money to upgrade the CRM system and then goes back to the board asking for another mountain of money to fix all the bad data that just got loaded into the CRM system. That's how CIO's become ex-CIOs.
Best Practice #3: Data profiling and data de-duplication engines
Data profiling engines are a great technology for quickly improving the quality of data as it is integrated from one system into another. At the highest level, they are an engine that scans data, and applies certain easily definable rules to data elements, such as formats, ranges, allowable values and can evaluate relationships between different fields.
Furthermore, these engines can also be used to analyze existing data stores very rapidly and generate "exceptions files" for manual, or semi-automated remediation (if anyone can find a totally automated data remediation system, I'd love to know about it). So they can be used in "continuous testing" or "batch testing" mode. In batch mode, they're ideal for application migrations or big-bang integrations, as they're easiest to use them if you have your data in something like a staging database. But they can also be used to test data as it is "trickle integrated" into production systems.
De-duping engines generally fit into the same category. I haven't seen them be as effective as data profiling engines, yet I believe they're essential. The technology for de-duping is considerably more sophisticated - with a large number of different algorithms and tunable thresholds and such. It's a harder class of technology to implement. More manual effort is involved. And, unlike profiling (where there is NEVER a month "13"), de-duping can "get it wrong", so the technology needs to be applied more selectively.
I've never understood why these engines haven't been more popular. There is no "JUnit for data" as far as I know. But commercial solutions are available - they're not terribly expensive and rapidly pay for themselves.
On the other hand, I've never understood why organizations are so tolerant of bad, dirty data. They waste millions and millions directly because of it (and untold quantities of money in "wasted opportunities"), but are reluctant to spend $15,000 on a data quality engine to help fix a significant portion of the problem.
- ARM Server to Transform #BigData to #IoT | @CloudExpo #DigitalTransformation
- Software Quality Best Practices: Healthy Software
- Twenty-Thousand Men Pregnant Because of Bad Data
- $3 Trillion Problem: Three Best Practices for Today's Dirty Data Pandemic
- Question: Why Is IT Project Failure Always an Option?
- Why Infrastructure Technology Is Challenging
- Modernization of IT: Solving a Legacy of Business Problems & Applications
- Flourishing ARM Server Market Creates Opportunity – for Software
- Legacy Modernization
- Klout Crisis Leads to Tough Questions for PROskore Founder Bill Jula