Key Considerations for a Successful Hyperion Planning Implementation

UKOUG EPM & Hyperion Conference 2011 Key Considerations for a Successful Hyperion Planning Implementation Edgewater Ranzal UK Division Mike Killeen Vice President, Oracle Ace & Mija Deering Principal Solutions Manager Slide 1

Agenda KEY PROJECT PHASES RECOMMENDED BUILD TECHNIQUES – Application Definition & Plan Type Delineation – Define Dimensionality – Master Data & Data Integration – Building a Planning Model – Development of Forms – Development of Calculations – Process Flow / Control – Define Security – Tuning, Optimization & Maintenance – Typical Customization TEN ELEVEN PLANNING TIPS TO REMEMBER Slide 2

About Edgewater Ranzal Focus Services 15 Years People 700+ clients 1000+ projects Methodology Customers Partnership Slide 3

Quick Audience Poll • Rolled out Planning? – Pre System 9 – System 9 – Fusion • 11.1.1.x • 11.1.2.0 • 11.1.2.1 • In the midst of a Planning project? • About to embark on a Planning project? • Are IT or Finance Professionals? Slide 4

Key Project Phases Slide 5

Ranzal Project Lifecycle Overview Project Planning & Management Approach Pre-Engagement Project Initiation Project Execution Project Closure Proposal & Kick-Off, Logistics, Manage schedule, scope, issues, risks, cost & Successes & Statement of Work Coordination & Plan resources – status reporting Lessons Learned Implementation ApproachFocus Points• Multiproduct Analyze Design Build Test Rollout / Sustain Experience• Knowledge Install, Configure & What is Wrong, What & How to Infrastructure, Training, Transfer Right & Needed Deploy Unit Test System Integration & Documentation &• Performance Acceptance Testing Knowledge Transfer Benchmarking• Understand Priorities Change Management Approach• Flexible Approach Plan/Scope Assess/Design Build Deploy Monitor• Modular Scope• Prototyping Define the Define Future Prepare for the Facilitate the Monitor the• Leverage Change and Organization and Change Change Results Prior Work How to Manage Understand Impact Slide 6

Typical Implementation NEEDS ANDREQUIREMENTS PLAN AND CUSTOMIZED GO LIVE AND ANALYSIS DESIGN PHASE BUILD PHASE TEST PHASE TRAINING ROLLOUT SUPPORT• Current state and • Define a project • Construct • Upload test data • Develop easy to • Review Go Live stakeholder needs roadmap templates and use reference Checklist • User validation analysis • Determine models guide • Move solution • Calibrate models• Identify process, optimal level of • Report / dash- • Develop custom into production system, and detail and board build-out • Document final training and • Provide on-site organizational structure process, system, exercises • Prototype org support components • Design docs reviews • Deliver user • Semi-annual • Detailed work • Develop data training audits and plan with interfaces process/model deliverables reviews Slide 7

Analyze vs. Design Analyze Design Requirements unknown or undefined Key requirements are understood Existing business processes need to be updated Future business processes are Existing business processes not known or known documented Basic understanding of technology Desire to re-engineer to align with being used for build business vision or industry best practices Deliverables As-Is vs. To-Be Processes Functional Requirements Deliverables Technical Requirements Design Document Project Roadmap & Timeline (High Level) Proof of Concept / Prototype * Infrastructure Architecture Finalize Scope, Schedule & Budget Project Strategies (Training, Testing, etc) Slide 8

Leading Practices in Analysis – What Should We Do? Planning Planning Leading Practice: Align Strategic & Operational Plans Does it improve productivity? Does it make us more accurate? Top Down and Bottom Up Planning Does it improve decision making through greater insight? Leveraging Driver Based Planning Focus on the Right Areas – Materiality vs. Volatility Reduce Cycle Times Leverage Rolling Forecasting Processes Reporting Implement Reporting Governance Organization Clearly Define Reporting Standards, Processes, Tools, and Responsibilities Establish “Single Source of the Truth” by Report Type Provide Drill-Through Capability Slide 9

Leading Practices in Design – How Should We Do It? What We Deliver – Scope & Quality Functional Requirements Performance & Technical Requirements Maintenance Requirements Support Requirements Maximize Value! Prioritization of All of the Above Value = Num/Den Numerator – What We Deliver Denominator – Time & Cost What it Costs – Budget & Timeline Timeline Impact Resource & Cost Impact Appetite for Risk & Appropriate Factors Slide 10

Planning Implementation Risks LACK OF AVAILABLE MASTER DATA & DATA – Clients often underestimate the effort required to source and validate data and master data, and this is a frequent reason for project delays – The level of effort must be aligned with the quality of data, number of data sources, and degree of change (e.g., new COA) LACK OF RESOURCES – Technical – It is critical to identify the administrators of the new system early on, and ensure they are properly trained for rollout – Functional - Clients sometimes do not dedicate enough resources to the project effort as the project is viewed as simply a technology implementation LACK OF CLARITY OR CONSISTENCY IN BUSINESS PROCESSES – Planning systems by their nature attempt to predict the future. Clients sometimes have difficulty identifying which disparate elements of their planning process should go into the application, particularly if different areas of the organization have different models. – Defining what should NOT go into the model is as important as determining what goes in (particular impact on Global Planning implementations) Slide 11

Tradeoffs in a Sample Project • Tradeoffs in a Sample Project Phase 1 – Focus on Scope and Push the Limits on Performance • Phase 2 – Scale Back on Scope to enable better performance • Phase 3 – Techniques and Technology Shift the Curve to support both Slide 12

Critical Success Factors Clearly Defined and Communicated Project Goals Key Stakeholder Participation and Approval Finance and IT Involvement Throughout Entire Project Clearly Defined, Reviewed, and Approved Application Design Ownership and Accountability for Project Tasks Thorough Quality Assurance and Testing Communication of Company-wide Benefits Proper Administrator and End User Training Consistent Project Management Slide 13

Planning DesignRecommended Practices Slide 14

Basic Build Approach Application Definition Delineate Plan Types Define Dimensionality Master Data Integration Data Integration Building a Planning Model Development of Forms Development of Calculations Process Flow / Control Define Security Slide 15

Types of Applications • G&A Expenses • Project Cost Centers Internal / External Projects Cost Allocations Resource Allocation Driver Based • Balance Sheet / Cash Flow • Salary / Labor Full Financials Employee Intercompany / Consolidations Position Key Drivers, I/S Integration Variable vs. Fixed • Sales Pipeline • Margin Sales Reps Product / LOB Customers Customer / Segment Integration with CRM • Capital • Long Range / Strat Plans Asset Category Integrate w/ AOP / Forecast New vs. Existing Capital Driver Based Integrate w/ Source Capex Initialization of Future AOP Slide 16

Application Definition SINGLE APPLICATION BENEFITS (up to 3 Custom Plan Types + WFP/FACP) Master Data is shared across an application Common Versioning, Scenarios between plan types Business Rule Efficiency within same app (XREF & XWRITE) Shared Interface for forms and rules between plan types Leverage common set of task lists, right click menus, smart lists, and personal variables MULTIPLE APPLICATION USE CASES Common for separate operating units w/ disparate planning processes Allows for distinct processing windows – US vs. Intl Security – Financials vs. Salary Detail Planning doesn’t support asymetrical security models Ran out of plan types Separate Workflow Processes (e.g. Geography vs. Functional) PLANNING vs. ANALYSIS Slide 17

Application Definition WHAT ARE THE CAPEX / WORKFORCE MODULES? A set of pre-built forms, rules, and menus for planning Salary and Capital expenditures. Pre-built functionality – fully customizable Out of the box functionality to calculate: – WFP – Salaries, Payroll Taxes, Benefits, etc. Based on attributes associated with the employee. – Capex – Depreciation, Capital Spending by Asset Categorization. EXPECTATIONS No one will use the modules out of the box without any customization. Key is to use out of the box functionality with the right blend of customization. Expected customization includes: – Updating Smart List attributes for use within an organization – Modification to forms / rules to allow for budget & forecast processes that converge. – Updating Master Data – Employees, Asset Category, etc. – Adding a requisition number input field Slide 18

Delineate Plan Types WHEN DO I NEED A NEW PLAN TYPE A model needs a different set of dimensionality – Revenue modeling for the organization is done by product and customer – Salary modeling is done by employee and position – Project Planning is done by Project Number – Capital modeling is done by asset classification Inter-dimensional Irrelevance – Does my Core GL plan type need Product, Employee and / or Project #? – Impacts performance of forms, business rules, and reports. – Want to minimize number of stored dimensions for each plan type. IMPACTS OF A NEW PLAN TYPE Data Movements between Plan Types Additional Essbase Cube to optimize Master Data & Data Integration Considerations Slide 19

Define Dimensionality DIMENSION Stored hierarchies within an application Core – Accounts, Entities, Time, Years, Scenario, Versions Revenue – Core + Product, Customer, Sales Person Capital – Core + Asset Category, Project Salary – Core + Employee, Position ATTRIBUTE Associated with a base dimension A dimension member can be associated with a single attribute member from an attribute dimension. WARNING! Slowly Changing Attributes – future Attribute Limitations •No Security Examples •Limited Selections – Start Date (Employee) •Limited Reporting – Address (Customer) •Performance – Brand (Product) – Growth, Productivity, Maintenance (Project) Slide 20

Define Dimensionality SMART LIST A member in an outline (often an account) that is represented as a drop down within the data grid. Smart Lists can be used to drive business rules Smart Lists cannot be sliced and diced like dimensions * Smart Lists can be reported on within Hyperion Reports Stored as numeric value in Essbase Textual Value show in Planning Forms Can be predefined in Essbase Smart Lists – No adapter, load right to tables or use outline Load Utility (depending on release level) Slide 21

Define Dimensionality DATA ELEMENT (TEXT / DATE) Allow user to input text and date directly into a cell in Planning Can leverage in Hyperion Reports Text stored as numeric lookup relationally – HSP_TEXT_CELL_VALUE Date stored as number 20090101 Can be predefined in Essbase No adapter, load right to tables or use OutlineLoad Utility (depending on release level) Slide 22

Master Data Integration MASTER DATA MANAGEMENT VS. ETL TOOLS They are not the same thing A Master Data management tools provides you with a graphical interface to manage your Master Data across disconnected applications. An ETL tool moves data from one place to another MASTER DATA MANAGEMENT TOOLS EPMA – Essentially “DRM” for EPM Applications, w/additional deployment capabilities – Ability to synch Planning, HFM, HPCM & Essbase dimensions across multiple applications – V11 – More Stable (although not for Essbase) WARNING! – Update via Interface Tables – ETL, or Flat File Planning vs. HFM – EPMA File Generator – Creates ADS Files •Entity – Legal vs. Mgmt DRM •Structure Version – CY vs. NY Full blown Master Data management tool Supports Master Data management across any toolset – Hyperion, ERP, etc. Agnostic – read from any source, write to any source Does not have adapters to source / target systems Flat file extracts created from DRM to load into Planning Slide 23

Master Data IntegrationETL TOOLS ODI – “HAL Replacement” – Limited Use ODI Bundled with EPM toolset – Planning must be a source or target to use – Relational Staging Repository for work – ELT – Extract, Load and Transfer Tool DIM/Informatica - Near End of Life – Adapters that connect directly to Planning – Additional Licensing Costs – For Informatica shops – Functionally very similar to ODI HAL - End of Life – Not an option for new clients – Still works in 11X for legacy clientsOTHER UPDATE METHODS Outline Load Utility Manual Update SQL into EPMA Interface Tables & Batch Client Slide 24

Data IntegrationSOURCES General Ledger – Oracle EBS, Peoplesoft, JDE, SAP R/3, Lawson Payroll – Peoplesoft, Oracle, SAP, Ceridian, Lawson HRIS Fixed Assets – Oracle, Peoplesoft Project Tracking – Oracle Project, Peoplesoft, JDE Billing System Order Management EDW Manual Load FileINTEGRATION OPTIONS Essbase Load Rules – SQL Interface – Flat Files Outline Load Utility FDQM – With or without ERPi ODI / DIM / HAL – ETL Tools, use when there is heavy file manipulation Slide 25

Building a Planning Model KEY CONSIDERATIONS What data is needed to facilitate input? What data needs to be collected from end users? Are there supporting drivers that must be input? Are there calculations that need to be processed before input? Read vs. Write on data form elements Are there calculations that need to be processed after input? Before Input? Are the inputs and calculations consistent globally? TIPS Break the process into steps if possible Use menus or task lists to drive navigation Simplify the user experience, provide tools to facilitate navigation Try not to clutter and overcomplicate a form Be conscious of release level impact on Smart View vs. Web Slide 26

Development of Forms PERFORMANCE Balance performance with functionality Load Performance – 3 seconds or less Save Performance – 3 seconds of less Hone business rules – Focus on fewer blocks – FIX (Entity), FIX (Scenario, Version) – Don’t calculate more than you need to – Balance form calculations with an hourly ‘sweep’ – Poorly performing business rules can stack up and kill Essbase performance PERFORMANCE TIPS Suppress Missing Rows vs. Suppress Blocks Rows vs. Columns vs. Page Isolate Performance Issue – Form vs. Rules Query Issue – Size or Poorly Designed Essbase Cube? Block Size Balancing Act – Query vs. Calculations Latest Release – calculations on Forms Slide 27

Development of FormsDESIGN TIPS Large Sparse Dims on Rows – (Improvements to GUI in Talleyrand) Turn on Attribute Display and Impact on Suppress Missing Block Show member formulas Slide 28

Development of Forms DESIGN TIPS Startup Message to Guide Blank Forms Column Definition Drivers & Commentary in BegBalance Member Data Values in IDESC (YearTotal) Slide 29

Development of Forms Use Flag Members to drive form layout – Smart List to drive Flag – UDA’s to drive form definition – Flag Member – Set flag based on UDA definition and Smart List Selection Slide 30

Development of Forms Simple Form Enhanced Forms Slide 31

Development of Forms Composite Forms – Grid 1 – General Information – Grid 2 – Data Collection Slide 32

Development of Forms Control Navigation with a Menu Slide 33

Development of Forms TIPS & TRICKS • Calculations & Forms Should be Developed in Tandem • Robust Essbase Calculation Library • Calculation Manager – Graphical Web Based Rules Builder – Pre-built Templates – Requires EPMA Integration (Talleyrand support for Classic) – Ability to Convert HBR to CM Rules • Alternatives to Drive Calculations – Member Formulas – Business Rules / Calc Manager Rules – Essbase Member Calc Formula Slide 34

Development of Calculations Essbase Member Formula – Simple Member Calculation – Dependencies - Outline Order Important EXAMPLES – Calculations that don’t require user input •Ratios – Calculations don’t require moving data between plan types •Metrics •Modeling – Can be run upon save of form – ‘Calc members on form’ TIP •Create Calc Mbrs •Put All Logic in One member to Eliminate order of Operation issues Slide 35

Development of Calculations Business Rules – Allow for user input to the rule – Allow for passing through variables from the form to the rule Examples – Multiple Members Calculated Upon Form Save with Dependencies •Data Movement •Aggregations – Can be launched on save, or from a right click menu •Currency Conv. – Typically more procedural than member formula •Allocations – Leverage BR to move data between plan types @XREF or @XWRITE •Eliminations Slide 36

Development of Calculations Essbase Member Calc Script – Write multiple member formula’s in an Essbase member – Place member on form, and hide – Allows for procedural member formulas ala Business Rules – Run on save of form – Cannot allow user input to calc – Cannot move data between plan types Slide 37

Development of Calculations DESIGN CONSIDERATIONS Minimize Calculations – Run Time Prompts – Align w/ Page – IALLANCESTORS (RTPs) to aggregate instead of CALC DIM Beware Run on Save / Load Launch Rules from Right Click Menu TIP Sequences Key Commands – Calculation in Current Plan Type @RELATIVE – XREF Data to Core Plan Type @IALLANCESTORS DATACOPY XREF Dangers – Slow across applications – Create Block Issues • Create Blocks in Business Rule • Schedule hourly “sweep” to catch any issues – DATAEXPORT • Use new @XWRITE feature (push vs. pull) Currency Conversion Limitations – Rates stored High (impact on block size) – Manual Input of Rates (or use Outline Load in 11.x) – Pros – Entity has requirement to plan in different local currencies Slide 38

Process Flow/Control Form / Folder Organization – Logically name forms and folders (use numbers) – Order based on ‘Steps’ Right Click Menus – Jump to other forms – Launch Rules – Launch Reports Task Lists – Guide user through a task list – User can check off items as they complete – Review completed vs. outstanding tasks Workflow Being rewritten due to current limitations Targeted for Talleyrand (next release) Slide 39

Define Security PROCESS 1. Setup Groups & Users in Shared Services 2. Assign Access in Planning & Workspace 3. Push Security to Essbase SETUP USERS & GROUPS IN SHARED SERVICES Define Groups – ALL_PLANNING_GROUP - Handles basic provisioning tasks – Version, Scenario, Accounts – ENTITY_PLANNING_GROUPS - Most detail security occurs along the Entity dimension – FUNCTIONAL_PLANNING_GROUPS - In charge of a functional area – for example – margin detail Assign Users to Groups PITFALLS / SUGGESTIONS Groups within Groups (based on release level) AD Groups vs. Planning Level Groups Form Security – Read vs. Write 11X – Apply Security to Folders Slide 40

Shared Services • Basic Planning Access – Planner – Key role for ‘input’ users – View User – Read only user to planning content – Interactive User – Create / Delete Forms – Mass Allocation – Use the mass allocate features – Analytic Services Write Access – • Direct write back to Essbase • Limitations with Period/Yr & Workflow • Essbase Access – Server Access – Connectivity to server – App / DB access • Workspace Access Slide 41

Security Utilities CSS Import Export Use to bulk upload users / groups to Shared Services Provision a few “sample” users, export them to expose the format, application, project, and role names Also used a lot in migrations from Pre-System 9 Create a bulk import Automate Build & Backup of Planning Security Export - HspExportSecurityCmd Import - HspImportSecurityCmd Slide 42

What is Optimization?Optimization - MINIMIZE the time it takes to perform a specific operation…. Rate = Volume/Time Time = Volume/Rate or Decrease Volume (do less) Increase Rate (do it faster) NOTE: All optimization techniques focus on either volume or time. However, the business usually mandates the time and the volume and IT will work to meet the required rate. Slide 43

Optimization Priorities – Balance Query & CalcAssumption: Essbase retrieval is FAST so focus on calc optimization - Trade Off - • Usage of Attribute Dimensions • Dense/Sparse Retrieval Configuration to support Calc Time: calculations Time • Dynamic Calcs • Allocation of Memory to Caches • Transparent Partitions Finding the Balance is the KEY! Testing early on with a realistic data set is on the critical path for every project in order to assess and validate this balance Slide 44

Sample Application Optimization Techniques• Block Size – Impact on Calcs vs. Reports Optimize Outline (BSO) – Larger Blocks – typically faster calcs – Smaller Blocks – typically faster reports• Outline Order – Impact on Calcs vs. Report• Other Techniques – Transparent Partitioning and @XREFs – minimize data – Tuning Parameters – CALCLOCKBLOCK and Data Cache – Dynamic Calcs – implement best practices (defined later) Slide 45

Typical Dynamic Calc Usage Dynamic Calc UsageOUTLINEMETRICS Dollars Level Zero Members with Formulas Nbr Employees Avg $ Per Employee (formula)YEAR QTR 1 Upper Level Members of Dense Dimensions Jan Feb MarScenario Actual Two Pass Members Budget PctVarProduct Prod1 Upper Level Sparse Dimension Members with a Few Prod2 Prod3 Children Slide 46

Dynamic Calc Usage (continued) • For Dense Dimensions, keep Number of Children to a parent < 100 if possible (avoid flat lists) • For Sparse Dimensions, keep number of children to a parent < 7, and avoid multiple levels of dynamic calc if possible – Great idea for 1 to 2 level small sparse dimensions • Avoid dynamic calculation commands that will cause the calculations to execute in CELL mode vs. BLOCK mode – Multiple IF statements for a subset of the block may evaluate faster then @CURRMBR • Minimize Dependent Dynamic Calculations, either hierarchical or formula based – Pay attention to Deep, Ragged Chart of Account Structures – consider formulas for certain upper level members – Recreate calc logic as performance optimizer (maintenance impact) • Consider nearly all two pass calcs as dynamic – Exception – smaller KPI/metrics cubes where all dimensions are stored Slide 47

Dynamic Calc Trick (Dense) Eliminate Dependencies on other dynamic calcs in formulas or hierarchies Total Expenses = @SUM(@RELATIVE(“TOTAL EXPENSES”, 0)) is FASTER than Total Expenses Operating Expenses (and all of its hierarchies) Non Operating Expense (and all of its hierarchies) Slide 48

Dynamic Calc Trick (Sparse) Stagger Dynamic Calc at Multiple Level of Hierarchies, and Supplement with Multiple Loads (e.g. Add to Existing Values) Use Add to existing Values to Load Here Scenario (Label Only, Sparse) in Rule Actual (Dynamic Calc) Actual_Load (Stored)(+) Actual_EDW (Dynamic Calc) (~) Actual_EDW_A (Stored) (+) Actual_EDW_B (Stored) (+) Actual_EDW_C (Stored) (+) Actual_GL (Dynamic Calc) (~) Actual_GL_JDE (Stored) (+) Actual_GL_PS (Stored) (+) Actual_Adj (Stored)(+) Slide 49

Typical Maintenance Routines Maintenance Routines • Defragmentation Routines – Outline (predominantly ASO) – Database (index/page files) • Log Purging Operations – Application Server – Agent and Event Logs on Essbase Server – Planning Audit Logs • Recycling of Services to Clear Memory (BEA J2EE) • Reboot Machines Monthly • Archiving off of Older Data Sets – “History” Cubes – Read Only Reporting Cubes (ASO) vs. Read/Write Modeling Cubes Slide 50

Typical Planning Customizations Maintenance Routines• Bulk Load of Supporting Details – a must for Pillar Migrations• Essbase CDF via Business Rule - Copy Supporting Details/Cell Text – Incorporate into Business Rules with Run Time Prompts – Better then Copy Data or Copy Versions – Key Planning Table -• Essbase CDF via Business Rules – launch external processes• Essbase CDF – solve simultaneous equations vs. Looping (debt/interest modeling)• Custom SQL Views in Planning RDBMS against Web Analysis or OBIEE – Audit Reporting – “Search” Capability for Supporting Details – Custom Security Reports• Currency Conversion Tip! – Use Essbase CDFs, and the relational repository to Customize – will be easier to upgrade later on Slide 51

Eleven Planning Tips to Remember Maintenance Routines1. Consider alternatives to out of Box Planning Currency Conversion & Target Scenarios (storing data high)2. Load and Validate Dims & Data in Essbase, then port to Planning3. Separate Business Rule Functionality – Modeling, Data Movement, Agg4. Ensure Developers have “test” user ids to validate functionality and view of forms – Administrator masks a multitude of sins5. Separate Essbase ASO Reporting Cube – optimize read vs. write6. Model it in excel before you model it in Planning7. Understand impact of Scenarios (Management Cycles) vs. Versions (Iterations of a Management Cycle)8. Use Suppress Empty Blocks in Form Design9. Convert Actual Data to “Plan View” to accommodate different levels of grain and simply form design10. “Push” data between plan types on change, don’t pull always11. Establish thresholds for business rule performance in multi-user environment – e.g. one minute for a rule is too slow in a multi user environment Slide 52

ClosingRanzal Differentiators• Technology Excellence• Delivery Quality• Industry Expertise• Client Focus• Solid Business Methodology• Strong Customer References• Relationship with Oracle / Hyperion• Vertical Expertise from Edgewater• North American and European Presence• Webinars – http://www.ranzal.com/news.htmCome Visit us in Booth 5 in the Exhibition Hall Contact Contact Mija Deering Mike Killeen Principal Solutions Manager VP of Technology, Oracle Ace Edgewater Ranzal Edgewater Ranzal E-mail: mdeering@ranzal.com E-mail: mkilleen@ranzal.com Slide 53

http://ranzal.wordpress.com	2308
http://www.ranzal.com	43
http://edgewebauth1.edgewater.com:8081	20
http://translate.googleusercontent.com	4
url_unknown	2
http://webcache.googleusercontent.com	2
http://ranzal.wordpress.com HTTP	2
http://www.slideshare.net	1
http://dashboard.wordpress.com	1

Key Considerations for a Successful Hyperion Planning Implementation

by Edgewater Ranzal on Jun 22, 2011

Accessibility

Tags

Upload Details

Usage Rights

9 Embeds 2,383

Statistics

Key Considerations for a Successful Hyperion Planning Implementation — Presentation Transcript