By way of introduction, I am a SAP consultant that started out as an end user in a distribution center 11 years ago (now certified in SAP-LE). My strength is in process knowledge around logistics execution – warehousing and distribution.


I am creating this blog to give some advice and hopefully help improve your future implementations if you fit the description in the title of this post. The opinions expressed in this post are based on observations during 6 (well 5 and 3/4 to be totally honest) end to end implementations.

I have seen that there is some room for improvement during many initial design and blueprint phases when SAP is implemented in an operational setting like SAP warehouse management.This could also apply to any other process area where users are executing transactions in SAP.

First I need to say (and stress): SAP Loves People!!!

SAP is happiest when it can spend a lot of time with all the staff members using it and it tends to behave badly if its neglected. It clearly cherishes the moments together with its end users. As consultants we need to be mindful of this when mapping out requirements and offering solutions to a company that is new to SAP-ERP systems.


While SAP obviously offers superior levels of tracking, control, monitoring, reporting and transaction processing function modules then any other existing software offering similar solutions it also comes with some risk. The risk increases when replacing legacy systems without all the options and functionality of SAP. The risk as I see it is using too much and automating too little.


What I am trying to say is that standard SAP requires more time executing steps and checking processes then any other similar system. I use the term similar loosely considering no other platform is nearly as robust as SAP. Taking that into consideration we need to do our best to use “tough love” and limit the amount of time SAP is allowed to spend with its beloved end users.

As we all know the vast majority of consultants currently working on SAP implementations do not have a strong background in operations. Meaning most of us haven’t picked items on a pick line or loaded trucks with a forklift on the dock of a warehouse. I believe most consultants coming into this field these days are actually talented programmers and developers making the switch to consulting to move forward in there carriers ($).

All that being said here is where the real advice part comes into this post. When considering implementation options for any process that involves human interaction with SAP:

First: Consider the previous system and whether or not there staff spent much time executing the same process you will be implementing SAP for.

Second: Compare the current process with the legacy system with the to-be process in SAP in terms of time spent completing the process.

Third: Take the above as a first point of consideration before making any suggestions on implementation.

I have seen many processes and functionality put into production systems that were less efficient then legacy systems and on occasion completely unnecessary.This could have been avoided, to some extent, if the consultants had taken the points above into consideration as a rule.

I will mention a couple examples as briefly as possible.

1. At a multilevel distribution center where there legacy system did not include any WM systems. They had no computers in the DC other then a few in the managers office and most of there staff members were computer illiterate. Every thing was done on paper and later updated in there system by a select few employees. There through-put or volume was rather low and there processes were actually quite efficient (considering how outdated they were). We implemented SAP-WM with RF picking and a full suite of complex customized transaction that covered all internal process at that site. The end result of the project was good and they are currently working with the all the benefits that SAP provides. However getting to that point was extremely painful for every one involved and there was a negative financial impact (orders didn’t ship on time and the company lost customers as a result). The main complaint from the business is how long it took to complete processes using SAP. In this case the difficulties should have been anticipated and accounted for during the design phase. In this case the business would have been better server by using SAP IM only (no WM level functionality). Literally every aspect of there current processes and level of proficiency with computer systems pointed to a simpler method of implementation but that was never taken into account. The business suffered because the consultants assigned to the implementation considered system development and design above the practical application of the product at that specific site.

2. At a modernized distribution center using a WM system that was already customized to improve efficiency we implemented SAP-ERP and WM. For the most part the implementation was pain free and seamless. SAP was accepted by there staff, they learned and adopted the new system quite efficiently. However select functionality was put into place that increased the transaction processing times by more then 200%. This was done to meet business requirements and it was done without any consideration to how long it would take to process the volume of updates manually. The focus was strictly on how to make it work from a development perspective. In the end two separate process areas were unable to complete there processes and a large backlog of work built up. We were forced to revisit the site and completely re-work the functionality and start with completely new development (throwing out all the hard work that had been done). We were of course able to stream line the processes and automate steps by developing new transactions that took into account the volume of work in those process areas.

In both of the cases above there were serious concerns raised and endless complaints to upper level management.If the Developers turned Consultant had read and followed the advise laid out in this Blog the issues would have been avoided completely.

We have to put ourselves into the shoes of the end users and imagine how the process will work day to day, we cannot limit ourselves to the development options and system perspective or in the end the project suffer. If we don’t understand the process well enough we should spend a few days working with there staff during the initial design. That will give us a better picture of what we should do for them and it’s a great way to build relationships that will help smooth the transition.

Note: never discount the importance of training the users on saving variants and layouts in standard SAP transactions, could have avoided creating a few customized reports over the years if there was more focus put on that. But I suppose that’s a different blog

Best of luck in your future deployments, I hope this helps in some small way!!



To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

    1. Jacob Rose Post author

      Thank you, hope I didn’t come off as being anti developer turned consultant, actually the perfect mix would be one functional consultant from the business side (with hands on experience ) and one former ABAPer as a team in each module

      The former ABAPer can keep the process guy from making any stupid promises and the process guy can help the ABAPer avoid putting in dev with too many steps for the users

      🙂

      But how often will the client be so lucky? Not often I *** u me.

      (0) 
  1. Ramesh Babu Nagarajan

    The functional consultants who are not actually developers per se should cover this aspect you have elaborated well. It is their responsibility to convert the business requirements into SAP configuration / development requirements and then carry out the required design activities.

    (0) 

Leave a Reply