A high level explanation of the SOP on HANA Heuristic Model

Finally I am re-surfacing after a very intense two-months period spent to build the most complex SOP on HANA configuration attempted so far.

As a first step to understand the Heuristic model let us talk briefly about the main logical step performed by the Heuristic model. In my view the model is essentially performing --almost-- sequentially the following step:

1) propagate customer demand to supply network

2) propagate demand inside the supply network

3) calculate the supply plan

4) calculate the resource utilization 

[return the Heuristic result]

5) recalculate the Heuristic from manually adjusted key figures.

For supply network I mean a set of location-products connected via the equivalent of what in other SCM solutions are called transportation lanes. For the point #1 the transportation lane is called "customer source", for which the model requires Master data to function correctly. The Demand (potentially a sales adjusted forecast fed from other systems) is a key figure known at the Customer-Product level. In order to perform the first step the system requires that  the sum of the "Customer sourcing ratio" for a given Customer Product be equal to "1" (aka 100%). The customer ratio can be maintained in the Master data tables as a time-independent value or as a key figure should the quantity be sourced in different ways at different times in the future.

The Customer Demand is of course editable at this point. And this step does nothing more than splitting the Customer demand on the first series of "connected" locations. This contribution is stored in a key figure called "Customer Dependent Demand" which is defined at the Customer-Product-Location level.

The equivalent of the transportation lanes connecting locations for a given product is called in SOP "Location Source" and as you can easily foresee also in this case there are conditions to be fulfilled for the system to work. As to the distribution problem one needs to consider for the step #3 also procurement and production (or any other sort of "assembly"), I will need to introduce concepts that are needed to complete step #3.

SAP has designed the product sourcing in three main ways: "P-rule" for Production or assembly, "T-rule" for transportation  (sourced from other location) and "U-rule" for Procured product (U stands for Unconstrained if I am not mistaken). The condition requires that the coefficients (if time independent) or the key figures (for time-dependent values) setting these rules sum up to "1" (100%). This design, even if understandable form a functional perspective, requires to maintain the rules in two different set of parameters and requires particular care to make sure that one does not violate the rule. As typically customers will be requiring these coefficients as key figures (as MD cannot be changed so easily in the UI), one really needs to make sure that only advanced business users will change them or otherwise the entire model will break. So, as a lesson learned, make sure that you "protect" the production sourcing and the customer sourcing until SAP has introduced a more elegant way to handle these exceptions.

Starting from a consistent configuration, the algorithm will propagate at this point the demand recursively to other location and in the process will also "explode" the bill-of-material, so that a demand for a main product will be broken into the main configured components, until the end of the chain will be met.

At this point the algorithm follows different strategies depending on whether it is constrained or unconstrained. The infinite planning will confirm all the required demand and then build receipts according to the need and violating resource constraints. The constrained algorithm on the contrary will calculated backward the plan without violating the resource constraint and end up with a result potentially below the required quantity.

The constrained algorithm will calculate the resource utilization progressively (as it is basing its constraint on the resource utilization) while the infinite planning can calculate the resource utilization separately (and indeed the resource consumption rate is not required for the infinite/unconstrained planning).

Finally (#5) the user may change a set of "Adjusted" key figure to adjust the plan.

The beauty is that the changes can now be performed at the aggregate level (i.e. Product Family/ Region) or at the finest granularity level depending on the need. Few tools allow to handle the planning so flexibly. And when you see the results in Excel…..well….. it does not really look like SAP…

This will drive adoption as Business Users love excel. So where Duet did not generate the expected traction, you'll see: SOP on HANA will do a very good job.

New SAP Inventory template (courtesy of C. Zimmermann)

SAP S&OP on HANA and the Supply Chain Modeling

S&OP on HANA comes with a built-in ability of aggregating data on the fly once the data have been provided at a fine granular level. One would store data in S&OP at location product/week or month and then planning on Product Family/Region/Quarter and Year, providing that the Master data contains the required dimensions to categorize product and location.

Read More