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
No comments:
Post a Comment