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.
Conclusion
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.
Related Posts:
- Why Ad Hoc Reporting Won’t Work (part 3): I don’t want people poking around in data they shouldn’t have access to
- Why Ad Hoc Reporting Won’t Work (part 1): Our People Aren’t Smart Enough
- Why Ad Hoc Reporting Won’t Work (part 5): If I Give Them Ad Hoc Access to Data, They’ll Keep Asking For More
- Five Reasons Why Ad Hoc Reporting Won’t Work in Some Organizations
- Why Ad Hoc Reporting Won’t Work (part 2): We Need to Massage the Data First
Trackbacks/Pingbacks
[...] [...]