Johnson & Associates Consulting

 The long awaited patch for Oracle EPM 11.1.2 just came out a few weeks ago.  This means that customers should start considering going to 11.1.2 if they are starting a project.

One main feature of this patch is that it creates an upgrade path from prior versions to 11.1.2.  There are numerous other "features" / issues that one must consider when upgrading.  The patch notes are found at:  http://download.oracle.com/docs/cd/E17236_01/index.htm.

At this time if you are an existing customer you should be on either:

• -system 9.3.1 (expires January 2012)
• -system 11.1.1.3 (with patches)
• -system 11.1.2 (with just released patch)

 So, the real question is if you're on system 9, should you go all the way to system 11.1.2 or just move to 11.1.1.3. 

I've worked on 11.1.2 on native Essbase (unix) and on Hyperion planning without any patches.  While there were some "neat" features, at the time I would not consider to any customer to goto 11.1.2 without any patches.  This patch makes things interesting.  Are enough issues fixed?  This is where having that extra test environment comes into play.  If you don't have the time or resources available to stage up a 11.1.2 environment, this might be a great time to check out some of the cloud vendors.  You could build your own on Amazon or rent one (really cheap) at http://www.full360.com/hosting.  I spent some time tinkering with one of their virtual machines and was impressed that everything worked.  I'm not sure if they have 11.1.2 patched up and running yet or not.  I'll look into that.

Each customer should do their own due dilligence in order to make an informed decision.  If you ask your consulting firm and they say no you should really think before overriding their decision.  I know of a few customers that wish they had listened to such advice.

I'll keep my ears open listening for success stories and report back after I've heard about 5 customers moving forward successfully.  Unfortunately I'm on a long term project on system 11.1.1.3 so I won't experience first hand a production environment on 11.1.2 patched.

hj

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 a dozen Hyperion Planning projects I've seen some pretty whack stuff.  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 resutls, 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 mine), 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 11.1.1.3, 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 has 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.