Skip to Content
Author's profile photo Sven Denecken

#S4HANA use case series: 1b – next generation logistics (tech view)

In the corresponding Business value blog #S4HANA use case series: 1a – next generation logistics (biz view) we have explained why to cater towards growing consumer demands, product planners and Materials Requirements Planning (MRP) controllers need instant access and prioritized view on material flow issues. Real-time alerting drives the responsible person to the exception, while the daily business is running without frequent interaction required decision making and finding the right supplier to order the right material has to be supported by system-generated solution proposals.

Today´s blog will shed a light on what has changed with SAP S/4HANA from a technical point of view to address the need of a Production Manager to adjust the production in real-time according to customers’ demand. In other terms, how optimizations and simplification can improve the Material Requirements Planning monitoring.

MRP is a critical business process and by far more than a simple calculator. A Material Planner is responsible for making sure the production plant never runs out of materials, components or sellable products. For example, if a material is produced in-house, the MRP calculates the dependent requirements. The quantity of components required to produce the finished product or the assembly, by exploding the Bill of Material (BOM). If a material shortage exists, Production Orders or Purchase Orders are created at every BOM level to cover requirements.

Simplification by code optimization

The MRP within SAP S/4HANA runs entirely on the in-memory platform SAP HANA which has been optimized and improved the overall performance. The internal logic to read the planning elements from the database to the internal table has been fully redesigned to run in-memory planning. And large parts of the application logic in the database server were implemented in SQL Script (15.000 lines of code).

Furthermore transactions were rewritten and tables simplified. The example below shows a code optimization.


With the new transaction code the MRP planners are able to run transactions close to real time which were classical batch processes in the past. More filter functions provide a broader flexibility to parametrize the MRP.

In the classic implementation approach, the application server calls the database server many times to read relevant data. The data were transferred from the database server to the application server. Tables are read sub sequentially. The additional roundtrips required a significant bandwidth to load the data. With SAP S/4HANA tables are read in parallel. The calculation engine within the database is directly hosting the calculations, which eliminates data load into the application layer.

All optimizations superpose each other to optimize the elapse time by a factor 10 (example from 30 minutes to 3 minutes for the same requirement calculation). POC results of up to factor 20 have been achieved as well, the more data a customer have and the longer the elapse time have been, the more reduction can be achieved). In the same way, the memory/data footprint is reduced by factor 5. Based on this achievement it is now possible to run the MRP on a much higher frequency – which is completely changing decision processes. Planner can meet the vagaries of production better and service levels can be increased.

Simulations as the base for real-time optimizations

Aggregated material views are historical necessary to achieve reasonable response times for specific views. An increased number of inserts and updates into redundant tables have been the price to pay. Customers transferred Analyzes into Data Warehouse Systems allowing a flexible reporting at reasonable response times. But again, this added complexity.

OLTP (Online Transaction Processing) is designed for fast row inserts, updates and selections. OLAP (Online Analytical Processing) is designed for long lasting queries. An OLAP database is populated with rows from OLTP database. This requires complex data extraction, transferring and loading mechanism. The mechanisms are usually slow and executed once a day submitting batch jobs during night time. SAP S/4HANA, build on an in-memory database, eliminates this overhead and allows OLTP and OLAP in one single system. It manages to preserve the fast OLTP transactions as well as achieve up-to-date data for OLAP queries.

Increasing speed of execution and analyses are the key capability to meet the new requirements of the market, introducing also a new generation of business applications that are used to create new business models and processes. With the integration of the analytical part in the same system, customers can address today’s demand for real-time business insights.

With the MRP a perfect storm is created bringing all this aspects together. Identifying solutions to material shortages traditionally, several ERP transactions have to be executed (see Figure). In the MRP within SAP S/4HANA, data is pulled in real time from all areas of material management including procurement lead times, inventory stock availability, lot sizes, manufacturing scheduling and sales orders across multiple sites. The system goes one step further and suggests potential solutions for the shortage through Solution Cards. In fact, Solution Cards has all information needed to resolve the material shortage (e.g. Reschedule Purchase Order, Increase Purchase Order, stock transfers). As this system is on one common base, financial data can be mixed directly into the process to rank proposed solutions. Each proposed solution is evaluated in real-time and the Material Planer can preview viability and impact before accepting a solution.


The second example is the way how SAP S/4HANA is transforming the user experience. In fact, the material resources planner will completely change the way work is done, because it can now optimize daily work tasks by focusing on exceptions and on the most urgent problems with the highest financial implication.

Do to the merge of OLTP and OLAP; we can use the real time analytical capabilities directly on the transactional processes, and propose simulations possibilities for the user.

Starting from the current state of the supply chain and including the existing MRP algorithms, the simulation computes the future inventory situation in detail. The optimization algorithms make use of the simulation to find the ideal replenishment strategies and parameters. E.g. with this ability to simulate and compare the ways of resolutions, the Material Recourses Planner can compare, for example, the effectiveness of an external replenishing compared to a replenishing via a production on an industrial site. Additionally all financial implication of the proposed solutions is visible.

In conclusion, with SAP S/4HANA, the Material Planner´s work environment will be role based and exception driven.

Stay tuned for the next use cases and follow me via @SDenecken for latest news.


#S4HANA – the use case series – Overview

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Jānis B
      Jānis B

      That code optimization example is IMO somewhat unfortunate... To never ever use in any "serious code" the kind of looped/nested SELECTs one had learned fresh out of SAP's ABAP training, was one of the very first things taught to us by SAP guy from Walldorf, hired by my first client to do code reviews and otherwise support us. That was... err... nineteen-nineties and R/3 was 3.something, if my memory serves me right 🙂

      Author's profile photo Rodrigo Silveira
      Rodrigo Silveira

      This abap example follows the worst practices . lol

      Author's profile photo Former Member
      Former Member

      I understand that this is marketing material, but to be honest, developers (as in other comments) can recognize that optimization in that particular case is achieved by code optimizations, do you have comparison on this code between any db and HANA ?

      By the way it's really cool that coding will be reviewed and optimized!

      Author's profile photo Karlheinz Lehmann
      Karlheinz Lehmann

      Table CDPOS was a cluster table so far, so there has been no way to use a join statement when selecting data. So the code example is not directly related to HANA. You would get similar effects on all DB Systems as long as the CDPOS is not a cluster table.

      However, all kind of optimization helps. And all (code) reviews are welcome.

      Author's profile photo Lalitkumar Sonawane
      Lalitkumar Sonawane

      Thanks for sharing this informative document. its very useful to know basic about new logistic.