SAP EWM in the cloud - even for automated warehouses?

We begin by looking at the different SAP EWM variants. There are different options for various warehouse types:

Variant 1: Embedded SAP EWM

Embedded SAP EWM runs on SAP ERP (Enterprise Resource Planning). This requires an SAP S/4HANA system; if that is not available, this first option is not even considered. If you opt for Embedded SAP EWM, there is no longer an independent decision as to whether it runs on-premise or in the cloud; it runs wherever the SAP S/4HANA system is located.

Variant 2: Decentralized SAP EWM

With decentralized SAP EWM, you can choose between on-premise (you provide and operate the infrastructure, hardware and SAP EWM yourself) and operation from the cloud. When operating from the cloud, hosting takes place using hyperscalers such as Azure, Google or Amazon. A hyperscaler is a virtual network whose purpose is to enable scalings in cloud computing; they also provide the infrastructure and install and operate SAP EWM, which is offered as a SaaS (Software as a Service) licensing model. The various services are negotiable with SAP.

Public or Private: Two different cloud solutions

The Public Cloud is a multi-tenant solution in which several firms share one SAP EWM. This arrangement scarcely allows any adaptations; therefore the solution is suitable for less complex warehouses. Three to four release changes per year result in higher testing effort, but the SAP EWM is always fully up to date as a result.
The use of a Private Cloud provides an EWM that only you use; extensive customizing and additional programming are possible. There are hardly any restrictions compared to an on-premise solution.

Typical architecture when using SAP EWM including SAP-based add-ons

In addition to the costs of a cloud solution, response time behavior plays a central role. The graphic shows a typical system architecture (image must be inserted close to the text here) with the ERP system being used and the SAP EWM / MFS - these are connected via an interface through which they communicate.
Our SAP-based add-ons can be used to extend the standard functions of the SAP EWM.

For example, companies that work with hazardous goods, oils or batteries, and need to provide safety certificates, rely on our K.Motion S/DGM (Dangerous Good Management). K.Motion S/CEP can be used to connect CEP (Courier Express Parcel) service providers, e.g. to guarantee that the correct shipping labels are printed. Another Körber add-on is K.Motion S/LSO (Load Space Optimization), which is typically used in transport management and helps with truck planning and package optimization. But LSO can also be employed to pre-calculate the automatic packing of shipping cartons of different sizes onto a pallet by means of robots.

So-called APC (ABAP [Advanced Business Application Programming] Push Channels) are used to control the PLC level. As a rule, SAP EWM MFS directly controls the PLC of the lower-level systems (e.g. high-bay warehouse, automated small parts warehouse, shuttles, palletizers etc.).

Is the cloud fast enough? What role do latency times play?

The usual response time behavior when using automatic warehouses is between 50 and 200 milliseconds, and is a question of design. This behavior plays an important role in warehouse operation, and depends on the computing power and processes. Hyperscalers are very well positioned in this area.

Latency times nowadays are usually between 1-10 milliseconds, although they must be multiplied by a factor of 4. Round-trip times within Europe are less than 30 milliseconds, with an average of 13 milliseconds. This must be checked and negotiated on a case-by-case basis. Hyperscalers can usually expand Hardware very quickly, so that shorter computing times compensate for problems with latency. Therefore, SAP EWM can also run in the cloud with MFS for dynamic automated warehouses.

Network connection availability (the last mile)

Network connection is the Achilles heel in many customer systems. Hyperscalers significantly reduce the risk through redundant network connections. This means that various redundant service pathways exist, using different media types, e.g. fiber, copper, LG or 5G. For example, one of the other options can be accessed if there is a problem in the ground. Moreover, node-disjoint network paths are used, which have completely separate physical network nodes and lines. If one line fails, this does not mean that all the other lines are also disconnected from the network. Customer experience regarding the availability of the entire network has been extremely good.

Security through emulator tests

In practice, if the theoretical values for latency and computing times are very good, they can be verified in advance by means of an emulation. Thus, in the case of automated warehouses, the PLC level is very often emulated by using external software (e.g. based on Java), and is tested together with the emulation of the SAP EWM/MFS excluding the conveyor system. If the emulation is run on a computer located in the warehouse, you can easily check the response time behavior including latency times, and thus prevent any unpleasant surprises during a go-live in the cloud.

CONCLUDING SUMMARY

In summary, it can be said that:

• SAP EWM in a private cloud offers the same flexibility as an on-premise installation.
   
• As a rule, the latency times and computing power of cloud solutions meet the requirements for an SAP EWM/MFS.
   
• SAP’s prices for a cloud solution (SaaS - Software-as-a-Service) should be compared with those for an on-premise solution.
   
• Hyperscalers, together with SAP, have a large volume of experience in the installation and operation of an SAP EWM.
   
• Security (cybersecurity) is usually significantly higher with hyperscalers than with an on-premise solution.
   

Technically, SAP EWM in the cloud is a very good alternative to an on-premise solution, even for automated warehouses.