What to Forecast?
In previous articles I covered the fundamental planning questions of "Why Forecast?" and "How to Forecast?" and now it is the turn of "What to Forecast?".
There are no limits to what you can forecast and in Business there are plenty of predictions from Annual Budget to Daily Goods-In Schedules. The Diagram above provides a broad but by no means complete list of examples of data that can be collected and predicted. For the purpose of this article, I will be focussing more on Demand Management processes, but the principles herein can be applied generically.
When I work with a client for the first time the primary questions are almost always: What do you Forecast and Why? "We forecast Finished Goods Demand for Manufacturing" might be the response and you might think that would be enough to answer the article question but actually, what you forecast is defined by the structures of your Demand Planning solution.
The Right Structure
Whatever it is that you forecast, you need structure to create the rows and columns in your Excel spreadsheet or Demand Planning system. More formally, you need Dimensions, Hierarchies & Data Streams.
Dimensions are structured with Hierarchies that provide Levels to manage Data. For example, the Dimension of Time can contain the Hierarchy of Gregorian Calendar (Day <-> Month <-> Quarter <-> Year) with the Data of days.
Demand Planning Dimensions are typically Time, Location and Product with the Location Dimension structured by multiple Hierarchies of Organisation, Customer & Sales Territory. You can have multiple Dimensions, Hierarchies and Data Streams and while a bigger structure means greater insight it also equals greater complexity and data management.
Loading data into your planning solution isn't just about the level that you work but how you get to work at it. Hierarchies are required to make logical sense of the data. Levels within those hierarchies are then used to create statistical forecasts, slice the data for distributing to the planners and places to edit, review and publish the data.
Be careful when including Dimensions and Hierarchies in your Demand Planning solution when those structures are not used by planners. Typical examples here are Distribution centres, Manufacturing Sites or even Customer Ship To. The Right Structure will be dictated by your available data and the level at which the Forecast is created, maintained and published.
The Right Data
With a Dimension and Hierarchy Structure in place, we can now look at the Data that can be held in that structure. There are Historical Data Streams, Future Data Streams and Data Streams that are both past & future. Historical streams tend to be inputs to the Demand Planning Process and Forecasts are typically the outputs. The Diagram below present some typical examples.
As you progress through your time horizon some Data Streams will move from the future to the present and then into the past. For example, imagine publishing a forecast today for the next year... in one months time, the first period of that forecast data stream will be historical and in two years' time it will all be historical forecast.
Prepare to think creatively with your data streams. Historical Data can be lagged into the Future to become a Forecast Stream. This is especially useful for comparing current Forecast to the same period the year before. Take this a step further... a lagged historical data stream, add a percentage adjustment calculation and you have an instant easy Forecast - no need for Engines. How often have I heard from Sales: "I just want last year with an uplift factor!"
Selecting the Historical data type (such as Orders, Shipments or Invoices) is the first of two related steps - the second step is to select the date method. Take Sales Orders, they can be collected by Booked Date, Requested Date, Promised Date, Shipped Date or Invoiced Date. The date selected is the Time bucket that the volume will be held in and, if you are using a Statistical Engine, this will form the basis of your Forecast Shape.
In other words, Sales Orders by Invoiced date will generate a Forecast of what can expect to invoice. This is clearly not the same as what you expect to Purchase or Manufacture. Best Practice for Demand Planning is to generate a Forecast based on what the Customer Requested - even if the dates were impossible - because this generates a forecast of what your customers wanted rather than what you delivered. This might result in lower accuracy (because the impossible is impossible - right?) but it drives improvement.
There can be issues with a Requested date though. Typically, there will be orders that don't have that date defined, or orders where it is changed, or orders with request in the past, or perhaps you have incompatible ERP sources that don't use the same definitions. A common compromise is to use an Invoiced date because you know the order was completed or because it's the same date for different business processes or is gathered from a consolidated Business Intelligence repository.
Months of discussion and analysis can be consumed by the pros and con arguments for Date Type. My recommendation would be to try and determine if there is any actual difference between the resulting forecast shapes. Create forecasts generated using Requested, Shipped and Invoiced dates and analyse them. If the variations are all within the same period of time - it probably makes no difference. If the shapes and totals are different across time, then the right date format could be very important for your downstream activities.
I accept that this approach is difficult when considering a new solution as you need the solution implemented before you can assess properly how it should have been defined! This will be the subject of a future article and if you are interested in the implications, please get in touch.
Another option here is to collect more than one Historical Data and Date Type and create different Forecasts from them. Segmentation and analysis of suitability are the key here (and a system solution that can be capable of managing that much data). Flexible solutions, where you can switch from one data source and date type to another without re-implementation, are advantageous and very powerful.
Cause & Affect
Another key element to consider when defining what it is that you want to forecast is the impact on your business of causal data. Causals can be Global (affect everything) or Local (specific to a location or product) and there are a vast and ever-increasing number that can be tracked: promotions, the weather, social media, competitor stock-outs, fashion, sustainability factor, shelf location and so on.
Although causals can be different from business to business the methodology is broadly similar: Collect the data (such as promotional information) and apply it into the past and the future - then your Statistical Engine and your Planners can measure the past promotions against history and use that information to model the impact where those promotions are planned to be.
There are virtually unlimited causals out there but the key factors to consider are: how easy is it to collect and apply it to your combinations? Solution providers will crow about the power of casuals and how the Internet of Things will transform your forecasts but be careful of biting off more than you can chew. Loading, creating and maintaining causal data can be an intensive activity. If you are implementing a new solution, casual configuration is better achieved as an incremental activity after the solution is bedded in and understood.
Attributes
Causals affect your data, but Attributes help planners to slice and dice and to focus on segments of information. Attributes can be managed as Hierarchy Levels or as Data Streams or in separate Plans or Filtered Worksheets or a drop-down function... there are many options. Attributes are typically things like, Order Type, Colour, Weight, Packaging, Country of Origin, Life Cycle etc. Match the attribute solution method to user functionality - they should be slick and easy to use.
Casual information and attribute control are one of the elements that can take your planners and your forecast up a maturity level. Causals are difficult to obtain and use (especially in older Legacy applications) but if you can automate and evaluate them, they will give you a better forecast and a serious competitive edge.
The Lowest Level of a Thing
Finished Goods SKU's, Bills of Material with their components and Spare Parts are the most common lowest level of the product being forecasted and these three types typically require different Hierarchies to function optimally. Managing all three in the same solution will likely compromise data management and also create performance headaches.
Push or Pull?
What you forecast can but can be further refined by whether the data is unconstrained or not and whether there are usage impact rules. Is the forecast to be used for Planning and Allocation or is it for Replenishment? Both options require rules to be defined. Planning and Allocation often requires less setup but creates more effort inside the forecast cycle whilst Replenishment will usually reduce forecast cycle tasks at the expense of higher up-front setup effort. Demand Driven Forecasting - where Point of Sale data provides a signal to purchase, make & deliver (based on re-stocking rules) can be a powerful and efficient process but will not be suitable for all businesses.
Volume or Value?
Is the initial source of your Demand Plan the Sales Forecast? This can create compatibility and conversion problems as the Sales Forecast is often defined in value ($) while the Demand Forecast will be defined in volume (Qty). The approved Demand Plan will then often be converted back into value for the Revenue Forecast. Managing accurate fiscal values in a Demand Plan can be extremely data and resource intensive. Prepare to compromise with conversions and decide whether a 'One Number Forecast' is really achievable or sensible.
Other Factors
This article has covered the structure and data that defines 'What to Forecast' but there are a myriad of other elements such as Horizon, Process, Industry, Performance Indicators & Reporting, Organisation Structure, System selection, Cycle time, Planner Maturity, Ownership and Bias that can have a serious influence on what you predict. I will be covering these elements in further articles provisionally titled 'When to Forecast', 'Where to Forecast' & 'Who Forecasts'.
Garbage in Garbage Out
What and how well you forecast is defined by the Dimensions, Hierarchies & Data that you collect, the suitability of the System selected and the maturity of the planning team that runs the process. Master Data should be clean and easy to maintain, Hierarchy data must be logical and compatible from Collection through to Publish, Data Streams, attributes and functions should be selected by and for your planners and not compromised by additional users' requests. It is possible to make a limited forecast structure produce a better forecast with training and extra resource but ultimately, if the structure is incorrect, your forecast will suffer.
__________________________________________________________________________
Articles in this series are:
If you have any questions, thoughts, additions, queries or contentions about Demand Planning, Oracle Solutions or even grammar reflections please get in touch.