Your views, experiences on webi adhoc reporting

[Former Member]

Folks,

We have a boxi 3.1 base version implementation. Our user base consists of non-technical users, but they are very proficient in Excel and can churn out very high quality management reports too using excel.

We are trying to encourage our users to use BO/WEBI for their complete reporting needs, instead of exporting data into excel and create those reports. We have faced some challenges where it's hard to compete with Excel in terms of it's charting/visualization options.

I would love to hear your feedback on efforts you might have had to take to get your users comfortable with webi/ad-hoc reporting, steps that worked, bad ideas etc. You are welcome to share anything from high level strategies and training/BI adoption plans to individual sharing.

Thanks in advance for sharing.

Edited by: ramaks on Apr 9, 2010 6:12 PM

[Former Member · Accepted solution]

Ramaks,

There is a saying about horses and water (you can lead a horse to water, but you can't make it drink). I think the same analogy works here, you can lead folks to BusinessObjects Enterprise XI (Wonderful WebI), but you can't make 'em use all of it. What is the harm in folks going to WebI, creating their report, not using the bells and whistles, downloading it to Excel, and allowing them to format to their hearts content? The biggest battle any organization faces is getting everyone to go to a single source for the data. If everyone is building their ad hoc against the same database, as you're describing, then more than half the battle is won. The next issue is presentation, some folks can format something (like certain charts/graphs) that will distort the meaning, so that would be the next issue to address -- standards in presentation. However, if there are no standards in place, then you don't have a leg to stand on. In my own experience, the value of a "standard report" was not so much to make folks use it per se, but to show that when you have these data points appearing on a report, then this is the way to format the chart. I didn't care how they got the work done, just so that when it made its way up to higher management that it's format was consistent with the "standard report" method. Just to remind you, if a person builds an ad hoc report and requests a CSV data export (must run it in Infoview), that the output is according to the layout seen in the "Edit Query" mode; so based on this capability, it is clear to me that the BusinessObjects developers intended to support this type of activity -- grab and go in Excel (or Access, or anything else that reads CSV readily). So, no tears are shed if folks use something other than WebI as long as everyone is able to produce the same context at the end of the day.

Thanks,

John

[Former Member · Accepted solution]

John,

My sincere thanks. You have made a very valid point. Integrity of underlying data is the most critical aspect for any BI implementation. No matter how great a tool is with bells and whistles, unreliable data is the surest way to lose business interest and thus the BI sponsorship. So i totally understand where you are coming from on this issue.

In our case, we have pretty good data ( its integrity trusted by business) and ofcourse our webi is used for adhoc analysis. Our purpose is two-fold

A. To leverage existing enterprise capabilities ( scheduling, publication, share reports ) etc

B. Use Webi to make decently formatted reports - This will save everyone time.. business users need not repeat basic tasks ( weekly reports etc) and frees us in IT to some extent.. as these otherwise would be done in say Crystal.

So in a sense, we are already in a sweet spot as far as usage is concerned..just thinking of ways to let them leverage complete enterprise tool-set capabilities.

Regards

[Former Member · Accepted solution]

Ramaks,

Thank you for clarifying your angle

just thinking of ways to let them leverage complete enterprise tool-set capabilities.

My answer: training and case history. Be open to conducting training on a recurring basis, even if the attendance is sparse at first, having a consistent and clear-cut traiining plan, and executing it well in a hands-on classroom setting will get the ball rolling. As unpopular as it may seem, having some type of "mandatory" hands-on training before granting a userid/password to the system may be one way to start (but requires full support from the higher-ups too). Case history is to observe one of your groups "doing their thing", then devising the standard report/schedule, etc, and show how much time can be saved. Presenting your findings could be done in a periodic newsletter, or a "case history" corner on your web site. The goal is to not disparage anyone, but to come alongside and show how using basic features of BOE can make a person's life easier.

Again, just some thoughts in continuing to think through the "which comes first: the chicken or the egg" syndrome.

John