Trashy Data Improves Profits

Really now, what is trash data?  Data gone bad!  You know as I do that data is an asset.  What most people take for granted (or believe) is that only “good data has value.”  I’m here to tell you that belief couldn’t be further from the truth.  By now, I’m sure you’ve heard of: if it isn’t broken, then don’t fix it.  Right?  Well, how do you know what’s broken if their is no bad data?  I guess your stuff doesn’t stink right?  Well, read on to find out why bad data really can harbor a gold mine of information.

Headlines seen in traditional BI shops

  • Don’t provide “bad” data to business users, they’ll end up not trusting the data warehouse
  • “Bad Data” should never be brought in to the warehouse, it has no value
  • “Bad Data” should be changed in to good data before presenting it to business users
  • “Bad Data” = “Bad Decisions” in a business intelligence solution
  • Storing “Bad Data” only contributes to the “big data” problems
  • “Bad Data” can’t be loaded properly, ever…

Too often, I hear many of these (and many more) headlines shouted by the BI / EDW team members, and even the business users chime in…  They seem to all chant the statements: “Just put a band-aid on it”  – although they are not this direct, they basically tell IT: “Just FIX the bad data, make it GOOD before giving it to me…”  What?  As we will find out, this is a very bad practice to continue in Business intelligence projects.

Just what is “Bad Data” anyway?

Bad data is a symptom – seen as a result of a different problem. Bad Data is often defined as: data that does not meet the business users’ perception of today‘s reality.  In other words, data that “breaks business rules”, “doesn’t align with today’s wishes of the business user”, or of course, data that is purely “wrong”.  But really, what makes the data “wrong” in the business users’ eyes?

The real question is: What Causes Bad Data?   There are only two fundamental causes of bad data:

  • Perception (IT and business users) : i.e. data does not align with the business users’ perceptions
  • Process Errors (encoded along the way, or process failures, missing edit checks) : i.e. a process messed up somewhere causing faulty data to be produced, or allowed faulty data to be entered.

Really there is no other explanation for “bad data”, so why all the fuss?  What’s all the hubub?

In reality, data, in and of itself IS NEITHER BAD NOR GOOD, IT JUST IS…  IT EXISTS, therefore we must manage it, categorize it, allocate it, file it, change it, and delete it (when appropriate).  Data are just a set of facts.

Ok, so given that statement – the biggest problem with Bad Data is that it get’s a bad wrap when it falls out of alignment with what the business believes to be true.  Yes, you heard me….

IT’S ALL IN THE PERCEPTION BABY!

Now, here’s the thing: if the business requirement says: “Today every account balance must have one and only one customer attached to it.”

What happens when we load a data warehouse from an auditability perspective?  Well, when we load “recent” history (past 3 months), then most likely this statement/this requirement holds true.  Everything is hunky-dory (going well).  However, when we begin to load data that is 5 years old, or even 10 years old, or perhaps we load external data delivered from a system outside our company…  What do we find?

  • Account balances without customer numbers
  • Customers without account balances
  • NULL account balances without customers
  • Accounts tied to two or more customers
  • Single customers tied to two or more accounts

You see, none of these errors (as a reality) are very important by themselves.  It’s the results I say, yes, it’s the results of the pattern analysis that make all the difference in the world.

Going Gold Hunting….

Where do we find the results?  what difference do the results make?

  • You need to understand WHY these errors are happening
  • You need to establish what percentage of overall total data that these errors are happening to
  • You need to establish how often these errors occur over a time-line
  • You need to find out if these errors are still occurring
  • You need to know where these errors are coming from

As sure as I stand here and speak of this, some of you are cringing in your seats….  Never been through a real audit hey?  Well no matter…  The point is this: as a business manager / director / executive – YOU should care about the impact that these errors and percentages of occurrences have on your business process.  WHY?  Because it is costing you money every time a business rule / business perception is broken!  I garauntee it!

As a technologist, or an EDW practitioner, you have a responsibility to explain when and how often the data doesn’t meet the business requirements.  As a business person you have a responsibility to find out why it’s happening, and what is causing it.

The gold is in the finding and fixing of the business problem – closing the gap, bringing the business process (whatever it may be) in to compliance / alignment with your expectations.

Once this is done, the problem data disappears, is no longer generated, and thus, you now have the start of a full total quality management (TQM) process that involves the data warehouse.

Gold, Gold, Everywhere…

So you see, if you “change / alter / modify / cleanse” the data before you put it in your data warehouse, you and the business users LOOSE OUT at the opportunity to find and fix problems that exist in the source systems.  You are putting a band-aid on the cut, but you are not stopping the bleeding.

To have the real-gold, you must have a raw and integrated by business key enterprise data warehouse…  That’s just what the Data Vault gives you (but don’t forget, you need to use the methodology in conjunction with the model in order to achieve the full effect).

So, if you still believe there’s NO VALUE in bad data, then you’ve missed the whole point of business process alignment, and I hate to say this but: Go back to school, preferrably th school of hard-knocks where a business is attempting real and true alignment of their operational systems.

Thoughts? Comments are always welcome.

Cheers,
Dan Linstedt
PS: you can find out more about the Data Vault model & Methodology at: http://LearnDataVault.com

Tags: , , , , , , , ,

No comments yet.

Leave a Reply

*