Buyer’s guide FP&A Buyer’s Guide To Planning and Reporting Systems from Alight Planning This Buyer’s Guide is designed to help FP&A teams charged with finding a new planning and reporting software package. We’ve organized the guide from four perspectives: I.

Planning Maturity: Where Do You Want to Be? Budgeting and reporting systems mainly deliver cost savings, but the real opportunity for more meaningful plans and forecasts comes from software functionality that lets you move up the Planning Maturity Curve. Page 2.

II. Getting a Handle on the ROI of a Planning System. Finance must justify its software choice with an ROI analysis. Understanding Type 1 (Savings) and Type 2 (Value Add) benefits will give you a handle on how to approach this thorny analysis. There are cost savings to document, but there are also intangibles such as the impact of a more agile planning regimen on decision making. Page 3. III. Understand the Pain Points; Ask for Solutions . Write down what’s not working with your current system, especially if Excel is your tool, and then ask vendors to demonstrate how their software addresses the pain. This is a fast-track process for sorting through the players and finding a winner. Section III suggests a list of common pain points and the expected vendor solutions. Page 5. IV. Second Level Questions. This last section focuses on functional areas of planning software commonly obfuscated by vendors. We provide you a list of “second level” questions you might ask in the following areas: 1) Multi-dimensional data structures, 2) Driver-based planning tools, 3) Data integration, 4) Flexibility, 5) IT/consulting dependency, 6) User experience, and 7) Consulting, training, and technical support. Page 7

FP&A Buyer’s Guide to Planning and Reporting Systems

I. Planning Maturity: Where Do You Want to Be? We start with a graph of Planning Maturity:

The hypothesis is simple. Companies start by installing straight forward budgeting and reporting tools which add value to the business. The value is accelerated, however, as the organization matures and moves to a monthly or quarterly rolling forecast regime that supplements static budgets with flexible forecasts that recognize changing conditions. This may be followed by what we describe as Agile Planning TM—event driven planning characterized by scenario analysis with real time feedback as key assumptions are tested in a driver-based planning model. What’s important about the curve is the functionality you need in planning software “builds”. You start with basic feature sets for budgeting and reporting—e.g. multi-user support and automated consolidation and rollups to the P&L. Moving to rolling forecasts requires additional functionality—e.g. adding and populating additional time periods and comparing forecasts. Finally, moving to an agile planning environment, the highest level in planning maturity, requires another layer of functionality—especially tools for driver-based planning and in-depth scenario analysis. As you evaluate planning packages, you should think about where you want to be on the curve and the timetable for getting there. A singular focus on the first level, budgeting and reporting, will lead you to a simpler, less expensive package which will probably not work for rolling forecasts and agile planning. Broadening your search to evaluate functionality for higher levels of planning maturity—i.e. forecasting and agile planning—will help you understand the trade-offs and make a better decision.

Page 2

II. Getting a Handle on the ROI of a Planning System Even finance (or especially finance) has to justify the expenditure for a new planning system. On the low end, the price will be $20K, software and services. The high end can be in the millions of dollars for large organizations. Whatever the price, the justification will be some type of ROI calculation. To get a handle on the ROI of a planning system, we introduce the concepts of Type 1 and Type 2 Benefits. Type 1 benefits are savings typically achieved through process cost reductions by making the process, in this case planning and reporting, more efficient and less wasteful. Type 2 benefits are value adds from improved insights into the business leading to actionable knowledge and better decisions at the C-level, by finance and by line managers.

Type 1 Benefits You should expect that a new planning system will reduce cost and inefficiencies in the system. All vendors promise that. For example: End Users spend less time filling in budget templates because:

 Historical actuals can be easily imported into actuals time periods, then copied and pasted into plan periods as starting point placeholders.

 End Users can then adjust and “spread” plan data across time periods without arduous typing.  End users are protected against themselves—i.e. they can’t break the template by inserting line items or building simple models.

 End users are less confused and easily trained because they are working with budget templates for their accounts only. Finance spends less time consolidating and analyzing the numbers because:

 The system is automated and prevents #Ref errors during consolidations.  Data can be analyzed across dimensions—e.g. accounts, organization, and products.  The system automates rollups to the P&L with minimum maintenance.  The system automates rollups to the Balance Sheet with minimum maintenance. Planning software packages should deliver 20% to 40% in Type 1 cost savings. For example, if the organization expends 100 hours of finance and manager time in a typical budget or forecast cycle, then the 40 hours (i.e. 40%) saved across twelve monthly plan cycles represents a cost reduction of 480 hours. Pricing the savings at $80/hour, the Type 1 benefit is $38K a year, not a bad ROI if you paid $50K or less for the system. But not an impelling return if the system cost $100K or more. Big data OLAP systems will cost $500K and up.

Page 3

FP&A Buyer’s Guide to Planning and Reporting Systems

Type 2 Benefits An important measure of value from planning (or any business activity for that matter) should be how it contributes to profitability and cash flow. While the measure is relevant at a high level, it misses the mark for finance in the trenches. Deep down, finance wants what we call Type 2 Benefits which are described by the terms Insight, Actionable Knowledge and Decision Making. Here are some definitions: Insight. If you take time to build financial plans, then the deliverable should be more than just budgetary control or confirmation of targets. A rolling forecast in particular should provide the finance team and manager’s real insights about re-allocation of resources and the financial impact of tactical moves such as price changes or new commission structures. The financial model should be transparent and communicable between the players. Actionable Knowledge. To be truly useful, forward looking financials need to be tied to operational drivers—especially at the business unit level where the day-to-day decisions are made. Actionable knowledge comes from plans with clearly defined operational assumptions that can be manipulated in the planning model and that managers can act upon. Decision Making. We want the big decisions backed up by numbers, and the numbers should cleanly flow into financial plans so that we can understand the P&L and balance sheet impacts of alternate choices. Numbers based, quality decision making is the most important Type 2 value add benefit you should get from a planning system. In our experience, savvy finance teams prioritize Type 2 value-add benefits over Type 1 cost savings in evaluating planning systems. They’ve figured out that simple budget systems are about accounting control, not management action and decision making. Therefore, the feature/functionality conversation with vendors quickly turns to the foundations of Type 2 benefits—especially data integration, driver-based planning and scenario analysis. The potential return quickly escalates multi-fold beyond Type 1 savings where: plans are linked to operational drivers that deliver actionable knowledge; and where decision making is in the context of real time scenario analysis. Here’s a test. Ask the question: how many bad decisions avoided or good decisions made would pay back the $50K or $100K you’re going to invest in the system? Planning software with functionality that delivers on Type 2 value add benefits delivers a significantly higher ROI.

Page 4

III. Document Your Pain; Ask for Solutions Your IT or procurement organizations may want you, the FP&A team, to kick start the purchasing process with an RFP (Request for Proposal) to vendors. That makes sense for very large performance management systems from vendors like Oracle, IBM and SAP. For mid-sized companies or independent divisions of larger organizations, there’s a better way—document your “pain points”, then ask vendors how they will fix them. In effect, your pain points are your RFP, but it’s not the formalized process you would go through for a larger system purchase. Below are a series of pain point issues that many companies, especially those stuck in “Excel Hell”, are experiencing with current planning and reporting. The list is organized by the three levels of planning maturing— budgeting/reporting, rolling forecasts and agile planning. While not definitive, the lists suggest questions you might ask and the answers you should expect, confirmed by demos.

Budgeting & Reporting You want budgeting and reporting that alleviates the pain in the first weeks after implementation. Here’s a suggestive list: Budgeting Pain Point

Vendor Solution

Confidential data leaks—e.g. salaries

User security on distributions/consolidations

All users look at the same accounts

User templates by account and organization

Don’t know who has completed what

Process controls that track budget status

Too much typed data entry for users

Data entry tools—spread functions, copy/paste

Don’t know user assumptions

Line item detail with notes at line item level

Consolidations with too many errors

Structured consolidation with error checking

Formula errors—data integrity

Admin control over formulas and calculations

Trouble with rollups to the P&L

Automated P&L rollups with “built in” intelligence

Can’t compare current/prior versions

Version control with side-by-side comparisons

Can’t compare to historical actuals

Easy import of actuals from the GL with updates

.

The value of budgets and reporting against budget diminish quickly over time as operating conditions and assumptions change.

Page 5

FP&A Buyer’s Guide to Planning and Reporting Systems

Forecasting After fixing a broken budget process, the next focus is forecasting which commonly starts a couple of months after the budget is approved. Especially critical is functionality that lets you do rolling forecasts—i.e. forecasting beyond the current fiscal year (sometimes call “The Wall”). Here’s a list of the most common forecasting pain points and expected solutions: Forecasting Pain Point

Vendor Solution

Too much data to deal with

Forecast at higher levels, not at lowest sub-accounts

Data inputs are too static

Implement driver-based planning using formulas

Too hard to roll the forecast/add periods

Ability to add time periods incrementally to the model

Too hard to “line up” actuals and plan

Mechanics for combining actuals with forecast

Can’t “slice and dice” the data

Support for multiple dimensions with attributes

Too much time revising forecast templates

Easy “tops down” maintenance tools

Not enough time to get forecast done

Fast turnaround on distribute/consolidate

Analysis is too hard to do

Built in analytic tools—e.g. volume/rate causals

.

The value of rolling forecasts and agile planning build cumulatively over time as new insights, actionable knowledge, and numbers based decisions produce results.

Agile Planning The natural evolution of forecasting is to move to an agile planning environment. This is where short and long range planning are event driven activities—e.g. planning in response to a competitor’s price move, or evaluating alternatives for how to expand distribution to the Far East. The focus is on real time analysis and decision making for strategic and tactical issues versus cost control or target setting. Agile planning is characterized by integration of operational drivers into financial plans and extensive scenario analysis. Here’s a list of pain points and solutions for an agile planning environment:

Page 6

Agile Pain Point

Vendor Solution

Changes in assumptions don’t ripple thru

Implement driver-based planning with formulas

Can’t easily create/change scenarios

Tools for finance to create scenarios on-the-fly

Can’t easily compare scenarios

Side-by-side scenario reporting at all levels of detail

Can’t easily maintain scenarios

Modify inputs to multiple scenarios in one operation

Disconnect between multiple plan files

Structures for data transfer and linking files

Slow refresh of model calculations

“In memory” application with rapid calculations

Inputs spread across multiple sheets

Dashboards where you can input assumptions

Can’t calculate performance indicators

Formulas that combine statistical and financial data

Can’t create a balance sheet/cash flow

Integrated balance sheet with “built in” intelligence

.

IV. Second Level Questions All software vendors deliver pretty much the same product demo. They know your “first level” questions and have simple examples at hand to demonstrate. What you want is answers to “second level” questions in critical functional areas. The following materials lay out questions you might ask in seven areas: 1. Multi-Dimensional Data Structures 2. Driver-Based Planning Tools 3. Data Integration 4. Flexibility 5. IT/Consulting Dependency 6. User Experience 7. Consulting, Training and Technical Support

1. Multi-Dimensional Data Structures Dimensions is how you “slice and dice” your actual and plan data—e.g. by accounts, organization structures, regions, products, customers, job titles, legal entity and the like. All credible vendors support multi-dimensional data structures with “drill down”, the ability to double click through layers of information. The questions are how well do they do it and for what purposes. Here is a suggested list of “second level” questions: How many dimensions are supported? 3 is minimum for budgeting; 6+ for forecasting. Do dimensions have attributes? 3 per dimension is minimum; 5+ is optimal. Are dimensions all in one database? Multiple databases may slow performance. Can you use dimensions across revenue, expenses, etc.? You need this for product profitability analysis. Can you use all dimensions for user security? If not, what are the restrictions? Can you use dimensions for structured or ad hoc report filtering? What is the response time when changing dimension filters? Page 7

FP&A Buyer’s Guide to Planning and Reporting Systems

Can you use dimensions as filters for modeling? Do dimension assignments apply to actuals as well as plan? Can dimension assignments apply to actuals OR plan?

2. Driver-Based Planning Tools A major problem with all types of planning and reporting is the disconnect between the operational drivers of a business and financial plans—especially when planning is done in spreadsheets. For example, managers have difficulty forecasting headcount and expenses because templates do not contain models that allow them to relate their spending to marketing forecasts or other operating activities. As well, without ties to operational drivers, finance staff who roll up the numbers have little basis for evaluating the reasonableness of submissions or for answering questions from the executive staff. What’s missing is driver-based planning, a best practice methodology where financial plans incorporate assumptions about business activities which are modeled to drive financial data such as revenue projections, headcount, spending and capital requirements. Here are second level questions about driver-based planning which focus on the software’s modeling capabilities and interfaces: Does modeling involve writing “scripts”? Yes means IT involvement. Can you model at the line item level—i.e. below accounts? This is critical functionality. Is linking “cell based”—i.e. =E25*$L$5? Is Excel the modeling/linking interface? Is linking “object based”—i.e. link to names of things such as “ Product A Units”? Is linking automatic across all time periods, or do you have to do a “fill right” operation? When new time periods are added, do links automatically perpetuate? Is there built-in tracking and reporting of linking relationships? Can you build models using dimensions and attributes? Can you replicate template models across dimensions—e.g. products, customers, regions? Can you make “tops down” adjustments across models—e.g. naming, links, dimensions, formats? Can you build models driven by underlying searches that update when values change? Can you build models with links across plan types—e.g. revenues driving heads or expenses? Can you build models with “actuals” as drivers? Can you model actuals—e.g. back calculate rates, create KPIs for actuals? Is the modeling environment intuitive, easy to use? Ask to see the interface. Does the system architecture facilitate drivers—e.g. easy access to underlying units and rates?

Page 8

3. Data Integration Finance staff spends endless hours with databases, spreadsheets and other tools integrating actual and plan data for budget and forecast templates, financial reporting, graphs and PowerPoints. Without substantive integration of actuals and the lessons learned from both operational and financial histories, we’re just guessing in our financial plans about what may work and what may not. Budgets and forecasts must be grounded in reality. Here are the second level questions about data integration: Is the import process easy to set up and maintain? Is import on-demand by the Admin or automatically “pushed” from the GL or ERP? Can you import “metadata”—e.g. account and cost center names and IDs? Does importing have error checking and log files? Can you import from any source—e.g. GL, CRM, ERP, data warehouse? Can you import to any level of detail—e.g. line item, account, cost center, department? Can you import data creating line items on-the-fly? Can you import line items with dimension member assignments? Can you model actuals—e.g. back calculate actual rates; create KPIs on actuals? Can you export data in multiple formats—e.g. .xls, comma/tab delimited?

4. Flexibility Vendors walk a fine line when designing complex software. At one end of the spectrum, the planning application may automate many specific functions—e.g. computing benefits at the employee level. But doing so usually preempts other approaches—e.g. benefits by job title or headcount. This “my way or the highway” approach to planning can speed up implementation but can also become a serious blocker. At the other extreme, the application may let you create any type of model but doing so requires complex calculation scripts that are difficult to create and maintain. The latter is characteristic of pure OLAP systems such as Essbase or TM1 where you (or more likely a consultant) build your custom application from scratch. The price tag can be enormous. The balance between automation and flexibility is driven in part by where you want to be on the Planning Maturity Curve. Simple monthly budgeting at the GL account level can more safely be automated with built in algorithms. Moving to rolling forecasts and agile planning typically means less automation, especially in modeling where you want the flexibility to do it your way. The more complex your modeling requirements—e.g. a sophisticated commission structure—the more important it is to have a flexible modeling environment but one that is easy to use.

Page 9

FP&A Buyer’s Guide to Planning and Reporting Systems

Here are second level questions you might ask that highlight common trade-offs between automation and flexibility. It’s always a balance: Are plan time periods fixed or flexible? Fixed periods don’t work for rolling forecasts. Are time period totals fixed—e.g. only quarter, YTD and year total? Forecasting requires flexibility. Can a time period be something other than months—e.g. days, weeks, quarters, years, etc.? Can any number of time periods be added to the current set? Can users add line items on-the-fly, or are they restricted to defined levels—e.g. accounts only. Can linking relationships be created at the line item level? Can you link to “anything” in the model—e.g. to any line item, sub-total, total or search algorithm? Can you drive headcount from operational drivers—or are heads always specific employees? Can you calculate payroll taxes/benefits at any level—e.g. employee, job title, total salaries, etc.? Can the Admin create multiple worksheet tabs for different purposes? Can users build separate sub-models—e.g. project spending—that feed the main model? Are there tools for automating the balance sheet—e.g. automatic cash reconciliation? Can the Admin easily create a cash flow statement from the balance sheet?

5. IT/Consultant Dependency Your Information Technology (IT) group is necessarily involved in any networked system including planning and reporting. The question is: how much? High end performance management systems—e.g. Hyperion Planning, Cognos Planning and SAP/BPC—are IT intensive requiring substantial support, especially from the vendor’s consulting group or partners. Most mid-market vendors including SAAS (Software As A Service) providers are IT independent or IT light, though consultants are typically needed for the initial system implementation and ongoing support for certain kinds of activities. We believe finance should substantially manage the planning and reporting process for critical elements such modeling, creating and maintaining scenarios, and report generation. Below are second level questions about IT or outside consultant support. Is the software on-premise or SAAS? There are pros and cons that can be debated. If SAAS, are you restricted to the number of “models” you can build and/or pay for. If on-premise, how long does the software take to install? Is IT/consulting required for software updates and other maintenance? Is IT/consulting required for setting up and maintaining user security? Is IT/consulting required to set up and maintain dimensions? Is IT/consulting required to create modeled relationships—e.g. driver-based planning? Is IT/consulting required to create reports? Is IT/consulting required to create versions and scenarios? Page 10

6. User Experience All categories of planning—budgeting, forecasting and agile planning—involve finance users, executives and line managers at various level of engagement. To support this, planning systems must deliver multi-user security, process controls and a reasonable user experience. The area is complex, however. Functionality varies widely. Here are second level questions. Multi-User Security Are privileges assigned across all dimensions, or restricted—e.g. only Accounts and Organization? Can user interaction be differentiated—e.g. read-only, enter data, modeling privileges, etc.? Is there role-based security—i.e. assign users to pre-defined privilege sets? Can different reports be assigned to different users? Do users have access to “ad hoc” reporting within their privilege sets? Can users be assigned custom dashboards? Can the Admin “preview” a user’s interface and reports before distribution? Process Controls Does the Admin control plan cycles—e.g. timing of distributions/consolidations? Can the Admin include user instructions with distributions? Is there email notification of distributions and submissions? Does the Admin have reporting on status of user submissions? Are consolidation of submissions “on demand” by the Admin or automatic? Can distributions/consolidations be hierarchical? How many levels? After consolidation, can the Admin identify line items changed by users? Are changed line items identified by user and time stamped? User Experience Can users have custom views of their actual and plan data? What types? Do users see (or select from a list) only the accounts, cost centers, etc. they have access to? Can users add and name their own line items on-the-fly to document plan details? Can users add notes to input assumptions? Can users examine details behind modeled line items—e.g. benefit calculations? When users change inputs, are modeled relationships automatically updated? How long does this take? Can users work offline as well as online? Can users save off (i.e. Save As) alternate versions for later submission? Can users work with different scenarios, or only one scenario at a time? Can users create their own reports?

Page 11

FP&A Buyer’s Guide to Planning and Reporting Systems

7. Consulting, Training and Tech Support Most vendors provide consulting, training and technical support for their software. The first level questions focus on the kind of support and price. The second level questions take you many directions. Consulting Does the vendor provide consulting? Is the consulting in-house or through partners? Is the consulting on-site or online? Travel expenses aside, onsite will cost more. Is the consulting billed fixed price or hourly? Fixed requires specifications/change orders. Does the vendor offer special consulting packages? If hourly, does the vendor provide details of billing? Will the vendor provide a pre-engagement estimate of services? Can you meet and approve your consultant prior to engagement? Is your consultant’s bill rate commensurate with experience? Has your consultant built models in your industry before? Can you talk with a customer that has used your consultant before? Does the consultant build you model end-to-end? Do you participate? What level of internal resources should you plan for implementation? Training Does the software include a comprehensive help system? Is there online training? Is onsite training required? Does the consultant do training? Is training done on your own model or a generic one? Technical Support Does the vendor provide installation support? Does the vendor provide technical support—e.g. bugs, crashes, etc.? Does the vendor provide a support hot line? What hours? Does the vendor provide software updates? How frequently? What is the tech support pricing model? Copyright © 2012 Alight LLC. Agile Planning is a Trademark of Alight LLC. This Buyer’s Guide is protected by U.S. copyright laws and trade secret laws. It may also be protected by copyright and/or trade secret laws of non-U.S. countries by international treaties or otherwise. No part of this buyer’s guide may be used, disclosed, reproduced, stored in a retrieval system or transmitted by any means electronic, mechanical, photocopying, recording or otherwise without the prior written permission of: Alight LLC. All rights reserved.

Page 12

www.AlightPlanning.com