This is an excerpt, you will find more detailed descriptions in the book.
The IT environment is the most important thing we have in an IT organization. It is where IT services are produced and benefit is supplied to the business. If the IT environment was to stop functioning, the IT service would come to a halt and the business would then derive no benefit from the IT organization.
It is with this in mind that the IT organization needs a fast and well-aligned process to restore errors which arise in the IT environment. If an element that the IT organization has promised in agreements with the business is not functioning, then there is nothing more important at that precise moment.
A fundamental prerequisite for the Incident Management process to function is that clear agreements are in place. That there is absolute clarity about what should function and what should not. Otherwise there is a risk of the process becoming clogged with issues that are not directly linked to an error in the IT environment. The IT organization then grows accustomed to a constant flow of incidents with the result that the link to incidents being important disappears.
An incident is defined as:
” An unplanned interruption or a deterioration in the quality of an IT service. An error in a component in the IT environment that does not directly affect the quality of the delivery (for example, a hard drive with redundancy) should also be classified as an incident.”
The main purpose of the Incident Management process is to restore the agreed service level as quickly as possible and to reduce the negative consequences for the business. This means that if the IT organization is not able to rectify the error directly, a temporary solution (workaround) which restores the functionality for the user can be sufficient. The purpose also means that an incident should as far as possible be rectified in such a way that the business suffers no further negative effects.
The purpose of Incident Management is achieved through:
- Ensuring that standardized methods and procedures are used
- Making incidents visible internally and in the business
- Acting professionally through communicating and resolving incidents rapidly when they arise
- Starting out from the business’s priorities when prioritizing incidents
The word incident means ”unexpected, disruptive event”. Incident Management is consequently ”management of unexpected, disruptive events”. This means that expected, disruptive events are not included in the Incident Management process.
To set a clear limit on which disturbances can be expected and which cannot, this is regulated in documentation which is produced in the Release Management process. Errors detected during the testing of releases that are deployed should be documented as known errors. This documentation of known errors is subsequently used as a definition of what is unexpected or expected. This means that if an error registered by a user is recorded in the list of known errors, the issue should not be regarded as an incident. The difference between types of issue and how these are to be managed is described in more detail in the chapter about the Service Desk function.
All incidents in the IT environment, independently of who discovers them, are included in the incident process. All incidents that affect the delivery of IT services, regardless of who produces the service, must be included in the incident process. This means that an error which arises at a supplier, which in turn affects the delivery of IT services, should also be regarded as an incident.
The following activities are part of the Incident Management process. If the issue arrives at Service Desk via a user, the first two activities (registration and categorization) are managed in the Request Fulfilment process.