From Water Distribution to Product Allocation

The water distribution control system is quite similar to gATP product allocation. What is available in vanilla PAL is something like the open loop control system.



A common development in PAL implementations is to use sales forecast to create the allocation plan. By frequently updating the allocation plan, PAL will become a feedback controller.



The key piece of technology to have a good control system is the controller. In this case the controller is the logic that calculates the bucket capacities from the sales forecast and user defined constraints. It is a bit amazing that SAP APO, probably the most advanced supply chain planning system, left this key piece of technology out of the software. It is up to the people doing the implementation to build the controller. And that is something hard interesting to do.

Similar Control System

I tried to find some real work control problems that are similar in objective to PAL . So far, the one I like more is the control of water allocation in regions of limited water and power supply.

The water distribution is done using a network of reservoirs. In dry regions, planning and controlling the level of water in each reservoir is quite important since it may not be possible to pump more water into each tank. For each time period (day, week, etc) there is a planned level of water for each tank in the network. If everybody tries to consume more water than available then all will have shortages. In that scenario the planned tank level corresponds to the fair share of water available for each node in the network.

On the other hand, if there is some tank that experiences more consumption than planned and other tanks have excess capacity, then water needs to be pumped from one place to the other. If power is limited in the region it is also important to plan the pumping of water because it may be more expensive (or not possible at all) to transfer the water only when the tank becomes empty.

The water network control system will probably plan the consumption of water in each node of the network based on historic values. Then, based of the available water capacity, will define the level that will be loaded on each tank (or the quantity to be pumped).

The system could just wait for the end of the period and do the same operation again for the next period. Of course this will have the risk of unexpected consumption making some tanks empty. If that happens, and if water is available, someone will have to try to pump water from some node to the empty tanks. This is not a very good system because there will be a penalty for users that run out of water, it needs manual intervention, and it may be more expensive to pump water. This is like the open loop system described before.



A more advanced system will do real-time monitoring of the water level in each tank. Using that information will recalculate the forecasted consumption. Using the new forecast it is possible to define the values for the tank levels so that quotas are enforced in case of drought but at the same time all available water will reach consumers. This is a supervisory control system with a feedback loop.

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.

Open loop controller at home

In my house the heating system is made of electrical heaters that are mainly connected during the night (electricity is cheaper at night where I live). And during the day the heat accumulated in ceramic materials is slowly released.

To control when the heater should be connected I have a clock timers in the electrical plugs with the scheduled night hours.



This clock device is an open loop controller (a controler that makes decisions without information of the controlled variable). It is also a good example of the disadvantages of such systems. Since there is no feedback loop, the temperature will vary depending on the external conditions, since the heat input will remain constant. Sometimes it becomes too cold in the house and I need to connect it manually some more hours. When the winter is coming to an end temperature increases, and then I know it is time to reduce the programmed number of hours.

This system has some advantages but it's terrible if one wants to have good control of the temperature. And it would be expensive if I was to spend time analyzing the measured temperatures and manually trying to adjust the number of hours to adjust the system to the external conditions changes. It would be expensive because my time is limited.

Looking at what comes with the SAP standard, gATP PAL is an open loop controller (to be continued).

Product Allocation

When I think of science I always think of something exciting like invention. But truth is that many times it is not more than transfering knowledge between similar areas. Like moving furniture between rooms. It's not exciting but it is much more effective than building something new from scratch on the other room.

So I've been moving some furniture between control theory and gATP product allocation. I'll try to write down my findings in a series of posts.

Data references

The following is the data reference equivalent to the example code using an object. It's shorter but less clear (IMHO).

TYPES:
  BEGIN OF t_place,
    place TYPE char30,
  END OF t_place,
  t_place_tab TYPE TABLE OF t_place,
  BEGIN OF t_city,
    city_name TYPE char20,
    places_ref TYPE REF TO data,
  END OF t_city.

FIELD-SYMBOLS:
  <ref> TYPE t_place_tab.

DATA:
  gt_city TYPE HASHED TABLE OF t_city WITH UNIQUE KEY city_name,
  gs_city TYPE t_city,
  gs_place TYPE t_place.

START-OF-SELECTION.
  gs_city-city_name = 'Porto'.
  CREATE DATA gs_city-places_ref TYPE t_place_tab.
  ASSIGN gs_city-places_ref->* TO <ref>.
  gs_place-place = 'Torre dos Clerigos'.
  APPEND gs_place TO <ref>.
  gs_place-place = 'Casa da Musica'.
  APPEND gs_place TO <ref>.
  gs_place-place = 'Serralves'.
  APPEND gs_place TO <ref>.

  INSERT gs_city INTO TABLE gt_city.

  gs_city-city_name = 'New York'.
  CREATE DATA gs_city-places_ref TYPE t_place_tab.
  ASSIGN gs_city-places_ref->* TO <ref>.
  gs_place-place = 'Empire State Building'.
  APPEND gs_place TO <ref>.
  gs_place-place = 'Central Park'.
  APPEND gs_place TO <ref>.

  INSERT gs_city INTO TABLE gt_city.

  READ TABLE gt_city INTO gs_city WITH KEY city_name = 'Porto'.
  IF sy-subrc = 0.
    ASSIGN gs_city-places_ref->* TO <ref>.
    SORT <ref> BY place.
    LOOP AT <ref> INTO gs_place.
      WRITE: / gs_city-city_name, gs_place-place.
    ENDLOOP.
  ENDIF.