In this lesson we will cover:
– Change Management Explained
– Types of Change
– Change Management Tab
– Approval Processes
– Approval Step on a Workflow
– Change Freeze Periods
– Asset Dependencies
– Change Calendar
– Date Dependencies
Associated Admin Guide:
Change Management
When a change request ticket is raised, this should be assessed according to your change management process, often this will require approval before any changes are implemented or scheduled for implementation. Different types of change requests can be configured, such as a Standard Change or an Emergency Change, depending on the urgency of the change required.
Types of Change
Types of change should stick to a standard process in order to efficiently go about change management. For best practice 4 distinct change types should be implemented.
1. Standard Changes
- A low-risk, pre-authorised change that is well understood and fully documented, and can be implemented without needing additional authorisation. Is often initiated as a service request, but may also be an operational change.
- Requires a full risk assessment and authorisation only during creation, or modification due to business change or occurrence of an incident.
2. Normal Change
- A change that needs to be scheduled, assessed, and authorised following a standard process.
- Involves change models based on the type of change determine the roles for assessment and authorisation i.e. low level changes require local (team or supervisor) authorisation while high level changes may require board level authorisation.
- Initiation is triggered by the creation of a manual or automated change request.
3. Major Change
- This change has a high level risk or great financial implications for the business.
- A full change procedure is required with approvals from appropriate levels of management before proceeding with this change type.
4. Emergency Change
- A change that must be implemented as soon as possible without strictly following the standard process e.g. to resolve an incident or implement a security patch.
- The process for assessment and authorisation is expedited to ensure quick implementation, so scheduling and documentation is not a priority.
- The change authority may be separate from what is standard or normal practice, typically smaller in number but with greater capacity to expedite approval.
Categorising any change should be one of the first steps in recognising a change, understanding its impact and severity.
Change Management Tab
The change management tab can be configured in Configuration > Tickets > Change Management. Head to the Custom Objects course to see how the change management tab can be configured in a different way (Lesson: Custom Tabs).
When enabled, the change management tab will appear on all change request ITIL ticket types and the fields displayed with in it can be checkboxed on, as shown above.
Approval Processes
Fig 1. Approval Process Buttons
The approvals can be configured in the approval process module of the configuration. The purpose of this is to restrict who can approve certain changes and ad-hoc approvers can be added for when the other approvers are not available.
There are 5 types of approvers
The first type of approver is an end-user. An approval process of this type will send an email to the end-user asking for their response to an approval request. This could be related directly to services that you provide or assets they are associated with.
The second type of approver is a manager. When you're using the Active Directory integration this will sync your managerial structure through to Halo. This means that the system will have a record of who manages whom, and can therefore use this information to send approval messages to the end-user's manager or even manager's manager if selected.
The third type of approver is a Team Leader, which is configured in the agent's permissions.
The fourth type is a Change Advise Board (CAB), which can be added to the approval process which is a group of people that are specifically configured for a certain approval. For example, if there was a team of people that you would want to add as part of the setup process, you can set the approval to approve by: A fixed CAB
Fig 2. Configuring a CAB for approvals
A CAB's work by a given number of accept votes is required for successful approval. If the number of accept votes does not meet the required number, the approval is rejected. This number is listed in the configuration for the CAB.
The final type of approver is an ad-hoc approver. This will ask you to select a user or agent from the list of all available approvers. This option can also be used in combination with the above options by checking the below option on the approval step.
Fig 3. Allowing Ad-hoc approvers
The My Approvals Area of the service desk is useful to see the list of approvals that require action. The following tile style display can be viewed when clicking into the area:
Fig 4. My Approvals Area
Approval Step on a Workflow
Approvals can be added to workflows in order to i.e. prevent the next step being moved to without someone approving the current step.
Fig 5. Approval Step Added to a Workflow
Change Freeze Period
Within the change management module of the configuration, there can be freeze periods set on a table. The purpose of this is to allow for certain date ranges where there is to be no changes made, this will stop agents from being able to create change requests during the specified dates. This is useful for certain times throughout the year such as christmas when there may be no employees working, so the change freeze period could be set from i.e. the 24th of December until the 28th of December, it can also be recurring as shown below.
Fig 6. Adding a Change Freeze Period
The setting called "Enable Change Collision Detection" is used to notify agents when they attempt to log a Change Request with times that overlap any Freeze Periods defined.
Fig 7. Setting Freeze Period to Recurring
The "Create Schedule" option becomes visible when the recurring checkbox is selected. This is used to set a recurrence pattern.
Fig 8. Configuring the Schedule for the Change Freeze Period
Asset Dependencies
If there are assets on the ticket, which are dependant on other assets, there is now an option to add in the dependencies tab of the assets. First click into the edit section of the asset field on the field list of a ticket type:
Then tick on the "Show Dependencies Tab" on the edit list:
Now when an asset with relationships to other assets, is added to a ticket, then the dependencies tab will show on the ticket.
We can also show related services by checking the following checkbox in Configuration > Asset Management > General Settings:
When this general setting is on, we can see the related services option on the sidebar of the dependencies tab, in this case, the service called "Desktop" is now showing on the far right hand side of the dependency diagram:
Change Calendar
Change request tickets can show on the agent calendar so you can see upcoming and scheduled changes due to take place. To show change requests on the calendar head to the calendar module and ensure the 'Show change requests' filter is checked.
Tickets must meet two criteria in order to appear on the change calendar:
- The ticket type must have ITIL ticket type 'change request'
- The 'Start date' and 'Target date' field must be completed
The dates the change spans on the calendar will be taken from the the 'Start date' and 'Target date' fields on the change request ticket.
Change Freeze periods will also appear on the change calendar (in Grey).
To have only change requests that have been approved appear on the calendar enable 'Only show changes that have been approved on the Change Calendar' in configuration > tickets > change management. This will ensure the ticket must have completed an approval process and been approved before it will show on the calendar. This ensures only requests that are actually taking place will appear on the calendar.
Custom Filters for the Change Calendar
Results that appear on the change calendar can be filtered by a custom field against the ticket. This allows you to filter results based on custom criteria.
Note: Filters can only be based on dropdown custom fields
To set a filter based on a custom field, head to configuration > custom objects > custom fields > select the custom field you would like to filter by, enable 'Filterable on the Calendar screen'.
Now when you head into your calendar and expand the 'Filters' a filter will be available based on this custom field.
In the above example if I set the 'Change Type' filter to be 'Emergency' only change request tickets that have the Change type field set to be 'Emergency' will show in my calendar.
Note: Ensure the custom field you are filtering by is in the field list for your change request tickets. If a filter for this field is applied and the field is not in the field list for the ticket the ticket will not appear in the results.
Showing the Change calendar in the Portal
The change calendar can also be used to display upcoming changes to users in the portal. This provides a more date-specific view of upcoming changes, allowing users to see the exact dates changes are scheduled to take place. The change calendar will show all tickets that have the ITIL ticket type 'Change Request', the start date and target date fields on the ticket will determine the dates the ticket appears on the calendar for.
To enable the change calendar for the portal head to configuration > tickets > change management, enable 'Publish the change calendar to the Self-Service Portal'.
Once enabled you will see a setting to determine the 'Change Calendar Visibility', the option selected here will determine what change tickets appear on the calendar for the logged in user.
Show all changes to all users – All users will be able to see all change requests, regardless of who the end user of the ticket is
Show changes for the logged-in users client only – The user will only be able to see change request tickets in which the end user of the ticket is under the same customer as them.
Show changes for the logged-in users client and services they have access to – The user will only be able to see change request tickets in which the end user of the ticket is under the same customer as them. If the change request is linked to a service, they will only be able to see request tickets linked to a service they also have access to.
Show changes for the logged-in users client and their subscribed services – The user will only be able to see change request tickets in which the end user of the ticket is under the same customer as them. If the change request is linked to a service, they will only be able to see requests linked to services they are subscribed to.
Once this setting in enabled you can add a button to the portal for users to access the change management calendar, head to configuration > self service portal > add the menu button 'Change calendar'.
Now users will be able to navigate to and see the change calendar in the portal.
Viewing change request tickets from the calendar
Users can select an entry in the change calendar to view the change request ticket for that change. If you would not like users to be able to view the associated ticket disable 'Allow all Users to access Tickets shown on the change calendar' in configuration > tickets > change management.
Date Dependencies
Date dependencies can be used to adjust start and target date of a child ticket based on another child ticket. This can be useful for larger scale changes that require one process to be completed before the next begins. For details on this, see the "Date Dependencies" section of Creating Projects.
