Oracle OBIEE Reviews

The most valuable features of OBIEE for me are definitely the graphs and reporting that it provides. The data it displays look really great and they're easily customized.

Sales people have a different kind of mindset and they want to see different varieties of reports. If somebody wants to see data by store, or by store in a particular ad, and their district managers want to see something with the region specifically, OBIEE can provide them that detailed data.  Also, through BI Answers, we can get data that's time-specific, holiday-specific, weekday-specific, or weekend-specific. We can easily configure and manage pretty much any metric we want across our retail business.

Some of the main disadvantages of Oracle would be they don't give the whole privilege for the end user to customize the way they want. Some things can only be done by an admin or a business analyst, and then really only someone familiar with OBIEE would be able to do it. But unlike other product, like Domo or Tableau, irrespective of the database, you can write run-time reports by an end user. The interface is going to take care of it and, depending on the variables that they change, they would get the data. Data remains the same, but you are giving more to the end user to handle.

We have no issues with deployment.

We've had some stability pain points with OBIEE. Operationally it's fine, but cloning causes big stability problems.

It has a Repository Creation Utility that has its own schema. It's on a production database so when you clone them, they're going to come with the same schemas where you won't be able to run those well for the test database. You'll need to export or import so that before the clone you drop and recreate the whole BI suite.

Setting it up or even upgrading it is definitely not for someone within the first year of their career. You really need to to be experienced and to know a lot of things, such as integration, how it behaves, its parts, and a million other things before you start to get the hang of it.

We implemented it ourselves with our in-house team.

I did a demo with Domo, but those guys were right behind me for more than a year. We didn't have any plans with Tableau, but it may be a solution that we could eventually migrate to.

I wouldn't recommend it as there are many other product out there, as long as your database is covered with RDBMS or other warehousing database. If you're freshly implementing, there is no reason in going with a 90's-style solution in 2016.

We use it as our primary system for passing information and data through Oracle E-Business Suite, and for pulling in data from other platforms. In this way, it's our information and data hub.

Interacting with other non-Oracle applications and sources is a little difficult right now. It needs to be easier, such as interactions with cloud resources.

I've used it probably for up to 10 years now.

We've had no issues with deployment other than the interactions between it and non-Oracle apps.

We run an older version right now, so we haven't made any changes to it. It's stable in its current state, and we haven't had any issues with instability.

There have been times where we probably could use an initial processing power, but we're constrained around the licensing that we're in.

We just dropped our maintenance with Oracle last year and have gone to a third-party service provider. It was less than half of the cost, and we didn't see the value of the money that we were spending at the time with Oracle.

The initial setup is fairly straightforward, but I wasn't around when the implementation was done.

The re-licensing is a large cost proposition so we may be looking at alternatives, I think, in the next couple of years.

We are using it just because we have other tools we've retired. I'm not really excited about it nor am I ready to kick it to the curb.

Basically reporting, and we have a couple of modules which we bought. OBIEE, which is used financial procurement and reporting purposes.

I think in the older version, 11g versus 12c, Oracle has thought through so many things. I think the installation is a lot simpler. I think they have improved a lot. If you asked about the older one, maybe I would have given you many reasons, but not with the new one.

It's close to four years now, or even more, maybe close to five years.

It is a stable product and I think we are on the latest and greatest. We are in the process of upgrading to 12c, and any product you take, it will have some issues, so it's not something we run into a lot of issues with.

I think the amount of reporting, the amount of users that we have, I think we are pretty solid and how we scaled it I think the end user is very happy.

When you open up SR Oracle has a list of things which they ask for. Being an end customer, when we open an SR, we give as much as information as we want and again the support person comes into the picture, and without reading what we have put through, they just has the same questions over and over. What version, what product, all that kind of things, which is not at all fair.

We used to have Interactive Reporting which is an Oracle product. Hyperion Interactive Reporting.

I would say if you want to make your financial reporting simpler and easier, and you can put it towards the end user, and the way you can control the things, and show the graphical use, or ease of use, and functionality, it's very simple for the financial user or end users. I think it's very good product.

Maybe not all products are up to the speed or like any product you take, there is space to improve. I think for our company, the way we use it, we are very happy with it and the end customer is very happy with it.

Obviously the most valuable feature is the data, both in the way it's presented visually with graphs and just the accessibility to that data.

It empowers users to perform ad hoc analyses themselves rather than having to go to IT or somewhere else. That makes it much more efficient for our users to do their jobs because they have access to data analysis in front of them instead of having to find that information elsewhere.

It would be beneficial to allow the user to further personalize their own page a little bit more instead of just being presented with data. I think the user interface still needs more fine-tuning. It needs to be easier to create user reports. People who first use it don't know where to get what they need as there are so many tabs and so many things you can do. It would be nice for it to be made more intuitive.

We've had no issues deploying it.

I would say it's pretty stable. We've had no issues with instability.

It has scaled well for our needs.

We've opened tickets and the IT side handles that. I'm more on the functional side. We send the request to IT and they open up the tickets, but the turnaround time is a little long.

I wasn't involved in the initial setup, thought I haven't heard that it was particularly difficult or complex.

We implemented it with our in-house team.

We didn't evaluate other options because we did a pilot program ten years ago and we already had the licenses and infrastructure in place for it.

It's a valuable tool and it really benefits our work. The main thing is to let your users know how valuable it is so it's worth their effort to learn how to use the tool.

The most valuable feature of OBIEE, for me, is the speed with which we can get a solution to the customer. It takes a lot of work upfront on our side, but once that's done, it's a matter of clicking here, there, and we've pretty much got a solution for them.

Users can create their own ad hoc analyses and reports, so that's definitely a big plus. Also, another way its improved our functioning is the speed that it gives us to provide solutions to the customer. That's important to our company so that we can meet contract requirements, particularly ones that are time sensitive.

When we went from version 10 to 11, Oracle changed some of the functionality for us, and ultimately for those few customers that use it. For example, with filters, it was like, "Okay, give me a filter. I want this and I want this." Now it's more like five or six clicks to do the same thing to get to where you're actually defining what the filter is going to do. In my opinion, we lost a little functionality there. We lost some of the streamlining, efficiency, and speed.

We've had some issues with one of the subject areas, in particular, where somehow, somewhere this analysis was built off of this subject area. That subject area got removed. The result was that this analysis still runs properly as it should, but we can't make any changes to it because it says I have an invalid subject area. You can create a new one with the same name, but the internal workings of OBIEE, it knows that it didn't come from here. I've asked several of the experts, and even Oracle, the product manager, and the technical side, they're like, "Wow, really?" That's an unsolved problem.

We deployed it just fine, and implemented it just fine, as everything was squeaky clean, except for what we did wrong, which was essentially user error.

It's rock solid. We've had absolutely no issues with instability.

We can add users without issues. We're able to scale just fine.

Setting up all the metadata and the RPD takes a lot of work. Then, of course, it migrates through the physical layer, the business model layer, and the presentation layer. At that point, we can turn OBIEE loose to some of our customers. Some of them are quite skilled, and they like the hands-on. Some of them are not.

We had an Oracle consultant come in to help us. The DBAs actually installed OBIEE and set up the RPD. I'm not sure that, even now, that was set up optimally. We learned a lot as we went along. It's like, "Now we're this far down the road, and it sure would have been nice to know this back here," because I found that going back and trying to really change some of the structure is difficult.

Every Oracle product is expensive, so OBIEE was expensive as well.

Depending on the skill level of the people who are actually going to be the BI administrators and developers, I would suggest a consultant, someone who is well-versed and knows the in's and out's, to help implement OBIEE. As I said, we had an Oracle consultant. When he came in, one of the first things we did was sent him to some training for OBIEE. I'm not sure how that came about, but it seemed a little strange to me. The way I look at it, when you hire a consultant to come in and help you, I'm expecting that person to have the background and the knowledge.

The guy did a great job, but there was the training thing that just didn't register. He was a great help to those of us who now develop the solutions for the customer. It was good experience having him there. It was a collaborative effort. I was sitting over his shoulder until I couldn't take it anymore. I said, "No, I have to touch it." You've got to just jump in there and do it. That foundation, seeing some of the stuff he did, and the way he went about it, I think, is invaluable.

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.

The most valuable feature for us is the flexibility for somebody who's not in IT to be able to create a report. They can change fields around or add or remove things, customize the information that we get.

In our company, we've got finance, HR, operations, and then CRM, which is what I represent, all using it. They're all able to use BI in a non-technical way.

The biggest organizational benefit is having data or information at your fingertips for all the different subject areas that we cover. I think it makes the data readily available and easily available for the people that need it, when they need it. That's really important.

I feel like sometimes it can be slow. It doesn't have the flexibility as some other BI tools like Tableau. There are other ones out there that have more flexibility. Its main area of weakness are the graphical aspects that it doesn't have.

We just implemented it last year.

It took a long time to implement, over half a year.

It's a stable product. We haven't really had issues with any instability.

We have a lot of users, I think close to 300 users in our company. QA, engineering, supply chain, and other departments use OBIEE as well.

It was complex because we had views built for discovery and we had to transfer the reports and views over to OBIEE. We had a third-party contractor that was helping us do that. It just took a long time.

We implemented with the help of a third-party contractor.

Compared to Tableau, I think it's mostly useful for more tabular reports where we are just exporting transactions and things like that. Typically, we will take that information and pull it into Excel to create a chart or graph, and then throw it into a presentation. It's good for that. It's good for getting the data dumps that you need, I mean, at least for us because it replaced our discovery tool.

Get help from somebody who knows what they're doing.

The most valuable feature for us is the ability for endusers and superusers to do some deeper dives without IT intervention. It allows our users to be more responsible and to manage their data a little more responsibly without IT interference.

OBIEE is essentially a queue-based data mining tool that allows all aspects of the business, from finance to manufacturing, to do a little more data analysis on our 24/7 operational data.

I wish there was a way you could implement real-time data easier rather than through the ETL process. I know that Oracle's got their own ETL process that does have that feature, though.

We've been using it for a couple years now.

We've had no issues with deployment.

I'd say it's pretty stable. With anything that's web-based, there are some issues with browsers, but nothing huge that's obvious.

But with some of the ETL processes, such as bringing in new pieces of data like cost categories, anything from the EBS Suite into the cube, you can get issues.

We don't have that many functional users using it, so scaling has not been a true issue for us.

We use a third-party hosting solution. A lot of the setup in technical maintenance is all handled through them. I know we've logged several SR's for several OBIEE issues.

We set it up with the stock Oracle solution because we purchased a lot of the stock reporting cubes. We've slowly added our own custom ETL processes to pull data as needed. Since we're a 24/7 manufacturing company, there's a lot of data that wasn't there that we've had to slowly bring in. We're still fighting through a lot of it, and since it's not a priority service, it's kind of a secondary function. There's gain on it, but it's definitely lower on our priority list than a lot of the day-to-day, 24/7 operations.

Make sure they understand the true use of it. Originally, we were shown the dashboard, all the great features that come with OBIEE and OBIA. But we weren't truly told what it takes to maintain it, what it takes to get valuable data for our company out of it. It's a lot more work than Oracle led us to believe at first.