SAP Extended Warehouse Management

10 keys to success for your migration to EWM (Part 1)

Contents

Despite the announcement of Stock Room Management, SAP Extended Warehouse Management remains SAP's strategic solution for warehouse management. Therefore, more and more SAP customers face the challenge to migrate their many warehouses from SAP WM or a third-party warehouse management system to SAP EWM.

In this article, we explain why an EWM project is not a technical migration project (even if you are currently using SAP WM) and why a black-box approach of warehouse management is not useful. Furthermore, we highlight important tools and provide useful advice which you can put to use in your migration project to SAP EWM.

An EWM implementation is not really a migration project

The implementation of SAP EWM is not a technical migration project. Even if you are currently using classic SAP WM, an EWM implementation is a separate, stand-alone project that you should consider accordingly in your project plan. This applies also and especially in the context of an S/4HANA greenfield project or an S/4HANA conversion.

The main reason for this is that the technical foundation of both warehouse management solutions differs fundamentally. Although some technical objects from SAP WM were re-used in SAP WM (developers know the L3 function group), EWM is not an advance development of WM, but a stand-alone solution for modern warehouse management. Therefore, one should also consider that by implementing SAP EWM, the necessity to change the company structure may arise (e.g. storage locations). A black-box approach is therefore not helpful. Existing company-specific developments from SAP WM can only be transferred to EWM in a very restricted context and the terms used as well as the user interface in EWM are vastly different than in WM.

This is the reason why you should consider the following 10 success factors for your EWM implementation project to make it a success.

1. Define project strategy

Starting an EWM implementation, one should first answer the questions regarding the focal implementation and roll-out strategy. Oftentimes, a pilot location is determined where EWM is implemented first and afterwards rolled out to other warehouses. With this approach, one can gain experience with the new warehouse management system and use already implemented optimizations directly during the roll-out.

You choose to implement SAP EWM at several locations at the same time? Often, a central IT team is responsible for this whose resources are limited. Consequently, it should be analyzed thoroughly why and in which project phases bottleneck resources may occur who need reinforcement.

Also, the timeline should be considered, e.g. in the context of an S/4HANA project. Through lack of synchronization between the different modules waiting and idle times may occur while one part of the project team is already finished with their implementation and the other is still working on it. Last, one should always keep in mind that an EWM implementation is a separate project part which comes close to a new implementation.

2. Choose suitable deployment option

SAP EWM can be deployed in different ways. The first decision to make is if your new warehouse management system should be run centrally (Embedded EWM in S/4HANA) or decentrally.

Central deployment: EWM Embedded Basic and Advanced

Central deployment of EWM in S/4HANA is also called Embedded EWM. As EWM on S/4HANA is now part of the central coding line, the EWM components will automatically be installed when setting up a new S/4HANA instance on a current release. You can then choose between the basic and the advanced version which is confirmed by a flag in the EWM customizing. The difference between basic and advanced is that some functions may not be used in the basic version.

Additionally, there is the option to deploy EWM as an add-on on SAP ERP. However, this is a different coding line than EWM on S/4HANA - the add-on coding line matches the EWM on NetWeaver (see decentral deployment).

Decentral deployment

Until now, there was the option to install EWM as a decentral stand-alone system on the NetWeaver stack. The versioning here was EWM 9.0 to EWM 9.5.

As EWM is now included in the S/4HANA stack, this option is no longer the preferred way, because EWM on S/4HANA is now considered to be the main coding line. The EWM on S/4HANA release corresponds to the release of S/4HANA, i.e. S/4HANA 2020. If one chooses to run EWM on S/4HANA, it can too be run decentrally. It is then equal to the advanced version of Embedded EWM.

If you opt to install e.g. EWM 9.5 on SAP NetWeaver, you may face a later migration from NetWeaver to EWM on S/4HANA.

3. Plan the project lifecycle realistically

As described initially, an EWM implementation is a separate SAP project. This is true for project resource planning as well as for the timeline including the concept phase, implementation phase, testing phases, migration until the go-live.

Since a warehouse management software is supposed to map the physical material flow correctly, a re-arrangement of warehouse structures must be considered while planning on-site testing.

Additionally, dependencies between the timelines and resource planning of other SAP modules have to be considered - an integrated project planning approach should be used.

4. Consider process re-engineering

When one switches from WM to EWM, this offers an opportunity to check existing processes in intralogistics for weaknesses and pain points, re-occuring problems, transparency gaps and performance weaknesses. As the application architecture differs strongly between WM and EWM, it is often not possible to re-use developments from WM in SAP EWM. Therefore, the process should be analyzed and thought through holistically. Simply implementing existing warehouse processes from WM in EWM without considering the aspects mentioned above may be wasting an opportunity for improvement.

Furthermore, SAP EWM Standard offers far more functionality than the classic warehouse managementwhich allows you to design your processes in a flexible, maintainable and extensible way. In order to not just implement EWM as a cause in itself, one would have to put the functionality of EWM to use.

5. Implement change management

A change of the warehouse management system is always a change in daily work for a company's employees in logistics. Over the years they may have gotten used to a system adjusted to their needs. The user interface (UI) in EWM looks different and the underlying concepts differ from the legacy warehouse management system.

Therefore, an integrated change management is useful, which includes the key resources and lets them participate in the design process. The relevant key users should be included, as they know the warehouse processes in depth and live them every day. Otherwise, the project may lead to frustration or even worse, processes are designed that are not lived in later practice. This has to be avoided if your EWM project shall be a success.

Continued in part 2

We hope you have liked part 1 of this article. In part 2, we give even more insights into the do's and the don'ts of a migration to SAP EWM. We will also cover the technical migration of the migration objects from SAP WM to EWM.

If you have any questions regarding your EWM project or the migration from SAP WM, we are here to support you – just let us know via the contact form below.

Here you can learn more about our process consulting for SAP EWM.

Our service: Strategy consulting
Our service: Process consulting
More about SAP Extended Warehouse Management

Do you have a question or require more information?

Details on the use of personalized data are outlined in our Privacy policy.