ITS Service Management Newsletter
In this edition, we have some exciting updates to share!
Service Management
Please check out the new ITS Service Management Roadmap to see what the Service Management team will be working on for the next few years.
Incident Management
The Service Management Incident Management page has been completely updated and now includes the recently approved ITS Incident Management Standards and Guidelines and an updated Major Incident Checklist!
The old ITS Maintenance and Incident Communication Policy wiki is now deprecated and the site will be retired on 9/15. Please ensure all your bookmarks and internal documentation is updated.
Training
- Training on the Major Incident Checklist is scheduled for Thursday the 16th and 30th in September.
- Training for the ITS Incident Management Standards and Guidelines is available on the Incident Management page.
Change Management
The Change Management Standards and Guidelines document has been updated to replace all references to the old ITS Maintenance and Incident Communication Policy wiki and the FAQ has been completely updated to include all the questions we answered in previous newsletters.
Please keep sending in your feedback to us using the ITS Service Management Contact Form which is also linked on our ‘Contact Us’ page.
Planned Updates
We have been working through your feedback with the ServiceNow team and have a number of updates to the Request for Change (RFC) process going in with the October ServiceNow release.
| Feedback | Solution |
|---|---|
| Staff are forgetting to check the ‘Create Outage’ checkbox on an RFC when the change will result in an outage. This oversight results in the change not having a record created on the Alerts & Outages page ‘Planned Maintenance’ section in ServiceNow. | Change the ‘Create Outage’ checkbox on the ‘Planning’ tab to a required drop down text box with options for ‘Disruptive (Create Outage)’ and ‘Non-Disruptive’. When ‘Disruptive (Create Outage)’ is selected, a record for the planned outage will be created on the Alerts & Outages page in ServiceNow. |
| The ‘Impacts Security of Information’ checkbox on the ‘Risk Assessment’ tab isn’t needed and does not trigger any action. | Remove the ‘Impacts Security of Information’ checkbox on the ‘Risk Assessment’ tab. |
| It is not clear what the ‘Service Customer Notification’ checkbox on the on the ‘Planning’ tab is for. | Change the text of the ‘Service Customer Notification’ checkbox on the ‘Planning’ tab to ‘Dependent CI Notification’ and update the tooltip. This checkbox is intended to be used in the future, once the CMDB is completed, to automatically notify owners of dependent CIs of planned maintenance. |
| The Change Management S&G requires a communication plan (Section 8.2) but there isn’t a requirement for that in an RFC. | Add a required text box field and tooltip for ‘Communication Plan’ to the ‘Planning’ tab and remove the ‘CSU Communication Required’ checkbox on the ‘Risk Assessment ‘tab. |
| It is not clear what the ‘Security Sensitive’ checkbox on the ‘Risk Assessment’ tab is for. | Add a tooltip to the ‘Security Sensitive’ checkbox on the ‘Risk Assessment’ tab . If checked, it will no longer require planned start and ends dates on the ‘Schedule’ tab and an outage record will not get posted in the Service Portal so the change will not be advertised. |
| The default answer of ‘None’ is a logically value response to the RAV questions on the ‘Risk Assessment’ tab but it is not selectable. | Change the default answer for each of the RAV questions to ‘Select One’ from ‘None’ on the ‘Risk Assessment’ tab. |
Future Updates
| Feedback | Proposal |
|---|---|
| The approval group for an RFC should be automatically populated when the Configuration Item (CI) is selected. Staff must manually determine the correct ‘Assignment Group’ for an RFC CI by reviewing a KB in ServiceNow. | We are proposing to utilize the ‘Change Group’ field instead of ‘Assignment Group’ since ‘Change Group’ is a valid field in the CI Class Manager and ‘Assignment Group’ is not. This change should allow the RFC workflow to automatically populate the group that is associated with the CI selected. This will also require Service Owners to define the name and membership of a ‘Change Group’ for each CI eligible for an RFC. |
| There should be multiple people who can approve an RFC rather than just the service owner. This limitation creates a bottleneck for approving changes when the approver is OOO. | We are proposing to utilize the ‘Approver Group’ field instead of ‘Assignment Group’ owner for approvals. This change should allow the RFC to route to multiple people for approval. This will require Service Owners to define the name and membership of an ‘Approver Group’ for each CI eligible for an RFC. |
| The list of Configuration Items (CI) available to choose from in an RFC should be limited to just those that are eligible for an RFC to be raised against them. | We are proposing to utilize the ‘Change Group’ field to limit the CIs available to choose from. Since the Configuration Item (CI) field is widely used throughout ServiceNow, this will require some customization to the field for the RFC form. |
Please submit your questions or comments for the Service Management Team