ServiceNow Process Guide CHANGE

Change Management
Process Guide
Change Management
Process Guide
Table of Contents
1 Introduction .................................................................................................................................. 1
1.1 Overview.................................................................................................................................................. 1
1.2 Process Description .................................................................................................................................. 1
1.3 Process Goal............................................................................................................................................. 1
1.4 Process Objectives ................................................................................................................................... 1
1.5 Relationship with Other Processes ........................................................................................................... 2
1.6 Principles and Basic Concepts .................................................................................................................. 2
1.6.1 Policies ................................................................................................................................................ 2
1.6.2 Methods of Raising an RFC ................................................................................................................. 2
1.6.3 Configuration Management Interface ................................................................................................ 3
1.6.4 Types of Change Requests .................................................................................................................. 3
1.6.5 Change States ..................................................................................................................................... 4
2 Process Roles ................................................................................................................................ 4
2.1 RACI Matrix .............................................................................................................................................. 6
3 Change Management Activity Description ...................................................................................... 8
3.1 Process Overview ..................................................................................................................................... 8
3.1.1 Process Overview Activity Description ................................................................................................ 9
3.2 Standard Change .................................................................................................................................... 10
3.2.1 Process Planning and Design Activity Description ............................................................................ 11
3.3 Normal Change ...................................................................................................................................... 13
3.3.1 Normal Change Procedure ................................................................................................................ 14
3.4 Emergency Change ................................................................................................................................. 20
3.4.1 Emergency Change Procedure .......................................................................................................... 21
4 Process Control ........................................................................................................................... 24
4.1 KPIs ........................................................................................................................................................ 24
4.2 Operational Data ................................................................................................................................... 24
4.3 Reports & Homepage Gauges................................................................................................................. 24
Figures
Figure 1 Process Overview
Figure 2 Standard Change
Figure 3 Normal Change
Figure 4 Emergency Change
© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

ServiceNow and the ServiceNow logo are trademarks of ServiceNow, Inc. All other brand and product names are trademarks or registered trademarks of their respective holders. i
Change Management
Process Guide
Appendices
Appendix A Document Conventions
Appendix B Standard Change Guidelines
Appendix C Risk Assessment
Appendix D Scheduling Assessment
Appendix E Emergency Change Guidelines
Appendix F Expedited Change Guidelines

ServiceNow and the ServiceNow logo are trademarks of ServiceNow, Inc. All other brand and product names are trademarks or registered trademarks of their respective holders. ii
Change Management
Process Guide
1 Introduction
The concepts described in this guide are aligned with ITIL 2011 and may reference capabilities that are
dependent upon other ServiceNow applications. These references will be noted by blue italicized font.
1.1 Overview
A process is defined as a set of linked activities that transform specified inputs into specified outputs,
aimed at accomplishing an agreed-upon objective in a measurable manner. The process definition laid
out in this document further breaks down these activities into actions and the role(s) responsible for
their execution.
This document also describes how ServiceNow supports the change management process with its
abilities to manage the creation, assessment, approval, scheduling, and implementation of changes to
minimize risk to the IT environment.
1.2 Process Description
A change is the addition, modification, or removal of anything that could have an effect on an IT service.
Change management is the process responsible for controlling the life cycle of all changes to minimize
the risk of disruption to IT services.
1.3 Process Goal
The goal of the change management process is to enable beneficial changes to be made with minimum
disruption to business operations, thus ensuring that the best possible levels of service quality and
availability are maintained. This is accomplished through a formal approach that assesses the risk and
business continuity, impact, and resource requirements of the change against its realizable business
benefits.
1.4 Process Objectives
The objectives of change management are to:
 Respond to the customer’s changing business requirements while maximizing value and
reducing incidents, disruption, and rework.
 Respond to the business and IT requests for change that will align the services with the business
needs.
 Ensure the changes are recorded and evaluated, and that authorized changes are prioritized,
planned, tested, implemented, documented, and reviewed in a controlled manner.
 Ensure that all changes to configuration items (CIs) are recorded in the Configuration
Management Database (CMDB).

ServiceNow and the ServiceNow logo are trademarks of ServiceNow, Inc. All other brand and product names are trademarks or registered trademarks of their respective holders. 1
Change Management
Process Guide
1.5 Relationship with Other Processes
Process Relation Description Input Output
A request for change (RFC) can be initiated when a CI change is

X
required to resolve an incident.
Incident  Change management is responsible for keeping the service

Management desk informed of all scheduled changes.
X
 Access to recent change information can be used to determine
the cause of current incidents.
A RFC is initiated when a CI change is required to remove a

X
Problem detected or known error.
Management Problem management is informed of the status and progress of
X
submitted RFCs.
Information from configuration management (CMDB) is used to

X
Configuration evaluate the risk and impact of changes to business services or CIs.
Management Change management ensures that CI information is updated
X
following a change implementation.
1.6 Principles and Basic Concepts
1.6.1 Policies
Policies are formally documented management expectations and intentions that are used to direct
decisions and ensure consistent and appropriate implementation of processes, standards, roles, and
activities. Policies may also dictate specific tool requirements. Examples of common change
management policy topics include:
 Creating a culture of change management across the organization where there is zero tolerance
for unauthorized change.
 Evaluating possible risk and performance impact of all changes on the service capability.
 Defining emergency change criteria and authorization requirements.
 Ensuring that changes create business value and that the benefits are measured and reported.
 Segregating duty controls for security and error mitigation.
 Defining change windows – enforcement and authorization for exceptions.
1.6.2 Methods of Raising an RFC
There are several ways to generate a new change record in ServiceNow:

Change Management
Process Guide
 Create a change manually through the Change application.

 Request a change through the Service Catalog.
 Initiate a change from an incident.
 Initiate a change from a problem.
 Generate a change from a pre-configured inbound email. See inbound email action in the
ServiceNow Wiki for a description of how to utilize this feature.
1.6.3 Configuration Management Interface
The configuration management database (CMDB) supports the change management process by
providing reliable, quick, and easy access to accurate configuration information to:
 Perform impact assessment

 Identify high-risk, high-impact CIs
 Identify related CIs that will be affected by the change
 Populate the change record with relevant CI information
 Capture CIs, configuration baselines, and releases
 Link CIs to past changes
A well-planned integration between the configuration management system (CMS) and change
management is a best practice that enables optimal process efficiency and effectiveness.
1.6.4 Types of Change Requests
Different types of changes require different levels of process rigor and control. The ServiceNow
application provides workflows for three different types of service changes:
 Standard: a low risk change to a service or other CI for which the approach is pre-authorized by
change management and follows an accepted and established procedure or work instruction.
See Appendix B for standard change guidelines and considerations.
 Emergency: a change that must be implemented as soon as possible to eliminate an error that is
negatively impacting the business to a high degree, or could do so in the future. See Appendix E
for emergency change guidelines and considerations.
 Normal: any change that is not a standard or emergency change.
On occasion, there may be a need to implement a change sooner than the normal change approval will
permit. Some organizations choose to identify these as an Expedited change. See Appendix F for details
on this additional change type.

Change Management
Process Guide
1.6.5 Change States
Changes should be tracked throughout their life cycle to support proper handling and reporting. The
state of a change indicates where it is in relation to the life cycle and helps determine what the next step
in the process might be. The typical uses of the workflow state values in the ServiceNow base system
are:
 Draft: default value upon creation.

 Review: planning is complete and the change is under peer review prior to submission for
approval.
 Approval: the change has been submitted for approval.
 Scheduled: the change has been approved and is ready for implementation activity.
 In Progress: change implementation activities are in progress.
 Completed: the change has been implemented.
 Closed: the change record is closed and can no longer be updated.
 Cancelled: the change has been closed because it is no longer required.
2 Process Roles
Each role is assigned to perform specific tasks within the process. Within a specific process, there can be
more than one individual associated with a specific role. Additionally, a single individual can assume
more than one role within the process although typically not at the same time. Depending on the
structure and maturity of a process, all roles described may not exist in every organization.
The following describes the typical roles defined for change management.
Role Description
Process Owner A senior manager with the ability and authority to ensure the process is rolled out and
used by all departments within the IT organization.
Responsible for:
 Defining the overall mission of the process.
 Establishing and communicating the process mission, goals, and objectives to all
stakeholders.
 Resolving any cross-functional (departmental) issues.
 Ensuring consistent execution of the process across the organization.
 Reporting on the effectiveness of the process to senior management.
 Initiating any process improvement initiatives.

Change Management
Process Guide
Role Description
Change Manager Responsible for:
 Managing the day-to-day activities of the process.
 Gathering and reporting on process metrics.
 Tracking compliance to the process.
 Maintaining the change schedule and projected service outage.
 Facilitating/leading Change Advisory Board (CAB) meetings.
 Authorizing Standard change templates/models.
Requester  The person raising the change request. A requestor can be anyone in the
organization who needs a change to be made or they may submit change requests
on behalf of others.
Change Coordinator There may be different coordinators for each category of change.
Responsible for:
 Reviewing RFC(s) to determine approval based on value to the business, potential
risk associated with the implementation (or not) of the change, and the benefits
expected to be realized.
 Performing a risk and impact assessment of submitted RFC and seeking additional
information, if needed.
 Creating any additional tasks that must be performed beyond those identified by
the Requester.
 Coordinating the change build, test, and deployment activities, as appropriate.
 Participating in the change review prior to closure.
 Providing expert input at the CAB meetings, as needed.
Change Advisory The CAB (typically comprised of representatives from all areas of IT, the business, and
Board (CAB) rd
possibly 3 party providers or suppliers) supports the assessment, prioritization,
authorization, and scheduling of changes.
Responsible for:
 Reviewing and approving RFCs.
 Reviewing the change schedule and providing information to help identify
conflicts or resource issues.
 Reviewing projected service outages.
 Reviewing unauthorized and failed changes.
 Reviewing proposed Standard change templates/models.
Implementer(s) This role may also be referred to as release packaging or deployment practitioner.
Responsibilities of this role include the building, testing and physical deployment tasks
associated with approved changes that may be assigned to multiple individuals.

Change Management
Process Guide
2.1 RACI Matrix
Roles and responsibilities are assigned to specific process activities.
Configuration Manager
Configuration Analyst
Change Management
Process Owner
Stakeholders
CI Owner
ID Activities
CHG SC Standard Change
CHG SC.1 Access ESS portal or service catalog A/R
CHG SC.2 Select appropriate Standard change A/R
CHG SC.3 Provide requested information A/R
CHG SC.4 Submit request A/R I
CHG SC.5 Enter new date for change A/R
CHG SC.6 Perform assigned task(s) I A/R
CHG SC.7 Mark task(s) as completed I A/R
CHG SC.8 Document Necessary Correction(s) A/R I
CHG SC.9 Review Comments and Remediate C A/R
CHG NC Normal Change
CHG NC.1 Create new RFC A/R
CHG NC.2 Document change description A/R
CHG NC.3 Associate affected CI(s) A/R
CHG NC.4 Document change, test, and back-out plan A/R C
CHG NC.5 Indicate desired or new change date A/R C
CHG NC.6 Submit the request I A/R
CHG NC.7 Review RFC A/C R C
CHG NC.8 Cancel RFC A/R I I
CHG NC.9 Assess RFC A R I
CHG NC.10 Request Approval A A/R I
CHG NC.11 Authorize or reject minor change A/C R I I
CHG NC.12 Authorize or reject major or significant change A/R C I C I
CHG NC.13 Coordinate change build and test A/C R C I C
CHG NC.14 Schedule deployment A/R R C C C
CHG NC.16 Coordinate deployment C A/R C I C
CHG NC.17 Conduct post-implementation review I A/R C I C
CHG NC.18 Verify and close RFC A/R R I I C
CHG EC Emergency Change
CHG EC.1 Create New RFC A/R
CHG EC.2 Enter planned start/end date and time A/R C
CHG EC.3 Document Minimal Change, Test, and Back out Plan A/R C
CHG EC.4 Request Approval I I A/R

Change Management
Process Guide
Configuration Manager
Configuration Analyst
Change Management
Process Owner
Stakeholders
CI Owner
ID Activities
CHG EC.5 Assess Emergency Change Request A/R R C C
CHG EC.6 Convene ECAB A/R C C I I
CHG EC.7 Authorize or Reject Emergency Change A/R I I C I
CHG EC.8 Coordinate Deployment A/R C I C
CHG EC.9 Conduct Post Implementation Review I A/R C I C
CHG EC.10 Review and Close Emergency Change A/R R I I I
R: Responsible A: Accountable C: Consulted I: Informed

Change Management
Process Guide
3 Change Management Activity Description

3.1 Process Overview

Change Management
Process Guide
Figure 1: Process Overview
3.1.1 Process Overview Activity Description
ID Activity Description
CHG 1.0 Create and Review During this activity, the RFC is created and all necessary information for its assessment and authorization is captured.
RFC Once the information has been captured, the RFC is submitted for review to filter out incomplete, impractical, or
duplicate requests.
CHG 2.0 Assess and At this stage, the RFC categorization is validated and detailed risk and impact analysis is performed when necessary.
Evaluate RFC Emergency changes are also identified and the Emergency change procedure initiated.
CHG 3.0 Authorize and Necessary approvals must be obtained in order for the change to proceed. For changes requiring build and test,
Coordinate Change confirmation that the change has undergone and met any testing requirements may be necessary. Once approved,
the change is scheduled for implementation. The approved implementation tasks are executed and verified.
CHG 4.0 Review and Close Some changes may require a post-implementation review (PIR) to ensure that the change has been implemented
the RFC successfully and that no unacceptable risks have been identified following the implementation. For minor changes,
suitable checks are performed and the change is closed.

Change Management
Process Guide
3.2 Standard Change
Figure 2: Standard Change

Change Management
Process Guide
3.2.1 Process Planning and Design Activity Description
ID Tasks Procedure Primary Role Input Output
CHG SC.1 Access ESS Portal To create a standard change request, Requester Standard change required List of authorized
or Service access the Employee Self Service portal Standard Changes on
Catalog or the Service Catalog and look for the ESS portal or service
desired standard change. catalog
CHG SC.2 Select Select the desired Standard change Requester List of authorized Standard Changes Appropriate
Appropriate from the list of available on ESS portal or service catalog Standard change
Standard Change services/standard changes. form opened
CHG SC.3 Provide When applicable, provide the requested Requester Appropriate Standard change form Requested
Requested information in the appropriate field. opened information provided
Information
CHG SC.4 Submit Request Click the Submit button to initiate the Requester Requested information provided Submitted standard
Standard change. If a specific date has change request
been entered for the execution of the Or
change, the Collision Detector will verify
if the requested date is available and is Identified conflicting
not in conflict with: date for change
implementation
 Another change record against the
same configuration item (CI).
 A defined blackout window, where
no changes should occur to this CI.
 A change that is already scheduled
for a related (parent/child) CI.

Change Management
Process Guide
CHG SC.5 Enter New Date If a conflict has been identified and the Requester Conflicting date for change Standard change
for Change change cannot be completed on the implementation identified request submitted
initial desired date, provide a new date with new valid date
for the change to be executed.
CHG SC.6 Perform Assigned Perform assigned task(s), as described Implementer(s) Assigned predefined task(s) from Executed task(s) or
Task(s) submitted standard change request Corrections
Or
Corrections or adjustments to be
made
CHG SC.7 Mark Task(s) Once the task(s) are completed, change Implementer(s) Executed task(s)  Task(s) marked
Completed the assigned task state to Completed. as completed
 Standard Change
Completion
Notification sent
to Requester
CHG SC.8 Document If the Change has not been completed Requester Standard Change Completion Documented
Necessary properly, document what needs to be Notification sent to Requester Reason(s) for
Correction(s) corrected or adjusted in the request rejection of the
form Change
CHG SC.9 Review Review comments provided by Implementer(s) Documented Reason(s) for rejection Corrections or
Comments and Requester and make necessary of the Change adjustments to be
Remediate correction or adjustments. made

Change Management
Process Guide
3.3 Normal Change

Change Management
Process Guide
Figure 3: Normal Change
3.3.1 Normal Change Procedure
CHG NC.1 Create New From the Change application, click Requester  Incident Opened Change
Request for Create New to open the Change  Problem Request form
Change (RFC) Request form.
 Project
CHG NC.2 Document Provide a summary of the required Requester Opened Change Request form RFC form
Change change in the Short description field and documented with
Description a detailed description of the change change description
including the reason(s) for the change in
the Description field.
CHG NC.3 Associate In the Affected CIs section, indicate Requester RFC form documented with change RFC form
Affected CI(s) which CI(s) will be impacted by the summary and detailed description documented with
change. change description
and associated CI(s)
CHG NC.4 Document Document the Change plan, Test plan, Requester RFC form documented with change RFC form
Change, Test, and Back-out plan. description and associated CI(s) documented with
and Back out change description,
Plan associated CI(s),
Change plan, Test
plan, and Back-out
plan
CHG NC.5 Indicate Desired In the Schedule section, indicate the Requester RFC form documented with change RFC form ready to be
or New Change Planned start date and Planned end description, associated CI(s), Change submitted
Date date of the change. plan, Test plan and Back out plan
If the Conflict Checker has identified a

Change Management
Process Guide

date conflict with:
 Another change record against the
same configuration item (CI).
 A defined blackout window, where
no changes should occur to the
associated CI(s).
 A parent/child related CI for which
a Change is already scheduled.
Provide a new Planned start date and
Planned end date for the change to be
executed.
CHG NC.6 Submit the Click the Submit button to submit the Requester RFC form ready to be submitted Draft RFC submitted
Request change request for review. for review
CHG NC.7 Review RFC Open the submitted RFC and review its Change Draft RFC submitted for review Valid RFC
content to ensure that it is: Coordinator Or
 Complete Invalid RFC
 Practical
 Necessary
 Unique and does not repeat RFCs
that have already been accepted,
rejected or that are still under
consideration
CHG NC.8 Cancel RFC If the RFC does not meet the above Change Invalid RFC Cancelled RFC
requirements, cancel the RFC and Coordinator
inform the requester of the reason(s)
for the rejection.

Change Management
Process Guide
CHG NC.9 Assess RFC  Verify that the calculated risk level Change Valid RFC Valid RFC with
is appropriate for the change and Coordinator Or accurate risk land
that the business impact is well impact documented
documented. See Appendix C for Documented change build and test
information on risk assessment results (CHG NC.13)
techniques.
 Ensure that the Change, Back-out,
and Test plans are documented
properly
Or
Once the Change build and tests are
completed and documented, validate
the initial RFC categorization, risk, and
impact levels, and adjust if necessary
CHG Request The RFC is submitted for Change Valid RFC with accurate risk land RFC submitted for
NC.10 Approval approval/authorization. Coordinator impact documented approval
CHG Authorize or The Change Coordinator approves or Change Medium or Low Risk RFC submitted Authorized or
NC.11 Reject Medium rejects medium or low risk change. Coordinator for approval Rejected Medium or
or Low Risk Low Risk RFC
Change
CHG Prepare CAB Prepare a CAB meeting agenda. A Change High Risk Changes to be Authorized Formal CAB meeting
NC.12 Meeting typical CAB agenda contains: Manager invitation
 RFCs to be assessed by the CAB And
 Outstanding changes CAB meeting agenda
 Failed, backed-out, and identified with list of High Risk
unauthorized changes changes to be
authorized sent to

Change Management
Process Guide

 Change calendar CAB members and
 Emergency changes implemented SMEs
since last CAB meeting
Distribute the CAB meeting agenda to
all CAB members and required SMEs.
SME approvers can be:
 Customers
 User group representatives
 Service owners
 Application developers
 Specialists/technical consultants
 Services and operations staff
 Third-party representatives
CHG Authorize or The CAB recommends approval or Change Formal CAB meeting invitation RFC authorized for
NC.13 Reject High-Risk rejection of high risk change. Manager/CAB And build and test
Change Or
CAB meeting agenda with list of High
Risk changes to be approved sent to RFC authorized for
CAB members and SMEs deployment
Or
RFC Rejected

Change Management
Process Guide
CHG Coordinate Ensure that required tasks for building Change RFC authorized for build and test Documented test
NC.14 Change Build and the change have been assigned to Coordinator results
Test appropriate technical groups.
Validate that the change is thoroughly
tested and that the test results are
documented.
CHG Schedule  Verify that the requested Change RFC authorized for deployment RFC scheduled for
NC.15 Deployment implementation date does not Coordinator/ implementation
conflict with other changes, Change
maintenance windows, or blackout Manager
periods.
 Adjust the schedule if necessary.
 Update the change calendar.
 See Appendix D for information on
techniques to assess potential
schedule conflicts.
CHG Coordinate Ensure the change is deployed as Change Scheduled deployment Change completed
NC.16 Deployment defined in the approved execution plan Coordinator successfully
and that all tasks are updated properly. Or
In the event that the deployment Change completed
cannot be completed successfully, the with issues
back-out plan is executed.
Or
Change completed
unsuccessfully

Change Management
Process Guide
CHG Conduct Post- Conduct a PIR if justified by change Change Change implementation requiring Documented PIR
NC.17 implementation management process policies. Examine Coordinator PIR
Review (PIR) how the change was handled
throughout its entire life cycle, and
whether it produced the desired results.
Document opportunities to improve the
implementation of similar changes in
the future and assign action items
accordingly.
CHG Verify and Close Ensure that all the necessary Change Change completed successfully Closed RFC
NC.18 the RFC implementation information has been Coordinator/ Or
captured. Change
Manager Change completed with issues
Depending on the result of the
implementation, select the appropriate Or
closure code and close the RFC. Change completed unsuccessfully
Note: The RFC can only be closed after
all associated tasks have been closed.

Change Management
Process Guide
3.4 Emergency Change

Change Management
Process Guide
Figure 4: Emergency Change
3.4.1 Emergency Change Procedure
CHG EC.1 Create New  From a Priority 1 or 2 Incident, click Requester Priority 1 Incident Opened Emergency
Emergency “Create Change” do open the Or Change Request form
Change (RFC) Change Request form. containing all
Priority 2 Incident information from
 Review the information transferred
from the Incident record in the originating P1/P2
Description field and ensure it Incident record.
provides a detailed description of
the change.
CHG EC.2 Enter Planned  Enter the Planned Start Date and Requester Opened Change Request form RFC form
Start/End Date Time documented with
and Time  Enter the Planned End Date and change description
Time and Planned
Start/End date and
time
CHG EC.3 Document Provide a minimal description for the Requester RFC form documented with change RFC form
Minimal Change, Change plan, Test plan, and Back-out description and associated CI(s) and documented with
Test, and Back plan. originating P1/P2 Incident record minimal Change plan,
out Plan Test plan, and Back-
out plan
CHG EC.4 Request Click the “Request Approval” button to Requester RFC form documented with Minimal Emergency Change
Approval submit the Emergency Change Request Change plan, Test plan, and Back-out submitted for
to Change Management for approval. plan approval

Change Management
Process Guide
CHG EC.5 Assess  Verify that the calculated risk level Change Emergency Change submitted for Emergency Change
Emergency is appropriate for the change and Manager/ approval ready to be
Change Request that the business impact is well Change Authorized
documented. See Appendix C for Coordinator
information on risk assessment
techniques.
 Ensure that the Change, Back-out,
and Test plans are documented
properly
CHG EC.6 Convene ECAB For a High Risk Emergency Change, Change High Risk Emergency Change ready ECAB session in
convene the ECAB members, to obtain Manager to be authorized progress
proper authorization.
CHG EC.7 Authorize or The ECAB recommends approval or ECAB Emergency Change ready to be Authorized or
Reject rejection of High Risk Emergency Change authorized Rejected Emergency
Emergency Change Manager/ Change
Change Change Manager/Coordinator is Change
responsible to authorize or reject Low Coordinator
or Medium Risk Emergency Change.
CHG EC.8 Cancel If the Emergency Change is rejected, Change Rejected Emergency Change Cancelled RFC
Emergency cancel the RFC and inform the requester Coordinator/
Change of the reason(s) for the rejection. Change
Manager

Change Management
Process Guide
CHG EC.9 Coordinate Ensure the change is deployed as Change Authorized Emergency Change Change completed
Deployment defined in the approved execution plan Coordinator successfully
and that all tasks are updated properly. Or
In the event that the deployment Change completed
cannot be completed successfully, the with issues
back-out plan is executed.
Or
Change completed
unsuccessfully
CHG Conduct Post Conduct a PIR if justified by change Change Change implementation requiring Documented PIR
EC.10 Implementation management process policies. Examine Coordinator PIR
Review how the change was handled
throughout its entire life cycle, and
whether it produced the desired results.
Document opportunities to improve the
implementation of similar changes in
the future and assign action items
accordingly.
CHG Review and Close Ensure that all the necessary Change Change completed successfully Closed Emergency
EC.11 Emergency implementation information has been Coordinator/ Or Change
Change captured. Change
Manager Change completed with issues
Depending on the result of the
implementation, select the appropriate Or
closure code and close the RFC. Change completed unsuccessfully
Note: The RFC can only be closed after
all associated tasks have been closed.

Change Management
Process Guide
4 Process Control
4.1 KPIs
KPIs are best represented as trend lines and tracked over time. They provide information on the
effectiveness of the process and the impact of continuous improvement efforts.
KPI/Metric Purpose
Number/percent of changes completed by Measure of process efficiency. Look for opportunities to
Type. increase percentage of Standard changes and lower
percentage of Emergency changes.
Number/percent of changes completed by Measure of the effectiveness of the change management
state (such as Successful or Unsuccessful). process.
Number/percent of completed changes that
Measure of negative impact to IT service quality.
caused incidents.
4.2 Operational Data
Active changes that require visibility, oversight, and possible management intervention are best tracked
on a dashboard or homepage that is monitored by the Change Manager.
KPI/Metric Purpose
Number/percent of changes completed by Measure of process efficiency. Look for opportunities to
Type. increase percentage of Standard changes and lower
percentage of Emergency changes.
Number/percent of changes completed by Measure of the effectiveness of the change management
state (such as Successful or Unsuccessful). process.
Number/percent of completed changes that
Measure of negative impact to IT service quality.
caused incidents.
4.3 Reports & Homepage Gauges
There are numerous default reports available in ServiceNow that can be used to generate charts, publish
to a URL, or schedule to be run and distributed at regular intervals. Users can also create custom
reports. See Creating Reports in the Wiki for more detail on this capability.
In addition to reports, each user can create a personal homepage and add gauges containing up-to-the-
minute information about the current status of records that exist in ServiceNow tables. See Customizing
Homepages in the Wiki for details.

Change Management
Process Guide
Appendices

Change Management
Process Guide
Appendix A: Document Conventions

Symbol Description
Process start or end point: represents the starting and ending point of the
process.
Process activity or task: presents an activity or task that needs to be accomplished

to produce a specific outcome.
Predefined external process or organization: indicates a contribution from an

external process or organization.
Decision: indicates that a question needs to be answered in order to identify the

following activity or task in the process. The answers are indicated on the different
connectors attached to the decision box. Every answer is linked to an associated
activity or task.
System action or function: indicates that an action is being performed in the

system as an output of the previous activity and an input to the next.
Off-page reference: indicates a reference to another diagram within the same

process. The number of the referenced diagram is indicated in the shape.
On-page reference: indicates a link to another activity within the same diagram.
Association: indicates an association or a relation between the connected,

processes, tasks, or activities. May be represented by a dotted or dashed line.
Sequence flow: shows the order in which the activities are performed.
Represented by a solid line and arrowhead.

ServiceNow and the ServiceNow logo are trademarks of ServiceNow, Inc. All other brand and product names are trademarks or registered trademarks of their respective holders.
Change Management
Process Guide
Appendix B: Standard Change Guidelines

Standard Changes for Process Efficiency
A Standard change type is one for which approval has been granted in advance (typically by the Change
Manager), and is usually low risk, routinely performed, and has been implemented without incident in
the past; that is, has a good track record. Standard changes follow a fast-path through the process and
may or may not require scheduling. A change process with unnecessary levels of administration and
oversight may be viewed as overly bureaucratic and therefore subject to resistance. Therefore, Standard
changes should be identified early when building the change management process to promote efficiency
and buy-in.
Standard Change Models
Standard changes are often managed and controlled through the use of change models. A change model
is a pre-defined sequence of steps that must be taken to execute a change in an agreed and accepted
manner. ServiceNow provides the ability to create change models with template functionality. These
templates are constructed so that much of the information about the change is already pre-filled. Values
for items such as the planned start and end date and time, requester, and possibly the affected CIs need
to be provided. See Creating a Template in the ServiceNow Wiki for more information on how to build
templates for standard changes.
Initiating a Standard Change from the Service Catalog
Standard changes are frequently used to fulfill service requests initiated from the service catalog. In
these cases, the service catalog can be used to request changes through a record producer. Record
producers appear in the service catalog like catalog items, but when submitted, they create a change
record with the information provided either by the user or by a template. See Record Producer in the
ServiceNow Wiki for more information on how to use this feature to generate a standard change from a
service request.

Change Management
Process Guide
Appendix C: Risk Assessment

It is a best practice to use a risk-based assessment when evaluating a change. This approach helps
identify factors that may disrupt the business or impede the delivery of services. Different approaches
can be taken to assess and manage risks and each organization must determine the approach it will use.
The following list details the various approaches that are supported by ServiceNow. The approaches are
listed in order of complexity, starting with the most simple:
1. Manually select the risk value from a pre-defined list (for example, Low, Moderate, High, Very
High).
2. Use a simple matrix that determines risk based on impact and probability, where:
 Impact is the effect that a negative outcome would have on business.
 Probability is the likelihood that a negative outcome will occur.
Risk is generated from impact and probability according to the following table.
Probability High Probability Medium Probability Low
Impact High Risk 1 Risk 2 Risk 3
Impact Medium Risk 2 Risk 3 Risk 4
Impact Low Risk 3 Risk 4 Risk 5
3. The ServiceNow Change Risk Assessment plugin provides a flexible way to capture information
from the end user to determine risk. Libraries of questions can be used to derive the risk of a
change based on criteria contained within the change record. For example, a different set of
questions could be set for a hardware change versus a software change. The assessment uses a
weighted score approach for each question and the overall score for an assessment is evaluated
against thresholds to determine the risk of the change. See Change Risk Assessment in the
ServiceNow Wiki for information on how to use this plugin.
4. In addition to manually evaluating risk, it is possible to automatically establish the risk of the
change based on the CI that is identified in the change record. The Change Risk Calculator plugin
enables dynamic calculations of the risk and impact of a change and bundles some best practice
risk calculations that use CI attributes and time measures. See Best Practice - Change Risk
Calculator in the ServiceNow Wiki for information on how to use this plugin.

Change Management
Process Guide
Appendix D: Scheduling Assessment

The Change Management Collision Detector plugin provides the ability to detect whether planned
changes conflict with other changes or have other scheduling issues. When the Collision Detector is run,
any issues that are detected are added to the Conflicts related list at the bottom of the Change Request
form with an explanation of the issues detected. See Collision Detector in the ServiceNow Wiki for more
information on how to use the Collision Detector plugin to identify scheduling conflicts for a change.
Activating the Change Management Collision Detector plugin automatically enables the Maintenance
Schedules plugin if it is not already active. Depending upon the conflict properties that are selected, this
enables the Collision Detector to identify:
 Conflicts with the maintenance schedule of the selected CI in the change record.
 Conflicts with the maintenance schedules of any child or parent CIs or any affected CIs that may
be listed in the change record.
 Conflicts with any blackout schedules (times during which changes cannot be scheduled) that
have been created.

Change Management
Process Guide
Appendix E: Emergency Change Guidelines

Emergency Change Description
The ‘emergency’ change procedure is reserved for changes intended to repair an error in an IT service
that is negatively impacting the business to a high degree, whereas changes that are intended to
introduce immediately required business improvements are handled as ‘normal’ changes with the
highest urgency. The number of emergency changes proposed should be kept to an absolute minimum
because they are generally more disruptive and prone to failure. However, when an emergency change
is necessary, measures should be taken to ensure the change is designed carefully and properly tested
prior to its implementation.
Emergency Change Authorization
There might not be sufficient time to convene all the CAB members when an emergency change arises.
In this case, authorization is provided by the emergency CAB (ECAB). Membership of the ECAB may be
decided at the time a meeting is called and depends on the nature of the emergency change. While not
all emergency changes will require the involvement of the Change Manager or the ECAB, it is essential
that the Change Management process policy clearly defines the required levels of authorization and
delegated authority to ensure appropriate decisions are made in any conceivable circumstance.
Late or Retroactive Change
It may not be possible to update all Change Management records at the time that urgent actions are
being completed. However, it is essential that temporary records are made during such periods, and
that all records are completed retroactively, at the earliest possible opportunity. An agreed time for
completion of these updates should be documented in the Change Management process policy.
Essentially, the emergency change procedure will follow the normal change procedure except that:
 Approval will be given by the ECAB rather than waiting for a CAB meeting
 Testing may be reduced, or in extreme cases forgone completely, if considered a necessary risk
to deliver the change immediately
 Documentation, i.e. updating the change record and configuration data, may be deferred,
typically until normal working hours.

Change Management
Process Guide
Appendix F: Expedited Change Guidelines

While ITIL describes three different types of service change (Standard, Emergency and Normal), many
organizations manage a fourth type of change, often referred to as ‘Expedited’. An expedited change is
basically a normal change that must be implemented sooner than originally planned and therefore must
bypass the normal approval process due to lack of lead-time. These types of changes can be easily
identified because the ‘planned start date’ will be earlier than the lead-time required for the normal
change approval process (including CAB review). Expedited changes are usually the result of an
unexpected shift in business need, poor planning, or both. In any event, an expedited change will
require a separate approval process to be defined. Expedited changes should be monitored and
reviewed by the Change Manager to identify opportunities for process improvement or additional staff
Change Management process awareness and education.


ServiceNow Process Guide CHANGE

Uploaded by

Copyright:

Available Formats

ServiceNow Process Guide CHANGE

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ServiceNow Process Guide CHANGE

Uploaded by

Copyright:

Available Formats

Change Management

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

1.2 Process Description

1.3 Process Goal

1.4 Process Objectives

The objectives of change management are to:

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

1.5 Relationship with Other Processes

Process Relation Description Input Output

A request for change (RFC) can be initiated when a CI change is

Incident  Change management is responsible for keeping the service

A RFC is initiated when a CI change is required to remove a

Information from configuration management (CMDB) is used to

1.6 Principles and Basic Concepts

1.6.2 Methods of Raising an RFC

There are several ways to generate a new change record in ServiceNow:

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

 Create a change manually through the Change application.

1.6.3 Configuration Management Interface

 Perform impact assessment

1.6.4 Types of Change Requests

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

1.6.5 Change States

 Draft: default value upon creation.

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

2.1 RACI Matrix

Roles and responsibilities are assigned to specific process activities.

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

3 Change Management Activity Description

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

Figure 1: Process Overview

3.1.1 Process Overview Activity Description

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

3.2 Standard Change

Figure 2: Standard Change

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

3.2.1 Process Planning and Design Activity Description

ID Tasks Procedure Primary Role Input Output

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

ID Tasks Procedure Primary Role Input Output

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

3.3 Normal Change

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

Figure 3: Normal Change

3.3.1 Normal Change Procedure

ID Tasks Procedure Primary Role Input Output

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

ID Tasks Procedure Primary Role Input Output

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

ID Tasks Procedure Primary Role Input Output

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

ID Tasks Procedure Primary Role Input Output

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

ID Tasks Procedure Primary Role Input Output

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

ID Tasks Procedure Primary Role Input Output

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.