1. IT Change Management in ServiceNow
Adapting our mindset to use ServiceNow

2. Agenda How HITS will be approaching Change Management
How legacy (MCIT and MSIS) change “types” map to ServiceNow
A “cross-walk” detailing legacy/new terminology and functionalities
The different kinds of change templates in ServiceNow
Hands-on walkthrough based on Change Management use-cases
Open Discussion/Q&A

3. HITS Approach to Change Management

4. Change Management: The Basics
A change is an event that is:
approved by management
implemented with a minimised and accepted risk to existing IT infrastructure
results in a new status of one or more configuration items (CIs)
provides increased value to the business (increased revenue, avoided cost, or improved service) from the use of the new or enhanced IT systems.

5. Out of Scope
Global Change
Freezes

6. Three kinds of change:
Normal:
Standard:
Emergency:

7. Normal: Standard: Emergency:
Three kinds of change:
Normal:
What we do every day - updating systems. We need to coordinate efforts and help each other to do our best work. We always check our own work, sometimes we have an independent group check for us.
Standard:
Emergency:

8. Normal: Standard: Emergency:
Three kinds of change:
Normal:
Standardized procedures that are pre-approved, requiring us to build defined standard changes. These aren’t worth taking time to discuss each time - but are worth tracking to keep consistent.
Standard:
Emergency:

9. Normal: Standard: Emergency:
Three kinds of change:
Normal:
Standard:
Changes that are affecting our users requiring immediate fix, but need to be checked without a formal CAB meeting taking place first.
Emergency:

10. Mapping legacy change types

11. Non-Standard (MiChart only)
Mapping Legacy Types
MSIS (Zendesk)
HITS (ServiceNow)
MCIT (Remedy)
Non-Standard
Normal
Non-Standard (MiChart only)
Standard
Standard
Standard
Emergency
Emergency
Emergency
Global and Emergency Global changes will continue to be run out of the RFC form in Remedy until later this fall.

12. Key differences from legacy systems
Change as Tasks
a series of discrete, coordinated tasks,
owned by the team that wants to see a change through to production,
supported by the rest of the organization.
Change Meetings
There is no “Local” CAB → All Changes include peer review
All changes can choose to go to a CAB (Change Advisory Board) meeting for review
Change Types
Non-Standard = Normal
Standard = Created as templates from Normal changes

13. Workflow changes from legacy systems

20. Zendesk: Change
Remedy: TKT/CSR

21. Zendesk: Change
Remedy: TKT/CSR 1 6 3 9 5 2 7 8 4

22. Change Management in ServiceNow

23. Change
Successful Change

24. Service Request Change Task (Order Computer) Task (Deploy to Test)
Task (Test)
Task (Build Computer)
Task (Deploy to Staging)
Task (Load Software)
Task (Deploy to Customer)

25. MiChart Change Promote to POC/Dev Promote to Staging Promote to Test
Testing

26. Affected Configuration Items
Incidents Resulting from Change
Change Request
Impacted Services
Approval Tasks
Implementation task
Incidents Pending Change
Post-implementation task

27. Workflow

28. Create change, with plan, steps, and necessary details to approve.
When scheduled time arrives, execute the work for the change.
Review by team members.
Assess the results of the change and determine if successful.
Review by Change Advisory Board (CAB)
Completed change.
On calendar to be implemented when time arrives.
Change withdrawn/canceled.

29. Normal Change Management process
New
Assess
Authorize
Scheduled
Implement
Review
Close
Requestor submits a new change request.
She fills out as much information as she has today. Example:
Planned start and end dates, description, and impact. When all required information is complete, move to assess phase.
The team in the Assignment group reviews the change.
The change is approved or rejected by one person on the team.
The Foundational Services Change Advisory Board (CAB) reviews and approves the change at their normal weekly meeting.
The change is approved and is waiting for implementation on the on scheduled
date
Start work implementing the change on the scheduled date and time.
Once post- implementation testing is complete, move to review.
The team in the assignment group field reviews the change to determine if it was successful.
Close out the change, indicating whether or not it was successful and any notes.
Change Tasks
Implement - move to PRD
Post-Implementation testing

30. “Local” Change Management process
New
Assess
Authorize
Scheduled
Implement
Review
Close
Requestor submits a new change request.
She fills out as much information as she has today. Example:
Planned start and end dates, description, and impact. When all required information is complete, move to assess phase.
The team in the Assignment group reviews the change.
The change is approved or rejected by one person on the team.
No authorization required
The change is approved and is waiting for implementation on the on scheduled
date
Start work implementing the change on the scheduled date and time.
Once post- implementation testing is complete, move to review.
The team in the assignment group field reviews the change to determine if it was successful.
Close out the change, indicating whether or not it was successful and any notes.
Change Tasks
Implement - move to PRD
Post-Implementation testing

31. Emergency Change Management process (Legacy MSIS)
New
Assess
Authorize
Scheduled
Implement
Review
Close
Requestor submits a new change request.
She fills out as much information as she has today. Example:
Planned start and end dates, description, and impact. When all required information is complete, move to assess phase.
No assessment required
The Emergency CAB approves the change.
The change is approved and is waiting for implementation on the on scheduled
date
Start work implementing the change on the scheduled date and time.
Once post- implementation testing is complete, move to review.
The team in the assignment group field reviews the change to determine if it was successful.
Close out the change, indicating whether or not it was successful and any notes.
Change Tasks
Implement - move to PRD
Post-Implementation testing

32. MiChart Normal Change Management process
New
Assess
Authorize
Scheduled
Implement
Review
Close
Requestor submits a new change request.
She fills out as much information as she has today. Example:
Planned start and end dates, description, and impact. When all required information is complete, move to assess phase.
The team in the Assignment group reviews the change.
The change is approved or rejected by one person on the team.
The MiChart Change Advisory Board (CAB) reviews and approves the change at their normal weekly meeting.
The change is approved and is waiting for implementation on the on scheduled
date
Start work implementing the change on the scheduled date and time.
Once post- implementation testing is complete, move to review.
The team in the assignment group field reviews the change to determine if it was successful.
Close out the change, indicating whether or not it was successful and any notes.
Change Tasks
Migrate from POC to TST
Migrate from TST to STG
Testing - TST
Change Tasks
Implement - move to PRD
Post-Implementation testing

33. MiChart “pre-approved” Change Management process
New
Assess
Authorize
Scheduled
Implement
Review
Close
Requestor submits a new change request.
She fills out as much information as she has today. Example:
Planned start and end dates, description, and impact. When all required information is complete, move to assess phase.
The team in the Assignment group reviews the change.
The change is approved or rejected by one person on the team.
No authorization required
The change is approved and is waiting for implementation on the on scheduled
date
Start work implementing the change on the scheduled date and time.
Once post- implementation testing is complete, move to review.
The team in the assignment group field reviews the change to determine if it was successful.
Close out the change, indicating whether or not it was successful and any notes.
Change Tasks
Migrate from POC to TST
Migrate from TST to STG
Testing - TST
Change Tasks
Implement - move to PRD
Post-Implementation testing

34. MiChart Emergency Change Management process
New
Assess
Authorize
Scheduled
Implement
Review
Close
Requestor submits a new change request.
She fills out as much information as she has today.
She assigns the change request to the “MiChart Managers” Assignment Group
The team in the Assignment group reviews the change.
The change is approved by two MiChart Managers.
No authorization required
The change is approved. Move directly to Implement.
Start work implementing the change.
Once post- implementation testing is complete, move to review.
The team in the assignment group field reviews the change to determine if it was successful.
Close out the change, indicating whether or not it was successful and any notes.
Change Tasks
Migrate from POC to TST
Migrate from TST to STG
Testing - TST
Change Tasks
Implement - move to PRD
Post-Implementation testing

35. Hands-On Demo: Normal Change
Test System:
Login: Lvl2 login with Duo

36. Step 1: Creating a change

37. Creating a Change: Four options
From the Change module
You can create all three types of change from the Change module.
Navigate to Change > Create New.
Select one of the following types of change: Normal, Emergency, or Standard.
From an incident
You can create only normal or emergency changes from an incident.
Open the incident.
Right-click the incident header and select Create Normal Change or Create Emergency Change.
From a problem
(not yet live for HITS)
You can create only normal or emergency changes from a problem.
Open the problem.
Right-click the problem header and select Create Normal Change or Create Emergency Change.
From an existing change record.
You can create a new change from a copy of an existing change record.
Open the change record that you want to copy.
Click Copy Change.

40. Creating a Change: Updating rooms in Schedulon
Please be sure to use Test!
Create New Normal Change
Navigate to Change > Create New.
Select the following type of change: Normal
Select the Category, and CI
Select ‘Applications Software’ in Category
Type in ‘Schedulon’ within the Configuration Item (CI) field.
Choose the Priority, Risk, and Impact
Set the Priority to 4 - Low
Set the Risk to Low
Set the Impact to 2 - Medium
Fill in Assignment Group
Fill in your Assignment Group
Assign it to yourself as the Assigned To
Fill in Description fields
Fill in an abbreviated description to make it easy to find your Change
Fill in a longer description to describe the change result.

42. Creating a Change: Updating rooms in Schedulon
Please be sure to use Test!
Fill in information under Planning tab
Add information describing the Justification for the change in Justification
Add information describing the implementation plan in Implementation Plan
Add information explaining the Risk and Impact from above in Risk and Impact Analysis
Add information on how the change will be backed out if necessary in Backout plan
Add information on how this will be tested once implemented in Test plan
Fill in the Schedule tab
Select “No Outage” as this doesn’t require system downtime
Fill in August 31, 5:00 PM as the Requested By date
Fill in August 30 8:00 AM as the Planned start date
Fill in August 30 10:00 AM as the Planned end date
Leave the CAB Required field ‘unchecked’
Click ‘Update’ and the change will save and close, taking you back to the list of all Open changes

44. Creating a Change: Updating rooms in Schedulon
Please be sure to use Test!
Find the Change, using one of the following options
Sort the list of changes by number (yours will be near the top as it is recent)
Search on the name or number of the change
Navigate to ‘recent items’ and select it from the list near the top
Search for “Schedulon” in the Global search and select it from the active Change items
Check Conflicts
Look at the Conflict Status field and see if any conflicts are indicated
Note that the Conflict Last Run field is from only moments ago
Click on the Conflicts tab and observe that
This is scheduled outside of our sample blackout window (Wednesdays are blackout days)
This is not in our maintenance window (where changes are supposed to be on the weekend)
Related Links
Note that the Affected CI section includes Schedulon because that is the application we chose.
Here we can add more CIs if this will impact other products.
The remaining tabs will be used as we move the change through the workflow

46. Creating a Change: Updating rooms in Schedulon
Please be sure to use Test!
Resolve Conflicts
We want to move off of Wednesdays, so we are going to move the change to a Tuesday
Search for “Schedulon” in the Global search and select it from the active Change items
Update the Planned Start Date to :00:00
Update the Planned End Date to :00:00
Click update
Return to the Change and see that the Blackout window is no longer indicated as a conflict

48. Creating a Change: Updating rooms in Schedulon
Please be sure to use Test!
Adding Change Tasks
Navigate to the Change that is active
Under “Change Tasks”, add any additional steps needed to successfully execute this change
Assign those tasks to the teams and/or assignees needed by either clicking on the task or double-clicking the item directly where the data is needed

50. Step 2: Assessing a change

51. Creating a Change: Updating rooms in Schedulon
Please be sure to use Test!
Moving through the workflow
Click on ‘Show Worfklow’ to see an overview of where we are in the change process for this request
Blue boxes indicate steps that have been completed
Green box is where the request current sits in the workflow
Hovering over the steps in the workflow provides information on the current status, timing, etc.
Request Approval
Click ‘Request Approval’ either at the top of the screen or at the bottom of the schedule window
Reopen the change request
This will move the change request from New to Assess at the top of the screen
Note that the approvers tab is now populated with your team members for them to review and approve. (In the live system, and will also be sent prompting reviewers to act.)
Review and Approve the Change
Navigate to your home screen to view changes in process, or
Navigate to the Service Portal ummedtest.service-now.com/sp/, or
Use the mobile app to view the change.
Mark the change as approved (or add comments as desired)
Look to see how the other reviewers have changed to ‘No Longer Required’ (if the CAB check box was checked, additional reviewers will have been added)

60. Step 3: Authorizing a Change

61. Creating a Change: Updating rooms in Schedulon
Please be sure to use Test!
Change Advisory Board (CAB) Approval
Only appears if “CAB Required” is checked
If the CAB Required box was checked, it now routes to the Change Advisory Board for review.
Navigate to the active Change request
Notice that the approvers now list the CAB members required
Click ‘Show Workflow’ and notice that the green box has moved to CAB approval
The CAB will review this request as part of their standard process within their weekly meetings

62. Creating a Change: Updating rooms in Schedulon
Please be sure to use Test!
CAB Approvers
For members of a Change Advisory Board, the functionality improves significantly within ServiceNow
They are able to manage CAB meetings from within the tool as part of the CAB Workbench, supported by the IT Service Management team
We have two CABs defined: MiChart CAB adn Foundational Services CAB
Review and Approve the Change
Navigate to your home screen to view changes in process, or
Navigate to the Service Portal ummedtest.service-now.com/sp/, or
Use the mobile app to view the change.
Mark the change as approved (or add comments as desired)
Look to see how the other reviewers have changed to ‘No Longer Required’ (if the CAB check box was checked, additional reviewers will have been added)

66. Step 3: Scheduling, Implementing, and Review a Change

67. Creating a Change: Updating rooms in Schedulon
Please be sure to use Test!
When approved, tasks stay in Scheduled while waiting
Scheduled indicates the change will happen, but is not to the planned implementation phase yet.
This allows the system to show others that there are changes scheduled for that product or service or window of time.
When ready to implement, move the Change to the Implement phase
Click Implement at the top to show the organization that you are moving forward (this notifies watchers, etc)
Two tasks will be added automatically - Implement and Post Implementation Testing
Execute the change tasks and close out each accordingly.
Review the Change when Implementation has been completed
The change moves to Review automatically when implementation is completed.
Review and address any necessary incidents or issues, and update the Change.

69. Step 4: Closing out a Change

70. Creating a Change: Updating rooms in Schedulon
Please be sure to use Test!
Provide closure information and Close the Change
Navigate to Closure Information and provide a Close Code and Close Notes as needed.
The Change will move to Closed and will record the resolution within the system.

72. Hands On/Q&A Time