Three important facets of Oracle Hyperion project implementation

When implementing an Oracle Hyperion project, a company must be aware of technical, management and roadmap issues.

I am researching technical issues that might occur during Oracle Hyperion budget and planning implementation.

I'm focusing on issues that a large enterprise might face while working on a Hyperion project with an Oracle implementation partner. The partner's goals are not necessarily the same as my company's, and thus I should understand the issues involved to avoid being overly dependent on the partner.

Ian IrlandezIan Irlandez

I know you are interested in the technical issues, but if you can address issues with management and create a roadmap, it would alleviate at least half of the dependency on the Oracle Hyperion partner. I would break things down to three areas to consider: technical, management and roadmap.


You need to be aware of a handful to things from a technical standpoint, especially for a large enterprise solution. Usually large enterprise solutions are complex. The complexity resides on two fronts: multiple integration points and a larger database with complex calculations.

Multiple integration points are designed to merge data and metadata from multiple sources. Tools such as Hyperion Data Relationship Management (DRM) and Oracle Data Integrator (ODI) are used to integrate metadata and data into Hyperion Planning and Essbase applications. Relational databases can also be used to store the data and metadata from DRM, therefore making the integration design more elaborate. You need a lot of coordination between the DRM, ODI and DBA developers to ensure success. Another metadata and data integration tool to use is Oracle Enterprise Performance Management Architect (EPMA), which does not require levels of coordination as high as DRM. But EPMA has had issues in the past with deploying applications in Planning and Essbase. Using EPMA may require more patience and investigation on application deployment. The newest release of EPMA may be more stable than previous releases.

Database size and calculations are other potential technical issues for a large enterprise. Usually large companies have many dimensions in their database because they want several ways to track their data. This helps establish their metadata. Next, large companies sometimes require more elaborate calculations. But developing an elaborate database can hamper system performance. Running a series of stress tests helps with server and database tuning, as well as hardware sizing.

Other technical considerations for a Hyperion project would be backup and disaster recovery. Large enterprises usually already have an established requirement for backups and DR. If the requirement exists at the client, then use this methodology. However, the Oracle partner can suggest a schedule for backups and a DR strategy.


Some management issues reside around whether internal resources have enough technical knowledge for system maintenance. If the client is implementing just a planning application, then a resource will minimally need experience developing Essbase calc scripts or business rules and planning application development.

For more on Oracle Hyperion

Read how to create business rules in Hyperion Financial Management

Is Hyperion a major release?

Has Hyperion improved Oracle's BI strategy?

If DRM and ODI are used, you'll need a full-time resource to maintain both applications. So the complexity of the project dictates the resources needed. This issue is often overlooked and is usually why there is such a large dependency on Oracle partners. If a company puts in place an internal team while development is ongoing, it can learn from Oracle partners and participate in development in a controlled manner. This will help the team establish credibility, gain experience with the tools, and foster an easy transition from an Oracle partner to internal support teams.

When it comes to managing the business process, many clients depend on Oracle partners to design the process of the planning cycle. Although this can be done, it's better to have the internal team drive the discussion. The Oracle partner should only partner with the internal resource or resources to establish the planning process. It helps the company take more ownership of the application and reduces dependence on the Oracle partner. Internal resources manage the change management of the project as well.


The same internal resources should also team up with the Oracle partner to establish an implementation roadmap. With large enterprises, the application can be complex and deployed to many locations worldwide. Enterprises should craft a roadmap with a phased approach. For example, begin with a P&L plan for phase 1, and then a balance sheet plan for phase 2. Or roll out the planning application to North America in phase 1 and then Europe in phase 2. If the client has this mapped out, it can prepare for obtaining resources and establishing milestones for the project, therefore lessening dependence on the Oracle partners.

If the client can manage all these items, then it can use the Oracle partner to just advise and help establish a roadmap, change management/process, knowledge transfer to internal resources for total company ownership, and provide the heavy lifting of the development efforts prior to the internal resources establishing themselves as viable options.

On most Hyperion project implementations, the Oracle partner is heavily involved in the beginning, partnering with the client to establish the roadmap, understanding the process and then building the application. If internal resources can be leveraged to do some of the development, it helps with dependency on the Oracle partner. However the internal resources will need to be on board immediately and have some experience with the tool to be effective.

Ian Irlandez is a solution architect at TopDown Consulting, an Oracle Hyperion consultancy. He has more than 10 years of experience working with Hyperion applications.

Dig Deeper on Oracle Hyperion