Implementation of the Change Management Process in ServiceNow
description
Transcript of Implementation of the Change Management Process in ServiceNow
Change Management, IT Meeting 2
Implementation of the Change Management Process in ServiceNow
Change Management Demo for IT 11/06/2013
11/06/2013
Change Management, IT Meeting 3
OutlookThe Change Management Process establishes standard methods &
procedures for efficient/prompt handling of changes controlling infrastructures
• Demo topics• 1st Block
• Presentation of the 4 changes types implemented in the system• Access to the Change Management application in ServiceNow• Involved actors
• 2nd Block• Fulfillment of each change type
• Workflow description• Tickets access and control
11/06/2013
Change Management, IT Meeting 4
Documentation• Change Management User Guide:
https://services.web.cern.ch/wiki/training-material
11/06/2013
Change Management, IT Meeting 5
• 1st Block• 4 changes types implemented in the system• Access to the Change Management application in ServiceNow• Involved actors
11/06/2013
6
4 types of changes
11/06/2013 Change Management, IT Meeting
Wor
kflo
w
1. Significant: Full workflow2. Minor: Reduced workflow3. Urgent: Reduced workflow4. Standard: Reduced workflow
based on templates
Getting Started: Navigation Panel1 Module accessible from the tool for any ITIL
person (for any supporter)
Change modules including:• Access to a new change • Changes assigned to me (changes for which I
am the coordinator)• Changes assigned to my support group(s)• List of all active changes recorded in the
system
Task actions including (to see in next slides):• List of tasks assigned to me• List of tasks assigned to my support group(s)
1
2
3
2
3
7Change Management, IT Meeting 11/06/2013
Getting Started: Change Workflow
8
1. New: Automatic status at change creation time: Fulfillment of the change form2. Admission: After the submission, the change request is sent to the FE manager for its
study (Significant Change). 3. Evaluation: Performed by the FE manager when the change request has been accepted.
In this case the declaration of a change coordinator is mandatory (Significant Change). 4. Approval: The change request control is on the coordinator’ hands. If needed, further
approvals can be requested at this step• For Significant changes the coordinator approval is always requested in default• For Minor changes the FE managers approval is requested• For Urgent changes the coordinator approval is requested
5. Plan&Build: Development of the change plan. (Significant Change)6. Test: Testing phase of the applied change (Significant Change)7. Deployment: Deployment of the change 8. Review: Review of the change (and closing decision)9. Closed: Final (automatic) state
Change Management, IT Meeting 811/06/2013
Completion of these steps will depend on the change type
Change Management, IT Meeting 9
Getting started: The actors• The following persons will have a role in this process:
• (M) Submitter Any supporter (ITIL role)• (M) FE Manager group Responsible of the change admission• (M) Coordinator Manager of the whole change defined by the FE
manager• Approver(s) Any person declared by the coordinator for specific
approvals• Task responsible(s) Any person declared by the coordinator to
execute specific jobs (tasks)
(M) MANDATORY
11/06/2013
Change Management, IT Meeting 10
• 2nd Block• Fulfillment of each change type
• Workflow description• Tickets access and control
11/06/2013
Change Management, IT Meeting 11
Change type = Significant• Characteristics of a significant change
• Default change type• It satisfies the whole workflow
• Remarks:• Any supporter can submit a change “proposal” for any FE in the catalogue
• This is true for significant, minor and urgent changes• Approval or rejection responsibility will depend on different bodies depending on the change type
• The control of the change requested is transferred to the FE managers in a significant change once the form is submitted
• Life demo Creating a new significant change• Workflow steps completed in the demo: “New” “Admission” Evaluation
• Involved actors: Submitter, FE manager, Coordinator, (task executor if any)
11/06/2013
Admission Phase: Change submittedThe change is now FE manager’ responsibility
12
2
11. Admission states
• Requested: Default status• Accepted: Change is accepted by the FE manager• Not accepted: Change is rejected. Final state
2. If the change is accepted, then the declaration of a coordinator becomes mandatory
• If needed, the FE manager can change the assigned FE. Once the ticket is saved with the new FE, the control passes to the new FE managers group
• Once the change is approved by the FE manager, the control of the ticket passes to the coordinator
Procedures described at each step
3
3
Evaluation phase: Declaring tasks and approversThe change is now coordinator’ responsibility
13
12
4
1. Coordinator’ name can be changed2. “Assigned to” field contains the current coordinator3. The coordinator can declare tasks assigned to other persons4. Coordinator is allowed to declare further approvers that will
have to accept or reject the current change5. Once the approvers have been defined (a not mandatory
action), the coordinator can request such approvals clicking on: “Go to approval”
5
3
Declaring Change TasksReminder: Coordinator’ responsibility
• From now on (Evaluation phase) tasks can be requested by the change coordinator• Not mandatory• Tasks Assigned to other persons (not necessary ITIL members)• This action can assist the coordinator while completing the evaluation phase
based on the results of these tasks• Fulfillment of these tasks does not prevent the continuation of the change
workflow if decided by the coordinator
11/06/2013 Change Management, IT Meeting 14
Completing the Change Task
15
12
3
4
51. Declaration of the assignment group handling the task
(editable)2. Person who will complete the task (editable)3. Short description of the task (editable)4. Task description5. Internal work notes visible for the support group members
only
Task person responsibility
Acknowledging/working on the task
16
1
2
3
41. Access to the list of tasks assigned to the log-in person 2. List of all tasks assigned to me and status (columns can be
personalized)3. Communication field with the coordinator4. Task states (changed on a manual base)
• Open: Initial state• Work in Progress: Task acknowledge (starting the work)• Closed complete: Available only when the previous state (work
in progress) has been selected and saved
Reminder: Task person responsibility
Approvals handling
• Coordinator might require further approvals (technical, financial, functional approvals) before proceeding with the change
• Approvals can be requested by the coordinator during the evaluation phase
Approval mechanism • A single rejection closes the change (final state)• All approvers need to agree with the change before the coordinator can proceed with
the change• The change is blocked until all approvers take a decision
• Coordinator is added automatically to the list of approvers• Once the list of approvers is completed, the coordinator needs to require the
approvals clicking on the action: “Go to Approval”
Reminder: Coordinator’ responsibility
11/06/2013 17
Change Management, IT Meeting 18
• Life demo Declaring approvers• Workflow steps completed in the demo: “Approval” • Involved actors: Coordinator and approvers
11/06/2013
Types of Approvals
• The coordinator can declare different types of approvals: financial, confidentiality, functional (default), technical
19
1
2
31. List of all approvers available for the coordinator from the
change form2. Clicking on the approval state, the coordinator will be directed
to the approval form. The type of approval can be edited. The available values are: “Financial”, “Confidentiality”, “Functional (default)”, “Technical”
3. Comments can be added and will be received by the approver
Coordinator’ responsibility
Approver View: Finding the approvals
1. List of approvals reachable from the navigation menu
1
2
2. Approval details reachable while clicking on the state column• The list of approval can be personalized as any other
list available in the system
Approver responsibility
11/06/2013 Change Management, IT Meeting 20
Approver View: Approval formReminder: Approver responsibility
1
2
1. Comments can be added for the coordinator2. Approver decisions: “Approve” or “Reject”
• WARNING: If rejected, comments become mandatory
11/06/2013 Change Management, IT Meeting 21
Change Management, IT Meeting 22
• Life demo Finishing the workflow• Workflow steps completed in the demo: “Plan & Build” “Test -->
“Deployment” “Review and Close”• Involved actors: Coordinator
11/06/2013
Next step: Plans and build • During the Plan&Build phase some of the dates fields become
mandatory• Planned start date• Planned end date
Coordinator’ responsibility
1
1. Fields available in the change form. The change cannot be saved at this point without introducing planned dates identifying the start and the end of the planning phase
11/06/2013 Change Management, IT Meeting 23
Next step: Test
• Phase corresponding to the change testing• Declaration of tasks for testing purposes can be necessary at this level (not mandatory
though)• If needed coordinator can roll back to the stage: Plan&Build
Coordinator’ responsibility
11/06/2013 Change Management, IT Meeting 24
Next step: Deployment Coordinator’ responsibility
• Phase corresponding to the change deployment• If needed coordinator can roll back to the stage: Plan&Build (rolling back to
TEST is not allowed)• Deployment start date becomes mandatory
1
1. Declaration of the Deployment start date is mandatory at this level
11/06/2013 Change Management, IT Meeting 25
Next steps: Review and Closed• Final Review of the change• Available states now:
• Reviewed: Final state (change successfully completed)• State = Closed• Automatic Close code = Complete
• Rollback: Final state (change has failed)• State = Closed• Automatic Close code = Failed
• Deployment end date becomes mandatory independently of the state chosen by the coordinator• Only when the deployment end date is provided the change can be closed
Coordinator’ responsibility
11/06/2013 Change Management, IT Meeting 26
Change Management, IT Meeting 27
Change type = Minor• Characteristics
• Reduced workflow• Change coordinator = Requestor• Workflow goes directly to the Approval stage once the form is
submitted• Skipping Admission and Evaluation stages
• Approvers = FE managers in default• Coordinator approval is no longer needed
11/06/2013
Minor Change Workflow1 2 3 4 5
1. Change creation time: New2. Once the minor change is submitted the workflow directly jumps to Approval 3. FE Managers approvals mandatory
• Coordinator and the requestor are (in default) the same person• One FE manager approval is enough (in case of multiple FE managers)• Once approved the change passed directly to Deployment
4. From Deployment stage the Minor and Significant changes workflows are identical
11/06/2013 Change Management, IT Meeting 28
Life demo Minor change workflowWorkflow steps completed in the demo: ALLInvolved actors: ALL
Minor Change form
29
1
2
3
1. In default and automatically the requestor becomes the change coordinator also
2. The change type cannot be modified3. The list of approvers is populated with the FE managers of
the FE chosen at change creation time
• Change type: Urgent
11/06/2013 Change Management, IT Meeting 30
Creating an Urgent Change• Characteristics
• Reduced workflow• Change Coordinator = Requestor• Workflow goes directly to the Approval stage once the form is
submitted• Skipping Admission and Evaluation stages
• Approvers = Coordinator
11/06/2013 Change Management, IT Meeting 31
Urgent Change form
1
2
3
1. In default and automatically the requestor becomes the change coordinator also
2. The change type cannot be modified3. The list of approvers is populated with the coordinate name
only
11/06/2013 Change Management, IT Meeting 32
Urgent Change Workflow1 2 3 4 5
1. Change creation time: New2. Once the Urgent change is submitted the workflow directly jumps to Approval 3. Coordinator approval is mandatory
• Coordinator and the requestor are (in default) the same person• Once approved the change passed directly to Deployment
4. From Deployment stage the Urgent and Significant changes workflows are identical
11/06/2013 Change Management, IT Meeting 33
• Change type: Standard
11/06/2013 Change Management, IT Meeting 34
Creating an Standard Change• Characteristics
• Reduced workflow based on templates• It is the Requestor responsibility to chose this type of change while
clicking on the right hand top menu bar and select the template applicable to the corresponding standard change
• Change coordinator = Requestor• The workflow jumps directly to the Deployment stage• No approvals are requested• The Deployment End Date becomes the unique mandatory date
before setting the change stage to Reviewed
11/06/2013 Change Management, IT Meeting 35
Life demo Standard change workflowWorkflow steps completed in the demo: ALLInvolved actors: ALL
Standard Change Form1
2
1. Right click on the top bar menu and select “Apply Templates” action from the Templates menu
2. The list of available templates will appear in another dialog box• The available templates are defined on a group based• Creation of templates is (for the moment) an admin action
11/06/2013 Change Management, IT Meeting 36
Standard Change Workflow1 2 3
1. Change creation time: New• Selection of template mandatory
2. Once the Standard change is submitted the workflow directly jumps to Deployment • Approvals no requested in this change
3. From Deployment stage the Standard and Significant changes workflows are identical• Only the Deployment End Date is mandatory
11/06/2013 Change Management, IT Meeting 37