Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« Overcoming Innovation Challenges in Banks: Need for Strategic Thinking | Main | OBIEE 11g Upgrade - Some Key Considerations »

Thinking beyond Hyperion Essbase for planning (Part 2)

Guest post by
Hari Ram, Senior Systems Engineer, Infosys

 

In the previous part of the blog, I discussed about the basic differentiators between Essbase & Hyperion Planning based Financial Planning systems. In this I am sharing thought on Data and Process management aspects of both the approaches.

  • Version management
    In Hyperion planning, the Version dimension, which is one of the default dimensions, can have two members of either a Standard Bottom-up or Standard Target type. The Standard Bottom-up allows users to input data only at the lowest level of members, while the Standard Target allows users to input data at any level of members.

In Standalone Essbase based planning system, a Version dimension may be created to handle different versions of data (In Progress, Frozen, Approved etc..,). The different versions don't have any built in features to handle Bottom-Up or Top-Down planning.

  • Data validation at entry level
    Hyperion planning provides the inherent data validation rules feature that can not only highlight the deviation of data from the guiding rule, but also reflect the same in the Approval process. This not only gives better visibility of deviation, but also keeps check on the data-integrity and track of problem areas. The turn-around time for an additional look at the situation is reduced due to the single-standard, single view of Data Forms, approval path across the users.
  • Handling task calendar
    Financial Planning process would involve a series of activities and processes and change of ownership, beginning from the data load from a transactional system. In many cases, where Hyperion planning is not the Financial Planning system,  the individual tasks, activities, ownership, due dates, status are tracked either in a customized MS Excel spreadsheet or another web-based portal.

Consider a Calendar tracking system based on a web-portal. The Calendar would have-
•   Option to create tasks.
•   Assign ownership
•   Select the due date
•   Option to update status of tasks.
•   Links to the standard Excel based data entry/reports spreadsheets

One has to traverse from the Calendar tracking portal to the data entry excels and then connect to Essbase to work with data. The loose-coupling/dependent -yet so alien relationship (a very bad combo) between the underlying code of the Calendar system with the Data repository (Essbase) poses a major threat to the very thought of enhancing the approach. The rigidness of the existing Calendar tracking application and the effort of coding the portal or making the enhancements to the legacy approach do bring in a road-block due to time and money involved with it.

I have seen few Task Supervisors maintaining Excel based Calendars to track the status of tasks during the Financial Planning process. It sounds so risky & unmethodical.
The Hyperion Planning Task List provides a tightly coupled, single box relation between the Calendar tracking system and the Database and Data Forms. Enhancements or change in approach can be seamlessly brought-in without much hassle.

  • Approval process
    The approval process is handled either through conventional mails or web-based portals built outside Hyperion family.  Hyperion Planning brings the comfort of having a comprehensive box to handle data ownership and promotion towards approval. Also, the centralized view keeps the user community informed of the status and bottle-necks along the data movement/approval process.

I used to work with a standalone planning application, where data would be moved to relational database through a web-based portal for data approval and then transferred to another application for Head-Quarter view. Handling approval process for multiple entities was a challenge due to rigid coding of the Java based portal working with PL/SQL. After lot of brainstorming, we had to give up the whole idea of multiple entity promotion due to additional effort and chances of violating the standard approach across the Organization.

The Planning unit Hierarchy in Hyperion Planning, which is a combination of members of the Entity, Version, Scenario and an additional dimension, handles promotion of single or multiple Entities for approval.

  • Reduction in Planning cycle time and effort
    Availability of a central system, capable enough to handle critical & requirements of Financial Planning process makes Hyperion Planning more efficient in terms of time and effort, when compared to Standalone Essbase based planning system.

Comments

Hari-
An excellent blog series which brings out the capabilities that Hyperion Planning(HP) comes with. While Essbase still remains the heart of HP we are able to bring the best practices of financial planning using HP.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles