My clients often wonder which Oracle tool they should use for reporting, building graphs, and generating dashboards. It’s a great question because, as anyone in this realm knows, there are many different options. This blog will touch on the three reporting tools I’m familiar with: Financial Reporting Studio (FRS), Web Analysis (WA), and Oracle Business Intelligence Answers (OBI).
One caveat here is that the bulk of my experience comes from the Oracle Hyperion side, so I have much more familiarity with FRS and WA, and definitely less so with OBI. So, this blog will be written from that perspective.
Below, I’ll give a synopsis of what each tool does, based on my experience, followed by my opinion of when each should be used.
Financial Reporting Studio
FRS is a great tool for producing regular reports, like a monthly reporting package. It allows you to create production level reports with a multitude of formatting options. FRS reports can be viewed in PDF or HTML format, from a client component or over the web. Reports can be gathered together in Books and batch scheduled to run at the frequency of your choosing, and then saved to a particular location or emailed out to a list of users.
FRS is not a tool for producing dashboards, is limited in its chart and graph functionality, and would not generally be used for ad-hoc reporting.
Web Analysis
WA comes from the Hyperion suite of products as the tool for building dashboards. In my experience, it’s most often used to create quick snapshots of data for management or executive level users. WA allows you to create multi-view looks at your critical business metrics, either in graphical or grid format. For example, a dashboard might include a line graph of sales by region in one quadrant, a bar chart of sales by VP in another quadrant, a pie chart of expenses by category, and a grid showing spending by department. WA includes traffic lighting as a feature, allowing you to highlight or color significant variances of data.
WA would not be used for production reporting.
Oracle BI Answers
OBI Answers is a tool for building both reports and dashboards from a variety of sources including relational and multi-dimensional databases. You can build similar dashboards to what WA offers and publish reports similar to what FRS offers. The entire OBI suite has pre-built modules by industry that allow for easier implementation depending on the particular business case.
While OBI Answers can use Oracle Essbase as a data source, there are some issues in doing so that prohibit the use when a particular hierarchy exists. This should be addressed in an upcoming release, but at this point, the OBI link to the Oracle Hyperion suite of products is very limited.
Which Tool?
So, which reporting tool should be used when? With the current releases and functionality available, here is how I would use them:
FRS – Use for regular production reporting such as income statements, operating expenses, headcount, and any other meaningful financial metrics from an Oracle Hyperion data source such as Essbase, Planning, or Financial Management. I generally don’t create charts and graphs using FRS because the options and functionality are fairly limited. But, if you have fairly straightforward and simple chart requirements, then FRS should work fine for you.
WA – I would use Web Analysis for producing grid and chart dashboards from an Oracle Hyperion data source. WA does a good job of incorporating “bells and whistles” that make a dashboard “pop”, providing important metrics quickly.
OBI Answers – OBI is a great tool to use to quickly build reports and dashboards from a data warehouse. In my opinion, this is the easiest tool to learn and use of the three. As I mentioned above, I don’t think it’s currently the right tool to use with Oracle Hyperion data sources, but that very well could change in the near future.
Going Forward
In future releases, I think that OBI will become the tool of choice for reporting and dashboarding, even for Oracle Hyperion data sources. Oracle is very good at creating synergies between their product lines, and while each individual application generally has their own set of tools, eventually, they converge to similar toolset technologies. I think as OBI gets more integrated with the Oracle Hyperion suite of products, it will become the tool of choice for reporting. In my opinion, it is easier to both learn and use compared to both Financial Reporting Studio and Web Analysis.
OracleBIBlog Search
Friday, March 26, 2010
Which Tool Should Be Used for Reporting?
Friday, February 26, 2010
The Impact of IFRS for EPM Reporting – Part 6
In Part 6, I want to provide more detail on the similarities and differences for reporting Financial Instruments. The details below were from notes I took during a presentation during a company sponsored educational seminar about IFRS.
Financial Instruments
Similarities
Both require financial instruments to be classified into specific categories to determine measurement
Both require the recognition of all derivatives on the balance sheet
Hedge accounting is permitted under both
Both require detailed disclosures in the footnotes Differences
Fair value measurement
- US GAAP – one measurement model (FAS 157) based on exit price
- IFRS – various standards use slightly varying wording to define fair value – transaction price at inception date is generally considered fair value
Use of fair value option
- US GAAP – financial instruments can be measured at fair value with changes in income
- IFRS – financial instruments can be measured at fair value with changes in income, when certain criteria (more restrictive) are met
Differences
- US GAAP – can recognize day one gains on financial instruments even when all inputs to the measurement model are not observable
- IFRS – only recognized when all inputs are observable
Debt vs. equity classification
- US GAAP – certain instruments with characteristics of both debt and equity must be classified as liabilities
- IFRS – classification focuses on the contractual obligation
Compound (hybrid) financial instruments
- US GAAP – not bifurcated into debt and equity components, but may be bifurcated into debt and derivative components
- IFRS – required to be split into a debt and equity component, and if applicable a derivative component
Hedge effectiveness – short cut method
- US GAAP – permitted
- IFRS – not permitted
Hedging a component of a risk in a financial instrument
- US GAAP – risk components that may be hedged are specifically defined – no additional flexibility
- IFRS – allows entities to hedge components of risk that give rise to changes in fair value
Impairment recognition – available for sale debt instrument
- US GAAP – may have an impairment due solely to a change in interest rate if the entity does not have the positive ability and intent to hold the asset
- IFRS – generally only evidence of a credit default results in impairment of an AFS debt instrument
Convergence
Wednesday, February 10, 2010
The Impact of IFRS for EPM Reporting – Part 4
In Part 4, I want to provide more detail on the similarities and differences regarding: Business Combinations and Inventory. The details below were from a presentation I viewed during a company sponsored educational seminar about IFRS.
Business Combinations
Similarities
- All accounted for using the purchase, or acquisition method
- Recognized at fair value, but currently differing definitions of fair value
- Acquisition date is the date that the acquirer obtains control
- Contingent consideration recognized at fair value at acquisition date, subsequent changes in earnings
- Negative goodwill recognized immediately as income
- Acquired in-process R&D recognized at acquisition date fair value
- Restructuring liabilities only recognized if criteria have been met, and is recognized at the acquiree level at the acquisition date
- Net identifiable assets of acquiree are recognized at their full fair value
- All transaction costs expensed as incurred
Differences
Acquisition of less than 100% of acquiree
- US GAAP – noncontrolling interest is measured at fair value, including goodwill
- IFRS – Choice of measuring noncontrolling interest at either full fair value including goodwill or at its proportionate share of the fair value, exclusive of goodwill
Inventory
Similarities
Same principle that the primary basis of accounting for inventory is at cost
Both define inventory as assets held for sale in the ordinary course of business, in the process of production for such sale, or to be consumed in the production of goods or services
Permitted techniques for cost measurement, such as standard cost method or retail margin method are similar
Cost of inventory includes all direct expenditures to ready inventory for sale, including allocable overhead
Differences
Costing methods
- US GAAP – LIFO permitted
- IFRS – LIFO is prohibited
Measurement
- US GAAP – carried at lower of cost or market
- IFRS – carried at lower of cost or net realizable value
Reversal of inventory writedowns
- US GAAP – cannot be reversed
- IFRS – can be reversed up to the amount of the original impairment loss
Thursday, January 21, 2010
Automating Your Reporting Package in Hyperion
Putting together your monthly, quarterly, and annual reporting packages is menial enough, but if that process is done manually, it makes it all the more tedious. Especially if, in a worst case scenario, you’re having to consolidate, reconcile, and update individual spreadsheets and print those off one-by-one….
Hyperion Workspace provides a great solution to remedy this problem through its inherent batching and scheduling functionality. This feature set allows you to collect reports into a book, batch reports and books, and schedule them for a variety of output. Following is a brief rundown of the scheduling process.
First off, you will need to decide whether your reports should be gathered into a book. Books generally consist of logical sets of reports and/or report snapshots. A report snapshot is a picture of a report on a specific date and time and does not dynamically link back to the source database. You might see a book gathered by category (monthly, quarterly, annually), by scenario (actual, budget, forecast), or by functional area (sales, engineering, administrative). It all depends on business need and logical groupings.
Books have their own point of view (POV) that allow you to override user or grid POVs. For those who aren’t familiar with Hyperion POVs, in a report, a POV is a single dimension member that applies to the entire report. From a report perspective, you have dimension members in rows, columns and the page. Any dimensions not included in the row, column, or page fall to the POV and any dimension in the POV can only have a single member selected. A grid POV applies to a grid in a specific report, whereas a user POV applies for a specific user across multiple reports. So, as an example, if you wanted to run all reports for the budget scenario for 2010, you could override report selections by using the book POV. Books can also be set up with prompts, allowing member selections to occur when the book is run.
Finally, books have a table of contents feature, enabling you to show and/or print out a listing of the reports included in the book.
The second step would be to create a batch. A batch can include items such as individual reports, report snapshots, and books. The batch is required in order to schedule reports for output. Also, if reports or books included in the batch contain prompts, members can be selected for those prompts as part of the batch set up. Like a book, a batch has its own POV that can override the POVs of its included objects.
The last step in automating your reporting package is to schedule the batch. The batch scheduler allows you to generate output immediately or on a specified date, time, and recurring frequency. Oftentimes, what I’ll see clients do is run their scheduled reports afterhours, so the processing time occurs while end users are out of the system. From a performance standpoint, this is optimal since the batch generation won’t compete with end users for system resources.
A newer feature of batch scheduling is bursting. Bursting allows you to enable reports to be run for multiple POV members. As I mentioned above, the POV is a single dimension member applying to a particular object. Bursting lets you choose multiple members and then runs the batch output for those selections. This would be useful if, for example, you wanted to run both budget and actual reports or reports for the western, eastern, northern, and southern regions.
The next batch setting is the output. You have the following options:
• Generating a report snapshot saved in the reports repository. A nice feature here is that you can set permissions to the output as part of the batch scheduler.
• Printing output.
• Exporting the output in PDF format to a shared directory and/or as an email attachment. This can be especially useful for users who do not have an ID set up in the application.
• Exporting the output in HTML format to a shared directory.
Finally, you can set up the batch scheduler to send an email if the batch generation is either successful or unsuccessful.
In terms of the mechanics for setting up books and batches and scheduling them, it’s fairly straightforward. All of these items are created in Hyperion Workspace. For books and batches, that’s done through the File -> New -> Document menu option. To schedule batches, click the Navigate icon and go to Schedule -> Batch Scheduler.
Once all your reports, books, and batches have been set up and scheduled, you really should have a self-sustaining system with dramatically decreased cycle times.
Monday, January 11, 2010
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.
Posts
