Continuous Planning


Published on

This white paper defines the three core requirements you need to look for if you want to move to a rolling forecast software: Scenario Analysis, Driver-Based Planning, and Integrated Actuals.

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Continuous Planning

  1. 1. With company valuations in the dumpster and credit markets tight, the eco- nomic crisis is forcing hard looks at revenue sources and spending across the board. The economy aside, old ways of doing business are continuously chal- lenged by competitors with innovative business models enabled by the inter- net. These and other socio-economic trends are pressuring finance teams every- where to make planning systems more immediate and responsive. The old way of thinking—you run a company through the once a year budget process—is on the way out in favor of new concepts and system approaches generally de- scribed as “continuous planning”. The practical implementation of conti- nuous planning is through rolling forecasts—frequent updates of financial plans that include integrating actuals data and rolling the forecast time pe- riod beyond the current fiscal year. This white paper explores the concepts and practices of continuous planning with a focus on defining application requirements for integrating actuals, fi- nancial modeling and scenario analysis—the three foundations of a conti- nuous planning system. Alight Planning is an integrated planning and reporting software package that supports the requirements for continuous planning. Application Requirements for Continuous Planning By Rand Heer and Ben Lamorte Beth Anders, CFO for Whitehorse Corp., a $300 million manufacturer of electronic equipment, shook her head. The Ops Re- view meeting, all two hours of it, was a bomb. Peter Forrester, the Planning Direc- tor, was looking glum. Despite three days of preparation, Beth and Peter’s presentation of the rolling forecast left too many unanswered questions about where and how Whitehorse should cut back operations in light of a recent drop in orders and rising inventories. Like most manufac- turers in their industry, the credit crunch had an immediate ripple effect that required action. © 2009 by Alight LLC. All rights reserved.
  2. 2. Application Requirements for Continuous Planning Preparing for the meeting, Beth and Peter Q1 actual spending rates into Q2 fore- realized that the company’s 2009 budget cast months. approved only three months earlier was useless. Whitehorse had missed Q1 sales Modeling inventories. The budget and profit targets by a package included modeling tools. For wide margin. No example, during budgeting Peter could amount of number forecast inventories in the aggregate crunching produced a based on links to cost of sales and as- credible forecast where sumptions about inventory turns. How- Q1 misses could be ever, for the new forecast he needed made up in later quar- more granularity, a model that projected ters. This was a first at inventories by product group and Whitehorse, coming off type—raw, WIP and finished goods. the full year budget at The modeling in the budgeting applica- the end of Q1. tion had an Excel-like formula interface, but it was too restrictive and difficult to The real pain, however, came from working use. Forecasting inventories at a more with the company’s new budgeting soft- detailed level didn’t get incorporated in- ware. Installed the previous summer, Whi- to the forecast. That was an embarrass- tehorse replaced its Excel budget templates ment at the Ops Review. with a high end budget applica- tion built on an OLAP (on line Beth and Peter needed response times analytical processing) database. The new system had seemed to measured in seconds, not minutes or work: cycle times for budget re- hours…They needed a tool that made visions were reduced; line man- collaboration a real time process. agers were less confused over how to input data; and consolidations were Setting up scenarios. While budgeting, faster with fewer errors. Peter used the new system’s versioning Beth and Peter had expected that the bene- capabilities for managing revisions. It fits would continue as they used the bud- worked. For the rolling forecast, howev- geting package for developing a rolling er, it didn’t. The focus this time was on forecast at the end of Q1. However, the new scenarios, also known as “what if” anal- system failed to support several critical ysis*. The problems were maintenance. needs. Here were the issues: Peter couldn’t make structure changes, like adding a line item, across multiple Integrating actuals. Peter was able to scenarios at one time. As well, if he import actuals for January through needed to make a change to an input as- March into the budget package and re- sumption across scenarios—like updat- port variances against budget. However, mechanics were not available for inte- * We use the terms scenario and “what if” inter- grating actuals data into the balance of year plan. For example, he could not set changeably. Both have essentially the same up a model where Q1 actual orders meaning—namely, an alternate financial analy- sis with its own assumptions that are different drove Q2 revenues, nor could he spread from a known starting point or baseline case. Page 2
  3. 3. Application Requirements for Continuous Planning ing rent expense—he had to change you run a company through the budget each scenario one by one. When com- process—is on the way out in favor of new paring scenarios, Peter could compute approaches such as continuous planning, a variances only at the account level. discipline for developing plans and decision There was no visibility into differences making promoted by such organizations as between scenarios of underlying activity the Beyond Budgeting Round Table and drivers. In short, the new budget pack- planning gurus like Rob Kugel at Ventana age didn’t work well for the in-depth Research. scenario analysis that Whitehorse needed. Pulling from the literature, the table below presents the differences between budgeting, Update response time. The budget ap- the historical discipline, and continuous plication’s client server architecture and planning, another way of thinking pro- user security made gathering user in- moted in this white paper. puts easier than with spreadsheets. However, Whitehorse’s current plan- ning situation was not about re-doing the budget. The company needed to make short term decisions about staff- ing, inventory management and other elements of the business, each with ma- jor impacts on profitability and cash flow. During the plan analysis, the cycle time between changing input assump- tions and then viewing the impact on fi- nancials took too much time. Given the sheer volume of analysis required, Beth and Peter needed response times meas- ured in seconds, not minutes or hours. Historically, budgeting has been the com- The Need for Continuous Planning mand and control foundation for running a business—that once a year Uber-process With company valuations in the dumpster that produces a one size fits all binder docu- and credit markets tight, the economic crisis ment with performance targets, bonus for- is forcing hard looks at revenue sources and mulas, sales quotas, headcount and spend- spending across the board. The economy ing controls, standard costs for inventory aside, old ways of doing business are conti- valuation, capital budgets, and Wall Street nuously challenged by competitors with guidance—all based on the same numbers innovative business models enabled by the with the same underlying assumptions. The internet. With instant access to product in- budget also becomes the company official formation and comparative pricing, cus- forecast for at least two quarters because no tomers rule as never before. manager admits to not being able to “make budget” sooner than Q3. That’s the politics These and other socio-economic trends are of budgeting. pressuring finance teams everywhere to make planning systems more immediate Few finance organizations are ready to and responsive. The old way of thinking— dump budgets per se. However, many are Page 3
  4. 4. Application Requirements for Continuous Planning looking critically at their spreadsheets or problems preparing for the Ops Review canned budgeting applications asking how meeting that bombed. they can deliver more immediate and res- ponsive financial plans. In particular, Actuals—the issue is not whether an finance is getting more serious about roll- application can import actuals data; all ing forecasts that incorporate a senior level of them do. The issue is how well im- involvement in core operational issues and ported actuals can be integrated into the their financial impacts. forecast plan. Many organizations already do rolling fore- Modeling—the issue is not whether an casts, principally Fortune 500 companies application includes modeling tools; all where the discipline is ingrained. Here, the of them do. The issues are how flexible challenge for finance is to find ways to are the tools for building complex driv- make the process less political, especially in er-based models and how easy is it for dealing with hockey sticks forecasts. the super user, people like Peter, to build and maintain the models. Requirements for Continuous Planning Scenarios—the issue is not whether an As Beth and Peter discovered, there can be a application supports versions and sce- big difference between a budgeting applica- narios; again, they all do. The issue is tion and what’s needed for real planning— maintaining the scenarios, visibility into in their case, implementing a rolling fore- the underlying activity drivers of each cast process that’s heavily focused on mod- scenario, and response times. eled elements, scenario analysis and near term decision making. The materials that follow describe these is- sues and show how Alight Planning han- Whitehorse’s dilemma sets the stage for the dles the functional requirements. theme of this white paper: what are the most important functional requirements to Integrating Actuals look for in a software package for imple- Virtually all budgeting appli- As Beth and Peter discovered, there cations support importing ac- tuals from the general ledger, can be a big difference between a bud- typically based on rigid chart geting application and what’s needed of accounts structures. As for real planning, in their case a rolling well, you can usually import headcount and salaries from forecast… the HR system. Once im- ported, budget applications also support menting continuous planning—and its not comparing actuals to budget based on levels so distant cousin, rolling forecasts? in the chart of accounts with computation of In the materials that follow, we walk amount and percentage variances. through three software feature/function Outside the safety of the accounting struc- areas that are central to all planning appli- tures, however, lining up actual and plan cations, whether simple budgeting or more data in a continuous format for a rolling sophisticated planning. Not so coincidental- forecast is typically a zoo, principally be- ly, these are areas where Beth and Peter had cause it is difficult to get actuals data ap- Page 4
  5. 5. Application Requirements for Continuous Planning ples-to-apples with plan data at the line cally imported from a data warehouse or a item level. CRM system. For example, for basic revenue planning: Finally, in our Whitehorse story Peter dis- covered with the budgeting application that Units * Sell Price = Sales Amount he could not set up a model where Q1 actual 500 * $100 = $5,000 orders drove Q2 planned revenues, a severe For actuals, however, you get the data whe- limitation. For robust continuous planning, rever you can, and the data is typically you must have the capability of truly inte- amount and units. Therefore, for an apples- grating actuals into the financial plan. That to-apples comparison across units, price means: 1) being able to model actuals as an and amount, the actuals data must be mod- activity driver for the rolling forecast, and 2) eled to back calculate the sell price: spreading actuals data into plan time pe- riods—e.g. projecting last month’s actual Sales Amount / Units = Sell Price spending run rates into future months. $5,000 / 500 = $100 As the examples illustrate, actuals data fre- quently need modeling different from plan data to get valid comparisons and trends. For maximum flexibility in setting up roll- In Alight, you can create data relationships where ing forecasts, the planning application actuals are activity drivers for plan. In the example, Product A unit sales drive Product B sales with a two should allow modeling of actuals with algo- month time lag. Note that Product B’s forecast sales rithms and linking separate from modeling for Jan 09 are the same as Product A’s actuals for Nov 08—i.e. actuals are integrated into plan. of plan data. In Alight, you can “spread” actuals data into plan timeframes. In the example, Feb 2009 actual spend- ing rates for Legal, Accounting and IT Service fees are spread into the plan time periods Mar and Apr 2009. The spread action on multiple line items is done in a single operation. Driver-Based Modeling Alight includes separate tabs for modeling actuals and plan at the line item level. In the example, plan Budgeting focuses on gathering static in- units * rate = amount. For actuals, amount / units = rate. puts from users, principally for headcount and expenses. Little modeling is involved— In addition, actuals data need to be im- typically just calculation of payroll taxes ported from any source at any level of detail, and benefits. not just the general ledger. In the above revenue example, the actual sales amount is Such a process is not workable for conti- imported from the general ledger, but units nuous planning, especially in the context of for back calculating average price are typi- rolling forecasts. The cycle time for complet- ing a forecast after month end close is too Page 5
  6. 6. Application Requirements for Continuous Planning tight to accommodate broad based user in- ships based on the names of things—e.g. volvement on the scale done for budgeting. Commissions are linked to Net Sales and As well, user based planning involves high the Commission Rate is 5%—versus cell volumes of static inputs in order to achieve based linking in Excel with formulas precision. By contrast, continuous planning like = Sales! C45 * $L$15. Object based needs to reduce the volumes of data, focus- linking makes auditing and visibility in- ing instead on fewer truly material forecast to activity driver relationships signifi- elements. cantly easier to track, thus eliminating many errors, speeding up development The objective of reducing data volume is and reducing maintenance time. achieved in part through “driver-based planning”, a type of financial modeling where the most material items in a financial plan are linked to operational drivers or quantifiable activities of the business —e.g. volume measures such as units, transac- tions, subscribers, customers, call levels, hours, installations and the like. Such driver-based modeling has three fo- cuses: 1) revenue forecasting based on the Alight’s modeling interface is based on object-based volume measures and driver relationships linking where you create data relationships by link- between products, 2) variable and semi- ing to the names of other line items or totals. Linking automatically operates across all time periods—i.e. variable headcount and expenses driven by no fill right as required with spreadsheets. the volume measures or identified underly- ing activity levels; and 3) for cash planning, Modeling across dimensions. Planning balance sheet items such as inventories, ac- applications should support custom di- counts receivable and accounts payable, mensions—e.g. product, customer, each based on their respective P&L drivers channel, region, project, job type, grade at a relevant level of detail. level, etc. The modeling environment should then allow tapping into the cus- Companies moving to a continuous plan- tom dimensions for building specialized ning discipline should closely evaluate the activity-driver models—for example, modeling environment of the planning ap- aggregating sales line items by channel plication they are buying into. Modeling to drive channel specific discounts; ag- and model maintenance should be fast, flex- gregating employee salaries by job class ible, and (unlike Excel) provide clear visibil- for driving tiered bonuses. Applications ity into linking relationships. without modeling based on dimensions do not have the flexibility required for In our experience, there are two make or driver-based planning. break functionalities in the modeling inter- face needed to make driver-based planning Robust Scenario Analysis work: Budgeting is about managing versions, not Visibility into driver relationships. scenarios. As the budget is developed, This requires object based linking where finance keeps track of versions to under- the modeler establishes data relation- stand who changed what and to make sure Page 6
  7. 7. Application Requirements for Continuous Planning the right amounts are approved. Once a satisfy the need for speed we’re used to version is superseded, there is rarely a need with Excel. Scenario analysis must be an to look back at the old numbers or change interactive process responsive to ques- them. tions and testing of assumptions on-the- fly. Continuous planning needs tight By contrast, continuous planning is about feedback loops on the numbers. scenarios, lots of them. If you can’t predict the future, the next best thing is to set up scenarios that let you explore how you might behave (or decide) if things are better or worse or just different. Unlike budgeting where you care about who changed what number, scenario analysis is about under- standing what’s behind the numbers—the most critical assumptions, volume and rate impacts, and especially what’s driving ma- terial changes to the P&L and cash flow. Unlike budgeting apps, in Alight you can change values of line items across multiple scenarios. Click- The deliverable of scenario analysis is ac- ing the Scenario button lets you choose which Sce- narios you want to apply the new values to. Updates tionable knowledge. By analyzing a specific to financials are immediate. scenario and comparing it to a baseline case or other scenarios, the management team is Maintenance across scenarios. Budget better able to evaluate best courses of ac- versions don’t require ongoing main- tion. Where there is an immediacy to the tenance because old versions are super- issues—e.g. to proceed with a capital project seded by new ones. Scenarios do. The or change pricing—the deliverable is deci- planning application should support sion making. Because it’s decision and ac- adding, modifying and deleting line tion focused, robust scenario analysis is the items across selected scenarios in a sin- most critical underpinning of continuous gle operation. Calculation and update of planning. financials after structure changes should take only a minute or two, at most. The functionality you need for effective scenario analysis goes beyond simple budg- Robust comparison at the line item et versioning. Here are our criteria: level. Budgeting focuses on amounts in accounts. Continuous planning is about Real time feedback. Whether you’re a in depth comparison of scenarios and financial analyst working through the differences in values at any level of de- numbers late at night or the CFO ans- tail, especially at the line item level wering questions live in an operations where the most significant inputs and review, scenario analysis should be de- modeling occur. Where the underlying livered by the planning tool in real time. data or links are available, scenario That is, when you change a value, all comparisons should reveal variances in elements of the financial model—the underlying unit activity drivers and P&L, balance sheet, cash flow, financial rates. ratios, performance metrics—should update in seconds, not minutes or hours. In short, scenario analysis must Page 7
  8. 8. Application Requirements for Continuous Planning COMPARISON OF SCENARIOS WITH VOLUME/RATE CAUSAL ANALYSIS: Alight lets you compare scenarios at any level of detail including analysis of underlying units, rates and amounts. In the report below, the scenario called 2009 Downside is compared to the scenario 2009 Base Forecast. Each scenario has underlying monthly data. The right hand column is a causal analysis that computes by line item the amount variance between scenarios and the volume and rate components of the amount variance. Analytic tools. Scenario analysis should Summary incorporate related analytic tools such Continuous planning and rolling forecasts as: require special features that extend beyond the capabilities of spreadsheets and many Sensitivity analysis: Tools for iden- budget applications. Actuals data must be tifying the most and least sensitive available for driving forecast values. Model- input assumptions and calculating ing tools must be robust and provide trans- their impacts on sales, profitability parency into underlying activity drivers. or any target in the plan. Scenario analysis should be real time with Goal seek: Here’s how: 1) choose a maintenance across scenarios. It should in- target such as operating profit 2) clude supporting analytic tools. specify a financial goal—e.g. $1 mil- In a continuous planning environment, the lion 3) select an input variable—e.g. return on investment is not from reducing unit sales. The application calculates time spent on planning. The ROI comes how many units are required to from better financial performance as a result achieve the $1 million profit goal. of a more responsive planning environment Causal analysis: Where underlying and improved decision making. units and rates are available, com- _______________________________________ pute volume and rate variance im- Rand Heer is President of Alight LLC and the pacts between scenarios. (See exam- creative force behind Alight Planning. He was ple above.) also the founder of Pillar and designer of Hyper- Dashboards: Display key perfor- ion Pillar, the first enterprise software for budg- mance indicators that update as sce- ets and forecasting. narios are changed. Allow display and rapid update of input assump- Ben Lamorte is Vice President, Sales at Alight. Previously, he headed his own consulting firm tions from the dashboard. specializing in complex model building for such companies as Adobe, Kaiser and PlanetRX. Web: (530) 622-5485. Page 8