Rules for re-opening incidents

Incident Closure

The Service Desk should check that the incident is fully resolved and that the users are satisfied and willing to agree the incident can be closed. The Service Desk should also check the following:

• Closure categorization. Check and confirm that the initial incident categorization was correct or, where the categorization subsequently turned out to be incorrect, update the record so that a correct closure categorization is recorded for the incident – seeking advise or guidance from the resolving group(s) as necessary.
• User satisfaction survey. Carry out a user satisfaction call-back or e-mail survey for the agreed percentage of incidents.
• Incident documentation. Chase any outstanding details and ensure that the Incident Record is fully documented so that a full historic record at a sufficient level of detail is complete.
• Ongoing or recurring problem? Determine (in conjunction with resolver groups) whether it is likely that the incident could recur and decide whether any preventive action is necessary to avoid this. In conjunction with Problem Management, raise a Problem Record in all such cases so that preventive action is initiated.
• Formal closure. Formally close the Incident Record.

Note: Some organizations may chose to utilize an automatic closure period on specific, or even all, incident s (e.g. incident will be automatically closed after two working days if no further contact is made by the user). Where this approach is to be considered, it must first be fully discussed and agreed with the users – and widely publicized so that all users and IT staff are aware of this. It may be inappropriate to use this method for certain types of incidents – such as major incident s or those involving VIPs, etc.

Despite all adequate care, there will be occasions when incidents recur even though they have been formally closed. Because of such cases, it is wise to have pre-defined rules about if and when an incident can be re-opened. It might make sense, for example, to agree that if the incident recurs within one working day then it can be re-opened – but that beyond this point a new incident must be raised, but linked to the previous incident(s).

The exact time threshold /rules may vary between individual organizations – but clear rules should be agreed and documented and guidance given to all Service Desk staff so that uniformity is applied.

4.2.6 Triggers, input and output/inter-process interfaces

Incidents can be triggered in many ways. The most common route is when a user rings the Service Desk or completes a web-based incident-logging screen, but increasingly incidents are raised automatically via Event Management tools. Technical staff may notice potential failure s and raise an incident, or ask the Service Desk to do so, so that the fault can be addressed. Some incidents may also arise at the initiation of supplier s – who may send some form of notification of a potential or actual difficulty that needs attention.

The interfaces with Incident Management include:

• Problem Management: Incident Management forms part of the overall process of dealing with problem s in the organization. Incidents are often caused by underlying problems, which must be solved to prevent the incident from recurring. Incident Management provides a point where these are reported.
• Configuration Management provides the data used to identify and progress incidents. One of the uses of the CMS is to identify faulty equipment and to assess the impact of an incident. It is also used to identify the users affected by potential problems. The CMS also contains information about which categories of incident should be assigned to which support group. In turn, Incident Management can maintain the status of faulty CIs. It can also assist Configuration Management to audit the infrastructure when working to resolve an incident.
• Change Management: Where a change is required to implement a workaround or resolution, this will need to be logged as an RFC and progressed through Change Management. In turn, Incident Management is able to detect and resolve incidents that arise from failed changes.
• Capacity Management: Incident Management provides a trigger for performance monitoring where there appears to be a performance problem. Capacity Management may develop workarounds for incidents.
• Availability Management; will use Incident Management data to determine the availability of IT service s and look at where the incident lifecycle can be improved.
• SLM: The ability to resolve incidents in a specified time is a key part of delivering an agreed level of service. Incident Management enables SLM to define measurable responses to service disruptions. It also provides reports that enable SLM to review SLAs objectively and regularly. In particular, Incident Management is able to assist in defining where services are at their weakest, so that SLM can define actions as part of the Service Improvement Programme (SIP) – please see the Continual Service Improvement publication for more details. SLM defines the acceptable levels of service within which Incident Management works, including:
• Incident response time s
• Impact definitions
• Target fix times
• Service definitions, which are mapped to users
• Rules for requesting services
• Expectations for providing feedback to user s.

Дата добавления: 2014-12-23