El proceso de Gestión de Incidentes comprende el conjunto de tareas orientadas a registrar, analizar, resolver y restablecer las interrupciones de un servicio tecnológico.
Cada incidente atraviesa una serie de etapas denominadas ciclo de vida, que contempla el reporte del problema, el diagnóstico, la solución y la restitución de la prestación.
Para administrarlo eficientemente, es clave entender el funcionamiento de este ciclo que le aporta estructura al procedimiento, ya que de otra manera sería un flujo constante de solicitudes inconexas. En definitiva, este proceso ayuda a los equipos a organizarse, priorizar y actuar de forma coherente.
En este artículo, recorremos las fases de la Gestión de Incidentes y explicamos la ventaja de su formalización, su aporte a los equipos de IT en particular y a las empresas en general, su importancia para las operaciones informáticas y su implementación efectiva utilizando las mejores prácticas.
Puntos clave
- El proceso de Gestión de Incidentes incluye la detección, el registro, la clasificación, la priorización, la resolución, el cierre y la revisión de cada problema.
- Apresurarse o saltearse cualquier etapa del ciclo de vida -especialmente el registro y la revisión posterior- genera incidentes recurrentes que se acumulan con el tiempo.
- Cada fase tiene inputs, outputs y modos de fallos concretos: su comprensión marca la diferencia entre un service desk reactivo y uno estructurado.
- InvGate Service Management automatiza los pasos del proceso que son más propensos a errores -clasificación, priorización, seguimiento de los SLAs y escalamiento- y, además, no requiere el uso de código.
Prueba Gratis
Sí (30 días)
¿Qué es el ciclo de vida de la Gestión de Incidentes en ITIL?
El ciclo de vida de la Gestión de Incidentes en ITIL se refiere a la secuencia de tareas que sigue una organización para abordar los problemas, desde su detección hasta su cierre. Se trata de una manera de estructurar la identificación, categorización, priorización, resolución y revisión de dichos incidentes.
Ese ciclo define el modo en que el service desk registra las cuestiones mencionadas, las asigna para su solución y restablece los niveles normales del servicio.
Antes de profundizar en las etapas, cabe aclarar que un incidente se define como una interrupción o degradación no planificada de un servicio de IT. Mientras que un problema constituye la causa subyacente que genera uno o más incidentes.
El ciclo de vida que explicamos aquí se aplica a los incidentes: la fase de respuesta inmediata y su resolución. La Gestión de Problemas se lleva a cabo en paralelo, a menudo desencadenada por patrones descubiertos durante las revisiones de los incidentes, pero opera en plazos y objetivos distintos. Esta distinción es fundamental para establecer el alcance de cada etapa.
¿Por qué es importante el ciclo de vida de los incidentes?
Cuando los equipos trabajan sin un ciclo de vida de los incidentes, las consecuencias pueden ser las siguientes:
- Respuestas inconsistentes: diferentes agentes manejan el mismo incidente con enfoques diferentes. Esto imposibilita la mejora del proceso o la fijación de expectativas confiables.
- Incumplimientos de los SLAs (Service Level Agreement o Acuerdo de Nivel de Servicio): sin reglas de priorización ni desencadenantes claros para el escalamiento, los incidentes de alto impacto quedan en la misma fila que los de menos críticos.
- Falta de datos útiles: un registro deficiente y los cierres informales no permiten realizar un análisis significativo. Así, por caso, las cifras de MTTR (Mean Time To Repair o Tiempo Promedio de Reparación) no reflejan el verdadero escenario, los patrones suelen pasar desapercibidos y los incidentes se abordan como si fueran nuevos cada vez.
- Fallas repetidas: sin una revisión posterior, el ciclo no se cierra y resurgen las mismas causas raíz. En consecuencia, el equipo debe dedicar sus recursos a ofrecer respuestas, en vez de prevenir los incidentes.
Cabe aclarar que un ciclo de vida estructurado no elimina los incidentes, sino que los convierte en una oportunidad para reducir la ocurrencia de otros a futuro.
7 pasos en el proceso de Gestión de Incidentes en ITIL
El proceso de Gestión de Incidentes se asemeja a un flujo que comienza con el reporte y termina con su cierre tras la confirmación del usuario.
Aquí, cada etapa del ciclo de vida de la Gestión de Incidentes en ITIL.
1. Detección e identificación
El primer paso de las fases de la Gestión de Incidentes según ITIL es la identificación, el momento de detección y reporte.
Su descubrimiento se puede llevar a cabo a través de tres canales principales:
- Alertas automatizadas en el monitoreo: el sistema señala anomalías antes de que las noten los usuarios -por ejemplo, los tiempos de respuesta del servidor se disparan, un servicio deja de estar disponible, las tasas de error superan un umbral, etc.-.
- Informes de los individuos: la persona envía un ticket o llama al help desk por una falla.
- Observaciones directas del equipo de IT: un miembro del departamento identifica un problema durante las revisiones de rutina o mientras trabaja en una tarea relacionada.
La detección proactiva mediante un monitoreo siempre es preferible al enfoque reactivo a través de los reportes de los usuarios. Porque en ese caso el incidente ya los afecta desde hace algún tiempo.
En esta etapa también se debe confirmar que un incidente sea efectivamente tal -una interrupción no planificada del servicio- y no una solicitud, la cual sigue un flujo diferente.
2. Registro
Un ticket incompleto representa un riesgo. Cuando los agentes comienzan a investigar un incidente sin la información adecuada -quién lo reportó, qué servicio se vio afectado, cuándo comenzó, cuántos usuarios sufrieron consecuencias- dedican tiempo a recopilar datos que deberían haberse reunido en el momento de la recepción.
Por lo tanto, cada ticket tiene que incluir, como mínimo, lo siguiente:
- Quién lo reportó y cómo (portal, teléfono, correo electrónico, alerta automatizada).
- Qué servicio o activo fue afectado.
- Descripción del incidente (más allá del “no funciona”, aportar detalles específicos).
- Hora en que ocurrió o se reportó por primera vez.
- Impacto inicial estimado (un usuario, un equipo, un departamento o toda la organización).
La coherencia también es muy importante. Sobre esa base, hay que evitar el uso de terminología diferente para el mismo problema. Si un agente notifica una falla de VPN como “conectividad de la red” y otro como “acceso remoto”, los datos se fragmentan. En conclusión, resulta fundamental en esta fase el registro correcto para que todas las etapas posteriores -desde la categorización hasta el análisis posterior al incidente- sean confiables.
3. Categorización
La categorización en el proceso de Gestión de Incidentes se lleva a cabo durante la creación del ticket en base a la selección que hacen los usuarios en el portal de servicio, los formularios que completan y la estructura propia del catálogo.
El diseño de la prestación, las decisiones de los agentes y la organización del portal que guía a las personas al lugar indicado son claves para una categorización efectiva. Como consecuencia, el enrutamiento y la generación de reportes resultarán más confiables.
Por el contrario, cuando las categorías están mal diseñadas, los agentes perderán tiempo reclasificando los tickets, mientras que los datos de los informes serán poco útiles a lo largo del tiempo.
El objetivo consiste en crear categorías lo suficientemente detalladas como para facilitar el enrutamiento y el análisis de las tendencias, sin llegar a ser tan específicas de modo que los usuarios y los agentes las apliquen de manera inconsistente.
Categorías como “Hardware > Impresora”, “Software > Correo electrónico” o “Red > VPN” brindan suficiente contexto para dirigir los incidentes al grupo de soporte adecuado, al tiempo que permiten generar informes completos.
Una categorización precisa no solo facilita la asignación de los tickets, también ayuda a los gerentes del service desk a identificar problemas recurrentes, analizar tendencias y vincular los incidentes con las tareas particulares para la Gestión de Problemas.
Así, cuando los equipos categorizan los incidentes de manera consistente, los datos históricos se convierten en una fuente confiable para descubrir las causas raíz y las oportunidades de mejora del servicio.
InvGate Service Management ofrece la posibilidad de diseñar catálogos de servicios, formularios y categorías del portal que orienten a los usuarios hacia la clasificación correcta. Las reglas de enrutamiento automatizadas entonces utilizan esas categorías para asignar los incidentes al equipo adecuado, sin necesidad de una intervención manual.
4. Priorización
Considerando que no todos los incidentes revisten la misma importancia, si se abordan igual se incumplen los SLAs.
En efecto, cuando los equipos resuelven una fila por orden de llegada en lugar de tener en cuenta el impacto, los incidentes críticos quedan rezagados, generando el incumplimiento de los Acuerdos de Nivel de Servicio en los elementos de alta prioridad, a la vez que la urgencia pierde relevancia.
Para evitar este escenario, ITIL define la prioridad como el producto de dos variables:
- Urgencia: ¿Con qué rapidez debe resolverse esto? ¿El impacto aumenta con el tiempo?
- Impacto: ¿Cuántos usuarios, procesos o funciones del negocio se ven afectados?
En la práctica, esto se traduce en una matriz de prioridades: una tabla que asocia combinaciones de urgencia e impacto a niveles de prioridad predefinidos (de P1 a P4, o Crítico/Alto/Medio/Bajo), cada uno con un objetivo de SLA correspondiente.
La matriz de prioridades de ITIL implementa este modelo, definiendo qué significa cada celda en cuanto a tiempo de respuesta, escalamiento y requisitos de comunicación. Estrechamente relacionados son los niveles de gravedad de los incidentes, que algunas organizaciones gestionan como una dimensión paralela a la prioridad, especialmente en el caso de los que son críticos.
En cualquier caso, la prioridad debe ser visible para todos los que trabajan en la fila, más allá del agente asignado. Cuando los equipos acceden a ese dato en el tablero de incidentes son capaces de tomar mejores decisiones sobre las responsabilidades, sin depender de la coordinación manual.
5. Investigación, diagnóstico y resolución
En esta etapa se lleva adelante el trabajo real de solucionar el incidente, pero su eficiencia depende de la calidad de todas las fases anteriores.
Los agentes de nivel 1 suelen seguir un conjunto definido de pasos para una primera respuesta antes del escalamiento: consultan la base de conocimiento o los documentos con las soluciones provisionales, aplican medidas básicas de resolución y confirman si el problema es aislado o afecta a varios usuarios.
Si no pueden resolverlo dentro de un plazo definido, el incidente pasa al nivel 2 o al 3.
En este contexto es menester hacer dos distinciones importantes:
- Solución alternativa vs. resolución: la primera restablece el servicio temporalmente (reinicio de un servidor, redireccionamiento del tráfico a un sistema de respaldo), pero no aborda la causa subyacente. La segunda, en tanto, proporciona una solución definitiva. El ticket debe documentar cuál de las dos se aplicó.
- Escalamiento funcional vs. escalamiento jerárquico: el primero transfiere el ticket a un equipo con la experiencia técnica necesaria para su abordaje. El segundo involucra a la gerencia cuando el impacto, la duración o la visibilidad así lo justifican.
En este sentido, los datos de los activos desempeñan un rol de apoyo significativo: saber qué elemento de la configuración se ve afectado -historial, cambios recientes, dependencias- a menudo acelera considerablemente la identificación de la causa raíz.
InvGate Service Management ayuda en esta fase con la base de conocimiento integrada, donde los agentes acceden a casos anteriores y a soluciones documentadas sin salir de la interfaz del ticket, lo cual reduce el tiempo dedicado a problemas que ya fueron abordados con anterioridad. Complementariamente, las reglas de escalamiento automático reasignan dicho ticket al siguiente nivel si no se registra actividad dentro del plazo establecido por el SLA. De este modo, se evita que el tiempo transcurrido en un nivel inadecuado consuma silenciosamente el margen disponible para resolver el incidente.
La plataforma también se integra con los datos de los activos que se reúnen en InvGate Asset Management, mostrando el historial del Elemento de Configuración afectado directamente desde el ticket -información fundamental para un diagnóstico más rápido-. En este punto las capacidades de gestión automatizada de los incidentes demuestran la velocidad en la resolución.
6. Cierre
Si bien el cierre de un ticket parece una simple formalidad administrativa, lo cierto es que resulta un paso clave en el proceso de Gestión de Incidentes. En efecto, esta fase determina la calidad de los datos generados, que constituyen la base para los informes.
El cierre formal requiere:
- Confirmación del usuario: la persona debe corroborar que el servicio fue restablecido según sus necesidades. También existe un protocolo de tiempo de espera si no responde en un plazo determinado para que se proceda al cierre automático del ticket tras una notificación previa.
- Documentación de la resolución: informar qué se hizo, si se trató de una solución temporal o de una corrección permanente, y qué causó el incidente.
- Evaluación para abrir un registro del problema: si la resolución fue temporal o si el incidente forma parte de un patrón recurrente, tiene que activarse la Gestión de Problemas.
- Precisión de los tiempos: el sistema registrará tanto el momento de resolución como el del cierre formal, ya que estos datos se incorporan directamente a las métricas de Gestión de Incidentes (MTTR y cumplimiento de los SLAs).
7. Revisión posterior al incidente
La revisión posterior al incidente es la etapa que, cuando se lleva a cabo de manera formal, aporta el mayor valor a largo plazo, porque es el momento en que los datos recopilados a lo largo del ciclo de vida se transforman en información útil para la toma de decisiones y la mejora continua.
¿Cuándo realizar una revisión posterior al incidente?
- Obligatoria para cualquier incidente grave.
- Recomendada para incidentes que hayan provocado un incumplimiento del SLA.
- Recomendada para incidentes recurrentes, bajo la misma categoría de problema tres o más veces dentro de un período definido.
La revisión debe responder lo siguiente:
- ¿Cuándo comenzó realmente el incidente?
- ¿Cuándo comenzó el incidente en comparación con cuándo se detectó por primera vez? (Gap en la identificación)
- ¿En qué etapa el equipo dedicó más tiempo? ¿En qué punto se ralentizó el proceso?
- ¿Fue correcta la priorización, o se le otorgó al incidente una prioridad excesiva o insuficiente con relación a su impacto real?
- ¿La resolución fue permanente o provisional que dejó sin solucionar el problema subyacente?
- ¿Existe un patrón -en este incidente y otros similares- que justifique abrir un registro del problema?
Cabe aclarar la diferencia entre una revisión posterior al incidente y un análisis de la causa raíz: la primera se centra en el proceso al examinar el modo en que el equipo gestionó el incidente a lo largo de su ciclo de vida; el segundo se orienta a los aspectos técnicos al investigar qué ocasionó la falla en el sistema subyacente. Ambos son valiosos, pero responden preguntas diferentes. La revisión posterior al incidente a menudo genera un análisis de la causa raíz.
Los resultados de una revisión se incorporan directamente al sistema: actualizan los artículos de la base de conocimiento, refinen las taxonomías de las categorías, ajustan las reglas del flujo de trabajo y, si se justifica, crean un registro del problema para dar seguimiento a la causa subyacente hasta su resolución.
¿Cómo abordar las fases de la Gestión de Incidentes con InvGate Service Management?
La gestión del ciclo de vida de los incidentes a través de herramientas desconectadas entre sí genera problemas. En efecto, cuando la detección se realiza con una solución de monitoreo, el registro se lleva a cabo en un sistema de tickets, el conocimiento se almacena en un espacio independiente y las métricas se guardan en una hoja de cálculo; el proceso se ejecuta técnicamente, pero en la práctica queda fragmentado. Como consecuencia se generan retrasos en los traspasos entre las etapas, se pierde el contexto y los datos necesarios para la revisión posterior nunca se agregan de manera clara.
La ejecución del proceso de Gestión de Incidentes en una plataforma unificada cambia la dinámica operativa. Así lo hace InvGate Service Management:
- Automatización de los flujos de trabajo sin código: cada transición entre las fases -asignación, escalamiento, categorización, SLA, cierre- puede automatizarse mediante reglas configurables que no requieren trabajo de desarrollo. Esto elimina los pasos manuales que son más propensos a errores.
- Seguimiento del SLA: los temporizadores se activan automáticamente desde el momento en que se crea un ticket. Así, las reglas de escalamiento se ponen en marcha antes de que se produzca un incumplimiento, lo cual le da tiempo a los equipos para responder.
- Base de conocimiento centralizada: los agentes acceden a soluciones documentadas y alternativas directamente desde la interfaz del ticket, sin tener que cambiar a un sistema externo.
- IA para la detección de incidentes graves: la plataforma es capaz de identificar grupos de tickets relacionados que indiquen un posible incidente crítico, permitiendo a los equipos escalar de manera proactiva antes de que impacte en los usuarios.
- Tableros para saber el desempeño del ciclo de vida: el volumen de incidentes, el MTTR, el cumplimiento de los SLAs y los patrones de escalamiento están disponibles en tiempo real. Esto proporciona datos fundamentales en la fase de revisión posterior al incidente.
- Integración con la información de los activos: cuando se conecta con InvGate Asset Management, el Elemento de Configuración afectado por un incidente se aprecia directamente dentro del ticket -incluido su historial y los cambios recientes-, lo cual acelera el diagnóstico en la etapa 5.
El resultado es un proceso de Gestión de Incidentes con etapas que se vinculan entre sí: los datos reunidos en el momento del registro se encuentran disponibles durante el diagnóstico, la lógica del SLA establecida en la priorización se aplica hasta el cierre, y las métricas que surgen en la revisión posterior reflejan lo ocurrido en cada fase.
¿Quieres conocer en la práctica el modo en que InvGate Service Management respalda tu ciclo de vida de Gestión de Incidentes? Entonces comienza tu prueba gratuita de 30 días ahora mismo. La plataforma cuenta con la certificación de PeopleCert en las mejores prácticas de ITIL, incluida la Gestión de Incidentes.
Errores comunes en cada etapa (y cómo evitarlos)
Incluso las organizaciones que cuentan con un proceso documentado cometen errores recurrentes. La mayoría de los incidentes se resuelven eventualmente, pero las pequeñas fallas durante la detección, la clasificación, la investigación o el cierre a menudo provocan tiempos más largos de resolución, escalamientos innecesarios y problemas recurrentes.
Preguntas frecuentes
¿Cuáles son las etapas del ciclo de vida de la Gestión de Incidentes?
El ciclo de vida de la Gestión de Incidentes consta de siete etapas: detección e identificación, registro y documentación, clasificación y categorización, priorización, investigación y resolución, cierre y revisión posterior al incidente. Cada una aporta información para la siguiente, mientras que la fase final se utiliza para mejorar el procedimiento de cara al futuro.
¿Cuál es la diferencia entre el ciclo de vida de la Gestión de Incidentes y el proceso de Gestión de Incidentes?
El ciclo de vida define qué ocurre en cada etapa: la secuencia de actividades desde la detección hasta la revisión. El proceso establece cómo se llevan a cabo esas tareas: procedimientos, roles, responsabilidades y herramientas involucradas en cada fase. El ciclo es el marco; en tanto el proceso representa la implementación operativa.
¿Cuándo se debe realizar una revisión posterior al incidente?
Una revisión posterior al incidente es obligatoria después de cualquier incidente grave. También se recomienda luego de producirse un incumplimiento del SLA o que forme parte de un patrón recurrente -es decir, cuando la misma categoría de problema se presente varias veces dentro de un período definido-. La revisión examina el proceso (cómo se gestionó el incidente), no solo la causa técnica.
¿Cómo define ITIL la prioridad en la Gestión de Incidentes?
ITIL calcula la prioridad en función de la urgencia (la rapidez con la cual se debe resolver el problema) y el impacto (cuántos usuarios o procesos del negocio están afectados). La combinación de ambos determina el nivel de prioridad -generalmente de P1 a P4-, al que se asocian objetivos específicos de tiempo de respuesta y resolución.
En la práctica, este enfoque se implementa mediante una matriz de prioridades, que relaciona las distintas combinaciones de urgencia e impacto con los requisitos específicos de los SLAs.
