Down the Rabbit Hole with EWM Configuration


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 setup 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.

Groundhog Day

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.


Can Big Consulting Companies Perform Software Selection?


Big consulting firms are very quiet about their primary objectives during software selection.

After a number of projects increasingly the answer appears to be “no,” or at least not in a way that delivers value to the client.

The primary reason has to do with the internal incentives of the big firms combined with the low character of those in leadership positions. These companies are so focused on revenues that it is truly impossible for them to provide objective advice. For the big firms software selection is just an introduction for the implementation which they intend to staff. This holds regardless of the benefits to the client. I recently observed a major consulting firm turn away from a solution that was a perfect fit for the client on only what I can assume to be the fact that they would not have been able to place resources on the project (since they lacked the skills internally). The fact the software was a perfect match seemed irrelevant to them.

Outcomes

I have decided to focus on selection myself because the market is so poorly served currently. Continually picking the wrong software just because some major consulting company wants to staff a project is extremely bad for the economy. I have a link which describes this topic in more detail.

http://www.scmfocus.com/consulting/consulting-facts/why-big-consulting-firms-cannot-do-software-selection/


SAP’s Product Marketing Approach to SPP

SAP’s SPP History

In the Initial stages, SPP was sold as a very complex solution. Because it was implemented and developed as part of a combined solution for CAT Logistics, SAP appeared to think that the market would be interested in a more or less identical footprint. However, CAT Logistics is one of the most dedicated companies in the world to service parts, so their solution is not going to be appealing fort the vast majority of service organizations that are the potential market for SPP. Thus, unlike DP or SNP, which are often presented and understood that they can be implemented individually, SPP was presented as if it needed to be (or should be) implemented with a number of other different SCM modules. In its training material, SAP states the following.

“You don’t have to use all the building blocks (for SPP) ….but you will lose functionality.“ Solution Architecture and Implement-ability

Our response to this is most companies we have consulted with want the basic service parts planning functionality that is provided simply with SPP alone. So we question how realistic it is that most the companies looking to implement SPP are prepared to implement the full solution that SAP recommends, or at least recommended at one time. Putting in SCM modules is challenging. Putting in more than two modules at once is even more challenging. Furthermore, service parts businesses are greatly underinvested in, which means that many companies are starting from a lower baseline in service parts, in terms of IT and business knowledge, than their finished goods business.