Solutions

  • Products
  • Use Cases
  • Industries
  • REPORT
  • Patching paradox
  • Patch work demands attention to protect data as hackers outpace security teams.
  • REPORT
  • Healthcare vulnerability
  • Patch work demands attention to protect data as hackers outpace security teams.

Platform

  • STUDY
  • Forrester: Improve agility
  • Simplify and consolidate your platform to put more focus on revenue growth.

Customers

  • SUCCESS CENTER
  • Your Strategic Resource
  • Discover best practices for every phase of your ServiceNow journey

Explore

  • WHY SERVICENOW
  • Thanks to you.
  • You're why we're #1 on the Forbes World's Most Innovative Companies list.

Automate change management

 

  • Begin your change management automation strategy with clear definitions of business rules for change risk assessment, scheduling, and approvals and oversight.
  • Gain a clear understanding of risk, backed by historical data, so you can expedite more standard, low‑risk changes with fewer manual steps. 

With change management automation, your organization can both speed up the deployment of changes and reduce the risks associated with change. Focus your automation on the specific change management subprocesses that are designed to mitigate risk but that are still largely dependent on manual work—these might include change risk assessment, change scheduling, and change approvals and oversight. 

Change risk assessment

When you automate your change risk assessments, you improve the efficiency of your change management process by expediting change request categorization. This way, you can expedite more standard, lower‑risk changes. 

Using the Now Platform, you have two methods for automating risk assessment: the Change Risk Calculator and Change Management Risk Assessment.

Change Risk Calculator plugin

The Change Risk Calculator is activated by default and uses predefined properties and values to calculate a risk value. The system administrator specifies how and when to apply risk and impact rules to change requests. System admins can do this using a builder that sets these conditions (and the order they’re evaluated by), through developing more advanced conditions based on business rules, or through a script.

You can also set this common advanced condition based on business rules: Determine the impact to business services from one or more CIs. Set a rule to identify if the CI represents a business service, and if the business criticality associated with that service is 1 – most critical or 2 – somewhat critical. If the condition matches, the rule will set the risk for the change request to High and the impact to 1 – high.

Another common scenario that requires scripting is determining the business services that will be impacted as a result of a change to one or more CIs. The calculator plugin provides a sample rule that grabs the CI entered on a change request and locates all associated parent and child business services. These services are then evaluated to identify any critical services.

Risk Assessment

With Change Management Risk Assessment, you have the option to allow end users to answer risk assessment questions associated with a change request so others can use the information to calculate the risk. 

This means your organization needs to define risk assessment questions, thresholds, and conditions to support the calculation. Keep your conditions simple and mutually exclusive so they’re easy to understand and maintain. 

It also means your organization needs to determine weights that reflect the relative importance of assessment question categories, as well as weights for the questions in the assessment categories. You can use historical data from past changes to inform this weighting—the key is to identify the factors that mattered most in the changes that resulted in service interruptions and/or that had to be backed out.

Use the Change Risk Calculator and Risk Assessment together, or just use one. If you use them together, always select the highest risk value from both methods. 

Regardless of the method you choose, for effective automation, you need a clear definition of business criticality, whether you use Service Mapping, as outlined in Stage 1, or use the rules and conditions built into Risk Assessment. 

To get that clear definition of business criticality, your organization must identify the relative criticality of services, based on how essential they are to business operations. And don’t forget—if you don’t have a well‑defined business service taxonomy, you can use your existing disaster recovery and business continuity planning frameworks to understand relative criticality across systems, as defined by recovery tiers. 

Next, the change management process owner and change advisory board (CAB) should review the risk conditions, their threshold values, and the order they’re evaluated by. 

Automation effectively “cements” a set of business rules for risk assessment so the assessments can be completed quickly and consistently. This means your business rules need to be reviewed and agreed upon upfront—potentially by your CAB—and regularly revisited as services change or as your organization’s risk management posture changes.

Checklist for automating change risk assessment

Change scheduling

Change scheduling automation should provide the ability to detect and assess whether a planned change conflicts with other changes or blackout periods, and if the proposed change timing meets with predefined maintenance windows. This requires administrators to use the Blackout Schedule form to specify times during which change requests should not be scheduled, and the Maintenance Schedule to specify times during which change requests should be scheduled.

Conflict detection supports effective automation of scheduling by identifying when changes are scheduled at the same time or impact the same CIs. You can run conflict detection manually based on the proposed start/end dates of the change request, the CI subject to change, and (in advanced mode) related CIs. 

Automated conflict detection can then run at specific intervals or when a change request is updated. Prior to running conflict detection, however, your organization should take into account:

  • CMDB list size and relationship complexities  Conflict detection will take longer to complete in organizations with a large CMDB. Don’t let this inhibit you from automating conflict detection—just remember to keep the CMDB manageable.
  • Inactive changes are not evaluated – Automated conflict detection will not evaluate inactive changes when identifying conflicts, such as those for cancelled or closed change requests. This means that change management process owners should put the appropriate procedures and training in place to ensure that cancellations and closures are recorded in a timely fashion on the Now Platform.
  • Advanced mode conflict checking switched off by default – After an upgrade, advanced mode conflict checking, which identifies conflicts with CIs that are related to or affected by the CI being changed, is switched off. Use risk assessment results to identify whether you should use advanced mode—you’ll likely want to know if changes carrying a higher degree of risk have the potential for change collision based on related items, not just the CIs being changed.

Changes at risk of collision are subsequently flagged for approvers. Organizations should use the existing calendar interface in the Change Management application to show when changes are planned and where potential conflict exists with either blackout or maintenance schedules. 

Checklist for automating change scheduling

Change approvals and oversight

The Now Platform supports the three types of service changes (or “state models”) described by ITIL. You can add new types, but they may modify default workflows. (Consequently, after adding one, review the default workflows for any changes to the state model). Table 1 outlines the tasks required to implement automation for each state model.

TYPE OF CHANGE

DEFINITION

AUTOMATION TASKS

Normal

Any service change that is not a standard or emergency change

Define review and approval rules – Normal changes are routed first for peer review and technical approval. They’re then routed to the change management process owner and CAB for scheduling and final authorization. To do this, you must designate review and approval authorities.

Standard

A pre-authorized change that is low risk, relatively common, and follows a specified procedure or work instruction. Once approved, standard changes can bypass CAB approval.

Define a catalog of pre-authorized change templates – These templates make accessing and requesting a standard change more efficient. They include rebooting a Windows server, adding a network switch to a data center cabinet, standard implementation, blackouts, and test plans for the change, so new proposals only need to include the CI(s), assignment group, and schedule. Base your templates on a history of similar successful changes. Note that you can track the success of pre-authorized templates—this way, you can modify or retire them if they don’t lead to successful changes.

Emergency

A change that must be implemented as soon as possible, for example, to resolve a major incident or implement a security patch

Define approval rules, which may vary from normal approvals – Emergency changes progress directly from submission to the Authorize state for approval from the relevant CAB approval authority. Some organizations define an emergency CAB (e-CAB), with specific authorities for approving emergency changes.

 

Table 1: ServiceNow state models for change management

A new change request progresses through states once you submit it. Table 2 shows these change states. In the Assess state, ServiceNow routes normal changes to peer reviewers and technical approvers, so you need to identify reviewers and approvers (ideally in advance) for efficient automation.

CHANGE STATE

DESCRIPTION

New

Change request is not yet submitted for review and authorization. A change requester can save a change request as many times as necessary while building out the details of the change prior to the submission.

Assess

Peer review and technical review of the change details are performed during this state. This is not required for Standard or Emergency changes.

Authorize

Change management and the CAB schedule the change and provide final authorization to proceed. This is not required for Standard changes.

Scheduled

The change is fully scheduled and authorized and is waiting for the planned start date. An email notification is sent to the user who scheduled the change.

Implement

The planned start date has approached and the actual work to implement the change is being conducted. An email notification is sent to the user who requested the change.

Review

The work has been completed. The change requester determines whether the change was successful. A post-implementation review can be conducted during this state. An email notification is sent to the user who requested the change.

Closed

All review work is complete. The change is closed with no further action required.

Canceled

A change can be canceled at any point when it is no longer required. However, a change cannot be canceled from a Closed state. An email notification is sent to the user who requested the change.

Table 2: ServiceNow change states

The ServiceNow CAB Workbench plugin supports streamlined scheduling automation and CAB approvals. To put the plugin to use, the change management process owner must ensure that the organization has:

  • A clearly defined CAB manager 
  • A list of CAB members (including those who can substitute for the CAB manager) for normal and emergency CAB meetings
  • A schedule for CAB meeting dates 
  • Clear rules on the types of change requests that are to be included in the CAB agenda

Once established, your CAB members can view an overall meeting calendar and individual agenda items (aka, change requests) alongside a change calendar that includes the blackout schedule and maintenance schedule. 

CAB meeting chairs can also align individual agenda items to specific time slots so stakeholders only need to attend a CAB meeting based on automated notification of when discussion starts for relevant agenda items.

The value of automating and overseeing your change approvals is largely driven by the extent that change management process owners can shift overall change volumes from normal to standard changes. Change management process owners should provide incentives and KPIs for teams to build pre‑authorized change templates that users can access through a change catalog. Teams should target CIs with a consistent, successful, and frequent record of change that’s based on historical data and/or interviews with subject matter experts. Ideally, standard changes should constitute 70–90% of total change volumes. 

 

Expert Tip

EXPERT TIP

If your organization wants to implement DevOps and/or continuous delivery, focus your effort upfront on building a change catalog of pre‑authorized templates for the CIs anticipated to change most frequently.

Explore additional phases

Plan

You want to be sure everything is in place for a smooth, successful deployment.

Deploy

You want to be sure you’re following best practices during implementation.

Optimize

You’re up and running and want to get the most from your investment.

Extend

You’re ready to extend ServiceNow into other areas of your enterprise.

Thank You

Thank you for submitting your request. A ServiceNow representative will be in contact within 48 hours.

form close button

Contact Us

I would like to hear about upcoming events, products and services from ServiceNow. I understand I can unsubscribe any time.

  • By submitting this form, I confirm that I have read and agree to the Privacy Statement.