Guidance on Transitioning Customized Risk Management Module to Out-of-the-Box

[thomasanton]

Dear Team,
As the Product Owner for our Risk Management module, we are planning to transition from our current highly customized implementation back to the out-of-the-box ServiceNow configuration.
We are seeking expert advice on the best approach to achieve this transition while minimizing disruption and ensuring the preservation of historical data.
Could you please provide guidance on recommended strategies, potential challenges, and best practices for this undertaking?
Thank you for your time and expertise.
Best regards,
Thomas

[Dr Atul G- LNG]

Hi @thomasanton 

For which module you are referring GRC or Change Management.

[thomasanton]

Hi Atul,

We are looking at the GRC module.

Thanks,

Thomas

[Dr Atul G- LNG]

Hi @thomasanton 

Even though I don’t have much experience in GRC, as a process consultant, I would suggest that coming back to OOTB is quick and easy.

• The most preferred and efficient way is to get a new instance and use OOTB.

• If that’s not possible, then list down the differences between OOTB and the custom build.

Start from:

• Form level

• Field level

• Value level

• Flow level

This list will give you a clear picture of the direction you need to take. Make step-by-step changes and move forward, removing customizations as needed. It’s also important to analyze the change-effect relationships—don’t rush through it all at once, take it step by step.

[Robert H]

Hello @thomasanton ,

Here is how we have approached similar exercises in the past (not specifically for Risk Management but several other applications). This is mostly generic, since the specifics would of course depend on the actual level of customization that has been made in your case.

• Ask your ServiceNow account manager for a demo of the OOTB application, to see and understand all the features and all the kinds of data that can be managed with it. Most likely the current version of GRC Risk Management is very different to the one you started out with. These sessions are also useful to get feedback and input from the experts at ServiceNow about your planned exercise. Also install the application on a Personal Developer Instance and explore it thoroughly. The more familiar you are with the application the easier the other steps will be.
• Create an inventory of all the customizations and all configuration, including custom fields, that was added to your instance. You can find a list of affected application files by looking up the "GRC: Risk Management" plugin in the Application Manager and then navigating to Installed Details > Customized Files. You can also find a list of all application files by filtering the sys_metadata table by "Application = GRC: Risk Management" and then checking the Created by and Updated by fields to identify files that were added or modified by your company. Repeat this for any other GRC Risk plugins that you might have installed.
• Decide for each of the above inventory items if they are still needed. Check if the OOTB application nowadays provides features that you had to implement through customization in the past. Also check if it has data fields now that have the same or similar purpose as some of your old custom fields, so that you can map your old data to them if it's still needed. If you identify custom fields that you no longer need then don't delete or deactivate them but just make sure they are removed from any Forms or List Layouts, to preserve this historic data.
• The higher the amount of customization the higher the chance for major disruptions that cannot be avoided. For example, if you have customized any Flows/Workflows that came with the application, or created your own, it is very likely that you will have to cancel them, and reset any open Risks or other records to their initial state (e.g. Draft). You might also want to create a custom field temporarily where you store the string value of the state the Risk was in before you reset it, which may help with quickly moving it to the same or equivalent state again after the OOTB transition.
• The actual steps for reverting back to the OOTB Risk Management application are different for configuration that your company has added, and actual customizations of the baseline application files. To address the former, just deactivate all that added configuration (e.g. Business Rules, Client Scripts, etc.). To address the latter, find the "GRC: Risk Management" and related plugins in the Application Manager and either update it to the latest version, or if it is already up to date click Repair. In both cases you can then navigate to System Diagnostics > Upgrade History and find the upgrade "From = n/a" and "To: sn_risk" that you just performed. Open that record and review the related lists "Skipped changes to review" and "Customizations unchanged". These are the customized application files. For each of them, click "Resolve conflicts" and review the changes that were made to them, and if those changes are no longer required click "Revert to Base System".
• Identify the other processes and applications that Risk Management is integrated with at your company, and assess the impact that reverting Risk Management to OOTB would have on those.
• Allocate around 40% of the project time for all preparatory work, 20% for making the actual technical changes, and 40% for testing. Also consider the non-technical aspects of this project, especially OCM, since this kind of change will likely affect a lot of people and they probably have to unlearn/relearn many things about using Risk Management.

These are the most important things I can think of for now. If you have questions about specific aspects please let me know and maybe I can think of more.

Regards,

Robert