Why Ad Hoc Reporting Won’t Work (part 1): Our People Aren’t Smart Enough

I recently 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.  As promised, I will be addressing each of those concerns and showing how they can be overcome.  Today, we begin with the first one: “Our people aren’t smart enough to create their own reports”

As I mentioned previously, I hear this one way too often and it usually is a case of not understanding the capabilities of a well-designed Business Intelligence solution.  Managers are concerned (and rightfully so) about the level of training their users will require, their ability to understand how the data fits together, etc…  But it doesn’t have to be a concern at all.

With the breadth of tools and capabilities that are available in today’s BI solutions — and with a solid understanding of the user’s requirements for ad hoc information access — it can be relatively easy to build a solution that delivers on those requirements without requiring a huge investment in training.

Let’s first take a step back to look at what ad hoc reporting really means.

What is Ad Hoc Reporting?

When a client tells me they are interested in implementing ad hoc reporting, I always ask them to define that for me. My experience tells me that people often have varying views of what ad hoc reporting really is, including:

  • Ability for a user to refresh a report themselves and fill in prompts to filter the results
  • Ability to perform simple queries or ask simple questions of the data to find the information they need
  • Ability to create production-ready reports themselves.

When someone in the SAP BusinessObjects world says “ad hoc reporting”, they typically are referring to the WebIntelligence product.  But as you can see there are a variety of other tools that can be used to satisfy those needs — depending, of course, upon your definition of “ad hoc”.

Using SAP BusinessObjects Tools to Support Basic “Ad Hoc” Reporting

  1. Crystal Reports
    While certainly not a tool that I would give to untrained end users, Crystal Reports themselves are an excellent way to implement  “filter and refresh adhoc”.  These reports could also include interactivity to drill into the hierarchy of the data, link to more detailed reports, etc… making it a great way to build a sandbox for simple interactive, ad hoc reporting
  2. Xcelsius
    While typically thought of as a dashboard/visualization tool, Xcelsius can also be used to assemble easy-to-use ad hoc sandboxes.  Using filters, drop-down lists and the like, IT can deliver visually stunning, interactive “ad hoc” reporting to end-users.
  3. Explorer
    Finally, SAP BusinessObjects Explorer provides search, exploration and visualization — much in the way I’ve described above in allowing ad hoc reporting within a predefined sandbox.

Depending upon your needs, this level of ad hoc reporting may be enough.  In fact, it will probably satisfy most ad hoc information needs.  If you need to move beyond that, however, read on for some tips on how to create a true ad hoc environment with SAP BusinessObjects that people can and will use.

A Few Tips for Creating a True Ad Hoc Environment

Even if you need to deploy true ad hoc reporting, it shouldn’t be cause for alarm.  While there will always be some degree of a learning curve in terms of creating queries, formatting the report, etc…, there are a few steps we can take to minimize the training required.

  1. Focus on Subject-specific data
    Throughout my 10 years as a BusinessObjects consultant, I’ve seen a lot of styles of Universe development.  Strike that.  I’ve fixed a lot of styles of Universe development.

    While I suppose it’s noble to develop a universe that contains every bit of information a company needs, if that universe contains 50 classes, 1,200 objects and 9 contexts…I respectfully say you’re missing the point.  (This isn’t an extreme example…unfortunately we’ve seen fixed much worse.)

    Our methodology for developing ad hoc BusinessObjects universes is to focus on a specific subject-area, and provide all the information a would-be end-user needs to answer a specific set of questions.  No more.  No less.

    Instead of developing a “Finance” universe, think about developing one universe for Accounts Receivable, one for Accounts Payable, one for the General Ledger, etc…  Not only will the universes be easier to use, but they’ll be infinitely easier to maintain as well.

  2. Start with the data in the correct format
    With SAP BusinessObjects, you have a number of opportunities to get the data in the correct format for a given analysis: at the database level, in the universe, and in WebIntelligence report itself.  And I recommend tackling it in that order.

    If you can “fix” the data at the database level, do it.  Not only will it be easier to develop the universe if the data is structured for reporting, but you’ll also likely gain performance advantages along the way.

  3. Build as much business logic into the Universe as possible
    Continuing on with the theme from #2, try to push as much business logic to the universe level so end-users won’t have to worry about data aggregation, calculating averages, grouping data together, etc…Once we understand the specific requirements, we work hard to make the ad hoc environment as close to “drag and drop” as possible.  The less the end-user needs to do to get the results they’re after the better.

That’s it for part 1, “Our people aren’t smart enough…”.  Stay tuned for our next “objection” to implementing ad hoc: “”We usually need to massage our data…”.

Question:  How does your organization use ad hoc reporting?  If you’re utilizing true ad hoc reporting, what steps have you taken to make the environment as easy-to-use as possible?

Related Posts:

  1. Why Ad Hoc Reporting Won’t Work (part 4): I Pay People in IT to Create Reports
  2. Why Ad Hoc Reporting Won’t Work (part 3): I don’t want people poking around in data they shouldn’t have access to
  3. Why Ad Hoc Reporting Won’t Work (part 5): If I Give Them Ad Hoc Access to Data, They’ll Keep Asking For More
  4. Five Reasons Why Ad Hoc Reporting Won’t Work in Some Organizations
  5. Why Ad Hoc Reporting Won’t Work (part 2): We Need to Massage the Data First
, , ,

This post was written by:

- who has written 26 posts on the Altek Solutions Business Intelligence Blog.

Follow Scott on Twitter at www.twitter.com/scottrzimmerman.

Contact the author

Leave a Reply