Even the most sophisticated technical implementation of an OLAP solution can fail if put into production without thought to the reporting needs of the users. Without user input, the system will not meet user expectations.
Frequently, we hear how the user community simply wants one reporting tool - an idea that speaks to simplicity, but is unfortunately flawed. The reality is there is not a single "silver bullet" reporting tool, because there is no single type of user. Typically, several use cases are needed to drive the application design. For example, an executive "big-button" user needs technology to be simple and guide him, while a technical analyst wants technology to get out of the way and let her quickly perform ad hoc analyses. The OLAP application developer must discover the needs of all interested users, and make sure they have options available that meet their requirements.
Oracle offers an approach that fits in with this reality. When looking at the different reporting tools an organization may need, the solution may indeed be a suite of tools to suit different users. Oracle Business Intelligence Suite Enterprise Edition Plus (OBIEE Plus) delivers reporting tools to support a wide range of end- user reporting needs.
Underlying the OBIEE Plus philosophy is delivery of tools that can be used for different purposes, yet should be integrated, so they are easy to maintain, regardless of data source. OBIEE Plus is the strategic platform for BI reporting from Oracle, and the examples in this chapter come mainly from that set of tools.
In addition, OBIEE Plus allows access to many different data sources, including both Oracle OLAP and Oracle Essbase, as well as relational sources. Companies can use OBIEE Plus to report from a single source, as well as to combine data from many different data sources by means of a federated query engine supported by a single semantic model, interface, dashboard, or report. OBIEE Plus will serve as the central reporting interface for Oracle for years to come. So, invest time to learn its tool set and many capabilities.
In this chapter, we cover many of the considerations necessary to support reporting from an OLAP application. We start by focusing on user discovery, followed by an introduction to the types of reports that are available. After you have a sense of what is possible, we bring the possible into the realm of what is doable with a discussion of deployment options and architectural considerations for your organization. Finally, we spend some time discussing the types of functionality you should look for in web-based and desktop-based reporting tools.
One consistent, successful strategy for OLAP applications is the formation of a user committee. This committee - whether formal or informal - helps to secure buy-in from relevant people throughout all phases of the project. A user committee generally starts with the people who championed the purchase of an OLAP system, and expands to include anyone with a vested interested in OLAP results. A well- rounded, representative user committee - that is, one with members from all areas of the organization that may use the OLAP application and the OLAP reports - is ideally suited to take on the task of user discovery.
Identifying the Consumers of OLAP Reports
Early in the process, use the committee to identify the potential content consumers, or end users, of OLAP reports in your organization. Typical consumers are executives, managers, and analysts. Do you have additional consumers in your organization? Identify the departments to which your consumers belong. Where, geographically speaking, are your consumers located?
For example, Company XYZ envisions a roll out to 1,000 users around the world. The company's purchase of software follows the standard breakdown of users: about 80 percent are strict report consumers, 15 percent need more interaction and analysis, and 5 percent are power or administrative users. The majority of these users are in the United States, but given the global nature of the company, it is probably a 60/40 split. The users require 24-hour support. As this software is implemented, the user breakdown and global nature of the company must be taken into consideration.
Gathering Information About Your Users
The next step is to find out how your users prefer to consume their information.
You might use a questionnaire or conduct interviews with interested parties. You do not need to collect exact numbers; rather, just get a feel for the needs of your different users. Your questions should suit your environment, but as a starting point, you may need to ask a few key questions. A good guide for determining the type of questions to ask is Oracle's Comprehensive Guide to Realizing Enterprise Performance Management Version 2.2. Here is a sample of questions that you may want to ask your users, paraphrased from that white paper:
- Do you expect to consume static reports with no interaction?
- Do you need reports that you can customize through interacting with the report? In what ways would you want to modify the report?
- Do you want a big-button approach to reports, such as dashboards that contain summary reports from multiple sources?
- Do you prefer to build reports from scratch, rather than using prebuilt reports?
How do you expect to access reports? From the desktop, Web, or both?
From your users' responses, you can begin to determine how many people in the organization will require which kinds of reports. Some need just one type of report, while others need three or four to provide context while analyzing data.
Discussing the Reporting Needs of Your Users
After you have formed a picture of what your users expect, you can begin to piece together the style of reports they may want to consume. Here are some questions that the user committee can use to discern which reports may be needed (also from the white paper):
- Are predefined dashboards part of the user vision?
- Is there a need for delivery via a corporate standard portal?
- Is there a "start from scratch" set of users who require ad hoc analysis and reporting? These users might require drill-down, pivot, and "slice-and-dice" capabilities.
- Do users need to integrate multiple data sources into one report? What about into one dashboard?
- Do some users need standard drag-and-drop controls along with a right- click context menu for ease of use?
- Is there a need for deployment through Microsoft Office?
- Do you need to provide the ability to drill through from the analytic measures to the underlying transactional detail?
- Is there a need for offline analysis?
- What about scheduling and batch bursting of reports?
Suppose that Company XYZ ended up purchasing 1,000 OLAP licenses to support enterprise performance management (EPM) and BI applications. Two different departments were involved in the purchase: the finance department needed 700 licenses, and the operations department claimed 300. Now that the user committee has done its work, the project team must work with each department and get more details about their users and reporting needs.
In the interview with the finance department representatives, they list several current reporting projects and the need to improve them. Executives have a 50-page book of reports created mainly in Microsoft Excel that takes a team of analysts two weeks each month to create. Around 200 executive users want to consume the reports in this book. Currently, they receive the book via interoffice mail, and keep copies of past and present books on their local computer hard drives. The executives would prefer to view the reports online in static dashboards and have links to PDF versions of past books stored in a central archive to support future audits.
The team that creates the monthly book still wants interaction with the Microsoft Office suite of tools, but with much more flexibility and speed. They want the ability to link data points from Excel to Word to PowerPoint. Instead of spending weeks to create the reports, they want a set of reports that they can simply refresh with the new monthly data. They also want any changes in hierarchy structure to flow through to the reports automatically, removing the need for manual updates.
Each of these executives has a team of around 500 managers and analysts who truly need both ad hoc reporting and the ability to start from scratch against that monthly data. They want to consume a group of dashboards as a starting point - to see the same information as the executives - but they also want to be able to modify the report sections and work free-form to do additional analysis. These users also want to do forecasting based on the seasonal monthly trends. They decide that an Excel add-in would suit their requirements, allowing them to drill down to detail data and pivot data, and write back to a database. The higher-level visual analysis features are appealing to a group of about 50 users that do statistical trending.
The operations department has a brand-new sales reporting project to meet the requests from its field sales team. All 300 users will be mobile, and they need to be notified when the sales reports for the previous day are ready. They want to receive an e-mail message that has a link to the online system, but also an attached static sales report for just their customers. The static report keeps them informed of the sales activity, and the ability to link to the online system gives them the flexibility to do some ad hoc reporting via the Web. They also need offline analysis capabilities, so they can work in an airplane or a location without Internet access.
To summarize, Company XYZ needs to deliver a unified reporting system to meet the requirements of both departments, starting with a single sign-on to corporate dashboards that everyone uses to see total company results. These dashboards provide links to additional reports and tools that make sense for the users' daily jobs. The reports need to be available via the desktop and the Web.
Clearly, a project team needs to be ready with reporting options and tools already in mind for the different styles of reports each user community mentioned.
In the next section, we review the types of reports that are generally available in a reporting tool. After that, we look at possible deployment options.