Close

El camino hacia una mejor gestión de incidentes empieza aquí

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

Por Nick Wright, Director de operaciones de servicio de Atlassian

En primer lugar, necesito confesar algo: las personas de apoyo de primera línea son los héroes anónimos de todas las empresas.

De todas y cada una de las empresas.

Sinceramente, creo que el soporte técnico debe considerarse un sector de servicios, y los clientes deben poder compensar de alguna forma a los agentes que ofrecen un servicio excelente. Si pudiera, les dejaría con muchísimo gusto una buena propina a todos aquellos profesionales de soporte de tomo y lomo que han resuelto mis incidencias rápidamente y, además, con una sonrisa.

Pero a ver, que me estoy desviando. Si estás leyendo esto, es probable que gestiones o prestes servicio en un equipo de un centro de ayuda. Es probable que ahora mismo tengas el pelo en llamas. Porque este trabajo te quema de verdad. Además, ese olor a chamuscado es horrible. Hagamos algo al respecto: pongamos bajo control tu proceso de gestión de incidentes de TI.

Pero antes de sumergirnos de lleno en la gestión de incidentes, pongámonos de acuerdo sobre unos cuantos términos comunes.

Gestión de incidentes e ITSM

Si trabajas en el mundo de la TI, probablemente te habrás familiarizado con conceptos como la ITIL, la ITSM, los incidentes y los problemas. Ahora bien, para que todos nos entendamos sobre lo que vamos a hablar, a continuación te defino brevemente cómo empleamos estos términos en Atlassian:

La ITIL (biblioteca de infraestructuras de TI [del inglés, IT infrastructure library]) es un conjunto de prácticas recomendadas para la ITSM (hazte a la idea que es como un manual de estrategias).

ITSM (gestión de servicios de TI) es una estrategia habitual para crear, respaldar y gestionar servicios de TI. El concepto básico de ITSM es la idea de que la TI debe prestarse como un servicio. Además, una de las prácticas básicas de ITSM es la gestión de incidentes.

Los incidentes son eventos imprevistos de cualquier tipo que alteran o reducen la calidad del servicio (o amenazan con hacerlo). Una aplicación empresarial que deja de funcionar es un incidente. Un servidor web "agonizante" también puede serlo, porque va lento y eso afecta a la productividad. Y lo que es peor, existe el riesgo aún más grave de que se produzca un fallo completo.

Un problema es el origen no identificado de uno o varios incidentes. En el incidente anterior, donde la red agoniza y una aplicación empresarial ha dejado de funcionar, el problema subyacente podría ser un router mal configurado.

La importancia de la gestión de incidentes como práctica de ITSM

Entonces, ¿por qué la gestión de incidentes? ¿Por qué forma siquiera parte del universo de la ITSM?

La respuesta reside en la repercusión. Hay estudios que indican que los incidentes graves les cuestan a las empresas entre 100 000 $ y 300 000 $ de media por cada hora que un sistema está caído.

Tener un proceso de gestión de incidentes bien definido puede servir para reducir esos costes significativamente. Estas son las ventajas de contar con un proceso bien definido:

  • Resolución de incidentes más rápida
  • Menos costes o pérdidas de ingresos para la organización
  • Mejora de la comunicación (interna y externa) durante los incidentes
  • Mejora y aprendizaje continuos

El proceso de gestión de incidentes

Utilizaré el marco de trabajo de la ITIL para explicarte de forma general y a grandes rasgos cómo gestionar los tickets como es debido, pero la mayoría de los demás marcos de trabajo populares vienen a detallar conceptos más o menos parecidos con una jerga ligeramente distinta.

La clave para la gestión de incidentes es tener un proceso (que sea bueno) y ceñirse a él.

Sí, lo sé, solo eso ya puede antojarse desalentador, pero la buena noticia es que puedes aprender de la experiencia de miles de equipos más de servicios de TI.

Uno de los principales errores de las organizaciones de TI en crecimiento y con un volumen alto de actividad es intentar reinventar la rueda y crear procesos desde cero (sin aprovechar las prácticas recomendadas) o desarrollar herramientas de cosecha propia para el envío de tickets.

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

Nick Wright
Director de operaciones de servicio, Atlassian

Mi equipo y yo nos aseguramos de que las aplicaciones en la nube y la infraestructura de Atlassian funcionen al máximo nivel, y arde en deseos de contarle a todo el mundo cómo lo hacemos al tiempo que escalamos con rapidez. Soy kiwi (neozelandés), pero a pesar de esa desventaja lingüística, soy capaz de pronunciar fish and chips. Cuando no estoy trabajando, me podrás ver montando en bicicleta, jugando a videojuegos o pasando el rato con mi mujer y mi encantadora hija.