1 / 21

Moving Data within a Planning Application at Avago Technologies

Learn how Avago Technologies implemented a Hyperion Planning application to enhance efficiency in budgeting, forecasting, and financial reporting cycles.

lerica
Download Presentation

Moving Data within a Planning Application at Avago Technologies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Moving Data within a Planning Application at Avago Technologies Audrey HolifieldProject Manager, FP&AAvago Technologies Patrick LouieDirectorHackett Technology Solutions

  2. About Avago Technologies • Leading global manufacturer of optoelectronics and analog interface components • Former semiconductor business of Agilent Technologies • $1.6B in annual revenue • Primary Locations: California and Singapore • Primary Finance Locations: California, Singapore and Malaysia

  3. About Hackett Technology Solutions • Provide Professional Consulting Services for all of Oracle’s Hyperion suite of products • Publicly traded on the NASDAQ (symbol: ANSR) • Formerly known as Answerthink • #1 Hyperion Americas Reseller Award at Solutions 2006 and 2007

  4. Agenda • Introduction • Main Considerations for Design • Issue 1 – Workforce Inputs • Concerns • Solution • Issue 2 – Functional Reporting • Concerns • Solution • Closing • Q&A

  5. Introduction • Avago Technologies decided to implement a Hyperion Planning application to enhance the efficiency of its budgeting, forecasting, and financial reporting cycles for both the Income Statement and Balance Sheet. • Three databases deployed at Avago: • Workforce (Employee level planning) • FINSTMT (Annual Operating Plan at account, department and country level) • FCST (Forecast and monthly reporting at summary level)

  6. Main Considerations for Design • Performance • Simple for users • Supports user analysis and reporting needs

  7. Issue 1: Workforce Inputs • Finance users making salary and benefits entries to the Workforce database • Need to see the effects on the Income Statement in the FINSTMT database • Waiting for scheduled batches to transfer data from Workforce to FINSTMT would slow down the planning process

  8. Concerns • Scheduled batches would have to be broad in scope and would affect performance while the batch was in process • Run-time prompts could lead to human error • Users could forget to run scripts to transfer data, leading to expenses not populating in FINSTMT as expected

  9. Solutions • Hyperion Business Rule that utilized the @XREF function to transfer data from Workforce to FINSTMT • Using Variables in the HBR that could take the POV from the form so that only the members that were being written to were transferred; the changes were then aggregated up in FINSTMT with the @ANCESTORS function • HBR wasset to ‘run on save’ in the input form

  10. Workforce Input form with Business Rules

  11. Issue 2: Functional Reporting • Operating expense accounts jointly used by all functions at Avago (i.e. people and project expense account numbers) • Functions appear at in different sections of the Income Statement (i.e. R&D is function 2, Marketing is function 4) • Previous application used by Avago was set up for a unique account and function combinations, which created 5x number of expenses accounts (i.e. 800001 – FN1, 800001 – FN2, etc.) • Need an intuitive solution so users can easily enter expenses and have them appear in the correct section of the Income Statement without complicating the account structure

  12. Function breakout on Income Statement

  13. Concerns • Having same accounts appear at different points on an Income Statement hierarchy could create duplicate data • Relying on all users to use Account and Function combinations in reporting and analysis is cumbersome and risky • Need database to correctly calculate the various subtotal values of the Income Statement (i.e. Cost of Sales, R&D, Admin)

  14. Solution • Create custom accounts dedicated to each function that could be placed at different points in the Income Statement hierarchy • Create People Expenses, Project Expense and Absorption accounts specifically for each function

  15. Custom Functional Accounts

  16. Solution • Create custom accounts dedicated to each function that could be placed at different points in the Income Statement hierarchy • Create People Expenses, Project Expense and Absorption accounts specifically for each function • Use member formulas to copy level 0 data for department and geography from each of the specific functions

  17. Custom Functional Account Member Formulas

  18. Solution • Create custom accounts dedicated to each function that could be placed at different points in the Income Statement hierarchy • Create People Expenses, Project Expense and Absorption accounts specifically for each function • Use member formulas to copy level 0 data for department and geography from each of the specific functions • As a maintenance and scaling compromise, detailed analysis on those expense accounts would be done at an Account/Function level

  19. Shared Accounts

  20. Closing • Solutions were efficient to not slow down the planning process • Users were not required to use a complex process to enter data • Structure supports reporting requirements

  21. Q&A

More Related