Art of BI: Top 8 Oracle Reporting Mistakes You Should Avoid

Business Intelligence (BI) software can help you achieve business objectives, but its implementation and use requires solid understanding of best and worst practices. You can avoid failure of your BI initiatives by first, not believing the hype, and second, not falling for the lure of the latest tool, platform, or application. A careful selection of a solution that works for your organization is a great start, but sticking to best practices during implementation, rollout, and usage of your BI software will help you realize its potential and make you better informed when it comes to business decision making.

Here are the eight biggest mistakes people make in Oracle BI reporting (in no particular order). Awareness of some of the worst practices and learning how to avoid them will help you achieve success with your own BI initiatives.

1. Trying to replicate an old report exactly as it used to be

At least one person at every client says, “I need this exact report in the new tool.” Sometimes that works / is easy and sometimes it does not. Just because it worked previously does not mean it will work now or that there is not a better way to visualize the data on that report. Sure, there are the specific reports that have to be replicated but that does not mean all of them do. The main purpose of implementing BI solutions is to find a better way to display and communicate data. Users who try to replicate old reports with a new BI application run the risk of becoming frustrated because Oracle BI tools won’t be able to replicate exactly what used to be accomplished with the old tools. This can happen because of how the data warehouse is designed or how the tool itself displays. Don’t get sucked into the black hole of individually customizing reports (adding JavaScript, extra steps, etc.) when you can take a step back and see if there is a better way to get what you need.

It puts a lot of stress on a server to try to replicate data in a specific manner that is was not built for. Knowing the tool’s limitations and specifics can help determine if the report should be built utilizing OBI’s analysis or in BI Publisher, which produces pixel-perfect reports that are well formatted. Your best bet is to understand the tool and its limitations and decide whether you can salvage some of your existing report design or whether you should start from scratch.

2. Only using plain old tables or pivot tables

Even though tables in Excel provide much utility for business users, they can compromise the quality and consistency of information. The use of plain old Excel as a BI tool is not recommended, especially for large organizations. Utilizing Oracle BI correctly, it’s much easier to both visualize and interpret the data. Is it easier to find out that a key performance indicator (KPI) is off by scanning through rows and columns of data, or by sitting on a performance tile (or some other different visual) on your dashboard? Utilizing correct visualizations gives you the ability to make faster decisions with greater confidence, which can drive down costs and save money. Using offline spreadsheets or pulling online data into offline spreadsheets could land you in a situation where users are pulling information separately, using disparate criteria, and you get stuck trying to compile all the different reports. But if you need to integrate a spreadsheet or other data into your reports, OBIEE 12c allows for data mashups so you can accomplish this in a more controlled manner. Make use of the tools at your disposal – it’s worth it to move forward into the more innovative and efficient frontiers.

3. Picking flashy visuals that do not make sense for the data

Selecting report visualizations that are decked out with lots of color and visuals may make them look impressive but does not necessarily improve insight. In many cases, it can hinder functionality and negatively impact the time to get to the correct answer as well as user adoption. Visualizations should be easy to read and interpret, but should also make sense of the data. The purpose of dashboards and reports is to clearly convey critical information, which your organization uses to achieve its goals. For example, it doesn’t make sense to use a heat map of the entire continental United States to convey a number that has nothing to do with the question you’re trying to answer simply because it looks cool. Although the map looks slick, how does that help you run the business and get you to the answers you need?

4. Trying to use Oracle BI to display data in a way the underlining data was not built to do

This is one of the most complex of Oracle reporting mistakes one should avoid. This worst practice arises when a data warehouse is viewed as solution to all information problems. Understanding the data and how it was set up in the source will help drive the Repository development that in the end will help with report development. Trying to put a square peg in a round hole will just cause frustration and distrust in the tool, when it is not the tool that is the issue.

It can be tricky configuring Oracle BI on top of an underlying online transaction processing system (OLTP) often used by financial institutions and in retail sales. It is recommended that you build the data warehouse with the future reporting tool and end game in mind.

5. Building complex calculations in the reporting layer instead of the RPD

It is confusing when you open a column formula and see a bunch of lines of code to create a calculation but then have to copy and paste that into a new column (correctly) when building a new report with that same value. This can all be done and depending on the case should be done in the RPD. The RPD comprises three layers: physical, business model mapping (BMM), and presentation. Once the physical layer is established and the data is moved into the BMM, the data can be transformed to better serve the end user. Here you can start putting together what will look like your future presentation tables and columns and can perform basic to complex calculations on columns, create additional joins, and other tasks.

These tasks should not be completed by just anyone, but more of a seasoned power user or the application administrator (some companies have and RPD developer too). Someone doing this should be well versed in the RPD and the front-end reports utilizing the calculation as not all calculations can or should go in to the RPD. Column calculations that are utilized in more than one instance or single complex calculations could be moved into RPD to take stress off the BI Server to calculate on the fly – this can potentially mitigate different types of issues (i.e. performance).

Once the calculation is created in the BMM, the developer moves it into the presentation layer and sets up the column. Then end users to can bring their reports into the column in an easier, less stressful manner.

6. Creating reports that display too much data (data-dump reports)

Too much non-essential data can make a report confusing, ineffective, and slow. Organizations generate huge amounts of data that can help them discover very useful insights and drive business decisions., But that doesn’t always mean, “Give me all the data and I will find the answers I need.” Pulling in large amounts of data takes time and then you must sift through it to get to the certain numbers you are looking for in the data dump. There are lots of issues that could occur creating data-dump reports; performance, security issues, user adoption– just to name a few.

Planning the report to show the key information and what actually needs to be seen is better and more effective than throwing it all out there and hoping for the best. It’s important to determine the problem(s) you are trying to solve, then pinpoint a core set of KPIs that will help you achieve your goals. From there, you can create tidy dashboards and effective reports that include only the most relevant information to drive business decisions. Putting in the effort and time to build effective reports up front can save time when it matters most later. This has a lot of similarities to the next topic on overpopulating dashboards with reports.

7. Overpopulating a dashboard with reports

Overpopulating a dashboard with too many charts and reports, no matter how attractive it may look, is easy to do, but should be avoided. There are two main concerns when overpopulating a dashboard. One being end-user confusion and efficiency and the other being performance/server stress.

Too many reports on a dashboard can cause end-user confusion, loss of time spent locating the desired report/values, and more difficulty with user adoption. When creating a dashboard, there are a lot of items to keep in mind (I will not bore you with all of them but you can check out my white paper on storyboarding to gain some more insight). A dashboard should not only be visually appealing, but also functional. Throwing 20 common reports on a page so everyone who is anyone has access to all the numbers in one spot can be every inefficient and take longer than carefully putting together the story(board) of the data.

Now let’s talk about the back-end chaos that can occur when trying to cram everything onto one dashboard. Each report generates its own logical SQL that is then sent to the BI Server to process. Imagine someone throwing 20 blog posts at you at one time and saying “read these” – you cannot do it all at once. Then add in multiple concurrent users looking for different views of that dashboard at the same time to add more stress to the server. It puts time and stress on the BI Server and that can turn into performance issues with the dashboard. This is something you don’t want because then you start losing the trust of your users because the dashboard takes minutes to render instead of a few seconds.

8. Restricting your power users from self-service reporting

A major problem for many organizations when using self-service BI occurs when users find the tools too difficult to master and revert to asking the IT department for custom reports. Others overuse the tools, creating report chaos, or worse, creating runaway queries that bog down performance. These are legitimate concerns, but don’t let them completely deter you from allowing your power users to have access to these helpful tools.

It’s important to know your users and their BI functionality comfort zones; you will usually figure most of this out during the implementation or training. Securing the environment correctly so your users have the freedom to utilize self-service, but also mitigate risk, is key. Also, giving access to a non-critical environment can allow your users to build their skills, help them learn more about the tool, and build your confidence in them using the tool without risking the chaos that could ensue. Self-service BI is not the enemy, and can help in more ways than it can hurt, as long as it is well-managed.

Use Your Resources

As you can see, a lot of intelligence needs to go into selecting and implementing a business intelligence solution. Why not tap our intelligence when evaluating your BI options? Datavail offers 24×7 managed services and project consulting in BI/Analytics, data warehousing, and enterprise performance management. Our expert consulting team specializes in integrations, implementations, and upgrades for applications across the Oracle stack, including Hyperion, OBIEE, OBIA, GoldenGate, WebLogic and more.

For additional resources about Oracle reports please download our white papers: Storyboarding in Oracle Analytics and Data Visualization and Discovery in Oracle Analytics