Fotolia

Manage Learn to apply best practices and optimize your operations.

How to start redesigning your Hyperion consolidation

As the business world changes, your Hyperion consolidation may need to change. Hoa Pham shows how to separate wants and needs and how to use multidimensional reporting to redesign your Hyperion consolidation.

Over time, as business strategy and reporting requirements change, your Oracle Hyperion consolidations application may need to change as well. When you design and implement a Hyperion consolidation application, there are certain assumptions you have to make looking three to five years -- or more -- down the road. When those assumptions no longer hold true, it's time to redesign.

First, review your Hyperion Consolidations applications. The goal is to gain an understanding of the applicable changes to your consolidation applications, and then to come up with a strategy for redesign.

At the macro level, you will want to look at four different components of the consolidation platform:

  • Infrastructure review: Analyze your software and hardware setup.
  • Application design review: Analyze the design of your consolidation applications, primarily Financial Data Management (FDM) and Hyperion Financial Management (HFM).
  • Business rules review: Analyze the efficiency and relevancy of all calculations.
  • Reporting review: Analyze the design, efficiency and relevancy of report outputs.

At a more detailed level, you need to ask questions specific to your company's needs:

  • What requirement(s) does the consolidation satisfy for the company?
  • Why does the company have the requirement(s)?
  • How does the consolidation help the company meet the requirement(s)?

Answering these questions should give you the framework for a redesign. You've done your review and determined your strategy for redesign. You know what the end result should deliver, so the question now is how to get there?

Fig. 1: Before and after
Fig. 1: Before and after

 Next, begin the process of building the HFM metadata dimensions that support the business requirements. In my experience, there are two major drivers that cause challenges:

  1. There is a lot of information required to build a chart of accounts, an entity hierarchy and various alternate reporting views. There are also many stakeholders involved, all of whose interests are considered.
  2. With multidimensional reporting, failure to adequately understand how different dimensions interact can cause errors in the build.

The key to blunting these two typical challenges is to consider them as interrelated so as to mitigate both negative impacts at the same time. When you first start to build the HFM metadata dimensions, create some dimension matrices that show how the HFM dimensions intersect and provide a blueprint for their reporting usage.

Start with a table at the summary level (Figure 2) showing the Chart of Accounts groups in the rows and your ICP and custom dimensions in the columns. Identify in the boxes the intersections between each of the Charts of Accounts groups and your ICP and custom dimensions. This summary-level matrix shows how much detail you need to build in the account dimension as well as the supporting custom dimensions. For example, let's say you are discussing with the treasury department what cash accounting detail to build into the HFM application. From Figure 2, you know cash accounts from the Assets group will have their supporting detail in Custom1. If Treasury requires cash by bank detail, you might not need to create a separate cash account for every bank because you can store the bank information in Custom1.

Fig. 2: Summary level matrix
Fig. 2: Summary level matrix

Next, expand on the matrix in Figure 2 by adding in the Entity dimension (see Fig. 3). This will show how entity hierarchies work with the intersections of the existing categories. Some HFM applications have entity hierarchies that are used for reporting on specific custom dimensions only. For example, I had a client with multiple entity hierarchies in the HFM Entity dimension, but only one hierarchy had equity accounting business rules. This meant only that particular hierarchy could be used with the Custom4 Data Type dimension.

When you've gotten the dimension matrix well-defined, append notes to identify your major business requirements (Figure 3.) This is important for managing project scope. The matrix becomes a very useful tool for discussing requirements with stakeholders and sorting out what they really need versus what they want. The metadata aligns with meeting the business requirements and helps to determine what is really critical in building out your dimensions.

Fig 3: Matrix with entity hierarchies
Fig 3: Matrix with entity hierarchies

This is the first part of a three-part series.

Next Steps

Learn how to use Hyperion for functional income statements and natural class.

Oracle Hyperion Planning hits the cloud and other news.

Solid data management is key, and products like Hyperion make it look good.

This was last published in October 2014

Dig Deeper on Oracle Hyperion

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide

SearchDataCenter

SearchContentManagement

SearchFinancialApplications

Close