VMware Monitor
Incident and Problem Management - Closing an incident
When a potential resolution has been identified, this should be applied and tested. The specific actions to be undertaken and the people who will be involved in taking the recovery actions may vary, depending upon the nature of the fault - but could involve:
- Asking the user to undertake directed activities on their own desk top or remote equipment
- The Service Desk implementing the resolution either centrally (say, rebooting a server) or remotely using software to take control of the user's desktop to diagnose and implement a resolution
- Specialist support groups being asked to implement specific recovery actions (e.g. Network Support reconfiguring a router)
- A third-party supplier or maintainer being asked to resolve the fault.
Even when a resolution has been found, sufficient testing must be performed to ensure that recovery action is complete and that the service has been fully restored to the user(s).
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, incidents (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 incidents or those involving VIPs, etc.
Rules for re-opening incidents
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.Other ITIL Processes
In order to have a good understanding of ITIL and the importance of configuration management, we first define what ITIL is: ITIL is literally a collection of documentation.
This documentation can help IT organizations implement the best practices. The documentation grows and grows as more successful techniques are documented and guidelines established for what can make others successful. The latest ITIL resources are published by the UK Office of Government Commerce (OGC).
Integrated service delivery refers to the need for Configuration Management, Change Management, Incident Management, Problem Management and Release Management processes that are linked together in a meaningful manner. For example, the process of releasing components to the live environment (the domain of Release Management) is also an issue for Configuration Management and Change Management whilst the Service Desk is primarily responsible for liaison between IT providers and the Users of services. This section highlights the links and the principal relationships between all the Service Management and other infrastructure management processes.
ITIL processes fall under Operational Layer or Tactical Layer, as follows:
| Operational Layer: | Configuration Management - Service Desk Management - Incident & Problem Management - Change Management - Release Management |
| Tactical Layer: | Service Level Management - Availability Management - Capacity Management - Continuity Management - Financial Management |