Reporting Tool Selection
Buy vs. Build
There is a wide variety of reporting requirements, and whether to buy
or build a reporting tool for your business intelligence needs is also
heavily dependent on the type of requirements. Typically,
the determination is based on the following:
- Number of reports: The higher the number of reports, the more likely that
buying a reporting tool is a good idea. This is not only because reporting tools
typically make creating new reports easier (by offering re-usable components), but
they also already have report management systems to make maintenance and support
functions easier.
- Desired Report Distribution Mode: If the reports will only be distributed in
a single mode (for example, email only, or over the browser only), we should then
strongly consider the possibility of building the reporting tool from scratch.
However, if users will access the reports through a variety of different channels,
it would make sense to invest in a third-party reporting tool that already comes
packaged with these distribution modes.
- Ad Hoc Report Creation: Will the users be able to create their own ad hoc
reports? If so, it is a good idea to purchase a reporting tool. These tool
vendors have accumulated extensive experience and know the features that are
important to users who are creating ad hoc reports. A second reason is that
the ability to allow for ad hoc report creation necessarily relies on a strong
metadata layer, and it is simply difficult to come up with a metadata model
when building a reporting tool from scratch.
Reporting Tool Functionalities
Data is useless if all it does is sit in the data warehouse. As a result, the presentation layer
is of very high importance.
Most of the OLAP vendors already have a front-end presentation layer that allows users to call up
pre-defined reports or create ad hoc reports. There are also several report tool vendors. Either way,
pay attention to the following points when evaluating reporting tools:
Data source connection capabilities
In general there are two types of data sources, one the relationship database, the other is the
OLAP multidimensional data source. Nowadays, chances are good that you might want to have both.
Many tool vendors will tell you that they offer both options, but upon closer inspection, it is possible
that the tool vendor is especially good for one type, but to connect to the other type of data source, it
becomes a difficult exercise in programming.
Scheduling and distribution capabilities
In a realistic data warehousing usage scenario by senior executives,
all they have time for is to come
in on Monday morning, look at the most important weekly numbers from the
previous week (say the sales
numbers), and that's how they satisfy their business intelligence needs.
All the fancy ad hoc and drilling capabilities will not interest them,
because
they do not touch these features.
Based on the above scenario, the reporting tool must have scheduling and distribution capabilities.
Weekly reports are scheduled to run on Monday morning, and the resulting reports are distributed
to the senior executives either by email or web publishing. There are claims by various vendors that
they can distribute reports through various interfaces, but based on my experience, the only ones that
really matter are delivery via email and publishing over the intranet.
Security Features: Because reporting tools, similar
to OLAP tools, are geared towards
a number of users, making sure people see only what they are supposed
to see is important. Security can reside at the report level, folder
level, column level, row level, or even individual cell level.
By and large, all established reporting tools have these capabilities.
Furthermore, they have a security layer that can interact with the
common corporate
login protocols. There are, however, cases where large corporations
have developed their own user authentication mechanism and have a
"single sign-on" policy. For these cases, having a seamless integration
between the tool and the in-house authentication can require some work.
I would recommend that you have the tool vendor team come in
and make sure that the two are compatible.
Customization
Every one of us has had the frustration over spending an inordinate amount of time tinkering with
some office productivity tool only to make the report/presentation look good. This is definitely a waste
of time, but unfortunately it is a necessary evil. In fact, a lot of times, analysts will wish to
take a report directly out of the reporting tool and place it
in their presentations or reports to their bosses. If the reporting tool offers them an easy way to
pre-set the reports to look exactly the way that adheres to the corporate standard, it makes the
analysts jobs much easier, and the time savings are tremendous.
Export capabilities
The most common export needs are to Excel, to a flat file, and to PDF,
and a good report tool must be able to export to all three formats.
For Excel, if the situation warrants it, you will want to verify that
the reporting format, not just the data itself, will be exported out to
Excel. This can often be a time-saver.
Integration with the Microsoft Office environment
Most people are used to work with Microsoft Office products, especially Excel, for
manipulating data. Before, people used to export the reports into Excel, and then
perform additional formatting / calculation tasks. Some reporting tools now offer
a Microsoft Office-like editing environment for users, so all formatting can be done
within the reporting tool itself, with no need to export the report into Excel. This
is a nice convenience to the users.
Popular Tools
No comments:
Post a Comment