BI Problems – Report Chaos

I have to say straight out that while my work environment may be unique in many areas, I doubt that I am the only one to have come across this issue.  For over a decade we have allowed users outside of IT unrestricted access to production environments to write their own reports in their own tools.  Over the course of this no one has provided any guidance on how to manage large stores of reports or even how to ensure that time and effort is being spent on the right types of reports.  Because of this we are currently faced with over 10,000 report files in existence on our network to review.

Yes, I know that sounds like a ridiculous number but when you consider that a few dozen people were given the tools and access and that they’ve had a number of years to produce and distribute these files it isn’t that much of a stretch to imagine how this got out of hand.  Admittedly this is all very overwhelming and I have spent a considerable amount of time trying to sort out how best to approach determining which of these reports my team will be converting as part of a larger project and also how to prevent it from happening again in the future.

Our first step is really to determine the scope of the project.  This means gathering the list of reports, who owns them, what systems are they written off of and most importantly if they are still needed.  My gut and experience tells me that somewhere in the realm of 20% of these reports will turn out to be no longer needed and perhaps another 20% will be good to have somewhere down the line and therefore not a priority.  The second step is to take this master categorize list and starts splitting it out based on source system, in this particular case if the data source for the report is not impacted by our conversion then I can leave them alone for now.  Once that is done that we can move on to the third step which is to take this hopefully paired down list and start categorizing reports based on three very particular criteria; mission critical, time sensitive, and decision support.

Mission critical reports would be those that if they were not available business would be severely hampered or would cause a significant amount of difficulty.  A good example of this would be a daily production reports, in the case of a publishing company you’d need reports to confirm your space is utilized properly and that all of the pieces necessary for publication are available and I would add to that any report involved in balancing billing or any other financial system.  Time sensitive reports are those that are needed for specific time based functions, examples of this would be budget reporting, financial projects and anything needed to determine progress towards goal.  Decisions support is a little harder to define, I look at this as these reports as needed in order for the business to make good decisions so  things like profit and loss reports, time and attendance and anything involving trend analysis would fall there.

Once you have all these buckets defined and your reports completely categorized you can start the work of prioritization and assigning resources.  This does make it a bit easier to prioritize in that mission critical reports should come before time sensitive and time sensitive reports in turn should come before decision support as a general rule.  A couple of additional things to consider, look for areas where you may be able to combine reports that use similar datasets into single reports that use parameters to give a more custom view and also where you have reports that existing solely for querying, there are better tools to accomplish that.

That’s my plan of attack, straight forward and hopefully efficient in the long run and not too painful in the short term.


Comments are closed.

%d bloggers like this: