Hyperion Essbase Knowledgebase

Essential Hyperion Planning Do Not Do Tips

User Rating:  / 0

Some of the first tips that anyone touching Hyperion Planning in an administrative function should know include:

-Do not, I repeat, do not touch the Essbase outline (There are a handful of cases where this might be necessary but check with the developer of your system before doing anything in this regard).  The most important thing to understand about Hyperion Planning is that the database hierarchy is maintained in the Hyperion Planning repository tables.  This hierarchy is then pushed to Essbase via a refresh process.  If these ever get out of sync, then the Planning system is essentially dead.  At this time it's time to visit your recovery procedures.  BTW: make sure your backups for Essbase and the relational Planning tables are taken at the same time.

-During the refresh process, never, ever select "Create" from the refresh window (unless your developers has instructed you to do this).  I was at a client where their directions were to select "Create" for their refresh process.  They would then have to create their YTD members by hand in the outline directly.  This took place every refresh instance.  If they had instead chosen "Refresh" instead of create, these outline changes would not get lost.  Also, in the older versions of Hyperion Planning, the software did not allow you to create complex member formulas in the web then push them to Essbase.  This meant that you had to directly enter formulas in Essbase.  By selecting the "Create" button, all of your custom Essbase changes get lost.  Planning takes all the metadata and creates the database from scratch based on the metadata stored in the relational tables.

-In the Hyperion Planning web interface, never ever add a dimension by mistake.  This is easier said than done.  When you are in the Planning web trying to add a new member, it's very easy to accidentally add a dimension by mistake.

   Most every Planning project has had this occur.  The main pain is losing about 2 hours while you track down the directions to remove all the entries from the various relational tables.  The main pain in this process is that you need to have admin rights to the relational tables.  This can be quite an issue if you're relational tables are running on Oracle as the odds of a business person having rights to Oracle are like 0.  So, hopefully you're running sql server and can get rights to the tables.

-In Hyperion Planning do not enter all your member formulas manually in either the web interface or directly into Essbase.  I have seen too many instances where all the formulas were entered via the web then a rebuild of the entire application was mandated.  With Hyperion Planning, assumptions are made at the creation of the app that will possibly not be true as the project progresses.  We have to keep in mind during the build phase, that everything possible should be scripted.  Instead of manually entering the formulas, place them into a file for bulk loading into Planning via either a tool like ODI, DIM, or even directly to Essbase via load rules.  Note: As Planning is maturing, there are fewer excuses for entering member formulas directly into Essbase.  There might still be a few exceptions but at least 90% of all formulas can be bulk loaded to Planning these days.

-Do not leave the end user with a listing of rules to run by hand while navigating between web forms.  I've seen systems where a business analyst is supposed to run 5 different rules by hand after submitting 6 different web forms.  A system such as this represents a poor design.  In this case, each of the 5 rules were consolidated into 1 business rule.  This 1 rule was then attached to each of the 5 web forms to run on save.  This not only streamlines the workflow for the analyst, it also reduces the number of business rules from 5 to 1.  Maintenance will also benefit.

-Do not have your users have to enter more than 3 prompts while budgeting or reporting.  To keep the # of prompts down to a minimum you can make use of either setting a default value for a prompt then hiding the prompt or using a substitution variable.  I've seen an example of a financial report where the user was supposed to answer 14 prompts in order to run 1 report.  This was to meet a unique reporting requirement of a business user that was not too flexible.  Despite the design teams efforts, this report went live then was promptly taken down after go live.

-Do not run Hyperion Planning without a development environment (a test environment is really necessary to test the various patches that come out while you're in the middle of developing your project).  A development environment will cost you less than 5k these days.  That's less than the cost of an onsite consultant for a week.  This will allow you to test different strategies without trashing your production environment.

-Do not let your infrastructure constultants leave without having your personnel bounce the servers on their own to make sure they know how to do this.  You might be surprised if you looked under the hood of Planning to see over 10 services that need to be up and running.  Not only do these services need to be up and running, but they have to be started in the proper order.  Other infrastructure tips are posted here:  Infrastructure top 5 wastes of time


Additional information