Incident Management - Logging
All incidents must be fully logged and date/time stamped, regardless of whether they are raised through a Service Desk telephone call or whether automatically detected via an event alert.
Note: If Service Desk and/or support staff visit the customers to deal with one incident, they may be asked to deal with further incidents 'while they are there'. It is important that if this is done, a separate Incident Record is logged for each additional incident handled - to ensure that a historical record is kept and credit is given for the work undertaken.
All relevant information relating to the nature of the incident must be logged so that a full historical record is maintained - and so that if the incident has to be referred to other support group(s), they will have all relevant information to hand to assist them.
The information needed for each incident is likely to include:
- Unique reference number
- Incident categorization (often broken down into between two and four levels of sub-categories)
- Incident urgency
- Incident impact
- Incident prioritization
- Date/time recorded
- Name/ID of the person and/or group recording the incident
- Method of notification (telephone, automatic, e-mail, in person, etc.)
- Name/department/phone/location of user
- Call-back method (telephone, mail, etc.)
- Description of symptoms
- Incident status (active, waiting, closed, etc.)
- Related CI
- Support group/person to which the incident is allocated
- Related problem/Known Error
- Activities undertaken to resolve the incident
- Resolution date and time
- Closure category
- Closure date and time.
If the Service Desk does not work 24/7 and responsibility for first-line incident logging and handling passes to another group, such as IT Operations or Network Support, out of Service Desk hours, then these staff need to be equally rigorous about logging of incident details. Full training and awareness needs to be provided to such staff on this issue.
Categorization
Part of the initial logging must be to allocate suitable incident categorization coding so that the exact type of the call is recorded. This will be important later when looking at incident types/frequencies to establish trends for use in Problem Management, Supplier Management and other ITSM activities.
Please note that the check for Service Requests in this process does not imply that Service Requests are incidents. This is simply recognition of the fact that Service Requests are sometimes incorrectly logged as incidents (e.g. a user incorrectly enters the request as an incident from the web interface). This check will detect any such requests and ensure that they are passed to the Request Fulfilment process.
Multi-level categorization is available in most tools - usually to three or four levels of granularity. All organizations are unique and it is therefore difficult to give generic guidance on the categories an organization should use, particularly at the lower levels. However, there is a technique that can be used to assist an organization to achieve a correct and complete set of categories - if they are starting from scratch! The steps involve:
- Hold a brainstorming session among the relevant support groups, involving the SD Supervisor and Incident and Problem Managers.
- Use this session to decide the 'best guess' top-level categories - and include an 'other' category. Set up the relevant logging tools to use these categories for a trial period.
- Use the categories for a short trial period (long enough for several hundred incidents to fall into each category, but not too long that an analysis will take too long to perform).
- Perform an analysis of the incidents logged during the trial period. The number of incidents logged in each higher-level category will confirm whether the categories are worth having - and a more detailed analysis of the 'other' category should allow identification of any additional higherlevel categories that will be needed.
- A breakdown analysis of the incidents within each higher-level category should be used to decide the lower-level categories that will be required.
- Review and repeat these activities after a further period - of, say, one to three months - and again regularly to ensure that they remain relevant. Be aware that any significant changes to categorization may cause some difficulties for incident trending or management reporting - so they should be stabilized unless changes are genuinely required.
If an existing categorization scheme is in use, but it is not thought to be working satisfactorily, the basic idea of the technique suggested above can be used to review and amend the existing scheme.
NOTE: Sometimes the details available at the time an incident is logged may be incomplete, misleading or incorrect. It is therefore important that the categorization of the incident is checked, and updated if necessary, at call closure time (in a separate closure categorization field, so as not to corrupt the original categorization)
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 |