Product Allocation Controller
In this last post I wrote that PAL is an open loop controller. That statement implies that information from the evolution of the desired objective is not used to compute the control actions. At this stage I need to try to answer the question: what is the objective function for product allocation controlling?
It is easier to start by looking at what comes with vanilla PAL (what comes with standard SAP). Many designs are possible (this previous post shows some possibilities), but in each case there is a capacity that is constrained. For each time period and allocation characteristics (market, customer, etc) there is a bucket with a defined capacity. When the capacity is reached no more orders can be confirmed on the bucket.
This control system is quite similar to something I have at home - the flush toilet. When water reaches the capacity of the tank, the valve is closed and the inflow of water stops. Same with PAL, only that the tank capacity is defined by the user.
The flush toilet is an on-off feedback controller (uses the information of water level to decide on closing the valve). So PAL should also be an on-off feedback controller if the objective was to control the maximal capacity of the bucket.
But this is business software, the natural objective function should somehow relate to maximizing profit. And of course, it will always be profit related and only on few exceptions profit will be equivalent to bucket capacity limitation.
If the goal is to split the available capacity and it is guaranteed that there will be demand to fill each bucket, then capacity limitation and profit are equivalent. This happens because sales profit is constant (all available capacity will be sold) and the additional strategic value related to allocating the products to the desired customers is maximized. This scenario happens, for example when new and over-hyped products are launched or when short time promotions are done.
But it would be surprising, even in fast growing economies, that demand is always so much large than supply that whatever buckets are defined all capacity is sold. Because when that happens prices are increased to restore balance to the market and increase the profit. So most of the times, for sales allocation purpose, demand is only slightly larger than supply and the goal of PAL controlling has to be different - it must be maximizing capacity usage (all material must be sold) while minimizing the difference between actual and planned bucket allocation.
So if the control objective is not used for the control actions, it is an open loop controller. At home I have to check the temperature and manually change the controller set-point for the inflow of energy. Some PAL users have to manually change the bucket capacities (quotas) to reach the objective.
From experience I know that a vanilla PAL works quite well with peak demand (promotions, etc) and it is more problematic in the most common balanced market scenario. I find it interesting that it works well when it is a feedback controller and not so well when it is an open loop controller. So making sure that PAL is always a feedback controller should be a design goal.
It is easier to start by looking at what comes with vanilla PAL (what comes with standard SAP). Many designs are possible (this previous post shows some possibilities), but in each case there is a capacity that is constrained. For each time period and allocation characteristics (market, customer, etc) there is a bucket with a defined capacity. When the capacity is reached no more orders can be confirmed on the bucket.
This control system is quite similar to something I have at home - the flush toilet. When water reaches the capacity of the tank, the valve is closed and the inflow of water stops. Same with PAL, only that the tank capacity is defined by the user.
The flush toilet is an on-off feedback controller (uses the information of water level to decide on closing the valve). So PAL should also be an on-off feedback controller if the objective was to control the maximal capacity of the bucket.
But this is business software, the natural objective function should somehow relate to maximizing profit. And of course, it will always be profit related and only on few exceptions profit will be equivalent to bucket capacity limitation.
If the goal is to split the available capacity and it is guaranteed that there will be demand to fill each bucket, then capacity limitation and profit are equivalent. This happens because sales profit is constant (all available capacity will be sold) and the additional strategic value related to allocating the products to the desired customers is maximized. This scenario happens, for example when new and over-hyped products are launched or when short time promotions are done.
But it would be surprising, even in fast growing economies, that demand is always so much large than supply that whatever buckets are defined all capacity is sold. Because when that happens prices are increased to restore balance to the market and increase the profit. So most of the times, for sales allocation purpose, demand is only slightly larger than supply and the goal of PAL controlling has to be different - it must be maximizing capacity usage (all material must be sold) while minimizing the difference between actual and planned bucket allocation.
So if the control objective is not used for the control actions, it is an open loop controller. At home I have to check the temperature and manually change the controller set-point for the inflow of energy. Some PAL users have to manually change the bucket capacities (quotas) to reach the objective.
From experience I know that a vanilla PAL works quite well with peak demand (promotions, etc) and it is more problematic in the most common balanced market scenario. I find it interesting that it works well when it is a feedback controller and not so well when it is an open loop controller. So making sure that PAL is always a feedback controller should be a design goal.
posted by pvl at 12/21/2008
0 Comments:
Post a Comment
<< Home