HFM Dimensionality

What is HFM Dimensionality?

Key attributes of HFM ( Hyperion Financial Management ) include global consolidation features, a scalable web architecture, unlimited dimensionality, complete audit trail, robust reporting and analysis tools, and data integration.

With the latest release of HFM (Version 11.2), there are functional aspects that have changed from Version 11.1.2.4. Metadata and dimensionality can no longer be managed via EPMA ( Enterprise Performance Management Architect .) EPMA has been discontinued, however, at this time there are two options available to manage dimensions:

• 1. Classic - via the HFM client metadata manager
• 2. DRM (Data Relationship Management) - included with HFM 11.2 is a free restricted use license for DRM. An application can be made in DRM using the supplied HFM template.

On the horizon, Oracle has referenced a Native Metadata Manager with details to follow.

With HFM, a company has the added benefits of increased dimensionality (over Hyperion Enterprise- HE). HFM provides system predefined dimensions and an organization can create virtually unlimited custom dimensions (the number is limited to the maximum limit of the database and Oracle allows a greater number than MS SQL). Custom dimensions are associated with the Account dimension and provide additional detail about accounts.

When deciding how many custom dimensions to create it is important to know that technically speaking there is no ideal number of dimensions separate from the requirements of the business. Usually, the ideal number is the smallest number of dimensions, which handles all the business requirements. When considering performance, although the system has been updated to better tolerate a multitude of dimensions, the system's usability is increased with fewer dimensions.

Ultimately it is better to create fewer dimensions because it will be easier for the user to navigate within the product. Establishing a point of view is easier to for a user to do when there are fewer dimensions to select. When possible, it is an option to use the same dimension for different types of details, and then using the top member attributes in accounts to define the correct intersections.

There will be fewer dimensions to use in Journals, Reports, Grids, Web forms, Smart View. Thus, when contemplating the design of the application the number of custom dimensions depends on the details inherent in reporting requirements. When the same detailed analysis exists for multiple accounts, this detail should be created in a custom dimension. For instance, if Sales, Cost of Sales, and Gross Margin must all be detailed by each product, then it is prudent to create a Product hierarchy in a custom dimension. When an account must also be analyzed by a combination of details, for instance, Sales by Product and also simultaneously by Vendor, then these details should be created in separate dimensions. When more analytical details are required, more dimensions will be necessary. For instance, if Sales, Cost of Sales, and Gross Margin must be analyzed simultaneously by Product, Vendor, Department, and Acquisition Company, then it is advised to use 4 custom dimensions.

Use caution, however, because it is not possible to remove unused dimensions after the application has been built. A new application must be created. Yet on the contrary, if the reporting needs of the organization have changed, it is possible to add new dimensions to the existing application.

Recent Articles

Case Studies

Related Links