Best Practices in Hyperion Financial Management Design & Implementation

26
Best Practices in HFM Application Design Chris Barbieri Consolidation Practice Director Oracle ACE Ranzal & Associates

description

Deatiled practices in HFM design & implementation

Transcript of Best Practices in Hyperion Financial Management Design & Implementation

Page 1: Best Practices in Hyperion Financial Management Design & Implementation

Best Practices in

HFM Application DesignHFM Application Design

Chris Barbieri

Consolidation Practice Director

Oracle ACE

Ranzal & Associates

Page 2: Best Practices in Hyperion Financial Management Design & Implementation

Personal Background

Chris Barbieri

• Established HFM performance tuning techniques

and statistics widely used today

• 4+ years as Sr. Product Issues Manager at Hyperion

– HFM, Smart View, Shared Services, MDM

• Member of HFM launch team in 2001, certified in • Member of HFM launch team in 2001, certified in

HFM and Enterprise

• MBA, Babson College

• B.S. Finance & Accounting, Boston College

• Co-founded the HFM Performance Tuning Lab at

Ranzal with infrastructure expert Kurt Schletter

Page 3: Best Practices in Hyperion Financial Management Design & Implementation

Application Design: the Foundation of

Performance

• Hyperion Financial

Management

• Metadata design as it impacts

performanceperformance

– Volume of members

– Impact of structures

• Data

– Content

– Density

Page 4: Best Practices in Hyperion Financial Management Design & Implementation

Metadata

Page 5: Best Practices in Hyperion Financial Management Design & Implementation

Designing HFM’s 12 Dimensions

Application Profile

1. Year

2. Period

3. View

System

User controlled

5. Entity

6. Account

7. ICP

8. ScenarioSystem

4. Value dimension,

includes currencies

8. Scenario

User defined

9. Custom 1

10. Custom 2

11. Custom 3

12. Custom 4

Page 6: Best Practices in Hyperion Financial Management Design & Implementation

Application Profile

Year– No inherent impact on performance

– Cannot be changed after the application is built

– Impacts the number of tables that can be created in the database

Period– The base periods comprise the column structure of – The base periods comprise the column structure of

every table, whether you use them or not.

– For this reason, avoid weekly or yearly profiles unless it is key to your entire application’s design

View– No impact, but only YTD is stored and Periodic, QTD are

on-the-fly derivations

Page 7: Best Practices in Hyperion Financial Management Design & Implementation

System Dimension

Value Dimension– Can not directly modify this

– “<Entity Currency>” is a simple variable directing you to the current entity’s default currency

– “<Parent Currency>” points back to the currency of the entity’s parent

Currencies– Don’t add currencies you aren’t using– Don’t add currencies you aren’t using

• Sets of calc status records for (every entity * every currency)

• Impact of loading metadata with entity or currency changes

– Normally translate from the entity’s currency only into it’s parent’s currency.

– Beware of non-default translations• Impacted calc status

• Data explosion

Page 8: Best Practices in Hyperion Financial Management Design & Implementation

User Controlled Dimensions

Entity

– Sum of the data of the children

– Avoid Consolidate All or All With Data on each hierarchy

– Assign Adj flags sparingly

ICPICP

– “Hidden” dimension

Scenario

– Number of tables

Page 9: Best Practices in Hyperion Financial Management Design & Implementation

Impact of Account Depth

4- Net Income

3- Optg Income 5- EBIT

6- Net Income

� Effect is multiplied when you consider the custom dimensions

� Parent accounts don’t lock

2- Gross Margin

1- Sales

4- Optg Income

3- Gross Profit

2- Gross Margin

1- Sales

Page 10: Best Practices in Hyperion Financial Management Design & Implementation

User Defined Dimensions

Custom 1..4

– Think dozens or hundreds, but not thousands

– Avoid:

• Employees

• Products

• Anything that is very dynamic

• One to one relationship with the entities

Page 11: Best Practices in Hyperion Financial Management Design & Implementation

Metadata Efficiency Ratio

What does the average entity have in common with the top entity?– Density measurement of re-use of the accounts and customs

across all entities

top entity

children

unique custom 1

Page 12: Best Practices in Hyperion Financial Management Design & Implementation

Metadata Volumes (Americas)

Dimension Average

Volume

Recorded

High

Comments

Accounts 2,132 14,409

Entities 1,165 22,882

Currencies 16 233 use only 1 currency 30%

Custom1 388 19,410 use Custom 1 96%

Custom2 153 15,188 use Custom 2 86%

Custom3 61 26,816 use Custom 3 86%Custom3 61 26,816 use Custom 3 86%

Custom4 39 11,389 use Custom 4 62%

Scenarios 11 78

Entity hierarchies 3 24 the equivalent of Organizations in Hyperion Enterprise

ICP Accounts with Plug 41 1,223 use automated intercompany matching 56%

Accounts with Line Item Detail 36 1,667 16% use this, but only 10% have more than 1 account flagged

Consolidation Rules - - use consolidation rules 28%

Consolidation methods 5 10 use methods 14%

OrgByPeriod use organization by period 9%

ICP Members 86 1,407 track intercompany activity 81%

Entities flagged for Parent Adjs 143 7,698 Allow [Parent Adj] or [Contribution Adj] journals30%

Scenarios using Process Mgmt 5 53 use process management46%

Page 13: Best Practices in Hyperion Financial Management Design & Implementation

Data

Page 14: Best Practices in Hyperion Financial Management Design & Implementation

What’s a Subcube?

• HFM data structure

• Database tables stored by

– Each record contains all periods for the [Year]

– All records for a subcube are loaded into memory together

Parent subcube, stored

in DCN tables

Currency subcubes,

stored in DCE tables

Page 15: Best Practices in Hyperion Financial Management Design & Implementation

Take it to the Limit

Reports, Grids, or Forms that:

– Pull lots of entities

– Lots of years

– Lots of scenarios

Not so problematic:

– Lots of accounts

– Or Custom dimension members

Smart View

– Cell volume impacts bandwidth

– Subcubes impact server performance

Page 16: Best Practices in Hyperion Financial Management Design & Implementation

HFM Urban Legends

• 100,000 records per subcube

• Increase MaxNumDataRecordsInRAM = better

performance

• 500 children to a parent• 500 children to a parent

• System 9 allows an unlimited sub cube size

• Customs should be ordered largest to smallest

• Limit to the Account dimension depth

• 64 bit is faster (this requires some explanation)

Page 17: Best Practices in Hyperion Financial Management Design & Implementation

Data Design

“Metadata volume is interesting, but it’s

how you it that matters most”

• Density

• Content

– Specifically: zeros

– Tiny numbers

– Invalid Records

Page 18: Best Practices in Hyperion Financial Management Design & Implementation

Data Volume Measurement

• No perfect method

Method How-To Pros Cons

Data Extract Extract all data,

count per entity

Simple, easy to see input

from calculated

Can only extract

<Entity Currency>

FreeLRU Parse HFM event Good sense of average Can’t identify FreeLRU Parse HFM event

logs

Good sense of average

cube, easy to monitor

monthly growth

Can’t identify

individual cubes,

harder to understand

Database

Analysis

Query DCE, DCN

tables and count

Easy for a DBA, see all

subcubes

Doesn’t count dynamic

members, includes

invalid records

Page 19: Best Practices in Hyperion Financial Management Design & Implementation

Data Density Using FreeLRU

• Survey of data density using FreeLRU method

Number of applications reviewed: 32 Average Min Max Median ABC

Customer

NumCubesInRAM 2,672 72 10,206 1,345 577

NumDataRecordsInRAM 1,502,788 247,900 5,627,748 1,170,908 1,107,614NumDataRecordsInRAM 1,502,788 247,900 5,627,748 1,170,908 1,107,614

NumRecordsInLargestCube 86,415 2,508 593,924 53,089 31,446

Average records per cube 6,309 24 91,418 1,352 2,288

Average metadata efficiency:

average cube/densest cube

7.3% 0.3% 39.7% 3.4% 7.3%

Page 20: Best Practices in Hyperion Financial Management Design & Implementation

Loaded Data

• What percent of the loaded data is a zero value?– No hard rule, but <5% may be reasonable

– No zeros are best, watch ZeroView settings on the scenarios

• Watch out for tiny values, resulting from allocations

• How much does the data expand from Sub Calculate?– Am I generating zeros, or tiny numbers?

Input Base Records Input Plus Calculated Base Records % Increase

From Rules

Total 2,031,976 Total 4,387,520 116 %

Input zeros 18,024 Calculated zeros 413,837 2,196 %

% zero loaded 0.9% % zeros calculated at base 9.4%

Values > -1 and < 1 373,226 Values > -1 and < 1 calculated 593,981 59 %

% values > -1 and < 1 18.4% % values > -1 and < 1 calculated 13.5%

Page 21: Best Practices in Hyperion Financial Management Design & Implementation

Effect of Sparsity on Record Volume

• Most dense data is at the top entity

– Greatest number of populated intersections (account _ custom 1..4 combinations)

Page 22: Best Practices in Hyperion Financial Management Design & Implementation

Consolidated Data

• Total volume of data in any

subcube

• How many zeros are generated

by the consolidation process?

– Intercompany eliminations

Consolidated Base Records

Total 991,587

Consolidated zeros 194,204

% zeros 19.6%

Values > -1 and < 1 84,251– Intercompany eliminations

– Allocations

– Empty variables

Values > -1 and < 1 84,251

% values > -1 and < 1 8.5%

Loaded 0.9%

Calculated 9.4%

Consolidated 19.6%

Page 23: Best Practices in Hyperion Financial Management Design & Implementation

Data Density <> Calc Time

1.000

1.500

2.000

2.500

400

500

600

700

800

900

Se

con

ds

Re

cord

sAverage Rule Execution Time in Contrast with Data Volume

correlation between density and calc times

• Most applications are rules bound

-

0.500

-

100

200

300

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

Page 24: Best Practices in Hyperion Financial Management Design & Implementation

Invalid Records

•• Type 1:Type 1: Orphaned records from metadata that has been deleted

– Member is removed from dimension_Item table, but not from the data tables

– These can be removed by Database > Delete Invalid Records– These can be removed by Database > Delete Invalid Records

•• Type 2:Type 2: the member still exists, but is no longer in a valid intersection

– Most often from changing CustomX Top Member on an account

– These cannot be removed by HFM, but are filtered out in memory

Page 25: Best Practices in Hyperion Financial Management Design & Implementation
Page 26: Best Practices in Hyperion Financial Management Design & Implementation

Chris BarbieriChris [email protected]@ranzal.com

Needham, MANeedham, MANeedham, MANeedham, MA

USAUSA

+1.617.480.6173+1.617.480.6173

www.ranzal.comwww.ranzal.com