I’m currently in the ramp-up stage of a technical SAP Upgrade from ECC 4.7 to ECC 6.0. Gary Byrne, Managing Editor of the Financials and GRC hubs of SAPexperts, recently published an article “Key Questions to Ask During an SAP Implementation or Upgrade.” [insert hammer to nail head mental image here] I’m writing in response to his article and to offer some additional “words of wisdom” from a security standpoint on how to manage a technical upgrade.
The greatest challenge a project team will likely face on a technical upgrade is lack of communication. It is often challenging to understand how the functional consultants and technical resources work together and when each resource is needed. When upgrading an SAP system, some tasks can be tackled simultaneously while others may require preceding technical work to be completed. Having a clear timeline (typically in the form of a Gantt chart) can aid the team in overcoming communication barriers and keeping the project on track. As Gary mentioned, it is important to understand the timing implications of making functional enhancements during an upgrade project. Often times, outlying issues come to the surface during a technical upgrade, a functionality gap or a spec for a custom report for instance, every project team should have a central repository to track issues and enhancements that can be processed post go-live.
We (the SAP security consultants of the world) are all well aware that the successful execution of a technical SAP Security Upgrade is all housed in transaction SU25. 2A-2D. I got beef with whoever decided that 4 steps was a comprehensive enough approach to such an arduous task. There are various aspects to consider before, during and after the execution of the aforementioned steps in order to pay proper attention to all aspects of the SAP Security landscape. Some of these considerations include the following:
1. What does the current role design look like? Does the client utilize derived or enabler roles? How will the upgrade affect the optimization of the security landscape?
2. With the introduction of new authorization objects comes the ability for increased design around local and global control points. Will these new objects have an affect on existing controls or call for additional controls to be added?
3. Are there any open transport requests that contain roles (customizing requests) or SU24 work (workbench requests)? Work with customer on plan to handle these during the upgrade.
4. Is the customer currently doing SU24 Maintenence? If so, SU24 must be maintained to reflect role changes that occurred throughout the upgrade.
5. Do you have an understanding of the roles that are currently assigned to users? Take a snapshot of security in the CURRENT production system.
6. Do new authorizations correspond to previously inactivated authorizations? Create a plan to work with the business to test effected roles and z-tcodes across various functional areas.
One additional pain point. When working on a SAP Security Upgrade, it’s hard to pinpoint an exact time estimate prior to starting the SU25 work. SU25 could propose 500 or more role changes and more changes equals more testing and role maintenance.
Happy Hump Day! Weekend’s just around the corner for me. Jetting off to Chicago Friday morning to visit some of the best friends in the world: JN, SZ, AW, KE, MG, JB! Phi or Die(CHI)?