Lights-out automation is often times a top priority during a large implementation of Oracle EPM (Hyperion), and it’s easy to see why. The primary reasons for implementing a new solution are to cut redundancy times and allow for more data investigation. One of the most obvious ways to accomplish the former reason is to create automated data integration flows, such as nightly loads of actuals. Using a variety of tools, a quick integration between source and target systems can take a large workload off any system administrator.
However, there is a missing element that too often comes along with this solution: availability of an ad-hoc run. For example, the idea of nightly data load is great for 95% of the year….but what about during that yearly close? Or even the monthly close? In modern times, the timeliness of data is taken for granted at this point. Every piece of information is expected to be updated at any moment, on demand.
For those in a more technical position, there seems to be a very easy solution for this. Generally speaking, any piece of automation combines the use of a “scheduler” and scripting, where the scheduler’s job is to simply kick off the scripting at the requested time. Based on this logic, a user should be able to easily launch this same set of scripting manually, without having to wait for the scheduler to automatically execute the process.
While this approach is the most simple, it’s not always the most effective. If a financial administrator of an application does not have an ability to access this scripting, a request to IT will need to be submitted. Depending on an organization’s set-up, there might be hours of lag time between the request and the response. This is where the need for an administrator-run on-demand process comes into play.
Here’s where Oracle Hyperion Planning’s functionality can be leveraged to connect the administrator and the automation scripts. Within Planning, there are Substitution Variables that are used throughout the application. Generally they are used for items such as “Current Year” and “Current Month” in input forms, reports, etc. The importance of these variables from our automation example is the ease of modifying the value of the variable through the application front-end in addition to the variable values being available to the rest of the system.
By using a little extra “back-end” scripting, the value of the variables can be connected to the same automation script that’s run on a scheduled basis. Instead of making a request or waiting for the next run to complete, an administrator can modify the variable value to notify the script that an ad-hoc run has been requested. Then, the request is processed immediately by the system, instead of having to go through any request process.
The gains on data timeliness can be phenomenal, but the notification of errors/successes can be just as important. For example, Oracle Hyperion Financial Data Quality Management Enterprise Edition (FDMEE) is a great tool for the sourcing of hierarchies/trees in addition to data. However, a long data load will require an administrator to continually monitor the rule for successes/failures. While this may not be the most intensive task, it takes the administrator away from much more valuable opportunities. Using this idea of a front-end execution, the administrator can execute scripting that may not only execute the same FDMEE job, but it could also perform error handling with the errors/successes emailed to the administrator upon completion.
While this blog may have primarily focused on the Hyperion side of things, the issue of ad-hoc capabilities for financial administrators goes beyond both Hyperion and Oracle. There is a major wave of applications like Hyperion being put more into the hands of financial users while IT controls the infrastructure and server-side of the business. With more tasks being consolidated into the responsibility of a few people, the demand for a simple yet robust answer to data timeliness is becoming more important. By using the ideas described above, a quick and efficient solution can be put on top of an existing Hyperion Planning implementation to give it that extra push for those most demanding of days. When it comes down to it, a user that gets data one hour faster can respond with further input one hour quicker. And with so little time in the day, it’s sure to add up quickly.
For further information on incorporating a solution like the one described here, please send a note to firstname.lastname@example.org.
Author: Tyler Feddersen, Performance Architects