onestream - what's possible?

OneStream ‐What's Possible?

Consolidation and Reporting Requirements Clients are Satisfying Using OneStream

Part I

December 18, 2015

Jay Hampton

Agenda

• Finit Introduction• Importance of Design• Requirements Clients Are Satisfying Using OneStream

• Wrap Up

2

Jay Hampton [email protected]

• Partner and Director of OneStream Team

• 11 years CPM Experience (Hyperion and OneStream)

• Assisted over 80 CPM Clients

About the Presenter

Finit Introduction

Finit Delivers Unmatched Experiences

At Finit, we believe that value and success is not just the end achievement of a project – we believe that value and success is achieved through the entire journey and experience of delivering a solution to a need.

Our values, process and craft guide us in this effort:• Advocacy & Integrity• Craftsmanship & Delivery• Stewardship

We combine our values, process and craft with your goals and team to deliver more than just a solution: We deliver an unmatched experience.

Our Culture

We employ approaches inside Finit to align our employees to our values and principles:

• We use employees, not contractors• We actively and continually seek feedback• We base employee compensation on customer satisfaction, not billable hours

• We invest in training and growth in our consultants• We foster innovation and collaboration• We are debt free and are committed to the success of our clients’ programs before the profit of ours

Our Services and Solutions

We craft, deliver, and sustain solutions that improve an organization’s capabilities, controls and insights in the following areas:

• Financial Close & Consolidation• Financial Planning• Profitability & Management Reporting• Integration and Infrastructure

Our Company

• Founded in 2002• 80 employees in 21 states• We provide solutions and support during and after implementations.

• 100 % Project Success Rate Across:• 235+ Clients (19 OneStream)• 450+ Projects (25 OneStream)

• All Finit owners are actively involved in Finit’s operations

Some Finit / OneStream Customers

Questions

Importance of Design

Designers Dilemma

Viability

Feasibility

Desirability

What you WANTthe solution to do?

CAN we do that? Is it technically possible? Do we have the right data? What are the constraints?

Is the solution sustainable? Are we designing something that can be maintained easily?

Our Design Approach

Requirement:

Support Multiple Charts of Accounts

Multiple CoA Overview

• CoA – Chart of Accounts• ERP/GL CoA• Management Reporting CoA• External Reporting CoA

• Multiple CoA Key Points:• Multiple CoA

• Local CoA v. Corporate CoA• Unique base accounts

• Alternative CoA• External CoA v. Management CoA• Utilizes the same base accounts but rolls them up differently

• Metadata maintenance is an important consideration – having Local CoA’s means adding all of those elements and having good governance and communication.

Multiple CoA Possibilities

• Stage stores local GL detail and provides some analysis options.

• A single cube could be used to store all Chart of Accounts.

• Adding Local CoA’s as separate cubes inside OneStream.• If full robust reporting is required at the Local CoA level of detail, having a separate analytical cube best facilitates that.

• Extend the Corporate CoA to add the majority of the detail the local users need.• Having a single Chart of Accounts at a level that can be global while still providing the majority of local reporting needs can reduce the need for separate cubes and help with the governance challenges of multiple cubes.

Multiple CoA Approach

• Understand and finalize the scope of OneStream related to local detail.

• Discover and finalize whether a single detailed CoA can be utilized.• What requirements / needs are driving the need for the local CoA detail? Can it be solved through a single global CoA that contains more granular information?

• Determine the other local detail required beyond Accounts.• Are local Cost Centers, Products, Customers, etc. required?

• Design the Cube Approach• Single cube versus multiple cube.

Requirement:

Multiple Currencies

Multi‐Currency Overview

• Ability to see an entity in multiple currencies or to have OneStream handle transactional to functional translations.

• Seeing Actual data at Budget FX Rates is what we refer to as “Constant Dollar Analysis” which is a separate topic.

• Multi‐Currency Key Points:• OneStream has pre‐built functionality to support the translation of an entity into different currencies (i.e. Entity A is functional currency Euro and it needs to translate into USD).

• Each entity is assigned a currency to facilitate the native translation. No rules or logic is needed to perform foreign currency translation in OneStream for local functional currency to reporting currency.

• For the translation from transactional to functional, OneStream would need to be setup to perform re‐measurement.

Multi‐Currency Possibilities

• Only loading functional currency to OneStream• Storing data in transactional currency and having OneStream perform the translation to functional currency.

• Setting up OneStream to handle multiple currency “overrides”• If you have a Functional GBP entity that you need to see translated to EUR and USD but you want the equity accounts in both instances to translate at “historical” rates (i.e. not EOM rates that the rest of the Balance Sheet uses to translate)

• Creating data management jobs to move data to different scenarios to facilitate comparison between versions.

Multi‐Currency Approach

• Review and understand the types of accounts the transactional currencies will be stored and translated for (all trial balance, select accounts, etc..).

• Review and understand the functional currency information for those entities and how that data will be sourced and loaded relative to the transactional currency.

• Understand how many reporting currencies are required and how equity accounts need to be translated

• Understand the logic and re‐measurement translation logic.

Requirement:

“Automated” Cash Flow

Cash Flow Overview

• Cash Flow Key Points:• Cash Flow in OneStream starts with tracking Balance Sheet Movements through the Flow dimension. The Flow dimension was designed particularly for this purpose.• The Flow dimension can be configured, but typically stores Beginning Balance, Activity, FX and Ending Balance for each balance sheet account.

• Cash Flow accounts are setup to link to the Balance Sheet accounts / Flow dimension. • Operating, Investing and Financing line items are pulled from the Activity members.

• FX Impact on Cash is linked to the FX Flow members.• Roll‐Forward and Memo items play an important role in completing the submission of data needed for Cash Flow.

Cash Flow Possibilities

• Balance Sheet Movements / Unadjusted Cash Flow calculated in local currency at the lowest point the balance sheet exists.

• Roll‐Forwards and Cash Flow Memo Items submitted at a later time than when the Trial Balance is submitted.

• 2 common Design approaches exist:• 2D method (Main Reporting View)

• Tracking of Cash Flow line items by data sources (calculated, adjusted)

• 3D method (Audit View)• Tracking of Cash Flow line items by Balance Sheet Sub‐totals by data sources (calculated, adjusted)

Cash Flow Approach

• Define the level at where the Cash Flow will be initially calculated• We recommend this to be base entities in local currency for proper FX treatment.

• Define the level where Cash Flow will be reported at• This drives the minimum requirements of where roll‐forward, cash memo‐items and non‐cash adjustments need to be made.

• Define roll‐forward and adjustment submissions• Detail the roll‐forward components, submission process and approach.

• Define the presentation approach (2D / 3D)• Define the frequency and time periods

Requirement:

Variance / Bridge Analysis

Variance/Bridge Overview

• Explanation of change from one period to another• Variance/Bridge Key Points:

• OneStream has a pre‐built dimension used to store activity (Flow Dimension)

• Bridge ‘categories’ can be defined and stored in a custom dimension and can be added and applied across the accounts required.

• If bridge detail is calculated / input on parent reporting sub‐totals, separate accounts will be needed.• Parent accounts are calculated from children and cannot be input on.

• Statistical bridge accounts for entry can be created if necessary.• If input is required, forms or Excel templates can be setup and a workflow can be entered in.

Variance/Bridge Possibilities

• Some organizations use the Bridge categories across different activities:• Bridge of information (to Last Year, to Budget, etc..)• Walk‐Across from Forecast to Next Year Budget target

• Some organizations expand their categories to collect more information to help understand the assumptions:• Inflation, Productivity, Market Growth, Price Erosion, Restructure, etc..

• Some organizations add textual information with bridge components.

• Validations can be created and set to compare the sum of the Bridge categories to the true activity. This helps ensure the bridge actually foots.

Variance/Bridge Approach

• Review and understand the level of detail bridge information is submitted (Entity / Account).

• Review and finalize the Bridge submission process:• Frequency of the submission• User workflow process and timing

• Review and finalize the Bridge categories and what can be calculated and what requires input.

• Review and finalize the textual information and validations that may apply.

Requirement:

Pre‐Seeding Budget

Pre‐Seed Overview

• Creating a starting point for users in a Budget/Forecast scenario

• Pre‐Seed Key Points:• The seeding of data can be handled through multiple different design approaches.

• The main driver on design decisions is the timing of the pre‐seed and who will be initiating it.

• Data can be seeded either through a workflow process or through initiating a process to load data.

Pre‐Seed Possibilities

• The most common seeding of data performed by companies is the seeding of Actual data for Forecast (i.e. 3 months of Actual, 9 months of Forecast).

• Some organizations pre‐seed the current forecast with the prior forecast, while others do more of a ‘zero‐based’ forecast approach.

• A few companies have combined modeling with seeding and have seeded data via starting with a base set and then adding drivers to it.• Example is seeding Revenue taking current Forecast with sales growth rates.

Pre‐Seed Approach

• Review and understand all of the pre‐seed relationships between the different data scenarios (Actual, Budget, Forecast, etc..).

• Review and understand the timing of the pre‐seeding and whether submissions may overlap (i.e. Actual and Forecast occurring at the same time).

• Review and finalize the design approach and responsibility for seeding data.

Requirement:

Modeling / Acquisition

Modeling / Acquisition Overview

• Ability to view data with/without Acquisition or some other activity

• Modeling / Acquisition Key Points:• The basis of the item to be ‘excluded’ drives the design approach. • For example, if acquisitions can be determined by looking at the Entity only, alternative entity hierarchies could be created to exclude acquisitions.

• If it can not be defined by some element inside OneStream (i.e. Entity, Cost Center, etc..) we have to look to understand what determines the excluded item and how the data can be sourced and mapped into OneStream.

• The reporting treatment also determines the design• Should acquisitions be excluded for just a certain time period or for all of time?

Adjustment Overview

• Seeing data with / without Journal entries and is similar to acquisitions• OneStream has a pre‐built ‘Origin’ dimension that separates data by the source or origin of where it came from – Import (from a source system), Forms (from web forms or templates) or Journals (from Journal entries). • This dimension can be used to pick any entity and to see data across all sources or origin or just for one.

• Some clients want to further classify adjustment types and report with / without certain types of adjustments. Examples would be US GAAP adjustments, Management Adjustments and Audit adjustments. • For this type a classification, a UD dimension is setup as a data type dimension to track adjustments further.

Modeling / Acquisition Possibilities

• Comparative reporting with / without an Acquisition• Comparative reporting where an Acquisition is excluded for its first 12 months and then included.

• Comparative reporting excluding certain types of adjustments (Non‐GAAP Management)• Some organizations make ‘add‐back’ adjustments to GAAP financials to produce Management results and OneStream can be designed to show with and without those Management, Non‐GAAP adjustments.

• Comparative reporting excluding certain projects or initiatives.

Modeling / Acquisition Approach

• Our process for this item starts with a deep understanding of how reporting with / without acquisitions would be done.• Is there a time period of when acquisitions are included / excluded?

• How are acquisitions stored? Entities, profit centers, etc..?

• Understanding the source data and how that affects the future reporting state ensures the solution can be utilized.

• Finalize the design and approach.

Requirement:

Forecast Process

Forecast Overview

• Forecast Key Points:• Forecast data can be entered either through a web form inside

OneStream or via Excel templates that pull data from OneStream.• The items related to seeding apply to this and we have seen 3

approaches:• Start with Latest Actual + budget for forecast months• Start with Latest Actual + prior forecast for forecast months• Start with Latest Actual + no data for forecast months (Zero based)

• The definition of the Rolling Forecast is important• Is the forecast period always 18 months out (i.e. 3 months of Actual data +

18 months of forecasted periods, 6 months of Actual data + 18 months of forecasted periods).

• Or is the period always 18 months in total (i.e. 3 months of Actual data + 15 months of forecast periods, 6 months of Actual + 12 months of forecast periods).

• The level of detail of where Forecast is planned is important to understand.

Forecast Possibilities

• Some organizations perform their Forecast collection at a higher level of detail in the Chart of Accounts as opposed to the full granularity of the Actual and Budget data.

• Some organizations combine a Forecast with a Risk and Opportunity submission. The most typical approach is a Forecast on quarter months, a risk and opportunities on non‐quarter months with a risk‐adjusted forecast created.• Risk and Opportunities submission can utilize the bridge categories and typically is collected on just a few accounts (Sales, Gross Margin, Operating Income, etc..)

• Utilize a rolling 12 or 18 month forecast to provide more future forecast information.

Forecast Approach

• Review and understand the level of detail the Forecast submission should be collected at (same as actuals or less).

• Discuss the process options and timing of a Forecast collection.• Will the same collection be done always or will a Forecast / R&O approach be used together on different months?

• Finalize the strategy for seeding Forecast.• Review and discuss the process and methodology of the Rolling Forecast.

Requirement:

Driver Based Planning

Driver Based Planning Overview

• Driver Based Planning Key Points:• Companies that adopt driver based planning either put the drivers inside their CPM system or keep drivers outside in excel templates and load the end results.• Excel based drivers tend to be utilized when non‐licensed planners are involved or if a large number of unique local drivers exist.

• System based drivers tend to be utilized to drive standardization as well as when the planners all are CPM users.

• OneStream drivers are calculations of logic and they have the flexibility to be done globally or locally.

• We combined allocations with this topic and allocations differ by those that cross entity (allocate corporate costs to entities) or ones that spread data on an entity (allocate operating expenses on an entity down to product / customer based on sales).

• The biggest challenge to driver based planning is standardization and flexibility.

Driver Based Planning Possibilities

• Some of the most common drivers :• Revenue (based on Price * Volume * Mix)• Freight (% of sales or fixed amount)• % of sales adjustments (pricing givebacks, material economics)

• Direct costs (standard cost & part)• Merit increase (based upon growth factor)• Benefits (based on headcount• Travel (cost per trip * trips)• New Depreciation Expense (based on new capital assets)

• AR / AP (Sales / COGS by customer)

Driver Based Planning Approach

• Form an internal team of key stakeholders• Work to understand different drivers used currently and where commonalities exist / don’t exist.

• Finalize standardized and local drivers• Understand requirements for abilities to adjust driver‐calculated results.

• Understand user base and determine whether drivers will exist inside OneStream or Excel templates.

Requirement:

Intercompany Matching

Intercompany Overview

• Automatic Intercompany Elimination Key Points:• First Common Parent• No ‘Elim’ Entities• IC dimension stores Trading partners.

• Intercompany Matching Key Points:• IC Matching Reports allows users to see all IC booked to them• Can be built into Workflow

Intercompany Possibilities

• Early Intercompany Submission• Some organizations have utilized a preliminary Trial Balance submission to facilitate Intercompany Matching to be run prior to the due date of the full Trial Balance. A sample closing calendar may be:• Day 3 – Preliminary Trial Balance submission due (including all Intercompany data with the correct trading partner)

• Day 4 – all users run Intercompany Matching and build action plans with their counter party

• Day 5 – load final Trial Balance and move through certification steps

• Push Intercompany Matching responsibilities to data loaders• Intercompany Matching reports can be attached to the workflow and run by users as a part of their process

Intercompany Approach

• Define Intercompany Accounts and Relationships• Netted / Gross approach• Matching accounts and location of plug account

• Define Intercompany Trading Partner basis (Legal Entity, Profit Center, etc..)

• Finalize elimination requirements• Process Items:

• Review ability for source systems to map / load to Intercompany accounts and trading partners and need for a manual template

• Review when Intercompany Submission will exist• Review responsibilities of data loaders related to Intercompany during the close process.

See you in 2016…..

See you in 2016…..

• Future Webinars:• OneStream: What’s Possible – Part II• Deeper dive / demo of topics covered in this webinar

• Splash 2016 in Austin, TX• http://www.onestreamsoftware.com/splash/

Presenter:Jay Hampton

[email protected]

General Questions:Greg Barrett

[email protected]

Copy of the slidesEmail us for a copy of the slides or link to the recording

[email protected]

Follow us on Twitter for updates:@Finit_Solutions

onestream - what's possible?

Software