Reporting: The "Hippie's Backyard" of Software

As your Business Intelligence consultant, acting in my capacity as a reporting architect, I'm afraid I have to inform you that your current Reporting "system" is what we call a hippie's backyard.

Just think about it a minute.  Yes, it's a technical term.

Not important now.   The important thing is, it's not working for you or your organization. At all. In fact, I'd be inclined to describe the situation as reversed; you're working for it.  After all, how many man-hours do you waste annually on shuffling data in and out of Excel from one internal silo to another?  What kind of a report is a 26-tab spreadsheet with 64,000 rows of 50 columns of 8pt font in each tab?  And how many differing copies of those spreadsheets are currently strewn across network and thumb drives?  How many are the same?   Why didn't the developers of your Inventory system include any basic reporting functionality?

I'm just asking.  You don't have to get defensive.

Listen, I know how it goes: At first, there was supposed to be a set of reports included in the initial release.  But then the timeline got stretched, and you ended up with no real process, no real tool to get anybody any reports, just totally ad-hoc data requests fielded by whoever can do it whenever they can.   So then Ted in Accounting sets up an Excel thing that ties to the application database, people start using it, and data grows. Versions propagate.  Probably 6 or so around the network, some of them like 3 years old.  Two years pass, more users get on board, and the "Financial Data Mart" (as it's become known) has maxed out on file size, crashes itself at least once a session, crashes the Inventory application daily, and runs like cold molasses.  But there's no time to do anything about that.  Besides, Ted quit 6 months ago.  Who's going to do it?

Well, isn't that really why you called me?

No, no -- you shouldn't feel bad.  The same phenomenon is EVERYWHERE.  Reporting is the great red-headed stepchild of the IT world.  Ask any true-blue hacker how much they like building reports...  But here's the way to think of this:

At a certain level of organizational size and complexity (which will be different based on industry, culture, and other factors) a simple ad-hoc reporting system is insufficient.  You can't run it with a single person fielding 20-30 slightly different requests for the same data.  That setup doesn't scale, and can't handle the request traffic, can't handle the data volume, can't take the heat.  And truthfully, the organization will waste money trying to resolve the issue by throwing labor at it. The solution is to consider the problem holistically and strategically, and to provide a robust, organization-wide reporting solution.   The end goal is to establish a solution that provides all workers the information they need to do their jobs -- on-demand. 

How?  Well, first things first.  We need to do a broad inventory of prioritized reporting needs -- who needs to see what when, and what format works best for them.  That inventory is analyzed to generate a global information architecture, which organizes the various categories of information based on user need and natural hierarchies within the organization.  Next, the Data Structures at work in the organization must be analyzed to determine their usefulness vis a vis the information architecture, their accessibility, and their availability. When we bring the results of this analysis to bear on the Information Architecture, we can map specific information needs directly to data sources, we can design a truly centralized reporting solution. 

And, yes, we get your company out of the hippie's backyard.

So, now let's talk a little about just how many report requests are being made, by whom, and what information is in them.  And then we can talk about where all of that data comes from...