GRC 10.1 to 12 upgrade – Plan your GRC upgrade project now

Having the right planning and approach, along with the right technical foundation, can smooth the pathway, drive success and maintain the momentum to execute your strategic vision. This blog is against the backdrop of the end of maintenance of GRC 10.0/10.1 on 31.12.2020 and I will outline Proposal and Project Planning aspects of a typical SAP GRC upgrade from 10.1 to 12 in a business environment. Although from an operations perspective, this would be considered as just another upgrade, I strongly believe that it is crucial to plan this upgrade ahead in time as it involves all systems in the landscape and brings in multiple new features and functionalities. Please note this blog not just talks about the technical upgrade but focuses more on project planning and consideration that must be made for successful and flawless implementation that would entice consultants working more towards planning and implementation and not exactly on operations. So let’s get started!

1.      Why GRC upgrade is crucial in this year 2020?

As the Mainstream maintenance for GRC 10/10.1 will end on 31.12.2020, it is required to plan and implement an upgrade to version 12. Refer SAP Note: 2878927 – End of Maintenance GRC 10.0/ GRC 10.1 –  2878927 – End of Maintenance GRC 10.0/ GRC 10.1

What composes of a GRC system?

Following software components,

• SAP ACCESS CONTROL 10.0
• SAP ACCESS CONTROL 10.1
• SAP ACCESS CONTROL 10.1 for SAP S/4HANA
• SAP PROCESS CONTROL 10.0
• SAP PROCESS CONTROL 10.1
• SAP PROCESS CONTROL 10.1 for SAP S/4HANA
• SAP RISK MANAGEMENT 10.0
• SAP RISK MANAGEMENT 10.1
• SAP RISK MANAGEMENT 10.1 for SAP S/4HANA

1.1 Customer not interested to upgrade?

Yes, there are customers not willing to upgrade or they might be planning to align to S/4HANA offerings, for instance, SAP IDM. SAP provides mainstream maintenance (formerly standard maintenance) as part of the maintenance strategy. At the end of the mainstream maintenance period either through an agreement, the customer can enter Extended Maintenance else, the contract automatically enters Customer-Specific Maintenance. There is also Priority-One Support at the end of Mainstream Maintenance for selected releases.  It should also be noted that extended maintenance has additional charges and customer-specific maintenance has limited support. Check SAP Maintenance Phases to understand further.

2.      Analyze the current landscape – Pre-requisite

To upgrade GRC to 12, the underlying NetWeaver version should be 7.52 SP0x.
Also, there are three major software components we focus on,

Additionally, HCO_GRC_PI – SAP GRC 10.1 Plug-in for HANA, can also be considered if you plan to have Emergency Access Management for SAP HANA database.

Direct Upgrade from AC 5.3 to 12.0 Version is not recommended, and SAP doesn’t support it. Please refer to the 10.1 Migration Guide available on Service Market Place,

https://help.sap.com/doc/9c44f65ba0c94979afd580e8aa7b6b74/10.1.0.0/en-US/Migration_Guide_-_SAP_Access_Control_101E.PDF?

For upgrading AC 10.0/10.1 to 12.0, refer to the AC 12.0 Upgrade Guide:

https://help.sap.com/doc/8e4687084c55465c85a653023b8ceab3/12.0.06/en-US/loiob418d62abab34473a573adf94bc3daf6_en.pdf

You can upgrade GRC 10.1 at any SP level system to GRC 12.0 for both convention ECC environment and S/4HANA environment, there is no “Minimum Required 10.1 SP Level” with an exception that if on GRC 10.1 SP24, then the target can only be GRC 12.0 SP05 due to technical limitations. Check SAP Note: 2813572 – GRC 12.0 Prerequisites.

Also, Direct Upgrade from AC 5.3 to 12.0 Version is not recommended and SAP does not support it, customers who would like to upgrade from GRC Access Controls 5.3 Version to GRC Access Controls 12.0, have to Upgrade to GRC 10.1 first, and then Upgrade the 10.1 to 12.0. Please refer to the 10.1 Migration Guide available on Service Market Place to upgrade from AC 5.3 to 10.1 – https://help.sap.com/doc/9c44f65ba0c94979afd580e8aa7b6b74/10.1.0.0/en-US/Migration_Guide_-_SAP_Access_Control_101E.PDF?

Also, perform an elaborate risk and impact assessment for GRC upgrade and connected systems.

3.      Decide on the target versions

Commonly faced confusion in GRC upgrade projects what I’ve noticed is the support pack level to be maintained on the target GRC system and that of add-ons on the satellite plug-in systems and the underlying NetWeaver versions for ABAP & JAVA. Here is the solution – an Excel spreadsheet is uploaded as a quick reference to SAP Note: 1352498 – Support Pack Numbering – GRC Access Control to assist in ensuring your systems are in sync. Only these support packs are valid by SAP.

Further, review the SAP Notes below for an overview of the Support Packages and how to install them.

SAP Note:1128727 Guide to install GRC Access Control Support Packages

SAP Note:1086823 GRC Access Control: When to use the VIRSA, NH or HR RTA

Support Pack levels for add-on components on the plug-in systems for various NetWeaver versions are shown mapping with the GRC Foundation software component that is installed on the GRC system. For further details on the Support Packs of the plug-in NetWeaver systems compatibility with the add-on component, check the corresponding release notes for each of the support packs like below,

2602825 Release strategy and Maintenance Information for the ABAP add-on GRCPIERP V1200_S4

2602564 Release strategy and Maintenance Information for the ABAP add-on GRCPINW V1200_750

4.      Upgrade Approach

Main consideration determining the upgrade approach is what kind of an upgrade it is from a business point of view,

1. Technical Upgrade: Business doesn’t expect to use the enhancements and new features coming with the upgrade, but to continue current functionality only. Regression testing is less, and impact assessment is to see if current functionality works in the upgraded environment

Technical upgrades can be done with yearly or bi-yearly patching plans that project teams usually plan. GRC system can be upgraded with all other systems in the landscape, usually know as “Big-Bang” approach

2. Function Upgrade:  Business would like to take full leverage of enhancements and new features coming with the upgrade. Regression testing is elaborate and impact assessment is extensive to see how new functionality can be adapted and implemented in the upgraded environment.

Functional upgrades can be done with other systems following the Big-Bang approach but as timelines for testing would be long, usual this is planned and executed separately, probably as a mini-project.

4.1 Upgrade plan

Upgrade plan can be like any other conventional upgrades – a PoC upgrade can be performed on the Sandbox system with aggressive SIT, UAT testing to have the majority of the test case scenarios, test scripts and cut-over plan steps with red-book entries. Also, a system copy of the Production can be taken to perform the mock upgrade. A quick production system clone can also be taken (if a fast snapshot-based clone is configured like Azure NetApp Files data volumes) with adequate firewall settings to ensure isolation of the clone system.

4.2 Plug-in System upgrade

For upgrading AC 10.0/10.1 to 12.0, refer to the AC 12.0 Upgrade Guide:

https://help.sap.com/doc/8e4687084c55465c85a653023b8ceab3/12.0.06/en-US/loiob418d62abab34473a573adf94bc3daf6_en.pdf

Although SUM is the SAP preferred method for Installing and Upgrading including the add-ons, SUM requires Unix root access and the process for getting root access can cause delays. Hence, ABAP Add-ons can be installed via STACK.XML with SAINT as well. As a best practice approach, it is suggested to stop all the jobs and log off all the users during installations of GRC Plug-In

4.3 Project Plan

A typical project plan (template plan) is as shown below. An elaborate project plan must be presented to the customer/management to get the SOW signed. Once this is done, funding and resource management talks can take place to ramp-up on the project.

4.3.1         Major activities

As see in the plan, below are the major activities for this GRC upgrade activity,

1. Refresh: All non-prod systems apart from DEV are refreshed from the latest PROD data before the upgrade
2. GRC plug-in on satellite systems can be done during off-business hours or during weekends – plan in such a way that for each landscape upgrade completes by the weekend.
3. Upgrade and testing on Sandbox would be elaborate and extensive to identify the potential challenges and issues well in advance.
4. SIT, UAT testings are performed on Quality and Pre-Production. Some perform both on the same landscape – in absence of Prepord landscape
5. A clear process must be defined to obtain signoffs for the upgrade, SIT and UAT testing from the business for each landscape before moving to the next. Typically, these are IQs (Installation Qualification) and OQs (Operation Qualification) customarily observed in Pharma clients.
6. Hyper care & Steady-State support: post-upgrade support needed, followed by the maintenance and operational support of the new system and its users. This also includes training of the new support functions; staffing up for the user support and issue management etc,.
7. Document and create a central repository for the technical, process, change documents and the software dumps to be used for the entire project
8. Timelines here are only indicative and can change depending on various factors

4.3.2         Timeline – Due Diligence

1. Apart from signoff, few projects prefer involving client technical architects, BPOs for testing in Sandbox, SIT and UAT – hence the extended timelines in Sandbox. This would bring a sense of transparency and shared ownership with the client.
2. As obtaining signoff to move to the next landscapes are crucial compliance matters, timelines in the plan should ensure the availability of the Architects, IT Managers, and other approvers. Avoid having upgrades, SIT & UAT testing completed during the vacation/festival time

4.4       Change management strategies

Due attention must be provided to continued support for development, customization and change management during the entire period of the upgrade project. To do that, below upgrade plan can be followed,

4.4.1         Change Freeze

Upgrades can be performed sequentially from DEV to PROD. During the DEV system refresh and upgrade a short change-freeze would be called for.

4.4.2 Emergency (Stand-by) Landscape

The upgrade can be done sequentially with a Temporary/Emergency system as a place holder for the DEV system during its upgrade. In this case, the temporary system would be refreshed from DEV and upgraded before using it as temporary DEV. Change freeze can be avoided as this acts as a temporary DEV system during the upgrade of the actual DEV. Crucial it is to ensure changes made in this Temporary DEV has to be back-synced to actual DEV after its upgrade to continue the development/customizing

There can be other various approaches that can be taken. These are generic upgrade strategies and are a huge and interesting topic to be studied.

5.      Value-added services for the customer

Along with the GRC upgrade, what I did was to recognize potential pain points for the business/customer and see if it can be addressed as a part of the upgrade plan going beyond the contract to gain customer satisfaction and delight,

1. Resizing and revised hardware for GRC system
2. Migration to HANA DB if not done to fully leverage on GRC Functionalities
3. A kernel patching/upgrade to the latest version during the add-on deployment on the plug-in systems
4. Critical analysis of the customer landscape would reveal other issues. I had looked into the incidents and problem tickets on the GRC component raised in at least the previous 6 months and had discussions with GRC consultants to draw a more comprehensive analysis.

6. Conclusion

As you can see, in this blog I’ve provided an overview of a typical GRC upgrade project. It’s focused more on technical requirements and project planning for a successful GRC upgrade. If you’re interested to know in-depth steps and execution plan for this please let me know in the comment section and I can come up with another blog.

Please like, share and drop your suggestions, learnings in the comment section. Want to know more or you too are an SAP junkie and just want like-minded people? Feel free to reach out to me.

Happy consulting! 🙂