Gestión de incidentes ITIL

Este blog cubre las áreas de conocimiento clave de la Gestión de Incidentes.

1. Visión general de la gestión de incidentes
2. Ciclo de vida del incidente
3. Escalada de incidentes
4. Escalada funcional frente a escalada jerárquica
5. Beneficios, costes y retos

Lo primero es lo primero: antes de profundizar en cada área, es mejor tener una buena idea de las terminologías básicas y fundamentales. Para aquellos de ustedes que planeen presentarse al examen de ITIL, esto será muy importante saberlo. Por ejemplo, ¿qué es un "Incidente"?

Según el Glosario ITIL:

Incidente: (Operaciones de Servicio) Interrupción no planificada de un Servicio de TI o reducción de la calidad de un Servicio de TI. El fallo de un elemento de configuración que aún no ha afectado al servicio también es un incidente. Por ejemplo: Fallo de un disco de un conjunto espejo.

Gestión de Incidentes: (Operaciones de Servicio) Proceso responsable de la gestión del ciclo de vida de todos los incidentes. El objetivo principal de la gestión de incidencias es devolver el Servicio de TI a los usuarios lo antes posible.

Estas dos definiciones son muy importantes de conocer y se preguntan con bastante frecuencia en el examen de ITIL.

Visión general de la gestión de incidentes

• Disminuir o incluso eliminar los efectos o incidencias de las interrupciones informáticas, las perturbaciones o la reducción de la calidad.
• Los usuarios deben volver al trabajo lo antes posible
• Contratar a especialistas adecuados para registrar, clasificar y asignar todos los incidentes.
• Se debe supervisar el progreso
• Las incidencias deben resolverse TODAS
• El proceso debe cerrarse DESPUÉS de la resolución

Objetivos y ventajas de la gestión de incidentes

• Reducir el impacto en la empresa
• Mejorar la productividad de los usuarios
• Obtener una supervisión de incidentes independiente y centrada en el cliente
• Facilitar la información sobre los ANS (Acuerdos de Nivel de Servicio)
• Menor coste de la actividad empresarial
• Reaccionar con rapidez y eficacia
• Supervisión activa de los dominios y servicios de los usuarios
• Evitar que los problemas se agraven
• Mayor satisfacción del usuario/cliente
• Operaciones más precisas
• Evitar "demasiados cocineros

Ya hemos definido las "Incidencias". Veamos ahora el "Problema".

Los problemas causan incidencias. Las incidencias no se convierten en problemas. El problema es la causa subyacente y desconocida de una o varias incidencias. Por ejemplo, uno de los discos duros ha fallado. Si falla un disco, esa es laincidencia. Sin embargo, el problema es la causa subyacente de la incidencia. ¿Es un problema de configuración? Hardware problema? Es muy importante recordar la diferencia entre una incidencia y un problema.

Registros de incidentes frente a registros de problemas:

• Los registros de incidencias se centran en el usuario final
• La gestión de informes de incidentes se centra en la medición del tiempo de inactividad y el impacto en la empresa
• Los registros de problemas comienzan con la decisión de la dirección de TI de invertir recursos informáticos y tiempo de inactividad del usuario final para la investigación de la causa raíz y la aplicación de la resolución.
• Los registros de problemas se centran en los procesos informáticos internos
• Gestión Elaboración de informes sobre problemas, centrándose en las causas profundas y aplicando soluciones estructurales.

Ciclo de vida del incidente

Como gestor de incidencias, mientras prepara su solución de Service Desk y gestión de incidencias, a continuación se muestra un diagrama típico del ciclo de vida de las incidencias con el que posiblemente podría estar trabajando.

El primer paso es Detectar y Registrar. Se trata de la aceptación original de la solicitud al Service Desk. En ese momento, se crea el Registro de Incidentes. El segundo paso es clasificar y dar soporte. Por ejemplo, ¿el problema está relacionado con software o hardware , o es una solicitud de servicio? El incidente se codifica según el tipo de incidente, el estado o su impacto en la organización. ¿Es urgente? ¿Es crítica? ¿Cuál es su prioridad? ¿Qué relación tiene con el Acuerdo de Nivel de Servicio? A partir de ahí, el usuario puede recibir sugerencias del Service Desk basadas en el guión, o quizás, basadas en la experiencia para resolver el incidente o solucionar el problema, aunque sólo sea una solución temporal. Si se trata de una Solicitud de Servicio, en ese momento pasaríamos a un proceso diferente, ya que la Solicitud de Servicio no implica los pasos de Investigación y Diagnóstico.

Si no hay soluciones conocidas para este incidente en particular, entonces será investigado y diagnosticado más a fondo por el grupo del Service Desk o pasará por el proceso de escalado. Si se ha encontrado la solución, la incidencia puede entonces "resolverse". El paso "Resolver y recuperar" debe tener lugar. Tenemos que tener una solución para el incidente. Una vez que tenemos la solución a la incidencia, pasamos al Cierre. Se pregunta al usuario si está satisfecho con la resolución. Si lo está, cerramos la incidencia. Podemos hacer una encuesta o un seguimiento si queremos mejorar este proceso.

A lo largo de cada paso del camino, debemos hacer un seguimiento continuo y supervisar los progresos.

Escalada de incidentes

Aquí tenemos dos tipos diferentes de escalado: Escalado horizontal y escalado vertical (esto también se pregunta con frecuencia en el examen de Fundamentos de ITIL). En pocas palabras, el Escalado de Incidentes consiste en pasar el problema a un personal de mayor nivel de experiencia/autoridad.

Toda organización debería tener un modelo de escalada. Hagamos un repaso en términos sencillos para demostrarlo.

A un nivel muy básico, en primer lugar tenemos el Nivel 1. Este nivel se encarga de registrar y detectar el incidente. Esto vendrá en forma de algún tipo de petición. Puede ser de un usuario, cliente, sistema, aplicación, etc. Si la petición es una Solicitud de Servicio, por ejemplo, un nuevo empleado necesita configurar una cuenta de dominio, entonces este tipo de petición, como se mencionó anteriormente, pasaría por un Procedimiento de Solicitud de Servicio. Una vez que la incidencia llega a nuestra línea de Nivel 1, pasará al siguiente paso, Soporte. Si nuestro servicio de asistencia puede resolver la incidencia, pasamos directamente a la recuperación de la resolución y cerramos la incidencia.

Sin embargo, si el Support Desk no ha sido capaz de resolver la incidencia, entra en juego el escalado, lo que denominamos Tier 2. Este escalado, como ya se ha mencionado, puede ser horizontal o vertical.

• La escalada funcional (horizontal) es un proceso que consiste en incorporar a compañeros de trabajo, personal interno con conocimientos especiales o privilegios de acceso adicionales.
• La escalada jerárquica (vertical) implica dirigirse a niveles superiores. Por ejemplo, cuando se trata de un problema de red, tendríamos que ponernos en contacto con nuestro centro de datos, que está fuera de nuestra organización.

Desde el punto de vista del diseño del Service Desk, querríamos desarrollar primero la Escalada Horizontal para asegurarnos de que tenemos personal para dar soporte a nuestros usuarios.

Beneficios, costes y retos de la gestión de incidentes

Veamos primero las ventajas de la gestión de incidentes:

• La reducción del impacto en la empresa de los problemas e incidentes, incluidas las solicitudes de servicio, permite una mayor eficacia.
• Le permitirá introducir mejoras y cambios proactivos que facilitarán el funcionamiento de su empresa.
• Gestión de SLA orientada a la empresa
• Al mejorar la supervisión y el rendimiento, recibimos un servicio de mayor calidad
• Mejor utilización y eficiencia del personal
• Aprender de los incidentes y problemas nos permitirá eliminar futuros incidentes y solicitudes de servicio.
• Ayúdenos a mejorar la satisfacción del cliente/usuario

Todo tiene su precio y sus retos. La gestión de incidentes también los tiene:

• Planificación y ejecución iniciales - comunicación, proceso de formación
• Formación y puesta en marcha
• Hardware y software herramientas que se utilizarán (sistema de supervisión, sistema de tickets)
• Los usuarios/el personal se saltan los procedimientos; si el proceso es demasiado complejo o burocrático
• Atasco de incidentes - sobrecarga de procesos
• Demasiadas escaladas
• Falta de definiciones claras, acuerdos de nivel de servicio y compromiso del personal y la dirección.

Como puede ver, la implantación de un proceso de gestión de incidencias tiene muchas ventajas y toda organización debería tener un proceso de gestión de incidencias claramente definido si desea prestar un apoyo eficaz a sus clientes internos y externos.