What This Article Covers
- Understanding the enormous configuration effort with SAP EWM.
- Functionality overkill and the IMG.
- The logic of EWM’s design.
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 to me the importance of limiting 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 very limited and simplistic functionality in SAP WM, EWM is its polar opposite. However EWM projects will simply have to take more time and more 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 simply uploaded. Multiple line items with the same first cell of the row would simply mean how many items in a particular area would need to be setup. So 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 simply be copied over three times. A very significant benefit of this is a basic configuration 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 really just an offline tool.
In the movie groundhog day, Bill Murray’s character keeps reliving the same day…kind of like the experience of reconfiguring SAP boxes because I cannot port my configuration from one box to a new one.
I have become very tired of all of my configuration work being annihilated when a box is refreshed. Why can’t I port my configuration from SAP system to SAP system? Why must I reinvent the wheel every-time I arrive on a new project? SAP has few to no answers in this area, and clients do not seem to know how much double work there is involved with an SAP implementation because SAP has made it so difficult to maintain their systems.
A Logical Solution
The most logical way of handling this is to create a file that can be manipulated in Excel, that contains all configuration details. This file could then be uploaded to SAP. The system would parse the file for logical consistency, and would reject files and provide an error log for improperly configured files. This would help remove the bias of so many IT projects where after the initial design stages the project basically leaves the business behind and the entire project becomes about the technology.
Who is the Most Accurate Source on SAP?
Want to find out? See... A Study into The Accuracy of SAP