Background

Various costs are benefits are combined to determine if a product should be repositioned to a new location. I have graphically setup these costs and benefits in the post below.

You can read more about inventory balancing here.

http://www.scmfocus.com/sapplanning/2009/09/30/difference-between-the-snp-deployment-optimizer-and-inventory-balancing/

http://www.scmfocus.com/sapplanning/2010/09/05/spp-img-setup-inventory-balancing/

Background

These settings control whether and with what propensity stock is moved between locations.

/N/SAPAPO/RDPLPRF takes us to this screen. This is a profile that can be applied to a inventory balancing. It controls when an item should be considered “in excess” and when when it should be considered “short.”

/N/SAPAPO/RDPLPRFA takes us to a screen where this profile can be assigned to the planning version, area (location). So different profiles can be applied to different locations, meaning that each location can have its own profile, and thus propensity for movement or being relocated.

I did not know I was in for such a perplexing time simply trying to configure something that should be simple.

Background

Inventory Balancing is the movement of inventory which is already in the supply chain in order to more efficiently use already deployed stock. It is one of the most important capabilities of service parts planning, although the functionality is not unique to service parts.

The master data configuration setup does not make a lot of sense, also setting up the necessary relationships is filled with glitches in SPP.

SAP Development

SAP has created one of the worst configuration areas I can ever recall using. It is completely unnecessarily complex and little things, like accepting a dummy location as the top level in the inventory balancing area is a problem. I have had to use mind mapping software just to understand the unnecessarily convoluted connections between objects. It is difficult to see why any of this is necessary. With inventory balancing you simply need to identify the locations for which you want the balancing to occur. That should be a simple list of location. There is no reason to create a dummy location The creation of hierarchies is also unnecessary. Hierarchies are for DRP and setup parents an children, inventory balancing does not work like that – hierarchy is irrelevant, it simply comes down to supply vs. demand with costs limiting the movement of items (transportation, warehouse space savings, etc…). Instead all locations (within the defined group of locations) can send to any other of the locations in the defined group. This is apparent to anyone who understands how stock repositioning is performed.

Difficult to Change

In the screenshot below I am missing a parent dummy location. I would like to add one, and move the SUPPL01 to SUPPL04 underneath it. You can see because every location is listed as the first level of the hierarchy, every location is a inventory balancing area, which is not what we want. However, there is no facility to make this change. So this means I will have to delete these entries and add them again.

When I add them again, I will have to set the level in the hierarchy that I want by entering a value in the level field. So I need to delete all of these entries and re-add. However, there is a problem, the Level field entry does not activate.

How then can a different level in the hierarchy be created? It turns out with a right mouse click on the location (something I remembered doing a year ago when I was configuring this, but forgot).

What I am doing can be so easily represented by a plain CSV file that it is absolutely ridiculous. For companies looking to implement SPP, it should be obvious what this means…..extremely high costs for just elementary setup to be performed. Mind you, we are not into any functionality yet, just trying to setup some elementary network design master data. Don’t agree with me that this setup is onerous, ok let’s move to supersession.

Supersession

I spent several days documenting the supersession functionality which can be seen in the following posts:

http://www.scmfocus.com/sapplanning/2010/09/05/spp-img-setup-supersession/

http://www.scmfocus.com/sapplanning/2009/04/18/spp-supersession/

The configuration complexity with regards to supersession functionality goes on and on. You can read about it these posts above. However, does supersession configuration have to be so circuitous. Lets see how the leader in service parts planning does it. MCA Solutions has the different supersession types (normal, version, exception, included parts explosion), and they have a coding for whether the supersession will be one way or two way. There is not more than a few tables used, and these are all explicitlylaidout in their interface specification. And that makes sense. All that is necessary is a list of parts that have supersession relationships with other parts, some dates which describe when the new part will take over for the part, coding for whether the relationship is one way or two way, and voila, you have the necessary configuration to incorporate supersession into a planning engine. Now of course the planning engine code must act on that configuration, and I am not saying that part is a piece cake, here I am only speaking of the data that is necessary to be setup. Why SAP has turned this basic feature into a two day exercise to document is beyond me.

Conclusion

SAP development needs to clean up SPP because the present design has many area that are illogical and a degree of implementation complexity that can result in aborted go-lives. SAP must understand that location groupings for inventory balancing must be able to be flexibly changed as well as the fact that supersession relationships must be easy to update and change. SPP has problems in other areas such as its leading indicator forecasting (causal forecasting) which has an unresolved issue which has not been addressed.