Wednesday, July 18, 2007

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

Labels: ,

Friday, July 13, 2007

Places to take a break

Just a list of places for break-points in ATP processes:

In APO: /sapapo/rrp_atp_check (for CTP), /sapapo/quota_check (PAL), /sapapo/avail_check_controller (ATP and BOP).

In R3: saplvo3c_apoint has the call to bapi_apo_scheduling; saplatpc has the call to bapi_apoatp_check.

Labels: ,

Strange Industry

In a recent post from Vendorprisey Thomas shared some marketing numbers for the software industry:’s sales and marketing costs, for example, typically hover between 50% and 70% of revenue, according to past financial statements. That’s huge compared to traditional software vendors where sales and marketing costs typically run between 20% and 25% of revenue

You are the customer. They sell you software for $$$. Then if you find problems using the product they ask you to create a bug report, and pay you zero for that work. Then they go and spend $ of your money on mailing you some half plastic paper ads. Then they ask you on ways to improve the product, features you are missing, etc (again zip for that work of helping develop the product). And they go spend more of your $ on leaflets or TV commercials. The time comes and you are told: your software is not longer supported, either upgrade to be safe (and pay us $$$) or be aware that your product might blow-up and kill your pet. And they go spend $ of your money on some magazine ad.

It's a strange industry. Basically sells brainwashing with software as byproduct. Then again, if that is what the customer wants, so be it.

Don't like it? Then take some fresh air with linux.