Business Solutions with SAP
SAP smooth go-live requires a lot of coordination

SAP go-live issues

After you’ve done all the research, and gone to all the trouble to make your project a success, there are still four key areas that consistently cause trouble during your SAP go-live:

1.  SAP Security and Authorizations.

2.  Master Data.

3.  Business process changes, process gaps (missed processes and exceptions).

4.  SAP ABAP Custom Development.

While each of these areas consistently cause trouble at go-live, resolving the first item, Security and Authorizations, and the third item, Process issues, should be a standard part of every project no matter who does it.  There is just no real reason for authorizations or business process issues to be a problem on any project.

The Master Data and Custom Development are a bit more difficult to resolve.  Even companies that believe they have a good handle on master data often discover that it is not as “pristine” as they might believe.  Custom development can also be another source of headaches.  Often it is some “gee wiz gotta have it” improvement, automation, or rearranging a printed form 20 times to get it “right” where development can come back to bite you if you’re not careful.  This is especially true with inexperienced developers who read some ABAP programming book, or take some back room fly-by-night “certification” course and then get a fake resume presented.

1.  SAP Security and Authorizations…

To reduce SAP go-live headaches, security and user authorizations must be carefully tested.  By testing I am *not* referring to consultant testing, core team testing, or even extended user (power user) testing–, I mean actual end users logging in under their own SAP user ID’s and verifying they have what they need to get their job done.

The most effective method I’ve seen over the years is to incorporate authorization testing into the end-user training.  Usually end-user training has “dummy” training user ID’s created that are used during classroom training.  However, the best solution I have seen is for SAP end-users to use their own ID’s during training.  They log in under their own ID’s and then verify that they have access to all of the transactions they will need at go-live.

At one client the users had a form that matched their training classes and users had to initial a sheet next to each transaction they tested, sign the sheet, and then turn it in at the end of the course.  If there were problems they were noted on the form and sent in to security to be resolved.  The users then make use of their training ID’s for the classroom training.  While this is a little disruptive to the classroom training process, it is the most effective method I have ever seen.  The idea is that the end user must somehow log in and test their logon ID long before your SAP go live.  However you decide to do that is up to you, but doing so will reduce many headaches after go-live when everyone is focused on trying to resolve fires, gaps, process changes, and the users learning a new system.

Suggestions and ideas for handling SAP security

1)      Integrate the SAP security and training efforts.  Those identified for training should also have the tasks and transactions they will be trained on identified.  This is a good starting point for security access as well.

2)      Be sure to test security with every end user before you actually go-live.  This will help to reduce the production headaches with security and authorizations; unfortunately it will not eliminate them.

3)      Take the time and effort to carefully structure your security and authorizations.  Done properly authorizations should not be a maintenance nightmare.

Other than the obvious reasons, security maintenance after your SAP go-live can not be overemphasized; after the consultants leave this is one of the routine, regular, and ongoing maintenance areas and if there is not enough attention paid to it from a long term maintenance perspective you may have to live with a “nightmare.”  Aside from the normal security concerns an improperly designed security strategy will cause you ongoing maintenance nightmares because each person will eventually end up with completely “unique” one off security objects.  That translates into significant maintenance overhead that is not necessary with a properly designed security strategy.

Four Part Series on SAP Project Planning for a Smooth Go-Live:

Planning For a Smooth SAP Go-Live: Part 1
(introduction, security and authorizations)

Planning For a Smooth SAP Go-Live: Part 2
(master data, data transformation methods)

Planning For a Smooth SAP Go-Live: Part 3
(process issues, blueprinting, testing, and change management)

Planning For a Smooth SAP Go-Live: Part 4
(custom development, costs and consequences of inexperienced developers)


Contact me today through our site contact form ( ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175
Bill Wood contact


Print pagePDF pageEmail page

Related Posts:

One Response to “Planning For a Smooth SAP Go-Live Part 1”

  1. Would like to add my two cents to the discussion.
    ABAP (Advanced Business Application Programming), to me, is much like a COBOL and/or C hybrid. The value versus reference feature reminds me of C. The commands (MOVE, WRITE,…) and PERFORMs remind me of COBOL. ABAP constructs (Loops, subroutines, if/then,…) seem similar to constructs in other languages. The only aspects of the language not communicated in this web site are SAP GUI related features (Like functions defined in the SAP GUI). I felt ABAP GUI features/impacts would be too difficult to accurately explain.

Leave a Reply