Please use for the latest documentation.

This site is for reference purposes only and may not be accurate for the latest ServiceNow version

ITIL Change Management

From Wiki Archive
Jump to: navigation, search
Note: The ServiceNow Wiki is no longer being updated. Visit for the latest product documentation.


Change Management helps organizations understand and work to minimize risks of changes to the IT environment. It is essentially a process for managing the people-side of change. ServiceNow helps implement your Change Management process by providing on-demand capabilities for creating, assessing, approving and implementing changes to your environment.

Within the platform, changes are handled using the task record system. Each change is generated through a variety of means as a task record, populated with the pertinent information in individual fields. These tasks can be assigned to appropriate change management team members, who will deal with the task as appropriate. Once the change has been properly implemented, it is closed.

Change Management Process

Raising and Recording Changes

A new change record can be generated in a number of ways:

  • An IT team member (role: itil) can generate a change by hand through Change > Create New or clicking New from the change record list.
  • An IT team member (role: itil) can request a change through the Service Catalog.
  • A change can be requested from an incident.
  • A change can be requested from a problem.
  • If a user attempts to create a generic task, the task interceptor will first ask them to specify what sort of task they would like to create. In this way, tasks are always assigned a handling process.
  • If an appropriate inbound email action is configured, it can be generated from an email.

If an assignment rule applies, the change will be assigned to the appropriate user or group. Otherwise, it can be assigned by hand.

Email Notifications will keep involved parties informed about updates to the change request.

Assessing and Evaluating Changes

Once a change request is in place, the change management team must populate the change request with as much information as possible in order to fully assess the requested change.

Information that can be collected out-of-box:

  • Priority
  • Category
  • Type - Selects a type of change, which triggers an appropriate workflow. Out-of-box, these choices are:
    • Routine - A low-impact, commonly performed change.
    • Comprehensive - A higher impact change with a more complex procedure.
    • Emergency - A high impact change, created in response to an urgent situation.
  • Risk - In addition to manually evaluating the risk involved in a change, it is possible to install the Best Practice - Change Risk Calculator to assist in this aspect of the process.
  • Schedule - Includes a requested by date, a planned start and end date, and work start and end dates. This can be integrated with Outlook so that the change schedule will appear in Outlook's calendar. Note that changes made to the schedule in Outlook will not change the change record.
  • Change/Backout/Test Plans
  • Change Tasks - Can either be generated manually or created from a workflow. If Change Management Workflows is installed, the ITIL best practice workflow appropriate to the specified type (see above) will be used.
  • Approvers - Can either be generated manually, using an approval engine, or generated from a workflow.
  • Problems - If the change was generated from a problem, this related list will be automatically populated. Otherwise, this can be populated by hand.
  • Affected CIs - a list of configuration items (from the CMDB) that will be affected by the change.
  • Impacted Services - a list of business services (from the CMDB) that will be affected by the change.

Planning Changes

Changes can be planned directly in the change record, but for complex, multi-step changes, Project Management allows specificity of planning. Projects in the Project plugin can organize many layers of tasks, and present the tasks as a Gantt Chart timeline.

Authorizing Changes

Approvals for changes can be specified in one of several ways.

  • Specified by hand, using the Approvers related list
  • Generated using an Approval Rule
  • Generated using a workflow.

Using automated approvals, emails will be sent out informing the appropriate user that they need to approve the change. They can either update the Approval field on the form, or can simply respond to the email if the appropriate inbound email action is configured.

Closing Changes

Once the change has come to an end, and the change has been tested and confirmed, the change can be closed by changing the state. If the change was generated from an incident or problem, a business rule can be configured to automatically close them upon closing the change.

Continual Service Improvements to Change Management

The change management process can be improved by the service desk, using information gathered within the platform. Much of the data is already stored within the incident record. More information can be gathered by enabling auditing, which allows for an accurate review of the history of the problem. With Metric Definition Support, it is possible to define the Key Performance Indicators to monitor within the system. With these metrics, and the information within the database, it is possible to generate reports, which can then be added to homepages or automatically generated and distributed. With Database Views it is possible to join tables for reporting purposes.

Using this information, it is possible to refine automatic rules such as the assignment rules, workflow, approval engines, or scheduling to better suit the change management team's unique environment.