General Discussion
Products that exhibit seasonality can, if not handled properly, have a major adverse impact on inventory management and planning. Unless the forecast for these products recognizes and deals with the seasonality, the forecast will lag demand as the product enters its strong selling season, and it will just as seriously overstate the demand as the season drops off. The adverse impact on the inventory from these flawed forecasts can be quite serious--inadequate fill rates during the strong season and excess inventory during the off season. Typically, however, the inventory managers load the system with excess inventory all year long to offset the fill rate problem, thereby having excess inventory in the off season and a massive excess inventory during the period of slow demand.

Seasonality can occur for a variety of reasons. Weather is the classic variable, but factors such as the end of school, tax periods, and routine marketing programs can all create seasonal selling patterns. Because marketing and sales promotions frequently accompany normal seasonality, or at times actually cause a seasonal pattern, they are included in this discussion. The fact that the sales promotions can be deliberately varied from year to year does not exclude it from seasonality treatment. The methods of dealing with these shifts will be discussed later.

How much of a shift in sales from the low to the high point has to occur before we must consider seasonality in our forecast? A ten percent shift between the high and low points is a reasonable level for consideration. Below ten percent normal random variation tends to obscure the patterns, making their inclusion in the calculations marginal. Whereas above that level, the seasonality impact starts to become a factor and its exclusion has a considerable negative impact.

Historical Methods Of Dealing With Seasonality
Historically, inventory forecasting systems have dealt with seasonality in one of two ways, each being at the opposite end of the spectrum of complexity. The most common approach, and the simplest, has been to follow the logic of "look at what you did last year--and do the same this year". This "use last year" technique has taken on a number of forms, from actually using the month's sales in the prior year as the forecast for this year, to various smoothing techniques that averaged the adjacent months to smooth out aberrations.

There are two serious problems with this simplistic approach to seasonality. The first is that by definition, you are using year-old data. Year-old sales patterns will fail to comprehend products whose sales are either rising during the off season or declining during the off season. This is a dangerous situation in today's dynamically changing environment. We need a technique that will comprehend that products are changing their fundamental demand levels during the interim period and respond accordingly.

The second problem with the "use last year" technique is its vulnerability to aberrations in the data. It is very common to have a single month of sales impacted by some aberrant event. The sales could be artificially low because of a failure of a supplier to meet your order, or it could be high due to some artificial one-time-buy that had nothing to due with seasonality. The numbers of reasons for these potential aberrations are endless. One year later no one remembers the problems that beset the data, and suddenly the forecast becomes a reflection of these abnormal events and the problem is unnecessarily perpetuated.

At the other end of the complexity spectrum is the technique of letting the computer automatically calculate a set of seasonal indices for each SKU. The classic form of seasonally adjusted exponential forecasting is just such a system. The technique has the computer dynamically update each and every SKU with its own unique set of seasonal indices. While the concept is wonderfully elegant, it works only for items where you have at least two years of data, the sales levels are fairly decent, and there are no aberrations in the prior months of data. Violation of any of these criteria leads to out of line forecasts that can, in turn, lead to serious imbalances of inventory. Since 80 to 90% of most organization's SKUs do not meet these criteria, the technique shouldn't be used as it was originally designed.

Another approach to the problem is to arm the computer with a wide variety of forecasting models that the system uses concurrently for every SKU. The computer tracks the performance of as many as 20 different forecasting models and then proceeds to select the model that had the best historic performance for that SKU as the next forecast.

While this technique has a certain seductive appeal, it is also badly flawed. Not only is it a bit like shooting a mouse with a blunderbuss, but it actually can make highly erroneous forecasts for specific SKUs while trying to squeeze out trivial improvements in the remainder. This situation arises because the system can very easily misinterpret a past pattern that happened to match well as being the optimum model for the future. When in fact, the match was due to a random situation (e.g., an aberrant demand in a prior year matches a pattern that "forecasted" the aberration, but in reality was a coincidence).

Because of the seductive logic of the concept, I created a system of this nature on my own during the early days of developing the MARS system. I was amazed, however, how often the system locked onto a given model based on past performance. When I visually analyzed the situation it was ludicrous that this model should be used to forecast the future.

The Various Techniques MARS-IW Uses to Deal With Seasonality
This section provides an overview of the different aspects of seasonality and how MARS deals with each. The actual procedural steps to utilize each feature in MARS are outlined in the documentation relative to their specific sections. The purpose of this discussion is to provide a general overview and an understanding of when different features apply.

First of all, note the discussion deals with the creation of the set of seasonality indices the system will use. Once the indice set is created, MARS uses it both to seasonally adjust the forecast in looking forward for an item and for deseasonalizing the history just processed to insure the forecast is not unduly impacted by a recent seasonal effect. Charlie Bodenstab's book "A New Era In Inventory Management" discusses these issues in greater detail.

No Seasonality - If the product exhibits minimum or no seasonal characteristics there is no need to take any action. The download should simply default all items to a seasonality index of 01 that consists of a series of 1.0s for each of the 24 months.

The Universal Approach to Seasonality - This section covers the technique by which you will deal with the bulk of the SKUs, if not all of them, that have seasonal characteristics.

Later on we will cover a technique that automatically creates, and dynamically updates, a set of seasonality indices for each SKU. This technique unfortunately does not work for the majority of your SKUs for reasons that will be discussed at length and is also discussed very comprehensively in my book "A New Era In Inventory Management" starting with section 2.2.6 on page 52. You should read this section for a full understanding of the issues and the techniques employed. A summarized version of the concept, however, is as follows:

Rather than letting the computer automatically and blindly create the indice set, we are going to customize a seasonal index set for each "family" of products that tend to have similar seasonal characteristics. This approach rests on the concept that individual SKUs do not necessarily have unique seasonal characteristics, but rather belong to a family of products that respond to the same seasonal pattern. For example, there is no reason why a battery for an 88 Escort should have a different seasonal index than a 94 Mazda. They may have distinctly different demand levels, but their month to month variations will be similar.

One comment about the idea of a family of products…this is a group of products, as stated earlier, that all have a similar seasonal pattern to their demand. The group may constitute the total vendor's products but most likely will not. Since you are deeply aware of the nature of your own product lines, you most likely, with some thought, can decide what the logical groups should be. You may also find that with time you refine this family grouping, whereby you may breakout a group of products that experience shows exhibit their own somewhat different pattern.

With this concept we can now create a set of seasonal indices for a family of products as a one-time, overt process. In other words, rather than letting the computer automatically and blindly create a set of indices, we will overtly create a set with a high degree of manual observation. Once we create a good set of indices for a family of products, we do not have to redo the process for a number of years.

Each SKU is then tagged in the "seasonality code" field with a unique number that identifies it as belonging to that seasonal family. That same code is also assigned to a set of the 12 seasonal indices which the system accesses when performing the calculations for that item.

The advantages of this technique are as follows:

• The set of seasonality indices that result will have a highly rational pattern you are sure is a reasonable representation of the seasonality of the family of products in question.
• Slow moving items whose seasonal patterns are obscured by the high inherent randomness of their demand will have their seasonality effects effectively handled with this set of indices.
• Items where you have less than a full years data will nevertheless be seasonally adjusted, since they will spring off of the seasonality set that was developed independently from items that did have a year or more of data.

MARS contains three distinct methods of creating a set of seasonal indices for a family of products.

Using a Few Specific Items - This is the technique discussed extensively in my book and the feature in MARS is accessed from the group of icons that come up prior to the master screen. The icon is called "Indice Calculator". The actual theory behind the approach is discussed in the book and the specific instructions to use the feature are outlined in the documentation for Indice Calculations. The basic concept, however, is as follows:

With this feature you can access a few SKUs that are highly representative of the family for which you want to create a set of indices. These SKUs, which will act as the "template" for the family, should have all the characteristics of the "well-behaved" items defined earlier (e.g., that have at least one full year of history and preferably two and are high volume movers). Consequently, you will first of all be starting with items that have excellent characteristics. Then the feature allows you to "clean up" the data to eliminate any aberrations that may still be present. The net result is that you will create an excellent set of indices that are highly representative of the family as a whole.

By "cleaning up" I am referring to the process where you visually scan the indices to verify they are flowing in a logical way. (E.g., if the indices have a sequence of .6 --.8 -- .9 -- .7 -- 1.2 etc., you may feel the .7 simply doesn't make sense because your knowledge of the product line indicates that the product is increasing its demand fairly smoothly throughout the period. Therefore the .7 is a dip due to some aberration which study of the raw data supports. The raw data could then be "corrected" which may change the index to possibly a 1.0 causing some of the other eleven indices to be lowered slightly to make the total still add up to 12).

Using a Seasonality Set Developed Elsewhere - You may have some data that has allowed you to determine a set of seasonality indices, independent of MARS, you feel are very representative for a family of items. These can be inserted directly into the system by calling up the icon on the master screen called " Ind. Entry". This feature lets you create a seasonal index identifier and then key in the 12 indices for the set.

Incidentally, if you have a specific SKU you feel is highly representative of a total family and you placed an "XX" in the seasonality field, then that item will have a set of indices (as discussed earlier) that you could transpose into this feature for the total family. Additionally, you could do some "cleaning up" of the indices in the process.

Using a Group of Items - Another feature exists within MARS that allows you to use the "pre-select" screen to call up a complete group of items you feel are representative of a family. This feature is accessed by the icon on the master screen called "Ind/PRM". In this feature, the system will calculate a set of indices by simply adding all the demand for the group of products called up. Incidentally, it will only consider items for which a full year of data exist (e.g., any item that has existed for only a part of the year is not included in the calculation. The part of the year that is missing would bias the calculations into thinking that the demand was zero).

Be careful when using this feature that you do not commingle products that actually have different seasonal characteristics. Note also in this technique, unless you bring in the items one at a time, you will not be viewing the detailed monthly history so aberrations could exist that adversely impact the results. Accordingly, be sure the indices that result from the process make logical marketing sense before they are accepted.

Seasonality For "Well Behaved" Items - Earlier, because of data difficulties, I alluded to the pitfalls of automatically letting the computer create a set of seasonal indices. Certain products, however, do exhibit good data properties and can use this technique, particularly unique and routinely promoted items.

Since this approach is going to work only for items exhibiting "normal seasonality" that are "well behaved" let's define both terms. An SKU, or a series of SKUs, fit the definition of "normal seasonality" if they meet the following criteria:

The product exhibits definite seasonal characteristics, but there is at least reasonable demand in almost every month. The spread of sales between the highest and lowest months can be fairly extreme (e.g., 300 to 400 percent), but each month has respectable demand as contrasted to 90% of the demand falling all into a three to four month period.

They fit the definition of "Well Behaved Items" if they meet the following criteria:

• The item has a full year of history and preferably two years.
• A sales level that is respectable each month (i.e., at least 10 or more demands in just about every month).
• No serious aberrations or random spikes exist in the history for the item.

Items of this nature are handled very elegantly by MARS using a feature called "Seasonally Adjusting Well Behaved Items". Using the technique is extremely easy, since you need only to put an identifier such as an "XX" into the seasonality code for that item, and MARS will dynamically update and create a unique set of seasonality indices for each SKU so tagged.

This means each month, upon command, MARS will locate the items with an XX in their seasonality code and update the set of seasonality indices for that item. (The documentation describes the actual process and calculations.)

There may be a tendency to assume you can tag all your items with the XX and no further effort is required for seasonality. Recall our earlier discussion, however, where it was pointed out only 10 to 20 percent of your SKUs will fit the definitions for "well-behaved items". The technique will work fantastically well for the ones that do meet the criteria, however. For the remaining items we must go to the next sections.

This feature has particular use in the area of promotions. You may have a series of 100 or more items that are routinely promoted. Moreover, each item may have its own unique characteristics and therefore do not conveniently lend themselves to the "family" approach discussed later. Using the "XX" technique the system will monitor each of these items independently and automatically. Additionally, you can very readily access these items and shift the time of the promotion in the coming year. Again, the documentation contains the detail for these actions.

Radical Seasonality
The MARS documentation discusses the issue of radical seasonality in great detail and outlines exactly how to deal with the feature. The general concept, however, is as follows.

Some products are seasonal to the point that 90% or more of the demand takes place in three to four months. The demand in the remaining eight to nine months is therefore minuscule. Products with these demand patterns do not lend themselves to any of the techniques discussed so far. Accordingly, we have to shift to an entirely different methodology to handle these items.

The "radical seasonality" feature of MARS reverts to the "do what we did last year" concept I belittled earlier in this discussion. We have little choice but to look back to the prior year however, since there is no sales history during the slow period from which to "learn". Therefore we are left with only the demand during the peak period. MARS does, however, add some features to the approach that helps mitigate some of the objections to the conventional methods. Additionally it recognizes that these types of products are usually ordered as single one-time buys well in advance of the season. It also allows for fill-in orders during the season. Again, the documentation under "Radical Seasonality" discusses the specifics of how MARS operates in detail.

Other Comments
Promotions - Earlier we mentioned promotions were very closely associated with seasonality, since they either were associated with a normal seasonal pattern or they actually create the seasonal pattern themselves.

If the promotions do not change from year to year, then they may be safely included in the seasonality exercise. If, on the other hand, they change from year to year, then they become what we have labeled "random promotions". MARS deals with this issue by having two years of season indices. The first year (months 1-12) handles the processing of the data for the past year, while the next year (months 13-24) handles the coming year. The function of the first year is to "deseasonalize" the past data in developing the forecast. That is, it takes out the effect of the peak period (or troth period) in updating the forecast so the system does not confuse expected peaks or valleys with actual shifts in demand.

The second year is what the system uses for the forecast as it looks forward. If the seasonality and associated promotions are not expected to change, then the two years are the same. If on the other hand, you feel there will be a shift, or you fully intend to change the months of the promotion, then you can manually rearrange the indices to reflect your new program.

This process of changing the index may be accessed by the screen associated with the technique of creating "XX" seasonal items discussed above or with the "ind. Entry" icon also discussed earlier. The documentation describes the actual process in detail.

Individual Slow Months of Demand – In the discussion on "Normal seasonality" there was one issue that was not discussed. Even though the demand pattern may meet all the criteria for normal seasonality, there can be one or more months where the demand falls to extremely low levels. (This is not, however, as severe as radical seasonality where well over half the months are low.)

If the index for a month is, let's say, .2 (indicating the demand for that month is normally only 20% of an average month) then the deseasonalizing process of the forecast calculations can break down. For example, assume we normally sell about 50 units in an average month and we come to the month where the seasonal index is .2. This implies we expect to sell only 10 units. However, assume you get a random order for an extra 10 units (someone who is using the product for a non-typical use in the off-season) for a total of 20. When MARS deseasonalizes the actual sales, it divides the actual demand by the index, or 20 divided by .2, or 100. In other words, it is saying this is equivalent to selling 100 units in an average month. The 100 is then exponentially averaged into the deseasonalized average jacking it up to a misleading figure.

The entire problem arises because of the high potential to have wildly fluctuating demand during very slow periods. MARS solves this issue very simply, and you do not have to take any action yourself. If a seasonal index is .4 or lower, MARS simply does not update the deseasonalized forecast. This action causes the system to "mark time" during the period when updating the forecast or learning from the most current event has the potential of causing more harm than good.

This figure is defaulted to .4 in the "Systems Parameter" icon and can be changed, but modification of the level should be done with great forethought.

Seasonality Implications on The Reorder Target – Obviously as the impact of seasonality changes the forecast, the reorder target is affected as well, since the forecast is a key variable in the calculations. There is an additional complication, however, that MARS handles automatically and very effectively, of which you should be aware.

The forecast for the reorder target actually covers the entire "exposure period" for which the reorder target is trying to protect. This exposure period is the sum of the lead time and reorder frequency. For example, if the order frequency is one month and the lead time for the product to arrive is two months, the reorder target has to insure product is either on hand or in the pipeline to cover the forecasted demand for this period plus the safety stock.

If the reorder target calculation were to just blithely use the forecast for the coming month, or for the furthest out month, it would not properly reflect the true needs for the period. For example, assume the seasonality index for the next three months (the exposure period) was .7 -- .9 -- and 1.3. This is an expression of how the product will flow out over the three-month period. If we were to use the furthest out forecast (with the index of 1.3) the implication would be that the product is going to be consumed at that rate for all three months, which is obviously not the case. Rather we have to comprehend each of the individual periods from the present time to the furthest out month in our calculations. This is exactly what MARS does. It virtually simulates the use of product for each month, or part of a month, as it comprehends the exposure period. The net affect is a reorder target that very elegantly comprehends the expected flow of product during the exposure period at issue.