After you have done all the research and gone through all the trouble to make your project a success, four key areas can still 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.
The Master Data and Custom Development, however, 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. What may appear to be beneficial improvement, automation, and rearrangement can come back to bite you if you’re not careful. Inexperienced developers are especially prone to this downfall.
1. SAP Security and Authorizations
To reduce SAP go-live headaches, users need to carefully test security and user authorizations. 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.
Usually, end-user training has sample user ID’s created for classroom training. However, the best solution I have seen is for SAP end-users to use their own ID’s during training. Ultimately, I have found incorporating authorization testing into the end-user training to be highly effective.
At one client, the users had a form that matched their training classes. They 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, users noted them on the form and sent them 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, I have found this method to be the most effective. The idea is that the end user must log in and test their logon ID long before your SAP system goes live. Doing so will reduce many headaches after go-live when everyone is focused on trying to resolve fires, gaps, process changes, all while adapting users to a new system.
Suggestions and Ideas for Handling SAP Security
1) Integrate the SAP security and training efforts. The business should not only identify users who need training, but also the tasks and transactions they will be trained on. 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 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.
Security maintenance after your SAP go-live cannot be overemphasized. After the consultants leave, this is one of the routine, regular, and ongoing maintenance areas. If you do not pay enough attention to it from a long-term maintenance perspective, you may deal with unnecessary headaches. 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, translating into unnecessary maintenance overhead. However, you can avoid this 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)
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.