Process Definition

Change Management Process Diagrams

https://www.blueworkslive.com/scr/processes/10000cb3e430e03#bpmn

Actors

Actor	Definition	Functions Performed
Change Requester		Submits a request for a Change
Change Owner Assignment Unit		The assignment unit responsible for overseeing and coordinating the change
Change Owner Manager		The manager of the assignment unit responsible for overseeing and coordinating the change
Change/Task Owners		Persons responsible for carrying out the tasks associated with the change
Configuration Item (CI) Owner		The owner of the Configuration Item being changed
Change Advisory Board (CAB)		Approves significant, major and some minor changes,
Emergency Change Advisory Board (eCAB)		Approves emergency changes, oversees the emergency change process
ITSM Tool		The system used to track Changes

Use Cases/User Stories

Change created by the Change Owner

Change created by someone other than the Change Owner

Change requested by a client who only has ESS access to ServiceNow

Change created from an Incident

Change created from a Problem

Create pre-approved Change

Create normal Change

Create emergency Change

Create an Outage Incident from a Change

Data Dictionary

Name	Functional Use	Field Type	When Required	Change Type Used	Derivation/Rules	Map to current field
Open Date/Time	The date/time the Change is opened	formatted string	auto-generated when Change ticket is opened	All	auto-generated	Same
Close Date/Time	The date/time the Change is closed	formatted striing	auto-generated when Change is closed	All	auto-generated	Same
Short Description	Provide a brief description of the change. Also used in email notifications and queues/views	string	Acceptance	All	user supplied, or sourced from template or pre-approved change
Description	Provide a full description of the change.	multiline text	Acceptance	All	user supplied, or sourced from template or pre-approved change
Requested Implementation Date	The date which the requester would like the change to be implemented.	formatted string	Acceptance		user supplied
Change Source	The source of the Change (e.g. Incident, Problem)	drop down	Acceptance		user supplied
Planned Start Date	Provide the date/time when the implementation of this change will begin. Together with the Planned End Date will show the Change on the Change calendar.	formatted string	Before Change can be moved to Approval Phase	All	user supplied
Planned End Date	Provide the date/time when the implementation of this change will end. Together with the Planned Start Date will show the Change on the Change calendar	formatted string	Before Change can be moved to Approval Phase	All	user supplied
Actual Start Date	Provide the date/time when the implementation of this change actually began.	formatted string	Before change can be closed	All	user supplied
Actual End Date	Provide the date/time when the implementation of this change actually ended.	formatted string	Before change can be closed	All	user supplied
Submission Priority	Provides information on when the change was requested versus when the Change was implemented.	string	Auto-generated	All	formula derived from planned start date and open date; available options are Planned, Latent and Emergency; Emergency is not an option for pre-approved changes
Option for CAB Approval	This option should be used for when a Change is Minor but would still require CAB approval	TBD	Never	Minor	user supplied
Option for Advisory Change	This lets the CAB know about the Change, even though it is a minor Change that does not require CAB approval.	Check Box	Never	All	user supplied
Change Requester	Provide the name of the person who is requesting the Change	user object reference	Acceptance	All	derived from logged-in user but changeable
Change Type	Provide the type of change request	string	Upon assessment	All	Pre Approved, Normal, Emergency
Change Scope	Provides the scope of change request.	string	Upon assessment	All	Minor, Major, Significant. These changes are all change type of 'normal'.
Change Owner	The person responsible for coordinating the Change	user object reference	Upon assessment	All	derived from logged-in user but changeable
Change Owner Assignment Unit	The assignment unit responsible for coordinating the Change	user object reference	Acceptance	All	derived from logged-in user's default assignment unit but changeable
Work Notes	Provides information on Work performed on the Change	multiline text	Never	All	user supplied
Back out Plan	Provides the back out plan for the Change	multiline text	Before Change can be moved to Approval Phase	All	user supplied
Test Plan	Provides the test plan for the Change	multiline text	Before Change can be moved to Approval Phase	All	user supplied
Communication Plan	Provides the communication plan for the Change	multiline text	Before Change can be moved to Approval Phase	All	user supplied
Operational Support Plan	Provides the operational support plan for the Change	multiline text	Before Change can be moved to Approval Phase	All	user supplied
Implementation Plan	Provides the implementation plan for the Change	multiline text	Before Change can be moved to Approval Phase	All	user supplied
Related Records	Used to link the Change to the Problem it's trying to solve Used to link the Change to a Problem is has caused Used to link the Change to an Incident it's trying to solve Used to link the Change to an Incident it has caused	object reference	Never	All	user supplied or derived when a Change is created from an Incident or Problem
Maintenance Window	The maintenance window for the CI. This field is auto-populated from CMDB data for the CI.	object reference	Never	All	auto-populated from the CMDB
External Reference	Provides a place to log a reference to an item in an outside system such as a YNHH change ticket number or a reference to a ticket in another vendor's system.	text	Never	All	user supplied
Phase	Provides the phase or stage in which the Change currently sits	string	Acceptance	All	derived from system workflow. Phase options are draft, acceptance, pre-implementation, approval, implementation, post implementation review and closure
Risk	Provides the risk associated with the change	string	Before Change can be moved to Approval phase	All	derived from CI; this field helps to determine the Change Type
Impact	Provides the impact associated with the change	string	Before Change can be moved to Approval phase	All	derived from CI; this field helps to determine the Change Type
Confidence	Provides the confidence level of the change (needs better definition)	drop down	Before Change can be moved to approval phase	All	user supplied; this field helps to determine the Change Type
Closure Code	Provide information regarding the outcome of the change and whether or not if was successful or unsuccessful. Also provides information regarding the outcome of the change and whether or not if was fully implemented.	drop down	Before Change can be closed	All	user provided; Items in this drop down: Implemented-As Planned Implemented-Not as Planned Implemented-Partially Not Implemented-Backed Out Not Implemented Successful Partially Successful Unsuccessful-Backed Out Unsuccessful-Not Backed Out Cancelled Rejected
Change Tasks	Change tasks are used when work needs to be sequenced or coordinated between assignment units on a Change.	task	TBD	All	TBD
Change Task - Start Date	Provide the date/time when the implementation of this change will begin. Together with the End Date will show the Change on the Change calendar.	formatted string	Before implementation begins (how to enforce in SN?)	All	Before the implementation this is the planned date. After implementation this should be updated to reflect the actual date.
Change Task - End Date	Provide the date/time when the implementation of this change will end. Together with the Start Date will show the Change on the Change calendar.	formatted strinig	Before implementation begins (how to enforce in SN?)	All	Before the implementation this is the planned date. After implementation this should be updated to reflect the actual date.
Change Task - Short Description	The short description of the Change Task	text	When created
Change Task - Description	The description of the Change Task	text	When created
Change Task - Work Notes	Provides information on Work performed on the Change	multiline text	Never	All	user supplied
Change Task - Open data/time	The date/time the Change Task is opened	formatted string	auto-generated when Change Task ticket is opened	All	auto-generated	Same
Change Task - Close data/time	The date/time the Change Task is closed	formatted string	auto-generated when Change Task ticket is closed	All	auto-generated	Same
Change Task - Assignment Unit	The assignment unit to which the Change Task is assigned	user object reference	When opened	All
Change Task - Assignee	The person to which the Change Task is assigned	user object reference	Unsure	All
Change Task - Parent Change	The parent change of the Change Task	object reference	When opened	All
Change Task - Stage	Provides the stage in which the Change Task currently sits	drop down	When opened	All	Build, Test, User Acceptance. This should default to Build.
Change Task - Environment	Provides the environment to which the changes in the Change task are being made.	drop down	When opened	All	Development, Test, Staging, Production
Change Task - Risk	Provides the risk associated with the change task	string		All	derived from CI
Change Task - Impact	Provides the impact associated with the change task	string		All	derived from CI
Change Task - Closure Code	Provide information regarding the outcome of the change task and whether or not if was successful or unsuccessful. Also provides information regarding the outcome of the change task and whether or not if was fully implemented.	drop down	Before Change Task can be closed	All	user provided; will need info here about what to include in the drop down; This is combined with the old implementation code.
Change Task - Task Type	The type of task.	drop down	At creation of task	All	some of these tasks would be system generated that were created by the change workflow. we will also need other options for people creating tasks to accompany changes. Options in the drop down box still need to be determined.

Glossary

Change Process Term	Definition
Change	The addition, modification or removal of anything that could have an effect on IT services. The scope should include changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and other configuration items.
Change Task	One of the logical blocks of work that affect a Configuration Item required to complete a Change. Change tasks are used when there is a need to sequence work or coordinate work between persons or teams.
Pre-Approved Change
Normal Change
Emergency Change

Requirements

Requirement Area	Functional Requirement
Approvals	Need to balance the amount of approvals needed with the ability to move work forward without getting hung up in the tool.
Approvals	Change tasks need to be accepted by the manager of the assignment group or their delegate and then assigned to a person to work on the task. Change tasks should not be assigned directly to a person, they should be first assigned to an assignment group and then the manager or their delegate will assign the change task to the appropriate person. The goal of this is to ensure that when a task is assigned to an assignment group that there is acceptance by the manager (or their delegate) that someone in their group will complete this task at or by the specified date.
Approvals	Minor changes can be approved by the manager or a delegate of the assignment unit manager. Significant and major changes need to be approved by the assignment unit manager and also the CAB.
Scheduling	Changes are not allowed during blackout periods
Scheduling	When submitting a Change the requester needs ability to review that they are not selecting planned start/end dates that are outside of times the CI Owner has designated as approved change times (e.g. they are not selecting a time during a blackout date)
Scheduling	Pre-Approved changes are allowed only during the times when the CI Owner and Business Service Owner allow these pre-approved changes. It can be maintenance windows or other times.
General	When assigning the change for assessment the Change Owner Group should be auto-filled based upon the CI but allowed to be updated if the need arises
Emergency Change	Regardless of the origin of an emergency change, a business justification will be required for eCAB approval and should be obtained from business representation early.
Emergency Change	Emergency changes must all have an after action review of the Incident/Problem that caused the change.
Emergency Change	Both the Business Owner and the eCAB need to be notified of an emergency change and involved and approve emergency change
Emergency Change	Emergency changes are all significant or major changes. If a Change would normally be a minor change it would be considered a significant change if it were an Emergency.
Emergency Change	An emergency change needs to be invoked due to an Incident or Problem. If no Incident or Problem exists an emergency Change should not happen.
Emergency Change	An emergency change needs to be completed as soon as it's determined an Emergency Change is needed.
Post Implementation Review	There needs to be a way to determine if a post implementation review needs to be done on a pre-approved or a minor change. Major and significant changes would always have a post implementation review.
Change Tasks	Change tasks need the ability to be sequenced and have dependencies. The can be sequenced manually or automatically by the system.
Change Tasks	When the system manually sequences change task dependencies it should know to sequence the environments in the order of Development, Testing, Staging, Production.
Change Tasks	All pre-implementation change tasks must be completed before the Change is submitted for approval
Change Tasks	All implementation change tasks must be completely filled out before submitting Change for approval
Pre-Approved Change	When creating a pre-approved change the user should be able to select from the library of pre-approved changes that have been vetted by the CAB.
Pre-Approved Change	Pre-Approved changes should be reviewed once a year to ensure everything in the template is still accurate and that this change is still OK to be pre-approved.
General	We need the ability to create templates for Changes that also include the creation of tasks when the template is applied.
General	Need a text field where we can add an external reference to a ticket outside of ServiceNow. For example a change record that lives in YNHH system or a reference to an item that lives in a vendor system.
General	Change tasks can be added to the change at any time before the Change is submitted for Implementation approval.
General	Need to be able to audit the Change for any data changes and show them by area and the number of changes.
Reporting	Configuration Manager needs to be able to report on any and all changes made to a particular CI. For example if the root password is changed on 500 servers he needs to be able to report that the password was changed on each server.
Reporting	Change process needs to be able work with Configuration Management process to ensure that the system is able to report on unauthorized changes made to CIs.
General	Any change to any field in the ticket (both Change and Change Task) should be logged in the ticket so that changes to the ticket can be viewed by what was changed, who changed it and when it was changed.
General	All changes or activities (including emails and the opening/closure of Change Tasks) to the Change ticket or the Change Task ticket should be logged in the activity log.
General	All fields should have help with information about the field, its purpose and how to select an option. Hover over help suggested.
General	Change: Overlay Maintenance Schedule with Change Request Schedule. Need the ability to overlap maintenance schedules and blackout periods with Change Tickets in the Change Module. This would provide the ability to visualize changes that need to be rescheduled per finals week, commencement, or other major upgrades. Business Need: Ability to view change request and scheduled change against blackout, freeze and maintenance windows through one windows to help make decisions on execution of changes. Use Case #1: We would like to see changes being requested/schedule during an event like the R12 upgrade or commencement. The result may be to push off changes that would potential affect these events. Use Case #2: See change type Pre-approved & Minor change against Significant, and Major changes against events like commencement or mother maintenance event
General	When the change source is a new service or modification to a service a change task should be created for Service Introduction.
Approvals	Need to have a backup or delegate if the CI Owner is not available. This is mostly concerned with the Emergency Change process.
General	Once a Change is submitted for approval the fields should be locked down and unchangeable.
General	When the Change Requester is also the CI Owner the Change should automatically be accepted (since the CI Owner would be the one accepting the change).

Open Questions

Date	Question	Answer
7/25/2013	How the Change process will interact with Deployment Manager (Kintana) and how will the Release and Change processes intersect?
7/29/2013	How will we integrate Business and Provider Services into the Change Process?
9/4/2013	How will the Change process integrate with the other processes? What items will be carried over when creating a Change from an Incident or Problem?
10/9/2013	Should time tracking (like in Incident/Request Task) be part of Change/Change Tasks? Is there value in adding the tracking for this here?
10/9/2013	Is there any value in linking TAA to ServiceNow?	12/17/13: Not at this time as there is a project in progress to replace TAA with Quickbase. - Chloe
11/13/2013	We would like to combine the implementation code and closure codes. How can we do this and what options should be available?
11/15/2013	Is there a reason for rolling back changes? If yes we need use cases and specific conditions on when this can happen.
11/18/2013	Should the 'Change Owner' be changeable at any point during the change? Who should be able to make this change? Queue Managers? Use Case: Staff Member leaves for emergency leave and has changes in various states including Implementation. The queue manager needs to reassign the ticket at any time up until closure to a responsible party.
11/27/2013	Need to come up with a process for creating an outage incident from a Change.
12/18/2013	Should we be able to create Changes from Incidents? Need to follow up with Mark Kovacs about this.
1/17/2014	What happens when a CI is not in the CMDB? How is a Change created for a CI not in there? Idea is that there is a way to add it in unvalidated and have it reviewed for addition to the CMDB. There would need to be a loop back to the Change ticket and update it if necessary.
1/17/2014	Who would sign off on the Operational Support Plan items (like the creation of KB articles, training, communications)?
1/17/2014	Need to figure out a way to let CAB members review the changes up for CAB approval that week and have the ability add comments. This would be helpful if they were not able to attend the meeting.

Decision Log

Date	Decision	Attendees
10/29/2013	We will combine the closure code and implementation code to simplify as they are very much the same.	CB, MW, JS, AD, CT

Change Management Functional Spec - Summer 2013