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

Hyperion Planning

Embed Size (px)

DESCRIPTION

Hyperion Planning

Citation preview

Page 1: Hyperion Planning

Slide 1

Key Considerations for a Successful

Hyperion Planning Implementation

Edgewater Ranzal

UK Division

Mike Killeen

Vice President, Oracle Ace

&

Mija Deering

Principal Solutions Manager

UKOUG EPM & Hyperion Conference 2011

Page 2: Hyperion Planning

Slide 2

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

Agenda

Page 3: Hyperion Planning

Slide 3

Focus

Services

People

Methodology

Customers

Partnership

About Edgewater Ranzal

15 Years700+ clients

1000+ projects

Page 4: Hyperion Planning

Slide 4

• 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?

Quick Audience Poll

Page 5: Hyperion Planning

Slide 5

Key Project Phases

Page 6: Hyperion Planning

Slide 6

Ranzal Project Lifecycle Overview

Proposal & Statement of Work

Kick-Off, Logistics, Coordination & Plan

Manage schedule, scope, issues, risks, cost & resources – status reporting

Successes & Lessons Learned

Project Planning & Management Approach

Pre-Engagement Project Initiation Project Execution Project Closure

What & How to Deploy

Install, Configure & Unit Test

Infrastructure, System Integration & Acceptance Testing

Training, Documentation &

Knowledge Transfer

Implementation Approach

Design Build Test Rollout / Sustain

What is Wrong, Right & Needed

Analyze

Define the Change and

How to Manage

Define Future Organization and

Understand Impact

Prepare for the Change

Facilitate the Change

Change Management Approach

Assess/Design Build Deploy MonitorPlan/Scope

Focus Points• Multiproduct

Experience

• Knowledge

Transfer

• Performance Benchmarking

• Understand Priorities

• Flexible Approach

• Modular Scope

• Prototyping

• Leverage

Prior Work

Monitor the Results

Page 7: Hyperion Planning

Slide 7

Typical Implementation

NEEDS AND

REQUIREMENTS

ANALYSIS

PLAN AND

DESIGN PHASE BUILD PHASE TEST PHASE

GO LIVE AND

ROLLOUT SUPPORT

CUSTOMIZED

TRAINING

• Current state and

stakeholder needs

analysis

• Identify process,

system, and

organizational

components

• Define a project

roadmap

• Determine

optimal level of

detail and

structure

• Design docs

• Detailed work

plan with

deliverables

• Construct

templates and

models

• Report / dash-

board build-out

• Prototype

reviews

• Develop data

interfaces

• Upload test data

• User validation

• Calibrate models

• Document final

process, system,

org

• Develop easy to

use reference

guide

• Develop custom

training and

exercises

• Deliver user

training

• Review Go Live

Checklist

• Move solution

into production

• Provide on-site

support

• Semi-annual

audits and

process/model

reviews

Page 8: Hyperion Planning

Slide 8

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)

Analyze vs. Design

Page 9: Hyperion Planning

Slide 9

Planning� Align Strategic & Operational Plans

� Top Down and Bottom Up Planning

� 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

Planning Leading Practice:� Does it improve productivity?

� Does it make us more accurate?�Does it improve decision making

through greater insight?

Leading Practices in Analysis – What Should We Do?

Page 10: Hyperion Planning

Slide 10

What We Deliver – Scope & Quality� Functional Requirements

� Performance & Technical Requirements

� Maintenance Requirements

� Support Requirements

� Prioritization of All of the Above

What it Costs – Budget & Timeline� Timeline Impact

� Resource & Cost Impact

� Appetite for Risk & Appropriate Factors

Maximize Value!Value = Num/Den

�Numerator – What We Deliver� Denominator – Time & Cost

Leading Practices in Design – How Should We Do It?

Page 11: Hyperion Planning

Slide 11

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)

Planning Implementation Risks

Page 12: Hyperion Planning

Slide 12

• 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

Tradeoffs in a Sample Project

Tradeoffs in a Sample Project

Page 13: Hyperion Planning

Slide 13

� 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

Critical Success Factors

Page 14: Hyperion Planning

Slide 14

Planning Design

Recommended Practices

Page 15: Hyperion Planning

Slide 15

� 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

Basic Build Approach

Page 16: Hyperion Planning

Slide 16

Types of Applications

• G&A Expenses

� Cost Centers� Cost Allocations� Driver Based

• Salary / Labor

� Employee� Position� Variable vs. Fixed

• Margin

� Product / LOB� Customer / Segment

• Capital

� Asset Category� New vs. Existing Capital� Integrate w/ Source Capex

• Project

� Internal / External Projects� Resource Allocation

• Balance Sheet / Cash Flow

� Full Financials� Intercompany / Consolidations� Key Drivers, I/S Integration

• Sales Pipeline

� Sales Reps� Customers� Integration with CRM

• Long Range / Strat Plans

� Integrate w/ AOP / Forecast� Driver Based� Initialization of Future AOP

Page 17: Hyperion Planning

Slide 17

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

Application Definition

Page 18: Hyperion Planning

Slide 18

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

Application Definition

Page 19: Hyperion Planning

Slide 19

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

Delineate Plan Types

Page 20: Hyperion Planning

Slide 20

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.

� Slowly Changing Attributes – future

� Examples

– Start Date (Employee)

– Address (Customer)

– Brand (Product)

– Growth, Productivity, Maintenance (Project)

Define Dimensionality

WARNING!Attribute Limitations

•No Security•Limited Selections•Limited Reporting

•Performance

Page 21: Hyperion Planning

Slide 21

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)

Define Dimensionality

Page 22: Hyperion Planning

Slide 22

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)

Define Dimensionality

Page 23: Hyperion Planning

Slide 23

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)

– Update via Interface Tables – ETL, or Flat File

– EPMA File Generator – Creates ADS Files

� DRM

� 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

Master Data Integration

WARNING!Planning vs. HFM

•Entity – Legal vs. Mgmt•Structure Version – CY vs. NY

Page 24: Hyperion Planning

Slide 24

ETL 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 clients

OTHER UPDATE METHODS

� Outline Load Utility

� Manual Update

� SQL into EPMA Interface Tables & Batch Client

Master Data Integration

Page 25: Hyperion Planning

Slide 25

SOURCES� 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 File

INTEGRATION 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

Data Integration

Page 26: Hyperion Planning

Slide 26

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

Building a Planning Model

Page 27: Hyperion Planning

Slide 27

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

Development of Forms

Page 28: Hyperion Planning

Slide 28

DESIGN TIPS� Large Sparse Dims on Rows – (Improvements to GUI in Talleyrand)

� Turn on Attribute Display and Impact on Suppress Missing Block

� Show member formulas

Development of Forms

Page 29: Hyperion Planning

Slide 29

DESIGN TIPS� Startup Message to Guide Blank Forms

� Column Definition� Drivers & Commentary in BegBalance Member

� Data Values in IDESC (YearTotal)

Development of Forms

Page 30: Hyperion Planning

Slide 30

� 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

Development of Forms

Page 31: Hyperion Planning

Slide 31

� Simple Form

� Enhanced Forms

Development of Forms

Page 32: Hyperion Planning

Slide 32

� Composite Forms

– Grid 1 – General Information

– Grid 2 – Data Collection

Development of Forms

Page 33: Hyperion Planning

Slide 33

� Control Navigation with a Menu

Development of Forms

Page 34: Hyperion Planning

Slide 34

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

Development of Forms

Page 35: Hyperion Planning

Slide 35

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’

Development of Calculations

EXAMPLES•Ratios•Metrics•Modeling

TIP•Create Calc Mbrs•Put All Logic inOne member to

Eliminate order ofOperation issues

Page 36: Hyperion Planning

Slide 36

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 @XREF or @XWRITE

Development of Calculations

Examples•Data Movement•Aggregations

•Currency Conv.•Allocations

•Eliminations

Page 37: Hyperion Planning

Slide 37

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

Development of Calculations

Page 38: Hyperion Planning

Slide 38

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� 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• 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

Development of Calculations

TIPKey Commands

@RELATIVE@IALLANCESTORS

DATACOPY

Page 39: Hyperion Planning

Slide 39

� 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)

Process Flow/Control

Page 40: Hyperion Planning

Slide 40

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

Define Security

Page 41: Hyperion Planning

Slide 41

• 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

Shared Services

Page 42: Hyperion Planning

Slide 42

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

Security Utilities

Page 43: Hyperion Planning

Slide 43

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.

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)

What is Optimization?

Page 44: Hyperion Planning

Slide 44

Retrieval Time:

Assumption: Essbase retrieval is FAST so focus on calc optimization

- Trade Off -

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

Calc Time

• Usage of Attribute Dimensions• Dense/Sparse Configuration to support calculations• Dynamic Calcs• Allocation of Memory to Caches• Transparent Partitions

Optimization Priorities – Balance Query & Calc

Page 45: Hyperion Planning

Slide 45

Optimize Outline (BSO)• Block Size – Impact on Calcs vs. Reports

– 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)

Sample Application Optimization Techniques

Page 46: Hyperion Planning

Slide 46

Dynamic Calc UsageOUTLINEMETRICS

DollarsNbr EmployeesAvg $ Per Employee (formula)

YEARQTR 1

JanFebMar

ScenarioActualBudgetPctVar

ProductProd1Prod2Prod3

Upper Level Members of Dense Dimensions

Level Zero Members with Formulas

Two Pass Members

Upper Level Sparse Dimension Members with a Few Children

Typical Dynamic Calc Usage

Page 47: Hyperion Planning

Slide 47

• 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

Dynamic Calc Usage (continued)

Page 48: Hyperion Planning

Slide 48

Dynamic Calc Trick (Dense)

Eliminate Dependencies on other dynamic

calcs in formulas or hierarchies

Total Expenses = @SUM(@RELATIVE(“TOTAL EXPENSES”, 0))

Total Expenses

Non Operating Expense (and all of its hierarchies)

Operating Expenses (and all of its hierarchies)

is FASTER than

Page 49: Hyperion Planning

Slide 49

Dynamic Calc Trick (Sparse)

Stagger Dynamic Calc at Multiple Level of Hierarchies,

and Supplement with Multiple Loads (e.g. Add to

Existing Values)

Scenario (Label Only, Sparse)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)(+)

Use Add to existing Values to Load Here

in Rule

Page 50: Hyperion Planning

Slide 50

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

Typical Maintenance Routines

Page 51: Hyperion Planning

Slide 51

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

Typical Planning Customizations

Tip! – Use Essbase CDFs, and the relational repository toCustomize – will be easier to upgrade later on

Page 52: Hyperion Planning

Slide 52

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 Planning

3. Separate Business Rule Functionality – Modeling, Data Movement, Agg

4. Ensure Developers have “test” user ids to validate functionality and view of forms – Administrator masks a multitude of sins

5. Separate Essbase ASO Reporting Cube – optimize read vs. write

6. Model it in excel before you model it in Planning

7. Understand impact of Scenarios (Management Cycles) vs. Versions

(Iterations of a Management Cycle)

8. Use Suppress Empty Blocks in Form Design

9. Convert Actual Data to “Plan View” to accommodate different levels of grain and simply form design

10. “Push” data between plan types on change, don’t pull always

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

Eleven Planning Tips to Remember

Page 53: Hyperion Planning

Slide 53

Closing

ContactMike KilleenVP of Technology, Oracle AceEdgewater RanzalE-mail: [email protected]

Ranzal 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.htm

Come Visit us in Booth 5 in the Exhibition Hall

ContactMija DeeringPrincipal Solutions ManagerEdgewater RanzalE-mail: [email protected]