Would you recommend giving end users access to LSMW?

I have some people in management telling us that we should push out the usage of this transaction to the business users. I disagree as this transaction is very powerful. Can you provide some guidance?


1 month


Jimbo's picture

Hi Mark,

Handing off recurring migration tasks to an end-user is not necessarily a bad idea. It allows migration resources to be applied to new tasks or rolled off of the project.

Granting LSMW access to an business user is a very bad idea. Migrating data into SAP is like performing eye surgery and the tools are horrifically complex and dangerous. There are better solutions for allowing end-users to handle recurring data migration tasks--especially if these tasks are simple.

Optimally the best solution would be an unattended one that involves iDocs or some simple interface to SAP. If business user involvement is required in the recurring process then a non-LSMW option should be considered first.

A short custom program that repeatedly calls a BAPI based on source data provided by a business user is a relatively good option. It can be used to validate the source data and then provide feedback to the business user using the simplest interface possible. Simplicity is the key to a short learning curve; if a business user is forced to call the developer to understand how to operate the solution or how to interpret the feedback therefrom then the solution is lacking. LSMW would require a great deal of training, a long ramp-up time and almost certainly require constant interaction with the developer.

The MASS transaction may be a suitable solution for competent, trustworthy resources that need to make the same small change to many objects at once. The MASS transaction does not do direct table updates, but instead calls the appropriate programs for each object and the data and permissions are validated every time. This would require some training, but would still be a better solution than LSMW.

If, for some reason, a non-LSMW solution is unreachable, then a tightly controlled, locked-down version of LSMW may be your only option. A well-written LSMW object will require little ramp-up training from the developer and ample reporting would ensure that business user understands why records failed before trying to load them; reporting is key empowering the business user.

Please see this short overview for granting permissions to LSMW. It is 30,000-foot overview of a very complex topic, but it is a great start for your security team.

In conclusion:

SAP implementations are an ideal place to learn how to create LSMW objects from scratch. The catastrophic mistakes that we all make in the first months inevitably occur in development or quality systems without catastrophic consequences for the business. LSMW access in a production system without those first months of training and experience can cause too much harm and the risk is simply not worth the benefits of a quickly-empowered business user.