By TopDown Team
December 21st, 2011
A common question that arises when designing an application/system dedicated to business analysis/planning is the level of granularity deemed optimal for the application.
This question arises especially with regard to level of detail for the GL accounts and Products dimension (element) because, in many organizations, different entities (cost centers, departments) budget or plan at different levels of detail. For example, some departments/cost center may budget Travel Expense at a summary account level, while others for whom travel is a major cost element may want further break down of the Travel budget elements. Also when planning revenue and cost of goods, most organizations apply the 80/20 rule and will budget at a detail level for the highest revenue generating products (which may represent 20% of their total product portfolio) and at a group level for the remaining products.
The approach chosen, (summary or detailed level planning), does indeed influence the design of the application/system and ultimately performance.
A design built around a detailed chart of account and product dimension could result in a very sparse database with a low-density record set, meaning that each record could have many blank fields – like a Swiss cheese. Despite their low-density, the record set still take up valuable RAM (memory space) and therefore impact performance.
Analysis of the Issue
The issue has become more prevalent because more organizations want a central repository that can house Actuals and Budget/Plan data for management reporting and business analysis.
Since most managers like to have as much detail as possible on Actuals data, this desire tends to sway the decision in favor or an application with a high degree of granularity, which can create performance issues during the planning cycle.
Best Practice Recommendation
The best practice recommendation is one that addresses both the planning and management reporting needs of an organization in the most efficient way.
In my opinion, the ideal platform is one that can accommodate summary level and detailed level data capture/input capability within a single application.
Oracle-Hyperion Planning, one of the leading performance management tools, can accommodate up to five design specific databases within a single application. This number assumes initialization of the two custom modules (databases) i.e. Workforce Planning and Capital Expenditure planning that are packaged as part of Oracle-Hyperion Planning and come with pre-built, process specific functionalities and business rule templates.
Thus, in addition to the custom databases, one of the databases could be designed to optimize planning activities (i.e. a Planning Database) at the appropriate level of granularity, and the other could be optimized for reporting (i.e. a Reporting Database) at a more granular level for storing Actuals and imported Budget/Plan data.
This still leaves room for one more database that can be designed to plan other activities that may require yet another level of detail, e.g. customer-based activities for sales/revenue, etc. Or the database could be designed to plan and monitor construction costs, R&D expenditure, clinical trials, spending by vendor, etc.
Since all databases are accommodated within a single application, they could be linked automatically to keep them in synch.
Oracle-Hyperion Planning also supports the capability, for those who are interested in knowing the details behind the summary actual number, to drill through to the supporting details in the transaction database.
Thus, Oracle Hyperion-Planning is really designed to support efficient and optimal Business Analysis/Planning and Account Analysis from the same application.