Come and join us at SAPInsider in Vegas at the booth #830.
Here the Abstract and the outline of our presentation:
Speed and complexity: lessons learned and best practices in implementing SAP IBP for companies of different sizes and different business process variants:
- S&OP/IBP global templates rollouts vs one instance implementations of multiple process variants
-Global roll-outs of Demand Planning challenges vs Demand and Supply balance processes
-Integrated planning implementations (i.e. with SAP PPDS) vs stand-alone SAP IBP
-Planning vs Reporting
-How to support IT organization in smaller or larger organizations
-Data quality and governance
Join us in our presentation on lessons learned and best practices. Matthew Flood from Prestige Brands and Dustin Demmin from Nature's Way will join us and share their IBP experience.
Check our posting: https://www.linkedin.com/jobs2/view/104280911
Check out this webinar and learn about the value of SAP S&OP:
This week we are at SAPPHIRE NOW at Orlando to launch our new implementation and support services for SAP® Integrated Business Planning (IBP) powered by SAP HANA®. Our new service helps SAP customers achieve a fast financial return from their SAP Integrated Business Planning in cloud and on-premise environments.
We are very excited about this new generation of SAP solutions. They push the boundaries of the traditional sales and operations planning process. With SAP Integrated Business Planning customers can perform planning exercises that were unthinkable before. Planners get a crystal ball: no more rough-cut planning at the product family level and regional level. Now SAP customers can cascade their corporate plans and annual operating plans to the SKU level. They can run accurate supply models including optimization and then compare the bottom-up result against their financial targets.
On top of it, the return on investment can happen faster than ever. Our first customers for the new service have been able to make their implementation productive within 12 weeks, from concept to go-live. We currently work with customers from the High Tech, Chemicals, Oil &Gas, and Consumer Packaged Products industries.
If you are SAPPHRE NOW this week, stop by at the SAP for High Tech booth, Pod number 21039, where we will demo scenarios for the High Tech industry.
We look forward meeting you.
For more information on our new implementation and support services for SAP® Integrated Business Planning (IBP) powered by SAP HANA®, please read our press release here.
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.
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