Three stages BOP model
Users expect a lot from backorder processing (BOP). Since this is the transaction that will change dates and confirmations in the sales orders, it’s one of the major interfaces between planning and execution. A good plan will make users happy; a bad plan can ruin the orderbook. Being so, sometimes planners want BOP to make a miracle, that won't happen. But sometimes times they are not taking the most of it.
One common request is to have stability and still improve dates whenever possible. To have stability is important to check the plan on the confirmed date, but to have improvements the check must be made against requested date.
The many options used in practice comprise:
1) BOP checking always on the requested date
2) BOP checking the confirmed date and manual selective improvements by doing new ATP checks in the sales orders
3) Run BOP on the confirmed date and give dispatching users tools (based on pegging for example) to ship before the confirmed date if the material is ready
4) Run BOP on confirmation date with the flag of checking the first version (this essentially makes the check on the first confirmed date and not on the current confirmed date)
5)BOP running in two stages, first based on confirmation and after based on requested date
This post is about this last option. Although there is nothing hard on that strategy it’s use is not always obvious.
By running BOP based on confirmation date, and with the typical settings of new distribution one is able to solve negative ATP issues, with rescheduling typically based on delivery priorities or/and requested date. If there is no negative ATP problem for the material (during the time line the available receipts are able to always satisfy the requirement dates) then nothing will change in the confirmation, the stability property much desired for the operation.
On the other hand some receipts may be available earlier than when the first confirmation was defined. Since in these cases the first BOP run will maintain the confirmation date, a second BOP run is needed to improve those cases. This second run should check by the requested date and not have new distribution settings.
By not setting the new distribution flags the system will check each order without setting free the receipts for the other orders in the BOP run. Since a previous run was performed that solved all negative ATP issues, this second run will check each order against the same receipt of the previous ATP and will move the confirmed date closer to the requested date whenever possible.
The third stage is to run BOP for the unconfirmed orders. By excluding unconfirmed orders from the first and second step the available ATP quantities will not be used by unconfirmed orders of high priority customers, which would result in a less stable result.
Regarding the other strategies that only execute BOP based on confirmed date, this three staged strategy has some obvious advantages. There is less workload to manually improve orders and there is an overall visibility improvement by having confirmed dates close to the real dispatching date.
Running based on the first confirmed date can be seen as a compromise between stability and improvement. Nonetheless, it has still the stability issues of running on a date different from the confirmation and will not give the full improvement possible. The three staged approach will generally give a better combination of stability and improvement. It’s possible that in some cases the customer as agreed to the first confirmed date in a way that the system should never try to improve that date. In those cases the second step should check under these conditions.
Regarding the strategy to run BOP on the requested date, this strategy also has some advantages. It enables more stability both on the first confirmation date, and in all BOP runs. Running BOP on requested date is more used for industries that are often faced with the issue of distributing limited supply giving priority to special customers. This strategy is not so adequate for industries trying to apply a policy of “first in first served”, with emphasis with reliability on the first confirmation result.
Music playing: Kill Bill OST
One common request is to have stability and still improve dates whenever possible. To have stability is important to check the plan on the confirmed date, but to have improvements the check must be made against requested date.
The many options used in practice comprise:
1) BOP checking always on the requested date
2) BOP checking the confirmed date and manual selective improvements by doing new ATP checks in the sales orders
3) Run BOP on the confirmed date and give dispatching users tools (based on pegging for example) to ship before the confirmed date if the material is ready
4) Run BOP on confirmation date with the flag of checking the first version (this essentially makes the check on the first confirmed date and not on the current confirmed date)
5)BOP running in two stages, first based on confirmation and after based on requested date
This post is about this last option. Although there is nothing hard on that strategy it’s use is not always obvious.
By running BOP based on confirmation date, and with the typical settings of new distribution one is able to solve negative ATP issues, with rescheduling typically based on delivery priorities or/and requested date. If there is no negative ATP problem for the material (during the time line the available receipts are able to always satisfy the requirement dates) then nothing will change in the confirmation, the stability property much desired for the operation.
On the other hand some receipts may be available earlier than when the first confirmation was defined. Since in these cases the first BOP run will maintain the confirmation date, a second BOP run is needed to improve those cases. This second run should check by the requested date and not have new distribution settings.
By not setting the new distribution flags the system will check each order without setting free the receipts for the other orders in the BOP run. Since a previous run was performed that solved all negative ATP issues, this second run will check each order against the same receipt of the previous ATP and will move the confirmed date closer to the requested date whenever possible.
The third stage is to run BOP for the unconfirmed orders. By excluding unconfirmed orders from the first and second step the available ATP quantities will not be used by unconfirmed orders of high priority customers, which would result in a less stable result.
Regarding the other strategies that only execute BOP based on confirmed date, this three staged strategy has some obvious advantages. There is less workload to manually improve orders and there is an overall visibility improvement by having confirmed dates close to the real dispatching date.
Running based on the first confirmed date can be seen as a compromise between stability and improvement. Nonetheless, it has still the stability issues of running on a date different from the confirmation and will not give the full improvement possible. The three staged approach will generally give a better combination of stability and improvement. It’s possible that in some cases the customer as agreed to the first confirmed date in a way that the system should never try to improve that date. In those cases the second step should check under these conditions.
Regarding the strategy to run BOP on the requested date, this strategy also has some advantages. It enables more stability both on the first confirmation date, and in all BOP runs. Running BOP on requested date is more used for industries that are often faced with the issue of distributing limited supply giving priority to special customers. This strategy is not so adequate for industries trying to apply a policy of “first in first served”, with emphasis with reliability on the first confirmation result.
Music playing: Kill Bill OST
posted by pvl at 7/18/2007
3 Comments:
Boas Lima! Tudo bem?
Estou aqui com uma dúvida e é com agrado que encontro o teu blog, não sei se ainda por cá andas visto o último post ter 2 anos mas...cá vai:
Quando tens um segmento em que a quota está excedida (imagina que a reduziste quando estava já no limite), ao correres o BOP, ele olha para aquilo como um todo ou vai distribuindo e propondo confirmação para as ordens até atingir o limite na nova quota? Por exemplo, se tens 300m3 de ordens, baixas a quota até aos 100m3 e agora queres confirmar apenas ordens no valor de 100m3. O BOP deveria propôr confirmação até perfazer os 100m3 ou propões desconfirmar tudo (o que me está a acontecer)?
Abraço e obrigado ;)
Hi Jorge, it's the first scenario that you describe. There are some configurations that can cause what you describe in scenario II as a side-effect (for example distribution settings). Cheers, Pedro.
Hi Pedro,
Thanks for the reply! So, the BOP should confirm the orders up to the available quota.
Well, taking in count that i'm sure that it's come malfunction of the system. In my example i've a set of orders that non of them have more quantity than the quota available, so, therefore, whatever the criteria of BOP distribution is, it should always confirm at least one of the orders.
Once again thanks a lot for the help! Probably you don't remember who im I, hope everything is OK with you!
Jorge (PP team, SInd)
Post a Comment
<< Home