Background

I always find it strange when I am asked about performing fair share distribution with the cost optimizer. This is because the optimizer is designed to move product through a supply network based upon costs. I always like to keep the other costs in the optimizer equal when analyzing any one particular cost. So in the scenario I am discussing all costs are the same. This includes:

1. Production
2. Procurement
3. Prod Cap
4. Transport
5. Transport Cap
6. Storage
7. Storage Cap
8. Safety Stock
9. Handling Cap
10. Late Delivery
11. No Delivery (only this is changed in our discussion)
12. Rec.Bound
13. Quota Arrangement
14. Setup C.

While there are a lot of costs listed here, not all of them necessarily need to be used for to run the optimizer. The system will simply use those that you populate and not attribute any costs for those that you do not.

All of these costs can be found in SNP: Profile of Cost Multipliers. These penalties are set in specific locations, for instance the transportation cost is set at the transportation lane. However the penalties can be increased in proportion to one another.

Therefore, the penalties can be kept the same, but the but these can be used to multiply the cost categories by.

Here is the cost in the transportation lane. If the cost here was entered as 5 and the multiplier in the SNP Profile of Cost Multipliers were 2, then the cost incurred by moving a truck over this lane would be 10. Its not very useful to think of this in terms of dollars, because it is not actually dollars. I find it more instructive to think of it as points. The points are all relative. If all the costs / points are increased by a factor of 5 or 10, the same result comes out of the optimizer.

The most commonly populated costs that I have seen are the following:

1. Production
2. Procurement
3. Transport
4. Storage
5. Safety Stock
6. No Delivery (only this is changed in our discussion)

Fair Share

While SNP has in-built fair share capability, supposedly, it does not work very well. The concept of fair share is the opposite of cost optimization. Because of these limiting factors, SNP offers a fair share patch, which clients can buy. I analyzed this patch and found a lot of illogical things. From what I could tell, the patch seemed to make the optimizer ignore the case quantity or rounding values. Therefore if an optimizer deployment run looked like the following when the patch was included:

1. Location A = 5
2. Location B = 15
3. Location C = 100
4. Location D = 10
5. Location E = 75

and the minimum case size or other rounding value was 40, the deployment run without the fair share patch would look like the following:

1. Location A = 40
2. Location B = 40
3. Location C = 100
4. Location D = 40
5. Location E = None

What happened was that when the rounding value was implemented, the deployment optimizer was able to deploy to fewer locations, because it has to satisfy rounding values. However, the rounding values were in fact necessary. So any deployment optimizer run that produced below case quantity results simply had to be rounded manually after the fact.

Something else I noticed was that there did not seem to be any logic to how the fair share was allocated. There was no proportionality. So if a demand at location A was 20 and the demand at location B was 20, the deployment optimizer fair share patch might send 5 to A and 15 to B. In fact all the fair share patch seemed to do was violate the case quantity. It was essentially no value add.

Fair Share with Costs

One request that was made of me was to see if the deployment optimizer could be made to fair share between parent and child locations through using costs. So if A which supplies to B and C and they all had demands of 40 (which would appear to A as distribution demands from B and C) the could the deployment optimizer be made to allocate 120 units equally among the three.

Firstly, this is a request, but there is no documentation that states that the deployment optimizer can do this. There is a setting under the Demand at Source Location that is supposed to be able to control for this. This is the “Demand at Source Location” so it can be made to consider either forecasts or sales orders at the parent location. There was some confusion as to where this should actually be set (at the parent or the child), but I tested it at both, and neither worked. I communicated with SAP on this, and the comments that came back from development contracted this functionality. In my consulting experience, I have never seen this work, but on the other hand I have also no been asked to configure this requirement.

Getting back to obtaining a fair share with costs, one might think that by setting the costs of non-delivery the same at all locations in the supply network. However, when I tested it, it sent the all material to one location and divided none of it. This brings up a general point about the binary nature of how material is flow controlled in cost optimization that is a real concern, and which surprises me that it is not brought up more frequently as a major design problem. It has given me some real concern as to how well cost optimizers actually match real term requirements and is explained in more detail below.

http://www.scmfocus.com/supplyplanning/2012/01/03/the-problem-with-cost-optimization/

Conclusion

The optimizer has numbers problems with fair sharing. SAP’s fair share components for the deployment optimizer do not work. Secondly, attempting to emulate a fair share by setting the non-delivery penalty costs the same at the locations where the fair share is desired did not work. It seems this is because the SNP optimizer does not have any tie-breaking logic for when costs are identical, and how it selects which location to use are not apparent to me.

I am curious if anyone has any comments on this. The behavior I am seeing in the deployment optimizer is concerning as I can’t see it matching business requirements. I recall hearing from an IBM consultant several years ago how wonderfly nuanced and capable the optimizer was once it is “tuned.” I am not seeing this. However for years my veiwpoint has been obscured by the fact that the optimziers I have been working with have been misconfigured. I describe the problem with cost setting in this post.

http://www.scmfocus.com/inventoryoptimizationmultiechelon/2011/05/how-costs-are-really-set-in-cost-optimization-implementations/

However, even the simplest location to location movement within one echelon seem to be a problem. It is simply not desirable to send all stock to one location when mutliple locations have a demand. It is also not useful to source all stock from one location, until the stock is depleted, before shifting to a secondary location. Anyone who has worked in supply chain for some amount of time should know this, which is why I am a bit perplexed why there is not more conversation on this topic.