Data Rich and Information Poor

Question

Data Rich and Information Poor

Viewing 4 posts - 16 through 18 (of 18 total)

You must be logged in to reply to this topic. Login to reply

gischimp Old Hand Points: 363 More actions · Answer 1

Jay Holovac brings up an excellent point, one that we as data folks ought never to lose sight of. Mainly, just because we can draw inferences and create relationships, be they spatial or otherwise, does not guarantee that we have provided more information. Sometimes it is possible to make assumptions that just don't make sense. Our mantra should be "know your data, know your data".

Roger L Reid SSCrazy Points: 2004 More actions · Answer 2

We all hear and accept that "we have all this data but don't have the information". (Actually, seems I'm not the only one here questioning that).

It's one of those things accepted as true, without any citation. No one gets challenged to prove it.

For the statement "always having the information you want from your data is challenging, especially as the business changes", I don't need proof.

But that's why what we do is called "work".

I see the benefit of warehouses, and dashboards and the like. But in one way, they're just the modern replacement for green-bar paper.

If they can be more dynamic and useful, great. Learning Kimball-style techniques and Star designs is useful.

Meantime, I suspect most of the BI products out there aren't nearly as helpful as the vendor would like you to think. I can't even fathom SSIS - why waste all that time if you have Perl and BCP?

The gross labor inefficiency built into most MS products is probably a bigger obstacle to getting the information needed. "Simply click 1437 times, once for each occurrence" - instead of dropping a script with parameters into a scheduler and going home.

roger

Roger L Reid

Steve Jones - SSC Editor SSC Guru Points: 736494 More actions · Answer 3

Whoa, I'm not saying we need BI. I think BI can help here, but it doesn't have to be a fancy Proclarity report or a dashboard. It can be a text report.

In my experience, at a lot of companies, we had data, but not always information. Lots of time the "analysts" or "business people" either didn't know how to get or compile the information, or didn't know what it meant. I found them looking to me to explain patterns at times when I wasn't sure what the data meant myself. I often learned, and ended up being the expert on the business.

I've had other companies where they wanted BI stuff. But they didn't care about the technology. They wanted something to kick out trending and patterns, or look for anomalies, so I had a constant barrage of reports to create or alter. They told me what BI they needed so the data became information.

Look around in your business. I bet you find lots more data than information. Except in marketing. They like to create information without data :w00t:

Roger L Reid SSCrazy Points: 2004 More actions · Answer 4

It probably varies by business. I bet we actually have more information than data - but I don't think that's common. (We're a large professional services firm, which makes us a largish SMB.)

The people who end up with data in spreadsheets fed from ProCube know what they are doing. The people who feed ProCube from our transactional databases know what they are doing).

I think I am generally agreeing with you (not making you the representative of the "common wisdom"). Sometimes a paper report (perhaps delivered as a web page or email) is all that's needed.

Actually, our current "data that isn't information" is 2 decades of monthly reports, on paper. We still run them, don't print them. We're now scanning/ocring them back in, now that databases can hold all that.

I don't think there's a BI product out there for that. But we don't need one, since it's just getting reintegrated into the existing data - which was only purged because hardware was once too small and expensive to keep it all.

If I were at the Walmart home office, BI would be a hugely different question.

The only use I've tried to make of SQL Servers extras for BI, has been to consolidate information about the SQL Servers themselves - and mostly because of a fascinating presentation at TechEd 06. In the end, it was simpler to build with tools I already knew.

I kind of thrilled that there are others who aren't as sure the BI emperor has as many clothes as he claims. He ain't naked, but there sure are pitfalls if one is tempted to overdo it - or works in a place where quantity of results is some measure of success.

Roger L Reid