What is the most overlooked task on Hyperion Planning projects? Security.

Building security.

In the throws of a Hyperion Planning project, everyone is quick to want to get into the system to see and touch it. Sometimes this leads to the admin id / password getting out the door. Or almost as bad, all the folks on the team, including business users, getting provisioned the administrator security role.

This might seem like an ok idea on day one but no one ever comes full circle to test security from an end user perspective until that fateful day, UAT (user acceptance testing).

Here's why security cannot be slapped together in an hour or 2.

-reports that were developed without using a "secured" test user id WILL NOT work when using a "secured" id. In Hyperion Planning, any id other than admin cannot see data at the top of Entity, Scenario, or Version. Reports developers usually do not know this as their background might include writing reports directly against Essbase (not an issue here) and not Hyperion Planning. All too often when the army of report writers (IMO the customer should write the reports with consultants assistance) are brought in, they somehow acquire the admin id or privileges to get their report development moving. They get their 50 reports done and roll off the project. Then during uat (if security is actually tested), none of the reports works. Now you're left scrambling to "fix" these reports with the original developers long gone.

-properly setting security so a web form enables write access is not a small feat. Each of the "delivered" dimensions entity, scenario, and version first have to have members opened up (through "meta data" security assignment). This applies to administrators as well as users. Allowing administrator access for testing is only a crutch that will get you in the end.

-sometimes when looking at the security matrix it's determined that the entities dimension does not allow for the proper security to be applied and changes must be made to the entities dimension. This is not an easy thing to do at the end of a project. All business rules need to take into account any changes in the entity dimension as well as reports that have been developed.

-web forms that used to work under the admin id don't work with a secured id because the business rule security has not been assigned. Business rules have to have their security assigned for secured id's as well. Since business rules are usually set to run on save without interaction from the user, it can be a difficult issue to resolve when users report that a form is "busted" and give no further detail.

Security can be a very complicated matter. Not enough thought is given to the design of the security matrix and not enough time is dedicated in the project plan. Every project has to address building security in Hyperion Planning.

I will outline how I address security in a later post or on my website.

Like most everything, proper time needs to be taken in order to match the security requirements with especially the makeup of the Entities dimension.

hj