Flujo de la gestión de incidencias

El objetivo principal en la gestión de incidencias es detectar cualquier anomalía en el normal funcionamiento de los sistemas de información, aumentar la base de conocimientos (knowledge base) mediante la correcta entrada y clasificación de las incidencias y reportar la misma al área con las capacidades necesarias para solventar el problema detectado cumpliendo con los acuerdos de servicio (SLAs) aplicables a cada caso.

Aunque, generalmente, se asocia el concepto de incidencia con el funcionamiento anómalo de una pieza de hardware o software, ITIL lo define como:

“Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de calidad del mismo”.

Esta definición implica que como incidencia se engloben no sólo anomalías del sistema sino peticiones tales como la solicitud de nuevas licencias o cambios en la gestión de los permisos almacenados en el directorio activo que modifican el funcionamiento estándar de los diferentes módulos.

Una correcta gestión de las incidencias conlleva los siguientes beneficios:

1. Mayor control en la monitorización del servicio.
2. Aumento de la productividad de los usuarios al disminuir los tiempos de indisponibilidad de los servicios.
3. Seguimiento del cumplimiento de los SLAs acordados.
4. Optimización de los recursos destinados al soporte del servicio.
5. Una base de conocimiento amplia y bien estructurada que permite identificar rápidamente las acciones a llevar a cabo a la hora de restaurar un servicio.

Como consecuencia de todo ello, se consigue mejorar la calidad del servicio ofrecido al usuario, aumentando su satisfacción.

El ciclo de vida de la gestión de incidencias incluye cuatro pasos fundamentales:

1. Registro: el primer paso necesario para una correcta gestión de las incidencias es el registro de las mismas en el sistema. El origen de las incidencias es diverso, pudiendo ser tanto comunicadas directamente por el usuario final como por alertas automáticas implantadas en el propio servicio. Ha de comprobarse que la incidencia no esté previamente registrada en el sistema ya que no es infrecuente que diferentes usuarios alerten en un intervalo de tiempo corto de la misma incidencia. El incidente ha de quedar registrado bajo un número identificativo único que será facilitado al comunicador de la misma para su posterior seguimiento. La información básica a incluir en este punto es la referida al comunicador de la incidencia, la hora, los servicios afectados y una descripción del problema identificado. Además, se incluirá toda la información que pueda facilitar el cierre de la incidencia, tanto la aportada por el comunicador como la información disponible en la base de datos de conocimiento. Finalmente, si el incidente puede estar afectando a otros usuarios se recomienda su notificación para que conozcan el estado del servicio y no se produzca un pico de llamadas al centro de gestión de incidencias.
2. Clasificación: conlleva las etapas de categorización, priorización y asignación de recursos. La incidencia es asignada a una categoría en función del tipo de incidente, los servicios afectados y el equipo responsable de su resolución. La prioridad dependerá del impacto que tenga la indisponibilidad del servicio en el negocio. Si el primer nivel no es capaz de resolver la incidencia, la asignará a los recursos que puedan cerrar la misma. Finalmente, se asocia un estado al registro y se estima el tiempo de resolución teniendo en cuenta los SLAs acordados para el servicio y la prioridad asignada.
3. Diagnóstico: en un primer momento, se consulta la base de conocimiento existente para encontrar referencias sobre incidencias similares que hayan sido resueltas en el pasado. Si el registro no es cerrado, se ha de seguir el protocolo de escalado establecido. Es necesario actualizar toda la información disponible sobre el incidente en cada uno de los estados por los que pase el mismo, de modo que los intervinientes en la resolución puedan contar con todo el detalle actualizado.
4. Resolución: una vez resuelto el incidente, se ha de recoger la confirmación por parte del usuario del correcto funcionamiento del servicio. Se actualizará la base de conocimiento para facilitar el cierre de una incidencia similar en el futuro, se reclasificará el incidente si es necesario y se cerrará.

KPIs gestión de incidencias

Tal y como define IT-processmap, empresa especialista en servicios ITIL, y los propios libros de ITIL, a continuación, se muestran ejemplos de KPIs que pueden ayudar a la hora de evaluar el desempeño en las diferentes etapas que, tal y como se indicaba en el apartado anterior, definen el proceso de gestión de incidencias.

Estos KPIs son:

KPIs gestión de problemas

Tal y como explica ITIL, la gestión de incidencias tiene como único objetivo el restablecimiento del normal funcionamiento del servicio en el menor plazo de tiempo posible, y por lo tanto no es tan importante analizar las causas que originan estas incidencias. Si un incidente sucede de manera recurrente o impacta fuertemente en las infraestructuras de TI, entonces se gestiona como un problema. Un problema es una causa subyacente y no identificada de una o varias incidencias aisladas con un impacto significativo.

KPIs que ayudan a optimizar el proceso de gestión de problemas son los siguientes: