What is incident planning
Flow for incident planning.
The steps to be followed to correctly plan and manage an
incident are shown in the process described below. This flow follows the ITIL
definitions in their Service operations book and is used by many software
vendors when designing the processes in their tools.
1. Incident
identification : all elements of the service must be monitored to detect an
incident as soon as it occurs. Ideally, the incident should be detected before
affecting service users.
2. Incident
record : it must be recorded and identified with a unique code that allows it
to be referenced in the future. The incident record must b2b sales include the exact date
and time. These dates will be used to check the degree of compliance with the
different SLAs. In addition, all relevant information must be included to allow
it to be managed in the most efficient way possible.
3. Categorization
of the incident : assigning a specific category to the incident allows, later,
to analyze statistics and trends in the provision of the service. Most tools
have different levels of granularity for certain categories.
A high number of categories will increase the chances of
errors in the recording of incidents, while a very limited number will prevent
proper prioritization:
1. Prioritization
of the incident : this stage is one of the most important in the planning of
incidents, since the consumption of the available resources to recover the
service depends on it. Prioritization is usually assigned taking into account
the urgency of the incident and the impact it is causing. The urgency is
defined by how quickly the business needs the incident to be closed, while the
impact is usually determined by the number of users affected.
2. Initial
diagnosis : generally, the person, registering the incidence, is able to carry
out an initial analysis of what may be the cause of the problem based on the
information that is being provided. If possible, the issue will be resolved at
this point.
3. Escalation
: in the event that the incident could not be resolved in the first instance,
it will be necessary to escalate it. Escalation can be functional, when it is
directed to a department with specific responsibility for a series of elements,
or hierarchical when the incident has a special relevance and must be
communicated to the service managers.
4. Investigation
and diagnosis : when it has been confirmed that it is an incident and it could
not be resolved by the first level of support, it is generally necessary to
carry out analysis to determine the cause of the problem and be able to find a
solution to it. The analyzes will be carried out in parallel between all the
groups involved to try to reduce the time of this stage as much as possible.
5. Resolution
: when a possible solution to the incident has been found, it must be tested.
The participants, in the resolution of the incident, will vary depending on
each case, but it will be normal to have the affected user, the first line of
support and the specialist groups that have participated in the diagnosis.
6. Closure
of the incident : the first support line is in charge of verifying that the
incident is fully resolved. It also confirms that the assigned category is
correct, and also obtains information on the quality of the service perceived
by the user, via surveys, and collects all the information associated with the
incident so that it can be incorporated into the service knowledge database.
Prioritization of incidents.
The characteristics that define an incident when
prioritizing it are its urgency and its impact. Urgency can be defined as the
measure that indicates how quickly an incident must be resolved.
The impact can be defined as the potential damage that the
incident can cause before its resolution. In defining both the urgency of an
incident and its impact, IT service designers must work closely with the
business to establish a matrix that is agreed upon by both. The definitions of
urgency and impact depend on the type of company and the sector to which they
are dedicated.
