Does SAP EWM Have Close to 2,000 Live Customers?
Executive Summary
- There are few credible sources on the number of customers for various SAP products.
- We review the issues with the reported numbers for SAP EWM.
Introduction
It is easier to find the number of customers of an application than to find the number of live and active customers. This is because a customer is merely a company that holds a license for an SAP application or database. However, SAP customers have high amounts of shelfware.
Who Wants to Report Accurate Numbers?
The overall market of providers of information on the number of SAP customers overestimates the usage of SAP applications because they intend to promote SAP. Therefore, the first test is whether the provider of information has a bias to underreport or over-report the number of users. This eliminates SAP, SAP consulting firms, ASUG, and IT media entities. IT media entities, in particular, tend only to repeat the numbers provided by SAP.
Sales Intelligence Firms
The only companies we have found that provide somewhat reliable data are sales intelligence firms. These companies are not trying to sell SAP or SAP consulting services. Instead, they sell intelligence to salespeople and sales organizations that want to sell items into companies with SAP or other vendor products.
One of these companies is HG Insights, and we have included their estimates for the product SAP EWM.
About SAP EWM
SAP EWM is one of the worst applications we have ever reviewed and has had a tremendous failure rate. Additionally, it is not designed for shippers but instead designed around the requirements of the third-party logistics market, which is not where the application is sold.
The Method Used for Application Verification
We can’t believe that there are anywhere near 1,837 customers currently using EWM. Does this mean that we question HG Insights’ desire to be accurate? No, we are not questioning that, because as we will discuss in just one moment, there is a natural positive bias in the measurement process.
Common Issues with Application and Database Measurement
| Issue | Description |
|---|---|
| Incentives of IT within Implementing Companies | Once companies implement software they will keep that software running for years, even if it is providing minimal or no value so that they cannot be accused of making a mistake with their purchase. This means that even if the verification company is trying to get to the real value, the overall system serves to cause an overstatement of the number of live customers to be the norm. Furthermore, IT departments routinely overstate the usage of their systems by business users. |
| The Depth of the Verification | Depth of the verification is also an issue. It is unlikely the verifiers know what questions to ask, and that they have much time to ask questions about the usage of the products. An application or database can be used very minimally or intensively. If the measurement is simply "in use" this will capture many applications and databases with minimal usage, which is captured in the next point. |
| Verification Frequency | Companies that verify the entirety of the customers each month, so they space out the verifications. But the general interpretation is that the verifications are current. This is not so much a criticism of the entities performing the measurement as the interpretation of what the numbers mean. Again, verification is hard. |
| Task Difficulty | It is extremely difficult to determine the actual number of active customers of these applications. And there is a high burden of effort to verify whether companies continue to use an application or database. |
SAP WM
Let us compare the EWM estimate to the SAP WM estimate.
SAP WM comes as part of ECC/R/3. It has been around far longer than EWM. While it contains far less functionality than EWM, it is implemented in many more locations than EWM. It is doubtlessly far more than (4699/1837) = 2.5 times more popular than EWM. Therefore, while we do not believe the EWM estimate, we have no issue with the WM estimate.
How to Manage The Tremendous Complexity of SAP EWM
In developing a configuration document for EWM, it became apparent how large and complex the configuration of EWM is. In my previous implementation, we only brought up a few areas of functionality, such as slotting and rearrangement. However, the setup options of EWM seems to go on and on.
I counted at least 40 basic master data setup objects. Slotting itself has around 20 either direct objects or mappings between objects. The items are so numerous I am thinking of using mind mapping software to keep track of all of the relationships. One way to manage the complexity is to code each object as to whether it is in scope for the implementation. Then filter the objects for just the in-scope objects (and mappings), and it will substantially cut down the list necessary for me to review as I go through requirements gathering.
This will be the first time I have done this aside from creating a blog based configuration document for SNP. While it’s great to have, I don’t think a word processing type document is the right format anymore for this type of detail. I think more advanced tools are necessary.
How Far Down Does the Rabbit Hole Go?
After spending a great deal of time organizing EWM configuration screens into an external tool for reference on future projects, I increasingly appreciate how massive the EWM application is. I now have over 700 rows in my spreadsheet, each row representing a configuration screen. This, along with my implementation experience, highlights the importance of limiting the scope of EMW projects to something manageable. When compared to a module like SNP, there is just so much more detail to configure. Considering the minimal and simplistic functionality in SAP WM, EWM is its polar opposite. However, EWM projects will have to take more time and resources than what WM projects did in the past.
Functionality Overkill and the IMG
The size of the functionality is made even a more significant hurdle due to the inefficient IMG. The IMG serves to encapsulate information in a completely unnecessary way, and the large the functionality, the greater the liability of SAP’s IMG design. I have been wondering recently how much more efficient a configuration spreadsheet would be. The spreadsheet could be coded externally and then uploaded. Multiple line items with the same first cell of the row would mean how many items in a particular area would need to be setup. For instance, to set up four different Storage Types in EWM, three rows on a spreadsheet would be added to the spreadsheet. The master row would be copied over three times. A very significant benefit of this is a basic configuration that could be copied over from system to system. I have a spreadsheet like this, which I have created for my consulting practice. However, there is no way to upload it into SAP. So it is just an offline tool.
Limiting Scope and Lengthening the Timeline
This reinforces what I have thought previously about EWM. As the module with the broadest scope in SCM, getting clients to limit their project scope should be a heavy emphasis on any EWM project.
Secondly, software such as Red Prairie is far easier to configure. I would estimate that EWM projects have to be planned to be longer than typical SCM module implementations due to the inherent complexity of the application.
Conclusion
EWM has been a relatively popular application to purchase, but its implementation failure rate has been extremely high. The application is so high in overhead that it is unsustainable. This high number versus what we think is reality could be based upon the lack of accounting for this failure rate. It also means that if our general projection around EWM is correct, that a large number of customers purchased EWM but were not able to get value out of it.