How to Best Understand the Frozen Planning Period
Executive Summary
- The frozen planning period is an interval of time in the planning horizon during which a company does not change its supply plan for a product, regardless of events or changes that occur.
Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.
- This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
- Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.
What is the Frozen Planning Period?
I am sometimes asked to describe the frozen planning period and the benefits and costs of setting it at specific durations. The following applies to the frozen period in planning.
Characteristic #1: How to Determine or Calculate the Frozen Period
Standard planning philosophy dictates that the minimum frozen planning period should be the review time plus the lead time for the product. Typically the lower the cadence, the longer the frozen planning period is. While textbooks frequently recommend a frozen period of 1-2 weeks, frozen periods are often not used in real deployments of planning software.
At some companies, setting a real frozen planning period can be a difficult concept to get across. One reason is the typical presentation of the benefits of being “reactive.” Companies often want to know why they should use any frozen planning period at all.
Characteristic #2: How the APO Horizons Apply to the Frozen Period
There are four major timings for planning in SAP APO:
- The total lead time
- The planning horizon
- The plan rerun frequency
- The planning bucket
The planning rerun frequency has the greatest impact on the responsiveness of the plan. The higher the rerun frequency, the more responsive the plan is.
Planning timings are some of the most critical areas of configuration to set up. In the end, the planning model should be carefully vetted to match the requirements of both clients and the department.
In this article, we will cover both the frozen planning period and the planning horizon generally.
Hartmut Stradtler’s Definition
In the book, Supply Chain Management, and Advanced Planning, Hartmut Stadtler points out the following:
Planning on a rolling horizon basis is an implementation of this plan control revision interaction. The planning horizon is divided into months. At the beginning of January a plan is made that covers January to December. But only the first period, the so-called frozen planning period, is actually put into practice. At the beginning of the second period, a new plan is made considering the actual developments during the first frozen period and updated forecasts for the future periods. This procedure is a common way of coping with the uncertainty in operational planning both in classical planning systems and in APS.
A more efficient way of updating the plans is event-driven planning. A new plan is not drawn up in regular intervals but in case of an important event, e.g. unexpected sales, major changes in customer orders, breakdown of a machine, etc. This procedure requires that all data which are necessary for planning e. g. stocks, progress of work etc., are updated continuously so they are available at any arbitrary event time. – Hartmut Stradtler
- Here Hartmut seems to be differentiating event-based planning from a frozen planning period.
- In theory, a truly frozen planning period would mean that you did not make changes to the plan within the frozen planning period, so alerts would not be necessary.
I would say that I had always thought of using both a frozen period and alerts, but the text from Hartmut represents them as two different methods of setting up the planning system, and I think they have a point.
Our View of The Frozen Planning Period
The frozen planning period is the period within which changes that are made do not affect the plan. The logic for a frozen planning period is to only spend human and computer planning effort planning things that can be affected by the normal planning process (such as making a purchase order or stock transport order recommendations).
The existence of a planning horizon validates the demarcation between planning and expediting.
Demarcation Between Planning Groups and Execution
A frozen planning period helps differentiate between different planning domains (demand planning and supply planning, supply planning, and execution). I have this described in the graphic below.
This is an oversimplification. The frozen period would not be the same per planning domain. This shows the cascading nature of the frozen period, however.
Customizing The Frozen Planning Period
One of the most important considerations is the cadence of the system. Standard planning philosophy states that the minimum frozen planning period should be the review time plus the lead-time of the product. This is a difficult concept to implement since many of the products have different lead times. However, a limited number of frozen periods must eventually be selected.
Long Frozen Planning Periods by Industry
Some naturally low cadence industries like aerospace and defense (A&D) can be set with long-frozen periods. This is an industry marked by long lead times and long manufacturing lead times. A&D is also one of the few examples of a true make to order environment. Even though many different companies claim to be make to order, it usually turns out to be assemble or package to order.
Frozen Period Set in Months = Industry Example: Aerospace and Defense (Full Make to Order)
No Frozen Period = Industry Example: Pure Distribution Environment
For people with a significant orientation on planning, the desire can be to attempt to implement a relatively long frozen planning period to demarcate planning from operations essentially. The very selection of a frozen planning period determines whether APO is used only for planning or for both planning and execution. This is true, at least for the planning oriented components of APO.
However, this is only one way to peel the onion.
Planning Versus Execution in APO
While the official story from SAP is that SAP ERP is for execution and SAP APO is for planning, the actual story is more complex than that. APO has several execution elements to it. APO may never get to the point of cutting purchase orders, but a lot can be classified if not executional, then at least tactical.
The Actual Practice of the Frozen Period
A frozen period of a week or two is recommended and is considered the standard way of controlling a planning system, at least according to textbooks. However, frozen periods are not all that commonly used in real deployments of planning software. There are several reasons for this:
- For industries with a fast cadence, perhaps the best way to meet their planning needs is to dispense with the frozen period and instead allow changes that come within the lead time to be observed and reacted to by both planners and operators who each use the SCM system.
- Secondly, while “planning” systems were initially intended to be used for planning exclusively, companies tend to use planning systems for operations, short-term to mid-term planning, and very little long-term planning. The most long-term planning that occurs is in the S&OP process, which is a disaster area for most companies. Long-term planning is more about capacity planning, which means capacity adjustment, rather than moving demand around to meet demand with the current capacity.
Getting to How Planning Systems are Used in Practice
This brings up a critical point related to how planning systems are used in practice. This is quite a bit different from how vendors designed them to be used. One way to improve the planning system’s ability to manage both operations and planning is to create differentiated alerts.
The alert monitor allows alerts to be flexibly sent to different individuals who have different responsibilities.
Planning Alerts = APO Alerts outside of lead time
Execution Alerts = APO Alerts inside of lead time
Background on the Timing of Supply Chain Planning Systems
It is essential to consider the different timing controls in APO and develop independent reasoning for each one. Many discussions on implementations surround the timing of the system, and it is critical to have all of the timing controls properly defined before these discussions occur.
The following are the major timings in SAP APO:
- Total Lead Times – The time between order submittal and item receipt
- Planning Horizons (both forecast and supply planning) – The time into the future that the planning engine considers.
- Plan Rerun Frequency – How often the planning routine is run.
- Planning Bucket – The interval used to consolidate requirements.
The Planning Horizons
Planning horizons control how far out various APO modules perform processing on data and provide results. Planning horizons are important control settings for APO. Understanding them and how they interoperate with one another is an important step to any APO implementation.
This article explains the major planning horizons for four of the most commonly implemented modules in APO (DP, SNP, GATP, PP/DS), and how to socialize planning horizons on projects.
The Planning Horizon Determination for Demand Planning
This is shown by the following formula.
Planning Horizon >= Lead Time + Review Time
The Lead Times
The horizon and lead-time are strongly correlated. For procurement decisions, it is not necessary to create a forecast out further than the product’s lead-time. This is also true of the supply plan. The supply plan does not need to be longer than the total lead-time for the product. However, the supply plan horizon should be at least as long as the total replenishment lead-time for execution purposes.
Collaboration, warehouse capacity, and budgeting forecasts have a longer horizon.
The Planning Rerun Frequency
The planning rerun frequency is how often the planning routine is run. It is the most important control, which determines the responsiveness of the plan. The following graphic shows that the same planning bucket can be used with either a two-week or 2-month planning horizon and the same planning bucket can be re-planned at any interval.
Planning Frequency and Planning Bucket Differences
Weekly Planning = Unpredictable Demand, New Products
Greater Than Weekly Planning = Predictable Demand, Stable (Old) Products
The Planning Buckets
Planning buckets determine the granularity of the plan. Planning buckets should be set in a way that matches the necessity of the order placement.
- For instance, if a quantity of 50 for a product were forecasted to be required in the third week of March, in weekly planning, this would fall in the third week of the month.
- With monthly planning buckets, this requirement would fall in March.
Therefore, the item could be procured anytime in March and meet the requirements.
In the case that it is important that the item is procured in the third week, and not in say the fourth week, then weekly planning buckets should be used.
Therefore, planning buckets determine the granularity of the planning process.
However, they do not impact the planning horizon or the frequency of the planning run frequency.
And this brings up an important point. The time horizon, planning bucket, and the planning horizon should all have independent reasons used to determine their frequency.
The Implications for System Timing Settings on Planning Responsiveness
The responsiveness of the demand and supply plan is based upon a combination of the forecast horizon and the frequency of plan rerun, not the planning buckets selection. The planning buckets control where that requirement will be allocated, or more simply, where the supply and demand will end up.
It is the planning rerun frequency that has the greatest impact on responsiveness. How frequently a planning procedure (that is MRP, optimization, allocation, etc.) is run determines how frequently the demand or supply plan is updated. The main limitation on frequently rerunning either the supply plan or demand plan is its increased consumption of computing resources and the fact that it moves everything around. Most companies will have a nightly batch job that runs for what is called “net change,” or things that changed from the previous run, and then have a weekend batch job that runs the entire product location database.
Making the Proper Trade-off Between Planning Rerun Frequency
The benefit of updated information must be balanced with the processing resources and the planning downtime of the system. This decision should be made on these factors and independent of the planning bucket and horizons decisions.
- If the planning buckets are changed, but the network planning rerun frequency is kept the same, the system does not become more responsive. It only divides the demand to a finer level of detail.
- On the other hand, the planning buckets can be monthly, and the rerun frequency can be increased to weekly to make the planning more responsive. It is the planning frequency, not the planning bucket selected, that primarily determines the responsiveness of the system.
Is Responsiveness the End Goal of a Planning System?
It also needs to be understood that responsiveness, while an end goal of execution systems, is not the end goal of planning systems. Many people think this, but it is inaccurate. Instead, planning systems are by their nature set to a slower cadence and have a longer-range view than execution systems.
The Planning Cadence Determination Model
Any company performing this type of implementation needs to create a model where the different timing frequencies can be determined by analyzing the different characteristics of the products. The following model is one example of how the different timings could be determined. Any model needs to be carefully vetted with the business to match the requirements of both clients and the department.
The result should be a customized timing design.
- Lead Times Based Upon Actuals
- Planning Bucket Based Upon Product Volume + Order Frequency Volatility
- Planning Rerun Frequency Based Upon Criticality + Order Frequency Volatility
- Planning Horizon Based Upon Lead Time + Review Time
- Frozen Period Based Upon Lead Time + Review Time
Conclusion
Hartmut’s explanation is a good way of describing a frozen planning period that argues well for my initial statement.
Upon analysis of SAP APO, it is apparent that there are several ways of dealing with the changes that arrive within the planning system outside of the planning period.
One way is to deal with the changes only in SAP ERP. Another way is to use SAP APO and control the within lead-time changes by creating alerts that a specialized group that are more execution and expediting oriented than planning oriented, manage.
System timings are some of the most important areas of configuration to set up, and they are also some of the most difficult to get right. The only way to do this is to socialize all of the system timings to the business at a company. This is so they can (hopefully) make the right decisions.