When it comes to the fine art of writing business rules for Oracle Hyperion Financial Management (HFM), many practitioners tend to keep things as simple as possible. In most cases, this rule of thumb works well. However, there are times when you should create data units to increase performance and efficiency.
For those familiar with Visual Basic functions in Microsoft Excel, think of a data unit as a vlookup for HFM. Just as a vlookup can be very powerful in Excel, so too can opening data units really harness the power of HFM. In one particular case, using this approach at a large, Fortune 10 company enabled me to reduce the consolidation times of their application by over 40%.
Creating Rules to Retrieve Data in Oracle Hyperion Financial Management
When creating rules to retrieve data in HFM, there are essentially three methods for doing so:
- Explicit rules
- Rules based on member lists
- Rules based on opening data units
These methods typically get more difficult as you go down the list. Writing explicit rules is the safest and most straightforward approach. In many cases I find myself writing “temporary” explicit rules in order to test other more complicated rules using member lists or open data units. Using explicit rules has its limitations, however. You can only retrieve (or write) the point-of-view that the explicit rule specifies. If you need to retrieve a large set of data – say, all accrued expense accounts for all entities – you can only imagine how many lines of explicit rules you would need to write.
Using member lists is a more dynamic way of writing rules to retrieve data. This now-common method has proven to be very effective. In a nutshell, member lists are created to identify a more dynamic point-of-view – for example, all accrued expense accounts – rather than the single point-of-view specified by explicit business rules. The writer can then retrieve a large set of data in one fell swoop. As you can imagine, this can be beneficial. The overhead to manage this set of rules is less than explicit rules. In our example, we are retrieving data for all accrued expense accounts. If we need to add another account, the rules might not change at all if the member lists are dynamic. With explicit rules, we would have to creat an entirely new rule for the new account.
One drawback of using member lists is that they return a list of members in a dimension regardless of whether data exists for those members. This means that HFM could use consolidation time to process empty results, thus causing those processes to underperform and be less efficient. This is where opening a data unit has a distinct advantage over simply using member lists. Just like a vlookup in Excel, data units only include records for all intersections that have data for the specified point-of-view. This ensures that HFM is only expending processing power on actual data rather than potentially “empty” intersections. You can see how when calling large amounts of data that this could be an advantage over the member list method.
I have used data units on many occasions to help corral unruly data requirements. I find that they help to lessen the size of an HFM rules file and simplify maintenance for the HFM administrator. Depending on the complexity or sheer number of explicit rules within your rules file, you may see substantial gains in your HFM application performance by using data units. If you don’t already, I highly recommend that you consider the use of data units the next time you are tasked with writing HFM rules requiring the retrieval of large amounts of data. Hopefully you’ll see the benefit of doing so as well.
Brian Willson, a solutions architect for TopDown Consulting, has more than 10 years of experience designing and implementing consolidation solutions. He specializes in custom application configurations such as eliminations, consolidation rules, currency translation, and various allocation calculations.
This was first published in January 2012