Implementing an SAP ERP solution across the enterprise comes with a big price tag for the companies. Generally they run for years from the ideation phase to the deployment. It is not an easy thing to reach to the deployment phase, it needs a lot of hardship. Most of the times the business focuses on getting the solution to the live environment but often they miss to prepare for the post go-live. Business must have a solid plan to bring the operations to full pace sooner after the go-live. As part of this effort the IT team owns the responsibility to stabilize the system to run the operations smoothly.
In this blog, I tried to present some guidelines by summarizing my experiences in stabilizing the S4HANA EWM (embedded or decentral) post go-live of S4HANA solution. Most of these may applicable in general to any SAP module or ERP solution.
I broadly categorized the process of stabilizing the S4HANA EWM system post go-live into three phases.

- Prepare
- Act
- Reflect
Prepare
In the preparation phase,
- Make sure the design documents are up to date.
- Consolidate all the training materials including job aids, store them in a document repository with proper labels.
- Make sure the IT and business teams got the required training.
It is very common that the implementation team and support team is different in many ERP projects. As the teams change there will be a loss of knowledge. So, it is very important to have all the documents and in “up to date” status. It is must, even though the support team and the business users get the training at the time of go-live. Having the latest documents will help you to go through them in the future if needed. Also, you can advise your team members or the users to go through the training materials if they are new to the team or need a refresh of the process.
Act
This is the most challenging phase in this process where the teams get succeed or suffer for longer periods to stabilize. From my experience it is very important to have self motivated and pro-active team along with the EWM expertise. I assume you might have some sort of tools (like Jira, SAP Solman, ServiceNow etc.) to log the tickets and monitor them. Some of the key rules to succeed in this phase are given as below.
- Categorize the tickets based on the root cause: Most of the projects will have daily triage meetings but often they failed to identify the correct root cause, and directing the tickets to the right team. This will cause delays in fixing the issue and consequently impacts the operations badly. For example, slow performance of an EWM RF transaction is impacting the productivity of the users. It might be due to a bad WiFi network or a custom development. This needs to be analyzed and assigned to the correct team quickly. To help you with the categorization of the tickets I propose the below labels. While analyzing the ticket try to understand, is the issue caused by
- configuration
- custom development
- user error
- master data setup
- infrastructure such as Authorization, Basis, Network or the hardware etc.
Once you labelled it correctly, it will be easier to work on the fix.
2. Fix the tickets to the root cause: Sometimes the consultants tend to turn around the ticket by providing a work around or a temporary fix. Remember that it will not solve the problem completely. Even though the impact or priority of the ticket is downgraded after the quick fix, it is advised to continue to work on the ticket until it gets fixed to the root cause. Otherwise they will repeat forever.
3. Monitor the system actively and take the mitigation actions: Prepare a list of items that need to be monitored manually and automated. For example you may want to manually monitor the error queues for every hour and stock mismatches on a daily basis but setup automated alerts for the failed batch jobs and IDocs.
I had seen the projects where they had hundreds of queue errors and struggling to resolve them for years. Queue errors and Stock mismatches are tied to each other mostly. Mishandling of Queues such as saving the Queue or editing the Queue data without having full knowledge will lead to more problems. So, it is very important to handle the Queues and the Stock mismatches between EWM and S4H EM with priority. A couple of suggestions to reduce the Queue errors are to target the Queues based on the error message rather than going by each single Queue, and fixing the dependent Queue first.
Make sure to work with the business regularly for the bin counts and keep the stocks consistent in EWM and S4HANA. Otherwise warehouse will see the deliveries for no stock or no deliveries though they have stock.
4. Have weekly or bi-weekly connects with the business users: Get the feedback from the business to understand what is working or not working, what needs to be improved etc. details. Make sure all the issues are reported in the ticketing tool.
Reflect
The purpose of this phase is to reflect on the current state of the EWM system.
- Prepare a list of process improvements or the changes to the system needed and deliver them as per their priority.
- Keep the documents up to date.
I wish you good luck if you are preparing for an EWM go-live or already working stabilizing the EWM system. Hope the above are helpful to you. Let me know if you have any questions or share any of your experiences. Also, if you need any help we are happy to help you with your journey. We helped multiple clients in stabilizing their EWM application. Visit the contact page to reach out us.