What Warehousing Environment is SAP EWM Design For?
Executive Summary
- SAP EWM has a very particular design based upon a third-party logistics provider rather than a shipper.
- This has had negative implications for customers but is not discussed by SAP consulting companies.
Introduction
This article will discuss how major SAP consultancies conspired with SAP to bring a completely inappropriate application called EWM to their clients and how EWM bombed at client after client. The article will explain why the EWM design is so different from what most companies need from a WMS solution.
Background of SAP EWM Design
EWM has had limited success in the market. EWM is similar to SPP in that it came to the market with high hopes. However, it has proven to be both buggies and simply overly difficult to configure. I covered the issues with EWM’s enormous configuration challenges in this article.
What is the SAP EWM Design Actually For?
EWM is really designed more for 3PL or logistics (FedEx, UPS, etc.) companies that manage its own warehouse. This is because EWM was developed off of requirements or Caterpillar Logistics.
Many of the features that EWM has really pay off more when a warehouse is huge and very sophisticated. Interestingly, 3PLs and logistics companies are not real users of APO. A major way SAP gets companies to implement APO modules is when they are already APO customers. So a company that has DP and SNP then often wants to turn on other modules. However, by directing the functionality of EWM towards 3PLs and logistics types of warehouses, SAP has undercut its own natural marketing advantage.
I have worked in both 3PLs and understand the logistics companies. I can’t see them implementing EWM. EWM is not sufficiently practical for their needs and orientation. Very complex and expensive to implement systems don’t fly these types of companies.
The fact that SAP even developed the product with functionality set for these types of companies shows the lack of business knowledge within both the development and marketing organizations in SAP. This is an example of poor development decisions being made by people within SAP. It stems from SAP resources that both don’t understand the warehouse management market very well and apply a kitchen sink approach to product development.
A Better Strategy for EWM
SAP would have been far better off to direct EWM toward the needs of companies with APO already, that is, that have more basic warehouse management needs. This would also have made EWM much more implementable. This is a major factor holding back EWM from being a successful product. SAP has a tremendous advantage when they introduce new products. Many companies want to use SAP, and the problems with EWM and SPP in gaining market share demonstrate both how weak the products are and how poor the overall marketing and development strategy has been for these products. As a person who has been trained on both EWM and SPP, paying for the training myself, and this was money that was wasted.
SAP keeps marketing these classes and talking about EWM and SPP’s great future, but let’s get real, both these applications have had years to find an audience, and they have not for a good reason. I have personally questioned whether SPP is even live, that is, in a real way, at any account globally. Some of the first SPP clients have been trying to get the system live for roughly a decade. What is the length of payback on a ten-year implementation?
Should SPP and EWM Have Been Introduced to the Market?
I bought into the idea that SAP would have success with these new products, and in fact, I work in all the older modules. In fact, most companies, consultants, and even SAP itself would have been better off if EWM and SPP had never been introduced. Instead, SAP should have allocated the development effort to fixing the continuing problems in the pre-existing modules.
If SAP is ever serious about getting traction in EWM or SPP (which will be more difficult now that they have generated such a problematic track record), they need to hire people with business experience in warehousing and service parts planning, something which they have not done very much of up to this point.
What These Products Have Lead To
- Individuals waste money on products that are in the beta stage and not ready to be implemented.
- Companies spending implementation and software license on products they could have spent on best-of-breed applications actually worked.
- Friction between consultants who work in these modules depends upon them for their livelihood and those like me who point out that these products are not ready for prime time.
- Confusion within companies as to what the actual direction is with these products.
- Resources diverted that could have been used to make the other APO modules better and less buggy.
- A less efficient market, with limited monies that could have gone to vendors like MCA Solutions or Servigistics (for service parts planning) or Red Prairie or Manhattan and Associates (for warehouse management), all of which had products that were fully functional and ready to add value to client’s businesses.
What is the Future for EWM?
The future for EWM does not look good. SAP will probably try to reboot it, but rebooting it won’t be easy. I am also unsure that warehouse management offers the types of margins that SAP is used to. SAP’s WM product took minimal development effort and is more of a glorified inventory management system than a true WMS. It has been moderately successful in terms of implementations, although it is a bad product overall. However, with so little invested in it, it was still a worthwhile development. EWM took a lot of development work and will take much more development work to get right. If I am managing SAP development, I may consider cutting the product. I don’t think they will, but it may end up like the F&R module. That is, it exists, but it’s not actively implemented.
Conclusion
This article was written in 2012. This conclusion was updated in June of 2018. Since this article was written, EWM has all but disappeared from the marketplace, taking enormous amounts of consulting hours down the drain with it.
As we made this prediction in 2012, and if customers heeded the advice, instead of listening to Deloitte or Accenture, they could have saved themselves the cost and loss of time in implementing what was always a doomed application. For some reason, we doubt that Deloitte and Accenture, and many others will be published on how they were so wrong on EWM and how they billed so much for an application that could not be taken live.