HPT Implementation:web form based security is not sufficient...

I've just come across an instance in a hyperion planning system 9.3.1 implementaion where a few accounts were set to read only by using a row definition setting in a planning web form. Having this feature available to us as developers sounds pretty handy until you think about the consequences. This will lock down the cell for web forms and smartview if used in the web form mode. If however your users will have access to smartview adhoc (if they have smartview they have this) or the excel addin with "essbase write" access provisioned to them, this cell is wide open for users to change the values.

Why might you want a cell to be read only? You could have a business rule that populates the value based on drivers or some other metric, this account could be pre-seeded, or only admin personnel should be able to update this account.

What are some workarounds that are a better best practice?
-in planning under dimensions, give all users read access only to this specific account. (have a group created for all users, preferably 2 groups, all users read and all users write)
-in essbase / planning, make a new account that is a dynamic calc that merely points to this member. By having the property set to dynamic calc, planning will automatically set the cell to read only.

This is similar to a project (large datawarehouse) where everyone thought that securing access to specific web analysis forms and financial reporting reports would limit users access to the entire essbase cube data. While they did not allow access to the excel addin, they did allow users to create their own web analysis reports. I mentioned that while our 85 security filters did limit access to data based on the entitiy dimension it did not eliminate the users from seeing the data that made up these reports. The customer was just overwhelmed with the project and said it was good enough.

hj

HPT Infrastructure: Top 5 wastes of an infrastructure consultant’s time

Top 5 wastes of an infrastructure consultant’s time

There are many reasons a project can go over-budget. In the world of Hyperion Infrastructure the most common ones can be avoided. If you take the time to completely understand all the tasks needed of them before your infrastructure consultant arrived, you would save a great deal of money. Or, perhaps, be able to spend that time learning about your environment and its care and feeding.

1) Download the software before the consultant gets there.

When in doubt, download it. If you download something that you don’t need it is ok, but if you don’t get everything you pay for a consultant to watch a status-bar!

2) Create your databases and give the proper permissions.

Normally you'll receive a list of Databases (or user/schemas in the case of oracle) along with a list of permission. Make sure you follow this, in the case of FDM there are special requirements that need to be met.

3) Order the servers AS SOON AS POSSIBLE.

I know that no-one wants to have capital expenses depreciating on their cost center any longer than they have to. But please remember that your IT department is likely to be very busy with everyone else’s requests. Furthermore next day shipping doesn’t mean that the vender has the servers in stock or that they are even built, it just means when they get around to shipping it, you’ll get it the day after. I've honestly been stuck waiting (and billing) until Wednesday of the *SECOND WEEK* for equipment to be ready. My record before that was noon on a Friday (in that case we were merely waiting for a network cable to be plugged in). In any case I cannot stress enough ORDER YOUR EQUIPMENT EARLY PLEASE!

4) Ensure that you have the appropriate meetings with your infrastructure consultant ahead of time.

Only you can know what’s appropriate. I’ve had simple customers want 10 meetings about something simple (waste of your time) and I’ve had extremely complex customers with complicated (and battling) political factions have only one short meeting. If you have 1 it guy that can do it all, have one good meeting. If you have a complicated it department (even if the environment isn’t) get all the parties involved. It's NOT going to help anything if we finish an installation with automatic deployment, get ready to go live, and find out that your IT department won’t support you because it has to be manually deployed with custom ports!!! This HAS HAPPENED more than once!

5) Ensure that your IT department is on-board with the installation.

I've been at customers who ticked their IT department off so badly that they wouldn’t provide simple DBA support. I can handle this if given the keys to the kingdom, and most likely if your IT department behaves like this your environment will be better off with me doing everything anyways. However, I will one day leave. While I very much appreciate all the after hours billing, you won’t appreciate waiting for me to be done for the day with my present client so that I can put your production environment back together after someone mistakenly trashed it!

6) Get involved with the installation (you didn’t think that I would actually stop at 5 did you?)

The preferred method of installation is for me to build the first environment so that your applications consultants (or internal people) can get working/testing ASAP (remember the applications consultants are billing you too). This is the fastest way to bring an environment up. But on the second installation PLEASE sit with me in a conference room (bring a projector please) and we'll do the installation with you driving. Don’t get me wrong, I’d love to bill you every single day to Webex in and handle your minutia, but it's far more efficient if you understand your environment and can handle these things by yourself. I suggest having at least one IT person in the room and your Hyperion support person as well. This way there is always at least 2 people who understand exactly what Hyperion is doing, and can come to the rescue at quarter end when the CFO is shaking his/her fist at you because they don’t have the numbers to report.

pp

HPT Implementation: hyperion planning users will use the webforms, really?

HPT stands for hyperion planning tips

**start of disclaimer**
Contrary to my statement above, webforms can be a very useful data input tool. This blog entry is an attempt to address a shortcoming every project must address. The implementation of hyperion planning where existing excel spreadsheets are turned into web forms does no one any favors. The entire budgeting process should be analyzed and where possible turn the budget data entry items into driver based metrics (ie. some expenses go up as headcount goes up, etc.). By creating more of a driver based budgeting tool, users can get into the mode of testing out different versions in the same time it might take to perform the raw data entry task of the old system.
**end of disclaimer**

Bottoms up budgeting really does mean bottoms up.

With many implementations, an initial r0llout is to a regional head. They'll do the budget for all their facilities. That's the thought until they realize they have to go into these webforms for every location that they manage. So, if they are in charge of 80 locations, someone is going to have to open a web form, select a dropdown, select go, then update the web form. Then hit save. This process multiplied by 80 or 100 is overwhelming, especially when the web form has 100 rows on it. At one client, I let them worry about this until I let the cat out of the bag and showed them the excel addin. This was on system 9.2.3 where smartview wasn't really "up to snuff". The only problem was they saw that "crutch" as the panacea to all their problems. Fortunately I was able to convince them to use this for only certain metrics that were drivers for the system by location. Smartview could help make the web forms less painful but make sure you prototype your solution before showing it to the customer. There is definately a learning curve with this tool. There is a reason why the essbase security role was added to planning in 9.3.1.

Hyperion Planning users: will your users really use the web forms?

This question really need to be addressed at the beginning of the project and not at the end. I've seen multiple (many) occasions where a system is not only designed but built with the thought that web forms will be used exclusively.

Watch out. When that UAT session takes place be sure to duck for cover when users realize they will have to retype their entire budget into a web form. All the work that has gone into tweaking their spreadsheet budgeting is now thrown out.

For some customers this can be forced upon the users but for most companies your controllers and other users are already swamped with work.

This leads us back to that good old trusted essbase - excel addin. Using this tool, you can create templates that can be slammed into essbase directly without the overhead of planning (web forms, smartview, app servers, web servers). The drawback however is that this is not something that you can hand out to your users on the eleventh hour without customizations. Due to the freeform nature of the tool, some training definately needs to happen. It's even relatively easy to add some custom vba to lock it down but this is development. Development takes time. This data entry method should really be vetted out during the design phase and not the UAT sessions.

In closing, there is nothing wrong with web forms. With the new composite form they can be really powerful. You can have the top half show a high level total and the bottom half could consist of various drivers. After updating a driver you can see the results on the same screen without having to change forms.

This topic was just one of many reoccuring themes that every hyperion planning implementation needs to address.

hj

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

Hyperion Planning Implementation Team Makeup

For a typical Hyperion Planning project (3-4 months) I believe the following resources are sufficient. This is assuming the etl duties are owned by the customer. This is often not the case and the
I believe most Hyperion Planning projects can be implemented with a team consisting of the following makeup:

customer: 4 resources
#1 part time project manager
#2 subject matter expert business
#3 subject matter expert business
#4 tech / infr resource
#5 erp system resource (in charge of extracting necessary data)

Now on the consulting side (consulting team) this would be my breakdown if I had a choice (3 necessary, 4 optional):

#1-part time project manager (not the customer) that is there during the presales phase. This resource is onsite full time in the beginning and then tapers off to 8-12 hours a week. They don't have to be an expert on Hyperion Planning but this person should know the basics. The goal of this person is to be MR Change Control (or MS). On a recent project, my "part time project manager" played this role to such a tee, the meer mention of his name would stop all discussions of new functionality that was deemed essential but not discovered during the design phase


#2 -planning architect
It's good to have someone that's performed at least 5 Hyperion Planning implementations. But if this person is not a hard core essbase guy then you'd better have a ringer as your #3.

#3 essbase architect
-essbase architect. I'd much rather have someone that knows essbase hard core than a 2nd chair in planning in this role.

#4 (optional) junior resource
-someone to build web forms and reports

Here's a key point. The more seasoned and senior your resources, the fewer bodies you'll need. I once heard about a project where recruiters said they needed 14 hyperion planning resources. I ended up passing because they were a little stingy on the rate and something didn't seem right. It turns out that the project was shutdown after a few months. I'm not sure the scope of the project but there are only so many consultants that can work on a planning system at the same time. There's only 1 outline per plan type and only 1 person can make changes to the hierarchies at any point in time. I just can't see how to coordinate that many consultants with business requirements that always change on the fly.

In choosing your resources for your project team take a little time to read the resumes of the actual worker bees that will be showing up. Many times the tech guru that was present during the dog and pony show is not available when the project actually gets started.

Also, when choosing candidates, you're much better off getting a seasoned essbase developer (4.x, 5.x 6.5, or even 7.x) on the team than you are having 3 additional planning resources or even requiring system 9 experience. (have you guessed I'm an essbase guy. Yes, I'm proficient in 9.3.1 p1 but as stated, I'll take a real essbase developer over someone that's implemented planning 9 times. I can teach planning to an essbase guy in under a day but you can't teach essbase in 1 day) System 9 experience on essbase doesn't really require too many additional skills. I'll write about this later. "what you need to know about essbase to retool up to system 9".

In closing, there are too many Hyperion Planning projects going south out there. Why are they having problems? Because their database size is out of this world. In most every case, having a real essbase developer on the team (the gruff type that tells you when you are being stupid) could have provided insight as to the feasibility of the design months before go live. Remember the underlying database is essbase. All essbases rules of thumb apply (block size, database explosion, calc times, etc.). By having a hard core essbase developer on site, you likely could have even changed direction (scope, functionality) to hit the live date. Given the fact that there is currently a resource shorttage of system 9 folks out there, if I were a hiring manager, I'd start paying more attention to all those resumes of essbase developers that do not have system 9 experience and throw them on my key Hyperion Planning projects.

just a thought.

hj

Hyperion Planning 9.3.1: Time to upgrade

Having been fortunate enough to work with the various version of planning from 1.0 (ha, ha) to the latest 9.3.1.1, I can say with a clear conscience that Planning is ready for prime time with version 9.3.1.1. I just came off of a 9.2.3 project and I was really impressed with the stability. The only 2 issues that annoyed me were
-the open ldap directory getting out of sync with microsoft active directory (a batch utility is available to sync these)
-smartview not allowing ad hoc users to lock and send into essbase directly (now included functionality in 9.3.1. This is enabled by a new security role called "essbase write access")

Now with 9.3.1.1 there have been some improvements.
9.3.1.1 has 3 new security roles:
-offline user (might not be new to 9.3.1.1)
-mass allocation
-essbase write access

One dangerous feature is the addition of the mass allocation security role. This feature is initiated by planners selecting it via the web forms. In the docs it is specifically stated that users have the ability to allocate to cells and dimension intersections where they do not specifically have write access. While I'm going to ponder the use of this new feature, it's important for everyone to know that enabling this security role could have far reaching consequences. I think I'll stick to writing customized business rules for allocations for at least the next 9 months.

The best feature that might warrant upgrading is the addition of something called "composite webforms". This allows you to create one web form that is a combination of 2 or more web forms. The ways to use this are endless.
ex1.
-actuals could be in to top panel
-budget can be in the lower panel

ex2.
-top panel could be total entity or company consolidated
-bottom panel could be the current budget

While this is a great leap forward, you cannot resize the 2 combined forms. The size is fixed to half of the screen (either vertical or horizontal). I think we can live with this.

One drawback of the latest planning is the fact that Oracle/Hyperion no longer wants us to use HAL for maintenance of the planning tree. Our choices are now "enterprise architect" and DIM. There's nothing wrong with using HAL but you'll have to get special permission to find / download the software. It's not on the download site any more without special permission.

After asking around, "enterprise architect" seems a little green. One issue I have with the tool is that once you create or modify the planning hierarchy using architect, you can no longer use the planning web to modify the outline. Now we are forced to manage planning via the "classic planning administration" option.

DIM (informatica with planning plugin) is pretty nice (a little hard to figure out from the docs) but it appears that it might have a short life span. It appears that this product will be replaced by something else from Oracle. This is a shame because it looks like a really nice tool.

The best part of this verison of planning was that I was able to make a new planning application without manually editing any confiugration files. The new app appeared on the web also with no need to bounce any services.

hj

Hyperion Consulting Market is very hot right now...

Right now the Hyperion consulting market is very hot. Some projects I've recently had to pass on were:

• a 3 week hal project
• a simple 3 week system 9.3 essbase upgrade
• another system 9.3 essbase / reports install
• 2 different planning architect roles.
• a senior HFM architect role (DC)

I can help reduce your downtime between projects. I'm looking for very senior level independents out there that specialize in Hyperion. If you're a senior level independent consultant and would like another tool to help keep the downtime at a minimum, I'd encourage you to send me an email. I've even had to go outside and have my customer use a generic recruiter because we needed extra help. Right now my primary recruiting focus is top tier independent Hyperion talent (5 yrs exp+). I'm also gathering folks that are full time admins or consultants looking for a change of scenery. I get a call every few weeks from customers looking for full time admins. While my primary focus is being a hands on consultant (to pay the bills), I believe I can provide value in filtering out the really good projects for other independents out there. Just think how much more we can make (independents) if we could reduce the number of middlemen between us and the customer. I had one project where there were 3 middlemen. I got the rate I was looking for but was the customer really getting the best bang for the buck?

hj