It’s an age-old question. Should forecasts be done at item (product) level or at a higher level? Obviously, you need a forecast at product level to tell you what to make. And if you ship from more than one location, you need forecasts at product and location to tell you where to have it. But what is the best level at which to run your statistical forecast?
Bottom-up or Top-Down?
Bottom-up runs statistical forecasts at a SKU level and then aggregates up to family and category. Top-Down runs statistical forecasts at a higher level, such as product category, and then disaggregates to product and location. Here’s a good article on the difference between top-down and bottom-up forecasts: http://www.forecastpro.com/Trends/forecasting101January2009.html.
You might run forecasts at different levels for different purposes. Short-term forecasts used for the next several production and deployment cycles require much more granularity than long-term forecasts used for Strategic Planning or Sales and Operations Planning (S&OP).
Aggregating Forecasts
Pretty much everyone runs their statistical forecasts at some aggregate level. Even running stats at a product level usually involves aggregating data for multiple locations and customers. But is that the right level of aggregation? Is there distinct seasonality or trends between customers or locations that indicates they might be different populations? Or do multiple products have similar enough seasonality and trends that they could be treated as one population?
If market forces are the same and the lower-level data are statistically similar, forecasting at an aggregate level will usually give a more accurate forecast, even at product level. With a larger population, there is less impact from “noise” (random variation) that could skew the forecast. With more data, there is often a more pronounced structure, making patterns easier to recognize and forecast.
Identifying Forecast Groups
One key question is how to identify which products are statistically the same with similar trend, seasonality, and marketing. These can be aggregated for stat forecasts. Where I could do this, I’ve seen forecast accuracy at product level improve.
It is possible to analyze the data and do statistical tests for whether different materials belong to the same population. What if you have hundreds of products and hundreds of customers across multiple locations? The number of possible combinations is astronomical. Without sophisticated big-data tools, this analysis is unmanageable.
Planners can use their knowledge of market forces to quickly divide products into broad classifications that should be forecast separately. Different product categories, markets or distribution networks suggest distinct populations. Cookies and Crackers have different seasonality. Food Service and Convenience channels have different seasonality. Frozen and ambient products have different distribution. The product and customer hierarchies in your accounting or ERP systems will probably help you make these divisions.
Within these broad classifications, market forces may vary by category. In some categories, different pack sizes may have different trends. Sometimes similar flavors will have similar seasonality across multiple pack sizes. This is where planners should try slicing data in different ways to see what combinations have similar seasonality and trends. It is likely that the groups you come up with do not align perfectly with existing customer and product hierarchies in your accounting or ERP systems.
Visualizing Product Groups
I’ve had success using pivot charts in Microsoft Excel to visually analyze historical time series data and identify groupings. Even though we had data at weekly level, we consolidated to monthly so seasonality and trends would be easier to identify. The spreadsheet included material and location as well as SAP customer and product hierarchies.
We started with broader groups using planners’ market knowledge as described above. We used the pivot charts in Excel to drill down by material, customer chain, pack sizes, flavors, locations, and products. The pivot graphs helped us visually compare different settings for these attributes to see if they had similar seasonality and trend.
Most of the resulting forecasts groups were products of similar sizes or similar flavors for a specific distribution channel. There were also a few customer chains with unique historical patterns on some materials that were split out into their own forecast grouping. There is more information on the process in this case study.
Disaggregation
Once statistical forecasts are run at group level, they will need to be disaggregated to product and location for production planning and distribution planning purposes. Your demand planning software should be able to disaggregate based on recent history.
The time-period you use for disaggregation should be long enough not to be distorted by random spikes or valleys, but short enough to pick up trends. I’ve seen arguments to use an entire year for disaggregation because of seasonality. However, if seasonality is distorting your disaggregation, a better answer would be to divide the group further so products and customers within one group all have similar seasonality. I prefer to use only three months for disaggregation.
Low volume SKUs
Most CPG companies have a “long tail” of low volume products. These are often difficult to forecast, with high volatility due to sporadic demand. Even though these products should be managed with supply strategies other than make-to-forecast, a forecast may still be required for purposes of aggregating total demand for S&OP and other planning activities.
There might not be enough data points on some slow volume products for planners to be able to identify trends or seasonality. Planners can use their market knowledge to combine such products into a group of products they are most like. Planners will need to check regularly to be sure an order spike has not distorted the disaggregation by product.
Evaluating groups
A level of market knowledge is important when setting up the forecast groups. There may be times when historical patterns and even statistical tests indicate products have different historical patterns, yet they should still be the same forecast group.
Say your company ships through distributors to certain customers and a large chunk of volume shifted from one distributor to another. When you drill down to customer level in your history, you should see a significant level change upward on one distributor offset by a significant level change downward on the other (although timing may be slightly off if they manage inventory differently). If the end customer hasn’t changed, there may not be a need to put these in different groups. If the distributors pull differently from your DCs, you might have to make overrides at location level until the change is far enough in the past to no longer impact your disaggregation by location.
Likewise, there may be a market trend of one product replacing another. New products usually replace or significantly cannibalize one or more existing products. If the historical patterns and market forces are expected to be similar for the new product, they should be in same forecast group. You might use life cycle tools in your demand planning software to phase out one material and phase in the other. Or, if the trend is subtle, you might simply rely on disaggregation to slowly shift forecast to new product as its share of historical demand increases.
Group Size
How big should the forecast groups be? You want there to be enough data to see patterns and generate good statistical results. On the other hand, they can’t be so big that market changes in one or more products are overlooked.
Regardless of how many products are in groups, planners should review results of stats and disaggregation against actual shipments on a regular basis. Noticeable deviations in actual demand require evaluation to see if groupings or stat models need to be adjusted. Review should be at a product level, or even by product and location.
Implementing the change
As with any change, the implementation of forecast groups is likely to cause some disruption to current practices. There will be additional short-term workload to identify the groups and make the changes. Batch processes for statistical forecasts may need to be modified.
Shive Supply Chain Solutions LLC can help with the transition. We’ll help organize your data to better see the historical patterns. We’ll train your planners to recognize different historical patterns and develop forecast groupings. We’ll work with your IT department to update batch jobs.
Have you used forecast groupings to consolidate history for statistical models? Please e-mail your comments and questions to us at info@ShiveSupplyChainSolutions.com .