7 headaches after ERP go-live you have to avoid

Reading Time: 6 minutes

In this post, we highlight a couple of key problems that typically arise at the moment of go-live with SAP or any other ERP system. The ERP implementation has been prepared for months and then it goes wrong. Time and time again, we’ve seen the same patterns. When the cutover plan is well prepared, it is our experience that ERP cutover problems are easy to avoid or overcome.

Remember that an ERP implementation is much more than just another an IT project. Manage the ERP project as a business transformation project that touches the core elements of your business.

1. Material availability inconsistencies

One of the key benefits of any ERP system is the integrated and automated availability check. Because all data is centralized, information about availability of goods is at your fingertips. It goes without saying that all that data has to be accurate in order to have a reliable availability check. 

Inconsistencies can lead to a variety of direct and indirect problems:

  1. blocked/broken processes: user is not able to create delivery and organize transport, even though goods ‘should be available’.
  2. customer delivery performance issues: at the point of issuing, the goods appear not to be physically available.
  3. wasteful expenditure of time and resources due to misalignment between various persons and departments involved.

There are many elements that can lead to incorrect availability information. Typically, a variety of departments and functions are involved. Below we highlight the most important areas that impact accuracy of availability information during ERP go-live:

• incorrect stock figures: initial stock upload errors, wrong/missing consumptions, dummy stocks (on interim storage types), COGI (goods movements with errors), etc.

• open production or purchase orders: orders that were planned but never executed, orders that were partially executed but not closed and orders that are delayed without updating the system.

• unshipped sales orders and outbound deliveries: sales orders that were planned but never shipped, sales orders that were partially shipped and orders that were delayed without updating the system.

• future stock reservations.

• external/consignment coldstores.

• material master misalignment (see below).

How can you avoid headaches from material availability inconsistencies after ERP go-live?

  1. Create awareness. Organize cross-function workshops on availability long before go-live. Explain the risks related to the advantages of integrated material availability checks.
  2. Install follow-up routines and metrics. Be clear on who has to follow-up what, how and with what frequency.
  3. Make stock upload validation a key pre-go-live deliverable. We know it is a hell of a job, and it requires an awful lot of preparation, but doing a full stock upload test and validating the outcome is key for a successful go-live.

Are our posts inspiring you? Sure you will be impressed by our cloud solution to accelerate ERP implementations, powered with ERP methodologies, templates and best practices. Learn how it works here.

2. Material master misalignment

Are you sure the item or material code definition is applied the same way in SAP/ERP as it was in your legacy system? Chances are very high you will not have a one-on-one link between both environments. When it turns out after go-live that different definitions of a material code have been applied throughout the organization, the consequences are large and hard to tackle.

How can you avoid headaches from material master misalignment?

  1. Focus on the definition of the new material codes from the beginning of the project. It’s all about having the right level of detail. How do we define an item code? How does that relate to our legacy system material code definition?
  2. Install a central master data governance function. Involve this person/team in all areas touching material master. Distributing material master data preparation will most likely result in a headache at go-live.
  3. Install cross-checks when preparing (master) data where material item codes are being used (sales contracts, inforecords, initial stock upload, bill of material, …)

3. Account determination issues

Another huge advantage of an ERP system is the integration between logistics and finance. Goods movements trigger automatic G/L and cost center postings, which reduce accounting workload and increase financial analytics capabilities. However, inconsistencies in account determination can lead to incorrect postings, and if a determination rule or G/L account is missing, the user will not be able to confirm the logistics action. Consequences can be massive.

How can you avoid headaches from account determination issues?

  1. Test, test, test. Make sure all relevant scenarios and variants are tested before going live. Execute end-to-end tests with a finance key present.
  2. Be prepared. Make sure you have a plan, process and staffing on how to tackle account determination issues as quickly as possible when going live.

4. Missing master data

You know master data is key in SAP! We cannot stress that enough, but you already know.

But pay attention, there is a lot of master data in SAP that users do not realize is master data. Quite often they assume what is actually master data is configuration that will be automatically available on the productive system. This is not always the case!

Here below some examples (non-limitative):

  • output determination records for orders, deliveries, billing, etc.
  • tax conditions (MWST)
  • work centers
  • number ranges
  • classes and characteristics
  • WM control cycles
  • specific texts on printed documents

Just to mention some …

How can you avoid headaches from missing master data?

  1. Discuss this risk and how to mitigate it with your consulting partner.
  2. Prepare a central master data repository from the very beginning of the implementation. Update the repository during the preparation. Make sure it is clear ‘who’ has to do ‘what’, ‘when’ and ‘how’.

5. Handling customer return orders

Handling customer return orders is a solid – but rather heavy – process in SAP. During training and go-live preparations, this process is quite often overlooked. You have to be aware of the risk of facing a higher volume of customer return orders and the fact that – in the beginning – it will be much more time-consuming then before.

When not handled in a correct and timely manner, customer return orders can heavily impact your logistics and customer service department.

How can you avoid headaches from handling customer return orders?

  1. Assign one key user (and a backup) to handle customer returns physically. In later stages, multiple persons can be involved.
  2. Document and communicate the roles and responsibilities for logistics and the customer service department. How will exceptions be handled? What about unplanned returns? What if references are missing?
  3. Inform customers on the returns procedure to be followed.

6. User authorization issues

There are many possible reasons why a user cannot access a transaction or object:

  • mismatch between organizational design and daily practices
  • requirement has not been captured during preparation
  • requirement has not been configured appropriately

We want to stress the fact that an SAP implementation/project can only be successful when role fragmentation is limited as much as possible. There should be a strong focus on reducing the number of users performing the same operation and reducing the number of operations cumulated by the same user.

How can you avoid headaches with user authorization issues?

  1. Create a RASCI (responsible – accountable – supportive – consulted – informed) matrix from the beginning. Use this as a central repository throughout the whole project. Find some templates here (9teams_process_overview & Process_Flows) to get you started.
  2. Start simple. Don’t make roles too specific in the beginning. Make sure key ‘critical access’ and ‘segregation of duty’ risks are covered.
  3. Perform integration and validation sessions WITH users assigned to their productive roles.
  4. Make sure all users have access to transaction SU53 (display authorization check).
  5. Install a process for requesting, approving and assigning authorizations to users before going live.

7. Users locking each other

A typical problem we see days and weeks after go-live is that users get locked by other users. We don’t know why, but we see a lot of transactions that are executed in change mode, while the user only wants to display an object. Nine times out of ten, they don’t change anything, but there is always a risk that they lock other users. On top of that, users get interrupted, resulting in those objects being locked for even longer.

How can you avoid headaches from users locking each other?

  1. Create awareness by communicating this risk to all users at the moment of going live.
  2. Make sure all users have access to transaction SU01D (display user data). This way, they can identify the person behind the user and get in touch directly (if the contact details are specified in the user data).
  3. Make sure you have an emergency procedure installed, in case an administrator has to intervene to unlock the object.

Are our posts inspiring you? Sure you will be impressed by our cloud solution to accelerate ERP implementations, powered with ERP methodologies, templates and best practices. Learn how it works here.

One simple way to improve your ERP skills

Signup to the 9TEAMS newsletter today to receive one update per month.