Key Success Criteria for Hyperion Planning and HFM Integration
•Download as PPT, PDF•
10 likes•10,773 views
Chris Churchill, Practice Director at Edgewater Ranzal, presents on the key success factors for Hyperion Planning and HFM integration projects.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Key Success Criteria for Hyperion Planning and HFM Integration
Similar to Key Success Criteria for Hyperion Planning and HFM Integration (20)
More from Alithya
More from Alithya (20)
Recently uploaded
Recently uploaded (20)
Key Success Criteria for Hyperion Planning and HFM Integration
- 1. Key Success Criteria for Hyperion Planning and HFM Integration Chris Churchill, Practice Director Ranzal & Associates
- 2. Quick Audience Poll - Do you use HFM, Planning or Both?
- 8. Use Each Tool for What It is Best At!
- 10. All Comes Down to Business Requirements!
- 26. DRM and EPMA have a Complementary Relationship
- 27. Data Integration
- 37. Reporting
Editor's Notes
- Stress that many companies used Essbase to close the books prior to the advent of HFM. Many early Ranzal customers hired us to build out a complex consolidation routine in Essbase. Robust calculation engine allowed for this, but lacked a lot of the audit trail features needed for SEC reporting, especially after SOX was instituted.
- When taking on an integrated EPM project, these are some of the key areas that need to be assessed. Are any of these things changing in addition to the technology change? For example, as part of the technical implementation of HFM, is the organization also embarking upon defining a standard chart of accounts? If so, this changes the approach, requirements and design. For planning, are you looking to replicate existing functionality, but in a formalized planning tool – or are you looking to completely redefine your planning process?
- There is no silver bullet. No definition of the “right way” to integrate and do things. Each client has a unique set of requirements and challenges that will ultimately dictate the best approach for implementation. The key is understanding how the requirements relate to the technical aspects of the implementation, and which requirements drive potential complication in an implementation. Ryder / Avon will look MUCH different than Superior Energy, or Apollo Group Let’s look at some of the key requirement questions facing a multi-prod implementation
- Solution Architecture – The glue that holds the application together. Far reaching concepts that are applicable across the board. These will impact FM & Planning, and should be vetted early in the requirements process.
- Single biggest point of failure in an EPM implementation. First piece of the puzzle, often short sighted in nature. Hard to change later in the game if not properly architected out of the gate. Can start small and give room to grow, but need to make sure a proper plan is put in place to achieve this.
- Maintenance – One set of metadata to share across applications. Shouldn’t need two accounts dimensions to support FM vs. Planning. Note additional levels of detail might be required across apps, but basic structures should hold. Example – at the end of the day, a financial P&L is likely the end game for a planning cycle. This P&L should be defined by an account structure that is laid out in HFM. There might be an additional level of detail gathered in HFM, but the upper levels of the hierarchy should remain consistent. Common Definitions – Finance users that live in the Workspace / Smart View will likely bounce back and forth between Planning, Essbase, and HFM. It is important to standardize naming conventions, definitions, etc to simplify the end user experience. Reports should exist in such a manner that the back end that the user connects to is irrelevant. Integration – When it comes time to move data between Planning & HFM, common naming conventions will greatly simplify the process. Don’t want to add an additional layer of mapping if it is not necessary
- Value Dim – Depends on needs. I would argue that you just need the final consolidated – Contribution Total. Have had clients pull each piece of the value dimension in for reporting. Usually this is in Essbase friendly shops that are used to navigating using Essbase / Excel.
- Typically shared dimensions have some sort of metadata interface to a source system – a general ledger, a data warehouse, etc. that manages defintions, hierarchies and attributes about a dimension. These can be fed into EPMA, DRM, or Classic. Standardized dimensions are ones that are typically not updated frequently. Don’t add a whole lot of new months or scenarios after the initial build is complete. Attributes and hierarchies don’t change much. SHOULD STILL STANDARDIZE NAMING CONVENTIONS
- Build out metadata into each application separately. Planning – Outline Load Utility HFM – ADS Files Use Case – No plans to ever move beyond a single application. Do not own Planning AND HFM. One HFM app, or one Planning app.
- Stability comes in 11.1.1.3 To automate, have to update Interface Tables. Interface Tables need to be populated via an ETL process. This can be ODI, SSIS, Informatica, etc. Can convert from Classic to EPMA Will walk through process in a couple slides – when talking through DRM
- DRM – A tool to manage metadata – not just for Hyperion Apps. More robust security profile for users. Good fit if there is no manner to manage hierarchies.
- DRM creates files to load into the EPMA Interface Tables. NOTE – DRM cannot “LOAD” Interface tables. It only creates the file EPMA Interface Tables loaded via an ETL process…. Once Interface Tables are loaded, can be imported into EPMA. Once in EPMA, schedule deployment to the different EPM applications that have those dimensions. Deployment is managed at the application level – different timing requirements across apps.
- Financial data usually serves as the backbone of FM / PLN implementations. Typically PLN will require additional data elements – HR, Detail Sales & COS Metrics, Capital Expenditure Data Focus here on common data
- Caveat – FDM is not a data warehouse. Loading millions of records to FDM is not its strong suit. Need to think through the usage of FDM with regards to additional Planning work streams (outside of financial data)
- If FDM is not in play, or doesn’t make sense for a set of data, other ways exist to integrate data. Planning – Might not want to bring in relational sales data – millions of records… Could use a number of other methods to integrate directly with Planning / Essbase. FM – Perhaps FDM is overkill for collecting data from a sub. Suppose you just need three numbers a month, could provide them a form in HFM to collect instead of deploying FDM processes.
- Define Consolidated Data again vs. aggregated data
- Essbase natively wants to add things up in a linear nature HFM allows adjustments at upper levels, where detail doesn’t agg to parents. This poses a challenge to old school Essbase folks who like to load data to level 0 and aggregate.
- Hyperoll tool – new, very powerful Automated move of HFM data into Essbase cubes. Maintains the upper level adjustments where necessary. Instead of moving into relational EA tables, loading into Essbase cubes. Link these cubes via partitions to Planning. Lots of potential, but fairly new product. Costs $$
- Don’t want to rewrite eliminations, minority interest calcs – currency effects of these elements… in Essbase… Could require intense calc scripting, and would lead to duplicate maintenance. Not handled by Calc Manager. Calc Manager has different language for Essbase / Planning vs. HFM. Calcs are not transferable between apps. Consolidation logic in FM Currency Translation in both FM & PLN