HFM Extended Analytics Integration with ASO Essbase. Speakers: Brian Marshall Jon Rambeau

Transcription

1 HFM Extended Analytics Integration with ASO Essbase Speakers: Brian Marshall Jon Rambeau

2 Agenda Why HFM to Essbase? Why ASO Instead of BSO? Getting Data Out of HFM. Customer Needs. Needs and Challenges. Implementation. Other Options.

3 Why HFM to Essbase Leverage analytical capabilities of Essbase to improve HFM reporting and analysis. The use of Essbase reduces load on the HFM server. Provide actual data for planning applications. Allows for the use of both SmartView and the Excel Add-In.

4 Why ASO Instead of BSO Some calculations are better suited for ASO. No calc scripts, just member formulas for easier maintenance. Dynamic organizational changes without the need to execute additional calculations or aggregations (If an org changes parents, the data follows instantly). Data input using Excel propagates instantly without additional work.

5 Customer Backdrop Oil and Gas Company. BSO model was designed several years prior and was out of sync with their current business requirements. Data loads used reports from HFM. These reports required manual updates to include new accounts. Existing BSO calc scripts required 10+ minutes to execute each time data was input using lock-and-send. Existing meta-data management and data mappings required manual intervention and complex updates.

6 Customer Needs Wanted to send data changes and see instant updates without additional batch jobs. Streamlined meta-data management that removes as much manual intervention as possible. Provide a method of mapping multiple entity dimensions into a single entity dimension without the use of additional tools or load process (e.g. no Excel spreadsheets to send around and attempt to maintain). Load most data from HFM with just a few pricing structures from flat files. Do this without any additional software investment.

7 Challenges Meta-Data Challenges Current methodology required a series of s, files sent around, updates to reports, and a variety of other bad ideas. Investigated several products including ODI, Data Fusion HFM Extractor, and Extended Analytics. Need to map two entity dimensions into one. No new software investment! Data Challenges Any method of extraction had to be better than using a manually maintained report. Flat file exports in HFM don t include all the data, namely Journal Entries. The value dimension is not present in the flat file exports, meaning all data exports in entity currency. This would require additional currency conversion logic. Eliminations and other calculated values are not always stored at level 0 (this challenge is ASO specific). No new software investment!

8 How did we do it? After the dust settled from our research and testing, we determined that there was only one viable option without purchasing new software Extended Analytics ( EA ). Meta-data for all dimensions was available using EA. All data, including journal entries and the value dimension, was available using EA.

9 How did we do it? Because of the need to do data mappings, we devised a unique way of allowing administrators to use just EAS for this task. An ASO model was developed with the pertinent dimensions, data, and meta-data loaded directly to it. Mappings were handled by an additional dimension with a base member to store data and additional dynamic members using MDX. The MDX mappings were very simple and quite fast. This provided the client with not only a simple and effective mapping mechanism, but an additional method of analysis for HFM. In addition, server load was not increased and the users were able to utilize both SmartView and the Excel Add-In.

10 How did we do it? The intermediate cube feeds the analysis cube.

11 How did we do it?

12 How did we do it? After we selected EA, we began working heavily with the meta-data tables provided in the export. A star schema was created by EA, but boy was it ever ugly! The meta-data exported from EA did not come out in the proper order. Children appear before parents causing many interesting issues.

13 The parent child view: How did we do it?

14 How did we do it? Extract data using EA But what about upper-level members in ASO? Because ASO can only store data at level 0, upper-level data had to be handled differently. Accounts where data was stored at upper-levels were isolated in EA (such as Eliminations). Members were added to the ASO cube to store this upper-level data in the appropriate places. Views were created on top of the EA schema that isolated the upper-level data and allowed for two separate loads level 0 data in one load and upper-level data in the other.

15 The Final Product Initial data loads from HFM to ASO staging area to final ASO model took approximately 10 minutes. Changes to most data elements would allow reports to be instantly updated. Data could now be updated automatically with a single script. New accounts and entities would be added automatically. Mappings could be handled using EAS without maintaining spreadsheets or other load files or tables.

16 The Final Product

17 Essbase Analytics Links Other ways to solve the problem Managed entirely in EAS. Like Extended Analytics, the data is stored in a relational database separate from HFM. Generates outlines with synced meta-data including all desired dimensions. Creates a transparent partition in Essbase allowing it to be used in either ASO or BSO. The data can be near real-time if necessary or set to update at later times.

18 Q&A