Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« Innovation in Siebel | Main | BCMS PHASE 1 »

HFM solution design: What can be an ideal design and what needs to be considered


A lot is spoken about cloud solutions and there are numerous debates about the pros and cons about cloud vs on premises implementation. A lot of focus is on security, maintenance cost, performance and many more issue. Irrespective of which way the decision goes, the functional solution, or if I can say the problem addressed remains the same i.e. efficient handling of Consolidation and Reporting cycle. So in this discussion let us focus on the functional solution design.

What can be an ideal solution design will depend on the clients outlook and requirements. So for convenience of discussion I will like to divide the solution design in 3 categories,

  • Light N Easy,

  • Comprehensive but Complex N Heavy,

  • Something in between.

Light N Easy: A light N Easy solution design can be a design which may have all or most of the characteristics below: 

  1. Translation is done in source system so HFM is having a single currency application.

  2. Translation if at all done in HFM will be restricted to Spot and Average rate translation.

  3. Elimination done external or using JV's functionality available in HFM, instead of using HFM elimination engine.

  4. Simple data aggregation and reporting using HFM consolidation engine with no other consolidation requirement standard or non-standard.

  5. Simple business rules like posting of profit to B/S, roll forward of balances, simple rounding etc.

  6. Simple TB upload using FDMEE

  7. Input additional data using data forms/Smart view

  8. Reporting using FR reports/Smart view.

A light and easy design will be more appropriate for clients:

  • Wanting a quick rollout and an early payback period.

  •  Having a very complex current system and need to sum up the position before committing to a bigger solution.

  • Wanting to test water before deep diving and getting the organization ready for the big change.

  • Having an effective transaction system and can handle some functionalities out of the consolidation process. Having said that:

    • This may not be the case every time for this decision.

    • A question may arise that if the existing system is efficient why not handle consolidation in that system instead of having a separate system. (The argument in favor of HFM is that it is much robust and specialized consolidation tool - But this is not the current topic in discussion).

Comprehensive but Complex N Heavy: A comprehensive design will mostly use most of the functionalities HFM is capable of handling, (and my experience says that with smart design HFM can handle a lot of consolidation and reporting functionalities, standard or non-standard).

So I will say a comprehensive solution design can handle all or most of the following functionalities:

  1. Translation & eliminations.

  2. Ownership data management and use of relationship between holding and subsidiaries to have multiple methods of consolidation.

  3. Multiple reporting hierarchy. Eg Reporting, Management, Multiple accounting standard.

  4. Consolidation requirements like Minority Interest, UPOS, Goodwill calculations.

  5. Foreign currency translation reserve (FCTR) calculations.

  6. Progressive rounding.

  7. Local and Global COA.

  8. Complex reports like Cash flow statement (Indirect/Direct method).

  9. FDMEE for TB and additional data load

  10. Use of FCM for close process

  11. Use of DM for reporting and printing.

A comprehensive design will be more suitable for clients:

  • Having very stringent reporting/compliance requirements and who publish consolidated results.

  • Having/aiming a short closing cycle.

  • Having very matured and set reporting processes.

  • Having the time window to implement comprehensive solution.

Somewhere in between:

 This kind of design will have a combination of both the above approach. There will be always a give and take between the functionality and the time available for implementation. For this approach I will advocate to divide the requirements in

  1. Must have

  2. Good to have

  3. Can live without it.

This will give a platform to plan for a robust futuristic design. And the implementation can be easily divided in phase with clearly identified outcome.

Once the deliverables are chalked out and signed off then the design process can start. Here I will mention that everybody, I mean everybody, is tempted to start the design before the requirements are frozen and signed off. Time allocated to design also add compulsion to start early.  

You would have noticed, at the beginning I have specified efficient handling of Consolidation and Reporting cycle, and not best handling. A design should be optimum and based on the needs of the client and not on what is available and/or what can be achieved using HFM. An optimal design will:

  1. Take in to consideration the clients need and the complexity of the data.

  2. Time window for implementation.

  3. Client and end user preparedness and training requirement.

In interest of keeping this discussion relatively short, I will not go in details of HFM solution design but will like to mention some important inputs/constraints to be considered before starting. (I will clarify that this is not an exhaustive list, the list will change based on the client requirements and design chosen.)

  1. YTD data or MTD data.

  2. Based on the above, additional data, moments and roll forward of balances can be planned. If the frequency of data load is not monthly then consider impact of ZeroViewForAdj/Nonajd.

  3. Type of consolidation to be done? 100% consolidation with MI calculation or proportionate method? Equity method if required and the logic and accounts related to it. If MI is required which node of Value dimension to calculate MI, Parent or Contribution level? i.e. pre or post eliminations? Capture of pre-acquisition and post-acquisition profit and reserves to calculate Good will/Capital reserves.

  4. COA, Entity hierarchies and custom dimension. Caution should be exercised while deciding the custom dimension as data may not be available at the granularity at which the client desire the reports. It's a good practice to club all mutually exclusively custom dimensions in one dimension.   

  5. Rounding requirements.

  6. Adjustments requirements in case of multiple hierarchies and shared members.

  7. Standard translation, historical rate translations and calculation of FCTR.

  8. How to build BAU process around the application


Food for thought:

While the above will help in design for a futuristic design it's always good to think about certain issues well in advance. Though they may or may not be part of the solution design let us put some though on:

  • How to handle change in hierarchy.

  • Reconciliation post change in hierarchy.

    • What will happen if entity is shifted from one hierarchy to another hierarchy?

      • If Missing data is MTD or YTD

      • Recalculation of reserves

      • Impact of recalculation of reserves and recalculation of FCTR

  • Rounding. Simple rounding or progressive rounding.

  • Cash flow : How to handle cashflow without hard coding the rules

As you think on it I will also share my thought on some of the topics in my next blogs. Till then keep consolidating J.


Very informative and knowledgeable blog. Want to read many more such blogs.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles