ITSM 101: Consejos claves para la Gestión de Incidentes (Parte 2)

La semana pasada, publicamos la primer parte denuestro blog de consejos útiles para la gestión de incidentes y examinamos los siguiente pasos de dicho proceso: identificación, registro, categorización, priorización y diagnóstico inicial (matcheo de incidentes). En esta segunda parte del blog vamos encontrar algunos consejos para incidentes que estén relacionados con: escalamiento, investigación y diagnóstico, resolución y restablecimiento del servicio, cierre, monitorización, seguimiento y comunicación del incidente.

Si un incidente no puede ser resuelto en el primer punto de contacto (en una llamada o cuando el usuario final carga el ticket) entonces es necesario que sea escalado en pos de restaurar el servicio. Existen dos tipos de escalamiento en una mesa de ayuda típicamente configurada:

1. Funcional

2. Jerárquico

Escalamiento Funcional, cuando se necesita del conocimiento y experiencia del siguiente nivel de soporte técnico para resolver el incidente. Así, por ejemplo, una escalamiento funcional podría ser desde la mesa de ayuda que brinda el soporte de primer nivel, al soporte de segundo nivel, o desde el soporte de segundo nivel al soporte de servicios de red.

Asegúrate de tener los roles y responsabilidades basados en prioridades para todos los equipos de soporte y de que estén documentados en sus Acuerdo del Nivel de Operación (OLAs en inglés). Algunos ejemplos de lo que pueden incluir son:

• Escala de tiempos para que se realice el escalamiento

• Escala de tiempos para responder a un escalamiento

• Roles y responsabilidades, quién hace qué.

• Cómo responder en caso de que ocurra un incidente mayor

El Escalamiento Jerárquico se refiere al nivel de experiencia y antigüedad y se invoca normalmente en caso de que existan quejas de un usuario final o de un propietario del servicio, o si se debe replantear la prioridad del incidente, elevándose.

Los ejemplos de escalamiento jerárquico incluyen, desde el agente de mesa de ayuda al líder del equipo, desde este último al gerente y desde el gerente al jefe de departamento.

El escalamiento jerárquico aplica si un líder u otra persona con más autoridad necesita ser consultado para tomar decisiones que están más allá de las competencias asignadas a cierto nivel o equipo. Tal es el caso cuando se requiere asignar más recursos para resolver un incidente específico rápidamente o elevar una orden de compra de equipamiento adicional. Un escalamiento jerárquico predefinido puede ahorrar tiempo en el caso de una gestión de escalamiento, por ejemplo:

• Agente de Mesa de Ayuda  a

• Líder de equipo de la Mesa de Ayuda a

• Gerente de Mesa de Ayuda a

• Jefe de TI a

• CTO

Consejo clave: Los escalamientos podrán ser algo atípico en la organización de IT pero eso no significa que no debas tener un plan para cuando se necesite realizarlas. Dedicale tiempo a entender los posibles escenarios de escalamiento  y quién necesitará hacer qué, cuándo. Con el tiempo, esto puede y debe ser ajustado,  a medida que las necesidades y el personal cambien.

Investigación y Diagnóstico

La realidad es que la investigación y el diagnóstico ocurren durante cada etapa del ciclo de vida del incidente junto con la monitorización, las actualizaciones y la comunicación.Tan pronto como se registra el incidente, el agente de la mesa de ayuda comienza a evaluar la llamada (o el ticket que cargó el usuario final) y a recopilar información. Esto puede tener como resultado, una solución de primera respuesta, o el incidente puede escalarse al soporte de segundo nivel, y más allá, donde la investigación y el diagnóstico continuarán hasta que el problema haya sido resuelto y el servicio normal haya sido restaurado.
La documentación y el apoyo, en formato de wikis, bases de conocimiento o sitios de capacitación, puede hacer una verdadera diferencia en esta etapa del incidente. Al compartir mejor el conocimiento y brindar buenos consejos, mejorarás disruptivamente las tasas de resolución de incidentes, pasando de bueno a excelente.

Consejo clave: una parte central de una eficaz gestión del conocimiento, es poder ver cómo se solucionó un incidente previo similar, así como los pasos que funcionaron y también los que no. Por lo tanto, al resolver un problema para el que no hay ningún artículo formal de conocimiento, asegúrate de capturar todo lo que fuiste haciendo para poder utilizarlo en beneficio de la siguiente persona.

Resolución y restablecimiento del servicio

 Días felices, ¡todo está solucionado! Pero antes de empezar a hacer tu baile de la victoria, prueba y vuelve a probar.

Consejo clave: es genial que, desde tu perspectiva, el incidente esté solucionado; pero también es necesario comprobar que las cosas se han resuelto para el usuario final o el propietario del servicio. Es por eso que la mejor práctica sugiere un segundo elemento de cierre de incidentes: la confirmación del cliente.

El cierre del incidente

Esto realmente se reduce a dos pasos: la confirmación del cliente y el cierre del incidente en tu herramienta ITSM / de mesa de ayuda.Siempre que sea posible, ponte en contacto con el usuario final / cliente para confirmar que todo esté bien y que estén conformes con que su incidente se cierre.

La segunda etapa es actualizar el registro de incidentes con lo que pasó y lo que hiciste para solucionarlo antes de cerrarlo.¿Recuerdas lo que dijimos antes sobre el conocimiento compartido? Esto es parte de ello.

Escribir simplemente solucionado en un incidente no ayudará a la siguiente persona si el problema se repite. No tiene que ser como en Guerra y Paz, sólo se necesita un pequeño resumen de cuál fue el problema y cómo lo solucionaste. Entonces ¡puedes considerar que tu trabajo está hecho! Ahora sí, haz tu baile de la victoria.

Consejo clave: Asegúrate de que tus agentes de mesa de ayuda comprendan la importancia de de tomar registros de los incidentes a lo largo del ciclo de vida del mismo. Desde quién es el usuario final y los detalles tecnológicos, hasta la actualización del progreso, la documentación completa de las causas y la resolución definitiva. No hacerlo le costará caro al equipo ya que los incidentes reaparecen con el tiempo.

En conclusión, la gestión de incidentes es uno de los procesos ITSM más importantes que usarás porque afecta a todos. Y seamos realistas, casi todas las empresas necesitan algún tipo de soporte de TI, ya sea propio o externalizado. El área de soporte de TI y de gestión de incidentes son una parte muy visible de TI. Se podría argumentar que son su rostro visible. Por lo tanto, si tu proceso de gestión de incidentes no es efectivo, afectará a la percepción de todo TI de manera negativa. ¿No me crees? Analistas de la industria lo han probado en sus investigaciones. Entonces, asegurate que tu proceso de gestión de incidentes funciona bien, que los problemas son capturados consistentemente, que el servicio es restaurado tan pronto como sea posible, y nada se pierda, se ignore o se olvide.

¿Cuáles son tus consejos claves para la gestión de incidentes? Nos encantaría que nos lo hagas saber en los comentarios.