How to Best Understand Historical Adjustment in Forecasting

Executive Summary

• Historical adjustment is necessary to produce a forecast that matches with the desired adjustments.
• We cover historical adjustment in SAP DP and Demand Works Smoothie.

Introduction

Forecasting is not performed upon exactly what happened in the past. This is because companies are constantly in flux with regards to their products, and therefore some adjustments are necessary to account for changes in the business. For instance, a product that is sourced out of one location may not be sourced out of the same location going forward. This is an important forecasting technique.

See our references for this article and related articles at this link.

In this case, the company will want to move the demand history to a new location, rather than produce a forecast out of a location where the product will no longer be sourced. One of the best-known ways to do this is with an adjustment to history. This type of functionality is built into many forecasting applications.

In this article, we will cover multiple areas of historical adjustment, including, adjusting history, historical removal, as well as managing situations where there is insufficient history.

Historical adjustment moves demand history to locations where it did not occur.

What is interesting is the many reasons for the historical adjustment

1. When products are being transshipped
2. When a product is being moved to a new location (and the demand history must follow along with it)
3. When there is a direct shipment from a plant to a location which is not part of the normal supply network flow (in this case the forecast must be moved from the plant to another location depending upon how the company wants to recognize the sales)

This is just a sampling; there are more reasons than this, and they often vary per company.

Historical Adjustment

• Historical adjustment is necessary to account for a demand history that is not what is desired for creating a statistical forecast.
• Sometimes companies perform high maintenance adjustments, but there is a far better and simpler way to perform a historical adjustment.

What the Functionality Does

This functionality provides the ability to flexibly reflect alterations in the supply network in the demand planning system. For instance, if a product is to be stocked in a new location, it is vital that the demand history is reflected at this new location (or else, without a reorder point) the supply planning system will not bring in stock.

If a product is to be moved to a new location, then the demand history could be removed from the actual location it was incurred and moved to a new location.

Why is it Necessary?

Without historical adjustment, the burden placed upon supply planning to make manual adjustments, which tend to be error-prone.

Historical adjustment, in the application that has this functionality (An application that lacks historical adjustment can have its database directly changed, but this is not desirable.), does not affect or change the data file.

Instead, the historical adjustment is managed within the application.

Temporary Versus Permanent Historical Adjustment

Historical adjustments can be temporary or permanent.

For instance, an example of a temporary adjustment is when a factory is an overcapacity, and the supply must come from a different factory.

In this scenario, an adjustment must be made both at the initial factory where the demand was incurred to the factory where the demand was not incurred — and then switched back again after the capacity limitation passes. A permanent adjustment is when a decision to move the demand to be produced at a new factory on a permanent basis. In this case, the adjustment is permanent, which is only performed one time.

Historical Adjustments in Two Applications, SAP DP and Smoothie

Historical Adjustment in SAP DP as a Forecasting Technique

In other applications, historical adjustment tends to take place in the same view as that everything else happens in the application. However, SAP DP is different in that it has a separate Planning Book which is just designed to account for Historical Adjustments.

The Historical Adjustment or Correction Planning Book has just a few rows or Key Figures. The Promotional Adjustment is optional, but three o the Key Figures are required in any Historical Adjustment or Correction Planning Book. That is the previous actual demand – called Shipment History, in this case, the Correction Key Figure, and the Final Calculated Key Figure, in this case, the Corrected Shipment History. 

This Key Figure they are copied over to the primary Planning Book. In most cases, the Corrected Shipment History Key Figure will be placed above the Statistical Forecast Key Figure. The historical adjustments can be placed at the characteristic combination, so at Product, or at Product/Ship-From or Product/Customer, etc.. and the forecast will increase or decrease at that level in the hierarchy.

This is an important forecasting technique in SAP DP.

Realignment in SAP DP

For instance, the SAP DP application, like several other enterprise forecasting applications with weak attribute functionality, DP does not have a good way to display two different “truths” in the system. When something like a product being a move to a new location is required, DP must change the hierarchy through something called a realignment. This is where the historical adjustment is then reflected at the new location. However, realignments are very time-consuming and are not done that frequently.

This is the problem with the way some vendors manage ROLAP / star schemas and MOLAP / multidimensional cube systems; they make them extremely inflexible. However, a few vendors have figured out how to develop a ROLAP / star schema without requiring any maintenance or realignment. This is described in this article.

Secondly, the requirement companies have to be able to switch a product between locations flexibly (and to have their demand history follow), and many of the other reasons for moving demand history are similarly transitory.

They do not work well with systems that require major system activities like realignment every time a historical adjustment is required.

The Flow-Through Table

Because of these limitations, most clients I have worked with perform a custom enhancement. Many times this enhancement is some code and a ZTable in SAP. At a few companies, I have worked at this is named the “flow-through table.” What this does is moves the forecast to a different location as an intermediate step before the forecast is sent to the supply planning system.

This table above represents a simplified version of this flow-through table. However, in reality, it is much more complex than this. The single flow through table which I describe is in many cases multiple tables with different conditions.

However, my observation over multiple accounts is that this flow through table ends up being a major maintenance item, and most companies end up being not that satisfied with it.

The Negative Impact of Incomplete Historical Adjustment on Supply Planning

Unfortunately, because the flow through table often is incomplete, the issue concerning the adjustment can sometimes become supply planning’s issue. This means that time must be spent enabling or disabling the valid location to location combinations in a supply network. In some cases, to allow the forecast to flow through between locations, and in other situations to turn off the forecast flow. This is a poor design and extremely undesirable.

However, it is what can happen when the issue of historical adjustment is not managed correctly demand planning, and the negative effects then spill over into supply planning.

Historical Adjustment in Smoothie

Rather than be dependent upon a custom external table or tables, forecasting software should be able to hold all historical adjustments. It should be able to represent in effect multiple realities. That is one “hard” reality which is the actual demand history, and one or more alternative realities, which is the overlay that we want to place on-demand history to meet future objectives. Thus, the forecasting system should be able to maintain these historical adjustments for the full demand history, and they should be easy to adjust and to move around.

Interestingly, a vendor that I have discussed quite a bit on this blog handling historical adjustment quite easily. Demand Works has this to say on the topic of historical adjustment:

“Smoothie has the ability to forecast using history that is different that what actually occurred. The Adjusted History measure is where adjustments to history can be made. This is useful if you would like to ignore early demand, or adjust for non-repeatable events.

Background History adjustments are particularly useful for simulating history that may be copied and re-scaled from another item, or correcting for unusual events using an approach that will not influence forecast calculations at aggregate levels.” – Smoothie Help

There are so many advantages to having the adjustment kept within the forecasting application, rather than having an external custom table or set of tables, it difficult to know where to begin to describe these advantages.

With Demand Works Smoothie, the demand history can be continually moved, which is a requirement for all the companies I have consulted with. For instance, there are scenarios where it is necessary to move the demand history back and forth between two locations every few weeks. Smoothie allows this to change to be made flexibly. Interestingly, Bill Tonetti of Demand Works brought up the relationship to promotions.

“By the way, we use “promotions” for this, too. They’re additive and the advantage of this approach is that the effects of promotions are utilized at other levels of aggregation. History adjustments don’t aggregate, since there would be a risk of duplicating history while working with aggregations. Having both additive and absolute adjustments is an important and differentiating feature in Smoothie.” – Bill Tonetti

Historical Customer Demand Removal Definition

One can’t cover historical adjustment without covering historical removal.

• Historical customer demand removal removes demand history, typically beginning from the earliest and then working up the sequence of demand history periods, to improve forecast accuracy.
• Historical customer demand removal works in environments where the earlier demand history is not reflective of future demand.
• A historical removal algorithm can remove one period at a time; perform a forecast comparison or more than one period at a time.

Though not widely taught, and not thought a best practice, historical customer demand removal has been shown in our testing sometimes to improve the statistical forecast.

Historical customer demand removal must be compared to forecasting without historical removal before it is included as a strategy for the company.

Insufficient Sales History

There are many cases where there is not enough history of creating a reasonably accurate statistical forecast. In a previous article, I proposed that the forecasting system should not produce a forecast in every situation. This is not to say that a forecast will not eventually be created, only that it will not be created by the statistical forecasting system.

The Standard Approach for Dealing with Insufficient History

The standard approach with regards to statistically forecasting items that are “statistically forecasting challenged,” is to produce a forecast no matter what simply. In some systems, this is less of a problem, because the quality of the graphics and availability of forecast statistics very easily shows how good the forecast is. However, in SAP DP, it is much to difficult to see graphically or mathematically how good any particular forecast is. For this reason, it makes much more sense to stop producing forecasts that are not a value add and allowing planners to control the forecast entirely. This topic is quite relevant to items that have an insufficient history.

Insufficient history will generally be caused by “new” products that have not had a like product’s demand history assigned to it.

Who Faces the Problem of Insufficient Demand History?

Any company that introduced new products will face this problem. However, this problem plagues those industries that have a rapid turnover in their product numbers, which includes all food and most consumer packaged goods. For these companies, marketing’s ability to make slight deviations on products often overwhelms the supply chain’s ability to keep up with these changes.

Companies should have a formal approach to identifying and assigning the demand history of old products to new, but most do not. Therefore, it is quite common to run into a situation where products have an insufficient history of creating a forecast.

SAP DP Functionality

SAP DP does have a way of managing this. Within the Forecast Profile, there exists a setting which I see too infrequently used. This is under the Model Reinitialization Settings.

This is shown in the following screenshot.

Conclusion

One of the lesser discussed topics in demand planning is the use of historical adjustment.

If you perform a Google search on the topic, very little comes up, and here at Brightwork Research & Analysis where we get many questions on forecasting, we get very few questions on the topic of historical adjustment. A major part of promotions forecasting is adjusting history for the effect of previous promotions on sales history.

When compared with other forecasting topics, such as error measurement or forecasting methods, it is interesting how lightly the coverage is.

However, historical adjustments are required by all of the companies that I have worked with in the past, and most companies I have worked with have struggled with performing it functionally. Much of this is due to selecting solutions that are not designed to perform the historical adjustment. It is clear from this analysis that historical adjustment capability should be given much more weight during the software selection process.