1. Key Considerations for aKey Considerations for a
Successful HyperionSuccessful Hyperion
Planning ImplementationPlanning Implementation
Issam HejazinIssam Hejazin

2. • INTRODUCTIONS
• KEY PROJECT PHASES
• RECOMMENDED BUILD TECHNIQUES
– Application Definition
– Delineate Plan Types
– Define Dimensionality
– Metadata Integration
– Data Integration
– Building a Planning Model
– Development of Forms
– Development of Calculations
– Process Flow / Control
– Define Security
Agenda

3. Introductions

4.  Founded in 1996, Ranzal has implemented Hyperion solutions for
500+ companies (800+ projects since the acquisition)
 Oracle / Hyperion Platinum Partner - Highest Status
 Hyperion “Americas Reseller” & “Partner of the Year”
› 1999, 2005 & 2007
 Certified EPM Consultants & Instructors
 Vertical Expertise with High-Profile Clients from Coast to Coast
› East Coast & West Coast Presence
 Sound Project Methodology Insures Project Success
› Support Business Applications from start to finish
 One of the Largest Hyperion Practices in the U.S.
 “Best Planning & Essbase Practices with Best HFM Practice”
› Hyperion Development utilizes Ranzal for Planning, Essbase and HFM product direction
About Ranzal
Regarded in the industry as one of the "BEST” at leveragingRegarded in the industry as one of the "BEST” at leveraging
OLAP technology to develop EPM ApplicationsOLAP technology to develop EPM Applications

5.  Our team has been involved in 800+ successful EPM Implementations
› Financial Consolidation & Management Reporting
› Budgeting & Planning
› Profitability Management Solutions
› Business Intelligence and Data Warehousing
› Infrastructure Planning and Performance Tuning
› Business Process and Project Management
 Strong client portfolio across leading Industry Sectors including
 Certified consultants and instructors
› Hyperion Essbase, Hyperion Planning, Hyperion Financial Management, HPCM, Hyperion
Enterprise, Hyperion Strategic Finance, Hyperion BI+ (Web Analysis, Financial Reports,
Interactive Reporting, Production Reporting), Hyperion Data Relationship Management,
Hyperion Financial Data Quality Management, Data Services (including ETL, Warehousing)
› Financial Services
› Insurance
› Retail / Consumer Packaged Goods
› Manufacturing
› Pharmaceutical & Hospital
› Hospitality / Travel / Entertainment
› High Technology / E-business
› Energy / Utilities
› Distribution
› Government
› Other
Application & Industries

6. Key Project Phases

7. Project Phases
Analyze/Design
Build
Test
Rollout
Infrastructure
Build
Application
Install
Back-End Build
Front-End Build

8. Infrastructure (Simple)

9. Infrastructure (Complex)

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

11. Biggest Risks to Planning Projects
LACK OF AVAILABLE METADATA & 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 CLIENT 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 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.

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

13. Planning Design
Recommended Practices

14. Basic Build Approach
 Application Definition
 Delineate Plan Types
 Define Dimensionality
 Metadata Integration
 Data Integration
 Building a Planning Model
 Development of Forms
 Development of Calculations
 Process Flow / Control
 Define Security

15. Application Definition
SINGLE PLANNING APPLICATION
– Allows for three custom plan types
– Two “modules” – Workforce & Capex
APPLICATION SETUP
– Classic
– EPMA
COMMON PLAN TYPES
– Core – GL Account, Entity
– Revenue – Product, Customer
– Salary / Workforce – Employee, Position
– Capital / Capex – Asset Category, Projects, etc.
– Sales – Customer, Sales Rep
– Balance Sheet / Cash Flow

16. Application Definition
SINGLE APPLICATION BENEFITS
 Metadata is shared across an application
 Common Versioning, Scenarios between plan types
 Business Rule Efficiency within same app (XREF)
 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
 Ran out of plan types

17. Delineate Plan Types
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 with no 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 metadata – Employees, Asset Category, etc.
– Adding a requisition number input field

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
 Metadata & Data Integration Considerations

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.
 Examples
– Start Date (Employee)
– Address (Customer)
– Brand (Product)
– Growth, Productivity, Maintenance (Project)

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
 11.1.2 supports model to ASO for
increased reporting capabilities

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

22. Metadata Integration
METADATA MANAGEMENT VS. ETL TOOLS
 They are not the same thing
 A metadata management tools provides you with a graphical interface to manage your
metadata across disconnected applications.
 An ETL tool moves data from one place to another
METADATA MANAGEMENT TOOLS
 EPMA
– Relatively new tool (BPMA,)
– Essentially “DRM” for EPM Applications
– Ability to synch Planning, HFM & Essbase dimensions across multiple applications
– V11 – Stable, Much Improved
– Update via Interface Tables – ETL, or Flat File
– EPMA File Generator – Creates ADS Files
 DRM
 Full blown metadata management tool
 Supports metadata 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

23. Metadata Integration
ETL TOOLS
 ODI
– “HAL Replacement”
– Limited Use ODI Bundled with EPM toolset
– Planning must be a source or target to use
– Relational Staging Repository where a lot of the work is done
– ELT – Extract, Load and Transfer Tool
 DIM
– Adapters that connect directly to Planning
– Additional Licensing Costs
– For Informatica shops
– Functionally very similar to ODI
 HAL
– Not an option for new clients
– Still works in 11X for legacy clients but not supported
OTHER UPDATE METHODS
 Essbase
 Outline Load Batch Utility

24. Data Integration
SOURCES
 General Ledger – Lawson, Oracle, Peoplesoft, SAP, Great Plains
 Payroll – Ceridian, Lawson HRIS
 Fixed Assets – Lawson, Oracle Project, Navision
 Project Tracking – Oracle Project, JDE
 Billing System
 Order Management
 EDW
 Manual Load File
 Collect via Planning Form
– Currency Rates
– Benefit Rates (FICA Max, FICA %)
INTEGRATION OPTIONS
 Essbase Load Rules
– SQL Interface
– Flat Files
– MAXL Automation
– Simple ETL
 ODI / DIM / HAL
– ETL Tools, use when there is heavy file manipulation

25. Data Integration

26. 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?
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

27. Development of Forms

28. 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

29. Development of Forms
DESIGN TIPS
 Large Sparse Dims on Rows – (Improvements to GUI in Talleyrand)
 Turn on Attribute Display
 Suppress Missing Block
 Show member formulas

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

31. 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

32. Development of Forms
 Simple Form
 Enhanced Forms

33. Development of Forms
 Control Navigation with a Menu

34. Development of Calculations

35. Development of Calculations
TIPS & TRICKS
• Calculations & Forms Should be Developed in Tandem
• 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

36. Development of Calculations
Essbase Member Formula
– Simple Member Calculation
– Dependencies - Outline Order Important
– Calculations that don’t require user input
– Calculations don’t require moving data between plan types
– Can be run upon save of form – ‘Calc members on form’

37. Development of Calculations
Business Rules
– Allow for user input to the rule
– Allow for passing through variables from the form to the rule
– Multiple Members Calculated Upon Form Save with Dependencies
– Can be launched on save, or from a right click menu
– Typically more procedural than member formula
– Leverage BR to move data between plan types

38. 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

39. Development of Calculations
DESIGN CONSIDERATIONS
 Minimize Calculations
– Run Time Prompts – Align w/ Page
– IANCESTORS (Run Time Prompt) to aggregate instead of CALC DIM
 Beware Run on Save / Load
 Launch Rules from Right Click Menu
 Sequences
– Calculation in Current Plan Type
– XREF Data to Core Plan Type
 XREF Dangers
– Slow across applications
– Create Block Issues
• Create Blocks in Business Rule
• Schedule hourly “sweep” to catch any issues - DATAEXPORT
 Currency Conversion Limitations
– Rates stored High
– Manual Input of Rates
– Pros – Entity has requirement to plan in different local currencies

40. Process Flow / Control

41. Process Flow / Control
 Form / Folder Organization
– Logically name forms and folders
– 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)

42. Security

43. 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
 AD Groups vs. Planning Level Groups
 11X – Apply Security to Folders

44. Mark HiteMark Hite
mhite@ranzal.commhite@ranzal.com
Questions

45. Key Considerations for aKey Considerations for a
Successful HyperionSuccessful Hyperion
Planning ImplementationPlanning Implementation