Essbase Business Rules versus Calc Scripts – Which Way Do I Go?

 digg it |   delicious |   StumbleUpon |  reddit 

We've had a number of clients ask questions regarding Essbase business rules and calculation scripts - which one should I choose? It's a good question. They are very similar in nature and both can be launched via Essbase Administration Services console and the Planning web interface. Today, we will attempt to identify some subtle differences that you can utilize to help make the decision.

Scheduling Differences

It's common to create MaxL or Esscmd scripts to perform maintenance on Essbase applications. Many times, these consist of clearing and rebuilding an outline, loading some data, and then calculating the database. When this is the case, calculation scripts are the best choice. Business rules cannot be launched via Esscmd or MaxL.

However, if it is only a calculation that is required, business rules can be launched via a command line (CmdLnLauncher) and scheduled. So, in cases where you simply want to perform a calculation or series of calculations, business rules can be created and scheduled without the need to create additional MaxL or Esscmd scripts to schedule the calculation execution.

Business Rules Advantages

Macros and sequences - Business rules provide the option to use macros and sequences. Macros are mini rules that can be reused across multiple rules. Additionally, the macros and business rules can be sequenced to order the rules based on business requirements.

Run-time prompts - Business rules have the ability to use runtime prompts.  A value or dimension member name can be entered by a user via a prompt or read directly from a Planning form. The business rule then becomes dynamic in nature through the use of the run-time prompt.

Security - Many assume that business rules can only be utilized within the Planning product. This is incorrect. Business rules can also be executed against standalone Essbase cubes. An advantage of the business rule approach is that business rules can be included in a project within Shared Services, and security can be assigned and managed at the project level rather than against the individual business rules.

Calculation Script Advantages

Debugging - Calculation scripts provide a much better environment for debugging any errors that may occur. Calculation scripts provide much more detail in the error messages generated. Calculation scripts will provide the user and line number in the script where the error occurred. Business rules, on the other hand, will not show the user executing the rule, merely the user associated to the data source name.

Script Creation and Maintenance - It sounds simple, but the ability to perform search-and-replace functions in the calculation script editor is definitely better than the find only feature within the business rules editor. Also, you can't perform an Undo function within the business rules editor. Finally, validation is easier in the calculation script editor, since there is no requirement to save the script prior to validation.

Hopefully these tips will help you make a more informed choice the next time you have to.

Oracle Hyperion Planning Guidelines: “Planning” before a Planning Implementation

 digg it |   delicious |   StumbleUpon |  reddit 

-Written by Chris Harris

Oracle Hyperion Planning is a great tool for the forecasting and budgeting process.  The ability to both gather and report a wide array of budget and forecast data in a central system is invaluable to an organization of any size.  Include the Capital Expenditures (Capex) and Workforce modules and Planning can handle nearly any requirement of a company's planning process.  However, if a company fails to properly plan for the new system it will be very difficult to realize the benefits offered by Oracle Hyperion Planning.  The following are crucial items to keep in mind when implementing a new planning system.

Define business processes prior to implementing the system - It is important to have a clear understanding of what the underlying business processes are going to be prior to the start of an implementation.  This may seem obvious for existing processes, but it also applies to new processes that will be implemented with the system.  If these processes aren't clearly defined and understood by both the business and technical professionals prior to the implementation the details could easily derail the project.

Identify inefficiencies with the current system and plan to change as part of the implementation - Oracle Hyperion Planning definitely facilitates the budgeting and forecasting cycle, but building a planning system around flawed processes won't fully leverage the tool.  Even worse, incorporating these items into the system can delay implementation and take away from the areas where Oracle Hyperion Planning excels. Many times these inefficiencies appear to be must haves because they have been part of the cycle for years, but close examination will probably show that these processes are costly and at the same time add little or no value.  Because these processes are so deeply engrained they can be the hardest to challenge, but doing so will ultimately improve the Hyperion Planning system.  The Oracle Hyperion Planning implementation should be more than an implementation of software, but also a refining of processes.

Focus on Pain Points Steps should also be taken to flag pain points and ask why they are problematic.  Many times the answer is collection and organization of the process.  This is where the out of the box functionality of Planning comes to the rescue.  However, a lot of these issues are a result of offline calculations and data gathering.  Many times this will require customizations to the system in the form of custom business rules and data forms.  It is crucial to identify these items prior to implementing.  Most often this is done by including the right players in the design process and sessions.

Don't try to do more than planning with the Planning system - When designing a planning system it is crucial to know "the right tool for the right job".  Depending on the complexity and requirements, it may be necessary to keep processes like allocations and management reporting downstream from the Planning system.  It is very important for an Oracle Hyperion Planning system to be quick and nimble.  Many users will simultaneously be using the system and the more extraneous processes incorporated the slower the system will be.  Identifying processes and reporting that is not essential to the budgeting and forecasting cycle and moving these into other tools will ultimately benefit both those processes and the Planning system.

Executive management buy in is key - It is crucial to involve executive management in the initial stages of an Oracle Hyperion Planning implementation and to keep them updated throughout the project.  In addition to sponsoring the project financially, these individuals will ultimately be the audience for the output of the system.  Involving this group early and often will ensure the system meets their needs and delivers value added output.

Implementing a new budgeting and forecasting system is a big undertaking that requires the input, effort, and cooperation of many players across the organization.  Planning ahead and considering the items above will contribute to the success of the Planning system implementation.