¿Qué es la gestión de incidentes ITSM?

Qué es un incidente de TI?

Un incidente de TI es cualquier interrupción en los servicios de TI de una organización que afecta cualquier cosa, desde un solo usuario hasta toda la empresa. En pocas palabras, un incidente es cualquier cosa que interrumpe la continuidad del negocio.

¿Qué es la gestión de incidentes de TI?

La gestión de incidentes es el proceso de gestionar las interrupciones del servicio de TI y restaurar los servicios dentro de los acuerdos de nivel de servicio (SLA) acordados.

El alcance de la gestión de incidentes comienza con un usuario final que informa un problema y termina con un miembro del equipo de la mesa servicio que resuelve ese problema.

Las etapas en la gestión de incidentes

Con una gestión de incidentes adecuada, recopilar información sobre los incidentes es más fácil y menos caótico ya que no es necesario enviar y recibir cientos de correos electrónicos para hacerlo. Los equipos de la mesa de servicio pueden publicar formularios en el portal de autoservicio del usuario para garantizar que se recopile toda la información relevante al momento de crear el ticket.

La siguiente etapa en la gestión de incidentes es la categorización y priorización de incidentes. Esto no solo ayuda a ordenar los tickets entrantes, sino que también garantiza que los tickets sean asignados a los técnicos más calificados en el tema. La categorización de incidentes también ayuda a que el sistema de mesa de servicio aplique los SLA más apropiados a los incidentes y a comunicar esas prioridades a los usuarios finales. Una vez que se clasifica y prioriza un incidente, los técnicos pueden diagnosticar el incidente y proporcionar una resolución al usuario final.

El proceso de gestión de incidentes, cuando se habilitan las automatizaciones relevantes, permite a los equipos de la mesa de servicio vigilar el cumplimiento del SLA y enviar notificaciones a los técnicos en caso de posibles infracciones del SLA. Los técnicos también pueden escalar las violaciones del SLA al automatizar el escalamiento, según corresponda al incidente. Después de diagnosticar el problema, el técnico ofrece al usuario final una resolución, que el usuario final puede validar. Este proceso de varios pasos garantiza que cualquier problema de TI que afecte la continuidad del negocio se resuelva lo antes posible.

Cómo clasificar los incidentes de TI

Los incidentes en un entorno de TI se pueden clasificar de varias maneras diferentes. Algunos factores que influyen en la categorización de incidentes incluyen la urgencia del incidente y la gravedad de su impacto en los usuarios o en el negocio en general. Clasificar y categorizar los incidentes de TI ayuda a identificar y asignar los incidentes al técnico adecuado, lo cual ahorra tiempo y esfuerzo. Por ejemplo, los incidentes se pueden clasificar como incidentes mayores o menores en función de su impacto en el negocio y su urgencia. Por lo general, los incidentes mayores son los que afectan los servicios críticos para el negocio (afectan a toda la organización) y que necesitan soluciones inmediatas. Los incidentes menores generalmente afectan a un solo usuario o a un departamento, y es posible que ya tengan una resolución documentada.

¿Qué sucede si no ha implementado un modelo de gestión de incidentes de TI?

La gestión de incidentes cubre todos los aspectos de un incidente a lo largo de su ciclo de vida. Acelera el proceso de resolución y hace que la gestión de tickets sea transparente. Sin un modelo de gestión de incidentes, manejar los tickets puede ser toda una molestia. Algunos de los principales problemas que pueden surgir incluyen:

• Falta de transparencia sobre el estado del ticket y los plazos previstos para los usuarios finales.
• No hay un registro adecuado de incidentes pasados.
• Incapacidad para documentar soluciones para los problemas comunes o repetidos.
• Mayor riesgo de interrupciones del negocio, particularmente con incidentes mayores.
• Tiempos de resolución más largos
• Incapacidad para informar.
• Menor satisfacción del cliente

¿Quién utiliza la gestión de incidentes de TI?

Las prácticas de gestión de incidentes son ampliamente utilizadas por los equipos de la mesa de servicio de TI. Las mesas de servicio suelen ser el único punto de contacto para que los usuarios finales reporten los problemas a los equipos de gestión de TI.

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

• Paso 1 : Registro del incidente.
• Paso 2 : Categorización del incidente.
• Paso 3 : Priorización del incidente.
• Paso 4 : Asignación del incidente.
• Paso 5 : Creación y gestión de tareas.
• Paso 6 : Gestión y escalamiento del SLA.
• Paso 7 : Resolución del incidente.
• Paso 8 : Cierre del incidente.

Estos procesos pueden ser simples o complejos según el tipo de incidente; también pueden incluir varios flujos de trabajo y tareas además del proceso básico descrito anteriormente.

Registro del incidente

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.

Categorización del incidente

Los incidentes se pueden clasificar y subcategorizar en función del área de TI o negocio en la que el incidente causa una interrupción, como la red, el hardware, etc.

Priorización del incidente

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 denota el grado de daño que el problema causará al usuario o empresa. La urgencia de un incidente indica el tiempo dentro del cual se debe resolver el incidente. Según la prioridad, los incidentes se pueden clasificar como:

• Crítico
• Alto
• Medio
• Bajo

Enrutamiento y asignación de incidentes

Una vez que se clasifica y prioriza el incidente, se asigna automáticamente a un técnico con la experiencia relevante.

Creación y gestión de tareas

Según la complejidad del incidente, se puede desglosar en sub-actividades o tareas. Por lo general, las tareas se crean cuando se requiere la contribución de múltiples técnicos de varios departamentos para resolver el incidente.

Gestión y escalamiento del SLA

Mientras se procesa el incidente, el técnico debe asegurarse de no infringir el SLA. Un SLA es el tiempo aceptable dentro del cual se debe responder (SLA de respuesta) o resolver (SLA de resolución) un incidente. Los SLA se pueden asignar a incidentes en función de sus parámetros, como categoría, solicitante, impacto, urgencia, etc. En los casos en que está a punto de infringirse o ya se ha infringido el SLA, el incidente se puede escalar funcionalmente o jerárquicamente para garantizar que se resuelva lo antes posible.

Resolución del incidente

Un incidente se considera resuelto cuando el técnico ha encontrado una solución temporal o una solución permanente para el problema.

Cierre del incidente

Un incidente se puede cerrar una vez que se resuelve el problema y el usuario acepta la resolución y está satisfecho con ella.

Revisión posterior al incidente

Después de que se haya cerrado un incidente, se recomienda documentar todas las conclusiones de ese incidente. Esto ayuda a preparar mejor a los equipos para futuros incidentes y crea un proceso de gestión de incidentes más eficiente. El proceso de revisión posterior al incidente puede desglosarse en varios aspectos, como se muestra a continuación, y es particularmente útil para incidentes mayores.

Evaluación interna

Identificación del incidente

• ¿Quién detectó el incidente y cómo lo hizo?
• ¿Qué tan pronto se detectó el incidente después de que ocurrió?
• ¿El incidente pudo haber sido identificado antes?
• ¿Alguna herramienta o tecnología podría haber ayudado en la detección rápida o preventiva del incidente?

Flujo de información y comunicación:

• ¿Qué tan rápido se informó a las partes interesadas sobre el incidente?
• ¿Qué canal se utilizó para enviar notificaciones?
• ¿Se actualizó oportunamente a todos los interesados relevantes con la información más reciente?
• ¿Qué tan fácil fue comunicarse con los usuarios finales para recopilar información y mantenerlos informados sobre el estado del ticket?

Estructura

• ¿Cómo se estructuró inicialmente el equipo de respuesta a incidentes?
• ¿Se cumplió esta estructura durante todo el ciclo de vida de gestión de incidentes? Si no fue así, ¿por qué? ¿Qué cambios tuvieron que hacerse a la estructura?
• ¿Se cumplió esta estructura durante todo el ciclo de vida de gestión de incidentes? Si no fue así, ¿por qué? ¿Qué cambios tuvieron que hacerse a la estructura?

Utilización de recursos

• ¿Qué recursos se emplearon para manejar el incidente?
• ¿Estos recursos se utilizaron a su capacidad óptima?
• ¿Qué tan rápido se movilizaron los recursos para manejar el incidente?
• ¿Se podría mejorar la utilización de los recursos en el futuro?

Proceso

• ¿Cuán de cerca se siguió el proceso de gestión de incidentes definido?
• ¿Hubo alguna desviación en el flujo de trabajo y el proceso de gestión de incidentes?
• ¿Se cumplieron los SLA del incidente? Si no fue así, ¿cuáles SLA se incumplieron? ¿Por qué?
• ¿Se monitoreó de manera adecuada el proceso que se siguió para manejar el incidente?
• ¿Se podría mejorar el proceso para hacerlo más eficiente? Si es así, ¿cómo?

Informes

• ¿Se generaron informes para analizar cómo se manejó el incidente?
• ¿Qué parámetros se incluyeron en los informes?
• ¿Qué partes del ciclo de vida del incidente fueron analizadas?
• ¿Se pueden hacer mejoras? Si es así, ¿cómo?

Evaluación externa - Encuestas a usuarios finales

Además de los factores anteriores, también se deben evaluar algunos factores orientados al usuario final. A este efecto, se realiza una encuesta posterior al cierre para recopilar comentarios de los usuarios finales afectados por el incidente. Esta encuesta se debe usar para obtener información en algunas áreas clave, como:

• ¿Qué tan fácil o difícil fue para el usuario final reportar un incidente?
• ¿La primera respuesta del equipo de TI fue rápida y oportuna?
• ¿El incidente se resolvió de manera oportuna?
• ¿Qué tan satisfecho está el usuario final con la resolución?

Si bien cada organización puede tener sus propios roles y responsabilidades personalizados, a continuación se detallan algunos de los roles más comunes en la gestión de incidentes de TI.

Usuario final / usuario / solicitante

Esta es la parte interesada que generalmente experimenta una interrupción en el servicio y emite un ticket de incidente para iniciar el proceso de gestión de incidentes.

Mesa de servicio de nivel 1

Este es el primer punto de contacto para los solicitantes que desean presentar una solicitud o un ticket de incidente. La mesa de servicio de nivel 1 generalmente consiste en técnicos que tienen un conocimiento práctico de los problemas más comunes que pueden ocurrir en un entorno de TI, incluidos los restablecimientos de contraseña y los problemas de Wi-‍Fi.

Mesa de servicio de nivel 2

Esta mesa de servicio está compuesta por técnicos con conocimientos avanzados en gestión de incidentes. Por lo general, reciben solicitudes más complejas de los usuarios finales; también reciben solicitudes escaladas desde el Nivel 1.

Mesa de servicio de nivel 3 (y superior)

Este nivel generalmente está compuesto por técnicos especialistas que tienen un conocimiento avanzado de dominios particulares en la infraestructura de TI. Por ejemplo, los técnicos de mantenimiento de hardware y soporte de servidores se especializan en campos muy específicos.

Gestor de incidentes

Esta parte interesada juega un papel clave en el proceso de gestión de incidentes dado que monitorea cuán efectivo es el proceso, recomienda mejoras y garantiza que se siga el debido proceso, entre otras responsabilidades.

Dueño del proceso

Esta parte interesada es propietaria del proceso para gestionar los incidentes. También analiza, modifica y mejora el proceso para garantizar que sirva mejor al interés de la organización.

Cada rol tiene responsabilidades únicas, como se muestra a continuación.

Usuario final / usuario / solicitante:

• Contactar a la mesa de servicio para presentar una nueva solicitud de incidente.
• Dar seguimiento a una solicitud existente.
• Comunicar claramente toda la información requerida a los técnicos.
• Reconocer la restauración del servicio y la finalización del ticket.
• Responder a las encuestas de seguimiento después de la resolución del ticket completando el ciclo de retroalimentación.

Mesa de ayuda de nivel 1:

• Registrar todas las solicitudes de incidentes entrantes con parámetros apropiados como categoría, urgencia y prioridad.
• Asignar tickets a los técnicos.
• Analizar y resolver un incidente para restaurar el servicio.
• Escalar los incidentes no resueltos a la mesa de servicio de Nivel 2.
• Reunir toda la información requerida de los solicitantes y enviarles actualizaciones periódicas sobre el estado de su solicitud.
• Actuar como un punto de contacto para los solicitantes y, si es necesario, coordinar entre la mesa de soporte de Nivel 2 y los solicitantes.
• Verificar la resolución con el usuario final y recopilar comentarios.

Mesa de servicio de nivel 2 y 3:

• Realizar el diagnóstico de incidentes.
• Documentar los pasos seguidos para resolver el incidente y enviar los artículos de la base de conocimiento.
• Identificar cuándo un incidente es un problema y convertir el ticket de incidente en un ticket de problema.
• Si se resuelve el incidente, confirmar su resolución con el usuario final.
• Si el incidente no se resuelve, escalar a la mesa de servicio de Nivel 3.
• Si no se resuelve, enviar el incidente al equipo de gestión de problemas de TI para identificar el problema subyacente o los proveedores externos, según corresponda.
• Proporcionar experiencia en la materia.

Gestor de incidentes:

• Servir como punto de contacto para todos los incidentes mayores.
• Planificar y facilitar todas las actividades involucradas en el proceso de gestión de incidentes.
• Asegurarse de que se siga el proceso correcto para todos los tickets y corregir cualquier desviación.
• Coordinar y comunicarse con el propietario del proceso.
• Asegurarse de que se cumplan los SLA.
• Identificar los incidentes que se deben revisar y realizar la revisión.

Dueño del proceso:

• Asumir la responsabilidad del proceso general de gestión de incidentes.
• Definir indicadores clave de rendimiento (KPI) y alinearlos con factores críticos de éxito (CSF).
• Revisar los KPI y asegurarse de que cumplan los objetivos comerciales y los CSF.
• Diseñar, documentar, revisar y mejorar procesos.
• Establecer una mejora continua del servicio (CSI) en la que se revisen y mejoren los procedimientos, políticas, roles, tecnología y otros aspectos del proceso de gestión de incidentes.
• Mantenerse informado sobre las mejores prácticas de la industria e incorporarlas al proceso de gestión de incidentes.

• Ofrecer múltiples modos para la creación de tickets, incluso a través de un correo electrónico, una llamada telefónica o un portal de autoservicio.
• Publicar formularios de incidentes de TI personalizados orientados al negocio para recopilar información de forma efectiva
• Clasificar y priorizar automáticamente los incidentes de TI según los criterios del ticket.
• Asociar los SLA con incidentes de TI en función de parámetros de tickets como la prioridad.
• Si todos los técnicos tienen los mismos niveles de habilidad, asignar automáticamente los tickets a los técnicos según algoritmos como el balanceo de carga y round robin..
• Asociar datos de activos de TI, problemas de TI y cambios de TI con tickets de incidentes de TI.
• Asegurarse de que los incidentes se cierren solo después de proporcionar una resolución adecuada confirmando con el usuario final y aplicando los códigos de cierre apropiados.
• Configurar un proceso de comunicación personalizado con el usuario final para cada paso en el ciclo de vida del incidente de TI
• Crear y mantener una base de conocimiento con soluciones apropiadas
• Proporcionar acceso basado en roles a los usuarios finales y técnicos en función de la complejidad de las soluciones.
• Manejar los incidentes importantes creando flujos de trabajo únicos.