HPT Implementation: taking care of your resources...

As planning projects are getting larger and more complicated it's more important than ever to have the right resources. One key to getting the right resources is to provide 4 day workweeks and avoid at all possible the working on weekends. I haven't been on a project yet where working a weekend straight through will result in a successful project. There is usually so much input required from the customer that having consultants working crazy hours without end users to validate the system is just wasted money. In every case that I have witnessed, the need for this type of work schedule was due to changing requirements from the customer that were somehow missed (either the right questions were not asked during creation of the design document or the customer had new ideas after the system was already designed).

If you're with a consulting firm and this is not a #1 initiative for your consultants then your consultants will be leaving very soon. Your competitors are offering this if you fail to. If you're the final customer your pain will be even greater because it is very difficult getting hyperion resources hired.

Let's say you get phase 1 of your project complete and you're ramping up for phase 2 only to realize that all of your resources (employees, contractors, etc) have all decided not to follow you into battle. Think how much talent the customer just lost by having all the developers walk out the door? Was it really worth hitting that deadline to lose your entire technical team? I was at a customer where 3 employees quit within a week after being fed up with working xmas, new years, and endless weekends. The real pain point that that these employees were there for the duration of the 3 year project only to leave right after go live of phase 1. The best part of that project was that the 3 project sponsors, who didn't work any weekends and who were responsible for changing scope got big promotions for hitting their live dates while some of the employees on the team didn't have jobs after the project was over.

I've been present at a client when the "style" was to use profanity at my team. Profanity in and of itself has never really bothered me but it's a little different when it's directed directly at you with the words "this is unacceptable. You're all going to be bleeping fired." It's a little dishearting to hear these words on week 2 of a 5 month project. How motivated do you think we were to go over and above? How much extra stuff do you think snuck into the scope without a change order request?

hj

Hyperion Planning tips: entry 1

From time to time I stumble upon little tweaks that greatly affect deliverable functionality in planning. This is the first blurb in a series that will be updated over time. These apply to hyperion planning 9.3.1.1 p1. Most of these tips probably work with 9.2 as well but I can't confirm or deny.

1. -enabling YTD dynamic time series in planning
2. -creating alternate period rollups
3. -use of substitution variables
4. -top of dimension properties in planning
1. storage properties can be set
   

1. enabling YTD dynamic time series in planning:
In order to use ytd dynamic time series you must first rename the year dimension to something else. I tend to use Years. Year is a reserved word and using this as your dimension name will prevent you from being able to perform dynamic time series.

2.creating alternate period rollups:
If you'd like to create your own alternate period rollups you can now do this on the planning side and push them into essbase. You could make your own ytd rollups, qtd rollups or what ever you dream up. While adding them in the web interface it's a little painful as it's not too easy to reorder the members but it does work.

3.use of substitution variables:
We can now use substitution variables inside of member formulas. This applies to essbase as well as planning and probably came out with maybe system 9. This is a huge step forward and might effect every business rule you develop going forward. It could be used for the processing of the current budgeting period, forecast year, or anything you can dream up. I'm a little embarrased that I didn't stumble upon this (co worker tried it and told me it worked. I still didn't believe him) earlier. I need to spend more time reading the release notes.

4. top of dimension properties in planning:
storage properties can be set:
Now you can utilize some of those essbase skills in tuning a database. We can now set the storage property of the top dimension nodes. While we've probably all created our own work arounds to reduce blocks, this makes it a lot easier to "tighten up" our databases while working within the planning infrastructure.

as always feel free to correct me or better yet, send in some tips that you've stumbled upon..

you can contact me anonymously at hjohnson@john-assoc.com

hj

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