Financial Reporting Studio Report Design & Development Considerations

As a standard part on any EPM implementation the output from the culmination of the all project work (requirements, design, development, testing, etc.) is reporting. Typically, prior to an EPM implementation for Planning or Essbase, client reporting is typically performed in Excel spreadsheets. Thru the use of Excel spreadsheets reports are developed and consolidated into a reporting package. Utilizing Excel spreadsheets for financial reporting is fraught with many pain points. Making changes to multiple worksheets within a single workbook is often a tedious and time consuming task as well as the potential for human error in terms of incorrect cell references and worksheet links. I’ve worked with clients who have had to change dozens and dozens of worksheets in preparation for the next budget cycle. This process took weeks and weeks to complete and the owner of this process was never sure that all the spreadsheets were absolutely correct. The lack of flexibility with an Excel-based reporting is significant.

Oracle’s Hyperion Financial Reporting Studio (FRS) relieves companies of this problem. We’ll be discussing high-level reporting strategies to consider when creating reports using Oracle’s FRS.

Report Design Considerations

1) Determine the set of reports to be developed in FRS – this is a critical aspect of report development and should be determined during the requirements gathering process of a project but should be revisited as you move closer to the report development cycle to ensure the report set is still in alignment with the project requirements. In working with clients, the most successful report development phase of projects has been where client have been able to provide a full set of static reports not only for the current cycle but reports for a full year. This will provide you with the ability to determine if there any anomalies or differences between the reporting cycles.

2) Dynamic Reports – the objective should always be to develop dynamic reports because of their inherent ability to reduce maintenance. Dynamic reports should include:

a. Use of Essbase substitution variables. The benefits of utilizing substitution variables include reduced go-forward report maintenance and provides client with the ability to reuse a set of reports for different reporting cycles.

b. Use of relationship members rather than hard-coding dimension members. This will reduce report maintenance when new accounts, dept members, etc. are added to the Essbase outline. Instead of going into every report to update the particular row or column, the new member will automatically incorporate appear in reports. For clients that have a significant number of FRS reports the potential on-going time-savings is considerable.

c. Use of FRS functions. FRS provides a series a pre-built functions that enable report developers to develop reports that are dynamic in nature.

3) Report Consistency – reports should be developed with a consistent “look and feel”. Rows and columns should have a consistent height and width, spacing rows and columns widths should be consistent as well. Fonts should be consistent across reports. Headers and footers should be consistent across all reports.

By following these guidelines during the report developed process, clients will have the ability utilize FRS to its full effectiveness and have in place dynamic flexible reporting that will create more time for analysis of the data rather than the ticking and tying process. In addition, the ability to reusability of dynamic reporting and reduced maintenance and preparation for the future reporting cycles will enable will provide organizations the insight to their business that may not have had previously as well as provide consistent reporting themes across the organization.