Recent Posts


Choosing the Right Oracle EPM (Hyperion) Tool for Financial Modeling
Posted on October 2, 2014
Author: Ron Woodlock, Performance Architects

Oracle’s Enterprise Performance Management suite of products includes three tools for building financial models: Hyperion Planning (Planning), Oracle Essbase (Essbase) and Hyperion Strategic Finance (HSF). Understanding each product’s capabilities and limitations can help ensure successful project outcomes. To quickly determine the right tool for a given situation I evaluate four characteristics of a proposed financial model: time to value, inherent control, the number of users, and the level of collaboration.

Time to Value

Time to value is represented on the horizontal axis in the diagram below. The applications on the left side of the diagram, Planning and Essbase, follow a traditional application development life cycle that requires changes be developed and tested in a separate environment prior to migration to production. In contrast, the applications on the right-hand side of the diagram are capable of creating new financial modeling scenarios without going through a lengthy change process.

Two examples illustrate this concept:

  • Acquisition Model. When one company considers acquiring another, the acquirer needs a financial model to forecast possible results of the combined company. Required information includes how much debt will be needed, and how that debt will be serviced from operating income. Acquisition modeling is generally a good fit for HSF, as this type of modeling can be done within the application without making changes to the underlying software code. Within a few hours, an analyst can modify an existing company operations model to represent the changes required by the acquired company.
  • Annual Budget. Planning is typically used to prepare annual budgets. The budget process has a predictable cycle, generally occurring once annually. Several months prior to the start of the budget process, system owners request changes to the application. Typical changes include correction of issues from the last budget cycle, adding new web forms to collect data, or adding new business rules. Once the changes are made, a round of testing occurs to ensure the system is functioning as designed.    

ron w 1

Inherent Control

Inherent Control is represented on the vertical axis in the diagram above. The inherent control of an application is the combination of process and functionality that ensures the model continues to work as designed after changes are made. I’ve included Microsoft Excel because everyone is familiar with this application, and it is a great example of an application that has essentially no inherent controls.

HSF by contrast is a highly structured model that mimics standard financial statements. To use HSF, the analyst has to map actual data into the application’s chart of accounts. Once this effort is complete and tied out, the forecast periods can be modeled. This tightly controlled process ensures the integrity of the initial model, and more importantly allows for the incorporation of wholesale changes quickly and with a high degree of confidence that the model is still functioning correctly.

Planning is an application built upon an Essbase engine. Planning includes a proprietary structure that is customized during the initial implementation. The application’s inherent controls are derived from Planning’s proprietary structure and the controls added during the implementation. Essbase is used without the Planning application in situations where Planning’s proprietary structure prevents the system designer from meeting the business requirements. Applications built in Essbase have no inherent controls to begin with. All inherent controls need to be built to meet business requirements.

Number of Users

The number of users is a clear differentiator between the tools on the right and left of the diagram.  On the left, it is not uncommon for a Planning or Essbase application to have over a hundred users.  On the right, HSF typically has fewer than five users with an application model owned by no more than two analysts.

ron w 2

Level of Collaboration

Level of collaboration is also a differentiator. HSF offers functionality that allows analysts to share models and to integrate data between models, but does not allow for collaboration on the scale of Planning and Essbase. Budget and forecast models built with Planning and Essbase enable large groups of people to simultaneously input data and to calculate business rules, which is not possible in HSF.

Evaluation of these four characteristics should help to identify the right tool for the job!

Author: Ron Woodlock, Performance Architects


© Performance Architects, Inc. and Performance Architects Blog, 2006 - present. Unauthorized use and/or duplication of this material without express and written permission from this blog's author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Performance Architects, Inc. and Performance Architects Blog with appropriate and specific direction to the original content.

Leave a Reply

Your email address will not be published. Required fields are marked *