Last month I listened to several discussions about the importance of choosing the right reporting tool when installing a business intelligence (BI) solution. Here are some questions that were raised: Is the reporting tool really relevant when deploying a complete BI solution? Which type of reporting tool should I choose when deploying a BI system? Choosing the right reporting tool may not be as easy and simple as it appears.
Some BI system consultants and developers consider that when all the basic pieces—data warehouse, data flow, and analysis services—are in place, the reporting tool can be considered secondary and has less relevance in the information cycle. With all the background set up, you can work with a standard reporting tool and generate all the necessary reporting with reliable information. Personally, I don’t agree with this idea. Many times I have experienced the pain—and sometimes even the failure—in a project due to the fact that during its planning, the reporting tool was not considered as important as the rest of the other BI system components.
Information compiled from our database shows that most vendors have a strong set of reporting capabilities (above the average solution). The graph below shows the level of support (weighted average) for reporting capabilities (derived from our BI knowledge base).
Figure 1: According to our own data, most vendors have strong set of reporting capabilities, above the average
Is the Entire Package Really Important?
The first reason to consider a reporting tool as a fundamental part of the overall BI solution is simply because it’s the presentation layer of the system. There’s a Spanish phrase that says: “de la vista nace el Amor” which glosses to “looks aren’t everything, but they sure do count for a lot”. Don’t get me wrong, beauty doesn’t only come in colors and forms, but also in data frames, and if put in the right place, it can help the decision-making process. Also, you don’t want to mess with a reporting tool that’s not able to fit with your corporate image, or that has a poor set of visual resources to rely on.
The second reason is that sometimes when selecting a reporting tool, you have to consider all the necessary internal and external regulations and compliance needs that need to be met during the report publishing process. If this is your case, you will need to pick a reporting solution that can offer you all, or at least the most important reporting standards required for your organization, like the IFRS (International Financial Reporting Standards), or any other regulation.
Also, consider which types of reports need to be generated within your BI solution:
- Management Reports (Strategic): used to visualize business performance, strategy, and marketing data
- Business Reports (Analytical): periodical reports used for sales, customers, delivery, etc.
- Operational Reports: used for reviewing stock, expense, and accounts payable data, etc.
The types of reports have a lot of influence when you are considering a reporting tool because they are also related to the number of users using the reporting tool. It’s important to try to establish a list of pros and cons of all your reporting needs based on the depth (or type) of reports you will be generating.
Figure 2: General relationship between the report type and its number of users
Is not the size of the tool, it’s the way you use it.
The visual features are important factors, but the ability to empower users with self-service tools and resources is also important. Nowadays, decision makers and analysts need to have the ability to make analysis by their own means. Enabling end users to drill down through data, have data interaction, and let them directly use the data coming from different sources can definitely play an important role when defining which type of reporting tool one wants for our their organization.
But the use of this sort of capability has a lot to do with the corporate philosophy of the organization. Some organizations still rely heavily on common paper report designs, while others rely on screen analysis tools—like dashboards and other visual analysis tools (scorecards or online analytical processing [OLAP)]) tools to do get the job done.
Choosing the right reporting tool is important to bring end users the tools they really need to perform their common daily tasks.
It requires a lot of effort to make it work.
To date, I haven’t met an end user who is happy with the idea of dedicating endless hours to completing an executive report. Reporting users—as I like to call them—are the ones who have always very tight schedules. As such, they need an easy reporting tool to simplify their lives.
Ease-of-use helps an organization gain on productivity (speed of development, visual look improvement, etc.). But even when the “ease-of-use” concept is considered the “golden rule” on deciding which reporting application or BI suite to select, it can have very different meanings depending on the type of organization that is selecting the reporting tool.
My golden rule is: Consider the reporting capabilities that are important to you and prioritize them jointly with your users. Some of the major capabilities to consider are:
• complex reporting capabilities like drilling through information details, the look and feel of formatting, and so on;
• specific reporting capabilities like financial reporting, crosstab reports, compliance with specific regulations (e.g., XBRL, etc.);
• integration with other BI set of tools;
• analysis capabilities like OLAP cubes, predictive analytics; and
• other advanced features like alerts, advanced report distribution, etc.
The above list is not an exhaustive one and can grow to add more specific functional criteria. It is essential to establish a list of at least three to five priorities for your organization.
The Bottom Line
Selecting a reporting tool can be a critical phase when deploying a BI solution for an organization. At the end of the day, reporting is an end user matter, so it is important to comply with end user, organizational, and regulatory requirements.
I welcome your thoughts—please leave your comments below.
My company has built over 180 data warehouse and BI solutions and has been doing so since 1996. We focus now on the consumer goods industry, do to the complicated issues they have with POS and syndicated data.
This said, the architecture is without a doubt the most critical factor. BI tools are very important and can make or break the success of a data warehouse implementation. However, this is not because they are more important than the architecture. It is typically for several other reasons. First, we see companies chose a BI tool first and then architect around it. Wrong thing to do. Second, we see companies chose a SINGLE BI tool and expect everyone to use it. This is also wrong. Everyone has different job requirements and that is why the architecture HAS to come first. If you have the architecture open and flexible, then any solid BI tool can query it. Third, companies chose one tool, because the vendor told them they only want one to manage. Then they try to force feed a serious analytical tool onto management and sales people who have higher priorities than learning database schemas. Most companies have several BI tools. Let’s remember, that BI tools are not just Cognos or Business Objects, other tools such as BlueSky Analytics, Access, Hyperian, Forecast analysis tools, Promotion analysis tools, etc., should all be able to leverage the data warehouse platform. Tools can query a database, but if the data isn’t valid or in a usable format, then no tool will work well. Often BI tools are blamed for bad architectures. That’s because the BI tool is dependant on the architecture being sound. There is nothing wrong with multiple BI tools in a company. Give the users what they want and make the information they are querying reliable and you will see success.
Mitch, I saw this, thought you would like it.
I really appreciate you interesting feedback. I agree with you that the architecture could really come first. But I also think that the puzzle really has to be complete with the right selection of the reporting tool, in fact this could mean selecting a different reporting tool from the one integrated on a major BI vendor, which, as you stated in your comment can happen quite often.
I concur with your last phrase:
“Give the users what they want and make the information they are querying reliable and you will see success”
But, maybe it would be a good point of discussion to consider if this is always achievable regardless of the reporting tool. What do you think? Please leave a comment or feedback below.
Thanks for the post. Here’s a tool to use to create and publish your report online in minutes, without coding. You can create different graphs and layouts http://www.caspio.com/online-database/features/reports.aspx
[…] and MS Excel. The unparalleled advantage of data negotiations offers multifaceted control. This arrangement ensures relativity between stored procedures, views, and tables. Furthermore, extended data elements are stored and accessed […]