Oracle Hyperion Reviews

Our primary use case for Oracle Hyperion was planning and budgeting.

My role in the company is on the support side.

This is a customizable product. Our implementation was designed to fit our needs.

The user interface is in need of improvement. The forms should be more user-friendly.

Initially, we had some integration issues. However, these were solved after we submitted a couple of service requests.

We were using Hyperion for approximately eight years.

As of last week, we no longer use the original Oracle Hyperion. We have moved to the cloud version of the product.

Overall, the stability was okay. We did not have to raise many issues with support.

Scalability-wise, Oracle Hyperion is okay.

We did not have to raise many issues with support because we were only using the planning and budgeting features. We did initially have some integration issues and these were solved after we set up a couple of service requests.

Overall, the support is okay.

We were using Oracle Hyperion but have transitioned to the Oracle EPM Planning Cloud.

We switched because the support was ending and we decided to move to the latest version.

The deployment was done by a third-party implementation provider.

As of now, the Oracle Hyperion product is out of support, so I would not recommend it to anyone. Anybody that has it will not be supported by Oracle.

For anybody who is still planning to implement this product, my advice is to consider their needs during the initial implementation phase. The one that we were using was designed to fit our needs and anybody who plans to use this product should identify what forms and screens they will need. That is configurable at the beginning.

I would rate this solution a seven out of ten.

We're using the product for our OPEX planning and CapEx planning. We use it for the budget cycle. 

The most valuable aspect is that the time to market is very fast. You're able to finish your budgeting cycle in a very quick and fast way with a more detailed analysis.

The solution is reliable.

The scalability is good.

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.

I've been using the solution for almost seven to eight years.

The solution is very stable. There aren't glitches. it's reliable. it doesn't crash or freeze. 

A company can scale the product as needed. It's not a problem.

We have around 20 to 25 people using the solution.

Once the budgeting process is finished, it is being used by the quality finance team only throughout the year, however, the main key users will be working in the budgeting cycle for one month or two months only.

In terms of technical support, we are providing it directly as an IT division.

The implementation process is a little bit complex. Anything we need to customize as for the business requirement can get difficult. 

We do have our own team that maintains the solution as necessary.

The solution was implemented by a partner.

I don't have any details about the licensing. 

We are customers and end-users.

I'm not sure which version of the solution we're using. It's the latest version. About six months back, they upgraded to the latest version.

If any company would like to implement this product they should first have the internal resources with the skill sets ready to be developed for this product.

Overall, I would rate the solution at an eight out of ten. It does have some small flaws here and there. 

Hyperion is one of the best tools in the world. We can do planning and forecasting and store large amounts of data. We can draw a large amount of data and multiple combinations.

We can integrate with any system and pull data from SAP or SQL Server. We can also design our own role files to establish how we pull the file data and store it in our database. 

Hyperion provides excellent security. We can control all the users with filters and access levels and set permissions for who can control the system or input and process data. 

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. 

I've been working with Hyperion technologies for the last nine years, so I have experience in SMPs, planning, and Smart View. I also have quite a bit of admin knowledge in the form of SQL. I can do installations and patterns. I have more than four years of development knowledge and then three-plus years of experience providing support for Hyperion. 

Hyperion is stable.

Oracle support is quite good. When we have any questions about the product, we can immediately write the service request and contact them. They will respond in a day and fix the issue based on the priority. 

I'm using Hyperion for planning, but I'm not currently using it for financial reporting. But OneStream also has similar functionality now.

There is a lot of planning that goes into developing our Hyperion application. We need to create a planning application and set up everything. Then we develop the forms, create the cubes, and make smart lists. Everything we use is customized. 

I rate Oracle Hyperion eight out of 10. My advice to prospective Hyperion users is to focus on your business requirements. You need to consider what your business is looking for and how you will perform the planning and budgeting process. You also need to think about your data, including what level of data you're storing, the size, the frequency, and the architecture. 

We still need to learn many things about the cloud part. Every APM is moving into the cloud now. There are other aspects, like integration services, ODA, etc. We are facing many challenges in development and support. We are all still learning the Oracle products, and they're coming out with new features annually. 

We use the solution for financial reporting and planning.

The solution has too many tools. 

The integration should be addressed. 

I found the initial setup to be complex. 

I have been using Oracle Hyperion for nine years.

The stability is fine and quite user friendly.

The scalability is fine. 

The initial setup was complex. 

I do not have any specific advice for others who are considering implementing this tool. 

I rate Oracle Hyperion as a nine out of ten. 

My primary use case of this solution is as a full EPM shop, with HFM ,planning and FDMEE reports, as well as all the features available under the EPM umbrella.

There is room for improvement in the on-premises software, which doesn't have as many features as the cloud version, such as the EPBS features or the ability to edit metadata for HFM. There are also a number of bugs and issues present in the product.

This solution's stability is a little problematic - every time we go to a new version, there are bugs and issues, and we don't always get a quick solution or support from Oracle. 

Scalability is one of this solution's big plus points.

The support could be improved as service requests can sometimes take a very long time to be dealt with - we have some SRs that are a year old with no solution. In addition, the quality of the answers from the support team is not always good - sometimes we've had scenarios where we've had to ask the same question repeatedly without getting a useful answer.

Prior to Hyperion, we used Oracle OFA. We moved over to Hyperion after OFA was decommissioned.

The complexity of the setup depends on the application being worked on - some are quite complicated, others are easier.

I would rate our ROI as three out of five.

As long as you are designing the product correctly in the current matter, it should work well. How you design the product should be the most important element of your implementation. The design of the applications is variable - some are well-designed, some are not. Overall, I would rate this solution as six out of ten.

Centralization of the budgeting process. Our company was using Excel spreadsheets to capture all the managers' spreadsheets. They kept being changed by the managers and were never actually frozen in time. Very hard for top management to freeze the budgets.

Reduced budgeting process from six to eight months, to three months. Locking the budget process for the managers permitted us to control the data. No one was doubtful about which versions of the budgets they were working on.

• Flexibility
• Quick to add enhancements and adapt the tool to business requirements
• Little involvement from the IT department

Everyone was looking at the same numbers. As data was entered during the budget process from lower management, upper management had the live consolidated budgets.

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.

Three to five years.

Our primary use is for Enterprise Performance Management (in most cases), planning and budgeting, and as a reporting/allocation tool.

We provide customized solutions for finance offices in any industry.

Oracle has an integrated solution for Enterprise Performance Management (EPM) and Hyperion. It keeps the two platforms opened up to each other.

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

I have worked for more than seven years with Oracle EPM and Hyperion.

Hyperion has made our budgeting process and forecast analysis easy and robust, and it is a reliable tool. Primarily, we are using Hyperion for our budgeting analysis and to complete our whole budget cycle within the EPM application. We take the HR data from our legacy system, which is Cyborg, and then load it into Hyperion. We have a very specific type of planning application (PSPB) which is meant for public-sector planning and budgeting for governments, and it has most of the built-in, out-of-the-box calculations for us that we used to do in traditional Excel before and there was always a chance of human error. Security was an issue because we did a lot of emailing back and forth with the sensitive HR data.

It secures our sensitive data because it's security-enabled and is reliable with it's back-ups, migrations and restoration methodology. We can do LCM exports and import into target servers and applications. You can back up everything. Security tool is also integrated into the application. I'm happy with the security, how it is handled, and how users can integrate with their Active Directory. You don't have to go out of directory to get user names and passwords.

We're evolving with Hyperion as we move along in our yearly cycles. We have come to the point where the end-users are trained well on it. We don't have to go back and forth with emails, sending Excel files, anymore. We used to have big Excel files that you might not even be able to send through emails. Sometimes you have to put them in some common shared drive and then other users have to get it and then approve it and then send it back. That was not only insecure but it was also a hassle.

With Hyperion, all the design is done in one database, which is the central repository for all users. We have around 30 departments and they have different cost centers, and 150+ users are using the application. They're all managed by a team of around 10 budget analysts in our budget department, so the big advantage is it's all in one central repository for them. We have security-enabled for all the cost centers, and departments can log into it and they only see what they're supposed to see based on their access and based on what department they belong to.

With a big entity like government sectors, we have around 3700 employees. Like I said, we have a lot of users for this application and Hyperion has made it easier to access the data, process it, and perform data integration. Data consolidation is easier and running the reports is very easy. Hyperion has some good built-in reports and we are building our budget book from it, which is a big achievement for us.

We used to build a budget book, which is this thick book you have to print, and so putting it together was a huge challenge because you have to combine all the Excel reports with all the word narratives, format it, and then publish it for the public. Now, it's all being done using Hyperion. We're entering data into Hyperion and then pulling the reports out of there and combining the smart view add-on in Excel. Users can connect to the databases in Hyperion and then using Excel, they can pull the grids/reports, build the budget book, and then publish it.

It's easy, robust, reliable, more secure, and has built-in calculations which avoids human errors.

Not many people are aware of the new feature called Decision Package. We have a very specific tool in Hyperion called Public Sector Planning and Budgeting. It's for government entities, and it's a part of Decision Package. It's used for government entities to budget their positions, their allocations to different departments, their expenses and to create new budget requests, and to create new positions and do their analysis on it. 

The Decision Package is a new feature within this application, and they released it around 2 or 3 years ago. It's working well, but it has a lot of complaints from business users. It is meant for business users, not a technical person, but they always get back to me and ask me a lot of questions and I have to troubleshoot a lot.

Oracle development is still working hard on it, I know, but it's been 3 years and it's still not 100% mature. I have a lot of issues with it. That's one of the areas that I would like to see improvement because we are one of the pioneers in the United States to implement that module in the government sector, so not a lot of users and clients are using it and we don't have a lot of help from our peers. When we talk to different peers, if they don't have it, we don't have something in common to talk about. That's our pain point, and users are having a lot of trouble and we have a lot of complaints about it.

Other than that, Hyperion is a fantastic planning tool. It works great. I always encourage users to use it instead of their accreditation auxiliary reporting, but this tool it puts me down sometimes in front of the business users. If I can't troubleshoot it and I can't give them the answer, I have to create an Oracle SR that can't be resolved in time. We have missed deadlines because of that and I had to create some workarounds from my side. That's how we got it resolved, but it's a huge pain.

It has a lot of limitations, too, on reporting of the text and formatting. For example, with the Budget Book, that's for the whole county and we publish it and we build it out of Hyperion, and if we use the reports from Financial Reporting Studio, we cannot format the way we would like to. It has a lot of limitations on text and formatting. I have tried a lot of formulas to get the format that I want, but it's not fully capable of handling a lot of text data and formatting that I need. That's another area in reporting that needs a lot of improvement.

Some stability issues are there with the Decision Package and the kind of application we have built. It has all the out-of-the-box functionality from Oracle, but it's really complicated. It's not just any hyperlink application, which all or most of the clients are using. It's very particular to government entities and how they budget their chart data and their expenses for the whole county. It's a lot of data. We have a data budget worth almost $2.5 billion, which is a lot to handle with all the different accounts and awards, projects, programs that are within our hierarchy. 

It has some stability issues. Some bugs are still there, but we have workarounds which are working fine. I would like to see improvements in the specific area that I was talking about.

We are using two tools for reporting. One is the SmartView app that's used with Excel. I like it a lot. I told all of my users to use it because it has all the drilling and rolling and all the capabilities for analysis of online database applications. The other tool, which is called Financial Reporting Studio, is not user-friendly at all and it can improve a lot. It has potential to have some improvement from Oracle from a development point of view. It needs a technical developer to build the reports out of that tool, which is not good for the business users. They try to learn it but it's too complicated for them and it's clumsy and it's not as simple as using, of course, the Excel reporting that they are used to. There are not a lot of options that are available for reporting in Hyperion other than these couple of tools.

A lot of functional users or managers involved in buying Hyperion don't realize what they're buying and what it's capable of. So, requirement analysis is the key thing. Before you talk to an implementer, determine what it is that you need and what tools Hyperion has available.

There are different tools for different purposes -- planning, forecasting, financial analysis, etc. The tools in Essbase is a little different from the tools in Hyperion. Before Oracle acquired Hyperion in 2006, it wasn't so mature, but not with the acquisition, it's expanded a lot and it much bigger than it was 10 years ago. You now have different out-of-the-box functionalities for each tool that serves the purposes of your requirements.

The key thing is to analyze and see, do you need Essbase or do you need Planning? Within Planning, what is the specific tool? We are using Public Sector Planning and Budgeting, and within that tool we are using the Position Only Model, and in that tool we are using the Decision Package Enable Application, so that's a key thing.

You need to see what you need and go for the implementation. That's why the implementer partners are there.