Change Requests
The Change Requests table is used for Change Management. A change request is created when a change is needed to a configuration item or to any other business object that may require a set of approvals before such a change can be completed.
Once a change request (CR) is created, it can be assigned to the appropriate teams or individuals for one or many approvals, and may then be moved along in the process, from approval to scheduling, to action by staff members actually making the change, to completion, testing, and release.
Of course each organization has its own definition of types of change that may need to be managed in this way, but we have pre-populated the service catalog with a list of common change types. You can easily add your own change categories and types to the services table. Change requests differ from service requests in that they are not visible by default to end users and typically follow a stricter set of procedures and approvals.
The Change Request table pulls its services from linked entries in the Services table. A user creating a change request chooses the higher level Business Service from a drop-down, and then sees all the active service offerings for that business service in a second drop-down list called Service. The available services for change requests can be seen in the Service Portfolio (or by creating a CR record and opening the drop-down list). When the service is selected, several additional fields are pulled in with the service, including whether or not approvals and tasks are needed.
Creation of Change Requests and Initial Actions
Change requests (CRs) can be created directly by users or by action button from a Service Request or a Problem record. When created with action buttons, the Change Request is linked back to the generating record.
End User Record Submission
By default, change requests are not visible to end-users and cannot be created by them. This is defined by group permissions, and if you would like to allow end users to submit change requests, change the group permissions of the relevant groups to enable this and enable access to change requests in the end user interface.
Technician Record Submission
When a technician submits a change request, the submitter contact information fields automatically populate based on the details in the user's Person record. In the default setup, a request cannot be submitted on behalf of a user who has no user record in the system. However, the creator can select a different person as the submitter if needed.
The Change Request table pulls its services from linked entries in the Service Portfolio table. A user creating a change request chooses the Business Service from a drop-down, and then sees all the active services that belong to that business service in a second drop-down list called Service. When the service is selected, several additional fields are pulled in with the service, including fields defining whether approvals are needed and the approval generation type. Users in the appropriate groups may be given permission to modify the approvals needed for a particular change.
When a technician creates the CR they choose an assigned team and assigned person from the drop-down fields at the top of the screen. The assigned team or person will be automatically set when the record is saved if the user does not choose the assignees. New CRs are created in the status of Open by default. Once the main fields are filled in, the user navigates to the Configuration Items tab. This allows the user to look up one or more configuration items. The CIs can be filtered by choosing a CI Type first and then clicking the Select Configuration Items lookup.
As CIs are selected, important information can be seen in the view of the CIs, including their criticality and the diagram that shows their relationships with other CI's.
You must choose a Configuration Item, even if none are involved in the change request. A Configuration Item is required to facilitate task management and prevent system errors. The “No CI Involved” configuration item record, with the CI Type of None, should be used in this situation.
Once the CIs are selected, the user clicks Submit for Review to save the change request and begin processing. When the change request is saved, the status changes to Pending Change Manager. In addition, required fields are validated and background fields are set to control visibility of approval and task buttons.
Automatic Assignment of New Requests
When a new change request is saved, it is automatically assigned to a team based on the values in three fields pulled from other tables. The related service has a Responsible Team associated with it and a field called 'Give Responsible Team Priority over CI Team' with a Yes/No value. If a configuration item was identified for the request, then there is also a CI Responsible Team field that will be populated in the CR.
The current assignment logic is: if the Assigned Team is empty when created and the change request involves a specific configuration item (CI), then the request is assigned to the responsible team for that CI, unless the 'Give Responsible Team Priority over CI Team' is set to Yes. In this case, or If no CI is defined, then it is assigned to the Responsible Team for the service. If there is no Responsible Team for the service, then it is assigned to the Change Management Team.
Naturally, this logic may be changed to suit your organization. You can simply set a default value such as the Change Management Team or you may choose some other logic to use based on different fields. The current logic is implemented in the CR rule named 'Create: All Change Request Creation Actions' and the action named 'Assign change request'.
Automatic Emails Sent upon Submission
If the status is not Completed when saved, a rule will send the submitter an acknowledgement email and will also send an email to either the Assigned Person, if there is one, or to the Assigned Team.
Processing the Change Request
Most services linked to change requests require one or more approvals. See the section on Approval Management for details about how to set up approval workflows and templates.
Many of the default approval workflows for change requests contain conditional approvals, which depend on the Change Type (i.e. Standard, Normal, Emergency, Change Proposal) and Change Category (Category 1 - Minor or Small, Category 2 - Significant or Medium, Category 3 - Major or Large), and other factors. The workflows are predefined within each service, and can be used to create Change Models and Standard Change Workflows. Each service may have both a default Approval Workflow and a default Task Workflow.
In addition to being able to define standard change workflows and workflows for change proposals and other change models, further processing details that are pulled into the CR are also stored in the service record, including the Responsible Team, Escalation Team (i.e. which team it should be escalated to if thresholds for escalation are met), the default Change Type, and any additional fields that should be shown for the change request based on that service.
Managing the Approval Process
Change requests can use different approval methods, discussed in the Approvals for Change Requests section on the Service Catalog page. Based on the approval method defined in the service record, approvals will typically be created and launched within the change request using buttons.
Default Conditional Approval Workflow
We have defined a standard ITIL default approval workflow called Default - conditional approvals based on type/category with conditional approvals generated based on the combination of Change Category and Change Type. It is a good illustration of how conditional approvals can be set up. It contains the following approval templates: Change Manager Approval for all Minor changes; IT Executive Board Approval for Major Change; CAB first Approval for Significant Normal Change; ECAB First Approval for Significant Emergency Change; CAB second approval for Major/Normal change; ECAB second approval for Major / Emergency change.
The result of this setup is to create the following approvals for the following combinations of Change Category and Change Type:
- Minor change - Change Manager Approval only
- Significant Change / Normal - CAB Approval only
- Significant Change / Emergency - ECAB Approval only
- Major Change / Normal - IT Executive Board, then CAB Approval
- Major Change / Emergency - IT Executive Board, then ECAB Approval
Approval Creation and Processing
Once the request has been sent for review, if it was for a service that requires approvals, the change manager can review it and generate any needed approvals. Clicking the Generate Approval(s) button will generate the approvals based on the predefined approval workflow. If the change request service allows ad hoc approvals, options will be available to generate additional approvals as needed. Approvals are generated in a status of Queued by default. Once the approvals are generated, new buttons appear to 'Launch Approval Process' and 'Recheck Conditional Approvals.'
When change managers are ready for the approval process to start, they click Launch Approval Process to set all approvals with the lowest step number to Pending Approval. It will also update the status of the change request to Pending Approval.
When an approval’s status is set to Pending Approval, the approval team and/or approver are notified by email. Only the person identified as the approver or on the approval team will be permitted to approve or reject the approval. The approval process sequence is controlled by the step numbers. Approvals with the same step number value are launched at the same time, when the approvals with the next lower step number are completed. This is a different model than in the task workflows, in which the prerequisite task functionality provides more sophisticated branching sequences. With approvals, the step number controls the process and there are no separate sequences or threads in the approval process.
Another way in which approval generation is different from the handling of tasks is that conditional approvals are not created at all unless their condition is met at the time of generating the approval. Since these conditions generally depend on the meta data and fields in the change request, it is important to make any critical fields required to hold a value before getting to the point of generating approvals. The Recheck Conditional Approvals button does allow the technician to recheck the condition, if after generating the first approvals, the meta data changes. But it is best to ensure that any needed meta data is filled out first.
As the first approvals are completed, those with the next step number are set to Pending Approval and their assignees notified. Any approval notes put into the approvals are copied up to the change request in the running All Approval Notes field. Two fields below the approvals table track the Number of Approvals Needed and the Number of Approvals Completed, and once those two numbers are equal and greater than or equal to 1, the status is changed to Approved and the Requester and the Change Management team are notified.
Managing Tasks
Some services have predefined tasks that will be created, either in a multi-sequence workflow, or individually.
Tasks are generally created for the CR once any approvals are done. The user must first enter the Change Window Start Time and Change Window End Time, so that the tasks can be scheduled to start on the start date.
Services with a Single Default Task Defined
Here is an example where there is one default task for a given service (Perform update to the selected configuration item). Clicking the Generate Tasks button will generate one task for each of the CIs listed in the Generate Tasks for field.
The result of clicking the Generate Tasks button in this case is:
Generating Ad Hoc Tasks
Depending on the options selected in the service, the user may have an option to create one or more ad hoc tasks. He may check the box for Create New Task to Generate? to create another task template that can be generated for all the selected CIs. Checking that box will bring up some fields to fill in for the ad hoc task:
Clicking the button to Create New Task to Generate will create a new Task Template, save the change request, and reopen it to edit, with the new task selected in the Task to Generate field. From here, he can click the Generate Tasks button again to add the Task to this CR for each CI that is selected.
Launching Tasks
Tasks may not be launched until the approval process is completed. This is to ensure that no work is started without approval. Clicking the Launch Tasks button will run the following checks and actions:
- If the field Service Approvals Required is set to Yes and there are still pending approvals, the tasks are prevented from launching.
- If the change request is related to a release and the release status has not yet advanced to Build in Progress or beyond, the tasks are also prevented from launching.
- Otherwise, a background field that controls visibility of the Launch Tasks button is set to No, a field controlling visibility of the Create Tasks button is set to No, the field Launched in all tasks for the workflow is set to Yes, the tasks without prerequisites are set to a status of Assigned, and the change request status is set to Implementation Started.
See the Task Templates and Tasks Table topics for more details on how tasks are launched and processed.
Reassigning the Change Request
To reassign the change request to a different team or person, change the Assigned Team and/or Assigned Person field and the system will email the new assignee notifying them of the reassignment.
Completing the Change Request
When all tasks are completed, the Change Manager is notified. Based on whether the tasks were all completed or whether some of them failed, the change manager will then set the status of the change request to Completed and the Closure Category to the appropriate value. If there are tasks whose status is Failed, the closure category will be validated to contain an appropriate value.
Changing the status to Completed will send an email to the Requester stating that the change is completed. Upon closing a change request, fields on the Work Status tab can be used to create a Knowledge Article based on the change request.
Setting 'Review for Knowlegebase' to Yes indicates that a knowledge article should be considered based on this change request. Once Review for Knowledgebase is Yes, the Knowledge Document Status and Create Knowledge Article fields are visible.The default value of Knowledge Document Status is Pending Review, and once Create Knowledge Article is clicked, the Knowledge Document Status is automatically updated to Created. If it turns out the knowledge article is not necessary, Knowledge Document Status can be changed to Not Needed manually. Clicking Create Knowledge Article opens a new knowledge article record with some information mapped from the change request, such as the Title, Purpose, and Description. Additional required fields must be populated before saving the record. Once the new knowledge article is saved, it is automatically linked within the originating change request. In addition, the knowledge article will automatically include about the source change request.
Working Notes
The Working Notes field is updated automatically from the running working notes for all of the related Tasks.
Related Records and Removing Tasks
During the working process, some tasks may be removed as not needed by the change manager. The action bar above the Tasks table in the change request includes a button to remove one or more tasks. This changes the status of the selected tasks to Not Needed and hides them. They are moved to the History tab and the embedded table called Inactive Tasks. There is a button above this table allowing the user to select a task and reassign it back to an active task.
Additional Notifications to Teams and Individuals
There are two fields that result in automatically notifying specified people or teams when the status of the change request is changed to Approved, Scheduled, and Completed. The 'Notify these Teams on Status Changes' and 'Notify these People on Status Changes' fields are shown near the bottom of the Details tab.
The change manager can look up specific teams or people and populate them into these fields, and when the status changes to Approved, Scheduled, or Completed, the teams and/or users will receive a notification telling them of the new status and details about the request. The following is an example of the email sent when a request is scheduled.
Subject: Change request 278 is Scheduled
Body: You are identified as a CC on the change request shown below, which has just been schedule.
The change is scheduled to start on Jul 05 2016 01:00 and to end at Jul 05 2016 03:00.
Click here to view the request directly.
ID: 278
Change Category: Category 2 - Significant or Medium
Status: Scheduled
Change Management Team: Change Management Team
Change Manager: Chuck Eisner
...
Parent/Child Relationship
Previously we used a parent-child relationship of change requests to manage changes to multiple CIs. That possibility is still available but the fields for relating parent and child change requests have been removed from the layout, since that was a much more cumbersome process than the improved process based on generating tasks for each configuration item within the change request. However, if there is a need to relate change requests in a parent child structure, this logic can be re-utilized by putting the fields back on the layout and enabling the rules that managed the relationships.
Workflow
Change Request Form Layout
This section contains an overview and screenshot examples of the information stored in a change request in the out-of-the-box system.
Details Tab
A Change Summary must be entered to briefly describe the change, and a Change Category must be selected to categorize the significance of the change. A Change Management Team and Change Manager can be selected, and any team or people who want to be CC'd on status change notifications can be added to the notification fields. If a Change Management Team is chosen but a Change Manager is not, all team members will receive a notification. If a Change Manager is chosen, the email will be sent only to that individual.
The submitter fields, Submitter Name, Email, Phone, Manager, and Department in the Submitter Information section default to the person who creates the Change Request, but this can be changed by clicking the lookup icon.
Next, a Business Service must be selected. Depending on the Business Service chosen, certain Services are available to categorize the Change Request further. The Risk for both if the Change is done and not done can be logged for analysis and assessment of the overall risk of the change request. Impact indicates the scope of the change request's effect, and Urgency can be used to convey how important it is to make the change. Impact and Urgency have options that are available based on the priority group for the service selected. Once Impact and Urgency values are selected, the Set Priority button can be clicked to preview the Priority that will be assigned to the Change Request based on the Impact and Urgency.
A description of the change is required, and in some cases, business reasons that justify the change. A backout plan is required, and an attachment or multiple attachments with more details can also be uploaded.
Configuration Items Tab
The Configuration Items tab shows all of the configuration items that will be affected by the change being requested, and allows the user to create these relationships between the change request and the CIs. Any relationships created here will also subsequently be displayed when viewing the CI record directly. CI attributes are also shown to facilitate change assessment and authorization, such as the Criticality of each CI.
In the Relationship Diagram column, click the tree icon to see a relationship diagram for each CI that shows the other CIs to which it is related.
Approvals Tab
Based on the requirements specified for the service that the change request pertains to, approvals may be required. The Approvals tab displays the default Approval Workflow for that Service, and a different one can be selected if needed using a lookup. The approvals are then generated and launched, with the first approval set to a status of Pending Approval. Once all approvals are completed, the status of the change request is set to Approved.
Schedule and Tasks Tab
The Schedule and Tasks tab displays the maintenance window for the service and indicates whether there will be downtime. In addition, the change request can be tied linked to a Release record, and information about the Change Window Start Time and Change Window End Time can also be included. Once the change request is ready to be scheduled and has been approved, buttons appear to create one or more calendar entries for the change window, as well as for any build or test activities that should be published in the change calendar.
If Tasks are required for the change request, they are also shown on this tab with a Default Task Workflow and the option to customize and generate tasks.
Work Status Tab
The Work Status tab provides a place for working notes to be added. If the status is changed to a terminal status, for instance Completed or Canceled, a Closure Category is also specified for the change request.
Time Tab
Technician users may easily report the time they spend on handling change requests. There are two fields and an action button: Time Spent, Time Description, and Add Time on the Time tab of the layout. Entering values there will automatically create a new time entry record when the Add Time button is clicked. The time entry will show the work done by the technician and on the current date.
All the time entries for a request can be seen on the Time tab as well. If technicians need to report time spent on a different day or by a different user, they may click New on the Time spent table to submit a time entry directly and change the date or Done by field. All time entered is totaled in the All Time Spent field, which can be used in reporting or billing.
Note that this same time entry methodology is used in the Incident, Problem, Service Request, and Task tables.
Related Records Tab
The Related Records tab displays all of the links/relationships to and from the Change Request, including related problem records, related incidents, incidents caused by the change request, and related service requests.
Ownership
Records in the change request table are owned by the person whose login matches the Creator Login field.
Reporting and Statistics
This section describes the reports and statistical functions in the Change Requests table.
Forward Schedule of Change and Projected Service Outage
The Forward Schedule of Change represents approved changes and the proposed implementation dates. More generally, it is a list of change requests set to occur in the future. Functionally it might include CRs with restricted criteria, such as approved changes only, but by default the Forward Schedule of Change simply shows all change request that are not in a status of Closed.
The Forward Schedule of Change is a saved search available from the left pane menu under the Change Request table name. Change Requests are listed in order of Change Window Start Time. This search is also used in a structured HTML report of the same name. The report groups the CRs by requested date of completion, by week, and shows summary data including the sum of the Estimated Time to Complete for all records. The report can be configured to be sent in a weekly email to the Change Management team.
Projected Service Outage
The Projected Service Outage represents all approved changes that are set to occur in the future that will result in downtime. Similar to the Forward Schedule of Change, the Projected Service Outage (PSO) is also available from the left pane menu under the Change Request table name, and can be viewed in a structured HTML report. The change requests in the PSO are listed in order of the Change Window Start Time.
Both the Forward Schedule of Change and Projected Service Outage can be set up to be automatically emailed to various teams. This also applies to all charts and reports, which can be configured to be automatically sent to the defined teams. This allows for the sending of various reports to accommodate pre and post meeting workflows or CAB/eCAB proceedings, such as reports of pending changes, completed changes, and CRs pending post change reviews.
Change requests can be added to the Change Schedule using the Calendar icon at the top right corner of any record. Users can also subscribe and add the calendar as an internet calendar in Outlook. Users can further refine what they see on their calendars based on the Event Type in the Calendar entries, for instance Build, Test, Implementation. A link can also be generated and the same link can be distributed to all users to integrate the schedule into their Outlook Calendars.
Accomplished Change
Accomplished Change is the complement to the Forward Schedule of Change and by default shows all closed Change Requests, sorted by Date Closed.