Implementation of the Change Management Process in ServiceNow

2. Change Management Demo for IT 11/06/2013 Implementation of the Change Management Process in ServiceNow Change Management, IT Meeting

3. Outlook Change Management, IT Meeting The 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

4. Documentation Change Management, IT Meeting Change Management User Guide: https://services.web.cern.ch/wiki/training-material

5. Change Management, IT Meeting • 1st Block • 4 changes types implemented in the system • Access to the Change Management application in ServiceNow • Involved actors

6. 4 types of changes Significant: Full workflow Minor: Reduced workflow Urgent: Reduced workflow Standard: Reduced workflow based on templates Workflow Change Management, IT Meeting

7. Getting Started: Navigation Panel • 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 1 2 2 3 3 Change Management, IT Meeting

8. Getting Started: Change Workflow • New: Automatic status at change creation time: Fulfillment of the change form • Admission: After the submission, the change request is sent to the FE manager for its study (Significant Change). • 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). • 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 • Plan&Build: Development of the change plan. (Significant Change) • Test: Testing phase of the applied change (Significant Change) • Deployment: Deployment of the change • Review: Review of the change (and closing decision) • Closed: Final (automatic) state Completion of these steps will depend on the change type Change Management, IT Meeting

9. Getting started: The actors Change Management, IT Meeting • 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

10. Change Management, IT Meeting • 2nd Block • Fulfillment of each change type • Workflow description • Tickets access and control

11. Change type = Significant Change Management, IT Meeting • 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)

12. Admission Phase: Change submitted 3 Procedures described at each step 1 • Admission states • Requested: Default status • Accepted: Change is accepted by the FE manager • Not accepted: Change is rejected. Final state • 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 2 3 The change is now FE manager’ responsibility

13. Evaluation phase: Declaring tasks and approvers 5 1 2 Coordinator’ name can be changed “Assigned to” field contains the current coordinator The coordinator can declare tasks assigned to other persons Coordinator is allowed to declare further approvers that will have to accept or reject the current change Once the approvers have been defined (a not mandatory action), the coordinator can request such approvals clicking on: “Go to approval” 3 4 The change is now coordinator’ responsibility

14. Declaring Change Tasks Change Management, IT Meeting Reminder: 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

15. Completing the Change Task Task person responsibility 1 2 3 4 5 Declaration of the assignment group handling the task (editable) Person who will complete the task (editable) Short description of the task (editable) Task description Internal work notes visible for the support group members only

16. Acknowledging/working on the task Reminder: Task person responsibility 2 1 4 • Access to the list of tasks assigned to the log-in person • List of all tasks assigned to me and status (columns can be personalized) • Communication field with the coordinator • 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 3

17. Approvals handling Reminder: Coordinator’ responsibility • 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”

18. Change Management, IT Meeting • Life demo  Declaring approvers • Workflow steps completed in the demo: “Approval” • Involved actors: Coordinator and approvers

19. Types of Approvals Coordinator’ responsibility 1 2 List of all approvers available for the coordinator from the change form 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” Comments can be added and will be received by the approver 3 The coordinator can declare different types of approvals: financial, confidentiality, functional (default), technical

20. Approver View: Finding the approvals Approver responsibility 1. List of approvals reachable from the navigation menu 2 1 • 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 Change Management, IT Meeting

21. Approver View: Approval form Reminder: Approver responsibility 2 1 • Comments can be added for the coordinator • Approver decisions: “Approve” or “Reject” • WARNING: If rejected, comments become mandatory Change Management, IT Meeting

22. Change Management, IT Meeting • Life demo  Finishing the workflow • Workflow steps completed in the demo: “Plan & Build”  “Test --> “Deployment”  “Review and Close” • Involved actors: Coordinator

23. Next step: Plans and build Coordinator’ responsibility 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 Change Management, IT Meeting • During the Plan&Build phase some of the dates fields become mandatory • Planned start date • Planned end date

24. Next step: Test Coordinator’ responsibility Change Management, IT Meeting • 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

25. Next step: Deployment Coordinator’ responsibility 1 Declaration of the Deployment start date is mandatory at this level Change Management, IT Meeting 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

26. Next steps: Review and Closed Coordinator’ responsibility Change Management, IT Meeting • 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

27. Change type = Minor Change Management, IT Meeting • 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

28. Minor Change Workflow 1 2 3 4 5 • Change creation time: New • Once the minor change is submitted the workflow directly jumps to Approval • 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 • From Deployment stage the Minor and Significant changes workflows are identical • Life demo  Minor change workflow • Workflow steps completed in the demo: ALL • Involved actors: ALL Change Management, IT Meeting

29. Minor Change form 2 1 In default and automatically the requestor becomes the change coordinator also The change type cannot be modified The list of approvers is populated with the FE managers of the FE chosen at change creation time 3

30. Change Management, IT Meeting Change type: Urgent

31. Creating an Urgent Change Change Management, IT Meeting • 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

32. Urgent Change form 2 1 In default and automatically the requestor becomes the change coordinator also The change type cannot be modified The list of approvers is populated with the coordinate name only 3 Change Management, IT Meeting

33. Urgent Change Workflow 1 2 3 4 5 • Change creation time: New • Once the Urgent change is submitted the workflow directly jumps to Approval • Coordinator approval is mandatory • Coordinator and the requestor are (in default) the same person • Once approved the change passed directly to Deployment • From Deployment stage the Urgent and Significant changes workflows are identical Change Management, IT Meeting

34. Change Management, IT Meeting Change type: Standard

35. 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 • Life demo  Standard change workflow • Workflow steps completed in the demo: ALL • Involved actors: ALL Change Management, IT Meeting

36. Standard Change Form 1 2 • Right click on the top bar menu and select “Apply Templates” action from the Templates menu • 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 Change Management, IT Meeting

37. Standard Change Workflow 1 2 3 • Change creation time: New • Selection of template mandatory • Once the Standard change is submitted the workflow directly jumps to Deployment • Approvals no requested in this change • From Deployment stage the Standard and Significant changes workflows are identical • Only the Deployment End Date is mandatory Change Management, IT Meeting