Cómo dar en el clavo con el proceso de gestión de incidentes como un verdadero profesional de las operaciones de TI

Identifica un incidente y regístralo

Los incidentes pueden venir de cualquier parte. Puede notificarlos un empleado o caer literalmente del techo sobre tu mesa (imagina un centro de red mal instalado y un falso techo en mal estado, aunque no lo decimos por experiencia…)

Sea cual sea el origen del incidente, los dos primeros pasos son sencillos: alguien identifica un incidente y alguien lo registra .

Si el incidente te llega a través del centro de asistencia, estos dos primeros pasos te los ahorras. Si recibes una llamada telefónica o el incidente se notifica por correo electrónico, por SMS o por paloma mensajera, el equipo de centro de asistencia deberá encargarse de registrarlo.

Para registrar incidentes (o, lo que es lo mismo, para crear tickets), lo habitual es tener que introducir estos datos:

• El nombre de la persona que notifica el incidente
• La fecha y la hora en las que se notifica el incidente
• Una descripción del incidente (lo que está inactivo o no funciona correctamente)
• Un número de identificación único asignado al incidente, para el seguimiento

Categorizar el incidente

Los dos pasos siguientes (categorizar y priorizar) son fundamentales, pero también se suelen pasar por alto. Asimismo, de los centros de asistencia con los que he trabajado, permiten distinguir los más "cuerdos" de los que... bueno, no lo están tanto.

En primer lugar, debes asignar una categoría lógica e intuitiva a cada incidente (y una subcategoría, según convenga). Si no lo haces, te será más complicado analizar los datos y buscar tendencias y patrones posteriormente, algo esencial para la gestión eficaz de problemas y la prevención de incidentes futuros.

En resumen, no te olvides de hacerlo. Ah, y no te conformes con una solución de centro de asistencia de IT que no te permita personalizar fácilmente las categorías de incidentes.

Jerarquizar el incidente por orden de prioridad

En segundo lugar, hay que asignar una prioridad a todos los incidentes.

Para priorizar un incidente, lo primero que debes hacer es evaluar su repercusión sobre el negocio. Ten en cuenta tanto el número de personas que se verán afectadas como las posibles implicaciones financieras, de seguridad y de cumplimiento del incidente. Esto te servirá para estimar las repercusiones negativas del incidente y la urgencia con la que debe resolverse.

En este caso, la práctica recomendada es definir los niveles de gravedad y prioridad antes de que el incidente llegue a ocurrir, para que los gestores de incidentes puedan determinar la prioridad fácil y rápidamente.

¿Y qué hago si no tengo clara la prioridad? Aplica el nivel más alto. Es mejor pasarse que no llegar y correr el riesgo de que se cuele un problema grave.

Cuando hayas definido estas prioridades, aborda todos los incidentes abiertos por orden de prioridad. La mayoría de las organizaciones establecen acuerdos de servicio claros en torno a cada nivel de prioridad, de modo que los clientes saben con qué plazo pueden contar para recibir una respuesta y una solución. Recomiendo encarecidamente aplicar esta práctica.

Respuesta

"Respuesta ante incidentes" es un término bastante amplio, así que vamos a desglosarlo en los pasos que será más probable que debas dar una vez identifiques, categorices y priorices un incidente.

Diagnóstico inicial
Vendría a ser como el triaje que se hace en los hospitales cuando llega un paciente nuevo. El empleado del centro de asistencia hace una primera suposición sobre la causa del error, para empezar a resolverlo o seguir los procedimientos apropiados y reunir los recursos adecuados para ello.

En este paso, las bases de conocimiento y los manuales de diagnóstico también son herramientas útiles.

Si el agente del centro de asistencia que está en primera línea puede resolver el incidente a partir de sus propios diagnósticos iniciales y con los conocimientos y herramientas disponibles, el incidente queda resuelto. De lo contrario, tocará escalarlo.

Escalación del incidente
"Escalación" suena a palabrota, pero no lo es en absoluto.

El equipo de soporte de primera línea debe ser capaz de resolver gran parte de los incidentes más habituales sin tener que escalarlos. Cuando no pueda ser, el objetivo es recopilar y registrar la información adecuada para que el soporte de segunda o tercera línea (con un perfil más técnico) disponga enseguida de toda la información necesaria y, de este modo, el incidente pueda resolverse cuanto antes.

Investigación y diagnóstico
Para ITIL, este es "su paso". Aunque en realidad es un proceso que se extiende a lo largo del ciclo de vida del incidente.

La persona de soporte de primera línea ya está investigando (hasta cierto punto) el incidente en el momento en el que recopila información; de hecho, podría llegar a diagnosticarlo correctamente e incluso resolverlo sin tener que escalarlo.

Si las cosas suceden así, te saltarás directamente los pasos de resolución, recuperación y cierre de incidentes.

Si no es el caso, la investigación y el diagnóstico estarán presentes en todos los pasos del proceso de escalación al soporte de nivel 2 y 3, o de incorporación de recursos externos o miembros de otros departamentos para que asesoren y ayuden con la resolución.

Resolución y recuperación
Finalmente (e idealmente, dentro de tus acuerdos de nivel de servicio o SLA), llegarás a un diagnóstico y darás los pasos necesarios para resolver el incidente. La recuperación simplemente implica la cantidad de tiempo que las operaciones pueden tardar en recuperarse por completo, ya que algunas correcciones (como parches de error) pueden requerir pruebas e implementación incluso después de determinar la resolución adecuada.

Cierre del incidente
Si el incidente se había escalado, vuelve al centro de asistencia para que se pueda cerrar. Para mantener la calidad y garantizar un proceso fluido, solo los empleados del centro de asistencia pueden cerrar incidentes. Los propietarios de cada incidente deben consultar con la persona que lo notificó para confirmar que la resolución es satisfactoria y que el incidente puede cerrarse realmente.

Conclusión: no te saltes ningún paso

Este proceso puede antojarse un formalismo innecesario, sobre todo si en el centro de asistencia solo cuentas con unos cuantos analistas. No obstante, independientemente de la estructura de tu equipo, el ciclo de vida del incidente sigue siendo el mismo.

Pongamos por caso que solo dispones de un analista en el centro de asistencia, por lo que no hay soporte de nivel tres. Sin embargo, los incidentes que sobrepasan los conocimientos del analista de tu centro de asistencia tienen que ir a parar a algún lado, ya sea en las manos de tu ingeniero jefe, las de un consultor externo o incluso las tuyas, ¿verdad?

¡Y ya está! Lo cierto es que cuentas con un soporte de nivel dos o tres (simplemente, solo sois tu ingeniero o tú).

¿Adónde quiero ir a parar con todo esto? Pues que, aunque puede parecer que la ITIL son puras interpretaciones, no te enredes en ellas. Busca formas sencillas de adaptar la jerarquía organizativa y los flujos de trabajo de procesos para que encajen en un marco de trabajo de gestión de servicios de TI sencillo como el que he explicado antes.

Con ello, prestarás un servicio de atención al cliente muy superior y aportarás mucho más valor al negocio. (Además, de propina, tu pelo dejará de arder mucho más rápido).

Por último, unos cuantos recordatorios:

• Registra todos los incidentes. Asígnales un número único y anota los datos importantes (como la fecha, la hora y la descripción) en un sistema de centro de ayuda central.
• Si tienes un gran número de destinatarios internos o externos a los que comunicar las actualizaciones de incidentes, considera la opción de crear una página de estado para la comunicación de incidentes.
• Asigna a cada incidente una categoría (y una subcategoría, según sea necesario).
• Asigna a cada incidente un nivel de prioridad y a cada nivel de prioridad un SLA.
• Define claramente las funciones para los encargados de responder ante incidentes, como el responsable de la gestión de incidentes, el gestor de incidentes graves y el responsable de comunicación.
• Siempre que sea posible, proporciona a tu equipo de soporte de primera línea artículos de la base de conocimientos y scripts de diagnóstico de incidentes para ayudarlo a resolver incidentes rápidamente.
• Asegúrate de que el centro de asistencia mantenga siempre un control del progreso, del enrutamiento y del estado de los incidentes.
• Y no te dediques solamente a apuntar los datos de los incidentes. ¡Análizalos! Busca tendencias, patrones y posibles problemas subyacentes que puedan reducir el volumen de los incidentes y mitigar el riesgo.

Sobre el autor