During the requirements and design phases (pre-implementation) in an Oracle Hyperion Planning implementation project, the idea of improving the actual planning process often gets lost, recreating process issues in the new solution. The steps below demonstrate some important functional items to consider during requirements and design for a planning solution.
- Consolidate Data Entry and Calculations
Most of the user experience boil downs to how data is entered and calculated. Many users maintain scenarios outside the planning solution. Unless these “shadow systems” are truly investigated, the new planning solution will end up with a disconnect between what users need and what the planning system actually does.
The idea is simple, but the execution is difficult. Some users will have to compromise unless the entire planning audience happens to use the exact same planning methods.
A nice beginning may be to look for what the team uses when inputting data. Do they refer to Actual data? Budget? Forecast? Do they enter by Account or by Entity? In addition, do they use any type of source data in combination with a driver to get their new numbers? Spend a little time talking with key stakeholders, and a great time-saving opportunity may come out of it.
- Use Realistic Timeframes for Reports Availability
A common misconception is that all numbers need to be available for reporting at all times. This may be true for some organizations, but most do not have a true need to see an updated total across the entire organization each time a single data entry is made. This thought process is important because there will always be a give and take with performance versus availability. As data timeliness becomes more important, either more resources must be dedicated or a performance impact must be acknowledged.
This section will be more important to some than others. There’s a vast difference between a solution that uses two chart-field strings versus one that uses five or six. For the former, data availability might be a very simple issue to address, while the latter will see many more challenges along the way. Luckily, Hyperion Planning offers multiple options. Ask following questions when looking for the right solution:
- What data needs to be available immediately on a data change?
- What data can be updated periodically throughout the day (e.g., twice a day)?
- What data only needs to be updated once a day?
- What data needs to be available based on the beginning/end of a cycle (e.g., budget open/close)?
The difficult part of this process is determining what is actually required versus what people are simply most comfortable saying. Most of the focus will be on “all data at all times,” but there is often a large disconnect between the “want” and “need” mentality. Once team attitudes shift to what is actually needed, data can be updated very efficiently.
- Create an Automation Path
The question often comes up, “Can <insert request> be automated?” The answer is….maybe. The truth is that every piece of automation requires the following: technical capabilities, time, and universal requirements. The most important of the three often comes down to the final item. As a requirement becomes more universal throughout the organization, it becomes more difficult for the technical solution to address and thus takes more time to implement. As the time increases for a single piece of automation, the time available for other potential automation ideas diminishes.
When considering different automation ideas, try to prioritize the most important ones. For example, loading actual data from an enterprise resource planning (ERP) system is the most common, since this will generally benefit 100% of the organization. A more specific example might be to implement a quick way to apply a cost of living adjustment (COLA) for employee budgeting. Instead of a user having to modify each salary with the same percentage increase, a calculation can be created to automatically apply that increase on the user’s demand. The question would now be, “Can the same calculation be used for all users across the organization, or do some groups calculate this increase differently?” As more scenarios are uncovered, the time to create the calculation increases. As this time increases, more opportunities are sacrificed.
- Provide a Way to Change
Those with an existing process often end up using a “lift and shift” methodology during the implementation of a new solution, meaning the new application is simply created to do exactly what the existing application may have previously done. Sometimes this is intentional as part of a “crawl, walk, run” approach where the first phase is used to get the feel of new technology with ensuing phases used to apply enhancements. However, more often than not, it’s the result of people not wanting or not knowing how to change.
A new implementation offers the opportunity to make a process change that may have been difficult to make to the existing application. If a “lift and shift” technique is going to be used, a well-thought-out roadmap should complement the solution to avoid similar pitfalls. Without this, a technical solution can only be as effective as the functional process that it automates.
While the points above are geared more towards new implementations, these can also be incorporated into existing solutions as well, especially during an upgrade. Remember, there has rarely been a time when too much time was spent during the requirements stage!
Author: Tyler Feddersen, Performance Architects