Over the past ten years, I’ve been a part of literally hundreds of SAP BusinessObjects client demos.
I’m a firm believer in the solution selling approach, so most of the demo time is spent focused on solving the client’s specific issues. However, I do like to briefly review the rest of the SAP BusinessObjects product stack for a number of reasons:
- As a visioning workshop to show them the other tools and technologies they might be able to apply to their organization (you don’t know what you don’t know);
- To demonstrate how SAP BusinessObjects has the breadth of products to deliver true end-to-end business intelligence; and
- To head off any potential competitors who try to tout their product of having something that the client isn’t aware of SAP BusinessObjects having.
My demo subjects always welcome this quick look, and oftentimes end up utilizing some of the components that they were unaware of previously.
I’m always struck, however, when we reach the ad hoc portion of the demo and begin talking about WebIntelligence. While the end-users in the room get excited about having the ability to create their own reports and analysis without waiting on the IT department, we usually get a lot of push-back from the managers and executives in the room.
Don’t get me wrong. SOME progressive executives “get it” right away. But the vast majority that I’ve met with are initially resistant to the idea, until I’ve had some time to address their concerns.
It could be a fear of the unknown, or maybe they’ve been burned before by another reporting tool. In any case, I always get some interesting commentary on how their organization is unique and why ad hoc reporting won’t work for them. It’s always an eye-opener for me, and it gives me a chance to peak inside the organization’s culture.
I’ve compiled a list of some of the major concerns I’ve heard here, and will address each of them in an upcoming post. In the meantime, please comment on concerns with ad hoc reporting that you’ve seen in your organization, and what the outcome was. I would love to include your comments in my response.
- Our people aren’t smart enough to create their own reports (believe-it-or-not I’ve heard this many more times than I care to acknowledge)
- We usually need to “massage” our data a bit to make sure it is correct before sending out a report
- I don’t want people poking around in data they shouldn’t have access to
- I pay people in IT to write reports, why should I train end-users to do it?
- If I give them ad hoc access to data, they’ll keep asking for more data / others in the organization will ask for ad hoc access
What concerns do you have/have you had with ad hoc reporting in your organization? What were the results?
Related Posts:
- 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
- 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 4): I Pay People in IT to Create Reports
- Why Ad Hoc Reporting Won’t Work (part 2): We Need to Massage the Data First
Wednesday, March 10, 2010 at 8:46 am
We had many of these same concerns in my organization. But the biggest concern we had was over people creating their own reports when there already was a “canned” alternative already available to them. We ended up only giving ad hoc to a few people because of that, but I was wondering if there’s a better way.
Wednesday, March 10, 2010 at 1:20 pm
@Taylor Myers
Thanks for the comment.
If the report’s metadata (description, keywords, etc…) is filled in when it is published, that information can be used to search for an existing report in Business Objects. In addition, we also recommend that organizations establish an internal Business Objects committee/user group to help drive and support the use of the tools.
If someone needs to create a one-time ad hoc report to address a specific question that’s one thing. But if they’re going to invest a larger amount of time to create a report they expect to use ongoing, we recommend taking it to the internal committee first to see (a) whether that or a similar report already exists and (b) whether their needs can be combined with others to create a single report that will satisfy everyone.
With some planning and a little bit of communication, you can allow everyone to take advantage of the powerful tools that are available…without having to worry about a proliferation of identical or nearly-identical content.
Wednesday, March 10, 2010 at 2:18 pm
I saw a presentation at the TDWI in St. Louis a year or two ago (unfortunately I can’t remember the name of the gentleman who presented) and he talked about the difference between what people want (easy access to all of the information they want when they want it) and what most tools provide (the opportunity to build queries, format results, etc.). I personally think SAP BOBJ’s Explorer tool is a lot closer to what most people want when they say ad hoc.
I myself believe more in a guided analysis approach, where the individuals who have proven themself best at resolving business issues describe the process they go through, what data they need to see, and what they do with that data, and that process is built into a BI workflow that can be reproduced and distributed to individuals with similar responsibilities who either haven’t figured out how to resolve those business issues or who would benefit from having the data lready laid out in a format they can leverage. That isn’t true ad hoc, but it generates a feel similar to what most people are asking for in that they see some data, and if it needs more analysis they can go to the next relevant level over and over until the reach the level they need.
Wednesday, March 10, 2010 at 3:46 pm
@Jamie Oswald
You’re correct…there are many different definitions of ad hoc floating around. When a client tells me they want to implement ad hoc reporting, more often than not they really mean having a report with prompts that can be satisfied to tailor the result set. That seems similar to the guided analysis approach that you spoke about.
We then target the one or two power users in each department to deliver the “true ad hoc” reporting when needed for the others in their department.
The tools are getting better, and Explorer is a giant leap forward in terms of enabling users to have access to their data. The problem is that the BI industry as it stands competes largely on features and functionality, and companies are forced to continually add features (hence complexity) to their software to stay in the game. It would be nice if the industry as a whole would take a cue from 37 Signals, and work towards developing simpler, more elegant software.
Thursday, September 2, 2010 at 10:16 am
I personally worked in a company, where already exists system that supplies users with needed reports. There isn’t actually a need of a new report every day or even month. In fact, for any company number of needed reports is limited and doesn’t change significantly in short time, which means most of the time system exists in idle state – everyone have what they need. If need of something new arises – there are actualy two paths: 1) You already have data needed in form of actual report – you just need to deliver it to end user, or data needs to be slightly altered to match criteria which can be easily done once in most tools used by users w/o need to rebuild/edit report on universe( or similar) level. 2) new project that requires new data not present.
Let’s look in 2) in detail. With my experience ( including SAP/BO-like products) when something new appears in 80% cases it would be data that wasn’t included in datamart/cube/universe from start. So End-Users can’t solve it and it goes back to IT to solve the issue. So summing two up we got situation where if a need for ad hoc report arises it either can be effectively done by existing tools or can’t be done by End-Users at all.