From SAP WM to EWM

The journey from Warehouse Management to Extended Warehouse Management

11 February 2019

In 2025, the official support for Warehouse Management (WM) in SAP ERP will cease to exist. The intention is that customers should instead use the alternative and more comprehensive Warehouse Management System (WMS), Extended Warehouse Management (EWM). For this and other reasons, it’s expected that SAP WM-powered companies all over the world will begin a journey, moving from one WMS to another.

In this article, we’ll look into this journey and go through the steps we recommend that you take and the different variants of these, primarily guided by your ambition level.

Aligning your ambition level

Your ambition level is a key differentiator in your journey towards EWM. What do you expect to gain and what level of effort are you ready to apply? To understand the level of effort required, it’s essential to look at two aspects: the degree of technical reuse from the WM solution and the expectations of business impact.

The technical approach – migration or greenfield implementation?

You might be in luck, because EWM and WM are similar in many ways. Warehouse structure (storage types, sections, bins etc.), putaway and removal strategies and queues are almost the same in the two systems. This means there’s a potential for reusing elements of your WMS solution.

SAP has been helpful and created a set of migration tools to facilitate the technical process. This doesn’t happen with a simple push of a button, but in ideal cases, most of the WM solution can be migrated to EWM – even stock data such as physical inventory completeness and of course, pallets and their location.

However, before you get too excited about a quick and low-cost upgrade to EWM, there are a few things you should know.

  1. Some elements, like RF transactions, system users and authorisation roles cannot be migrated from WM in any case and will have to be built from scratch in EWM.
  2. Even for a basic EWM solution, the extra layer of complexity requires configuration not previously existing, such as activity areas, and availability groups. Furthermore, customising related to the product master must be done before migration, for example, storage type and section indicators, the control indicator corresponding to the special movement indicator in WM and more (bulk ind., cycle count ind., stock det. group).
  3. Self-programmed elements of your solution can’t be migrated and will have to be rebuilt (and rethought) in the new EWM system, as the programming method switches from linear to object-oriented. For rare cases, user exits can be replaced by almost identical BAdIs, and in other cases, standard functionality in EWM might cover the functionality needed.

To put it shortly, there are technical shortcuts to EWM for the more standard WM solutions and a bit of work ahead for the extensively customised WM solutions. They’ll either have to replace development with the “extended” functionality or a new development. In case very limited technical elements can or should be migrated, a greenfield implementation is a valid solution. This is also a way to ensure active consideration of all parts of the current solution and avoid bringing over unsuitable elements and functionality to the new EWM solution.

Lastly, it’s relevant to consider how deployment options bring differences in efforts, e.g. from an embedded, basic EWM deployment to an advanced, decentralised deployment, there’s a big difference in integration efforts and the license costs.

Business value – low or high expectations?

It isn’t a coincidence that EWM is replacing WM in the future – it is on the whole a better system. This line of thinking might lead you to believe there’s a business impact to harvest merely by upgrading. But be careful – remember that warehouse workers don’t run faster just because you’re running a new system.

To gain business value, you need to make changes for the better in your EWM solution. The reason why this is particularly important is that projects like these may be funded based on a business case and an ROI (return of investment). Yet, in the case of migrating with no changes, there’s no business impact, no ROI, but rather a pure sunk cost. If all the extra functionalities offered by EWM are not put to use, the immediate benefits will be minimum. This alignment of expectations is critical.

One thing you do get in case you’ve also upgraded to S/4HANA is the out-of-the-box Fiori apps for reporting and process monitoring. This is worth mentioning, as it’s been on the wish list for warehouse managers for years, and with the HANA in-memory database, warehouse data can be analysed and visualised on the fly. That being said, business value still doesn’t come by itself; processes and actions have to be wrapped around it.

The total effort on the journey depends on business value expectations and technical compatibility WM-EWM.

So, if you do have some expectation of business impact, you need to make a change to your solution as part of your upgrade. While new functionality in EWM, such as Labour Management, Slotting, Value-Added Services and Task & Resource Management might offer new opportunities, we believe real impact comes from solving existing pains and therefore, starts with looking at the processes of today. As an example, if you can save time by tweaking these processes, or even get rid of some of them, you have the potential of growing your business without having to hire extra manpower and incur more costs. That’s business value.

The journey steps from SAP WM to SAP EWM

Once you’ve aligned expectations and adjusted your ambition level, you can start planning the journey. Strategically, we recommend initiating the journey with a pilot site as the first implementation. This is done to build internal resources and reduce training, risk, complexity and cost. As the first site has been through the journey steps below, learnings on EWM and project approach can be used beneficially in the subsequent site journeys.

The WM-EWM journey

In case you decide on a greenfield implementation instead of a migration, the technical overview in step one would represent technical elements to recreate (typically at least the warehouse structure), while the rest of the steps will be conceptually similar.

Furthermore, depending on the ambition levels aligned before the journey began, many of the steps will vary greatly in effort, and consequently, so will the business value of the EWM solution.

Want to know more?

Please feel free to contact us, if this blog inspired you to take a closer look at your upcoming journey from WM to EWM, to assess your current WM solution or to better understand how EWM might solve some of your issues today and create higher warehouse efficiency.

Related0 4