Cuando un servicio deja de funcionar o baja su rendimiento puede significar pérdidas en las empresas, un estudio reciente de Ponemon Institute demuestra que el 54% de los líderes en TI no saben si sus herramientas funcionan sus herramientas a pesar de registrar gastos anuales de 18 millones de dólares. 

De esta forma los profesionales en proceso de aprendizaje pueden obtener una gran ventaja, no necesariamente aprendiendo cómo funcionan cuantiosas herramientas, sino aprendiendo a gestionar incidentes de manera protocolar y ordenada. 

La documentación relacionada a este apartado es bastante extensa, de esta forma debo aclararte que estás frente a un gran desafío en tu proceso de aprendizaje, pero con la gran recompensa de volverte aquello que toda organización de TI busca actualmente: Un profesional capaz de responder de manera correcta y que minimice las pérdidas frente los incidentes con las tecnologías de la información y comunicación. 

Lo primero que debe quedar claro es que no se espera que la gestión de incidentes realice un análisis de causa raíz para identificar por qué ocurrió un incidente. Más bien, el enfoque está en hacer lo que sea necesario para restaurar el servicio. 

Normalmente esto lleva a realizar una solución temporal para que los procesos de trabajo puedan continuar. Una herramienta importante en el diagnóstico de incidentes es la base de datos de errores conocida (KEDB), que se mantiene mediante la gestión de problemas. 

Esta base de datos permite identificar cualquier problema o error que haya causado incidentes en el pasado y proporciona información sobre cualquier solución alternativa que se haya realizado para continuar las actividades de la organización. 

Sin embargo esta base de datos, sumamente útil, es solo una herramienta más para lidiar con incidentes repetidos y permitir que continúen las actividades,para ser un profesional de valor se necesita conocer a detalle la gestión de incidentes ITIL. 


Definición de incidente en TI 

Podemos definir los incidentes en Tecnologías de la información como: cualquier interrupción en los servicios de TI de una organización que afecta cualquier elemento, desde un solo usuario o toda la empresa. De esta forma, un incidente es cualquier cosa que interrumpe la continuidad del negocio.

¿Qué es Gestión de incidentes en TI?

Se define como el proceso de gestionar las interrupciones de uno o varios servicios y restaurar el nivel de servicio acordado (SLA) La gestión de incidentes suele iniciar con un usuario final que informa de la interrupción o funcionamiento deficiente y con un profesional TIC que brinda la solución temporal. 

Etapas más importantes de la gestión de incidentes 

Las siguientes etapas de la gestión de incidentes, ayuda enormemente a organizar las peticiones y plantear soluciones de manera ordenada, sin una gran cantidad de peticiones vía correo electrónico o métodos más informales como whatsapp. 

Publicación de formularios en el portal de autoservicio

Los equipos de la mesa de ayuda (Helpdesk) pueden publicar formularios en el portal de autoservicio del usuario para garantizar que toda la información relevante se recopile en el momento de la creación del ticket.

Categorización y priorización de incidentes

Categorizar y ordenar los problemas según su prioridad no solo ayuda a ordenar los tickets entrantes, también permite que los tickets sean enviados a los técnicos más calificados para trabajar en un incidente específico.

Ofrecer soluciones al usuario final

La parte final de todo proceso de gestión de incidentes es que el responsable otorgue una solución, sea temporal o no, al usuario final, esta resolución puede estar acompañada de afirmar el correcto cumplimiento de SLA. 

El ciclo de vida ITIL para la gestión de incidentes

El proceso de gestión de incidentes se puede resumir de la siguiente manera:

Paso 1: registro de incidentes

Se puede registrar un incidente mediante llamadas telefónicas, correos electrónicos, SMS, formularios web publicados en el portal de autoservicio o mediante mensajes de chat en vivo, es el paso inicial del proceso y se busca que se realice de forma detallada y rápida para dar una solución adecuada sin retrasar aún más el regreso a las actividades. 

Paso 2: categorización de incidentes.

Los incidentes pueden dividirse en categorías y sub categorías según el área de TI, el área del negocio en el que ocurre el incidente o la causa de la interrupción: redes, hardware o software.

Paso 3: priorización de incidentes.

La prioridad de un incidente se puede determinar en función de su impacto y urgencia utilizando una matriz de prioridad. El impacto de un incidente está relacionado al grado de daño que el problema puede causar al usuario y a la empresa. La urgencia de un incidente indica el tiempo dentro del cual el incidente debe resolverse. Según la prioridad, los incidentes se pueden clasificar como:

  • Crítico 
  • Alto
  • Medio
  • Bajo

Paso 4: Diagnóstico inicial 

Se debe determinar si el incidente puede ser solucionado inmediatamente por un técnico o requiere de otros miembros del área de TI. Por ello el criterio del primer analista es importante. 

Tener un alto nivel de resolución en este punto es una excelente práctica, recuerde que para el diagnóstico inicial son importantes las habilidades blandas ya que el primer contacto es memorable para el usuario, los trabajadores o involucrados en un proceso quieren respuestas concretas y si no se las da o complica más la situación usted está dando un mal servicio. 

Paso 5: Creación y gestión de tareas

Según la complejidad del incidente, los profesionales TIC pueden dividir el trabajo en diferentes actividades. Este proceso es necesario cuando una solución, temporal o permanente, requiere la contribución de diferentes técnicos. 

Paso 6: gestión y escalado de SLA

SLA es un acuerdo de calidad de servicio, un contrato donde se describe la prioridad que debe tener ciertas interrupciones y tiempos prudentes de resolución, exceder los tiempos establecidos en este documento proyecta una imagen negativa del profesional, incluso podría generar penalizaciones.

Mientras se gestiona y responde al incidente, el técnico debe procurar no infringir el SLA. Estos acuerdos pueden asignarse a incidentes en función a parámetros como: categoría, solicitante, impacto, urgencia, etc. 

Paso 7: resolución de incidentes

Un incidente se considera resuelto cuando el profesional TIC responsable ha encontrado una solución temporal o una solución permanente para el problema. 

Paso 8: cierre del incidente.

Un incidente se considera cerrado cuando la interrupción fue resuelta, el usuario reconoce la resolución y está satisfecho con ella. Recordemos que quien experimenta y determinar si el incidente fue cerrado es el usuario final del servicio. 

Gestión de incidentes en ITIL V3

Estos 8 pasos, corresponden a la última versión: ITIL V4, por lo tanto representa una gestión moderna y correcta de la gestión de incidentes, a pesar de esto conocer a su antecesor puede darnos una idea del porqué se añadieron nuevas fases y otras fueron descartadas totalmente. 

ITIL V3 dividía la gestión de incidentes los siguientes puntos: 

  1. Detección
  2. Registro
  3. Categorización
  4. Priorización
  5. Diagnóstico inicial
  6. Escalado
  7. Investigación y diagnóstico
  8. Resolución
  9. Cierre

Como puedes ver comparten una gran similitud, con las siguientes diferencias: El término “escalado” es reemplazado por el de distribución de tareas, esto debido a que ya no se buscan delegar las tareas en la que un profesional requiere de ayuda, sino un trabajo colaborativo. 

A su vez se eliminó la investigación y diagnóstico, esto debido a que dicho proceso se sigue realizando después de cerrar el incidente porque la prioridad es dar soluciones a los usuarios para no interrumpir el flujo de trabajo y generar pérdidas a las empresas.

A su vez ITIL v4 incorporó la importancia de SLA como parte de este proceso, de esta forma podemos inferir,gracias a los cambios en las versiones de ITIL, qué aspectos priorizan las organizaciones modernas: 

  • Trabajo colaborativo. 
  • Rapidez en la resolución de incidentes.
  • Análisis constante, no reactivo.

La gestión de incidentes no acaba con el cierre del mismo

Ahora que conoces los pasos para gestionar los incidentes de ITIL estas mejor encaminado en cómo responder a las interrupciones del flujo de trabajo, sin importar su origen o las soluciones que puedas ofrecer, sin embargo el trabajo de un profesional en tecnología, no solo es reactivo sino preventivo, por lo tanto siempre se deben realizar análisis después de cualquier incidente.

La labor del profesional TIC no solo es prevenir estas interrupciones, sino ser capaz de realizar mejoras constantes, a través de las buenas prácticas de ITIL, el sistema de gobernanza de TI capaz de consolidar tanto una buena gestión de incidentes como la prevención continua de errores y con ello garantizar la continuidad de negocio. 

[button url=»https://ingenio.edu.pe/fundamentos-de-itil-4/» class=»» bg=»» hover_bg=»» size=»0px» color=»» radius=»0px» width=»0px» height=»0px» target=»_self»] Fundamento de ITIL V4 [/button]