PBCS Is Still Hyperion Planning - US-Analytics

PBCS Is Still

Hyperion PlanningBrian Marshall

US-Analytics

Agenda• Introductions• Technical Comparison• Functional Comparison• Implementation Strategies

– New Planning Implementation– New Financial Reporting Implementation– New Operational Reporting Implementation– Migrations from On-Prem

• Customer Success• Rapid Start Thoughts• Questions

Brian Marshall

• Director of Planning and Essbase Practice

• 15+ years IT and EPM/BI Experience

• 13+ years with US-Analytics

• 100+ projects with US-Analytics

• Presented at Kaleidoscope 2010-2016 and various regional events

• Frequent blogger at HyperionEPM.com

US-Analytics

We are nimble and respond quickly to customers’ needs

• Over 500 clients and over 1,000 successful Hyperion engagements

• Seasoned business and technical acumen with EPM and BI initiatives

Over 65 professionals with 12+ years each of Hyperion experience and certifications

Active leaders in the Oracle community

Founder of Hyperion Professional Women's Forum, advisory board leadership,

conference presentations, webinars, EPM Speaker of the Year at Kaleidoscope in

2015 and 2014 Corporate culture of integrity with 100% customer commitment

Managed services

Managed services team is Dallas based, each with 10+ years of experience

Proven processes for all aspects of managed services

Comparisons

Functional• So how different is PBCS from our traditional On-Prem

solution?• Functionally...the difference is marginal• The cloud accelerates certain aspects of your

implementation, like infrastructure• But don’t let it fool you…they are still very much the

same implementation• The timeline shouldn’t shorten or extend much based

on the choice between On-Prem and the Cloud

FunctionalOn-Prem Smart View

• Shared connections to all installed products

• Connect with Essbase for Ad Hoc

• Regular Sign-In Prompt

PBCS Smart View

• Shared Connections to only the single PBCS app

• Connect with Planning for Ad Hoc

• Web-Based Sign-In Prompt with Domain (which can be saved)

FunctionalOn-Prem Workspace

• Sign-In to Workspace

• Workspace gives us access to other apps, not just Planning

PBCS Workspace

• Sign-In to Cloud Services which redirects you to Workspace

• Emphasis on Simplified Interface

• Works well since we don’t have other applications

TechnicalOn-Prem Calculations

• Business Rules

• Calculation Scripts

• MaxL– Execute Calculate Scripts

– Execute ASO Clears / Calcs

• Calc Manager Command Line Launcher

PBCS Calculations

• Business Rules

• EPM Automate Utility

TechnicalOn-Prem Data Loads

• Essbase Load Rules– SQL

– Flat File

• Essbase Import

• FDMEE

• Outline Load Utility

PBCS Data Loads

• Essbase Import

• FDMEE– 11.1.2.4.200 Hybrid

– Cloud-Based “Lite” Version

• EPM Automate / Workspace– Essbase

– CSV

TechnicalOn-Prem Data Exports

• Essbase Export– Level 0

– Full

• Calculation Scripts (inc. SQL)

• Business Rules (inc. SQL)

• FDMEE

• Outline Load Utility

PBCS Data Exports

• Essbase Export– Full only – LCM

• Business Rule (excl. SQL)

• FDMEE– 11.1.2.4.200 Hybrid

– Cloud-Based “Lite” Version

• EPM Automate / Workspace

TechnicalOn-Prem Data Exports

• Essbase Export– Level 0

– Full

• Calculation Scripts (inc. SQL)

• Business Rules (inc. SQL)

• FDMEE

• Outline Load Utility

PBCS Data Exports

• Essbase Export– Full only – LCM

• Business Rule (excl. SQL)

• FDMEE– 11.1.2.4.200 Hybrid

– Cloud-Based “Lite” Version

• EPM Automate / Workspace

TechnicalOn-Prem Security

• Shared Services– Direct Active Directory

Integration

• Planning– User and Group Level

PBCS Security

• My Services– Active Directory Integration

with Federation Services

• Planning– User and Group Level

TechnicalOn-Prem Essbase

• BSO (3 Plan Types)

• ASO (10+ Plan Types)

• ASO Reporting Cube

• Hybrid Support

PBCS Essbase

• BSO (3 Plan Types)

• ASO (3 Plan Types)

• ASO Reporting Cube

• No Hybrid…yet

Technical

TechnicalOn-Prem Automation

• MaxL

• Outline Load Utility

• Move Files with Batches

• FDMEE

• Job Scheduler

PBCS Automation

• EPM Automate

• Job Scheduler

• Move Files with EPM Automate or SFTP

Implementations• New Implementations

– Financial Planning– Operational Planning– Financial Reporting– Operational Reporting

• Migrations– Number of Apps– Number of Plan Types– Integration and Automation

• Hybrid Cloud / On-Prem

About The Client - MV Transportation

• Largest private provider of paratransit services and the largest privately owned transportation contracting firm in the United States

• Over 130 operations in 28 of the United States, the District of Columbia, two Canadian Provinces, and Saudi Arabia

• Over 17,000 employees

• Over 10,000 vehicles in service

• Over $1 billion in annual revenue

Assessing the Situation

• US-Analytics was engaged to assess the application and work done to date• The application had a myriad of problems

– The account dimension was built at the wrong level, causing massive performance problems

– Data didn’t tie to the ledger– Virtually all forms were unusable– The one form that was theoretically usable performed so slowly that it was

problematic as well– Only simple business rules were created for aggregations, data clears, and

simple data copies– No automated processes whatsoever

The Account Dimension

• The majority of the problems with the application revolved around the account dimension

• Built at the sub-account level, the dimension contained over 4,500 members

• This isn’t a problem… except that they don’t plan at the sub-account level

• Instead, they plan at the account levels

• The upper level members contained “made up” account numbers rather than just using the name and having no alias

• This made it difficult to look at account numbers at level 0 and the parents at the same time

The Data

• The data did appear to tie for the most part at level 0

• Because no automated processes existed yet and training had not been completed, new entities were not yet added, causing even level-0 issues

• At upper levels, the data didn’t tie at all

• This was found to be related back to the root of all evil in our original application: the account dimension

• Many of the consolidation operators were incorrect, causing data tie-out issues above level 0

Form Issues

• With only one form that served any usable purpose… this form somehow still had significant issues

• The form was built using cherry-picked accounts at the top and then IDESC at the bottom, effectively doubling the number of accounts on the form

• This meant that the form was taking an incredibly long time to load

• Also contributing to the load times: sub-account

• Back to the root of all evil

Fixing the Initial Implementation

• MV needed to be operational quickly so that they could finalize their budget and perform consolidated financial reporting

• First we had to export all of the data to make sure that any data that had been budgeted could be restored once the application was fixed

• Made great use of the test environment provided by PBCS

• Identified the key areas to get things up and running

– Fixing the account dimension– Fixing the data tie-out issues– Loading consolidated financial data

Fixing the Root of All Evil

• First we stripped out the sub-accounts, leaving accounts as our lowest level

• This reduced the number of accounts from 4,500 down to roughly 1,500

• Next we fixed all consolidation operators

• Finally we reloaded the data back into the newly structure model

• The operational income statement was fixed!

Not Quite as Evil

• Next up was fixing our form

• The form was re-built from scratch with the new account structure in mind and performance was massively increased

Consolidated Financial

• MV uses a very complex mapping to arrive at consolidated financials

• This mapping is at the sub-account level… and the company level… and the business unit (entity) level

• The code behind this mapping is over 900 lines long and found only in a stored procedure

• This was the reason for sub-account in the first place… but without company, it was a fruitless pursuit

• So why try to re-invent the wheel?

• Instead, we use FDMEE to roll the wheel into our PBCS application, but still provide the users with the detail necessary to see how the data got there using drill-through

Consolidated Financial

• MV uses a very complex mapping to arrive at consolidated financials

• This mapping is at the sub-account level… and the company level… and the business unit (entity) level

• The code behind this mapping is over 900 lines long and found only in a stored procedure

• This was the reason for sub-account in the first place… but without company, it was a fruitless pursuit

• So why try to re-invent the wheel?

• Instead, we use FDMEE to roll the wheel into our PBCS application, but still provide the users with the detail necessary to see how the data got there using drill-through

Can Rapid Start Succeed?

• The short answer is of course, but not nearly as often as many companies, including Oracle, will make that promise.

• A Few Scenarios:

– Do you have an existing process that needs to be closely followed, if not re-created?

– Are you relatively new to Planning and Forecasting where anything outside of Excel is an improvement?

– Are you actually going to use PBCS for Planning?

– Do you want a fully automated and integrated solution?

– Do you have many disparate data sources?

Questions?

Shameless Blog Advertisement?