migrating skillset from essbase to hyperion planning:

This will be revised as I stumble upon other major topics but here's a start at some of the major components that must be understood by an essbase consultant for them to move into the hyperion planning world. (why an essbase guy should morph into hyperion planning is a topic for another day...)

For an essbase guy to morph into a hyperion planning consultant the following must be known and understood.

-yes, essbase is the back end for planning
-a planning app is comprised of an application and 1 or multiple plan types.
-a few database settings must be known when the application is created for the first time. Once created, these items cannot be changed. Among them are:
-starting year for model
-number of plan types. You can have up to 3 for planning. If you create only 1 when creating the application, you will not be able to create type2 and type 3 later. There are some additional modules that bring the total plantype up to 5 (capx, workforce planning)
-a planning application that contains more than 1 plan type will exist on the essbase side as an application with 1 or more databases. Each plan type translates into a database.
-the outline meta data is stored in a relational repository. When you want to modify the outline changes are made to the repository. Then they are pushed to essbase via a refresh operation.
-when a refresh operation is being performed, it affects all plan types at the same time. You cannot choose to update only 1 plan type when there are 3 existing.
-changes to the repository are made thru using either planning web interface (if not using architect), HAL (product is on life support and will sunset soon), DIM (informatica with planning adapter), or enterprise architect.
-do not play in the relational tables (unless you really know what you are doing)
-do not, do not, do not modify the outline directly on the essbase side unless you really know what you are doing (with system 9.3.1.1 other than some formulas, this is not that necessary)
-do not touch the system until you can confirm that backups are being performed properly. This means that the relational metadata tables and the outline must be backed up with the same date stamp.
-do not go home at night until the refresh has completed successfully.
-the worst thing that can happen is to have a planning model where the refresh will not run. The system will be up and work but your connection between the metadata and essbase is broken and you will never be able to update the outline again until the refresh completes successfully
-security in planning is not as flexible as that in essbase. You cannot have an account be writeable in budget and read only in forecast (assuming budget and forecast are both writeable). The filters are based on one dimension at a time.




If anything above doesn't sound correct please correct me....

hj