What needs improvement with Oracle Hyperion?

Integrating Oracle Hyperion, a multidimensional database, with relational databases poses challenges due to the differing database structures.

Evidently, we have a hypothesis. That's why we are building our own product. So, I wouldn't want to dive into the improvements needed in the solution at the moment. Since the UI is outdated, Oracle Hyperion has room for improvement in the area of its UI.

The analytics could be improved. I think we need the cloud version. If I want to get information from a company, I need to send an email and they give me information from SAP, but not Hyperion. When I want something to be improved, I work with our finance support team and they make the changes.

One of the problems we have had with technical support when we are on a project, is we need technical support from senior-level technicians instead of being assigned, junior-level technicians. What I like is to have everything on one platform and not in different modules like Oracle Hyperion. For example, segregated planning and HFM consolidation. OneStream has everything together on one platform. There is less data movement, and with Oracle Hyperion, you have to move data between modules. I think that would be an improvement if they can merge those products. But it has been like that for so long I do not know if Oracle Hyperion has the appetite to do that.

Configuration is a little complex, it's not very easy. The solution is integrated with Essbase and there are not many users of the Essbase database. If they can provide different modules for each subject area, like supply chain, for inventory forecasting or for order management forecasting, it would make each subject area easier to manage.

From going from level one to four, they've done a lot with driving the user to control what they're doing versus having a dependency on an administrator to drive data movement. Again, it's all predicated on how your planners want to use the application. You can give them all the tools, but if they don't engage in that type of planning, then you can have a Cadillac system. If they're only going to use 10% of it, you're not going to drive that value. All the planning systems out there are great. It doesn't matter which company you use. They're all great. I've seen demonstrations on a number of them, but it all boils down to the culture within the organization itself to use that functionality, understand it, and help drive it. I've had Oracle salespeople do demonstrations, and it looked really good. We get it on board, and everybody still sticks to their Excel spreadsheets because companies are a lot more complex than what you could deliver on the planning system. So, there should be more education on the capabilities, and there should be more understanding of organizations in terms of the way they access the data in order to plan. Because my organization is complex and there are different data streams, they don't bolt into Hyperion very well. You still have to extract the information and load it in, which is really difficult, especially if you have older systems or if you're going from a mainframe system for some of that information because there is no application out there now that's bolting on the mainframe systems.

Their documentation could be a little bit more descriptive at places. They don't really do a lot of How-Tos because that gets pushed through to the consulting groups. There have been some books. There is a real good one out there about how to look smarter than you are with Hyperion Planning that some people at a company called ArganoInterRel wrote. Those things do exist, but that's not in their documentation. It's basically like they'll say, "This is the field. This is what it's used for," but they don't tell you how to particularly use it in your case environment.

I have a problem with Hyperion when I need to log some changes in the budget. It's hard to know who made which changes in the budget. Also, since I am using the old version, I'm having some issues with the compatibility between the software and the browser. I think Oracle should package Hyperion with a browser so I won't have these problems.

Oracle Hyperion's scalability could be improved.

When you compare it with ERP, we want so many enhancements in that particular product. Since we are the Oracle hub, we know how the Oracle forms work. All the fields are dependent on the previous field example. If I want to select a product, I can select the channel, and automatically, the products button to those channels will be filtered. That sort of filtration, we cannot apply in Hyperion. We cannot have hierarchy-level filtrations over there. The initial setup can be complex. There's something known as a data block that Hyperion generates for each and every transaction. Sometimes it does not generate and we need to identify those issues and fix them manually. That is the only debugging process for me.

The analytical side of the product could be better. Improvements should be made when it comes to integration with other products. The reporting capabilities need to be improved.

We are still having some issues with the ASO Cube. It can take a long time to clear the data in the ASO Cube compared to BSO data-clearing operations. We don't have a specific calculation in the ASO, and we only have these aggregate options on the ASO side. If we need calculations, we have to calculate them in the BSO and pass the data to the ASO Cube for the reporting. That's one of the drawbacks. Oracle could also improve on the data logging side as well.

Definitely, there is a scope for improvement. For example, Oracle continuously releases patches. Every quarter they release patches for this solution. Users have indicated that they do not want the updates as frequently. Patches should be done once a year or twice a year, not quarterly. From a technical perspective, the technical support could be improved and the price could be reduced.

The solution has too many tools. The integration should be addressed. I found the initial setup to be complex.

The level of complexity of the implementation is always a challenge. They're for larger enterprises. They're just complex implementations and obviously we implement them, so we know the steps that have to be done. There could be better integration tools.

Its GUI could use some refinement. I think it's easy to use, but it's hard to say because we are very familiar with this product and have been using it for many years. For a new user, this product should be updated to work better with the environments of new operating systems. Modernizing the user interface is something I would suggest. But, in terms of overall functionality, I have no complaints. At the same time, I don't know if I'm objective after having used it for so long. I don't know if a new user would have the same opinion as I do.

From a business intelligence (BI) angle, it's only a small part of what Hyperion does. The solution is about to cease to exist, so it doesn't really matter if they add anything to it. It's at end-of-life. Oracle's strategy is to put those clients that are using Hyperion at the moment onto the cloud, through a new software. Companies will be able to have the cloud software but have the option of on-premise. Due to the rich functionality and the breadth of the functionality that it provides, the technical architecture of the solution is quite complex. That is maybe one of the reasons why that Hyperion or Oracle is taking some of the products that have become too complex in the architecture and have decided to rewrite it and put it in the cloud.

The learning curve is pretty steep. For people coming from a relational or star database background, users configuring Essbase need to learn a new way of manipulating the data.

Oracle EPM Cloud solutions have simplified the security model. Nevertheless, it would be better having a more differentiated security model.