How does it work when an incident requires a change

By ITIL® from Experience©

Incidents that need a change to be resolved can either be an:

Incident with a workaround
Incident without a workaround

To facilitate reading not all activities and procedures that would be performed are listed.

1. Incident with a workaround requiring a change

The incident is logged (e.g. by Event Management, User self-service, Service Desk, operation’s staff)
The Service Desk provides a workaround
(ITIL® Service Operation) Reducing or eliminating the impact of an incident or problem for which a full resolution is not yet available – for example, by restarting a failed configuration item. Workarounds for problems are documented in known error records. Workarounds for incidents that do not have associated problem records are documented in the incident record.
Source: ITIL® Glossary and abbreviations, 2011, www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx
which restores service
If Problem Management is implemented:
- The incident is closed since it has been resolved
- The Service Desk links the incident to an existing problem record or logs a new one and assigns it to the group responsible for the technology suspected to be at fault
- Once that group understands the root cause, they log a Requset For Change (RFC) to rectify the issue and they link the RFC to the Problem record(s) to be addressed
If Problem Management is not implemented:
- The incident's SLA clock is stopped
- The incident is assigned to the group responsible for the technology suspected to be at fault
- The group responsible for the technology determines if the situation warrants a change and either logs an RFC and links it to the incident -or- closes the incident
If the change would cause the workaround to fail, thus generating an Incident, the change implementation work must include the removal of the workaround to avoid causing an incident.

The advantage of this approach is that it removes the sense of urgency of implementing a change, thus enabling it to be properly tested and scheduled when it is least disruptive to the business. It can also leverage a release to address multiple issues in one change (e.g. problems, changes for enhancements, maintenance, patches).

2. Incident without a workaround requiring a change

The Service Desk is unable to resolve the incident therefore it escalates
(ITIL® Service Operation) An activity that obtains additional resources when these are needed to meet service level targets or customer expectations. Escalation may be needed within any IT service management process, but is most commonly associated with incident management, problem management and the management of customer complaints. There are two types of escalation: functional escalation and hierarchic escalation.
Source: ITIL® Glossary and abbreviations, 2011, www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx
the incident (i.e. assigns it) to the group responsible for the technology that appears to be at fault
That group attempts to resolve the incident and determines that a change is required therefore they log an RFC and links it to the incident and initiates emergency change process if required
Once the RFC is implemented the incident is closed.

This of course provides an incentive to implement the change as soon as possible to avoid breaching the SLA. But the reality is that it may not be practical to implement an emergency change for a low impact incident. Therefore, the User can be contacted and asked if they can live with the situation until the change can be applied in the next release or maintenance window. If they accept, the incident SLA clock can then be stopped to avoid a breach (e.g. Stop-the-clock action). Once the change is implemented, the incident resolution can be confirmed with the user and the incident can be closed.

The advantage of this approach is that by managing User expectations IT avoids breaching its SLA.

Related:

Category:

Plugin disabled

Plugin footnotearea cannot be executed.

<HR>