2. Agenda
• 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
4. About Ranzal
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
Regarded in the industry as one of the "BEST” at leveraging
OLAP technology to develop EPM Applications
5. Application & Industries
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
›
›
›
›
›
›
›
Financial Services
Insurance
Retail / Consumer Packaged Goods
Manufacturing
Pharmaceutical & Hospital
Hospitality / Travel / Entertainment
›
›
›
›
›
High Technology / E-business
Energy / Utilities
Distribution
Government
Other
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)
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
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
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
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
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
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)
43. Define Security
PROCESS
1.
2.
3.
Setup Groups & Users in Shared Services
Assign Access in Planning & Workspace
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
Ranzal has over 10 years experience developing Business Performance Solution. We are a platinum partner as a company certified in Essbase which only a few have met the stringent guidelines for and the ONLY Hyperion partner CERTIFIED on Planning which no other partner could accomplish so we are very PROUD of that
We have a very innovative development style. We are looking for “QUICK WINS” during development. Phases completed in weeks and months, not years. This helps management see results and continue project investment.
Talk to the different phases in this slide
Activities involved in each phase
- Requirements vs. Design (more next slide)
- Build
- Infra build
- Application Install
- Back end build
- Front end build
- Test
- Unit testing – Done during dev usually
- Integration testing – integrated testing of moving parts. End to end process testing
- UAT – Scripts, Informal
- Rollout
- Training
- Prep material
- Formal classroom
- Train the trainer
- Cutover to prod (or back to dev)
- LCM
- Go live support
Requirements – Often done independent of product selection. Can be used to help drive RFP process for product / vendor selection
Requirements – What are we implementing?
Design – How are we implementing?
Clearly defined goals – Organization wide…
- Don’t drop a new planning app on your users a week out. Important to evangelize the benefits of the new system.
- Improved reporting, clarity in budget vs. actual, ease of variance reporting, etc.
Integral to include feedback from key stakeholders – especially those that are actually using the system. Don’t develop what you think they need.
- Solicit feedback, Create POC’s, gain acceptance. Don’t surprise users.
- We use POC’s a great deal during design to help shore up concepts and allow users to visualize the end state
Finance vs. IT
– Not going to work if you have one group trying to pull the wool over the eyes of the other group.
Testing is critical, Recommended approach is about 20% of project hours, some company’s demand 30-40%.
Proper Admin Training – Planning Admin Training, Essbase Boot Camp – Looking for folks with business background, and technical leanings. Folks who are comfortable in Access, writing simple SQL statements, etc. but are typically fall under the finance umbrella are good choices.
Project Management – Client & Implementation Partner… It is important to have PM’s that have managed HYPERION specific implementations before. They know and understand the pitfalls.
Carried out after the design.
Design will help make the determinations for the build
Application Definition – How many apps?
- Vary by functional business unit?
- Vary by country
- Are we using Workforce, Capex Modules
- # of plan types per app
Plan Types Defined by Application – go hand in hand with dimensionality
Integration – ETL tools, Update Protocol for metadata and data
Building Model – How are different accounts derived? Driver based, simple input. Need to model out the components of the planning process. This drives form and calc development.
Simply define what makes up a planning app
- 3 custom + modules
Classic Planning
- Manage dim’s within planning, not EPMA
- Deploy applications the old way – not through EPMA library
- Business rules, not Calc Manager
- CAN upgrade a Classic App to EPMA
EPMA
- Manage dims and apps within EPMA
- Uses Calc Manager
Review common variants of plan types
Application layout and design…
Driven by:
- Different functional business units
- Different geographic business units
- Can apps coexist?
- Common COA’s
- Common metadata structures – Products, Projects, Entities, Departments?
- Common source systems?
- Common Processes?
- Common Business Rules, and Calculation Definition
Spoke & Hub Model
- Different business unit models for margin
- Common shared services model for common overheads – salaries, capital, G&A expense, balance sheet
- Consolidation Model for aggregated data
Modules – When to use them and why?
Good – Prebuilt FICA w/ limits, Prebuilt Depreciation & Amort Calcs
Bad – Misconception that this cuts down significantly on build time. Unless a company is willing to use out of the box functionality, can still be a significant build effort.
Impacts
- Need to write scripts to move data from Salary Core, Revenue Core, etc..
- Business rule on forms, hourly process to sweep all data
- Plan Type = New Essbase Cube
- Metadata
+ Does your new plan type need all of the same dimensionality as the existing plan types? Will have ETL to limit the dimensionality for the different plan types. Example – does your salary app need your entire COA?
- Data
+ New data loads for additional plan type to be thought through
Highlight the difference between dimensions, attributes, smart lists, and data types
How do you decide between dimension, attribute, smart list, and text/date members, etc.
Dimension –
+ Planning specifically by these members.
+ Select the member to prepare a plan, input by these members.
Attributes Dim–
+ Associated w/ base dim – one to one (no slowly changing in planning yet)
+ Reporting attributes for base members
+ Can display on forms, use to drive form definition
+ Example – Product SKU Base Dim, Attributes could be Brand, Color, Size, etc.
UDAs
+ Primarily for delineation on calcs, BR’s
+ Talleyrand will allow definition in forms by UDA
Other ways to ‘dimensionalize’ smart lists. Create an additional dimension, have all selections for the smart list go into ‘Input Member’, then create the rest of the members as dynamic calcs based on the selection in the smart list. Can make this ‘smart list’ dimension Dense, as it will have only one stored member.
Smart List –
+ Allows user to select an ‘attribute’ or a metric via a text drop down
+ Report on the smart list tag, but cannot ‘group’ out of the box
+ Can create reporting mechanism to expose these
+ Talleyrand – 11.5 Smart List to ASO conversion for reporting…
+ Have to use the planning connection to report on these in FR
+ Display as text, date in planning forms.
EPMA file generator – format not great, similar to HFM dim load format. Much improved though in 11x.
DRM with a simple metadata mart to help manage change control, and loads to various systems. Can use views to support different file formats (Planning vs. Essbase build requirements).
Other Update Methods
- Essbase – Build and maintain outline via Essbase cube, extract using outline extractor (which can be driven via a command line utility and automated). We have done this at a number of clients that have Essbase & Planning.
- Outline Load Batch Utility – Simple upload utility. Requires a specific format. Some ETL might be required to get source files in the proper format. Have used SSIS in the past to do basic manipulations. Some cleanup can also be done on the source extract.
- Manual – Some clients don’t have hierarchies maintained anywhere, and need Planning to be the source for their hierarchy. In these instances, hierarchies can be maintained in planning. New metadata elements can be integrated from data kick outs from loads.
Data Sourcing –
+ Data Marts to support Hyperion applications – EIS / Studio
+ Can integrate w/ existing Essbase application data
+ EDW – commonly source for revenue, units, sales, etc.
Key Considerations
- Does the user need to see historic run rate of information to help with the process?
- If forecast, what’s the process of moving actual data into a new closed month
- What data is collected from users –
- Is the data direct input, or going to be a derivation of supporting drivers and user input
- If there are drivers, how will the drivers be input? Do we want drivers on the same form, different form? Smart list to drive calculations?
- Setup calculated accounts as ‘read only’ on core forms
- Can run business rule or ‘calc form’ on load of form, or on save of form.
The majority of performance issues are related to poorly performing business rules.
Limit what is being brought onto a form – leverage suppression options
Do we have issues with the size of the query, or with poorly performing queries
Target block size – 40k-200k – balance calc vs. retrieval performance. Often times this is a balancing act.
Careful w/ Suppress Missing Block – won’t work if you have a Dynamic Calc member, or Attributes.
No “Calc Dim (Dimension)” on forms
Calcs stack up, kill Essbase performance
If you’re using large sparse dims on rows, leverage suppress missing blocks. Trade-off, can’t use attribute display on the form with suppress missing block.
Grid redesign in Talleyrand – will support larger grids in web forms.
Embedding multiple large sparse dim’s on rows can cause a form to exceed limit of # of cells that can be brought back.
New feature – startup message for blank forms. Can use to have user take an action.
Leverage Beginning Balance as a ‘No Time’ bucket. Leverage a usable alias for forms.
Workaround for not being able to use UDA’s on the forms…
Can drive different form layouts for different items.
In this example have defined two different views: Simple, Enhanced.
User UDA’s to help drive whether the account members need to show up in a simple or enhanced form.
Different forms displayed for different smart list selections.
Right clicks to launch other forms, or run BR’s.
Can pass Page Members to BR’s and between forms
Right click on a member in the grid, and that can be passed to another form or business rule
Tandem –
- Inputting info into a salary form. Input a new employee, want to see salary distribution, benefits and taxes calc’ed after save…
Minimize Calculations –
+ Don’t want to calculate more than what is needed in the form for the user interacting with the system.
+ For example – if a user has access to one cost center, don’t need to calculate ALL cost center’s salaries and benefits when a user saves the form for their particular cost center. Just calc their cost center. Leverage RTP’s and pass from Page.
+ If we want to aggregate data – don’t do a Calc Dim, Do @IANCESTORS(RTP)
Understand Calc Times if using Run on Save / Load
Create Block Issues – Same issue as in Essbase. Particular issue when XREF’ing to another plan type that may not have blocks created.
Groups within groups – problematic in early 9x versions, seem to have stabilized in 11x
AD Groups vs. Native Planning groups – can hinder performance and login times. Need to work w/ security team to troubleshoot and ensure that we are focused on a succinct node, not the entire AD structure.
Read Security on a form means user can access. Write means they can edit – if they are Interactive users. Nothing to do with database level security.