Detecting collisions between change requests
A collision occurs when a CI is related to two or more change requests whose implementation schedules overlap. Change Management detects collisions between change requests automatically, and helps you to make decisions to manage and resolve the potentially harmful conflicts between these change requests.
The following video (2:29) describes the process of detecting collisions and taking action on them in Progressive Web App screens:
What is a collision?
A collision occurs when the same service or configuration item (CI) is related to two or more change requests, and the schedule dates for the change requests overlap.
Best practice
How collisions occur
Understanding how collisions occur helps you to avoid spending resources inefficiently, and to avoid creating instability in your IT infrastructure. Collisions are dependent upon a time (scheduling) factor and a CI factor and not on the status of the change request. Together, both factors play a role in determining whether a collision exists.
Time factor
The time factor of collisions depends upon the Scheduled Start Date and Scheduled End Date values in the Date/System tab of change requests. Collisions occur when there is a complete or a partial overlap of implementation schedules. If you consider two change requests, A and B, the following schedule-based collision scenarios are possible:
- Identical dates—Both change requests have the same scheduled start and end date values. It is unlikely that the CI will be available for two IT personnel to work on at the same time.
- Complete schedule overlap—Work on change request B is scheduled to begin after work on change request A, but will be completed before the work on change request A is completed. In this scenario, even though change request B requires a shorter implementation period, the CI will be unavailable to the assigned IT personnel because of the work being done for change request A.
- Start date and end date overlap—Work on change request B is scheduled to begin before work on change request A is completed. In this scenario, the IT personnel assigned to work on change request B will not be able to access the CI because work on change request A is still in progress.
CI factor
The CI factor determines the risk that the implementation of a change request might impede or undo the implementation of another change request. Depending on the type of effect that a change request has on a CI, the following CI relationship-based collision scenarios are possible:
- Direct effect—A CI is related to two or more change requests. All of the change requests affect the CI directly, and have overlapping schedules.
- Indirect effect—A CI that has dependencies is related to a single change request. This change request is likely to affect the dependent CIs indirectly. If one of the dependent CIs is related to a different change request with a conflicting schedule, a collision occurs between the two change requests.
Example
Consider a server that hosts a number of virtual machines. User A submits a change request for an operating system upgrade on one of the virtual machines. The request is scheduled to be implemented between 4:00 P.M. and 5:00 P.M. on Tuesday, the following week. The next day, User B submits a change request to add another hard disk to the server. This request is also scheduled to be implemented on Tuesday of the following week, but between 3:00 P.M. and 6:00 P.M.
A collision now exists, because of the complete schedule overlap, and because the change request for the server hardware upgrade indirectly affects the virtual machines that it hosts. A change in schedule is necessary to implement both change requests efficiently.
How do I detect collisions and take action on them?
BMC Helix ITSM detects collisions after services or CIs are related to a change request, and the scheduled dates have been specified. Potential collisions are displayed when you are creating or updating the change request and after you save the change request.
When you create a change request, after you enter values for the Scheduled Start and End Dates, but before you save the change request, the list of collisions (if any) for services or related CIs are displayed when you click on Check collisions at the bottom of the screen.
In the Change collision window, you can see the Change ID, Summary, CI Name, Status, and the change coordinator name. Click the Send an email to all change coordinators with conflicting CRQs link to contact the change coordinators by email, in case you need to discuss schedules and priorities.
To resolve the collision, select the required impacted CI or all the CIs and click the required option from the Mark Selected list.
After you save the change request, if the collision is not resolved, the system warns you again about potential collisions by displaying an alert banner at the top of the change request details. To resolve the collisions, click or tap Show more to display the Change collision window.
Comments
Log in or register to comment.