Hyperion Essbase Knowledgebase

Hyperion Planning Best Practices

  • Print
User Rating:  / 0

Many times the focus of a Hyperion Planning project relate to system testing of the business logic.  All too often not enough time is spent walking through the workflow of the typical user.  After working on over 4 dozen Hyperion Planning projects I've seen some pretty whacked out projects.  Things like users having to have a cheat sheet of which rules to run when, a hand written set of notes for which forms to submit in what order, etc.

Through use of some of the built in features and some design strategies, your Planning system can be much more user friendly, can produce predictable results, and will result in many fewer phone calls for support.  Your users will complain less and be much more productive.

  • Web forms can have business rules attached to them that run on save.  Use them.
  • Just because you have 8 web forms for data entry for a type of business model does not mean that you need to have 8 different business rules.  Take a look at the 8 different rules and see if you can combine them into 1 rule without a noticable difference in performance.  Then attach the same 1 business rule to all 8 web forms.  You have just streamlined your administration.
  • Don't allow users to consolidate on top of each other.  While you probably want to allow a user to consolidate their slice of the world (if it doesn't take too long), be careful of allowing a total database consolidation to be kicked off by more than one user at a time.  If you allow all your users to launch an agg all on the entire database, then you run the risk of "changing" numbers when users are creating reports.  Depending on the calculations being performed (allocations come to mind), you can also create a system that will crash upon a heavy load.
  • Task lists: There are objects called task lists that force the user to follow a prescribed set of steps.  It will not let a user jump ahead in the budget process until the specific steps are completed.  I have mixed thoughts on this feature as as of system, the user could turn off enforcement of the task lists.  Aside from that, I think it dummies down the system a little too much.  Sometimes it's good for a user to enter their data then see that parts of their budget are not filled in due to their not loading some driver assumptions.  Some customers make great use of task lists but I don't feel they are essential to design a usable system.
  • During the day versus over night scripts: The hardest thing as a developer is to keep track of all the business rules and code changes.  There are many cases where during the day the numbers look good but when an overnight process runs the numbers appear to change.  This is due to running an overnight process that will fix or catch calcs that didn't complete during the day.  This type of script is essential but they are very complicated to maintain due to the order of operations that makes a big difference.
  • To use member formulas or not:  In designing your Planning system you have a choice as to where to implement your business logic.  You can make extensive use of member formulas or you can perform all your logic inside of Business Rules.  There are advantages to each.  With the member formulas, your consolidation calc scripts / business rules will be much simpler.  The drawback is that to make changes to these formulas, you will have to perform Planning database refreshes.  This will cause outtages however brief in the system.  If you embed all your business logic in Business Rules, then you can more easily make changes to the business logic during the day without bringing down the system to your end users.  You can also more easily control security over who can run what business logic by enforcing security at the Business Rule level.
  • If you use member formulas "do not" enter all of them via the web interface.  I've come across too many Planning systems that utilize member formulas extensively.  In most of these cases, the models have to be rebuilt for optimization purposes.  This means that during a rebuild if you don't have the building of the formulas scripted they will have to be reentered manually.  If you are going to use member formulas, make sure you can bulk load them into the Hyperion Planning relational repository.