Oracle OBIEE Reviews

I use this BI solution for ad-hoc and complex reports for finance and HR.

The main features of this solution are that it is easy to use, intuitive, and user-friendly. When I retrieve the data from the database it is in a very raw form, then when I use the Oracle Report Builder it has advanced intelligence features to allow me to view and make changes to the data easily.

There could be better integration with other solutions, such as Microsoft Office.

I have been using this solution for approximately six years.

The solution is 100% reliable and stable.

The solution is scalable. I have extended many areas in the reports and in other areas of the tool. My colleague was doing a project report in which he had to make some divisions and multiplications, similar to analytical functions. However, he was not able to do it in the SQL language. He gave me to try it in this BI tool solution and we achieved accurate results.

I have not found any issue to contact the support about.

The solution was easy to deploy and install. However, I have used the solution for a very long time and I am familiar with the technology, this could be why it was extremely easy for me to install and configure but might not be for others.

I would recommend this solution.

I rate Oracle OBIEE a ten out of ten.

We use the product to bring reports to the dealers. It is performing well.

We recently upgraded to version 12c.

It mostly supports enterprise level data. We have millions of records on a daily basis.

I would like more graphical charts.

While it is a user-friendly, data-driven tool, the data modeling should be easier to use. 

The stability is good.

It is good. I can use it with any type of data models, such as relational lines and dimensional lines.

The technical support is not as good as before. They used to have very good support five to six years ago. The support is now hectic and takes too much time to resolve issues. We often can resolve issues on our own before they can.

I would recommend the OBIEE over any other tool. Look at OBIEE and compare it with the competition.

Most important criteria when selecting a vendor: more technical features, technical support, and performance.

The most valuable feature for us is that it gives us the ability to provide our business users with daily real-time reporting on sales and inventory. This is obviously important for them to keep their finger on the pulse of what's being sold and how much of it.

Having up-to-date, current data for the executives and the managers that make decisions allows them to make more accurate decisions and helps us leverage our business. It's an advantage. It allows our management teams to make the right decisions with the right data. It provides our reporting visually. Some people like to see the bar charts versus the numbers and they like to see a trend. It's easy for them to read and to use.

It seems to be a little bit complex for an everyday user to grasp and get ahold of if they want to build their own reports. I think it takes a little bit more training for the users to get on board. It's not as intuitive as I think they would expect it to be. A lot of users like spreadsheets. I think if you give them a fancy tool, it will give them a little bit to adapt to that.

We've had no issues with deployment.

It's been pretty stable. We've had no issues with stability.

Operationally, it's been great. It doesn't need a lot of hand-holding. We run into a space issue every now and then. ETL to get the data into the data warehouse where it's reporting off of works great, but that's just a normal part of growth, I think. I don't know that I'd even call it an issue.

OBIEE was installed with our partner. We're a hosted environment so we have an important staff there, including DBA's and staff like that, that will do our installing. I don't think we ran into any issues with getting it configured and up and running. Again, it seems to be fairly stable and we've got a pretty good DI staff that can work with it. It's probably in between straightforward and complex.

Look at where you're going for your reporting. Are you getting your reports today? Are they going to grow? Are you going to add into it? What are you looking to achieve with reporting? Those are questions that I would ask, so think about them before choosing a solution.

Our customer is an enterprise that has over 120 entities. It used to take a lot of time (around 15 days) to collect data and generate reports for their performance. After OBIEE was implemented and some processes improved, our customer is now able to review their monthly performance with a clearly analyzed pattern within 5 days.

I've been using it for three years. I started with OBIEE 11g (11.1.1.5), and upgraded it to 11.1.1.6 and 11.1.1.7 afterward.

We did not encounter any serious issues when we deployed the tool.

OBIEE is a little unstable in our environment. The server/service has to reboot/restart every couple days, otherwise, users will see errors when they access reports.

I am not going to rate Oracle's support high. It took too many times to collect logs and screen shots, and talk to a support guy. And they still have to go back to R&D once they confirm the issue was product related. It took another loop to communicate with R&D guys, and there almost 70% of thje issues were treated as a "Fix in the Roadmap," which means we won't get a hotfix. We suffer quite a lot when we have to tell our customers that some bugs will not be fixed until it's in the roadmap, and even then, a few years later.

Our customer choose OBIEE as their reporting tool before we assisted them with implementation. I used TIBCO Spotfire after this project, and it's quite a different product. It seems business users will use a so called "analytic tools" such as Spotfire more often than "BI tools" like OBIEE or BO. Since their requirements become much more dynamic, they may not even know what they are looking for, or what questions they suppose to answer. BI tools needs too much IT effort for ETL and modeling to enable users to read the report. However, some questions cannot wait that long, and users need to know the answer as quickly as possible. On the other hand, analytic tools just need raw data and users can those data to generate reports whatever they need for whatever questions/purposes (if they know what those data means well and have some basic knowledge with database).

The setup is quite straightforward, unless you need to deploy with a cluster. Components in a model/presentation layer can do it simply by dragging and dropping, if all the calculations are done in the database. Although, some settings,such as "Write Back", is not that easy. They need to be configured, but you have no idea where to configure it unless you go through the documentation, and even some blogs perhaps.

I helped implement it as part of the vendor-side team.

Just keep the model as simple as possible, it'll make works much easier afterward.

The primary use case of this solution is RPD.

I think having the conformed structures makes it a lot easier for end users and pulling reports together.

I find the most valuable feature of the solution is the RPD, so the BI Server component, and the building conformed structures across unconformed data.

I think there is a lot of room for improvement. This solution is weak in the data science perspective. I have past data science experience. And, I find that there is a lot of room for improvement in terms of incorporating more advanced statistical modeling into the product. 

I come from a data science background. I find that there is a lot of room for improvement to incorporate more advanced statistical modeling into the product.

I have not been using it long enough to pass judgment on the stability of the product.

I think to spread this across an enterprise will be a significant investment. Be prepared to spend a lot of time and money.

I have past experience with QlikView, Tableau and Sisense.

The primary use case is for our various financial products. One is a trading platform called MarkitSERV. All the world-leading financial institutes are on-boarded to that client. They use the platform for trading. On the backend, we have the data warehouse of that trading platform, which helps produce quick analyses of the trading data and prepare reports on demand. For that purpose, we are using the OBIEE. We have defined a lot of trends in OBIEE so you can compare year-on-year and month-on-month data. We have various ways you can measure your numbers.

Performance is just okay. It doesn't have in-memory data. For every new analysis we prepare, it will go to the database and query the SQL. That takes a long time. That is the main challenge we are facing. People nowadays are very demanding. They want their analysis to come up very quickly, at the click of a button.

The most valuable feature of Oracle OBIEE, for me, would be the Web Catalog. From a development perspective, I do not need any client or any software to be installed on my laptop or desktop. Everything is browser-based, so I just open the browser and start development.

Similarly, for the end-user, it provides self-analytics services where the end user can drag and drop various fields, facts, and dimensions and prepare their reports. They can have them in the form of charts, etc. Then they can save them in the Web Catalog.

I have not seen this Web Catalog in any other tool. Web Catalog is kind of like Windows Explorer, where you can define your own folder and whatever analysis you are doing and you can save the analysis for future reference. 

One feature I would definitely like to see is the ability to provide the in-memory data. Oracle might have some plugins but, as of now, that feature isn't available out-of-the-box. You might have to purchase that feature. This is the feature that is most lacking, which we would like to have in the next release.

Also, the overall architecture. Currently, it comes in an Oracle suite. We want to have it come as a separate product and which is very easy to install, migrate, deploy etc.

I wouldn't say it's that stable. We are using it in production and we used to have one failure per month. When we're not able to figure out the reason, we just restart the services to sort it out. That might be an environmental issue, we're not sure. It could also be a tool issue. When we approached Oracle support, we could not find out exactly what caused the instability.

It's fairly scalable. It doesn't have its own engine, so everything depends on how much data your database can process.

We have used technical support. We didn't find it very useful. The responses are very slow. As the tool is very, very complex, there are a lot of scenarios that we need to go through with them. Most of the time we are not able to simulate the issues with them. Depending on the application-side logs that we provide to support, they start their investigation, but most of the time it is not that useful.

I wasn not involved in the initial setup. When I joined the organization, it was already set up. I would say that we're using only 20 to 25 percent of the features of OBI.

Setup and migration are very complex. Technically, Oracle accessory is extremely complex. These days, the industry demands a kind of Excel analysis, which is very easy to install, set up, and it's very developer-friendly as well as end-user friendly. OBIEE lacks all those features. We had to migrate from 11g to 12c and it took around six months because of the extreme complexity of the tool.

We are planning to move away from Oracle OBIEE, and to move to another tool that has in-memory data processing capabilities. Oracle doesn't provide that capability very easily, so we have performance challenges, etc. We are exploring Tableau and QlikView. They provide in-memory calculations and in-memory processing, which results in very fast throughput so that the data updates into the dashboard.

In terms of choosing a vendor, the most important criteria for me is the ability to create near real-time analysis, which OBIEE is lacking at the moment. Another is very good performance, which means it should have its own engine to process the data or even to do some small ETL operations on the data. In addition, it's the simplicity to develop and architect the solution.

All the drawbacks which I mentioned above, I would like to have all of those resolved in OBIEE. First of all, its installation, configuration, and setup should be very easy. It comes with its own application server and that creates a lot of conflict files on the server side. You have to be very careful while configuring all those files.

Technical support is another issue, where we generally do not get adequate support. And on Google, there is a lack of good material for OBIEE 12c. If you compare it with other tools like Tableau and QlikView, they have excellent community sites where you post your question and you'll immediately get a reply.

The client required the ability to produce the same reports that they currently produce in Excel (replicating as close as possible to the format as the users were used to this), but distributed via a dashboard/mobile front-end rather than relying on emailing Excel files.

For them, the most important features were the ability to build complex and highly formatted analytic reports, to publish them on dashboards, to build mobile apps to allow access whilst out and about, but still be able to email reports out for those users who still wanted them that way. Including the report in the body of the email to avoid having to open attachments was also desired.

The ability to directly access data in their warehouse rather than downloading into an Excel file was also an important consideration. This is a small company, but growing fast and the amount of data was becoming unwieldy in Excel and would just get worse.

These reports are used all day by the company’s sales representatives as they travel between regional outlets, customers and suppliers. Having access to this data quickly via a tablet/mobile phone meant spending less time at a desk and could ensure that they have up-to-date information during their meetings. It has therefore greatly increased the time the sales reps can spend out on the road and positively impacted on the deals they are making. Their managers can also monitor during the day what the sales reps are up to and provide better guidance.

The IT developers for this client have struggled in two areas, setting up the repository and fine tuning the report formatting.

The repository in OBIEE provides a huge capability for bringing in table structures from a database, linking them together, mapping hierarchies, adding custom calculations and so on. However, to do much of the complex mapping they needed is very difficult without considerable experience. There is very little within the repository administration tool to guide you on how to achieve complex tasks and the documentation is quite brief. Improvements in this area would certainly help.

For the reports, the requirement was to replicate highly formatted reports in Excel and despite the cell-level formatting in Excel that obviously cannot be replicated within a reporting tool, we’ve gotten extremely close. However, as with the repository, experience has been key – the analytic report-building screen provides a wide range of functionality, but without someone with experience on hand to provide ‘tricks of the trade’, they would have struggled. Simplifying the interface to provide easier access to all of the functions would help greatly here.

For this client, it was their first foray into professional business intelligence reporting products. Until now, they’ve merely been using Excel for all of their reporting needs.

There were some issues in the first few weeks with the services crashing with little or no meaningful messages in the log files, but these seemed to clear up and no issues have been encountered since. They have been put down to the developers being a little over enthusiastic with what they were trying as they were learning the product. Now they know what they are doing, all is ok.

This has not been an issue so far for this client, they are still in the early days of building their BI estate.

No technical support has been requested so far from the vendor.

Excel was the original solution. As the company was young and the quantity of data still relatively small, Excel was the obvious, easy and cheap choice. The growth of the company has now reached the point where the use of Excel is becoming problematic – the quantity of data needed to be downloaded, the size of the Excel file, maintenance of the VBA/Macro code in the sheets and access to the files by users out on the road were all issues that needed to be addressed.

The initial installation and configuration was relatively straightforward. Installing the software is a little complex for someone doing it for the first time; there are quite a few steps, but it was just a case of slowly working through them.

The big boon for this client was that they already had a data warehouse containing the data required for reporting; it was currently being assembled by an overnight process and then manually downloaded into Excel. OBIEE was able to directly connect to this warehouse and access the table/view objects within. The client was quickly able to start producing some of the simpler reports.

For this client, the licensing requirements where initially quite simple; they knew how many users they intended to provide the reports to, so they only purchased the licenses for them. The long-term intention is to incorporate more reports and, hence, service more users within the company, but they know they can extend the licenses as and when required. In this scenario the advice is quite simple – start small and grow as you need to; there is no point buying enterprise-wide licenses until you need to.

The client was already an Oracle database user, so Oracle’s Business Intelligence product was the obvious first port of call when looking for a better reporting solution. I do not know how seriously they looked at other products.

For a company just starting out in the world of BI reporting, this product, along with most other BI reporting products, is an expensive tool to buy, if you just want to play around and see what BI can do. It contains so many features, you can easily get caught up trying them all out and never actually deliver anything meaningful.

To get the most out of the product, you need to know what it is you are trying to achieve – what reports you want to produce, where the data comes from, how you want to provide those reports to the users. You can then quickly start to deliver benefit from the product just using the features you actually need. Later on, you can start looking at additional features to see what else it can do for you.

The product has a huge range of features as well as script/API interfaces to plug in others. However, many of the features are a little too complex to simply use ‘out of the box’. It is a product that Oracle are constantly developing and each release is better than the last, but each release also adds more features that make it even more complex. It is a comprehensive reporting solution, not a simple reporting solution!

Some of the most outstanding features of OBIEE is both its scalability and dependability. OBIEE is worthy of its ‘Enterprise’ moniker as it can handle any amount of end-to-end data thrown at it. But these strengths can only be realized if the business and engineering teams work diligently to define not only the various levels of data aggregation, but also clearly define the meta-data in order to establish efficient drill-down hierarchies and relationships. 

With proper table design plus good data governance, OBIEE can serve as the central delivery mechanism that brings insight into the business layer of almost any size of company.

With a wide array of internal customers, OBIEE has helped us provide a many-to-one Business Intelligence relationship. By transforming the company’s performance data into various dashboard perspectives, each information consumer can select a customized dashboard view. The result is to empower the business user to ‘self-serve’ some of their regular and most important reporting needs. 

This reduces the amount of noisy communication between the business and OBIEE power users within the company. It increases the speed of analysis, and it provides an unwavering consistency across the dashboards and downloaded reports.

In today’s business intelligence environment, nimbleness and flexibility are valued on par with scalability and dependability. Historically, Excel was perfectly aligned with the former two while enterprise solutions held firmly to the latter two. It was the business analyst’s conundrum to work seamlessly between the micro- and macro-solutions. Now, BI entrants into the market are challenging that paradigm, providing tools that span all four characteristics and this is where OBIEE is looking somewhat dated. 

OBIEE requires a lot of metadata customization that can only be achieved by individuals with very specific skill sets. This includes Oracle developers, web developers (including XML), Siebel, and more. These skill sets may even reside in different departments yet the business user depends on each to ensure that their KPI dashboard is updated with the latest segmentations and that the drill-down reports open up quickly. These challenges may ease somewhat with the introduction of Oracle's Visual Analyzer, however it is too young a product to tell how fast it will move up the development curve.

As the BI space continues to evolve, many business analysts are focusing more on complementary solutions that, although they may not be as enterprise-worthy in scope, are extremely flexible, easy to customize, and can get the analyst the needed insight without having to overcome some of the development hurdles in OBIEE.

OBIEE is as powerful as the Oracle backbone upon which it runs, but it will not serve the business as effectively as it could if there is not a commitment to align engineering resources with the needs of the business. With the right skill sets and a defined corporate data governance strategy, OBIEE can be a powerful BI engine for almost any company.

Over the past few years, OBIEE has become less important for us in the analytics group. In order to lead a proactive data discovery group, OBIEE just doesn’t provide enough flexibility. We are constantly blending various data sources together, creating on-the-fly segmentations, and iterating through potential dashboards. With OBIEE in a production environment, the business users cannot wait for the slowly moving development pipeline, QA, and scheduled code releases. As a result, we develop our own datasets and analysis on a production copy of the DW. We do our own QA and will road test the production style report while the production version works its way into the next production release. 

I think OBIEE’s sweet spot is a 20,000+ person financial services firm with a BI group divided into experts in Oracle, Java, and XML. The dev group is represented by business analyst/liaisons with the business units. If a manager needs a new dashboard, they meet with the liaison, specify what they need. The analyst takes it back to the BI group and then the developers build it out over the next month. 

This is where a BI tool like Tableau has helped us fill this gap. Over the last two years, Tableau is now becoming the de facto analysis/visualization tool for us.