Back in March I posted “Five Reasons Why Ad Hoc Reporting Won’t Work In Some Organizations“. In that post, I listed some of the major concerns that I hear from potential clients when the subject of ad hoc reporting is broached. We’ve already addressed “Our people aren’t smart enough to create their own reports”, “We need to massage the data first” and “I don’t want people poking around in data they shouldn’t have access to”.
One of the other reasons I hear is that managers don’t want to train end-users to create reports, since they have folks in IT that already tasked with that. Some report authoring will always need to be handled by IT, due to it’s complexity, lack of data availability, etc… But I argue that the lion’s share of the development can be handled within each department instead, freeing IT developers to take on other projects critical to the organization.
Two Kinds of Users
First, let’s set the record straight. You will ALWAYS have a majority in your organization that will only consume content. They will never have the desire or need to create their own reports, and that’s OK. Keep on providing them with canned reports that they can refresh on their own and they’ll be content.
On the flip side, you will also ALWAYS have a few power users that can do things with that data that will make your head spin. You know the ones. They’re sitting in Excel right now. Slicing and dicing the data to gleam insights in the information. And they could get it done a lot quicker if they didn’t have to wait 5 weeks for IT to create the updated report they’re looking for.
It’s Not IT’s Fault
I’ve spent many years on the IT side of the fence, so I feel for my technical brethren. You’re knee-deep in the middle of another project, when a request comes in to create a new report or data download. You’ve got tons of other things to work on, and now you need to create a new report…only to have the user tell you while you built what they asked for, it’s not really what they wanted. Sound familiar?
Just imagine the time savings you’d realize if you created a reporting environment one time, then rolled that out to power users in each department to do the actual reporting. Sure, you’ll need to make tweaks here and there. And once in awhile even the power users will get stumped and need some help. In the long-run, however, not only do you clear your plate to take on more strategic initiatives that are critical to the organization…but the users will gain access to information quicker, be able to perform iterative development to meet their requirements, and become better data stewards in the process. It’s a win-win for everyone involved.
It’s All About the Reporting Environment
A well-designed reporting environment will require very little training for users with the right aptitude. I’ve seen power users develop basic proficiency in SAP BusinessObjects tools within a matter of days. And if the universe metadata layer (and underlying database) is designed properly, you can eliminate many of the data-related questions as well. What you’re left with is a power user that has all the data they need at their fingertips, and the tools needed to turn that into useful information that can be shared with the rest of the team.
There’s no magic bullet, and deploying a well-designed ad hoc reporting solution will take an investment in time and resources. What cannot be underestimated, however, are the productivity and knowledge gains that can be realized once ad hoc reporting is released to your user base.
Free Web Intelligence Best Practices Guide
We put together a Best Practices Guide for Web Intelligence Development that includes over 20 pages of tips and techniques for developing business-ready reports. Plus we'll show you the common functions that have a negative impact on performance, how to create interactive reports, the best ways to standardize look-and-feel, and much more!
GET YOUR FREE COPY OF THE GUIDE TODAY!